[00:00] <kees> infinity: why are there hosts on the internet with unresolvable names?
[00:01]  * slangasek looks at kees blankly
[00:01]  * sarnold hands kees a soapbox
[00:01]  * sarnold grabs some popcorn
[00:01] <kees> slangasek: I'm following this eglibc bug, and I'm just trying to understand the parameters of the problem.
[00:01] <slangasek> hah
[00:02] <kees> it sounds like there are "legit" hosts that have a leading (or trailing) "-" character in their name. glibc (correctly?) follows RFC and refuses to look those up.
[00:02] <slangasek> so "unresolvable names" meaning "my hostname does not map to an IP"?
[00:02] <slangasek> fun
[00:03] <kees> like "cdn-9-.amazon.com" or something, let me find the bug. I've been reading comments out of order and in email.
[00:04] <kees> 144431
[00:05] <kees> example was "-kol.deviantart.com"
[00:05] <kees> bind has no problem with it.
[00:05] <kees> I'd learn towards supporting this, if bind supports it.
[00:10] <slangasek> kees: there are different RFCs for "this is a legal DNS name" vs. "this is a legal hostname".
[00:11] <slangasek> indeed, all SRV records are built around this fact
[00:11] <kees> slangasek: I haven't looked into that yet. I just got as far as making the simple observation that my bind server was involved in a successful query of this seemingly "illegal" name with no problem.
[00:11] <kees> (which is certainly UNtrue for hosts that have "_"s in their name, bind refuses to resolve those)
[00:12] <slangasek> ah, does it?
[00:12] <slangasek> I wonder why bind is picking and choosing :P
[00:12] <kees> that's my memory -- I haven't retested that recently, though.
[00:13] <kees> I'm mostly looking at it from a practical point of view: there are actual hosts doing this, and bind supports it, so why "filter" these results.
[00:13] <kees> I haven't checked other OS resolvers, though.
[00:14] <slangasek> so you think we should ignore the RFC?
[00:16] <kees> possibly, yes. If glibc is the only thing ignoring this aspect of the RFC, it doesn't seem sensible to retain that interpretation. it puts Ubuntu at a disadvantage for no good reason.
[00:16] <slangasek> s/ignoring/respecting/, you mean?
[00:20] <kees> yeah
[00:37] <Gsport> www.google.pt/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CD8QFjAB&url=http%3A%2F%2Fwww.computerworld.com%2F&ei=2NEnUvXwOoiRhQeSj4GoCw&usg=AFQjCNGWIgkWtnvRRqA8PHdgccurO6diMA&bvm=bv.51773540,d.ZG4
[00:37] <Gsport> apply
[02:33] <infinity> kees: Are you trolling me?
[02:54] <kees> infinity: no, I'm serious. I'm trying to evaluate this from a practical perspective.
[02:55] <kees> infinity: if the majority of internet infrastructure DNS accepts a non-RFC name, and only glibc-based OSes can't resolve it, it seems silly to wave the RFC as the reason.
[02:56] <kees> we've had plenty of things like this in the past (congestion control!), so it seems the same, except that a leading/trailing "-" is extremely rare.
[02:56] <kees> but BIND seems to have no problem with it. I haven't tested OSX or Windows, but it might be worth doing.
[03:27] <infinity> kees: The claim in the bug is that OS/X and Windows resolve it (which would make sense, or I couldn't see deviantart's admins not noticing).  Maybe I'm just being pedantic, but the argument that "if there's a host with that name on the internets, you must resolve it" is complete BS.
[03:28] <infinity> kees: Cause I can make BIND give you an A record for a whole lot of very-non-RFC-compliant names.
[03:32] <infinity> kees: Still, deviantart and tumblr are run by nerds, just like us.  The correct solution seems to be to ask them to be RFC-compliant, not to say "well, they screwed up, so we'd better toss the standard out the window".
[03:33] <infinity> kees: I can see the argument for "sure, we'll let this specific case slide", but what happens when it's another, and another?  Maybe the Windows resolver doesn't filter particularly sanely at all, and lets you try to resolve any old string (probably not, but maybe?), which would let people keep slippery sloping this mistake into madness.
[03:43] <pitti> Good morning
[05:04] <chiluk> infinity slangasek you still up/around ?
[05:05] <chiluk> got a bunch of e-mails about the apt upload "  We were unable to import the file because of errors in its format:
[05:05] <chiluk> No header found in this pofile"  any thoughts ?
[05:06] <chiluk> it looks like it built fine though.
[05:27] <infinity> chiluk: Don't worry about it.
[05:27] <chiluk> that's what I was leaning towards.
[05:27] <infinity> chiluk: Known bug.  Not your problem.
[05:28] <chiluk> infinity thanks, I was really getting tired of that bug.
[06:50] <dholbach> good morning
[10:00] <dpm> cjwatson, dholbach, I'm not sure if I'm supposed to be able to do that, but I was trying to unpack a click package to modify a file and repackage it again. Here's what I got: http://pastebin.ubuntu.com/6065919/ - is this a bug in click build, or should I do it differently/not at all?
[10:01] <cjwatson> dpm: can you give me a URL for that package so that I can investigate?
[10:01] <cjwatson> dpm: oh actually never mind
[10:01] <cjwatson> dpm: you shouldn't do it like that :-)
[10:01] <dpm> thought so :)
[10:01] <cjwatson> dpm: because click build moves manifest.json off to a different place when it builds, but it needs manifest.json
[10:02] <dpm> aha
[10:02] <cjwatson> dpm: you could probably do it with "dpkg-deb -R com.ubuntu.developer.davidplanella.qreator_0.1_all.click qreator-click && mv qreator-click/DEBIAN/manifest qreator-click/manifest.json && rm -rf qreator-click/DEBIAN && click build qreator-click" or something like that, but that might have other oddities and I don't recommend this workflow
[10:04] <dpm> cjwatson, so I guess that means I shouldn't unpack and repackage click packages and I should simply do 'click build' on the original source tree?
[10:05] <cjwatson> dpm: yes
[10:05] <dpm> ok, thanks
[10:35] <Laney> ev: I got a work item to ask you about your plans for finishing the Diagnostics panel in system-settings
[10:35] <Laney> well, that one was easy
[10:36] <ev> Laney: lol, hi
[10:37] <Laney> hello :P
[10:37] <ev> finishing how? It should largely be operation, save viewing existing reports which doesn't seem to flip over to the browser
[10:37] <Laney> ev: https://wiki.ubuntu.com/ErrorTracker#Client_design the extra things on the design there
[10:38] <Laney> Unless they are all not in scope
[10:39] <ev> Laney: we're not yet monitoring system information (metrics) or the location of wifi access points
[10:39] <ev> not sure who would be responsible for the latter one
[10:39] <Laney> yeah I thought that one might be a bit speculative
[10:40] <Laney> fair enough
[10:42] <xnox> Laney: any idea why system-settings is using qmake and not cmake? have you seen a cmake based qml extensions?
[10:43] <Laney> It is because it was
[10:43] <Laney> and I don't know what the second question means
[10:43] <xnox> (which actually use cmake to build, not merely providing cmake module for others to use cmake to find/link against the extension)
[10:43] <Laney> oh I see, hmm, no
[10:43] <Laney> but I haven't really looked at build systems for random qml things
[10:43] <xnox> ok.
[10:44] <Laney> try asking Mirv
[10:44] <Laney> and for a less-facetious answer - mardy wrote the initial implementation and that used qmake
[10:44] <Laney> we just carried that on
[10:44] <xnox> sure.
[10:45] <Laney> I think we wouldn't mind if it were ported, but nobody is going to prioritise that right now
[10:46] <Laney> if a conversion turned up and was feature-equal then we'd take that
[10:47] <xnox> Laney: right, there are some notices that cmake is the standard for our projects.
[10:48] <Laney> so I heard
[10:48]  * Laney whispers (autotools)
[10:49] <ev> ugh, autotools
[10:49] <Laney> hahaha
[10:49] <Laney> never fails
[10:49] <ev> :D
[12:35] <darkxst> ev, what happened with bug 1219188?
[12:35] <darkxst> we really need atleast the gnome-shell patch in asap, no the blocks are lifted ;(
[12:36] <ev> darkxst: apologies - I ran out of time during my patch pilot session. It'll need to be picked up by whomever is next at bat. I'd volunteer my time but the rest of the week has me completely committed to other work.
[12:39] <darkxst> ev, ok. but really the settings changes were supposed to come last ;(
[12:40] <ev> ah right, the bug made no mention of that
[13:01] <xnox> @pilot in
[13:22] <ChrisTownsend> xnox: ping
[13:23] <xnox> ChrisTownsend: hola! =)
[13:23] <ChrisTownsend> xnox: Hi, I was wondering if you had time during your pilot session to (re)review https://code.launchpad.net/~townsend/ubuntu/saucy/nautilus-share/fix-lp1214534/+merge/181160?
[13:50] <sconklin> @pilot in
[13:51]  * dholbach hugs sconklin and xnox
[14:08] <ChickenCutlass> pitti, are you around?
[14:08] <ogra_> pitti, are there any known issues with the hwdb stuff of systemd ?
[14:08] <ogra_> ChickenCutlass  has a werid socket error in his syslog and some device issues
[14:09] <pitti> ChickenCutlass: hello
[14:09] <pitti> ogra_: no, not to me
[14:09] <ChickenCutlass> pitti, I just upgraded my system and can no longer use adb
[14:09] <ChickenCutlass> pitti, I get this error in dmesg
[14:09] <pitti> ogra_: well, except for some keymap regressions, I have a fix for that queued, but not uploaded yet (freeze)
[14:09] <ChickenCutlass> pitti, [   19.202700] systemd-udevd[3565]: failed to execute '/lib/udev/socket:@/org/freedesktop/hal/udev_event' 'socket:@/org/freedesktop/hal/udev_event': No such file or directory
[14:10] <pitti> ChickenCutlass: apt-get purge hal :)
[14:10] <ChickenCutlass> pitti, ok
[14:10] <pitti> it should have died years ago, too bad we still have it in the archive
[14:10] <ogra_> why do we btw ?
[14:10] <pitti> (together with the remaining handful of rdepends)
[14:10] <ogra_> i thought you ripped all deps out in raring
[14:11] <ChickenCutlass> pitti, I assume I need to reboot
[14:11] <pitti> ChickenCutlass: no, not really; also, that error is quite harmless
[14:11] <ChickenCutlass> pitti, hmm ok I thought it might be related to not being able to use adb
[14:11] <pitti> ogra_: I killed all main rdeps in oneiric or so, and every release drops a few more universe through Debian
[14:11] <ChickenCutlass> pitti, it was just working then upgraded -- now not
[14:12] <pitti> ChickenCutlass: hm, works fine here; what does it complain about?
[14:12] <ogra_> ChickenCutlass, that might just be a bug in the udev rules
[14:12] <pitti> ChickenCutlass: did you reboot after dist-upgrade?
[14:12] <ChickenCutlass> pitti, device not found
[14:12] <ogra_> we need to revisit them one day
[14:12] <pitti> the rule works fine here, I get a proper ACL
[14:12] <ogra_> ChickenCutlass, adb kill-server && sudo adb start-server
[14:12] <ogra_> then try again
[14:12] <ChickenCutlass> ogra_, tried all that
[14:12] <pitti> I don't need sudo here (but it's good for debugging anyway)
[14:12] <pitti> ChickenCutlass: did you reboot after dist-upgrade?
[14:12] <ogra_> oh, and it didnt work ?
[14:13] <ChickenCutlass> pitti, yes
[14:13] <ChickenCutlass> ogra_, let me try a new USB cabel
[14:13] <pitti> ChickenCutlass: do you see the device in lsusb?
[14:13] <ogra_> yeah, if that dosnt work, blame the kernel
[14:13] <pitti> ChickenCutlass: and does the device think it's connected?
[14:14] <ChickenCutlass> pitti, ogra_ lol -- was the cable
[14:14] <ChickenCutlass> sorry
[14:14] <ogra_> heh
[14:14] <ogra_> good
[14:14] <pitti> ChickenCutlass: ah, sad for the broken cable
[14:14] <ogra_> saves us an upload
[14:14]  * ChickenCutlass throws out this cable
[14:14] <pitti> ChickenCutlass: it did have a positive side, you got rid of a zombie daemon on your system :)
[14:14] <ChickenCutlass> lol
[14:15] <pitti> ogra_: oh, and another reason was that when I annouced the intent to kill hal here like half a year ago, two people shouted "noo!"
[14:15] <pitti> because allegedly you'll need it for watching DRMed videos on youtube, or something such
[14:15] <pitti> that sounds very weird to me, and I really doubt that it even works, but I didn't hear an update for that
[14:15] <pitti> mdeslaur: ^ was that you?
[14:15] <ogra_> pitti, pfft, then i could have kept usb-imagewriter in the archive ... evil people, you shouldnt listen to them
[14:16] <pitti> ogra_: well, hald is definitively broken in saucy, so that's fine :)
[14:16] <ogra_> haha
[14:17] <mdeslaur> pitti: adobe flash uses hal to extract device serial numbers to play drmed content, such as amazon videos
[14:17] <mdeslaur> pitti: yes, that would have been me
[14:17] <pitti> mdeslaur: ah, ok; well, that would not work any more now anyway
[14:17] <mdeslaur> pitti: I believe chrisccoulson knows the exact details
[14:18] <pitti> mdeslaur: that probably wants a simple shim which just provides that D-BUS API, but not everything else?
[14:18] <chrisccoulson> pitti, mdeslaur, yeah, i wrote one ages ago
[14:18] <chrisccoulson> but i never really did anything with it
[14:18] <chrisccoulson> and priorities changed :)(
[14:19] <pitti> strings /usr/lib/flashplugin-installer/libflashplayer.so | grep hal
[14:19] <pitti> → nothing of interest here
[14:19] <pitti> and no hits for "Hal"
[14:19] <mdeslaur> pitti: did you xor it with "adobeencryption"? /joke
[14:19] <pitti> and it's not linked to libhal1 either
[14:19] <chrisccoulson> pitti, yeah, it downloads the drm module at runtime :)
[14:20] <chrisccoulson> i've already got a shim that works for it
[14:20] <pitti> mdeslaur: rot26 is a lot safer!
[14:20] <chrisccoulson> i'll dig it off my old laptop
[14:21] <mdeslaur> chrisccoulson: https://code.launchpad.net/~chrisccoulson/+junk/flash-hal-helper
[14:21] <chrisccoulson> mdeslaur, oh, yeah, that looks like it
[14:21] <chrisccoulson> not sure if it's up-to-date though
[14:22] <pitti> hal rdepends: wmbattery, moovida-plugins-good, dell-recovery
[14:22] <pitti> that's not too bad
[14:22] <pitti> I love edubuntu-live, which has a Conflicts: hal :)
[14:22] <mdeslaur> lol
[14:22] <pitti> libhal1 rdeps: xmbc-bin, libthunar-vfs-1-2 (ought to be obsolete), libsynce0 (unmaintained), librapi2, libhd16
[14:23] <pitti> seems only "squeeze" still uses the old thunar bits, and it's not seeded for xubuntu, so it can probably go, too
[14:23] <pitti> who does xubuntu these days?
[14:24] <smartboyhw> pitti, I think the Xubuntu people is going to be unhappy with that:P
[14:24] <pitti> why?
[14:24] <smartboyhw> (I mean, the "who does Xubuntu these days?")
[14:25] <smartboyhw> pitti, because Xubuntu is increasingly popular:P
[14:25] <pitti> smartboyhw: sorry, does that sound rude? certainly unintended
[14:25] <pitti> smartboyhw: yes, I know (I have worked on it myself for half a year)
[14:25] <smartboyhw> pitti, just weird:P
[14:25] <pitti> smartboyhw: but I'm interested in talking to the Xubuntu devs before I kill anything
[14:25] <Laney> he was asking who the main developers were
[14:25] <smartboyhw> pitti, ah
[14:25] <smartboyhw> micahg, ochosi, jjfrv8
[14:26] <smartboyhw> knome
[14:26] <cjwatson> smartboyhw: "who uses Xubuntu these days?" might have justified that response, but not what pitti actually said
[14:26] <smartboyhw> cjwatson, I would thought it should have been "Who's working on Xubuntu these days?"
[14:26] <smartboyhw> Does can mean a lot:p
[14:26] <Laney> assume good faith :-)
[14:26] <cjwatson> "does" would not mean "uses" in my book
[14:26] <cjwatson> too active
[14:27] <smartboyhw> cjwatson, rather, it is wrongly used here that shouldn't even appear in any book:P
[14:27] <pitti> anyway, I indeed meant "develops" here
[14:27] <cjwatson> from this native English speaker, it isn't wrong
[14:27] <smartboyhw> pitti, most of the Xubuntu developers are not here
[14:27] <smartboyhw> So, better if you go back into #xubuntu-devel
[14:28] <pitti> smartboyhw: ack, thanks
[14:30]  * pitti files bug 1221254 to track
[14:34]  * pitti goes to un-hal-ify some bits, like libsynce
[14:47] <asac> plars: seems the .1 test run nears its end
[14:47] <asac> ogra_: did we do manual smoke on .1 yet for mako/maguro?
[14:47] <asac> popey: have you tried .1? we want to push that most likely
[14:47] <ogra_> not me
[14:47] <asac> kk
[14:47] <ogra_> probably also -> touch
[14:48] <asac> ogra_: so unless we have a patch for security
[14:48] <asac> nevermind
[14:48] <ogra_> well, we have a patch, it was supposed to work
[14:49] <plars> asac: on touch_ro, they still have a ways to go
[14:51] <Laney> xnox: hah, we just got a branch to convert it to cmake
[14:58] <xnox> Laney: speak of the devil, excellent! Then I can steal that for my little experiment !
[14:58] <Laney> it's not complete yet
[15:10] <ockham> could someone do an SRU for this?
[15:10] <ockham> https://bugs.launchpad.net/ubuntu/+source/popularity-contest/+bug/858697
[15:10] <ockham> has been fixed in debian and newer ubuntus already, but not in precise
[16:02] <smoser> curious. what is the date string at
[16:02] <smoser> http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-i386/
[16:02] <smoser> i'm guessing thats installer version or something ?
[16:07] <stgraber> smoser: debian-installer source package version number
[16:10] <smoser> stgraber, thanks.
[16:21] <kirkland> I'm on Ubuntu 13.10, I installed python-daemon, but its libraries aren't available to me in python3 ... is this a packaging bug, or a bug or feature request in the library itself?
[16:21] <cjwatson> python-foo => Python 2
[16:21] <cjwatson> python3-foo => Python 3
[16:22] <cjwatson> If the upstream code supports Python 3 at all, it's a packaging bug for not building a python3-daemon package; if not, it's an upstream bug/feature-req
[16:22] <kirkland> cjwatson: and if python3-daemon doesn't exist in the archive, does python-daemon's source need to be updated to build that binary package too, or does it need to be created new, from scratch?
[16:22] <kirkland> cjwatson: I see
[16:22] <cjwatson> Depends
[16:23] <cjwatson> Most upstreams go for supporting both out of the same code base, either directly via bilingual code, or by way of 2to3
[16:23] <cjwatson> A few upstreams release separate source packages for Python 3
[16:23] <cjwatson> There isn't a single answer that suits everyone
[16:24] <cjwatson> (My own preference is bilingual code)
[16:36] <xnox> yeap, and bilingual code is relatively easy to write for python. 2.7 & 3.x is easy, but it's even possible to do 2.3 => 3.3 compatible code.
[16:37] <cjwatson> 2.3 sounds like an exercise in pain
[16:38] <xnox> cjwatson: i did that for apparmor I think, was fun =)
[16:38] <cjwatson> (also an exercise in futility, given how few users it must have these days)
[16:40] <xnox> it would be sad to regress support in apparmor though, just to gain 3.x which at the time probably had less usage than 2.4
[16:42] <cjwatson> for 2.3 the thing I remember is that we made 2.4 the default in Ubuntu 5.04
[16:44] <xnox> oh =) yeah old.
[16:45] <xnox> way before my time.
[17:35] <slangasek> awe: did you get an answer to your concern about packaging changes needed for ofono to report to whoopsie?
[17:36] <awe> no
[17:36] <slangasek> awe: I think that previously we weren't getting reports because ofonod on Touch was coming from a ppa; but now that that's resolved I'm not aware of any packaging issues that are outstanding
[17:36] <slangasek> ev: ^^ ?
[17:36] <slangasek> awe: however, we're not actually getting useful errors.u.c data from Touch because we're still blocked at the moment on getting armhf cross-retracers wired up
[17:37] <ev> we should still get reports regardless of whether or not a package comes from a PPA
[17:37] <ev> (armhf cross-retracers for errors.ubuntu.com: https://rt.admin.canonical.com//Ticket/Display.html?id=58019 )
[17:37] <slangasek> ev: ah, right; we do get the reports, but we can't appropriately bucket them without dbgsyms
[17:37] <ev> the "is this thing in the Ubuntu archive" check is only run for Launchpad bug reports
[17:38]  * ev nods
[17:38] <ev> though I'm keen to hear exactly what awe was seeing
[17:38] <ev> perhaps there's a bug here
[17:38] <awe> slangasek, so if the -dbg package is screwed up, that would prevent them from showing up, right?
[17:38] <slangasek> well, I suspect a case of Chinese whispers
[17:38] <slangasek> rather than an actual bug
[17:39]  * awe call me confused
[17:39] <ev> ah right
[17:39] <slangasek> awe: errors retracers use dbgsym, which are autogenerated on the autobuilders; there may be bugs there, but any -dbg package listed in debian/control should be irrelevant
[17:40] <awe> ok
[17:41] <jdstrand> slangasek, bdmurray: any idea why bug #1197049 is not showing up under ubuntu-sdk-bugs on http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-s-tracking-bug-tasks.html? the apparmor-easyprof-ubuntu one shows up under ubuntu-security-bugs, but the qtbase-opensource-src is not showing up under ubuntu-sdk-bugs
[17:41] <awe> slangasek, thanks for the answer re: 13.10 by the way!  ;)-
[17:42] <jdstrand> slangasek, bdmurray: pmcgowan subscribed ubuntu-sdk-bugs to qtbase-opensource-src it looks like (listed in the 'May also be notified' area of the bug
[17:43] <slangasek> jdstrand: good question; I defer to bdmurray
[17:44] <slangasek> jdstrand: I do notice it's listed twice under ubuntu-security-bugs, so maybe there's a bug making the qtbase-opensource-src task be misattributed
[17:48] <bdmurray> jdstrand: looking into it
[18:42] <bdmurray> infinity / slangasek: could one of you have a look at bug 1220898? it looks to me like it may be an issue with base-installer
[18:45] <infinity> bdmurray: base-installer?  u-r-u reuses d-i components for this?
[18:45] <slangasek> apparently so
[18:45] <bdmurray> infinity: yes
[18:45] <infinity> Ugh.  Sure does.
[18:46] <infinity> Well, this isn't an "issue" with base-installer, per se, so much as it is that base-installer has never had this logic.
[18:46] <slangasek> rather seems to me that it shouldn't, though
[18:46] <infinity> Why does u-r-u try to be so clever about replacing kernels?
[18:47] <infinity> We offer clean transitional packages for upgrade paths when we mangle kernel flavours, I can't see why the release-upgrader should second-guess any of this.
[18:50] <slangasek> infinity: originally due to bug #353534 / bug #441629
[18:50] <infinity> slangasek: From the code comments, I'm assuming this is all because the CDs didn't ship the transitional packages.
[18:50] <infinity> slangasek: Seems like that would have been the saner fix.
[18:51] <infinity> (And we can certainly make sure the 13.10/14.04 CDs have the -pae transitional packages)
[18:51] <slangasek> no, the original rationale was "the metapackage you had installed still exists but is no longer the thing we want you to be using"
[18:51] <infinity> Anyhow, we could *also* make base-installer list lowlatency as a valid kernel, which would fix this with minimal fuss in the short term.
[18:52] <slangasek> I'd rather see this code culled instead
[18:52] <slangasek> because it seems like the use case it was added for was a one-time thing back in 2008, we ought to get rid of the code instead of kicking the can down the road
[18:53] <infinity> slangasek: The old bugs looked a lot like the transitional packages were poorly done back then.  Talk of things being removed that shouldn't be, etc.
[18:54] <infinity> slangasek: We do still have an outstanding transition here (pae -> generic in 14.04), but it should also be done correctly this time.  Things shouldn't magically disappear.
[18:54] <slangasek> infinity: per the bug description, -386 was *not* a transitional package, but a "deprecated" flavor that we wanted users to move off of
[18:55] <infinity> slangasek: Yeah, a tiny bit different this time.
[18:55] <slangasek> because the meaning of the package hadn't changed, but we wanted to get users moved to a better kernel for their hardware... pae->generic is the opposite
[18:55] <infinity> (Though, we have a similar thing with generic (nonpae) -> generic (pae), and this time we handle it with a preinst check, I think.  We could have done what with 386 -> generic too)
[18:56] <slangasek> anyway
[18:56] <slangasek> cull the code
[18:56] <infinity> I'm all for the culling.
[18:58] <bdmurray> So just remove the kernel checks from ubuntu-release-upgrader altogether correct?
[18:58] <infinity> Bonus points if you can find the original commits to sort out what to revert.
[18:58] <infinity> But basically that, yes.
[18:59] <infinity> I think there is (or used to be) logic that tries to make sure you have "linux-$flavour" installed, matching the running kernel.  That's probably a sane thing to do.
[19:00] <slangasek> so following this thread, I think we want to cut out the dapper/hardy upgrade quirks in DistUpgrade/DistUpgradeQuirks.py too, since they also depend on the base-installer kernel detection
[19:01] <slangasek> and should never be hit on upgrade to saucy
[19:01] <slangasek> infinity, cjwatson, bdmurray: ^^ objections?
[19:01] <infinity> +1 to removing ancient quirks.
[19:02] <slangasek> """ this function works around quirks in the breezy->dapper upgrade """
[19:02] <slangasek> mmmhmm :)
[19:04] <bdmurray> seems like a good idea to me
[19:23] <slangasek> bdmurray: lp:~vorlon/ubuntu-release-upgrader/lp.1220898 pushed, raising an MP now.  (Haven't actually tested it yet)
[19:53] <lool> is there a good sample package for building multiple flavors of a package with dh?
[19:53] <lool> (multiple configure runs, make install etc.)
[19:54] <lool> well I guess I can just hook into override_dh_auto_configure: override_dh_auto_build: etc.
[19:55] <Laney> Both packages I know that do this use CDBS
[19:55] <Laney> glib2.0 gtk+3.0
[19:55] <Laney> Not exactly simple examples though
[19:55] <slangasek> lool: hmmmm.  I remember doing something like that recently but don't remember now which package it was
[19:55] <slangasek> I wonder if it was android-tools
[19:56] <slangasek> well... possibly it was, but I guess that's not a great example :)
[19:56] <slangasek> bdmurray, infinity: ok, have actually tried building u-r-u now and it fails the test suite for me due to testing some functions that have gone away. :)  I've pushed one more commit but still have another failing test that I'm trying to figure out now
[19:58] <lool> slangasek: ok, thanks
[19:58] <slangasek> anyway, yeah, I don't know of a way to do it without overriding the dh_auto_* commands
[19:58] <lool> slangasek: (funnily enough, I did quite some work to cleanup the android-tools patching to get in sync with Debian)
[19:59] <slangasek> :)
[19:59] <slangasek> lool: so this is frequent enough of a request that I think we need to extend dh to support multiflavor builds natively
[19:59] <slangasek> wishlist bug?
[20:00]  * lool checks if there's one
[20:00] <slangasek> bdmurray, infinity: ah, the remaining test suite failure is a pre-existing failure, score
[20:01] <slangasek> build-area/ubuntu-release-upgrader-0.201/tests/test_quirks.py", line 153, in testFglrx
[20:01] <slangasek>     self.assertTrue(q._supportInModaliases("fglrx", mock_lspci_good))
[20:01] <slangasek> nose.proxy.AssertionError: False is not true
[20:12] <slangasek> bdmurray, infinity: oho, the remaining build failure is because the test suite requires you to have restricted enabled in your build environment, what a silly thing.  Ok, test suite passes now.
[20:46] <infinity> slangasek: If dh(1) supported multiflavour builds in a clean way, I bet I could switch glibc.   Could take a few months, but I bet it could be done. :P
[20:47] <slangasek> infinity: this is very tempting :)
[20:47] <infinity> There'd be a sick sense of accomplishment in reducing glibc's thousands of lines of debian/* to a few lines of debian/rules.
[20:50] <lool> slangasek: actually fairly clean!  http://paste.ubuntu.com/6067962/
[20:51] <slangasek> yep
[20:51] <lool> (I could have avoided the repetition, but seems more readable this way)
[20:51] <slangasek> what's $(CONFIGURE_FLAGS)?
[20:51] <lool> slangasek: CONFIGURE_FLAGS := --with-liboil --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
[20:51] <lool> maybe I can drop the libdir nowadays
[20:52] <slangasek> ok - presumably that line will make it back into the final debian/rules, though :)
[20:52] <lool> slangasek: yeah, it's just an extract
[20:52] <lool> there was an irrelevant dh_install snippet too
[20:56] <infinity> lool: BTW.  France is bacon?
[20:56] <infinity> lool: http://i.imgur.com/xFO11dk.png
[20:57] <slangasek> that's *sir* france is bacon to you
[20:57] <mbiebl> lool: i'm basically doing exactly the same in one of my packages where I build a deb and udeb flavour
[20:57] <mbiebl> would be nice to avoid the boiler plate, but it's good enough for now
[20:57] <lool> infinity: I know another one with a John O'Bacon!
[20:59] <slangasek> infinity: I find that all the funnier for understanding the reference before reading the story :)
[21:01] <infinity> slangasek: Plot twist: You're the original reddit commentor?
[21:02] <slangasek> that would be a good plot twist
[21:04] <mbiebl> slangasek: I think what would help also if packages which are part of a transition are auto-rejected
[21:05] <mbiebl> so maintainers who do not follow/care
[21:05] <mbiebl> can not disturb ongoing transitions
[21:05] <slangasek> mbiebl: what transitions are you talking about?  (is this a response to my ubuntu-release post?)
[21:06] <mbiebl> slangasek: oops, sorry
[21:06] <mbiebl> entirely wrong channel
[21:06] <slangasek> heh :)
[21:06] <mbiebl> (was talking to jcristau...)
[21:06] <slangasek> wow, that's quite the name hash collision :)
[21:07] <mbiebl> hehe
[21:10] <mbiebl> slangasek: I'm currently discussing with jcristau on #debian-gnome that the current way of planning and executing transitions is a bit sucky
[21:10] <mbiebl> (to say the least)
[21:10] <mbiebl> especially for software like GNOME, where lot's of transitions are intertwined
[21:11] <mbiebl> so doing them bit by bit requires lots of backporting work to make that possible
[21:11] <mbiebl> and somehow, I switched focus in one of my last replies :-)
[21:11] <mbiebl> slangasek: how you managed to be the receiver of that message, I can't explain
[21:12] <darkxst> xnox, hey can you take a look at Bug 1219188
[22:04] <Spee_Der> Can I get help with gpredict here please ?
[22:21] <bdmurray> Sweetshark: I'm looking at the libreoffice in the raring proposed queue and noticed there are some patches not in the series file and a patch in the series file not in the diff
[22:26] <sconklin> @pilot out
[23:04] <bdmurray> charles: do you have any information on what a crash from bug 1122596 might look like?
[23:05] <bdmurray> charles: we'd like to be able to confirm it isn't happening anymore so we can release the precise sru
[23:05]  * charles looks
[23:07] <charles> hm, disappointing that there's not a stacktrace on the ticket
[23:08] <charles> bdmurray: it would show up as dereferencing a NULL pointer, the self->priv field
[23:08] <bdmurray> charles: would the crash be filed about some other package though?
[23:08] <charles> bdmurray, likely candidates for where this would happen would be
[23:09] <charles> app-indicator.c, bus_creation(), NULL dereference on app->priv->connection
[23:10] <charles> and much less likely, in app-indicator.c, theme_changed_cb(), in "if (priv->dbus_registration != 0)"
[23:10] <charles> wrt showing up in a different package... hmm
[23:13] <charles> bdmurray, I guess it's possible. If so, the stacktrace would show the levels app_indicator_init() -> bus_creation() -> crash
[23:13] <charles> bdmurray: if you're trying to eliminate candidate tickets -- if those aren't in the stacktrace, it's not #1122596
[23:14] <charles> bdmurray: is this helpful? I'm not sure that I'm answering the right question :-)
[23:24] <bdmurray> charles: a bit thanks
[23:25] <cjwatson> lool: I do multiple configure passes with grub2 though it isn't exactly simple
[23:26] <cjwatson> FWIW
[23:28] <cjwatson> lool: though maybe openssh is a better example; it's certainly closer to what you ended up with
[23:50] <sarnold> bdmurray: how shall I ask for an enhancement to the text of one of your bugbots? I want this text to include the relevant release, "The verification of this Stable Release Update has completed successfully and the package has now been released to -updates."... see e.g. https://bugs.launchpad.net/maas/+bug/1171418 comments #8 and #9 -- it took me a while to figure out that the verification had been only been done once, not multipl
[23:52] <cjwatson> sarnold: that's in lp:ubuntu-archive-tools, you can propose a merge
[23:57] <sarnold> cjwatson: thanks