[00:44] <fginther> wgrant, yes. any idea what might be causing the 401 Unauthorized error here: https://jenkins.qa.ubuntu.com/job/mir-saucy-armhf-ci/5/console
[00:45] <fginther> wgrant, it's intermittent, the same exact job will pass if retried
[00:46] <fginther> it's a relatively new issue, I don't recall seeing it prior to this week. Now they are fairly frequent
[00:46] <wgrant> fginther: Nothing's changed on the Launchpad size
[00:46] <wgrant> side
[00:46] <wgrant> There are two rules when Launchpad checks OAuth timestamps:
[00:46] <wgrant>  - The timestamp must be within 60 minutes of the current time.
[00:46] <wgrant>  - The timestamp must be no more than 60 seconds older than the latest request from the same OAuth token.
[00:47] <wgrant> In this case, the second criterion is failing.
[00:47] <wgrant> You're making a request with a timestamp that's a minute older than some other request with the same token.
[00:47] <wgrant> Perhaps the slave's system clock is incorrect.
[00:47] <fginther> wgrant, let me check
[00:49] <fginther> wgrant, it does appear to be 10 minutes behind
[00:50] <wgrant> That'd do it.
[00:50] <fginther> wgrant, thanks for the help
[00:50] <wgrant> np
[07:04] <dholbach> good morning
[07:48] <apw> pitti, these started recently i assume, can you tell what kernel did not show these issues 'before'
[07:50] <apw> pitti, as the recent kernel upload on the face of it does not have any ext4 changes at least
[07:55] <apw> pitti, so perhaps what i need is an example of the test that is failing that i can try and run here
[08:33] <zequence> Anyone available for a fairly simple upload (artwork update)? lp:ubuntustudio-menu
[08:34] <Laney> zequence: I recommend that you file a bug and subscribe ubuntu-sponsors
[08:38] <zequence> Laney: Right. Thanks
[10:48] <doko> mwhudson, are you porting libgo to aarch64?
[11:09] <doko> cjwatson, is Gerhard Fuchs still supposed to maintain packages.ubuntu.com?
[11:13] <cjwatson> doko: Gerfried; but yes, I believe so
[12:36] <pitti> Good morning
[12:36] <Ursinha> good morning pitti
[12:39] <pitti> apw: so far I know https://jenkins.qa.ubuntu.com/job/saucy-adt-firefox/150, https://jenkins.qa.ubuntu.com/job/saucy-adt-update-manager/93, https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-skimage/6/ARCH=amd64,label=adt/
[12:39] <pitti> apw: it only seems to affect amd64, and their syslogs have all rather random messages like that
[12:40] <pitti> apw: it seems to trigger with lots of I/O, like installing lots of dependencies with dpkg and all that
[12:41] <pitti> apw: haven't examined in more detail yet (sorry, plumbers conf and all that jazz)
[12:55] <apw> pitti, those were the only three i could find also, can we get one of them rerun, as i have run the skimage one 20 times without reproducing it
[12:55] <apw> pitti, following the instructions in your wiki on the subject
[12:56] <pitti> apw: these VMs run on precise, perhaps that's related?
[12:56] <pitti> apw: yes, I'll try to re-run the three, at least to get some more patterns
[12:56] <apw> pitti, sounds good
[12:57] <pitti> running now
[12:57] <apw> pitti, testing on a raring system indeed, so that might relate
[12:58] <apw> pitti, that tends to imply it is not the payload kernel in this case of course ...
[13:00] <pitti> apw: or that some of the assumptions it makes aren't valid any more on top of an old kernel or so?
[13:00] <pitti> apw: u-manager failed again (link coming)
[13:01] <apw> pitti, are we able to run these against older kernel easily, as they seem to have appeared so suddenly
[13:01] <apw> pitti, and we prolly need to ask the host if it changed kernel recently as well
[13:02] <apw> pitti, feel free to pass me on to whoever owns that box to ask
[13:02] <pitti> apw: jibel and I do, but I'm afraid my day today is packed with plumber conf stuff
[13:03] <pitti> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-update-manager/94/ARCH=amd64,label=adt/ is the new failure (look at syslog)
[13:04] <pitti> apw: ah sorry, unrelated this time; it didn't even get that far, pykde got uninstallable
[13:04] <pitti> so let's wait for the other two
[13:06] <apw> pitti, ok
[13:09] <pitti> apw: hah, skimage succeeded now; so what kind of sun rays hit us this time..
[13:10] <apw> pitti, indeed, can we tell which host ran the previous ones (is it the same one, ie is there more than one)
[13:10] <apw> pitti, i suspect some poking of the host is appropriate
[13:10] <pitti> apw: yes, we can
[13:10] <pitti> need to run now, sorry
[13:10] <apw> pitti, np, that the reruns are working takes the pressure off
[13:25] <cjwatson> infinity: I rebuilt some Fortran packages for gfortran 4.8, but I don't think that's the scilab problem after all - I think it's a missing build-dep or some other similar thing that was on the Debian maintainer's system when they built the package.  I filed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723644
[13:26] <cjwatson> infinity: If you can figure out https://launchpad.net/ubuntu/+source/mpich2/1.4.1-4.2ubuntu2/+build/5025697, that would be good.  I've tried it three times, and each time it's mysteriously SIGILLed somewhere in the middle of debhelper.
[13:26] <cjwatson> infinity: Which would make a lot more sense to me if it were, you know, doing anything odd there.
[13:30] <apw> cjwatson, there is a strong correlation between the explosions and collect2 in that log
[13:30] <apw> cjwatson, whre you see the command and a real looking error rather than "in your output was" messages
[13:34] <cjwatson> apw: Oh, you think it's dodgy output ordering?  Very odd for it to terminate at that particular point in debhelper though
[13:36] <apw> cjwatson, yeah that last one could be real, there are a lot of collec2 make failures as well with sigill and sigsegv as well before we get that far
[13:36] <cjwatson> I guess dh_installmime is the last thing in that particular cdbs make target
[13:36] <cjwatson> So it could be make failing and not debhelper, but that's still WTF.  Why isn't everything else failing to build then?
[13:37] <cjwatson> It's failed on three different builders
[13:37] <apw> yeah, most odd indeed
[13:37] <apw> did we get a new compiler by any chance recently
[13:38] <cjwatson> Other things are working fine
[13:39] <apw> makes no sense indeed
[13:40] <cjwatson> Indeed there's a test rebuild fairly happily chunking through
[13:42] <apw> i wonder if they are assertions failing, a c assert drops one of those doesn't it
[13:44] <cjwatson> apw: That usually raises SIGABRT
[13:44] <apw> bah not that then
[13:46]  * apw woudl like to know if the buildd in question is producing any dmesg noise to go with it
[13:46] <apw> alignement for instance
[14:26] <bdrung> chrisccoulson: why did you bump the epoch in thunderbird?
[14:27] <chrisccoulson> bdrung, because we already manually added one to the language pack binaries (carried over from when they came from a separate source), and it was either that or add extra hacks to manually add an epoch to the -dbgsym binary packages too
[14:28] <bdrung> okay
[14:38] <dobey> pitti, jibel: how do i see what triggered a certain autopkgtest run?
[14:47] <dobey> bah, i guess rdepends autopkgtets breaking doesn't block packages after all :(
[14:47] <Laney> which?
[14:50] <dobey> Laney: or maybe the previous "exit with non-zero when allow-stderr" bug was the issue. but new squid3 and new python-oauthlib broke a couple of the u1 packages autopkgtests :(
[15:05] <slangasek> dobey: which packages?
[15:05] <dobey> slangasek: ubuntu-sso-client and ubuntuone-control-panel
[15:08] <slangasek> ok.  python-ubuntu-sso-client certainly depends on python-oauthlib, which should be enough to make an ubuntu-sso-client adt failure block python-oauthlib migration.  However, the last update of python-oauthlib happened on Sep 3, and the ubuntu-sso-client build failures didn't start happening until Sep 10?
[15:08] <slangasek> so which package actually caused the regression?
[15:08] <dobey> slangasek: eh? it was synced to ubuntu on sept 9, and copied into the release pocket on the 10th
[15:09] <slangasek> dobey: ah - sorry, I was trying to go by the changelog, which of course only shows the Debian upload date
[15:09] <dobey> slangasek: but there was also a bug in adt-run that caused the tests to 'pass' even though they should have failed, which looks like it probably landed on the 10th, which is when the tests start failing
[15:10] <slangasek> ah
[15:10] <dobey> squid was updated on the 2nd, so it probably also slipped in due to the adt-run bug
[15:10] <slangasek> ok
[15:10] <dobey> :(
[15:10] <ochosi> slangasek: sorry bout that
[15:10] <Laney> yeah you got a passing run with the new oauthlib
[15:11] <ochosi> slangasek: so the thing is that there seems to be a cross-flavors issue with logout taking ~8secs (even on fast machines)
[15:11] <ochosi> slangasek: i noticed in xubuntu, then similar issues were reported/confirmed by ubuntu-gnome users, ubuntu users, lubuntu users
[15:11] <ochosi> slangasek: as there was a switch to logind (and in our case, xfce4-session was patched to support logind), i was wondering whether sessions need more work for logind
[15:13] <slangasek> ochosi: logind isn't meant to be in the critical path for session teardown.  When the hangs happen, what processes from the user session are still left running?
[15:13] <ochosi> slangasek: it's a bit hard to say for me, tbh i wasn't entirely able to debug it (and Laney mentioned that this hasn't been debugged yet in ubuntu either)
[15:14] <ochosi> slangasek: i checked xfce-session (as in ~/.cache/upstart/startxfce4) but there wasn't anything suspicious, i also checked lightdm's logs
[15:15] <slangasek> debbugged in Ubuntu?  Has it been reproduced in Ubuntu?
[15:16] <slangasek> ah, yes, you said
[15:16] <ochosi> well i haven't *personally* reproduced it in ubuntu
[15:16] <slangasek> are all of the affected flavors using upstart user sessions now?
[15:16] <ochosi> but it was confirmed to me
[15:16] <ochosi> i think so, but i can also say for xubuntu for sure
[15:22] <slangasek> ochosi: so my first guess would be that some user upstart job is not shutting down cleanly when asked, leading to timeouts with the session teardown; it could be related to logind, though I don't see any particular reason why
[15:22] <slangasek> debugging this probably involves either taking snapshots of the process state from outside the login session and seeing what's running when, or putting debug "echo"s in each of the upstart jobs
[15:24] <ochosi> hm, i'm not sure i'm technically fit to take care of that
[15:25] <ochosi> i mostly suggested logind, because i realized it was new and used by all flavors
[15:25] <ochosi> (so it was more an idea than an informed conjecture)
[15:28] <slangasek> ochosi: are there open bug reports about this?
[15:30] <ochosi> slangasek: not yet, i wasn't sure what to report it against...
[15:30] <slangasek> I'm not either ;)
[15:30] <slangasek> but better to have it in launchpad than not
[15:30] <ochosi> definitely
[15:31] <ochosi> if you have a suggestion i'm happy to write a bugreport
[15:31] <ochosi> it's also that i'm not sure what to report, as i haven't found anything relevant in the logs
[15:31] <ochosi> :s
[15:40] <ochosi> slangasek: so should i just report a generic bug..?
[15:40] <slangasek> ochosi: report it against upstart for now
[15:40] <ochosi> slangasek: ok, thanks, i'll paste the bug# as soon as i'm done
[15:40] <ochosi> or i can subscribe you to it
[15:48] <ochosi> slangasek: submitted the bug and subscribed, thanks so far!
[15:50] <happyaron> who's patch pilot right now?
[15:59] <rbasak> happyaron: there isn't one in right now. It's listed in the channel topic when there is.
[15:59] <rbasak> happyaron: but if you have a question, go ahead and ask it.
[16:00] <happyaron> rbasak: would like to find someone review/upload LP #1226492
[17:50] <shadeslayer> cjwatson: could you update the packageset?
[17:51] <shadeslayer> I put mplayerthumbs in the Kubuntu supported seed
[18:06] <alkisg> bdrung: hi, I'm using adblock-plus from https://launchpad.net/~mozillateam/+archive/xul-ext, but it needs updating now with thunderbird 24... thanks in any case!
[18:07] <alkisg> apt-get dist-upgrade ==>
[18:07] <alkisg> The following packages will be REMOVED:   xul-ext-adblock-plus
[18:07] <alkisg> The following packages will be upgraded:    thunderbird thunderbird-gnome-support thunderbird-locale-el thunderbird-locale-en
[18:07] <alkisg> (12.04)
[18:08] <brainwash> file a bug report against the affected package
[18:30] <dobey> xnox: ugh. the new python-paste you uploaded, is pretty well broken. its own unit tests don't even pass. and it breaks things that use it (like u1db)
[18:39] <dobey> xnox: who wrote this patch to convert it to python3?!
[18:43] <rbasak> dobey, xnox: ah, sounds like the same root cause as https://launchpadlibrarian.net/150553029/buildlog_ubuntu-saucy-i386.convoy_0.2.1%2Bbzr20-0ubuntu1_FAILEDTOBUILD.txt.gz
[18:44] <dobey> rbasak: indeed. https://bugs.launchpad.net/ubuntu/+source/paste/+bug/1227291
[18:44] <rbasak> StringType is not defined (a 2 to 3 thing) from inside /usr/lib/python2.7/dist-packages/paste/
[18:44] <rbasak> RIght
[18:44] <dobey> rbasak: looks like someone tried to make it work with py3 and failed horribly at it :(
[18:48] <dobey> rbasak: i don't know if it's a 2to3 thing exactly, but the new version of the paste package has a few patches which remove the import of that and several other FooType names, and doesn't quite resolve the usage of them properly
[18:49] <rbasak> dobey: I didn't mean 2to3 specifically, just a general issue when moving code between 2 and 3.
[18:51] <dobey> i'm not sure that's why it was there
[18:51] <dobey> if paste wasn't already supporting py3, then it was there for some other reason
[18:52] <rbasak> It might be an attempt to make code work under both 2 and 3 gone wrong.
[18:52] <dobey> rbasak: and anyway, fixing that one error by defining it in that file, onlyh results in other things breaking for another reason
[18:52] <rbasak> Yeah I don't think that's the root cause
[18:53] <dobey> rbasak: i don't think so. it's a pre-existing thing. the patches in the new package are an attempt to work under both 2 and 3 gone horribly wrong
[18:53] <bjsnider> in instances where apt has two different repositories providing the same package, how does it pick which one to use?
[18:54] <bjsnider> version string is exactly the same
[18:58] <rbasak> bjsnider: see the output of "apt-cache policy <package>".
[18:59] <rbasak> It scores them. If scores are the same, then it's non-deterministic I think.
[18:59] <dobey> whee, and the new squid moved junk around again
[18:59] <rbasak> You can alter the scores. Search for "apt pinning"
[18:59] <tarpman> bjsnider: apt_preferences(5) says it'll pick the one listed earliest in sources.list
[18:59] <bjsnider> rbasak, http://paste.ubuntu.com/6125062/
[19:00] <bjsnider> tarpman, oh my god you're kidding me
[19:00] <bjsnider> it's that trivial
[19:00] <bjsnider> it really is that g comes before l
[19:01] <rbasak> Ah. The APT preferences do not affect the choice of instance, only the choice of version.
[19:01] <bjsnider> rbasak, multiarch turned this into a problem
[19:01] <bjsnider> here's what this guy just described to me
[19:02] <bjsnider> he's got the amd64 version of that lib installed. came from the libreoffice ppa
[19:02] <bjsnider> he then adds the gnome3 ppa some time later. he asks for the multiarch lib
[19:02] <bjsnider> apt picks the gnome3 ppa version for trivial reasons
[19:02] <bjsnider> except the two changelogs are different
[19:03] <bjsnider> can't overwrite, now his system is broken, can;t do updates and -f install doesn't fix it
[19:03] <dobey> wtf can't people pick names that aren't used by other pieces of software, for things?
[19:04] <bjsnider> would have been avoided had pat realized it's safer to pick the libreoffice ppa version because the amd64 lib is already there
[19:04] <bjsnider> * apt
[19:04] <rbasak> PPAs are like that. If users want to use multiple PPAs, their maintainers need to be careful to not collide packages.
[19:05] <rbasak> Users can pin PPAs to a low priority to help with this to some extent, but that doesn't change their fundamental nature.
[19:06] <bjsnider> yeah but i think apt needs to be smarter than this
[19:06] <bjsnider> g comes before l is not good logic
[19:06] <rbasak> So pin your PPAs as you wish to have them.
[19:07] <tarpman> is there a reason why the gnome ppa copies the package instead of depending on the libreoffice one
[19:07] <dobey> tarpman: cross-ppa dependencies is a huge pain to get right
[19:07] <bjsnider> the two ppas have nothing to do with each other
[19:07] <dobey> much easier to simply copy or build your own
[19:07] <tarpman> dobey, ok
[19:08] <rbasak> bjsnider: yes they do. They share the package namespace on the user's system.
[19:08] <bjsnider> average users aren't going to know why these failures are happening or what to do about them
[19:08] <dobey> average?
[19:08] <rbasak> So PPA maintainers should get their work into a release or backports or whatever.
[19:08] <dobey> majority of people probably aren't using either PPA, let along both
[19:09] <dobey> and this problem is extremely rare in practice
[19:09] <rbasak> It's fine to use PPAs to override small things, but for entire sets of packages, it's dangerous for exactly this reason.
[19:09] <rbasak> I wouldn't recommend that an average user uses a PPA at all.
[19:10] <dobey> and the issue in apt really has nothing to do with PPAs or ubuntu, directly
[19:10] <rbasak> This is why we have releases.
[19:10] <rbasak> Packages in a single release are engineered to work together.
[19:11] <bjsnider> only use a ppa if you're na expert?
[19:11] <bjsnider> how about only use linux if you're an expert too
[19:12] <dobey> average users will by definition use a PPA if they install any "for purchase" apps from the software center, or use google hangouts
[19:12] <rbasak> If you use a PPA, you immediately lose security updates from the security tesam.
[19:12] <dobey> bjsnider: if you want to complain about apt's behavior, the place to do it is in a bug against apt upstream, not in inrc
[19:12] <dobey> err irc
[19:12] <rbasak> Only use a PPA if you trust the maintainer of the PPA to have engineered the PPA to work with all the other PPAs you have added.
[19:12] <rbasak> (at least for average users)
[19:13] <bjsnider> dobey, i just wanted expert opinion on the logic behind apt's decision-making in that case
[19:13] <dobey> bjsnider: well this channel isn't for the development of apt. it's more about the development of ubuntu (ie, building the packages that go in the archive)
[19:14] <rbasak> apt isn't smart enough to read the minds of PPA maintainers. It's designed to resolve things specified by package maintainers. If they haven't declared Conflicts, then it won't work. I don't see how it's a problem with apt.
[19:14] <dobey> bjsnider: #debian or an apt/dpkg-specific channel would be a better place to ask that
[19:14] <dobey> rbasak: it's a problem which apt deals with poorly
[19:15] <rbasak> dobey: I think it's more fundamental to how packages work.
[19:15] <dobey> rbasak: there are several things apt could do, which it doesn't, that would help. regardelss of the quality of the packages or repositories
[19:15] <bjsnider> dobey, agreed
[19:15] <bjsnider> g comes before l is not good enough
[19:15] <dobey> rbasak: as in other situations, apt could simply ask what to do (ie, pick which one you want)
[19:16] <rbasak> It is an error to show apt the same package and version from multiple sources that are not the same.
[19:16] <rbasak> Perhaps apt should detect the checksum difference and flag that.
[19:16] <rbasak> But whichever way, I don't think it can be expected to work.
[19:17] <dobey> it doesn't have to work. it just needs to be graceful
[19:17] <dobey> pretending to work and ending up with a broken system, is pretty bad
[19:18] <bjsnider> it's just a failure of imagination going back many years i'm sure. the original designers couldn't envision the circumstances that exist today
[19:19] <dobey> if we were still using the same version of apt that was shipped 10 years ago, i'd think we'd have far worse issues to deal with :)
[20:22] <genii> Hello. Since -frecord-gcc-switches seems not to be used, how to find what compile options were used to build ?
[20:26] <cjwatson> genii: simplest to look in the build log
[20:26] <cjwatson> genii: or anything unusual will normally be in debian/rules
[20:27] <cjwatson> genii: debian/rules is the entry point to the package's build system
[20:34] <genii> OK, thanks
[22:36] <cjwatson> shadeslayer: Done, I think, feel free to check
[22:36] <shadeslayer> checking
[22:39] <shadeslayer> cjwatson: well, Riddell already uploaded it, so I got a rejection message that it's already in the archive
[22:39] <shadeslayer> I suppose I'll have to wait till next time now ;)
[22:39] <cjwatson> what's your LP account name again?
[22:39] <shadeslayer> rohangarg
[22:40] <cjwatson> $ edit-acl -p rohangarg -S saucy -s mplayerthumbs check
[22:40] <cjwatson> Rohan Garg (rohangarg) can upload mplayerthumbs to Saucy/Release
[22:40] <shadeslayer> awesome
[22:40] <shadeslayer> thanks :)
[22:40] <cjwatson> (lp:ubuntu-archive-tools)
[22:43] <shadeslayer> neat, will remember that