=== imbrando1 is now known as imbrandon === bdmurray_ is now known as bdmurray [01:14] 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:14] Launchpad bug 990742 in openldap (Ubuntu) "slapd fails to upgrade: requires libsasl2-2 (>= 2.1.24) installed" [High,Triaged] https://launchpad.net/bugs/990742 [01:34] 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] 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] 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] Good morning [05:25] hi pitti === Amoz_ is now known as Amoz === dupondje_ is now known as dupondje [06:40] good morning === smb` is now known as smb === mthaddon` is now known as mthaddon [07:58] Good Morning! =) [08:08] debootstrap --variant=minbase is the absolute minimal system which is capable of proper installs with apt-get/dpkg, right? [08:23] sveinse: yes [08:23] That's Priority: required + apt [08:24] my sweet valgrind, why you don't run with X-forwarding :( === hrww is now known as hrw [08:31] pitti: hi! I have this bunch of kernel pkgs copied into the wrong component... could you take a look at this? [08:31] henrix: I'm already at it [08:31] pitti: cool, thanks [08:31] which component makes the 'when lid is closed, suspend, when power is critically low' etc ? is that gnome-settings-daemon ? [08:31] henrix: RAOF copied the kernels this time, and we wanted to try whether the +queue page works for overriding [08:31] apw: yes, g-s-d does the policy decisions, upower is the d-bus backend to actually "do" the actions [08:33] 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] pitti: I thought it was well-known that it doesn't :-) [08:33] now I do :) [08:34] so this is still a situation where only a person with cocoplum access can do the copying [08:35] 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] 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] I'm not sure whether the copying requires ~ubuntu-archive privileges, but it might not [08:37] Copying shouldn't [08:37] but anyway, fixing components needs an archive admin [08:37] pitti, oh hmmm though the component overrides are an issue, but could we cron those perhaps [08:37] They won't be sanely cronnable yet; maybe after I APIify overrides [08:37] but yes i assume anyone with upload rights for those package ought to be able to copy them [08:37] apw: at least you could do all the copies which don't involve ABI bumps [08:37] apw: right [08:38] apw: so if you want, you can try running copy-proposed-kernel.py when the next kernel is ready [08:40] 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] apw: no, they don't; they will be in unapproved just as regular kernel syncs [08:40] s/syncs/copies from PPA/ (they appear as "sync" on +queue) [08:41] apw: copies with binary packages from PPAs evades NEW [08:41] ahh i see [08:41] they are auto-accepted into universe [08:41] (which is the whole problem -- on the NEW +queue page we could override them to main) [08:41] ahh, poop, i see [08:44] is there an LP bug about that? [08:44] it should determine NEWness relative to the archive being copied into, IMO [08:44] * pitti looks [08:46] I can't find one [08:46] I'll file one [08:47] thanks [08:49] apw, cjwatson: Filed as bug 993120, sub'ed kernel and SRU teams [08:49] Launchpad bug 993120 in Launchpad itself "Copy from PPA with binaries evades NEW and puts new packages into universe" [Undecided,New] https://launchpad.net/bugs/993120 [08:51] 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:51] Launchpad bug 828649 in Launchpad itself "queue UI: apparently no way to override individual binaries" [Low,Triaged] https://launchpad.net/bugs/828649 [08:52] cjwatson: yes, but in all releases since natty we can do that [08:52] sure [08:52] for lucid there are still some binaries which are in universe, and those still need manual overriding [08:52] that's why I'm so insistant on having all binaries in main, as it makes the biweekly processing so much easier [08:53] 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] though I do hope to lift this restriction soon as part of API exposure [08:53] right, but that's a general limitation of the +queue page [08:54] for that, and for general component-mismatches we'll still need a lplib api for changing overrides, of course [08:54] yep, on its way [08:54] it is? great! [08:54] I've been working on it for a while, though shelved it for release [08:54] thinking about it, change-override.py is 90% of why I'm logging into cocoplum [08:55] the other 10% is manual diffs for large packages when the automatic diff is wrong or doesn't exist [08:55] 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] but that's not a principal limitation, and is possible on the client-side too [08:56] yep, will do; I think I read that page a while ago already, it came up on some ML [08:56] yep [08:57] oh, and lp-remove-package.py, of course (but that's also covered already) [08:58] indeed === Guest77193 is now known as yofel === yofel is now known as Guest53016 === Guest53016 is now known as yofel_ [09:24] * cjwatson runs out of obvious morning archive admin work to do. Is it really the beginning of the cycle? :-) [09:25] (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] removals? :-) [09:28] caught up on those too, at least those since 2012-04-01 [09:29] I think I got most of the earlier ones pre-release [09:29] 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] https://bugs.launchpad.net/launchpad/+bug/362957 [09:29] Launchpad bug 362957 in Launchpad itself "Ridiculous unicode transliteration on -changes announce list From: header" [Low,Triaged] [09:29] ah, good [09:29] though that's not quite the same bug; similar [09:30] yeah, not the same [09:30] * tumbleweed files a new one [09:31] meh, the ppa builders are quite buzzy atm. === lool- is now known as lool [09:44] 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] geser: only the relatively recent ones; happy to go back and look again, roughly what date were those removals done in Debian? [09:47] cjwatson: tcpquota: 2010-07-01 and the last two 2012-02 [09:48] wow, that's odd [09:48] old [09:51] going through tumbleweed's neglected package list I found one package more: "libnode-vargs" (2012-02-02) [09:59] tcpquota never showed up in the ftpmaster removals list [10:00] removing it manually now [10:02] libmoosex-chainedaccessors-perl has an rdepends: libhtml-formfu-perl, waiting for that to build first [10:02] (new version that drops the depends) [10:05] cradle rdepends channel-server, which claimed to be replaced by a package called "buddycloud-server" which has never made it to testing [10:06] though to be fair neither did channel-server, so I guess it doesn't lose anything === Tonio__ is now known as Tonio_ [10:07] this is the kind of reason packages don't get removed at the time :-) [10:08] libnode-vargs is in the same cluster [10:08] synced buddycloud-server, I'll see if that manages to build [10:08] geser: for future such cases, probably best to just file bugs, as they may well need analysis like this [10:18] 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] you can assume at this point that anything before about April isn't going to get removed automatically [10:19] if there's a bit of duplication, well, shrug [10:20] ok [10:26] pitti: sorry to bother again, but it looks like we have a few more pkgs landing on the wrong place === ikonia_ is now known as ikonia [10:37] 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] I see that quantal got nice set of upgrades ;) [10:42] pitti: have you had to use sru-release on cocoplum at all since we switched to the async copy method? [10:43] cjwatson: no, never; this is rock solid [10:43] can I nuke it then? [10:43] please do [10:44] 22 bottles of beer on the wall [10:45] pitti: also, does anything still use sru-pending on cocoplum? that looks kind of obsolete [10:46] cjwatson: indeed it is -- 21 bottles! [10:46] * cjwatson nukes [10:46] slowly but surely [10:47] those ubuntu-mozilla-daily ppa builds eat all resources [10:47] bastards! [10:48] * pitti waves with the CoC [10:50] 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] (ie, bisecting 4 days of commits as opposed to 1) [10:53] you should get a dedicated buildbox ;) [10:53] i'd like that! [10:54] 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] (I'd do it myself but I don't know if you want to do a more general packaging merge) [10:55] on my list, but not now [10:55] sure === doko_ is now known as doko === chuck_ is now known as zul === joink_ is now known as joink === jbicha is now known as Guest36751 [11:28] chrisccoulson: https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/3454000 [11:28] its stuck ? [11:28] Started 2012-05-01 [11:32] 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] most things will work fine; you'll get some tedious warnings if you chroot into it with locale environment variables set [11:33] you don't need to generate locales if you leave the locale environment set to C [12:00] [ 232.828] could not open default font 'fixed' [12:01] someone remember since when fixed font became required again? [12:11] hrw: That's the new libxfont I believe. [12:12] RAOF: will test with precise one than [12:13] henrix: fixed harder now [12:13] henrix: ♥ that bot :) [12:13] pitti: thanks :) [12:14] RAOF: thx, kdm booted up with precise one [12:15] RAOF: Bug #992745 already [12:15] Launchpad bug 992745 in libxfont (Ubuntu) "X doesn't load in Quantal, downgrading libxfont1 to Precise version fixes it" [Critical,Triaged] https://launchpad.net/bugs/992745 [12:16] slangasek: stealing your dh-autoreconf merge, since it's an easy sync [12:17] * dupondje smiles to chrisccoulson [12:24] Is this a known lucid-precise upgrade issue? https://plus.google.com/104216419012637157644/posts/JFeMQRkDyPi [12:25] not one I've seen, we'd need the full logs [12:26] bug 990740 [12:26] Launchpad bug 990740 in python-defaults (Ubuntu) "upgrading from lucid to precise fails" [Undecided,Confirmed] https://launchpad.net/bugs/990740 [12:26] aha [12:26] I've just been arguing with some people in it about that issue [12:27] (was pointed to it by an update-manager refusenik who'd hit it) [12:29] including the poster of that G+ notice. I've followed up with directions on attaching logs [12:29] thanks [12:29] ... twice, since I got it wrong the first time === _salem is now known as salem_ === dpm is now known as dpm-afk === dendroba` is now known as dendrobates === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [13:40] 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:40] Launchpad bug 885329 in eggdrop (Ubuntu Oneiric) "eggdrop crash on i386" [Undecided,Confirmed] [13:41] first on quantal [13:42] dupondje: And then a different debdiff for quantal? [13:43] anyway, eggdrop is a dirty one [13:43] debian doesn't have ssl [13:43] we have [13:43] but ssl support is unofficial patch, which is crap .... :) [13:43] dupondje: I meant, do then I need to create a debdiff for a SRU as well? === dendrobates is now known as dendro-afk [13:44] ofc [13:44] the smaller, the better :) only with the fix [13:44] for quantal you can do a merge [13:45] what about onerirc? [13:45] s/oneiric/precise/ [13:45] you could try to get that SRU'ed also [13:45] but oneiric is old ;) [13:45] Its still supported [13:45] I really think we should drop the SSL support custom patch :) [13:52] dupondje: I imagine the SSL support is there specifically because some of us connect to SSL-only servers. [13:53] ^ [13:54] Since, I am merging, should the changelog entry be "/debian/patches/foo : Merge from Debian Unstable (LP: #bugno)" ? [13:56] or the description of what the patch does? [13:58] Does debian intend to import the current debian tiff package? [13:58] mvdk, how do you mean ? [13:59] Sorry [13:59] Does ubuntu intend to import the present debian tiff package into quantal? [13:59] we surely sync/import whats there [14:00] so if its in the debian archive it will very likely soon show up in ubuntu [14:00] (quantal that is) [14:00] syncing has just begun [14:00] But does that happen if there's a version with "ubuntu" in the name? [14:00] Is that tiff3? [14:01] then it will show up on merges.ubuntu.com (once that runs reliably again) [14:01] That's one of the ones waiting for manual review because it overwrites an *ubuntu* version. [14:01] Normal tiff [14:01] That'd need a merge, then, yes. [14:01] infinity: the thing is that the ssl patch is quite buggy [14:01] and someone (usually the last uploader in ubuntu) will have to do a manual merge [14:01] Well, the last change was a security update, let's see [14:02] It's probably been applied in Debian too [14:02] Yeah, in 4.0.1-2 [14:02] Also in tiff3 3.9.6-2 [14:03] BTW, when does stuff land in backports, and on what basis? [14:03] Manual request [14:03] So lodge a bug [14:03] You can use the 'requestbackport' tool to help [14:04] tiff+tiff3 look good to sync, to me; I'm just going to double-check diffs and then do that [14:04] It depends on jbigkit [14:04] Which is already in quantal [14:05] but isn't in main [14:05] *shrug* [14:05] Having something depend on it is the usual first step anyway [14:05] It'll show up for promotion then [14:05] Cool === sforshee` is now known as sforshee [14:11] Hm, maybe I had better file an MIR first, I guess [14:11] (jbigkit) [14:11] new lintian tag: maintainer-address-causes-mail-loops-or-bounces Ubuntu Core Developers [14:11] * xnox hugh?! [14:11] Don't desperately want to make tiff uninstallable === agateau is now known as zagateau [14:13] Wow, hdf5 has a lot of reverse dependencies [14:14] mvdk: it's that good =) === zagateau is now known as agateau [14:19] could somebody kill https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/3454000 ? Its stuck (running for +24h) [14:20] same for https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/3456197 [14:22] https://launchpad.net/~damagedspline/+archive/waze-qt/+build/3455851 seems also stuck ... :) [14:22] hmmz [14:22] -> #launchpad [14:22] :) [14:22] dupondje: ^^ [14:24] mdeslaur: your tiff merge can become a sync, but bug 993304 should happen first [14:24] Launchpad bug 993304 in jbigkit (Ubuntu) "[MIR] jbigkit" [Undecided,New] https://launchpad.net/bugs/993304 [14:25] cjwatson: thanks, I'll subscribe to it === dpm-afk is now known as dpm [14:32] cjwatson: steal away :) [14:41] cjwatson: Can I ask you something? [14:47] vibhav: I would just ask [14:47] vibhav: since although you can ask; it is hard to know what the answer might be without knowing the question [14:48] vibhav: what sladen said === txwikinger2 is now known as txwikinger === cmagina_ is now known as cmagina === imbrandon is now known as imbrandon2 [14:54] Since, I am merging, should the changelog entry be "/debian/patches/foo : Merge from Debian Unstable (LP: #bugno)" ? [14:55] or the description of what the patch does? [14:59] 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] and then any other things you had to add [15:00] tumbleweed: I am taking only one change from Debian though [15:02] then that's easy [15:03] So should I stil use the same syntax in the changelog? [15:04] vibhav: do whatever you think makes sense. You'll get more feedback when a sponsor looks at it [15:05] it's good to summarise all the ubuntu-specific changes, and everything that you are changing in this upload [15:21] xnox: You wanted to move that ben file up a level too. [15:21] Laney: ok. Will update the merge. Gotcha what 'attic' means =) s/attic/basement/? [15:21] =) [15:21] well, the other end of the house, but yes. [15:22] No need to update, I'm doing it [15:22] and adding your name so we know who to go to :P [15:23] . [15:23] * xnox =( [15:23] ok. [15:24] 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] No. [15:24] (what are we talking about) [15:24] boost [15:24] 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:24] Launchpad bug 992968 in linux (Ubuntu) "Large file transfer to Sandisk Cruzer 8GB USB hangs for a long time" [Medium,New] https://launchpad.net/bugs/992968 [15:25] If someone wants to spearhead getting the transition done, that'd be great. [15:25] I'm not going to spend a lot of time on it. [15:26] There's not much point in spending much time on no-change rebuilds until after DIF though. === Chipzz_ is now known as Chipzz [15:29] 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] that's fine [15:30] dholbach: ping [15:30] vibhav, pong [15:30] Laney: ok. good. I'll keep an eye on it. [15:31] lots of sponsorship requests is a sure way to end up with upload rights :) [15:32] * xnox is noting this down. [15:38] 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] dpkg-gencontrol builds the binary control file based on the source control file. [15:39] 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] apw: Or see Colin's answer for how DEBIAN/control is generated in the first place. :P [15:41] 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] 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] 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] infinity, heh yeah, di makes life interesting in this regard [15:43] (Since that influences the .dsc, and what we think we know about the source package and what binaries it produces) [15:43] apw: No, the kernel build system makes it interesting, not d-i. ;) [15:44] infinity, let me restate that, kernel-wedge makes it interesting [15:44] I can get on board with that finger-pointing. [15:44] 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] apw: Oh? [15:45] Pretty sure you're just calling kernel-wedge in the wrong place, anyway :-P [15:45] It's a control file slicing tool, it has to be pointed in the right direction ... [15:46] cjwatson, heh probabally. i think this is something else some time with a pint and a hammer will sort it out [15:46] Given where you're calling it, there's no way it can be correct right now [15:46] No matter how clever it is [15:46] cjwatson, indeed [15:46] But, as long as you're calling it before dpkg-gencontrol, not sure how you'd be getting wrong descriptions [15:47] How wrong? [15:48] cjwatson, will confirm same shortly. but i am getting a human_arch for the amd64 arch in i386 and omap builds ... [15:49] cjwatson, which would match whats in the source package as that can only be built on one arch [15:49] cjwatson, but in theory at least should be different on the real builders ... [15:51] dholbach: You might want to check https://bugs.launchpad.net/ubuntu/+source/eggdrop/+bug/885329 [15:51] Launchpad bug 885329 in eggdrop (Ubuntu Oneiric) "eggdrop crash on i386" [Undecided,Confirmed] [15:53] 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] apw: hm, that bug was filed 14 hours ago, so DistroRelease: could be true [16:02] apw: apport gets that directly from lsb_release [16:03] good night everyone! [16:03] pitti, well the upgrade time is 15 days ago, 10 before we opened quantal [16:06] the upgrade time is often lies [16:06] cjwatson, oh ok, then perhaps it is real [16:06] 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] When was quantal released? [16:07] vibhav: A little over five months in the future [16:07] It was *created* on Thursday [16:08] cjwatson: Then how come is the bug you are talking about is reported in 12.10? [16:09] quantal exists and is on the mirrors. That's different from it being released [16:10] Im confused [16:11] Does a pre-release verion of quantal exist [16:11] that's what we are all working on, yes [16:11] vibhav: http://archive.ubuntu.com/ubuntu/dists/quantal/Release [16:11] that's kind of important for us all to develop it :-) [16:12] vibhav: note that Version stanza already is set to 12.10 (with a lot of hope we will get there) [16:12] we don't wait until October and then throw it all over the wall in one go [16:12] I see, the repos is still there [16:12] sladen: so I'll make bug 988995 a duplicate of the other one then? [16:12] Launchpad bug 988995 in whoopsie-daisy (Ubuntu) "package whoopsie 0.1.32 failed to install/upgrade: el subproceso instalado el script post-installation devolvió el código de salida de error 1" [Undecided,Confirmed] https://launchpad.net/bugs/988995 [16:13] qotd: [ cjwatson] we don't wait until October and then throw it all over the wall in one go [16:13] slangasek: I meant you there [16:13] Its a bit like Debian unstable, right? [16:13] bdmurray: yes, I think so [16:13] vibhav: yes. we call it ubuntu+1 [16:14] vibhav: /j #ubuntu+1 [16:14] right now it's very likely unusable [16:14] xnox: I know that :) [16:14] it'll take a couple of weeks for it to settle down after the initial sync from Debian [16:14] xnox: http://people.canonical.com/~ubuntu-archive/transitions/boost1.49.html [16:15] * xnox is off to do some work =))) === cnd` is now known as cnd [16:22] hello === nxvl_ is now known as nxvl [16:23] how can i see all my apps in ubuntu 12,04? [16:26] barry: http://people.canonical.com/~ubuntu-archive/transitions/dh-python2.html [16:26] barry: similar to ^ can we have a transition tracker for python3-only on the cd [16:27] I don't know how useful that transition tracker is... [16:27] cause the test is .depends python3* [16:27] but we need to cook up the 'affected' packages. [16:27] or do we need to test 'ubuntu-transition-tracker' what a package set is. [16:28] barry: you said you already had a script to generate all required dependencies which need transition? [16:28] tumbleweed: that was just an example. [16:28] you could have a tracker for packages building python3 modules, but I don't know how useful it would be either [16:29] tumbleweed: limited to those that are required/installed on the live-cd. [16:30] 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] Laney: is that doable? I'm guessing it means a (regex|of|package|names} ? [16:31] you can enumerate, sure [16:31] 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] yeah :) [16:32] surely we should be able to limit candidates by: seed or package task [16:33] Task should be doable, but it doesn't match with seeding-on-CDs that tightly [16:36] tumbleweed: don't we already have the bzr-branch into which the expansion of seeds gets commited (as in package names) [16:37] 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] seed expansions don't get committed to bzr === deryck is now known as deryck[lunch] [16:38] 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] Speaking of. [16:39] libjpg, anyway? [16:39] s/anyway/anyone/ [16:39] * infinity kicks his fingers. [16:39] Err, png? [16:39] * infinity also kicks his brain. [16:39] I need more coffee this morning. [16:39] cjwatson: ok. but python3 on cds is a more/less realistic transition this cycle (?!) [16:40] hopefully, but certainly not for the whole archive [16:44] cjohnston: hence the tracker should limit '.is_affected' to those that are on the cd's. [16:44] xnox: initial list is generated by oncd.py from lp:~barry/+junk/pydeps [16:44] looks like we have an expansion at: http://qa.ubuntuwire.org/ubuntu-seeded-pack%E2%80%90ages/seeded.json.gz [16:44] barry: ok thanks. [16:44] what are your thoughts to have an archive tracker for python3 transition? [16:44] xnox: well, if *you* fancy hacking the ocaml ;-) [16:45] xnox: it would be great [17:17] bdmurray: bug #993147> hadn't we suppressed this before? [17:17] Launchpad bug 993147 in grub (Ubuntu) "package linux-image-3.2.0-24-generic 3.2.0-24.38 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/993147 [17:19] slangasek: I don't think so === deryck[lunch] is now known as deryck === yofel_ is now known as yofel [18:21] 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] "Access Denied" [18:23] 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] bryceh: that works for me... [18:24] ScottK, do you mean https://wiki.ubuntu.com/X/Troubleshooting/Freeze ? [18:25] bryceh: That looks like it. Thanks. === dendro-afk is now known as dendrobates [19: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:01] Launchpad bug 705202 in grace (Ubuntu) "xmgrace window font is not loaded correctly" [Low,Triaged] https://launchpad.net/bugs/705202 === dendrobates is now known as dendro-afk [19:32] 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:32] Launchpad bug 705202 in grace (Ubuntu) "xmgrace window font is not loaded correctly" [Low,Triaged] https://launchpad.net/bugs/705202 [19:33] 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] (which is how all modern apps work) [19:34] it may be better than nothing, though [19:36] 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] slangasek: this one reads a little awkward to me: [19:38] +"The immutable flag on /etc/resolv.conf will be removed now, and the current " [19:38] 81 +"file will be moved to /etc/resolvconf/resolv.conf.d/original. If these " [19:38] 82 +"contents include static resolver configuration, it is recommended that you " [19:38] 83 +"copy these to /etc/resolvconf/resolv.conf.d/head." [19:39] specifically "If these contents..." [19:39] barry: thanks :) suggestions for improvement? "If the contents of this file"? [19:39] slangasek: too many "these"ses :) [19:40] or "If the original file contained [...]" [19:40] slangasek: how about: "If the contents of this file includes static resolver configuration values, it is recommended you copy the values to [...]." [19:40] slangasek: actually "recommended that you" [19:41] barry: is that better than http://paste.ubuntu.com/963052/ ? [19:41] possibly with a s/this/it/ [19:42] slangasek: well the problem is that i don't know what "this" reverse to, i.e. the file or the contents [19:42] 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] uh, "this" refers to [19:42] slangasek: so s/copy this/copy the file/ perhaps ? (or is it copy the contents? :) === slangase` is now known as slangasek [19:46] Dear power company! That's not how power works [19:47] barry: sorry, I missed anything you might have said after possibly with a s/this/it/ [19:48] 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] well... either works in practice - but I take your point [19:48] copy the file wfm [19:49] cool, other than that it looks good [19:49] ok - thanks for the eyeballs [19:49] 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] hallyn: yes, a bad test that's not safe under -Werror=format-security [19:49] admittedly it's very old, i need to merge with the debian version [19:49] drat [19:50] hallyn: you can pluck a patch for this out of coreutils [19:50] (it's not upstreamed to gnulib yet) [19:50] oh, actually, that's a different failure [19:50] so... *after* upgrading to current gnulib, you can grab the patch from coreutils ;) [19:50] heh [19:51] ok i guess i need to first do the merge and see how close to current gnulib that gets me [19:51] thanks [20:22] nice merge slangasek ! :) [20:22] horrid, horrid merge [20:22] nasty filthy merge [20:23] Its over now :) [20:23] until next time... [20:25] it'd been awhile since that was merged? [20:26] its really tempting to upgrade to quantal :P [20:26] ajmitch: yeah... was meant to happen for precise but slipped off the radar [20:37] 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 === dendro-afk is now known as dendrobates [20:40] mdeslaur: :) [21:00] 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 ;) === dendrobates is now known as dendro-afk [21:11] barry: that's part of the texlive mess infinity was working on? [21:12] 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] right [21:12] slangasek: i was trying to merge the latest from debian plus add the py3 packaging stuff [21:13] 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] slangasek: do you know if infinity's work is resolved or still in progress? [21:14] I do not [21:15] slangasek: so i have three options: 1) wait until that's resolved, pinging infinity into infinity until it is ; 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] barry: hmm, and htlatex is? I don't see any package by that name [21:18] tex4ht? [21:19] slangasek: yep [21:19] 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] latex2html has no other deps, as a MIR [21:20] 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] yeah, I think that's not unreasonable [21:21] slangasek: i'll double check but i'm pretty sure the build works fine with the upstream original [21:21] slangasek: cool, thanks === salem_ is now known as _salem [22:03] has anyone looked at klibc's "kinit" going into the initramfs? [22:07] 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] kees: I don't think so - what's that useful for? [22:28] 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] slangasek: would you take a patch to pam_motd to update the /var/run/motd file even if PAM_SILENT is set? [22:30] kees: so the initramfs would exec kinit, which would chain to the initramfs init? or the other way around? [22:31] broder: that's to make sure it gets refreshed for the next time, even if it's not displayed now? [22:31] slangasek: yep. it'd put it in line with what, e.g., pam_lastlog does [22:31] broder: yeah, that sounds sane [22:32] slangasek: cool. i'll put something together then [22:32] slangasek: I'm not really sure how kinit would get swapped into the initramfs. that's why I was asking. :) [22:33] kees: Getting it in is easy, the question is how it would be used... [22:34] infinity: yeah. I don't really understand what it's supposed to do [22:35] That makes two of us. [22:36] [klibc] kinit: replacement for in-kernel do_mount, ipconfig, nfsroot [22:36] I'm assuming it's for chainloading [22:36] ah [22:36] or not :) [22:36] That seems to explain it fairly well in a single line. [22:37] Seems like the intent was to tear the root mounting code out of the kernel completely, but that never happened. [22:37] And, hey, it's only been 6+ years. [23:33] Oh wow, armel is being rolled back to armv5t? Interesting. [23:33] for quantal... [23:34] ...unless I misread. [23:35] TheMuso: It's all in your head, you saw nothing. [23:35] 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] Right, I was wondering about that too, makes sense. [23:36] infinity: I never see anything anyway. :p === jbicha is now known as Guest99314 === Guest99314 is now known as jbicha1