[01:14] <adam_g> slangasek: any thoughts on whether the precise fix for bug #990742 should be targetted toward openldap or cyrus-sasl2 (like it did in debian)?
[01:34] <slangasek> adam_g: it needs fixing in both packages; cyrus-sasl2 needs to add the necessary Breaks and bump the shlibs, and openldap needs rebuilt against the fixed cyrus-sasl2 to get the right dependency
[05:00] <nixternal> infinity: hey, thanks again for your pointers earlier. i think i am finally on to something with apt-ftparchive & overrides for the Task. finally i see Task where I need to, now just hope the live-build works as planned :)
[05:01] <nixternal> on that note, I am going to go hunt down a beer, i have spent the better part of today hacking together a derivative skeleton using the proper tools. none of that remasterthis crap :D
[05:10] <pitti> Good morning
[05:25] <ajmitch> hi pitti
[06:40] <dholbach> good morning
[07:58] <xnox> Good Morning! =)
[08:08] <sveinse> debootstrap --variant=minbase is the absolute minimal system which is capable of proper installs with apt-get/dpkg, right?
[08:23] <cjwatson> sveinse: yes
[08:23] <cjwatson> That's Priority: required + apt
[08:24] <dupondje> my sweet valgrind, why you don't run with X-forwarding :(
[08:31] <henrix> pitti: hi! I have this bunch of kernel pkgs copied into the wrong component... could you take a look at this?
[08:31] <pitti> henrix: I'm already at it
[08:31] <henrix> pitti: cool, thanks
[08:31] <apw> which component makes the 'when lid is closed, suspend, when power is critically low' etc ?  is that gnome-settings-daemon ?
[08:31] <pitti> henrix: RAOF copied the kernels this time, and we wanted to try whether the +queue page works for overriding
[08:31] <pitti> apw: yes, g-s-d does the policy decisions, upower is the d-bus backend to actually "do" the actions
[08:33] <apw> pitti, i have a situation where the setting for "when power is critically low" is unset (probabally set to hibernate which is disabled) and this leads (on battery near empty) a wake from suspend/resuspend loop till power death, g-s-d or upower for the bug ?
[08:33] <cjwatson> pitti: I thought it was well-known that it doesn't :-)
[08:33] <pitti> now I do :)
[08:34] <pitti> so this is still a situation where only a person with cocoplum access can do the copying
[08:35] <apw> pitti, this is the copy from PPA to -proposed I assume.  i almost wonder on those if we could have a cronjob; given uploading to -proposed is 'open'
[08:36] <pitti> apw: yeah, I already mentioned this a while ago -- as there is nothing to decide for the SRU team, the copying shoudl/could just be done by the kernel team themselves
[08:36] <pitti> I'm not sure whether the copying requires ~ubuntu-archive privileges, but it might not
[08:37] <cjwatson> Copying shouldn't
[08:37] <pitti> but anyway, fixing components needs an archive admin
[08:37] <apw> pitti, oh hmmm though the component overrides are an issue, but could we cron those perhaps
[08:37] <cjwatson> They won't be sanely cronnable yet; maybe after I APIify overrides
[08:37] <apw> but yes i assume anyone with upload rights for those package ought to be able to copy them
[08:37] <pitti> apw: at least you could do all the copies which don't involve ABI bumps
[08:37] <pitti> apw: right
[08:38] <pitti> apw: so if you want, you can try running copy-proposed-kernel.py when the next kernel is ready
[08:40] <apw> pitti, i assume if its an abi bumper and i copy them they ought to go into (New) cause of the new binaries
[08:40] <pitti> apw: no, they don't; they will be in unapproved just as regular kernel syncs
[08:40] <pitti> s/syncs/copies from PPA/ (they appear as "sync" on +queue)
[08:41] <pitti> apw: copies with binary packages from PPAs evades NEW
[08:41] <apw> ahh i see
[08:41] <pitti> they are auto-accepted into universe
[08:41] <pitti> (which is the whole problem -- on the NEW +queue page we could override them to main)
[08:41] <apw> ahh, poop, i see
[08:44] <cjwatson> is there an LP bug about that?
[08:44] <cjwatson> it should determine NEWness relative to the archive being copied into, IMO
[08:44]  * pitti looks
[08:46] <pitti> I can't find one
[08:46] <pitti> I'll file one
[08:47] <cjwatson> thanks
[08:49] <pitti> apw, cjwatson: Filed as bug 993120, sub'ed kernel and SRU teams
[08:51] <cjwatson> pitti: "from where any archive admin or SRU team member could override them to main" - er, well, only if you want to override *all* binaries in the upload to the same component (bug 828649)
[08:52] <pitti> cjwatson: yes, but in all releases since natty we can do that
[08:52] <cjwatson> sure
[08:52] <pitti> for lucid there are still some binaries which are in universe, and those still need manual overriding
[08:52] <pitti> that's why I'm so insistant on having all binaries in main, as it makes the biweekly processing so much easier
[08:53] <cjwatson> I'm just cautioning against forgetting that this restriction exists, because at some point somebody will try to generalise this beyond the kernel
[08:53] <cjwatson> though I do hope to lift this restriction soon as part of API exposure
[08:53] <pitti> right, but that's a general limitation of the +queue page
[08:54] <pitti> for that, and for general component-mismatches we'll still need a lplib api for changing overrides, of course
[08:54] <cjwatson> yep, on its way
[08:54] <pitti> it is? great!
[08:54] <cjwatson> I've been working on it for a while, though shelved it for release
[08:54] <pitti> thinking about it, change-override.py is 90% of why I'm logging into cocoplum
[08:55] <pitti> the other 10% is manual diffs for large packages when the automatic diff is wrong or doesn't exist
[08:55] <cjwatson> if you happen to remember any of the remainder that isn't on https://wiki.ubuntu.com/FoundationsTeam/ReplaceArchiveAdminShellAccess, please do log it
[08:55] <pitti> but that's not a principal limitation, and is possible on the client-side too
[08:56] <pitti> yep, will do; I think I read that page a while ago already, it came up on some ML
[08:56] <cjwatson> yep
[08:57] <pitti> oh, and lp-remove-package.py, of course (but that's also covered already)
[08:58] <cjwatson> indeed
[09:24]  * cjwatson runs out of obvious morning archive admin work to do.  Is it really the beginning of the cycle? :-)
[09:25] <cjwatson> (I think the new auto-sync procedure is just that much easier; I'm sure I've never more or less caught up on new packages this quickly before)
[09:28] <Laney> removals? :-)
[09:28] <cjwatson> caught up on those too, at least those since 2012-04-01
[09:29] <cjwatson> I think I got most of the earlier ones pre-release
[09:29] <tumbleweed> I swear I've seen UTF-8 characters in names not get mangled before? https://lists.ubuntu.com/archives/quantal-changes/2012-May/000210.html
[09:29] <cjwatson> https://bugs.launchpad.net/launchpad/+bug/362957
[09:29] <tumbleweed> ah, good
[09:29] <cjwatson> though that's not quite the same bug; similar
[09:30] <tumbleweed> yeah, not the same
[09:30]  * tumbleweed files a new one
[09:31] <dupondje> meh, the ppa builders are quite buzzy atm.
[09:44] <geser> cjwatson: when you processed removals, did you process only new ones or old forgotten ones too? like "tcpquota", "cradle" or "libmoosex-chainedaccessors-perl"
[09:46] <cjwatson> geser: only the relatively recent ones; happy to go back and look again, roughly what date were those removals done in Debian?
[09:47] <geser> cjwatson: tcpquota: 2010-07-01 and the last two 2012-02
[09:48] <cjwatson> wow, that's odd
[09:48] <cjwatson> old
[09:51] <geser> going through tumbleweed's neglected package list I found one package more: "libnode-vargs" (2012-02-02)
[09:59] <cjwatson> tcpquota never showed up in the ftpmaster removals list
[10:00] <cjwatson> removing it manually now
[10:02] <cjwatson> libmoosex-chainedaccessors-perl has an rdepends: libhtml-formfu-perl, waiting for that to build first
[10:02] <cjwatson> (new version that drops the depends)
[10:05] <cjwatson> cradle rdepends channel-server, which claimed to be replaced by a package called "buddycloud-server" which has never made it to testing
[10:06] <cjwatson> though to be fair neither did channel-server, so I guess it doesn't lose anything
[10:07] <cjwatson> this is the kind of reason packages don't get removed at the time :-)
[10:08] <cjwatson> libnode-vargs is in the same cluster
[10:08] <cjwatson> synced buddycloud-server, I'll see if that manages to build
[10:08] <cjwatson> geser: for future such cases, probably best to just file bugs, as they may well need analysis like this
[10:18] <geser> cjwatson: will certainly do, I didn't look at those packages in detail yet. And I never know if a bug is needed or not (because the package will get removed on the next round of importing removals).
[10:19] <cjwatson> you can assume at this point that anything before about April isn't going to get removed automatically
[10:19] <cjwatson> if there's a bit of duplication, well, shrug
[10:20] <geser> ok
[10:26] <henrix> pitti: sorry to bother again, but it looks like we have a few more pkgs landing on the wrong place
[10:37] <jdthoodEtrawsfyn> I can't find this information in the Launchpad help: when report X is marked as a duplicate of report Y, do comments on Y get mailed to the submitter of X, or not?
[10:40] <hrw> I see that quantal got nice set of upgrades ;)
[10:42] <cjwatson> pitti: have you had to use sru-release on cocoplum at all since we switched to the async copy method?
[10:43] <pitti> cjwatson: no, never; this is rock solid
[10:43] <cjwatson> can I nuke it then?
[10:43] <pitti> please do
[10:44] <cjwatson> 22 bottles of beer on the wall
[10:45] <cjwatson> pitti: also, does anything still use sru-pending on cocoplum?  that looks kind of obsolete
[10:46] <pitti> cjwatson: indeed it is -- 21 bottles!
[10:46]  * cjwatson nukes
[10:46] <cjwatson> slowly but surely
[10:47] <dupondje> those ubuntu-mozilla-daily ppa builds eat all resources
[10:47] <dupondje> bastards!
[10:48]  * pitti waves with the CoC
[10:50] <chrisccoulson> dupondje, those daily builds aren't really daily for most releases. they are biweekly for most, which already makes my life significantly more difficult when something does regress on one release
[10:50] <chrisccoulson> (ie, bisecting 4 days of commits as opposed to 1)
[10:53] <dupondje> you should get a dedicated buildbox ;)
[10:53] <chrisccoulson> i'd like that!
[10:54] <cjwatson> doko_: could you merge at least the part of the gdb packaging that removes type-handling?  it's the last thing in the archive that uses it, and type-handling is due for removal
[10:54] <cjwatson> (I'd do it myself but I don't know if you want to do a more general packaging merge)
[10:55] <doko_> on my list, but not now
[10:55] <cjwatson> sure
[11:28] <dupondje> chrisccoulson: https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/3454000
[11:28] <dupondje> its stuck ?
[11:28] <dupondje> Started 2012-05-01
[11:32] <sveinse> Is it mandatory to set the locale on a debootstrapped system? I see the armel roostock tool sets the locale, but it seems a bare system works fine without it.
[11:33] <cjwatson> most things will work fine; you'll get some tedious warnings if you chroot into it with locale environment variables set
[11:33] <cjwatson> you don't need to generate locales if you leave the locale environment set to C
[12:00] <hrw> [   232.828] could not open default font 'fixed'
[12:01] <hrw> someone remember since when fixed font became required again?
[12:11] <RAOF> hrw: That's the new libxfont I believe.
[12:12] <hrw> RAOF: will test with precise one than
[12:13] <pitti> henrix: fixed harder now
[12:13] <pitti> henrix: ♥ that bot :)
[12:13] <henrix> pitti: thanks :)
[12:14] <hrw> RAOF: thx, kdm booted up with precise one
[12:15] <hrw> RAOF: Bug #992745 already
[12:16] <cjwatson> slangasek: stealing your dh-autoreconf merge, since it's an easy sync
[12:17]  * dupondje smiles to chrisccoulson 
[12:24] <mdeslaur> Is this a known lucid-precise upgrade issue? https://plus.google.com/104216419012637157644/posts/JFeMQRkDyPi
[12:25] <cjwatson> not one I've seen, we'd need the full logs
[12:26] <tumbleweed> bug 990740
[12:26] <cjwatson> aha
[12:26] <tumbleweed> I've just been arguing with some people in it about that issue
[12:27] <tumbleweed> (was pointed to it by an update-manager refusenik who'd hit it)
[12:29] <cjwatson> including the poster of that G+ notice.  I've followed up with directions on attaching logs
[12:29] <tumbleweed> thanks
[12:29] <cjwatson> ... twice, since I got it wrong the first time
[13:40] <vibhav> Since https://bugs.launchpad.net/ubuntu/+source/eggdrop/+bug/885329 is fixed in Debian, should I work on an SRU for oneiric or work  on quantal?
[13:41] <dupondje> first on quantal
[13:42] <vibhav> dupondje: And then a different debdiff for quantal?
[13:43] <dupondje> anyway, eggdrop is a dirty one
[13:43] <dupondje> debian doesn't have ssl
[13:43] <dupondje> we have
[13:43] <dupondje> but ssl support is unofficial patch, which is crap .... :)
[13:43] <vibhav> dupondje: I meant, do then I need to create a debdiff for a SRU as well?
[13:44] <dupondje> ofc
[13:44] <dupondje> the smaller, the better :) only with the fix
[13:44] <dupondje> for quantal you can do a merge
[13:45] <vibhav> what about onerirc?
[13:45] <vibhav> s/oneiric/precise/
[13:45] <dupondje> you could try to get that SRU'ed also
[13:45] <dupondje> but oneiric is old ;)
[13:45] <vibhav> Its still supported
[13:45] <dupondje> I really think we should drop the SSL support custom patch :)
[13:52] <infinity> dupondje: I imagine the SSL support is there specifically because some of us connect to SSL-only servers.
[13:53] <vibhav> ^
[13:54] <vibhav> Since, I am merging, should the changelog entry be "/debian/patches/foo : Merge from Debian Unstable (LP: #bugno)" ?
[13:56] <vibhav> or the description of what the patch does?
[13:58] <mvdk> Does debian intend to import the current debian tiff package?
[13:58] <ogra_> mvdk, how do you mean ?
[13:59] <mvdk> Sorry
[13:59] <mvdk> Does ubuntu intend to import the present debian tiff package into quantal?
[13:59] <ogra_> we surely sync/import whats there
[14:00] <ogra_> so if its in the debian archive it will very likely soon show up in ubuntu
[14:00] <ogra_> (quantal that is)
[14:00] <ogra_> syncing has just begun
[14:00] <mvdk> But does that happen if there's a version with "ubuntu" in the name?
[14:00] <cjwatson> Is that tiff3?
[14:01] <ogra_> then it will show up on merges.ubuntu.com (once that runs reliably again)
[14:01] <cjwatson> That's one of the ones waiting for manual review because it overwrites an *ubuntu* version.
[14:01] <mvdk> Normal tiff
[14:01] <cjwatson> That'd need a merge, then, yes.
[14:01] <dupondje> infinity: the thing is that the ssl patch is quite buggy
[14:01] <ogra_> and someone (usually the last uploader in ubuntu) will have to do a manual merge
[14:01] <cjwatson> Well, the last change was a security update, let's see
[14:02] <cjwatson> It's probably been applied in Debian too
[14:02] <cjwatson> Yeah, in 4.0.1-2
[14:02] <cjwatson> Also in tiff3 3.9.6-2
[14:03] <mvdk> BTW, when does stuff land in backports, and on what basis?
[14:03] <cjwatson> Manual request
[14:03] <mvdk> So lodge a bug
[14:03] <cjwatson> You can use the 'requestbackport' tool to help
[14:04] <cjwatson> tiff+tiff3 look good to sync, to me; I'm just going to double-check diffs and then do that
[14:04] <mvdk> It depends on jbigkit
[14:04] <cjwatson> Which is already in quantal
[14:05] <mvdk> but isn't in main
[14:05] <cjwatson> *shrug*
[14:05] <cjwatson> Having something depend on it is the usual first step anyway
[14:05] <cjwatson> It'll show up for promotion then
[14:05] <mvdk> Cool
[14:11] <cjwatson> Hm, maybe I had better file an MIR first, I guess
[14:11] <cjwatson> (jbigkit)
[14:11] <xnox> new lintian tag: maintainer-address-causes-mail-loops-or-bounces Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[14:11]  * xnox hugh?!
[14:11] <cjwatson> Don't desperately want to make tiff uninstallable
[14:13] <mvdk> Wow, hdf5 has a lot of reverse dependencies
[14:14] <xnox> mvdk: it's that good =)
[14:19] <dupondje> could somebody kill https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/3454000 ? Its stuck (running for +24h)
[14:20] <dupondje> same for https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/3456197
[14:22] <dupondje> https://launchpad.net/~damagedspline/+archive/waze-qt/+build/3455851 seems also stuck ... :)
[14:22] <dupondje> hmmz
[14:22] <cjwatson> -> #launchpad
[14:22] <dupondje> :)
[14:22] <vibhav> dupondje: ^^
[14:24] <cjwatson> mdeslaur: your tiff merge can become a sync, but bug 993304 should happen first
[14:25] <mdeslaur> cjwatson: thanks, I'll subscribe to it
[14:32] <slangasek> cjwatson: steal away :)
[14:41] <vibhav> cjwatson: Can I ask you something?
[14:47] <sladen> vibhav: I would just ask
[14:47] <sladen> vibhav: since although you can ask; it is hard to know what the answer might be without knowing the question
[14:48] <cjwatson> vibhav: what sladen said
[14:54] <vibhav> Since, I am merging, should the changelog entry be "/debian/patches/foo : Merge from Debian Unstable (LP: #bugno)" ?
[14:55] <vibhav> or the description of what the patch does?
[14:59] <tumbleweed> for a merge, the changelog entry is usually "Merge from ... (LP: #...), remaining changes" followed by all the changes that we are carrying over
[15:00] <tumbleweed> and then any other things you had to add
[15:00] <vibhav> tumbleweed: I am taking only one change from Debian though
[15:02] <tumbleweed> then that's easy
[15:03] <vibhav> So should I stil use the same syntax in the changelog?
[15:04] <tumbleweed> vibhav: do whatever you think makes sense. You'll get more feedback when a sponsor looks at it
[15:05] <tumbleweed> it's good to summarise all the ubuntu-specific changes, and everything that you are changing in this upload
[15:21] <Laney> xnox: You wanted to move that ben file up a level too.
[15:21] <xnox> Laney: ok. Will update the merge. Gotcha what 'attic' means =) s/attic/basement/?
[15:21] <xnox> =)
[15:21] <Laney> well, the other end of the house, but yes.
[15:22] <Laney> No need to update, I'm doing it
[15:22] <Laney> and adding your name so we know who to go to :P
[15:23] <Laney> .
[15:23]  * xnox =(
[15:23] <xnox> ok.
[15:24] <Laney> doesn't mean you have to do it all, but I like the idea of having a point man (unless ScottK wants to take on that role)
[15:24] <ScottK> No.
[15:24] <ScottK> (what are we talking about)
[15:24] <Laney> boost
[15:24] <apw> pitti, we have a bug come in which claims to be on quantal, but i think its all a lie, as the upgrade date is 25 days ago ... apport issue perhaps?  bug #992968
[15:25] <ScottK> If someone wants to spearhead getting the transition done, that'd be great.
[15:25] <ScottK> I'm not going to spend a lot of time on it.
[15:26] <ScottK> There's not much point in spending much time on no-change rebuilds until after DIF though.
[15:29] <xnox> Laney: i don't have upload rights, so while I can keep an eye on it, I can only file bugs/sponsorship requests.
[15:30] <Laney> that's fine
[15:30] <vibhav> dholbach: ping
[15:30] <dholbach> vibhav, pong
[15:30] <xnox> Laney: ok. good. I'll keep an eye on it.
[15:31] <tumbleweed> lots of sponsorship requests is a sure way to end up with upload rights :)
[15:32]  * xnox is noting this down.
[15:38] <apw> infinity, when one builds binary packages ... where does the description in apt-cache et al come from?  as there are essentially two control files, the one in the source package and the one in each binary run
[15:39] <cjwatson> dpkg-gencontrol builds the binary control file based on the source control file.
[15:39] <infinity> apw: It's an intersection of DEBIAN/control from the binary package (viewable with dpkg-deb -I foo.deb) and the overrides in the archive (see: /indices/ on a mirror)
[15:40] <infinity> apw: Or see Colin's answer for how DEBIAN/control is generated in the first place. :P
[15:41] <apw> cjwatson, on the buildd we rebuild the control file to get the udebs etc added, but we are saying that one isn't used in the final binaries /
[15:42] <infinity> apw: dpkg-gencontrol operates on the state of debian/control at the time you call it so, yes, re-generating it during build lets you mangle the end result.
[15:42] <infinity> apw: I think we've discussed before, though, that having debian/control in the source be incorrect/incomplete is probably a bug. :P
[15:43] <apw> infinity, heh yeah, di makes life interesting in this regard
[15:43] <infinity> (Since that influences the .dsc, and what we think we know about the source package and what binaries it produces)
[15:43] <infinity> apw: No, the kernel build system makes it interesting, not d-i. ;)
[15:44] <apw> infinity, let me restate that, kernel-wedge makes it interesting
[15:44] <infinity> I can get on board with that finger-pointing.
[15:44] <apw> infinity, but from that description I cannot right now understand why our binary packages for i386 have the wrong descriptions in them at the moment
[15:45] <infinity> apw: Oh?
[15:45] <cjwatson> Pretty sure you're just calling kernel-wedge in the wrong place, anyway :-P
[15:45] <cjwatson> It's a control file slicing tool, it has to be pointed in the right direction ...
[15:46] <apw> cjwatson, heh probabally.  i think this is something else some time with a pint and a hammer will sort it out
[15:46] <cjwatson> Given where you're calling it, there's no way it can be correct right now
[15:46] <cjwatson> No matter how clever it is
[15:46] <apw> cjwatson, indeed
[15:46] <cjwatson> But, as long as you're calling it before dpkg-gencontrol, not sure how you'd be getting wrong descriptions
[15:47] <cjwatson> How wrong?
[15:48] <apw> cjwatson, will confirm same shortly.  but i am getting a human_arch for the amd64 arch in i386 and omap builds ...
[15:49] <apw> cjwatson, which would match whats in the source package as that can only be built on one arch
[15:49] <apw> cjwatson, but in theory at least should be different on the real builders ...
[15:51] <vibhav> dholbach: You might want to check https://bugs.launchpad.net/ubuntu/+source/eggdrop/+bug/885329
[15:53] <dholbach> vibhav, can you subscribe 'ubuntu-sponsors' to the bug? this way somebody will take care of it - I'm currently in the middle of something else
[16:02] <pitti> apw: hm, that bug was filed 14 hours ago, so DistroRelease: could be true
[16:02] <pitti> apw: apport gets that directly from lsb_release
[16:03] <pitti> good night everyone!
[16:03] <apw> pitti, well the upgrade time is 15 days ago, 10 before we opened quantal
[16:06] <cjwatson> the upgrade time is often lies
[16:06] <apw> cjwatson, oh ok, then perhaps it is real
[16:06] <cjwatson> I remember working out why once; I think it always claims it's upgraded to the current release but actually quotes the last time update-manager did some particular kind of work, or something
[16:07] <vibhav> When was quantal released?
[16:07] <cjwatson> vibhav: A little over five months in the future
[16:07] <cjwatson> It was *created* on Thursday
[16:08] <vibhav> cjwatson: Then how come is the bug you are talking about is reported in 12.10?
[16:09] <cjwatson> quantal exists and is on the mirrors.  That's different from it being released
[16:10] <vibhav> Im confused
[16:11] <vibhav> Does a pre-release verion of quantal exist
[16:11] <tumbleweed> that's what we are all working on, yes
[16:11] <xnox> vibhav: http://archive.ubuntu.com/ubuntu/dists/quantal/Release
[16:11] <cjwatson> that's kind of important for us all to develop it :-)
[16:12] <xnox> vibhav: note that Version stanza already is set to 12.10 (with a lot of hope we will get there)
[16:12] <cjwatson> we don't wait until October and then throw it all over the wall in one go
[16:12] <vibhav> I see, the repos is still there
[16:12] <bdmurray> sladen: so I'll make bug 988995 a duplicate of the other one then?
[16:13] <nixternal> qotd:  [  cjwatson] we don't wait until October and then throw it all over the wall in one go
[16:13] <bdmurray> slangasek: I meant you there
[16:13] <vibhav> Its a bit like Debian unstable, right?
[16:13] <slangasek> bdmurray: yes, I think so
[16:13] <xnox> vibhav: yes. we call it ubuntu+1
[16:14] <xnox> vibhav: /j #ubuntu+1
[16:14] <cjwatson> right now it's very likely unusable
[16:14] <vibhav> xnox: I know that :)
[16:14] <cjwatson> it'll take a couple of weeks for it to settle down after the initial sync from Debian
[16:14] <Laney> xnox: http://people.canonical.com/~ubuntu-archive/transitions/boost1.49.html
[16:15]  * xnox is off to do some work =)))
[16:22] <semkox> hello
[16:23] <semkox> how can i see all my apps in ubuntu 12,04?
[16:26] <xnox> barry: http://people.canonical.com/~ubuntu-archive/transitions/dh-python2.html
[16:26] <xnox> barry: similar to ^ can we have a transition tracker for python3-only on the cd
[16:27] <tumbleweed> I don't know how useful that transition tracker is...
[16:27] <xnox> cause the test is .depends python3*
[16:27] <xnox> but we need to cook up the 'affected' packages.
[16:27] <xnox> or do we need to test 'ubuntu-transition-tracker' what a package set is.
[16:28] <xnox> barry: you said you already had a script to generate all required dependencies which need transition?
[16:28] <xnox> tumbleweed: that was just an example.
[16:28] <tumbleweed> you could have a tracker for packages building python3 modules, but I don't know how useful it would be either
[16:29] <xnox> tumbleweed: limited to those that are required/installed on the live-cd.
[16:30] <xnox> well, let's wait for barry to tell us how https://docs.google.com/spreadsheet/ccc?key=0AiT4gOXSkmapdFA1anRkWERsaXgtWnllUG9QWXhDVWc#gid=0 is generated currently.
[16:30] <tumbleweed> Laney: is that doable? I'm guessing it means a (regex|of|package|names} ?
[16:31] <Laney> you can enumerate, sure
[16:31] <tumbleweed> xnox: the dh_python2 transitions (for CD images) was handled by an enormous bug that people edited the description of
[16:32]  * xnox =((((
[16:32] <tumbleweed> yeah :)
[16:32] <xnox> surely we should be able to limit candidates by: seed or package task
[16:33] <tumbleweed> Task should be doable, but it doesn't match with seeding-on-CDs that tightly
[16:36] <xnox> tumbleweed: don't we already have the bzr-branch into which the expansion of seeds gets commited (as in package names)
[16:37] <xnox> could be a suitable hack as to which candidates to consider (sure it will be out of sync but it will be better than 'task' and closer to 'seeding-on-CDs')
[16:37] <cjwatson> seed expansions don't get committed to bzr
[16:38] <cjwatson> I guess I feel transitions are more useful for things where we can realistically transition the entire archive in a single cycle - i.e. make it all go green
[16:39] <infinity> Speaking of.
[16:39] <infinity> libjpg, anyway?
[16:39] <infinity> s/anyway/anyone/
[16:39]  * infinity kicks his fingers.
[16:39] <infinity> Err, png?
[16:39]  * infinity also kicks his brain.
[16:39] <infinity> I need more coffee this morning.
[16:39] <xnox> cjwatson: ok. but python3 on cds is a more/less realistic transition this cycle (?!)
[16:40] <cjwatson> hopefully, but certainly not for the whole archive
[16:44] <xnox> cjohnston: hence the tracker should limit '.is_affected' to those that are on the cd's.
[16:44] <barry> xnox: initial list is generated by oncd.py from lp:~barry/+junk/pydeps
[16:44] <xnox> looks like we have an expansion at: http://qa.ubuntuwire.org/ubuntu-seeded-pack%E2%80%90ages/seeded.json.gz
[16:44] <xnox> barry: ok thanks.
[16:44] <xnox> what are your thoughts to have an archive tracker for python3 transition?
[16:44] <cjwatson> xnox: well, if *you* fancy hacking the ocaml ;-)
[16:45] <barry> xnox: it would be great
[17:17] <slangasek> bdmurray: bug #993147> hadn't we suppressed this before?
[17:19] <bdmurray> slangasek: I don't think so
[18:21] <bryceh> hmm, when I go to http://cdimage.ubuntu.com/releases/12.04/release/ and then click on 64-bit Mac (AMD64) desktop CD (the first link on the page), it takes me to an error page
[18:21] <bryceh> "Access Denied"
[18:23] <ScottK> bryceh: Where is the current tutorial for "X got wedged on my Intel system, but I can SSH in and want to get enough information for a useful bug report."?
[18:23] <jussi> bryceh: that works for me...
[18:24] <bryceh> ScottK, do you mean https://wiki.ubuntu.com/X/Troubleshooting/Freeze ?
[18:25] <ScottK> bryceh: That looks like it.  Thanks.
[19:01] <valavanisalex> Hi All, quick packaging query: window fonts in grace have been broken since the xorg metapackage dropped its dependency on xfonts-100dpi and xfonts-75dpi (bug #705202).  Is it reasonable to add them as recommendations in grace?  The Debian maintainer wasn't particularly keen.
[19:32] <valavanisalex> Repost from 20:01: Hi All, quick packaging query: window fonts in grace have been broken since the xorg metapackage dropped its dependency on xfonts-100dpi and xfonts-75dpi (bug #705202).  Is it reasonable to add them as recommendations in grace?  The Debian maintainer wasn't particularly keen.
[19:33] <slangasek> valavanisalex: Recommends don't handle the fact that X is a client-server architecture; clearly any package that cares about xfonts-100dpi or xfonts-75dpi is using server-side fonts, and should really be updated to use client-side fonts
[19:33] <slangasek> (which is how all modern apps work)
[19:34] <slangasek> it may be better than nothing, though
[19:36] <slangasek> barry, cjwatson: I'd appreciate a native english review of https://code.launchpad.net/~vorlon/ubuntu/precise/resolvconf/lp.989585/+merge/103958 - I want to get that SRUed ASAP but should not be my own editor :)
[19:38] <barry>  slangasek: this one reads a little awkward to me:
[19:38] <barry> +"The immutable flag on /etc/resolv.conf will be removed now, and the current "
[19:38] <barry> 81	+"file will be moved to /etc/resolvconf/resolv.conf.d/original.  If these "
[19:38] <barry> 82	+"contents include static resolver configuration, it is recommended that you "
[19:38] <barry> 83	+"copy these to /etc/resolvconf/resolv.conf.d/head."
[19:39] <barry> specifically "If these contents..."
[19:39] <slangasek> barry: thanks :) suggestions for improvement?  "If the contents of this file"?
[19:39] <barry> slangasek: too many "these"ses :)
[19:40] <slangasek> or "If the original file contained [...]"
[19:40] <barry> slangasek: how about: "If the contents of this file includes static resolver configuration values, it is recommended you copy the values to [...]."
[19:40] <barry> slangasek: actually "recommended that you"
[19:41] <slangasek> barry: is that better than http://paste.ubuntu.com/963052/ ?
[19:41] <slangasek> possibly with a s/this/it/
[19:42] <barry> slangasek: well the problem is that i don't know what "this" reverse to, i.e. the file or the contents
[19:42] <valavanisalex> slangasek: Thanks, I'll see if I can figure out how to improve the font handling in grace.  Not really something I know about though!
[19:42] <barry> uh, "this" refers to
[19:42] <barry> slangasek: so s/copy this/copy the file/ perhaps ?  (or is it copy the contents? :)
[19:46] <slangasek> Dear power company!  That's not how power works
[19:47] <slangasek> barry: sorry, I missed anything you might have said after <slangasek> possibly with a s/this/it/
[19:48] <barry> slangasek: the problem is that i don't know what "this" refers to, i.e. the file or the contents.  so maybe s/copy this/copy the file/ perhaps?  (or is it /copy the contents/ ?)
[19:48] <slangasek> well... either works in practice - but I take your point
[19:48] <slangasek> copy the file wfm
[19:49] <barry> cool, other than that it looks good
[19:49] <slangasek> ok - thanks for the eyeballs
[19:49] <hallyn> hm, gnulib fails to build on q?  https://launchpadlibrarian.net/103905666/buildlog_ubuntu-quantal-i386.libvirt_0.9.8-2ubuntu18_FAILEDTOBUILD.txt.gz
[19:49] <slangasek> hallyn: yes, a bad test that's not safe under -Werror=format-security
[19:49] <hallyn> admittedly it's very old, i need to merge with the debian version
[19:49] <hallyn> drat
[19:50] <slangasek> hallyn: you can pluck a patch for this out of coreutils
[19:50] <slangasek> (it's not upstreamed to gnulib yet)
[19:50] <slangasek> oh, actually, that's a different failure
[19:50] <slangasek> so... *after* upgrading to current gnulib, you can grab the patch from coreutils ;)
[19:50] <hallyn> heh
[19:51] <hallyn> ok i guess i need to first do the merge and see how close to current gnulib that gets me
[19:51] <hallyn> thanks
[20:22] <dupondje> nice merge slangasek ! :)
[20:22] <slangasek> horrid, horrid merge
[20:22] <slangasek> nasty filthy merge
[20:23] <dupondje> Its over now :)
[20:23] <tumbleweed> until next time...
[20:25] <ajmitch> it'd been awhile since that was merged?
[20:26] <dupondje> its really tempting to upgrade to quantal :P
[20:26] <slangasek> ajmitch: yeah... was meant to happen for precise but slipped off the radar
[20:37] <mdeslaur> slangasek: my apologies for not having done that one in a while...I still have some numbness in my extremities from doing the last one
[20:40] <slangasek> mdeslaur: :)
[21:00] <barry> anybody know much about htlatex and friends?  i'm getting local build failures with pyopenssl which uses htlatex to build its docs.  the failures are mysterious ;)
[21:11] <slangasek> barry: that's part of the texlive mess infinity was working on?
[21:12] <barry> slangasek: i wasn't aware of that.  very well could be as even the precise version is no longer buildable on quantal (i.e. what quantal has now).
[21:12] <slangasek> right
[21:12] <barry> slangasek: i was trying to merge the latest from debian plus add the py3 packaging stuff
[21:13] <slangasek> couldn't tell you though if it's actually a bug in the tex side though, or if it's pyopenssl needing updating
[21:13] <barry> slangasek: do you know if infinity's work is resolved or still in progress?
[21:14] <slangasek> I do not
[21:15] <barry> slangasek: so i have three options: 1) wait until that's resolved, pinging infinity into infinity until it is <wink>; 2) temporarily disable the -doc package build and upload what i've got for now; 3) revert the debian quilt patch that switches from using latex2html (which still appears to work) to htlatex.  the problem with #3 is that latex2html isn't in main
[21:17] <slangasek> barry: hmm, and htlatex is?  I don't see any package by that name
[21:18] <slangasek> tex4ht?
[21:19] <barry> slangasek: yep
[21:19] <slangasek> barry: pyopenssl is also the only package in main that wants tex4ht... so you could probably swap 'em without too much trouble if you wanted
[21:20] <slangasek> latex2html has no other deps, as a MIR
[21:20] <barry> slangasek: not sure why sandro made that change for debian, but if it's not unreasonable for us to revert it, i think it would be idea.  more delta from debian, less from upstream
[21:21] <slangasek> yeah, I think that's not unreasonable
[21:21] <barry> slangasek: i'll double check but i'm pretty sure the build works fine with the upstream original
[21:21] <barry> slangasek: cool, thanks
[22:03] <kees> has anyone looked at klibc's "kinit" going into the initramfs?
[22:07] <DebolazST> When I try to install indicator-messages from source on my system, the menu I get when I click on the icon becomes empty. Do I need to do anything special other than --prefix=/usr to install it properly on my system?
[22:27] <slangasek> kees: I don't think so - what's that useful for?
[22:28] <kees> slangasek: I'm staring at http://git.kernel.org/?p=libs/klibc/klibc.git;a=blob;f=usr/kinit/capabilities.c;h=eab4d937af1f6e5c22af277537be980bcdc1f9b6;hb=ff0a614bd724f6c4c6a5014a9955dc1bc028f336 and not wanting to reimplement it for initramfs-tools
[22:28] <broder> slangasek: would you take a patch to pam_motd to update the /var/run/motd file even if PAM_SILENT is set?
[22:30] <slangasek> kees: so the initramfs would exec kinit, which would chain to the initramfs init?  or the other way around?
[22:31] <slangasek> broder: that's to make sure it gets refreshed for the next time, even if it's not displayed now?
[22:31] <broder> slangasek: yep. it'd put it in line with what, e.g., pam_lastlog does
[22:31] <slangasek> broder: yeah, that sounds sane
[22:32] <broder> slangasek: cool. i'll put something together then
[22:32] <kees> slangasek: I'm not really sure how kinit would get swapped into the initramfs. that's why I was asking. :)
[22:33] <infinity> kees: Getting it in is easy, the question is how it would be used...
[22:34] <kees> infinity: yeah. I don't really understand what it's supposed to do
[22:35] <infinity> That makes two of us.
[22:36] <infinity> [klibc] kinit: replacement for in-kernel do_mount, ipconfig, nfsroot
[22:36] <slangasek> I'm assuming it's for chainloading
[22:36] <slangasek> ah
[22:36] <slangasek> or not :)
[22:36] <infinity> That seems to explain it fairly well in a single line.
[22:37] <infinity> Seems like the intent was to tear the root mounting code out of the kernel completely, but that never happened.
[22:37] <infinity> And, hey, it's only been 6+ years.
[23:33] <TheMuso> Oh wow, armel is being rolled back to armv5t? Interesting.
[23:33] <TheMuso> for quantal...
[23:34] <TheMuso> ...unless I misread.
[23:35] <infinity> TheMuso: It's all in your head, you saw nothing.
[23:35] <slangasek> TheMuso: it's entirely speculative at this point; it's just as likely that we'll drop armel entirely, but *if* it's going to be kept, it's only interesting if it supports different hardware than armhf
[23:36] <TheMuso> Right, I was wondering about that too, makes sense.
[23:36] <TheMuso> infinity: I never see anything anyway. :p