=== _salem is now known as salem_ === salem_ is now known as _salem [04:27] Good morning === tgm4883_ is now known as tgm4883 === tkamppeter_ is now known as tkamppeter [07:08] good morning === smb` is now known as smb === sraue_ is now known as sraue [07:38] pitti, about gvfs, I found that a test has been requested for gvfs_1.17.2-0ubuntu3 when libgphoto2 2.4.14-2.1 has been synced [07:38] pitti, but no trace of a test when gvfs itself has been uploaded, i'll continue to investigate [07:40] jibel: well, don't waste too much time on it [07:41] jibel: I was just curious as this is pretty much exactly the kind of regression that we want to keep out [07:41] pitti, I suspect it is not limited to gvfs [07:42] jibel: infinity seemed to have a case yesterday where a new eglibc only triggered 19 rdepends, that also seemed a bit low [07:42] not sure whether this is related somehow [07:42] but if you say that a test had been requested on the libgphoto2 sync, then it's something else === doko_ is now known as doko [07:45] infinity: hm, what does that want to tell me? https://launchpadlibrarian.net/146278424/buildlog_ubuntu-saucy-amd64.sane-backends_1.0.23-0ubuntu3_FAILEDTOBUILD.txt.gz [07:45] infinity: some error in the PPA chroot's .sbuildrc? [07:45] Laney, any idea why gtk+3.0 is built sequentially? [07:48] dholbach, morning, we updated a new tarball at bug #1203958, would you please take a look? [07:48] bug 1203958 in UbuntuKylin "[needs-packaging] unity-china-photo-scope" [Critical,In progress] https://launchpad.net/bugs/1203958 [07:52] JackYu, taking a look === rickspencer3_ is now known as rickspencer3 [07:56] JackYu, I commented on the bug report === rickspencer3_ is now known as rickspencer3 [08:16] jibel: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-gvfs/ back to green \o/ [08:22] pitti: I wonder if unblock implies forcing the tests [08:23] gvfs was unblocked during the freeze [08:23] jibel: ^ [08:23] more a cjwatson question I'd guess [08:23] Laney: they indeed did coincide, perhaps that's it [08:23] but I thought unblocking would just mean "remove the block in the ~u-release branch", not actively pushing stuff [08:24] unblocks override blocks, so we tend to add them specifically [08:28] roaksoax, PING [08:29] Laney: oh, I misinterpreted that as "got unblocked after the freeze", sorry [08:29] ah [08:30] I mean the 'unblock' hint type - I wouldn't be surprised if that overrode test failures [08:30] p.s. good work on fixing that [08:30] Laney: very plausibly, yes [08:30] jibel: ^ so, don't waste time on investigating this (yet) === dholbach_ is now known as dholbach [08:54] dholbach, updated:). [08:54] tkamppeter: ah, it seems you are somewhat attached to flphoto? [08:55] tkamppeter: do you know if there is a patch anywhere to build it against libgphoto 2.5? I looked around (fedora, suse, etc.), but fedora never had it, suse dropped it, and upstream disappeared [08:56] tkamppeter: otherwise, would you be very sorry if we removed it? shotwell should by and large replace it [08:58] JackYu, uploading [08:58] dholbach, great, thanks a lot:) [08:58] anytime :) [09:00] pitti, jibel: looking at the python2.7 test failures on i386 ... [09:01] the test_curses test did fail to start early this week, however we had no python related changes. wasn't this the time when the new autopkgtest was enabled? [09:03] Laney: unblock doesn't force tests [09:06] doko: it's around the same time, yes, but that doesn't change how std{in,out,err} or the VMs look like; these were mostly fixes around error handling and wrong dependencies [09:07] pitti, no change in the redirection handling? [09:07] no [09:07] but why did it start failing? [09:08] doko: my first bet would be on https://launchpad.net/ubuntu/+source/ncurses/5.9+20130608-1ubuntu1 [09:09] that's quite a large change [09:09] doko: and presumably that python2.7 run was triggered due to the new ncurses, as it landed at that very time? [09:10] I guess it wasn't held back because someone marked python2.7's autopkgtest as 'known broken', as it had failed for a while [09:10] * pitti looks into the override branch [09:11] doko: hey, (not related) do you think that some part of boost needs to be rebuilt/there is a mismatch? I got https://launchpadlibrarian.net/146284943/buildlog_ubuntu-saucy-i386.mir_0.0.8%2B13.10.20130731.1-0ubuntu1_FAILEDTOBUILD.txt.gz during the day and still get it [09:11] sil2100: if you have time and finished the daily release activity, can you look about that (Mir related) please ^? [09:12] might be a victim of the same problem that allowed the new libgphoto2 sync to get in despite it breaking reverse dependencies [09:12] didrocks, ahh, the mpi split package ... but isn't mir in main? [09:12] doko: not yet, there is MIR for Mir, but not in main for now [09:12] didrocks: will do! [09:13] thanks sil2100 ;) [09:14] sil2100: if you find changes in the rdepends (as apparently doko did some), maybe the MIR for Mir needs to be updated as well === freeflyi1g is now known as freeflying [09:16] JackYu, hey, did you see my NEW review comments bug? [09:16] cjwatson: OK then, not sure why gvfs passed here - http://people.canonical.com/~ubuntu-archive/proposed-migration/log/2013-07-23/03:57:03.log [09:16] the timing matches up with ScottK's unblock, AFAICS [09:17] seb128, not yet. Where can I got it? [09:17] doko: so, what's up? how can you fix it? mind giving a little bit more info? ;) [09:17] JackYu, https://bugs.launchpad.net/bugs/1206613 [09:17] Ubuntu bug 1206613 in unity-china-video-scope (Ubuntu) "comments from NEW review" [Undecided,New] [09:18] JackYu, it would be nice if you subscribed to the packages you work on, so you get email for bugs filed on those [09:20] seb128, I see, thanks:). It seems that I overlooked the bug email... [09:21] JackYu, you're welcome, and no worry, I'm just pointing it, in case [09:23] seb128, got it, we will improve it in the next release:). [09:23] thanks [09:26] pitti, no problem to drop it, it was one of Mike Sweet's hobby projects. He did not do anything on it for years. The highlight of it was nice printing functionality, especially for more than 1 photo on a sheet and it was the only program which did automatic crop-to-fit to make a photo filling the whole page (or a given rectangle with an aspect ration not necessarily equal to the photo's). [09:27] tkamppeter: http://www.easysw.com/~mike/flphoto/ doesn't even exist any more, it just times out .. [09:27] pitti, perhaps we simply drop it. [09:27] tkamppeter: ok, thanks for confirming [09:28] pitti, easysw.com is history. Mike has no private servers any more. CUPS is coming from Apple now. Anything needed for CUPS but dropped by Apple is coming from me (OpenPrinting). [09:29] tkamppeter: ok, that explains why other distros dropped the package [09:31] pitti: resuming over here then [09:31] pitti: I only modify the source - and it's a new patch - I'll just check if it's fixed in 2.37 [09:31] pete-woods: I think it'd be better to update glibmm2.4 to 2.37.4 to match our glib version [09:31] pete-woods: if it's fixed there, of course [09:31] Laney: Hard to tell from this point, unfortunately :-( [09:32] Laney: But I did look over the unblock code and AFAICS it only does anything to blocks [09:32] pete-woods: if not, let's update anyway (as other API certainly changed) and apply your patch on top [09:32] pitti: that sounds reasonable to me! :) [09:33] Laney: That is, block is "set update_candidate to False unless we find a matching unblock", rather than unblock going through and setting update_candidate to True which might indeed do more than intended if that were the way it worked [09:34] pitti, but the autopkgtest did run before ncurses was in the archive [09:35] pitti: sane-backends> that's a known problem where Xen builders occasionally lose their mind and scribble over bits of the filesystem. It's pretty scary but we don't know what causes it ... For now the fix is generally to get ops to reset the slave [09:40] pitti: Which host was that on? [09:41] pitti: (Linking to builds is much friendlier than build logs) [09:41] pitti, looking at https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-python3.3/ARCH=amd64,label=adt/ I have a hard time to see why this is marked as failed. all tests succeed ... [09:43] pitti: from looking at the git repo now, it seems like I patched a generated file, so the patch works on the source tarball, but it's not going to apply upstream [09:44] lots of macro magic about _WRAP_CTOR [09:45] doko: I think you're being confused by Jenkins' terribly confusing UI [09:45] doko: Don't look at the log under "Last Successful Artifacts" [09:46] cjwatson: s/reset the slave/rebuild the slave/ [09:46] doko: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-python3.3/ARCH=amd64,label=adt/27/artifact/results/log is the last failure log [09:46] infinity: *nod* [09:46] cjwatson: Did anyone hunt down which guest it was and have it rebuilt? [09:46] 1 test failed: [09:46] test_curses [09:46] infinity: No, I tried but by the time I got to pitti's PPA he'd already retried it on another host [09:47] cjwatson, I did look at https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-python3.3/ARCH=amd64,label=adt/lastSuccessfulBuild/artifact/results/log [09:47] doko: The key in that URL is "lastSuccessfulBuild" :-) [09:47] doko: Like I say, Jenkins' UI tends to lead you to the wrong place [09:47] argh [09:47] doko: You need to follow the "Last build" link [09:47] i.e. https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-python3.3/ARCH=amd64,label=adt/lastBuild/ [09:47] got it [09:48] cjwatson: Looks like chindi05. *disables* [09:48] infinity: Ta [09:48] slangasek, how did you get samba uploaded? I get an error unpacking the unmodified source ... [09:50] JackYu, dholbach: unity-china-photo-scope accepted to saucy [09:50] yeehaw! [09:50] ;-) [09:52] seb128, wow, great! [09:56] infinity: I've encountered it on several, but I retried them; they worked the second time [09:56] pitti: Yeah, cause they hit a different host. I had to go hunt down the broken one. [09:56] doko: I think that's just time zone confusion [09:57] pete-woods: it's not fixed in 2.7.4? [09:57] infinity: the builder name isn't in the log anywhere? sorry then, I'll tell you the next time it happens [09:58] pitti: The builder name is in the log when sbuild starts. Which it couldn't because of this bug. :P [09:58] infinity: argh :) [09:58] pitti: Arguably, I should slap it at the top of the log too. Would be handy. [10:00] infinity: Totally [10:00] infinity: Do we have the build URL at that stage [10:00] ? [10:02] seb128: so https://launchpad.net/~pitti/+archive/ppa/+packages is complete (we'll remove flphoto), I tested upgrades, and that gphoto2, gphotofs, and shotwell still work fine [10:02] pitti, great, do you want to give it a try as well? [10:03] want *me* to* [10:03] seb128: si tu veux, bien sûr :) [10:03] cjwatson: I'm not sure that we ever do, that's not something the slave needs to know. [10:03] pitti, ok, je le fais [10:03] pitti: nope, same problem there - the problem is that the ctor methods are auto-generated, and don't delegate to the C-based ctor methods [10:03] pitti: so they miss out on the initialisation from there [10:03] infinity: Thought not [10:04] pitti: the same problem has been worked around in the class dbusmessage [10:04] pete-woods: ok; probably best to discuss that with Murray (upstream), he should be online and he knows better how this is (auto)generated === gusch_ is now known as gusch|lunch [10:05] seb128: FYI, I forgot to add a ~ppa suffix, so while the PPA has libgphoto2 - 2.5.2-0ubuntu1.1 I'll actually upload libgphoto2 - 2.5.2-0ubuntu1 [10:05] pitti, ok [10:06] seb128: dist-upgrade should remove libgphoto2-2 libgphoto2-port0 and install libgphoto2-6 libgphoto2-port10 [10:08] seb128: hm, upgrade worked fine in a schroot, but not on my desktop; investigating [10:09] pitti, http://paste.ubuntu.com/5932256/ for me [10:09] pitti, seems fine, out of the libsane-dev to be removed [10:09] seb128: hm, seems I missed the libsane-dev dep [10:09] well I don't need it but it seems buggy [10:10] hm, in my uploaded source it is correct [10:10] seb128: I wonder why it doesn't just upgrade it; might be the same problem that I'm seeing [10:11] seb128: probably the unversioned Breaks: is too strong and it confuses apt [10:11] could be [10:11] seb128: the libgphoto2 packaging is a mess, but I don't want to divert too far from Debian [10:12] pitti, also it removed libgphoto2-2-dev and didn't install libgphoto2-6-dev instead [10:12] is that wanted? [10:12] seb128: that's kind of expected; we could add a transitional package for -dev, not sure whether we should bother [10:14] seb128: ok, hold on for a bit, I'll try a new version [10:14] pitti: Does an unversioned Breaks even make sense? It's effectively a Conflict at that point. [10:14] infinity: yes, but I thought Breaks: were slightly friendlier to apt as it can remove the package after the broken one gets unpacked [10:15] pitti, oh, I upgraded to do runtime testing ... those -dev issues seem fine to me [10:15] infinity: but I'll drop the breaks and just keep the Replaces:, that ought to be enough (testing now) [10:16] pitti: Well, if the goal is to force the other package off the system, Replaces alone won't do it, it'll just overwrite some files. :P [10:16] it shouldn't actually break the old library, it just overwrites some READMEs [10:16] infinity: yes, that's the goal [10:16] doko: hi! I'd like to do a re-poke about the libboost-mpi issue we got during Mir building [10:16] pitti: But for overwrites, you *should* use Breaks/Replaces, to guarantee correct ordering, so files don't get lost. But, they should be versioned. [10:16] doko: could you give us some info about what could be wrong that it's not installable? [10:17] I installed gvfs, shotwell, and gphoto2 into a schroot and dist-upgraded to the PPA without a problem, but on my real desktop apt wants to hold back gphoto2 rather [10:17] pitti: Unless both packages will always ship those files, in which case, someone's doing something wrong. [10:17] doko: (along with libboost-mpi-python-dev and libboost-graph-parallel-dev) [10:17] infinity: so that means I'll keep the old names as transitional packages and keep them empty [10:18] I was hoping to avoid that, but *shrug* [10:18] sil2100: boost-mpi/boost just got uploaded/built, were you just running into arch skew? Which build? [10:20] infinity: hi! Ok, so I'm running amd64 and I'm encountering the same issue as in the logs - so, after doing update, apt-get install libboost-all-dev cannot install libboost-graph-parallel-dev libboost-mpi-dev and libboost-mpi-python-dev - we got the same here: [10:20] infinity: https://launchpadlibrarian.net/146284943/buildlog_ubuntu-saucy-i386.mir_0.0.8%2B13.10.20130731.1-0ubuntu1_FAILEDTOBUILD.txt.gz [10:20] infinity: so it's i386 [10:21] infinity: does it mean libboost-all-dev has invalid deps now? [10:21] Due to the switch? [10:22] What "switch"? [10:23] pitti: I have managed to make a patch that will apply upstream now - do you know what room / server I will find Murray in? [10:23] sil2100: If you retry that build, it should be fine. [10:24] sil2100: At least on i386/amd64. ppc and arm are still building the new boost. [10:24] pete-woods: he's "murrayc" in #gnome-hackers on irc.gnome.rog [10:24] pete-woods: .org [10:24] infinity: hm, it will? Since I just did update and apt-get install --simulate libboost-all-dev on my system and get the same error - but maybe my mirror is outdated? [10:24] sil2100: I just tried it here and it was fine. *shrug* [10:25] Well, I'm using the polish mirror, so I guess it could be this [10:25] Let me try a re-run [10:26] seb128: ok, got a clean upgrade now [10:27] pitti: thanks! [10:27] didrocks: ok, so anyway we'll have to wait for armhf mir at least until boost finished building there [10:28] infinity: I retried it this morning, but maybe too early? [10:29] sil2100: keep me posted ;) [10:29] didrocks: it's building now \o/ [10:29] seb128: tried again with gvfs (file-like browsing), gphoto2, and shotwell, WFM [10:29] didrocks: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4839926 [10:29] didrocks: so I'll re-try i386 as well [10:29] sil2100: sweetnesssssss! :) [10:30] pitti, works fine for me as well [10:30] seb128: gvfs' GPhoto test will need an update for the new ioctls, I'll do that [10:30] thanks [10:30] sil2100: The builds use the hidden master archive; everything, including archive.ubuntu.com, is potentially outdated relative to that :-) [10:30] seb128: ok, so ready for saucy? [10:31] pitti, seems so! UPLOAD ;-) [10:31] seb128: (-proposed) [10:31] it's transitions' week [10:31] (new poppler, new libgphoto, ...) [10:31] ;D [10:31] mmm transitions [10:34] doko: that's a behavior change in patch; the new version of samba in Debian unstable is fixed [10:36] slangasek, when you sync/merge it, could you update the config.* files too? [10:39] doko: I don't expect to have time to do that merge any time soon, fwiw - so maybe it's better to file a bug [10:39] sil2100: so, from the MIR for Mir standpoint, no additional package is needed? (if boost was splitted?) [10:40] slangasek, ahh, still in NEW [10:42] doko: hmm, what's in new? [10:42] slangasek, 4. but I see there is -2 in debian. will check it ... [10:43] right, I meant 3.6.16-2 only [10:53] didrocks: hm, doesn't look like it, I'm looking at the diffs but I don't even see any splitting going on [10:53] sil2100: ok, not sure what doko meant by "the mpi split package" [10:54] sil2100: didrocks: we only split the default boot version. Do you want to use a newer boost? [10:54] didrocks: no idea as well, but boost 1.53.0-4ubuntu1 was released long ago an ubuntu2 and ubuntu3 only added --disable-long-double --without-context [10:55] xnox: mir is using default boost and tries to install libboost-all-dev [10:55] (and the -dev deps on libboost-program-options-dev) [10:56] didrocks: libbost-all-dev is in universe, as that depends on mpi portion. Depend on individual libboost-foo-dev that your package actually needs. [10:56] I'm failing to see how any of those things are problems... [10:56] Except for the -all-dev, yes, which no one should build-dep on. [10:56] Interesting [10:56] infinity: do you think what the mir-team should deps on? [10:56] That's like a build-dep on "lib*-dev" because you don't know what you actually use. :P [10:56] didrocks: I think they should build-dep on what they link with. [10:57] didrocks: I guess that we need to consider talking to the mir team about that [10:57] sil2100: yeah, see my pings on #ubuntu-mir ;) [10:58] oh! [10:59] xnox: I suppose if you wanted to be nice to the lazy, you could provide a libboost-all-main-dev, but I tend to agree people should actually figure out what they need and only use that anyway. [11:00] infinity: that's obvious, I would just hope I wouldn't have to be the one again figuring that out for them and being taken in hostage because of that transition [11:00] infinity: meh, that would diverge from debian.... plus we may or may not move some boost portions to universe even if they are build from the main package, if nothing depends on them..... [11:00] so let's try to figure that out with them [11:01] didrocks: There is no transition here... boost has always been split like this. [11:01] didrocks: The transition is that they've moved from building in universe to main. :P [11:01] xnox: Fair point. === gusch|lunch is now known as gusch [11:05] infinity, let's introduce pattern dependencies for the mir team =) [11:10] doko: Depends: stripes\nSuggests: polkadots\nConflicts: plaid? [11:15] siretart: do you have plans for libav 9 in saucy? [11:17] sil2100: didrocks: doko: infinity: so mir will bring in boost chrono & regex, but both of those are build from the main src-package already, so it's just binary move. https://code.launchpad.net/~xnox/mir/boost-split/+merge/177804 [11:25] Laney: Yeah, we're going to start the transition Very Soon. [11:26] xnox: Sure, binary moves are no big deal, we deal with them all the time. [11:27] infinity: Neat. [11:28] xnox: MIRs only care about source packages, not binaries... as long as the source is in main, the binaries will be in main as long as something else in main needs them to be [11:28] slangasek: ok. [11:28] but mpi is obviously still a problem [11:30] slangasek: in progress being solved https://code.launchpad.net/~xnox/mir/boost-split/+merge/177804 [11:31] xnox: excellent :) === ashams_ is now known as ashams [12:13] anyone know a good example of a project using dbus-test-runner offhand? apt-cache rdepends is of no help, and I imagine build-rdepends isn't needed often enough to warrant the implementation [12:14] ev: did you try reverse-depends -b dbus-test-runner [12:15] dammit. Thanks jbicha. [12:18] ev: in whoopsie-preferences, is the "Send a report automatically for login problems" box still supposed to be insensitive? [12:19] jbicha: yes - we haven't implemented that yet. I thought we started hiding it though? [12:19] * ev digs [12:20] ev: when it was in a-l-m, I had to hide it "harder" https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/activity-log-manager/saucy/view/head:/debian/patches/01_really_hide_automatic_reports.patch [12:20] jbicha: it still is in a-l-m [12:22] whoopsie-preferences is a dbus service and library for communicating with said dbus service that controls /etc/default/whoopsie, /etc/apport/autoreport, and the whoopsie upstart job [12:29] slangasek: if and when you have time to review =) https://code.launchpad.net/~xnox/ubuntu/saucy/mountall/btrfs/+merge/177822 [12:34] pitti: hi again, so now that bug has been fixed upstream, I've backported the patch to the version we have in saucy [12:34] pete-woods: nice, that was fast [12:34] pitti: should I still submit a bug / patch for that off the current version we have? [12:34] pete-woods: I think it'd be better to update it to 2.37.4 and apply it on top of it [12:35] to match our glib [12:35] pete-woods: so no need for you to backport [12:35] pete-woods: (in terms of changing the code to apply to the older version) [12:35] pitti: I don't think that it'll be 2.37.4 - looking in the git tree that has already been tagged [12:35] pete-woods: we still need to add the patch to the package, of course [12:36] pete-woods: so a bug "please update" with a pointer to the patch (gnome git) is fine [12:36] pete-woods: unless you want to do the update yourself, of course [12:36] pitti, pete-woods: I can do the glibmm update today if you want ... what's the patch to include? [12:36] pitti: oh, that's cool - I thought we'd be waiting on "full" releases [12:36] seb128: I guess https://git.gnome.org/browse/glibmm/commit/?id=23823fdf3a54ed3851b8 [12:37] seb128: https://bugzilla.gnome.org/show_bug.cgi?id=705199 [12:37] Gnome bug 705199 in giomm "Cannot construct MenuItem - warning, no property named "label"" [Normal,Resolved: fixed] [12:37] pete-woods: depends on how urgent it is, but if you block on it we can cherry-pick the patch [12:37] slangasek, bug 1206897 [12:37] bug 1206897 in systemd (Ubuntu) "logind fails to work, falling back to ConsoleKit when /run/users already exists" [Undecided,New] https://launchpad.net/bugs/1206897 [12:38] pitti, pete-woods: if I do the update I can as well include the patch with it [12:38] pitti: well, the world won't end, but it is blocking me atm :) [12:39] pete-woods, pitti: I'm going to backport it, no worry [12:39] seb128: that would be awesome! :) [12:54] xnox: why should we special-case btrfs in mountall? Why should we not demand that the btrfs-tools provides the standard interfaces, like fsck.btrfs? [12:55] xnox: also, why is "major zero" a correct means of detecting "this is a filesystem we should skip checking"? [12:58] slangasek: because due to (a) intrisic features of btrfs, it does not need fsck on each mount (b) deficiencies of fsck.btrfs of not able to run on read-only mounts. [12:59] slangasek: i didn't find a definite explanation of what "major zero" mean and which fs have "major zero", but that's the check used now in chroot.sh (debian sysvinit) and there are references of similar used on fedora. [12:59] xnox: which is to say: btrfs devs are playing silly buggers with the standard fsck interfaces and people are letting them get away with it [13:00] slangasek: imho, ideally i'd want all btrfs filesystems specify fs_passno 0 in fstab. But nobody seems to be doing that at the moment. [13:01] right, but why wouldn't we fix *that* bug in Ubuntu? (installer + update handling) [13:01] slangasek: do we ever modify /etc/fstab post install? [13:01] sure [13:02] we did for migration to UUID-based mounting [13:02] cause, I still have ntrfs-3g patch to accept obsolete aliased option name for wubi, unless that's because we can't access/modify fstab.... [13:03] we certainly can modify fstab [13:03] it needs to be done carefully === _salem is now known as salem_ [13:06] seb128, pitti: have you guys noticed that this week, lid close events are not being handled correctly? It's a frequently-reported problem here at the sprint, that only just regressed [13:06] slangasek, was that the "upower hangs in libusbx code"? [13:06] or is that something different? [13:06] I see there was a upower update, but I can't make that line up with when I started seeing the bug [13:06] seb128: I don't know [13:06] is there a bug report about this? [13:07] slangasek, I synced the libusbx fix from aurel32 this morning, would be good to see if that's still happening with the update/an upower restart [13:07] upower doesn't seem to be hung for me [13:07] slangasek, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717988 [13:07] Debian bug 717988 in libusb-1.0-0 "libusb-1.0-0: upowerd deadlocks in libusb (maybe related to suspend/resume)" [Important,Fixed] [13:07] slangasek: My lid close was failing and then after an upgrade, stopped failing again. [13:07] slangasek: So, either it was fixed, or it's wildly intermittent and hard to reproduce. [13:08] slangasek, gdb to upowerd and "t a a bt"? [13:09] seb128: upgrading libusb-1.0-0 now to check [13:09] slangasek, you can easily reproduce? if you are in buggy state, having the bt before killing upowerd would be useful still [13:10] bah, why is update-manager broken again? [13:10] seb128: sure, trivial to reproduce; I'll pastebin the gdb bt [13:11] seb128: http://paste.ubuntu.com/5932741/ [13:11] slangasek, yep, locked in libusb code [13:11] why does apt-get dist-upgrade against saucy want to remove ubuntu-desktop? :P [13:11] did someone force something inappropriate through proposed-migration? [13:11] slangasek, don't use saucy-proposed? [13:11] I don't [13:11] hum [13:11] can you pastebin that as well? ;-) [13:12] http://paste.ubuntu.com/5932747/ [13:12] slangasek, your upower issue is almost for sure the one fixed by the new libusbx I synced earlier, let me know if the update works for you [13:13] yes, will do [13:13] slangasek, https://launchpad.net/ubuntu/+source/libgphoto2 [13:13] slangasek, apt-cache policy libgphoto2-2 ? [13:15] slangasek, or shotwell [13:15] slangasek, you are sure you don't use pitti's ppa or something? [13:16] slangasek, the new gphoto/gvfs/shotwell are still in proposed (and in pitti's ppa) [13:22] seb128: ive got a branch going to port sosreport over to python3 but it is still a ways away [13:24] seb128: so, upower was definitely hung; I had 0% battery life and didn't know it, so the laptop shut down in the middle of the upgrade ;P [13:24] libgphoto2-2: [13:24] libgphoto2-2: [13:24] Installed: 2.4.14-2.3ubuntu2 [13:24] Candidate: 2.4.14-2.3ubuntu2 [13:24] seb128: ^^ that's in saucy, not in a ppa or proposed [13:25] slangasek, which is your pastebin listing it as "to update"? [13:25] slangasek, you confirmed the dist-upgrade? [13:25] seb128: right, I apparently do have a ppa of pitti's enabled though [13:25] slangasek, having shotwell in that dist-upgrade doesn't make sense [13:26] seb128: I did an apt-get upgrade instead [13:26] shotwell was "to be removed" [13:26] slangasek, right, but shotwell-common to update [13:26] well, I don't know why I have pitti's ppa enabled /anyway/, so disabled now [13:26] slangasek, which doesn't make sense, https://launchpad.net/distros/ubuntu/+source/shotwell ... the current version is in saucy since july 12 [13:27] slangasek, pitti prepared the gphoto transition in his ppa, I'm pretty sure that's the issue you hit [13:27] * StevenK beats seb128 with the deprecated URL stick [13:27] slangasek, you probably had it from logind testing back then [13:28] StevenK, seems so, I never bothered changing my firefox alias it seems [13:29] seb128: I can't see us removing it because it's mostly cheap, but still ... :-) [13:30] StevenK, well, I didn't notice, I just do "lpurl " in my firefox and end up on the new url through the redirect [13:30] * xnox seems to be back online. [13:32] slangasek, seb128: re; was in meeting, reading scrollback [13:33] slangasek: upower is almost certainly bug 1203655 which is supposed to be fixed with latest usbx [13:33] bug 1203655 in libusbx (Ubuntu) "Hangs in pthread_join in libusb_exit" [High,Fix released] https://launchpad.net/bugs/1203655 [13:33] pitti, yeah, that was it, slangasek got a stacktrace [13:34] slangasek: yes, libgphoto in my PPA is slightly broken, the version I uploaded to -proposed fixes the Breaks: and the upgrade [13:34] seb128, slangasek: logind testing was a different PPA though [13:35] ok, maybe he had it for another reason [13:36] would anyone know why libgphoto2 doesn't appear on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt ? [13:36] it should still cause some uninstallability [13:36] seb128: or would it be possible to just have sosreport seeded on the cloud-image? [13:36] (some NBS packages) [13:36] pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libgphoto2 [13:36] seb128: post-reboot, pre-upgrade, the no-action-on-lid-close problem is not reproducible for me; but I'll restart upower and watch for the problem to resurface [13:36] Not considered -> not on _output yet [13:37] Laney: ah, it's first (build+tests) -> excuses, and then installability -> output? [13:37] Laney: (besides, the jenkins test finished over an hour ago0 [13:37] slangasek, great, let me know how it goes [13:37] Laney: I'm just anxious that it doesn't propagate now [13:37] something like that, yeah [13:38] Laney: thanks [13:38] stokachu, sorry, I skipped your first message in the backlog ... cloud-image: it's not my call, but as said I would prefer not other python2 users on the desktop image, since we are aiming at dropping python2 from the image [13:38] seb128: ok thats cool [13:39] pitti, "autopkgtest for gvfs 1.17.2-0ubuntu3: RUNNING (Jenkins: public, private) " ... you better check with cjwatson/jibel if there is an issue there [13:39] pitti, it might be that the test hit an issue and is stucked as RUNNING on that side [13:39] Not sure about the path results take from jenkins back to proposed-migration [13:39] wouldn't be the first time [13:39] seb128: the previous msg was i have a branch for python3 its just a ways away [13:39] it'll go to FAIL anyway, won't it? :-) [13:39] seb128: it's not stuck, I checked https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-gvfs/ and http://10.98.0.1:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-gvfs/ [13:40] but maybe it just didn't hit another britney run yet [13:40] does anyone know who manages the cloud-image seed? [13:40] anyway, for now it needs to stay in -proposed until I sort out the failing gvfs test [13:41] pitti, well, it seems that sometime the status doesn't go back to britney correctly, that's what I meant by "stucked" [13:41] pitti, e.g excuse keeps showing things are RUNNING when they are not [13:41] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine [13:41] stokachu, i'd guess smoser (not sure though) [13:42] ogra_: ok thanks ill try him and see [13:44] seb128: right [13:44] Riddell, ScottK: do you know if there are any architecture specific things in qt4-x11? and if yes, where? [13:46] slangasek: a hung upower sounds very familiar [13:47] slangasek: btrfs returns invalid major number (zero) since a single pair is not enough for btrfs, due to possible multiple drives/subvolumes. But yeah, sounds like a fragile interface. [13:47] I've been experiencing that quite a few times in the last weeks [13:47] mbiebl: yes, the libusbx one, already sorted out [13:47] pitti: ah, perfect [13:48] pitti: what was the problems (do you have a bug number?) [13:48] mbiebl: http://packages.qa.debian.org/libu/libusbx/news/20130730T171814Z.html [13:48] mbiebl, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717988 [13:48] Debian bug 717988 in libusb-1.0-0 "libusb-1.0-0: upowerd deadlocks in libusb (maybe related to suspend/resume)" [Important,Fixed] [13:48] mbiebl: bug 1203655 [13:48] bug 1203655 in libusbx (Ubuntu) "Hangs in pthread_join in libusb_exit" [High,Fix released] https://launchpad.net/bugs/1203655 [13:49] pitti, pete-woods: https://launchpad.net/ubuntu/+source/glibmm2.4/2.37.4-0ubuntu1 [13:49] pitti: thanks [13:59]