[00:09] * doko curses xnox for multiarching tcl/tk [00:17] xnox, any any reason for not doing tcl & tk at the same time? [00:25] doko: multi-arch? [00:25] * xnox was sponsoring a patch for tcl, and I accepted the work to make tcltk match for tcl m-a upload. [00:25] (defaults that is) [00:26] cjwatson now said he is ok to finish tk m-a for +1. [00:26] xnox, yes m-a [00:26] ok. will need another change for hfsutils [00:26] doko: hfsutils sounds like a package I should be maintaining =) [00:27] ? [00:27] file systems =)))) [00:27] although I don't have macs any more. [00:36] Trying to deploy an app to Ubuntu Touch on my Nexus 7. It's prompting for a password but not accepting the default "phablet" Anyone else run into this? [00:39] mathomastech2: see #ubuntu-touch people there should know. [00:39] xnox: Thanks, I am actually cross posting from there. Not having much luck yet. [00:39] xnox: I don't understand what "for the node itself" means here. Do you mean that the server mounts the filesystem the same way as the clients? [00:40] slangasek: maybe, my memory is fuzzy. [00:40] slangasek: I'll get back to you about that. [00:40] ok :) [00:41] mathomastech2: i'm sorry to hear that. Last resort try the ubuntu-phone mailing list. https://launchpad.net/~ubuntu-phone [00:41] slangasek: new guile-pg uploaded "closing" the guile-1.6 RM task. [00:45] xnox: cheers :) === bjsnider_ is now known as bjsnider [04:03] Who demoted tcl/tk8.4 to universe? [04:04] infinity: doko was working with that stuff earlier... [04:05] * StevenK grumbles at SourcePackagePublishingHistory:+publishinghistory [04:05] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [04:41] who promoted tck/tk8.4? demoting again ... [04:42] infinity: [15:41] < doko> who promoted tck/tk8.4? demoting again ... [04:43] doko: it registered on c-m [04:44] I assume I know who did promote it again. there is no reason to promote it for a work in progress, not even for infinity [04:44] doko: why not just fix what would pop up on c-m before demoting? [04:45] micahg, did *you* see this? [04:45] I saw it register on c-m... [04:46] ah, you fixed it, so that should be that then :) [04:46] so you did look up bug reports for tcl8.4, or tk8.4, or blt? [04:46] I didn't do the demotion/promotion [04:48] doko: honestly, I figured infinity would chat with you before playing override pong [04:51] * micahg enjoys removing old cruft as much as the next person [04:51] * micahg would love to rm vala-0.14 for raring... [05:02] doko: Typically, we remove the rdeps, then demote things when c-m whines, specifically to avoid pong. Having to trawl bug reports to figure this out doesn't scale. [05:02] doko: (I did look at blt, and there had been no uploads changing build-deps at the time) === freeflyi1g is now known as freeflying [06:28] Good morning [07:26] good morning === smb` is now known as smb [08:49] Laney: can you please remove the systemd and udev blocks? [09:08] hello [09:08] pitti: sure, if you're sure ;-) === davidcalle_ is now known as davidcalle [09:09] Laney: the initramfs-tools bug has been fixed, and otherwise the libudev1 transition is done [09:09] Laney: so with unblocking we merely get libudev1, logind etc. is still kept in universe [09:09] * Laney nods [09:09] (as with the current raring package) [09:10] ok, done [09:10] Laney: thanks; that should flush quite a bit from excuses [09:33] hmm, udev didn't go [09:33] Laney: "go"? [09:33] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt [09:34] oh, I was looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html and that says "udev valid candidate" [09:34] skipped: udev (1 <- 466) [09:34] got: 278+0: i-278 [09:35] * i386: bluedevil, blue... [09:35] I can't parse that, can you? [09:37] can't either [09:37] it thinks that those things are made uninstallable [09:38] it's a long list [09:38] perhaps it'll catch it in the next iteration when all the libudev1 stuff is i? [09:38] s/i/in/ [09:38] I guess the last try is more interesting === yofel_ is now known as yofel [09:39] there are a few trying: udev there [09:39] chromium might need force hinting due to the armhf ftbfs [09:40] the previous upload FTBFSed too, was that also manually pushed? [09:40] think so [09:40] yes, it was forced [09:49] pitti: parse> if you scroll way to the right you'll see that it thinks udev itself is uninstallable [09:49] pitti: the very long line is just an expression of the fact that udev has lots of reverse-deps [09:50] pitti: note that this means that it thinks (current raring) + (all binaries from udev in raring-proposed) results in uninstallable udev - so it's possible it needs manual hinting together with something else in -proposed [09:50] hm, udev just dropped the libudev0 dependency and binary [09:50] Which seems likely given that udev is installable in raring-proposed [09:51] yeah, I dist-upgraded to raring-proposed just fine, I have 175-0ubuntu21 installed [09:52] Bet you'll find that if you take raring and then try to upgrade to just udev/raring-proposed, it adds something else [09:52] A lot of the ones it's complaining about seem to come down to xorg-server AFAICT [09:52] libudev1, yes [09:52] for the initramfs-tools dependency [09:53] Laney: I don't think it's worth looking at anything else when udev itself is listed [09:53] (It might be worth making update_output sort the binaries from the source itself to the start) [09:53] I was trying to ascertain what to hint together [09:53] Hm, wait, it's not listed in the final entry for udev [09:53] right [09:53] that's the one I'm looking at [09:54] pyudev needs to be fixed [09:54] And yeah, in general anything with Depends: libudev0 needs to be fixed [09:55] proposed-migration normally computes installability based on all-NBS-removed [09:55] oh, hardcoded libudev0 dep, fixing [09:56] So, certainly worth trying 'hint udev/175-0ubuntu21 xorg-server/2:1.13.3-0ubuntu2' - if nothing else you'll get more useful output that way [09:56] well: skipped: xorg-server (1 <- 498) got: 96+0: i-96 * i386: xserver-xorg-core-udeb, xserver-xorg-input-evdev-udeb, xserver-xorg-video-fbdev-udeb [09:56] And you can see a reflection of that in update_excuses [09:56] pyudev uploaded [09:56] xserver-xorg-core-udeb/i386 unsatisfiable Depends: udev-gtk-udeb [09:58] right [09:58] Ah, you'll need xserver-xorg-input-evdev/1:2.7.3-0ubuntu2b1 xserver-xorg-video-ati/:7.1.0-0ubuntu1b1 xserver-xorg-video-intel/2:2.21.4-0ubuntu1b1 xserver-xorg-video-modesetting/0.6.0-0ubuntu1b1 xserver-xorg-video-nouveau/1:1.0.6-0ubuntu3b1 too [09:59] And more - anything that mentions "Depends: ... systemd' in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html [09:59] Which implies that this is blocked on chromium-browser/armhf [09:59] not sure about that - at least nouvaeu went in the last run [09:59] Ah, OK [10:00] Try it a bit at a time and wait for another cycle, I guess [10:00] I'll just try it with xorg-server [10:00] it will come down to chromium but as that's a force we should wait until we're certain [10:01] aye [10:02] I'm not sure about udev-gtk-udeb [10:02] our udev source package didn't build that, and I didn't drop it [10:03] systemd builds it now, but I disabled it [10:03] It's built by Debian [10:03] (because we keep the standalone udeb for now) [10:03] err, udeV [10:03] Either start building it, or remove the dependencies [10:03] I don't really mind which :) [10:03] I mean, how did that work before? [10:04] i. e. how did we get anything depending on udev-gtk-udeb into raring when that package didn't exist? [10:04] Let me look [10:04] The previous version of at least xserver-xorg-core-udeb doesn't depend on udev-gtk-udeb [10:05] It's a new dependency [10:05] oh, perhaps it was synced, and this was added independently from my libudev transition [10:07] hm, no [10:08] Well, it's 2:1.13.2-0ubuntu3 to 2:1.13.3-0ubuntu2 - I assume there was a packaging sync in there even if not a verbatim sync [10:09] yikes [10:09] why did alt+left/right just start switching me between ttys? [10:09] And yet xserver-xorg-input-evdev-udeb gained it with just a rebuild [10:09] pitti: I suspect udev's shlibs are wrong [10:10] Or rather systemd's [10:10] * cjwatson peers [10:10] ubuntu-archive@lillypilly:/srv/archive.ubuntu.com/ubuntu/pool/main/s/systemd$ dpkg -I libudev1_198-0ubuntu2_i386.deb shlibs [10:10] libudev 1 libudev1 [10:10] ^- smoking gun [10:10] udeb: libudev 1 udev-gtk-udeb [10:11] aah [10:12] dh_makeshlibs -plibudev1 --add-udeb=udev-gtk-udeb [10:12] * pitti drops [10:12] Can't drop that entirely [10:12] Still needs to have some --add-udeb value [10:13] Hm, is it intentional that systemd doesn't build any udebs at all? [10:13] libudev0-udeb ? [10:14] cjwatson: right now yes, I disabled all of them because we want to stay on the separate udev for now [10:14] Um, confused. Isn't libudev0 meant to go away? [10:14] yes, it is [10:14] I guess we need to build a libudev1-udeb [10:14] I guess I don't see how libudev0-udeb can be a legitimate udeb substitution for libudev1 :) [10:15] Sounds like it [10:15] cjwatson: so having libudev1 only implies that we cannot continue to use libudev0-udeb and udev-udeb built from the udev source? [10:15] I kept those for now [10:16] I had assumed keeping libudev0-udeb would be okay, and we could do that as a separate transition [10:16] I'm not sure about the new layout. In general life will be simpler if you have debs and udebs in sync [10:16] I think trying to avoid that is a false economy [10:16] libudev1-udeb sounds harmless [10:16] what I'd like to avoid is building udev-udeb from systemd [10:17] Well, you don't build udev from systemd right now, do you? [10:17] but just like the real udev, udev-udeb shouldn't depend on the library [10:17] That's what I mean by in-sync [10:17] And indeed it doesn't [10:17] So it's just a matter of getting the linkage sorted for stuff that requires libudev1 [10:17] so, so I'll build a libudev1-udeb from systemd, drop libudev0-udeb from udev, and adjust the shlibs [10:18] That sounds right to me [10:18] ok, thanks [10:18] sorry about the mess [10:19] that's ok, catching this is what these tools are meant to do [10:19] so this is a success :) [10:20] actually, udev-gtk-udeb is supposed to be libudev1-udeb AFAICS, /me asks mbiebl [10:30] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128 [10:38] cjwatson: systemd with libudev1-udeb installed; so I'll let that build and publish, then rebuild the X.org bits again to pick up the fixed shlibs [10:39] err, s/installed/uploaded/ [10:41] which would be xorg-server and xserver-xorg-input-evdev [10:43] COol [10:43] With sane capitalisation [10:48] I can handle the xorg rebuilds [10:48] meh, FTBFS due to enabled "make check" [10:48] tjaalton: ok thanks, I'll ping you when it's ready? [10:49] sure [10:49] I guess the chroots don't have an /etc/hostname or so [11:26] Laney: do you need to adjust your autohints for udev somehow? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt header looks a bit odd [11:26] Laney: (I don't quite know yet how this works, I'm just curious) [11:27] pitti: likely, since you uploaded it [11:27] but it may be that it can figure it out itself now [11:27] You'll need to bump the version [11:27] but udev and systemd don't appear at all any more [11:28] They won't, because they're out of sync at the excuses level [11:28] Nothing shows up in output (global consistency checks) until it passes the excuses stage (package-by-package checks) [11:28] So don't worry about it, it'll sort itself in time [11:28] ok, thanks [11:28] systemd already migrated a couple of versions back anyway, unless it's changed again in a way that needs more hinting. [11:29] it needs NEWing this time [11:29] Yeah, I'm doing that now [11:29] yeah, I'm waiting for the arm and ppc builds, and will prod an archive admin when they are ready [11:29] No harm NEWing in advance of that [11:31] (done) [11:32] shadeslayer: Hey, is there an upstream bump of ktp-contact-applet on the way to match the rest of your uploads? [11:33] shadeslayer: And ktp-presence-applet too. [11:34] shadeslayer: Without those two, the rest can't migrate. [11:36] cjwatson: I'm afraid upstream won't accept my fix for bug #1073062 . The maintainer says we should patch initramfs-tools instead but I disagree. Shall we keep the patch in Ubuntu? [11:36] bug 1073062 in kmod (Debian) "modprobe: Assertion `kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed" [Unknown,New] https://launchpad.net/bugs/1073062 [11:37] tseliot: Err, that has nothing to do with initramfs-tools. [11:37] tseliot: Which upstream maintainer? The Debian one, or upstream upstream? [11:37] * infinity goes to look at the Debian bug, hoping for context. [11:38] * cjwatson happily defers to infinity since he's looking [11:38] infinity: the Debian one [11:38] I thought he was upstream upstream... [11:39] Lucas is upstream, not Debian, yes. [11:39] Reading. [11:41] tseliot: He is right about one thing. Those aliases were only officially supported in modutils. So, a decade ago. [11:41] tseliot: I'm not sure if it was an accident or backward compat that they didn't break in m-i-t, but they weren't documented in m-i-t either. [11:43] tseliot: I don't see him saying we should patch initramfs-tools instead, unless that's in a private email? [11:44] infinity: true but I believe it shouldn't error out like that [11:44] infinity: yes, I don't know why that email didn't make it: "Then you should fix the initram update software. I suggest you to try the blacklist stuff instead of this off/null alias and if it doesn't work to tell me." [11:44] tseliot: Either way, breaking upgrades gratuitously seems like a bad idea, and initramfs-tools isn't the place for the fix. If upstream doesn't want the patch (and that's fine), we should carry it locally, make it also spit out a warning to stderr, and make sure we don't ship anything that creates aliases like that. [11:44] tseliot: And then, later, we can drop the patch (say, after 14.04). [11:44] infinity: ok, it sounds like a plan [11:45] tseliot: Also, he's missing the point that this isn't about using different config options, it's about smooth upgrades for people who have the old config options. [11:45] tseliot: You might want to point that out. [11:45] tseliot: Yes, blacklisting might be the right thing, but we can't magically change people's systems. [11:45] infinity: I will, even though I doubt it will change anything [11:45] tseliot: (And the reason blacklisting probably doesn't currently work with udev for us is that our udev doesn't use libkmod yet, his does) [11:46] At least, doesn't work the way he thinks it should. :P [11:46] Our udev just forks modprobe. [11:46] Probably without -b ... Though that would seem like a bug too. [11:46] If true. [11:47] (Are you sure blacklists don't work with our udev? They really should) [11:47] infinity: udev in raring uses libkmod but, apparently, the one in precise doesn't [11:47] /etc/blacklist.d/ very much does work in raring [11:47] I've just found out [11:47] tseliot: udev in raring doesn't use libkmod. [11:47] I wish it did, but it doesn't, yes [11:47] tseliot: Except via modprobe, of course. [11:48] tseliot: But that's not the codepath he was pointing out. [11:48] tseliot: And of course it doesn't in precise, we don't have kmod in precise. [11:48] infinity: I can see #include in src/udev/udev-builtin-kmod.c [11:48] tseliot: Yes, but we don't build that bit. [11:48] oh [11:48] tseliot: we still use the standalone old udev source [11:49] ldd /sbin/udevd is pretty conclusive. :P [11:49] ok [11:49] but does "alias module off" work in our udev? [11:49] but going back to blacklisting, that's supposed to always work, even with newer udevs [11:49] oh, I don't know that for sure [11:50] Anyhow, dumping core is a Bad Thing. I can see where upstream is coming from too, that supporting config options that haven't been documented as valid for over a decade is probably a complete waste of time. [11:50] tseliot: It's not up to udev for that to work, it just passes the mess to modprobe (in our case), so it'll fail the same as in initramfs-tools. [11:51] tseliot: Which is why the fix (for us) belongs in kmod. But I can see the argument for it not being upstreamable, and that's not world-ending. [11:51] infinity: agreed [11:51] tseliot: I will probably amend your patch to be verbose, so people get some fair warning that they should update their configs. [11:52] tseliot: And maybe it'll teach nvidia/fglrx people to Stop Doing That. [11:52] infinity: that's a leftover from precise (coming from bug #864149) [11:52] bug 864149 in nvidia-graphics-drivers-updates (Ubuntu Oneiric) "initrd doesn't set keyboard layout when nvidia drivers are installed (FRAMEBUFFER=n override)" [High,Fix released] https://launchpad.net/bugs/864149 [11:53] infinity: so I'll more than glad to stop doing that ;) [11:53] *I'll be [11:53] tseliot: Yeah, so those should be blacklists, not aliases. He's right. [11:54] tseliot: And, ideally, fixed in the next round of precise SRUs you do, so the problem eventually goes away. [11:54] tseliot: But we'll carry this patch until 14.04 to make sure upgrades don't go sideways. [11:54] (And I'll do the verbosity change today) [11:55] infinity: why Precise? Wouldn't it reopen bug #864149 ? [11:55] bug 864149 in nvidia-graphics-drivers-updates (Ubuntu Oneiric) "initrd doesn't set keyboard layout when nvidia drivers are installed (FRAMEBUFFER=n override)" [High,Fix released] https://launchpad.net/bugs/864149 [11:56] I'll change it in Raring for sure [11:56] tseliot: Erm, why would it reopen that bug? I didn't read the whole thing... [11:56] infinity: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/864149/comments/3 [11:56] Launchpad bug 864149 in nvidia-graphics-drivers-updates (Ubuntu Oneiric) "initrd doesn't set keyboard layout when nvidia drivers are installed (FRAMEBUFFER=n override)" [High,Fix released] [11:57] - set 'alias nouveau off' in the modprobe blacklist file, *not* 'blacklist nouveau'. (udev ignores module blacklisting by design!) [11:57] Hrm. [11:57] Now I see where you got that idea from. [11:57] yep [11:57] That seems like it shouldn't be true. But maybe it is. [11:58] I'm not willing to take that risk in Precise ;) [11:58] You could also do the install foo /bin/true thing. But this probably needs more investigation. [11:58] tseliot: Hold off on changing things in raring too, I think we'll need to dig deeper into ACTUAL behaviours, instead of relying on conjecture. [11:59] infinity: fine by me. Are you going to deal with it? (I don't see any problems with the change in raring) [12:00] Well, the change in raring may regress this too. (I mean, changing nvidia/fglrx, the kmod change is fine). [12:00] tseliot: I'll have to dig a big into how this all interacts, so I have decent warning text to throw to stderr to tell people how to fix their config files. [12:01] tseliot: And once I've sorted that a bit, I'll also have a good idea of what things should look like in both precise and raring (if the former should change at all) [12:02] infinity: ok, good, I'll leave it in your hands then. Thanks [12:03] * infinity shudders at the idea of turning on the nvidia GPU in his laptop again to test all of this. [12:03] Bye, bye battery life. :) [12:07] :) === MacSlow is now known as MacSlow|lunch === tvoss is now known as tvoss|lunch [12:37] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === _salem is now known as salem_ [13:09] tjaalton: libudev1-udeb is published now, so we can rebuild xorg-server and -evdev [13:10] tjaalton: do you have some actual changes, or want you or me to upload no-change rebuilds? [13:15] pitti: hmm, not really, rebuilds are fine.. [13:15] cjwatson: *blink* at 1061909 [13:15] odd, isn't it [13:15] cjwatson: Clearly a Chrome rendering bug, but. Uhm. Wha? [13:15] web team have been trying to reproduce it [13:16] cjwatson: I give 20-to-1 odds that if you move the "32-" to the middle of a line it goes away, but I don't have a machine I can reproduce on. [13:16] if removing line breaks really fixes it, I'll (a) cry (b) sort it out with the Python rewrite [13:16] since the reason the line breaks are there is that it makes the code neater in shell :) [13:16] Well, you could just move the variable expansion up a line, or whatver. [13:17] (Or whatever's generating that, I didn't look) [13:17] If it's just a block text, same story. [13:17] tjaalton: do you want to upload them (as you mentioned it earlier), or shall I do it now? [13:17] it's cat < Maybe I can install Chrome on a Windows VM and reproduce. [13:19] pitti: if you have them ready then go ahead .) [13:19] :) [13:20] cjwatson: Yup, reproduced on Windows. [13:21] cjwatson: Gut feeling would be that it's seeing the "^32-" as a multibyte char. [13:21] tjaalton: done [13:21] infinity: ... wow? [13:21] pitti: thanks [13:21] er, "how" [13:21] but "wow" works too [13:21] I mean, in what encoding is that possibly multibyte? [13:23] cjwatson: Effed if I know. But let me move the line break to test the theory. [13:25] cjwatson: http://lucifer.0c3.net/~adconrad/wtfchrome/ [13:25] cjwatson: Verified that 1.html renders wrong, 2.html renders fine. [13:26] cjwatson: Could have something to do with the files being \n-only and Chrome on Windows perhaps behaving crappily without \r\n? I dunno. That's pretty far-fetched, given all the UNIX-generated content on the interwebs. [13:26] cjwatson: Either way, not starting a line with 32- fixes it. === MacSlow|lunch is now known as MacSlow [13:46] infinity: those sources have been dropped, I might have missed something, so I'll have a look tonight [13:47] shadeslayer: If they've been dropped, we need to remove them. [13:47] shadeslayer: Which I can do for you. Is there a migration/upgrade path there? [13:48] infinity: ktp-desktop-applets now replaces those two packages [13:48] the upgrade path seems clean ( I tested it before uploading ) [13:50] shadeslayer: kde-telepathy-desktop-applets has a Breaks/Replaces for plasma-widget-telepathy-presence but not plasma-widget-telepathy-contac [13:51] t [13:51] shadeslayer: Also, is Breaks/Replaces really enough to remove the old package entirely? You're sure that test worked? :) [13:53] shadeslayer: Anyhow, once you've confirmed that both those sources can go away, let me know, and I'll remove them so the rest can migrate. [13:53] infinity: doesn't replace the contact widget because it doesn't overwrite files from that, and I always thought that autoremove will remove packages that nothing depended on ? === wedgwood_away is now known as wedgwood [13:54] shadeslayer: Oh, if there's no reason to forcefully remove it, sure, it'll just autoremove on its own iff it wasn't installed manually or a direct dep of a metapackage. [13:54] yeah, there's no reason to forcefully remove it :) [13:54] Kay. [13:55] I'll bounce them both out of the archive for you, then. [13:55] awesome thanks :) [13:57] shadeslayer: Before I hit , this look right?: http://paste.ubuntu.com/5616555/ [13:58] bryce, I have an xorg stack trace I'd like you to look at if you have some time. It's from a jenkins run [14:00] * infinity takes shadeslayer's silence as a "yes, and I've found better things to do already." [14:00] no wait [14:00] * shadeslayer is looking [14:00] ... [14:00] Too late. :P [14:00] hahaha [14:01] ALL GONE. [14:01] I'm a bit distracted since we have a Kubuntu meeting starting in 2 minutes [14:01] lol :) [14:01] okay :) [14:01] hey mterry [14:01] pitti, hi! [14:01] mterry: I bounced the systemd MIR back to you FYI, as I believe I addressed most of the concerns (except not having a py3 package; patches/help appreciated..) [14:02] jamespage: ok, just dput the new qemu (was waiting on debian-devel discussion). *should* fix your issues when it's built. phew [14:02] pitti, sure, that's not as urgent [14:02] hallyn, great - thanks for letting me know [14:02] infinity: thanks, looks good to me [14:02] i'll have to sru those for sure === kentb-out is now known as kentb === tvoss|lunch is now known as tvoss [14:19] infinity: All right, thanks. I'll sort it out in a bit [14:20] infinity: Can you try collapsing the whole paragraph onto one line and make sure that works too? [14:21] cjwatson: It should, but sure. [14:21] (Which should be obviously true, but the whole thing is non-obvious.) [14:22] cjwatson: All one line works too. [14:23] Good, thanks. [14:23] cjwatson: I'd be willing to bet that \r\n works too, but too lazy to bother checking. [14:23] (Cause that's a crap solution for us) [14:23] Though I'd look into it if I had the energy to file a Chrome bug upstream. [14:23] Does libudev0-udeb need to be NBS removed for britney to start considering udev? [14:24] No [14:24] No. [14:24] Damn my insistence on puctuation. [14:24] proposed-migration does its consideration on the assumption that any to-be-NBSed binaries don't exist [14:24] what does the excuses entry for udev mean then? [14:24] i.e. it assumes that the new suite looks like (old suite) - (all contents of old source package) + (all contents of new source package) [14:25] It means there a libudev0-udeb in proposed. [14:25] I'll remove it. [14:25] Oh, right. Yeah, maybe it does then :) [14:25] Forgot that it needs NBS removal to pass the excuses stage. [14:25] :-) [14:25] Fixed. [14:26] merci [14:26] NBS removal in -release isn't required, but it has a bit of a tizzy if there's NBS in -proposed. [14:28] Yeah. NBS removal in release pre-migration is kind of a bad idea in case the migration fails for a reason you haven't thought of, anyway. [14:29] * Laney nods [14:29] At least excuses is pretty clear about NBS in proposed === wedgwood is now known as wedgwood_away === wedgwood_away is now known as wedgwood [15:09] pitti: Looks like you missed xwiimote. I'll upload a rebuild there. [15:10] pitti: xwiimote might need an O_BLOCK change. [15:10] Laney: ^ [15:10] aww, infinity didn't review my fix for twisted last night. sad cupcakes :( [15:11] dobey: No, I had a bit of a crisis here. I'll look now. [15:11] infinity: Not familiar with the problem. You do it if you like. [15:11] infinity: oh ok. thanks :) [15:11] dobey: ... if I can find that browser window again. [15:12] Ah-ha. [15:14] heh [15:16] dobey: Looks plausibly correct. Uploaded. === salem_ is now known as _salem [15:17] thanks === greyback is now known as bzoltan-smells === bzoltan-smells is now known as greyback === Ursinha_ is now known as Ursinha === rsalveti_ is now known as rsalveti === _salem is now known as salem_ === Sweetsha1k is now known as Sweetshark [16:02] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogasawara [16:04] seb128: amd64 retracers dead again? [16:05] Laney, yes, for 2 days :-( [16:05] * seb128 removes lock [16:06]

