14:00:18 <licquia> #startmeeting LSB Bug Triage 2014 Apr 18
14:00:18 <lsbbot> Meeting started Fri Apr 18 14:00:18 2014 UTC.  The chair is licquia. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:18 <lsbbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:01:01 <licquia> good morning
14:01:06 <orc_emac_> kihi
14:01:09 <orc_emac_> hmm
14:01:13 <orc_emac_> licquia: hi that is
14:01:25 <licquia> #info lsb: 2 reopened, 2 pleasetest, 2 new
14:01:31 <licquia> #info fhs: 27 new
14:01:56 <mwichmann> be right there, fininshing wording on another bug I forgot
14:01:58 <licquia> orc_emac_: heh
14:02:54 <mwichmann> make that 3 new
14:03:24 <licquia> #info lsb: 2 reopened, 2 pleasetest, 3 new
14:03:30 <orc_emac_> licquia: saw and email from DLK about a security update for bgzla
14:03:39 <licquia> yup, saw that too
14:03:39 <orc_emac_> DKL ...
14:03:43 <orc_emac_> to issue later today
14:03:57 <licquia> oh? there's another one?
14:04:05 * licquia saw one earlier this week
14:04:11 <orc_emac_> dunno -- read it last nite
14:04:21 * orc_emac_ looks
14:05:40 <licquia> alright, let's get started
14:05:44 <licquia> !lsbbug 3195
14:05:48 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3195 normal, P2, ---, mats, REOPENED , LSB packages with unowned directories uninstallable on some rpm implementations.
14:06:05 * licquia saw that, had an action item from last week to do that release
14:06:20 <licquia> thought he had gotten to all those, but obviously not
14:07:13 * licquia proposes leaving this at reopened, adding action item for this week
14:07:15 <orc_emac_> licquia: actually that was a released patch seemingly not applied
14:07:28 <orc_emac_> as I recall
14:07:35 <licquia> right; the release needs to happen, didn't last week
14:07:59 <mwichmann> be good to get it out since a real-live user was battling it (dunno if got around it or not)
14:08:08 <mwichmann> we only have like four of those
14:08:09 <licquia> yup
14:08:31 <licquia> #action licquia release fixed tet-harness for 3195
14:08:43 <mwichmann> qmtest I thought it was
14:09:11 <licquia> it was, silly me
14:09:28 <licquia> #info correcting previous action
14:09:44 <licquia> #action licquia release fixed qmtest-harness for 3195
14:10:00 <licquia> !lsbbug 3599
14:10:02 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3599 normal, P2, ---, licquia, REOPENED , rework development Release naming to add a leading '0.' before the YYYYMMDD
14:10:29 <mwichmann> I put a patch that can be considered "generic" there
14:10:51 <mwichmann> note: do not try to apply it to tet-harness, it's different and needs some attention
14:11:09 <mwichmann> and did up build_env, misc-test and runtime-test
14:11:09 <licquia> right, i remember that
14:11:18 * licquia looks at snapshots
14:11:27 <mwichmann> not like we can have completely common stuff or anything... :(
14:12:19 <mwichmann> as usual there are old pkgs hanging around because of s390
14:12:23 * licquia sees the change in misc-test and build_env
14:13:14 <licquia> and the generic form in the bug is against perl-test; not applied yet there?
14:13:18 <mwichmann> no
14:13:28 <mwichmann> I don't think anyway
14:13:43 * licquia sees the last scheme still there
14:13:52 <licquia> -0.date
14:14:12 <licquia> so does this seem to do the right thing where it's applied?
14:14:22 <mwichmann> does to me
14:14:41 <licquia> i.e. if i get an inclination to churn this out across the board, we can close this out for good
14:14:50 <licquia> or if someone else does
14:15:00 <mwichmann> aside: recently restarted firefox with a zillion tabs open taking 360k
14:15:05 <mwichmann> (on windows)
14:15:18 <licquia> fun
14:15:23 <mwichmann> by the time I have to kill it because the system has gotten non-responsive it wil be around 1gb
14:15:30 <mwichmann> no problems here, move along
14:15:46 <mwichmann> 360m that was
14:16:23 <orc_emac_> ./qmtest-harness/lsb-qm-2.2-11.20140415.lsb4.ppc64.rpm
14:16:25 <orc_emac_> seen
14:16:50 <orc_emac_> ./build_env/lsb-runner-4.1.76.0.20140315-5.s390.rpm
14:16:50 <orc_emac_> ./qmtest-harness/lsb-qm-2.2-11.20140415.lsb4.ppc64.rpm
14:17:31 <orc_emac_> ./build_env/lsb-build-4.1.76.0.20140315-5.src.rpm
14:17:45 <mwichmann> the 390s are trying to complete a build which has already been going forever
14:17:59 <licquia> heh
14:18:03 <mwichmann> the srpm matching the last one will stick around until a new one flushes it
14:18:04 <orc_emac_> ./xts5-test/lsb-test-xts5-5.1.5-46.20140414.lsb5.i486.rpm
14:18:21 <orc_emac_> ./xts5-test/lsb-test-xts5-source-5.1.5-46.20140414.lsb5.x86_64.rpm
14:18:58 <mwichmann> runner matches to lsb-build now
14:19:04 <mwichmann> anyway... move on?
14:19:05 <licquia> those will likely need some special attention as well
14:19:16 * licquia writes a comment on the bug
14:19:20 <orc_emac_> [root@precision380-64-kvm snapshots]# find -name "*201*" | grep -v "\-0.201" | grep src | wc
14:19:30 <orc_emac_> yields 7 examples
14:19:42 <orc_emac_> I will put as status in the bug when you are done
14:20:05 <licquia> ok, done
14:20:27 <licquia> #agreed change for 3599 passes muster; roll out as we're fixing other things
14:20:32 <orc_emac_> and mine done as well
14:20:45 <licquia> !lsbbug 3946
14:20:47 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3946 normal, P2, 4.1-updates, licquia, PLEASETEST , Add scandir and alphasort interface with tests to olver-core
14:20:58 <licquia> and...
14:21:03 <licquia> !lsbbug 3947
14:21:05 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3947 normal, P2, 4.1-updates, licquia, PLEASETEST , Extend mutex interface in OLVER to support prioceiling and protocol
14:21:20 <licquia> did a test run, had weird vm issues when i did
14:21:25 <licquia> need to try again
14:22:08 <licquia> #action licquia retry test run to verify 3946 and 3947
14:22:34 <licquia> !lsbbug 3965
14:22:36 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3965 normal, P2, ---, licquia, NEW , old lsb-runner packages in repositories
14:23:18 * licquia takes a quick look at something re: that
14:24:12 <orc_emac_> that package was enumerated in my earlier list as well as mal-named
14:24:25 <orc_emac_> [root@precision380-64-kvm snapshots]# find -name "*201*" | grep -v "\-0.201" | grep src | grep lsb-run
14:24:28 <orc_emac_> ./lsbdev-runner/lsb-runner-4.81.0.0.20130311-2.src.rpm
14:26:09 * licquia thinks he may have found the smoking gun
14:26:43 <orc_emac_> was in in that warehouse in the end scene of the first Indiana Jones movie?
14:27:18 <licquia> lsb1:~ # ls -l /opt/buildbot/lsb-master/lsbdev-runner-*tar.gz
14:27:18 <licquia> -rw------- 1 buildbot users 1441862 Mar 18  2013 /opt/buildbot/lsb-master/lsbdev-runner-devel-ia64.tar.gz
14:27:18 <licquia> -rw------- 1 buildbot users 1103411 Mar 18  2013 /opt/buildbot/lsb-master/lsbdev-runner-devel-ppc32.tar.gz
14:27:18 <licquia> -rw------- 1 buildbot users 1096066 Mar 18  2013 /opt/buildbot/lsb-master/lsbdev-runner-devel-ppc64.tar.gz
14:27:20 <licquia> -rw------- 1 buildbot users 1019003 Mar 11  2013 /opt/buildbot/lsb-master/lsbdev-runner-devel-x86_64.tar.gz
14:27:27 <licquia> looky looky
14:27:38 <mwichmann> http://www.imdb.com/title/tt0120735/
14:27:46 <licquia> heh
14:27:49 <orc_emac_> strange permissions
14:28:06 <mwichmann> okay, so they're stored away somewhere magical
14:28:32 <mwichmann> tarballs?
14:29:08 <licquia> yup; those are the build artifacts as transferred directly from the slaves
14:29:29 <licquia> the update-snapshot script looks for them and unpacks them to build the snapshots area
14:29:35 <licquia> (and staging too)
14:29:54 <mwichmann> but likely not being transferred any longer - at least two of those vm's have been rebuilt since then
14:30:06 <licquia> right, but the tarballs are still there
14:30:20 <licquia> so the specific problem should go away later today, but there's a more general problem
14:30:31 <licquia> we need to delete old tarballs from buildbot
14:31:23 <mwichmann> this happens if a pkg is dropped, right?  we don't do often; in this case, I moved where runner got built from
14:32:27 <licquia> yup, exactly
14:32:43 <mwichmann> we do continue to see no-longer-built things like xdg-utils, but generally I don't think this is a frequent event
14:33:02 <licquia> the other thing, though, is that if our build of X in snapshots is really a year old and hasn't been tested/released, is it really still valid?
14:33:33 <licquia> if something current isn't being built regularly, that's a problem
14:33:44 <mwichmann> for /current/, yes
14:34:06 * licquia proposes deleting tarballs of builds that are older than 3 months
14:34:49 <orc_emac_> licquia: I saw the two new 390 units coming online so ypou will have a scriopt file for me ... -- perhaps beef that up into a puppet recipe, that salvage certificates, wipes, and redeploys each slave from pristine quarterly?  sort of a make clean ; make world
14:34:51 <mwichmann> in snapshots... I think that's fair enough
14:35:24 <mwichmann> today was Ubuntu Trusty day, eh?
14:35:24 <licquia> orc_emac_: not yet, they're not quite online
14:35:27 <orc_emac_> licquia: +1 on find deleting working older than N days, N initially 90
14:36:26 <mwichmann> brief bio break, back in a mo
14:36:30 <licquia> #agreed for 3965, delete builds older than 3 months old
14:38:28 <licquia> !lsbbug 3966
14:38:30 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3966 normal, P2, ---, mats, NEW , broken historical gtk links
14:39:38 <mwichmann> back
14:40:01 <licquia> so, old gtk std links
14:40:10 * licquia wonders if archive.org has them
14:40:58 <mwichmann> persistent problem for us, and I'm not even sure this bug is unique - didn't do a search
14:41:24 <licquia> https://web.archive.org/web/20081103025420/http://library.gnome.org/devel/gdk/2.8/
14:41:41 <licquia> so, for at least some of these, the answer seems to be "yes"
14:41:53 <mwichmann> cool
14:42:11 <mwichmann> scrape for archiving on our server?
14:42:28 <mwichmann> or point to this one?
14:42:39 <licquia> good question
14:43:09 * licquia wonders if we shouldn't scrape all our standards
14:43:43 <mwichmann> at least ones with appropriate licenses (that becomes the painful bit)
14:44:02 <licquia> yup, but the ones without appropriate licenses at least tend to be maintained more sanely
14:44:21 <mwichmann> that's why curses spec vanished, yes.  I get you.
14:44:32 <mwichmann> :)
14:44:39 <orc_emac_> mwichmann: US copyright law and archival backups to retain potentially disappearing content to which one is entitled access, are compatible -- include IAAL disclaimer
14:44:43 <licquia> did we ever run the link checker?  does the bug contain the complete list?
14:45:13 <orc_emac_> I used such archival copies just a couple weeks ago on something that RHT took down
14:45:14 <mwichmann> I did not, someone was going to make a recipe for doing elsewhere
14:45:39 <orc_emac_> prolly me .. I am getting there
14:45:58 * licquia thinks it tends to be gtk that's the problem anyway
14:46:04 <mwichmann> and then there was the bug about the secondary links
14:46:25 <mwichmann> yes, they are keeping more versions now they moved everything a couple of years ago
14:46:53 <mwichmann> but the ones from before the move to developer.gnome.org, not so much
14:47:06 <mwichmann> certainly not the first time had a prob over the gtk ones
14:47:09 <licquia> yeah, think someone got an idea to clean house
14:47:50 <licquia> if we ever did secondary links, we could point the secondary links for old gtk+ stuff to archive.org
14:48:38 <mwichmann> so it seems we've got a chain of stuff here
14:49:07 <mwichmann> I think the link checker will just do "current" so would not have spotted the stuff in this bug
14:49:23 * licquia looks for the secondary links bug
14:49:35 <mwichmann> except where those links are the current ones, if any
14:49:49 <mwichmann> 3960
14:50:03 <licquia> !lsbbug 3960
14:50:05 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3960 normal, P2, ---, licquia, ASSIGNED , url_checker should also examine ISrefspecurl
14:50:40 <mwichmann> wow, sdk build finished on one of the 390s
14:50:45 <licquia> heh
14:51:13 <mwichmann> buildbot didn't seem to update that on display yet
14:52:04 <licquia> it's possible that both builders were building the sdk
14:52:28 <licquia> when we move to native builders for s390, a lot of those problems will go away
14:53:00 <licquia> ok, so anything to do for 3966 other than mark assigned?
14:53:46 <mwichmann> don't think so
14:54:02 <licquia> #agreed mark 3966 assigned; maybe use archive.org links for missing specs
14:54:09 <mwichmann> and as noted, this only breaks navigator, so while we really should have our ducks on line, not strictly a blocker
14:54:16 <licquia> !lsbbug 3967
14:54:18 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3967 normal, P2, ---, licquia, NEW , runtime tests setup does not get architecture string right
14:54:54 <orc_emac_> I thnks this was an EASYFIX, as it was counting on RPM rather than the shell to set that value
14:55:20 <mwichmann> dunno about easy, I tried a few alternatives without getting it right either
14:55:25 <orc_emac_> find is looking for the relavant files for me atm
14:55:29 <mwichmann> too many layers of indirection...
14:55:53 <orc_emac_> mwichmann: thot coders LOVED pointers
14:55:53 <mwichmann> make -> shell/sed -> specfile -> shell/sed -> shell
14:56:09 <mwichmann> rpm was in that chain
14:56:24 <orc_emac_> rpmbuild is just a shell script controller with macros
14:56:47 <licquia> is this a situation where a variable used to be set by rpm, but isn't anymore?
14:57:00 <mwichmann> it's set by rpm,
14:57:06 <licquia> i.e. %{_arch}
14:57:20 <mwichmann> but that's not available in the context of the shell that runs the sed instruction, apparently
14:57:40 <licquia> ah, i see; that's never worked, then
14:57:48 <orc_emac_> rpm runs it in a subschell, so it is out of scope for external seds
14:58:24 * licquia vaguely recalls that we can ask rpm for that macro's setting
14:58:50 <orc_emac_> VALUE=` rpm --shoqrc | grep "_arch" | cut ...  `
14:58:59 <orc_emac_> showrc
14:59:02 <licquia> so maybe that's the best answer?
14:59:16 <orc_emac_> that gets most but not all (when a spec file does local over rides -- not relevant here
14:59:31 <licquia> yeah, should work for our purposes
15:00:10 <mwichmann> I wanted to record this, but don't see it as high prio
15:00:40 <mwichmann> you can deduce arch from the uname output that's stuffed into a different info line
15:00:50 <mwichmann> 5|Linux madison.wichmann.us 3.13.9-100.fc19.x86_64 #1 SMP Fri Apr 4 00:51:59 UTC 2014 x86_64|System Information
15:01:11 <licquia> maybe that's a better source for this info
15:01:15 <orc_emac_> mwichmann: we snould pull it within any possible setarch environment
15:01:20 <orc_emac_> more portible
15:01:34 <licquia> uname -m might be useful here
15:01:36 <mwichmann> uname outputs not necessarily compatible with the LSB arch names
15:01:45 <orc_emac_> licquia:  what mwichmann said
15:01:59 <mwichmann> and for our builds, we use buildarchtranslate to get the ones we want
15:02:31 <licquia> odd thing, though; shouldn't macros be expanded in the spec file before running those sed commands?
15:03:18 <orc_emac_> licquia: ./runtime-test/scripts/package/lsb-test-core.spec.sed is out in shell space, not rombuild
15:03:21 <orc_emac_> rpmbuild
15:03:35 <mwichmann> I have one other question when we're done with this one...
15:04:05 <licquia> i see now, right
15:04:18 <licquia> ok, adding a note and marking assigned.  works for everyone?
15:04:24 <mwichmann> yes
15:04:25 <orc_emac_> licquia: ok
15:04:42 <mwichmann> question was on these network tests...
15:04:57 <mwichmann> considerable rework on recv*, which orc_emac_ has reviewed
15:04:58 <licquia> ok
15:05:08 <mwichmann> should we push those through, or wait?
15:05:33 * licquia looks
15:05:48 <licquia> this is 3525?
15:05:56 <mwichmann> 3524
15:07:40 <licquia> so after a very quick look, i'd say let's just push and try it
15:07:44 <mwichmann> futzing with runtime-test in any significant way makes me nervous
15:07:46 <mwichmann> okay
15:07:56 <licquia> worst case, we revert and try again
15:08:02 <mwichmann> I'll add a small patch to fix the "uses fcntl wrong" problem in accept and connect tests,
15:08:08 <licquia> esp. w/ two sets of eyes on the patch
15:08:12 <orc_emac_> mwichmann: it is mor obviously correct code after ...
15:08:19 <mwichmann> but not try to do the same (needed) full rework on them
15:08:21 <mwichmann> time problem
15:08:55 <licquia> yup
15:09:34 <mwichmann> okay, these are all ready to go except the patching just mentioned, so will push in a few minutes and we'll see
15:09:40 <licquia> #agreed push patch to 3524 and try it
15:09:46 <licquia> anything else?
15:09:53 <mwichmann> not this time
15:10:01 <licquia> ok
15:10:01 <mwichmann> "review 5.0 block list" has to wait for some other
15:10:07 <licquia> #endmeeting