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