[00:00]  * infinity wishes his compilers built as fast as yours.
[00:03] <robert_ancell> infinity, well, we are just leveraging your compiler
[00:10] <jbicha> robert_ancell: bug 1017289
[00:10] <ubottu> Launchpad bug 1017289 in manpages (Ubuntu) "package manpages 3.35-0.1ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/getent.1.gz', which is also in package libc-bin 2.15-0ubuntu15" [Undecided,Confirmed] https://launchpad.net/bugs/1017289
[00:11] <robert_ancell> jbicha, cheers
[01:33] <alazare619> i cant locate smartbootmanager for making a ubuntu respun iso from scratch any idea
=== rsalveti` is now known as rsalveti
[02:02] <ScottK> robert_ancell: I see stuff in New that isn't ready for the archives for core-devs routinely.  Even from other archive admins.
[02:05] <cjwatson> Legal won't ever go for the notion of accepting uploads without some kind of gateway anyway, so this isn't something that's going to be relaxed.
[02:09] <ScottK> FWIW, if you think debian/copyright is pointless, you're probably one of the reasons a check is necessary.
[02:09] <ScottK> Painful, I totally agree, but not pointless.
[02:11] <cjwatson> Right.  And if you want to be corporate about it, we have customers that want us to do better with it, not worse.
[02:11] <cjwatson> (You == Robert)
[02:11] <ScottK> Yes.
[02:12]  * cjwatson is slowly getting round to converting his packages to the new machine-readable format now that it's stabilised ...
[02:21]  * RAOF would prefer a machine-writable format ;)
[02:25] <ScottK> Yes.
[02:25]  * ScottK is at the "patches will be considered" stage for that.
[02:34] <lifeless> hell yes
[02:34] <lifeless> I've been hugely put off by the copyright format stuff
[02:35] <lifeless> I get the various arguments, but its still super tedious, and only valuable in the margin. (Which isn't the same as not valuable).
[02:35] <RAOF> Sadly I suspect a general solution is probably quite close to strong AI. But a mostly working one would do well, too :).
[02:36] <RAOF> lifeless: I actually find the format quite valuable; it makes it easier for me to check that I've done the copyright thoroughly.
[02:37] <lifeless> sure, I can see that.
[02:41] <ScottK> If the machines want to read it, let them write it.
[02:41] <ScottK> I confess to being sloppy about patch header formatting too.
[02:46] <cjwatson> Sadly I think if it were machine-writable there'd be no need for a machine-readable format.
[02:49] <RAOF> Because then you'd just run the tool over the codebase, irght.
[02:50] <robert_ancell> The biggest problem with debian/copyright is it is only checked when creating the package, and then the package changes constantly underneath it.  How many of the debian/copyright files are actually an accurate representation of what the source copyrights are?  By writing a detailed file that probably contains incorrect information, what risk are we entering if we are incorrectly stating the copyrights?
[02:51] <robert_ancell> The only purpose from our point of view seems to be so we can check that we can legally distribute the software.  Anything more than that we should just say "consult the source/upstream"
[02:52] <cjwatson> This was all gone into in the discussions about the machine-readable format.
[02:52] <cjwatson> And no, that's *not* the only purpose, and as an uploader it's important that you understand this.  It's also important that our customers and users be able to do scans of licence compatibility without having to read hundreds of licences by hand.
[02:52] <cjwatson> This is a genuinely valuable piece of distro integration work.
[02:53] <cjwatson> Even if you don't care about it.
[02:53] <robert_ancell> yes, but that's only useful if the information is accurate
[02:53] <cjwatson> True of any distro integration.
[02:54] <cjwatson> Copyright changes are frequent, but for this purpose they're not desperately important.  Licence changes are infrequent and generally people do keep d/copyright up to date with those.
[02:54] <cjwatson> And if they miss it, it's only a bug report away once somebody notices.
[02:55] <robert_ancell> cjwatson, btw, which customers/users do these license scans?  And for what purpose?
[02:55] <cjwatson> This is a public channel; I'm not going to go into specifics.
[02:56] <cjwatson> Generally it's for compliance with what their legal department demand as due diligence.
[02:56] <robert_ancell> I mean "what types of customers/users", but I think you've answered that
[02:56] <cjwatson> Very big ones, generally.
[02:57] <cjwatson> At least IME from when they've asked Amanda questions and she's redirected to me.
[02:59] <robert_ancell> we should make the "Copyright" header optional, as that seems the most problemtaic one
[03:00] <cjwatson> Most widely-used licences require that redistributed copies of the software include copyright notices.
[03:01] <cjwatson> So I'm not particularly wild about encouraging you to violate those licences.
[03:03] <cjwatson> (Hm, actually, GPLv2 only requires that for source; GPLv3 likewise although it permits supplementation with terms that require preservation of legal notices in binaries.  BSD requires binary redistributions to reproduce copyright notices.)
[03:05] <cjwatson> Anyway, I appreciate that it's tedious and that it's an engineer's instinct to automate it away or try to avoid it, but good engineering also involves knowing what the constraints are.
[03:07] <cjwatson> The consequences of failing to keep Copyright up to date are probably relatively minor, but I do think it's worth at least making some effort.  Most of the rest is genuinely important in that failing to do our job there can easily result in either us inadvertently violating licences ourselves (because we assumed that our own licensing records were accurate) or in leading our users to do so.
[03:07] <cjwatson> So please make an effort.
[03:16] <mwhudson> (if this sounds like hard work, i have a flexlm install you might be interested in ...)
[03:28] <micahg> infinity: is there a chance we can use gcc-4.4 as the fallback for new compiler issues instead of gcc-4.5 on arm*?
[03:29] <micahg> that is assuming Debian is dropping 4.5 and not 4.4 imminently
[04:07] <slangasek> SpamapS: circular> yes, but that's allowed and not new
[04:34] <jbicha> robert_ancell: did you see that your manpages fix didn't work?
[04:35] <robert_ancell> jbicha, no, is there a bug report?
[04:35] <robert_ancell> oh, reading it now
[04:57] <robert_ancell> jbicha, ok, take 2
[05:42] <pitti> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[05:42] <pitti> Good morning
[06:00] <ion> that
=== tomreyn_ is now known as tomreyn
[06:59] <dholbach> good morning
[07:29] <larsduesing> morning together
[07:30] <larsduesing> hmm, is it ok to give users some advice which do not match the bug but I found while browsing apport-attachments?
[07:30] <larsduesing> (like i did https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1017161/comments/2 )
[07:30] <ubottu> Launchpad bug 1017161 in aiccu (Ubuntu) "package aiccu 20070115-14.1ubuntu3.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New]
[08:58] <xnox> I see that initramfs hooks copy udev rules from /lib/, and do not copy udev rules from /etc/ on top.
[08:59] <ogra_> sounds like a bug
[08:59] <xnox> is this intentional, or simply not supported to copy udev overrides into initramfs, and people should right their own initramfs hooks.
[08:59] <ogra_> if i'm admin of a system i expect my overrides to also show up in the initrd
[09:00] <xnox> surely there should be a helper function copy_udev_rule. Instead of each hook inventing their own way to copy the udev rule
[09:00] <ogra_> dont they just all use copy_exec ?
[09:00] <xnox> nevermind that there is wait_for_udev, and yet hooks are calling their own incarnation of udevadm settle
[09:00] <ogra_> oh my
[09:00] <cjwatson> That sounds unintentional.
[09:01] <xnox> copy_exec is to copy the binary + dependencies, not the text files *.rule
[09:01] <xnox> should I file a bug with found instances of this and open a task per package to fix these?
[09:02] <xnox> I'm guessing that a helper which does {/lib|/etc}/udev/*.rules copy first in initramfs-tools would be better.
[09:02] <xnox> unless there is one, checking.
[09:03] <xnox> anybody knows about the history of /usr/share/initramfs-tools/event-driven/upstart-jobs/mountall.conf
[09:03] <xnox> ?
[09:03] <ogra_> well, looking at my default install there are only three hooks copying rules around
[09:03] <ogra_> dmsetup, cryptopenct and udev itself
[09:04]  * ogra_ wonders why we still have the compcache hook ... i guess that can go
[09:05] <xnox> ogra_: dmraid, mdadm, lvm2, cryptsetup copy udev rules on my machine
[09:06] <xnox> well that means add lvm2 to your list ;-)
[09:06] <ogra_> ah, i dont have mdadm, cryptsetup or lvm installed
[09:07] <xnox> some of them actually do sensible things
[09:08] <xnox> http://paste.ubuntu.com/1058793/ copies combinations of "etc lib" && "97- 97_"
[09:14] <xnox> mdadm, udev, kpartx, cryptopenct  copy only the /lib/ version.
[09:14] <xnox> note that cryptoopenct copies only /etc/ one which doesn't exist.... maybe it's dynamically generated?
[09:14]  * xnox wonders if smartcard decryption works or not.
[09:20] <Laney> Does anyone have a trick to get sbuild to enter the chroot on ftbfs?
[09:24] <xnox> Laney: use pbuilder-dist with recovery hook. My recovery hook installs less & zile (small emacs clone)
[09:24] <Laney> yeah, I know how to do it with pbuilder
[09:24] <Laney> but sbuild is better :P
[09:24] <xnox> Laney: alternatively, I had some luck with LVM snapshots backed sbuild builds to leave the snapshot around on FTBFS
[09:24] <tumbleweed> Laney: it's not that hard to type schroot -rc $PASTE
=== kInOzAwA is now known as Guest85620
[09:24] <xnox> then I'd mount the FTBFS snapshot & chroot into that
[09:25] <tumbleweed> sbuild has an option to leave snapshots around after failures, no matter how they are backed
[09:25] <Laney> tumbleweed: if it's left around on failure
[09:25]  * xnox once ran out of snapshot space though.....
[09:25] <Laney> that is the kind of information i'm after
[09:25] <tumbleweed> $purge_build_directory = 'successful';
[09:25] <tumbleweed> $purge_session = 'successful';
[09:25] <Laney> ta
[09:26] <tumbleweed> now you need to occasionally run schroot -e --all-sessions
[09:26] <Laney> yeah, well I sometimes have to do that anyway
[09:27] <Laney> my overlay isn't that big, so I notice pretty quickly
=== zyga_ is now known as zyga
[10:36] <Daviey> slangasek / bdmurray / SpamapS : Please can the nova SRU be progressed soon.. ta muchly.
=== chu_ is now known as chu
[10:41] <larsduesing> hmm, is it ok to give users some advice which do not match the bug but I found while browsing apport-attachments?
[10:41] <larsduesing> (like i did https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1017161/comments/2 )
[10:41] <ubottu> Launchpad bug 1017161 in aiccu (Ubuntu) "package aiccu 20070115-14.1ubuntu3.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New]
[10:45] <tumbleweed> larsduesing: don't see why not
[10:45] <tumbleweed> lucky user
[10:45] <larsduesing> ok... just asking :)
[11:11] <Laney> tumbleweed: where is BUILDDIR?
[11:16] <tumbleweed> Laney: context?
[11:16] <Laney> re our previous conversation, when I schroot -rc into the chroot
[11:16] <tumbleweed> Laney: ah /build/*
[11:16] <Laney> I see "replacing <BUILDDIR> with /some/relative/path", but I don't know what it's relative to
[11:16] <Laney> oh, it's not relative, I see
[11:16] <Laney> ta
[11:16] <cjwatson> cd /build/<tab><tab>
=== MacSlow is now known as MacSlow|lunch
[12:12] <xnox> submittodebian didn't work as expected - it didn't let me edit the body of the message to explain why it is needed, instead it emailed the bug with ugly #### comments in them =(
[12:15] <tumbleweed> xnox: you don't use mutt?
[12:16] <xnox> tumbleweed: I use emacs
[12:17] <xnox> tumbleweed: I think the option 'printonly' kicked in on the screen and it didn't actually send it
[12:19] <tumbleweed> reportbug should have made you edit it first
[12:20] <xnox> I didn't have editor option set in the reportbug, but I had printonly set (maybe i was debugging something?!), that's why it did run editor, I think.
[12:20] <xnox> let's try again
[12:21] <tumbleweed> yup, that's probably why
=== _salem is now known as salem_
[12:47] <xnox> worked like a charm =)
[12:49] <tumbleweed> so you need to have more trust in your tools :)
[12:52] <infinity> micahg: My 4.5 workaround are VERY temporary, until the buildds have new kernels.  I don't expect nor want this to be long-lasting.
=== yofel_ is now known as yofel
=== doko_ is now known as doko
[13:11] <doko> ev, cjwatson: did you say, that the gdb debug mode only works with python2, not python3?
[13:23] <SpamapS> Daviey: I think today your best bet might be infinity
[13:24] <SpamapS> infinity: are you doing SRU processing today? If so, Daviey is asking for a queue jump for nova.
[13:24] <cjwatson> doko: I thought you said that and we just agreed
[13:24] <cjohnston> jdstrand: ping
[13:25] <jdstrand> cjohnston: hi
[13:25] <cjwatson> Perhaps /usr/lib/debug/usr/bin/python3.2-dbg-gdb.py being a dangling symlink isn't helping
[13:25] <cjohnston> jdstrand: I was asked to ping you on bug #1017462 to see your opinion
[13:25] <ubottu> Launchpad bug 1017462 in python-django-openid-auth (Ubuntu) "Please remove python-django-openid-auth from the repos" [Wishlist,Triaged] https://launchpad.net/bugs/1017462
[13:25] <cjwatson> doko: I think there's some confusion here between python3.2 and python3.2mu
[13:26] <infinity> SpamapS: I may be, but it won't be until after I've woken up from a much-needed nap. :/
[13:26] <xnox> bremner> xnox: btw, I think rlb will upload emacs24 soon, which should fix (sortof) your notmuch emacs-bug
[13:27] <cjwatson> Though my naïve attempts at fixing it locally haven't worked
[13:27] <jdstrand> cjohnston: what specifically did you need my opinion on?
[13:27] <jdstrand> (also if this is related to patch piloting, I had to rescedule my shift today)
[13:27] <cjohnston> jdstrand: see if you can think of any issues with removing it.
[13:27] <cjohnston> I don't think so
[13:33] <jdstrand> cjohnston: I can't no-- there are no reverse depends. You might want to look at http://wiki.debian.org/Renaming_a_Package (since it is effectively a rename when considering both Debian and Ubuntu)
[13:35] <Daviey> cjohnston: I raised this issue about a year ago.. but there were hesitations with removing it then.. I don't think those are still valid.
[13:35] <cjohnston> Daviey: ok..
=== zyga is now known as zyga-food
=== zyga-food is now known as zyga
[14:40] <csaba_pap> msg NickServ identify butch1117
[14:41] <pitti> someone might want to change her password now
[14:42] <chrisccoulson> oops ;)
[14:51] <xnox> is a 1.42.4-3ubuntu2~12.04.1  sensible version number for a Precise SRU where quantal has 1.42.4-3ubuntu2 ?
[14:52] <xnox> this is not a security upload
[14:53] <jamespage> xnox: does the fix apply for quantal as well?
[14:54] <xnox> jamespage: i am "backporting" micro point releases from quantal which fixed a lot of bugs
[14:54] <jamespage> xnox, ah
[14:54] <jamespage> I see
[14:54] <xnox> jamespage: well not a lot, but a few grave bugs.
[14:55] <xnox> jamespage: i thought this way I will not "steal" security version number 1.42.4-3ubuntu2.1 or like 1.42.4-3ubuntu2.12.04.1
[14:56] <xnox> jamespage: or I can upload a no-change rebuild into quantal to give myself room in the number, but I think that way will be slightly more ugly =/
[14:58] <xnox> jamespage: or I can upload a no-change rebuild into quantal to give myself room in the number, but I think the '~' way is less ugly =/
[14:59] <jamespage> xnox: I agree
[14:59] <jamespage> its more like what happens with backports which is what this is
[15:00] <tumbleweed> xnox: you can also use a more SRUish version, and just say that it's a backport of version X in the changelog
[15:01] <xnox> tumbleweed: I could use 1.42.4-3ubuntu0.12.04.1 hmmmm
[15:02] <xnox> but that would be lies.
[15:02] <tumbleweed> xnox: what's the package?
[15:02] <xnox> tumbleweed: oh *just a minor thing* *cough* e2fsprogs
[15:02] <tumbleweed> it's not really lies. We don't sync to older releases
[15:03] <tumbleweed> even could do 1.42.4-0ubuntu0.1
[15:04] <xnox> i'd rather have SRU version clearly show up-to which point the packaging goes as well though.
[15:05] <xnox> well, SRU team will review the version number anyway =)
[15:07] <xnox> ev: test driven development with C and cppUTest http://raphaelhertzog.com/2012/06/25/test-driven-development-with-cpputest-now-in-debian/
[15:07] <xnox> FYI
[15:10] <ev> xnox: this looks excellent from a cursory glance. Might play around with it tonight or tomorrow. Thanks!
[15:10] <xnox> ev: =)
=== Ursinha` is now known as Ursinha
=== Ursinha is now known as Guest89684
=== Guest89684 is now known as Ursula
=== Ursula is now known as Ursinha
[15:26] <cjwatson> mvo: Hey, do you have a minute to talk about the way DDTP uploads work?
[15:27] <ScottK> barry: If you're tracking python3.3 compatibility, the python3.3 compatible version of PyQt is in Debian New ATM and we'll have it shortly.
[15:27] <mvo> cjwatson: sure, in a call right now, after that, in ~15min?
[15:27] <cjwatson> mvo: Sure
[15:27] <barry> ScottK: \o/
[15:29] <micahg> infinity: ok, let's hope that's really the case :)
[15:49] <mvo> cjwatson: so lp:apt-ddtp-tools has all the stuff needed plus a file called "UbuntuChecklist" that hopeflly covers the bits and pieces needed, its mostly automatic, but only mostly :/ it was meant to become part of rosetta at some point
[15:50] <mvo> cjwatson: now obviously the branch owner "~mvo" on various places is wrong, I need to replace that with ~ubuntu-core-dev I think
[15:53] <xnox> English question: "an FBI agent" or "a FBI agent"
[15:54] <tumbleweed> an
[15:54] <tumbleweed> a/an is phonetic
[15:54] <ScottK> Agreed.
[15:54] <cjwatson> mvo: Right - I'd found that, but the thing I wanted to talk to you about was the mechanism it uses
[15:55] <cjwatson> mvo: It appears to me that apt-ddtp-tools is doing a set of binary-only custom uploads
[15:55] <cjwatson> mvo: Is my understanding correct?
[15:55] <mvo> cjwatson: yes, that is true, a custom upload target that got implmented around 2005 I think
[15:55] <cjwatson> The custom-ness is fine, but the fact that it doesn't have a source package is less fine
[15:56] <cjwatson> This makes it *really* hard to fix bug 827941
[15:56] <ubottu> Launchpad bug 827941 in Launchpad itself "Copy ddtp-translations uploads to new distroseries" [High,In progress] https://launchpad.net/bugs/827941
[15:56] <mvo> cjwatson: let me look at this bug
[15:56] <cjwatson> I have a patch for the Launchpad side of it
[15:56] <cjwatson> But it relies on being able to track through a SourcePackagePublishingHistory
[15:56] <cjwatson> And ddtp-tarball uploads are utterly anomalous because they don't have one
[15:56] <mvo> cjwatson: I'm happy to change the way the uploads are done in any way necessary
[15:57] <cjwatson> Do you think it'd be reasonable to rearrange apt-ddtp-tools so that it generated a source package which then produces these custom uploads?
[15:57] <cjwatson> I'd be happy to put a patch together
[15:57] <mvo> cjwatson: absolutely, that is fine
[15:57] <mvo> cjwatson: while at it, I  cleanup the branch ownerships issues
[15:57] <cjwatson> Cool.  I'm not certain off the top of my head whether a build that consists exclusively of custom files will work; but, if it doesn't, I'll fix that in LP
[15:58] <cjwatson> This will fix bug 672314, with a bit of cleanup of old series
[15:58] <ubottu> Launchpad bug 672314 in apt (Ubuntu) "No translated package descriptions for -updates repository" [High,In progress] https://launchpad.net/bugs/672314
=== deryck is now known as deryck[dentist]
[16:10] <Daviey> cjwatson: Re-spin of alternate & server?
[16:11] <Daviey> err, that was supposed to be in -release
[16:12] <cjwatson> que?
[16:22] <ximion> pitti: hi! Are you there?
[16:22] <ximion> you contributed to the PackageKit apt backend, right?
[16:28] <juliank> ximion: Fun fact is that I asked glatzor about the undefined variable bug 3 hours ago, but he did not answer me
[16:28] <ubottu> Launchpad bug 3 in Launchpad itself "Custom information for each translation team" [Low,Fix released] https://launchpad.net/bugs/3
[16:28] <juliank> bad bot!
[16:29] <ximion> :-D
[16:29] <ximion> cool!
[16:30] <ximion> well, the apt backend is in Debian if people want to try it out / to offer this option
[16:30] <juliank> I also asked him something on Saturday, but did not receive an answer either, so maybe he just ignores everything I write currently.
[16:30] <ximion> but if the apt backend does not work and nobody maintains it, I would likely drop it, as it is for no use to anyone at that state (and reinclude it later in Wheezy+1, if it is updated)
[16:31] <ximion> probably busy...
[16:32] <juliank> But not busy enough to introduce RC-buggy code everywhere I look.
[16:32] <ximion> but I'm not sure if the future of apt-backend is very save, since glatzor is the upstream author of aptd, so why should he work on making his own project obsolete? (if he thinks aptd is better, what he does at time (and he has a fair point regarding some issues atm))
[16:32] <ximion> hehe, okay - then it's a bad time to be busy :P
[16:37] <ximion> I'm very busy too (exams), but I still look at this stuff (fyi the aptcc security issue will be fixed, but I'm not 100% sure if I can do that before freeze - but I'll definitely get an exception for that :P)
=== beuno is now known as beuno-lunch
=== beuno-lunch is now known as beuno
[16:57] <JohnC_> anybody here?
[17:09] <ScottK> No.
=== Quintasan_ is now known as Quintasan
[17:41] <ximion> juliank: I'll do a packagekit upload tomorrow - if I haven't heard a decision yet, I'll drop the apt backend for Wheezy then, it's unlikely that it will be fixed before release.
[17:41] <ximion> the issues are massive and won't be ack'ed by the release-team
[17:42] <ximion> *I mean fixes for them would be huge and not accepted into testing
[17:50] <ximion> would be cool if pitti could comment on his view on the PackageKit apt backend :-)
=== AaronMT is now known as AaronMT|2
[18:02] <xnox> I messed up a wiki page
[18:02] <xnox> can a revision be reverted
[18:02] <micahg> xnox: sure, there should be an edit option
[18:03]  * xnox whooh, I think I managed to do it.
[18:08] <xnox> micahg: If you go to: https://wiki.ubuntu.com/StableReleaseUpdates how many special cases subtitles do you see?
[18:08] <micahg> xnox: 10
[18:09] <xnox> micahg: good. The 'info' tab diff is weird =/
=== deryck[dentist] is now known as deryck
[18:39] <skinpatch> hi all
[19:00] <tedg> slangasek, So, presumably the liveCD is going to have to have a collection of bootloaders on it.  How do we know which one is actually being used?
[19:01] <tedg> On an installed system, but I figure that will match the live CD.
[19:01] <tedg> Or will only one be installed?
[19:08] <Sp4rKy> a/W 25
[19:20] <Anxi80> Is there an official method for passing suggestions on to the devs for future version of ubuntu?
[19:20] <Pici> !brainstorm
[19:20] <ubottu> Post your ideas for Ubuntu at http://brainstorm.ubuntu.com and vote for the ones you like!
[19:21] <Anxi80> perfect thanks!
[19:25] <ahasenack> hi, is there a way to force do-release-upgrade to upgrade lucid to precise? It keeps saying "No new release found", and
[19:25] <ahasenack> if I change the config from "lts" to "normal" it tries to upgrade to maverick
[19:26] <xnox> ahasenack: LTS -> LTS upgrades start after the first point one release, i.e. 12.04.1
[19:27] <micahg> ahasenack: -d
[19:27] <ahasenack> micahg: won't that upgrade it to quantal?
[19:27]  * ahasenack tries
[19:27] <micahg> ahasenack: not from lucid :)
[19:27] <ahasenack> micahg: ah, nice :)
[19:27] <xnox> ahasenack: or listen to my evil twin micahg ;-)
[19:27] <ahasenack> micahg: it's working
[19:27] <ahasenack> xnox: thanks too, good to know about the .1 detail
=== trinikrono is now known as trinichica
=== trinichica is now known as chica
[19:44] <slangasek> tedg: what precisely is it that you want to know?  which bootloader /was/ used for the current boot?  which bootloader /will be/ used for the next one?  the latter may depend on whether the user has enabled/disabled secureboot between reboots
=== Guest73293 is now known as dpb_
=== dpb_ is now known as dpb__
=== dpb__ is now known as dpb___
[20:46] <hallyn> slangasek: hi, the debian sysvinit maintainer was very helpful at first, but now has gone quiet.  When you get a chance, could you take another look at my new proposed fix for bug 974584 ?
[20:46] <ubottu> Launchpad bug 974584 in sysvinit (Ubuntu Quantal) "Semaphores cannot be created in lxc container" [High,Triaged] https://launchpad.net/bugs/974584
[20:46] <hallyn> slangasek: if you wouldn't want to take that into ubuntu without it being accepted in debian, then i think i'll give up and keep working around it in lxc
[21:26] <dupondje> Empathy broken since last update :(
=== salem_ is now known as _salem
[23:32] <infinity> rbelem: Any news on the new plasma-mobile snapshot?
[23:49] <xnox> infinity: if I type $ host localhost
[23:50] <xnox> what do you expect as an output?
[23:51] <xnox> $ host localhost
[23:51] <xnox> localhost has address 127.0.0.1
[23:51] <xnox> localhost has IPv6 address ::1
[23:51] <xnox> But on my local machine I get
[23:51] <stgraber> xnox: depends on your DNS server
[23:51] <xnox> $ host localhost
[23:51] <xnox> Host localhost not found: 3(NXDOMAIN)
[23:51] <xnox> so my machine has borked DNS server?
[23:52] <stgraber> well AFAIK nothing in the RFC forces the DNS servers to return a record for localhost
[23:52]  * xnox is not good with networking but "Host localhost not found: 3(NXDOMAIN)" doesn't sound good
[23:52] <stgraber> what should always return the right result though is "getent hosts localhost"
[23:52] <cjwatson> You aren't really supposed to go to the DNS to look up localhost
[23:52] <xnox> $ host ::1
[23:52] <xnox> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa domain name pointer localhost.
[23:52] <xnox> doesn't look good either
[23:53] <stgraber> running "host" goes right to your DNS server without going through the nss stack
[23:53] <xnox> hmm
[23:53] <cjwatson> host(1) does an explicit DNS server query - it's not simply ... right, what Stéphane said
[23:53] <stgraber> I usually make sure that none of my DNS servers ever returns something for localhost/localhost.localdomain/127.0.0.1/::1/... as they shouldn't
[23:53] <xnox> and is there a magic switch to getent to get a IPv6 address?
[23:53] <cjwatson> Though your output for ::1 is a straightforward IPv6 reverse record
[23:54] <xnox> $ getent hosts localhost
[23:54] <xnox> 127.0.0.1       localhost
[23:54] <xnox> so where is my IPv6 address?
[23:54] <cjwatson> Doing this for everything in shell is probably difficult, but you can use getaddrinfo/getnameinfo in C
[23:55] <stgraber> not aware of a specific way of forcing getent to return an ipv6 record, I usually just use getaddrinfo()
[23:55] <cjwatson> Or any language that binds those functions
[23:56] <stgraber> xnox: depends on the systems but IIRC by default in Ubuntu "localhost" isn't an alias of ::1, ip6-localhost is
[23:57] <xnox> Started IPv6 smoke perftest on broker port 34980
[23:57] <xnox> Cannot resolve ::1:34980: Address family for hostname not supported (qpid/sys/posix/SocketAddress.cpp:140)
[23:57] <xnox> qpid-send: Failed to connect (reconnect disabled)
[23:57] <xnox> qpid-receive: Failed to connect (reconnect disabled)
[23:57] <xnox> receive failed '' != 'hello'
[23:57] <xnox> FAIL: ipv6_test
[23:57] <xnox> stgraber: it is the case on debian?
[23:59] <stgraber> xnox: no idea, I don't see why we'd diverge there though, so probably the same is true on Debian
[23:59] <cjwatson> AFAIK yes