504 Gateway Time-out

[16:07] hmm, I just came across a bug I filed on 2013-02-28 [16:07] which isn't retraced yet [16:10] Laney, is it tagged need--retrace ? [16:11] yes, and ~apport is subscribed [16:12] maybe we didn't get any run that managed to clear the backlog since [16:12] we keep restarting them but they hit launchpad timeouts regularly [16:12] Laney, what's the bug numbeR? [16:12] #1134468 [16:12] er, #1135568 [16:13] Laney, it's in the retracing pool [16:14] last run had a backlog of 350 bugs :-( [16:14] Laney, I will try to watch for timeouts and keep restarting until we clear the backlog [16:14] * seb128 shakes fist at launchpad [16:29] Laney: err, I did? that doesn't depend on libudev [16:29] Laney: not on amd64 at least [16:30] does here [16:30] Depends: libc6 (>= 2.14), libudev0 (>= 147) [16:30] (libxwiimote1) [16:30] Laney: ah; thank you! [16:30] not sure how it slipped through [16:31] np - I didn't upload it because of ∞'s comment [16:34] infinity: add a new highlight for ∞ [16:34] that was specifically intended not to highlight === salem_ is now known as _salem [16:36] pitti: Yeah, at a quick glance, it might need a similar-but-different NOBLOCK fix (in fact, their internal wrapper function already has a "bool blocking" argument, but then they call it with false...) [16:36] pitti: I'm trying to sort out if that's valid, or if they've misunderstood what they want and it accidentally worked before. [16:36] pitti: Not having a clue what any of it's meant to do, it's a bit of a crap shoot trying to follow the code and guess their intent. :P [16:37] pitti: And happy to hand it off to you, since it's your transition. I got distracted by chromium on ARM anyway. And Jono's G+... [16:37]