[01:31] <bryceh> cjwatson, nope, hadn't looked at the ubuntu-devel@ queue today
[01:35] <bryceh> slangasek, you about?
[01:35] <slangasek> bryceh: only for a second more
[01:36] <bryceh> slangasek, that xvfb issue with pygtk is actually a fakeroot bug, fixed in debian 1.17-1
[01:36] <bryceh> bug 829470
[01:36] <slangasek> oh, interesting
[01:37] <bryceh> slangasek, it's same as bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630591 in debian
[01:37] <slangasek> right, let me sync that
[01:37] <bryceh> awesome
[04:04] <DoctorPepper> hi guys !!!
[04:05] <DoctorPepper> as of today  does ubuntu support  systemd as an init system  without having to recompile the kernel  for cgroups support ?
[04:10] <RAOF> DoctorPepper: cgroups are enabled in the kernel, and I guess we've probably got Debian's systemd packages in the archive.
[04:11] <DoctorPepper> thanks
[04:12] <DoctorPepper> is the maintainer of appmenu  in here ?
[04:13] <pitti> Good morning
[04:13] <DoctorPepper> pitti:  good morning
[04:15] <pitti> slangasek: 832454> I understand how it is frustrating :/ indeed it seems we have lots of missing ddebs for these
[04:15] <pitti> now if only we had proper LP ddebs integration, the current hack has never been meant to even last that long :(
[04:15] <pitti> hey DoctorPepper
[04:16] <pitti> I just checked the ddeb-retriever, it's not stuck or anything
[04:16] <pitti> but it might be that some of the buildds are acting up, /me runs manually
[04:16] <pitti> sometimes the buildds time out when you try to talk to them, for several days
[04:17] <pitti> if it happens for more than two days, we lose ddebs
[04:37] <slangasek> RAOF: systemd isn't in the archive, and we definitely don't support it as an init system
[04:37] <slangasek> pitti: LP ddebs - yes, please :)
[04:38] <RAOF> slangasek: Oh, I certainly didn't mean to imply we would go so far as to *support* it; we've gone to the effort of blacklisting the sync, though?
[04:38] <slangasek> RAOF: you cannot run systemd as an init system on Ubuntu
[04:38] <slangasek> for whichever meaning of "support" you wish :)
[04:39] <RAOF> Just out of curiosity, what prevents that?
[04:39] <slangasek> the fact that all of our startup is done with native upstart jobs
[04:39] <pitti> I actually had a 10.10 system running with the systemd PPA packages
[04:39] <RAOF> I mean, apart from the bunch of packages that have native upstart scripts.
[04:39] <pitti> that PPA has a package to provide some missing ones
[04:39] <slangasek> that bunch of packages is pretty much the default Ubuntu install :)
[04:40] <RAOF> Ah.  Just the bunch of packages with native upstart scripts?  Oh, things like mountall probably don't get systemded, either.
[04:40] <pitti> RAOF: mountall isn't necessary with systemd
[04:40] <RAOF> So, as long as you rewrote a bunch of init scripts, it'd work :)
[04:40] <pitti> actually, most of the early startup is already done by systemd itself
[04:41] <pitti> the scary thing is that it sucks in more and more of the boot/system services stuff
[04:41] <pitti> it's like a "liblinux" now
[04:41] <pitti> so it doesn't require (and doesn't actually allow) a lot of configuration or script tweaking
[04:41] <pitti> which makes it easy for trying out, but rather hard as an admin to customize
[04:45]  * slangasek nods
[06:03] <sgnb> infinity: type-conv needs to be rebuilt as well
[06:22] <infinity> sgnb: I noticed that, due to the dep-wait.  Building now.
[06:26] <infinity> sgnb: The segv on powerpc in https://launchpadlibrarian.net/78022053/buildlog_ubuntu-oneiric-powerpc.ocaml-extunix_0.0.3-1build1_FAILEDTOBUILD.txt.gz is disconcerting.
[06:27]  * infinity retries to see if it was cosmic rays.
[06:27] <nigelb> Or an unfortunate alignment of the planets ;)
[06:27] <infinity> Moon phase, etc, yes.
[06:36] <sgnb> infinity: it happens also in Debian, see http://caml.inria.fr/mantis/view.php?id=5334
[06:37] <sgnb> I'm planning to disable this test on armel and powerpc
[06:38] <infinity> sgnb: Disabling the test seems like the wrong fix. :P
[06:40] <sgnb> infinity: feel free to submit a proper fix
[06:41] <sgnb> backtrace() seems an esoteric feature enough to me
[06:42] <sgnb> (I mean, for exotic architectures such as powerpc)
[06:42] <infinity> sgnb: PowerPC isn't that exotic. :P
[06:42] <infinity> sgnb: But I also have no interest in fixing it, so.. :)
[06:59] <sgnb> infinity: ocaml-data-notation failed because of type-conv
[07:04] <infinity> sgnb: I know. :)
[07:04] <infinity> sgnb: Waiting for the type-conv binaries to be published and I'll retry it.
[07:07] <infinity> sgnb: Any interest in feeding me a fixed ocaml-extunix?
[07:09] <sgnb> I'll upload one to Debian... but it's not urgent (no reverse-dependencies)
[07:09] <infinity> Shiny.  That's what I needed to know.
[07:09] <infinity> Just poke me to sync it sometime, then.
[07:20] <dholbach> good morning
[07:37] <makara> if I install Ocelot Alpha, will the automatic updates bring it up to the full release in October, or will I have to download that CD again?
[07:43] <infinity> makara: -> #ubuntu
[07:43] <makara> k
[09:53] <doko> pitti, sqlite ping ...
[09:53] <pitti> doko: pong
[09:53] <pitti> --verbose?
[09:54] <doko> pitti: what is left to demote it?
[09:54]  * pitti checkrdepends
[09:55] <pitti> -- oneiric/main amd64 deps on libsqlite0:
[09:55] <pitti> php5-sqlite
[09:55] <pitti> -- oneiric/main build deps on libsqlite0-dev:
[09:55] <pitti> bacula
[09:55] <pitti> libdbi-drivers
[09:56] <pitti> doko: nothing in main depends on php5-sqlite except for php5-dbg
[09:56] <pitti> so in theory it could be split out of the source
[09:57] <pitti> Bacula looks weird, it b-deps on both libsqlite0-dev and libsqlite3-dev
[09:57] <pitti> Daviey: ^ do you guys still care about bacula?
[09:57] <pitti> if not, perhaps it could just be demoted?
[09:58] <pitti> libdbi-drivers presumably needs it to build libdbd-sqlite, but it also builds libdbd-sqlite3
[09:58] <zyga> mvo: hi
[09:59] <mvo> hey zyga
[09:59] <doko> well, that could be built in universe too
[09:59] <zyga> mvo: I started merging a few patches and hit a wall with broken i18n support
[09:59] <zyga> mvo: would you mind looking at https://code.launchpad.net/~zkrynicki/command-not-found/rework-locale-support/+merge/72848
[09:59] <zyga> mvo: this is my attempt to fix them
[10:00] <pitti> doko: frankly, I'd just drop it from dbi-drivers
[10:00] <pitti> doko: libdbd-sqlite has exactly one rdepends in universe
[10:00] <pitti> interchange-cat-standard
[10:00] <pitti> which has alternative dependencies
[10:00] <mvo> zyga: sure, I will do after lunch
[10:01] <zyga> mvo: thanks
[10:02] <pitti> doko: so, I think the hardest one is php5-sqlite
[10:02] <pitti> dbi-drivers is easy to fix, and for bacula it should be possible to drop the b-dep (let's see whether server team still cares)
[10:19] <doko> pitti, sounds like a plan
[10:24] <Daviey> pitti: Where are you seeing bacula showing up?  I don't see it on c-m's?
[10:31] <pitti> Daviey: it doesn't show up in reports, we'd just like to get rid of sqlite for good
[10:31] <Daviey> pitti: but keep sqlite3?
[10:32] <pitti> yes
[10:32] <Daviey> pitti: Super,  Yes - i am happy for Bacula to be demoted.  It's not recieving the attention it probably deserves.
[10:34] <Daviey> times like this popcon by default for devel release would be handy to find out if anyone has actually tried it!
[10:35] <seb128> ev, do you know if anyone is working on updating the ubiquity slideshow for oneiric?
[10:37] <cjwatson> 11:12 <CIA-18> ubiquity-slideshow-ubuntu: evand * r360 ubiquity-slideshow-ubuntu/ (12 files in 12 dirs): Bump version strings to 11.10.
[10:37] <cjwatson> 11:16 <CIA-18> ubiquity-slideshow-ubuntu: evand * r361 ubiquity-slideshow-ubuntu/debian/changelog: releasing version 41
[10:38] <seb128> cjwatson, right, still it lists evolution as being our email client
[10:39] <seb128> cjwatson, that's this upload which made me think about it ;-) I noticed recently the content was still not updated
[11:00] <wildfire> hi, who can do a stable release update request for bug #817119 ?
[11:08] <wildfire> who is able to update https://wiki.ubuntu.com/StableReleaseUpdates to indicate that 'mere mortals' can not nominate a bug for SRU
[11:08] <wildfire> apparently it is an immutable page
[11:08] <pitti> wildfire: everyone can nominate
[11:09] <wildfire> pitti: no they can not
[11:09] <pitti> well, only few people can actually accept the task
[11:09] <wildfire> please see: https://answers.launchpad.net/launchpad/+question/140509
[11:09] <pitti> maybe nomination is limited as well
[11:10] <pitti> actually that's good news -- nominations are fairly useless
[11:10] <wildfire> pitti: well, good news for developers, I guess
[11:10] <wildfire> frustrating for users
[11:11] <wildfire> particularly when the process is described so throughly, and is so throughly wrong
[11:11] <pitti> not any more frustrating than nominating it and then never see anything happen
[11:11] <pitti> merely asking "I want this fixed" isn't magically going to make it happen
[11:12] <pitti> but in general, subscribing ubuntu-sru with an explanation why this is SRU worthy also works, and doesn't need nomination
[11:12] <pitti> or even better, uploading a fix :)
[11:12] <pitti> wildfire: that page isn't wrong, though -- developers can nominate
[11:14] <wildfire> pitti: I did not realise that the page was geared towards developers, I believed it was geared towards the people actually taking the time to report a bug and then hearing it has been fixed in a later version -- and that if the reporter wanted the bug fixed in that stable version, that was the process to follow
[11:14] <wildfire> pitti: care to update it to clarify that the audience is people who are both bug reporters and developers?
[11:14] <pitti> no, perhaps this should be clarified then
[11:15] <pitti> this is for people who want to do an SRU, not like to see a bug fixed
[11:15] <pitti> do you have a proposal how to clarify this?
[11:15] <pitti> e. g. append "This page describes the process for developers." to the first paragraph?
[11:24] <poolie> o/ wildfire
[11:26] <wildfire> pitti, poolie: I'd have: "If you would like to request a SRU and you are not a developer, please follow the procedure outlined at StabelReleaseUpdateRequest. This page documents the process for developers completing SRU requests."
[11:26] <poolie> good idea
[11:26] <wildfire> You can make the SRURequest page a blank wiki link and it can be filled in later on
[11:27] <poolie> there has been a lot of churn in the past because with so many users to developers any popular bug will get requests, regardless of feasibility or availability of effort to do it
[11:27] <pitti> well, there's not much to write there -- find a developer to fix it
[11:27] <poolie> as pitti says people just saying "i want this fixed"
[11:29] <wildfire> poolie, pitti: is the issue that the requests are invalid, or there is not enough time / developers to do it?
[11:30] <wildfire> I think there are different ways to address things depending on what is the main problem with requests
[11:30] <wildfire> if the former, you can suggest that a 'power user' (perhaps an MOTU? althougth aiui they don't exist anymore), should nominate things
[11:30] <StevenK> MOTU do still exist
[11:31] <wildfire> if the later, make triaging an SRU request part of the application process
[11:31] <wildfire> StevenK: OK, good to know - I was under the impression with fine-grained upload permissions, that someone who could upload an package into 'universe' or 'multiverse' was a thing of the past
[11:33] <poolie> in this case obviously there is an apparently working fix for it
[11:34] <poolie> if they make a merge proposal into the relevant branch that should fix it off
[11:34] <poolie> wildfire: i think the issue (which doesn't apply to this bug in particular) in general is a bit of both
[11:34] <pitti> wildfire: MOTUs are in the ubuntu-bugcontrol team and can nominate, yes
[11:35] <geser> wildfire: as 'universe' and 'multiverse' still exist we need MOTU to take care of it and even after that we need MOTU to take care of the packages that nobody takes care of
[11:35] <janimo> is Keybuk around this channel these days? Alternately is there any other public venue I can ping him on?
[11:35] <pitti> janimo: in principle yes, but only scarcely
[11:35] <janimo> I have ureadahead related questions but would rather not mail him personally
[11:35] <pitti> janimo: during European evening/Californian day mostly
[11:36] <pitti> janimo: mail should work fine
[11:36] <janimo> pitti, thanks, I'll keep an eye on him showing up :)
[11:36] <pitti> cjwatson: argh, just got a reject for my libivgraimpex upload
[11:36] <pitti> cjwatson: anyway, thanks for fixing it, too!
[11:37] <pitti> seems the bug assignment had a mid-air collision in LP
[11:37] <wildfire> poolie: maybe there should be a 'good SRU nominator' flag for people who consistently suggest good candidates for SRUs?
[11:38] <poolie> that's an interesting idea
[11:38] <poolie> or maybe more generally people who can't upload but who can be trusted to triage
[11:38] <poolie> (or is that already ~ubuntu-bugcontrol?)
[11:39] <poolie> perhaps ideally it would go off (a much better version of) karma
[11:39] <pitti> if these people could also dig out the corresponding patches, that'd help a lot
[11:40] <pitti> ScottK: oh, that was fast :)
[11:40] <pitti> Daviey: do you have an opinion on bug 833684?
[11:40] <pitti> Daviey: if you are fine with it, I can go ahead and do the syncs now
[11:41] <pitti> (and add the remaining package tasks to track the rdepends)
[12:02] <Daviey> pitti: comment added, TL;DR +1.
[12:12] <cjwatson> pitti: ah, heh, oh well
[12:12] <cjwatson> pitti: same fix? :)
[12:12] <pitti> yeah
[12:30] <cjwatson> directhex: bug 803978 - how about mono-uia, which depends on mono-debugger?
[12:30] <directhex> cjwatson, mono-uia depends on other things which are gone from mono. and the team behind it was laid off. Laney, didn't we file an RM request on uia*?
[12:31] <Laney> no
[12:31] <Laney> ray was/is hoping to resurrect it
[12:31] <Laney> but if removed, it can always be reintroduced
[12:32] <cjwatson> want to add a mono-uia task to that bug, then?
[12:33] <pitti> doko, Daviey: I'm touching bacula anyway for psql 9.1; while I'm at it, I'll also drop bacula-director-sqlite (no rdepends) and the sqlite2 dep
[12:33] <pitti> bacula-director-sqlite is a migration package, and we have carried it long enough (it's in lucid)
[12:34] <pitti> so there's an upgrade path
[12:34] <doko> \o/
[12:35] <Daviey> pitti: why didn't we drop it post lucid?
[12:35] <pitti> Daviey: I don't know
[12:35] <pitti> well, we do now
[12:38] <Daviey> We do a crappy job at transitional package planning :)
[12:39] <Daviey> I have NFI what ones we can drop after the next LTS.
[12:39] <pitti> well, in most cases it doesn't really hurt to have them around longer than necessary
[12:39] <pitti> but we stumble over them when we try to remove cruft
[12:42] <Daviey> I still wonder how many people installed mysql-server-5.X directly rather than mysql-server, and lost their upgrade path.
[12:44] <nigelb> Daviey: dear god.
[12:44] <nigelb> we're supposed to isntall mysql-server?
[12:44] <Daviey> nigelb: shutt'it
[12:45]  * nigelb always did 5.X
[12:45] <nigelb> :(
[12:46] <tseliot> pitti: can you approve nvidia-graphics-drivers-96 in bug #741930 and nvidia-common in bug #825259 (both in natty-proposed), please? (I did what RAOF and slangasek requested)
[13:02] <ximion> hi! I'm currently working on bug 831271 , an FTBFS because of multiarch-support...
[13:02] <ximion> why does debhelper install the library into multiarch paths even if this packages does NOT enable multiarch?
[13:02] <pitti> Daviey, doko: bacula uploaded, sqlite2 -= 1
[13:03] <pitti> doko: php5 looks strange -- it only b-deps on libsqlite3-dev, not on 0-dev, and yet php5-sqlite binary-depends on it
[13:03] <Daviey> pitti: \o/
[13:16] <debfx> ximion: qmake installs the libraries into the multiarch path
[13:22] <ximion> debfx: good to know... I'm converting this package to multiarch right now, so this problem should go away
[13:22] <ximion> is this qmake change an upstream change or a Debian change?
[13:23] <ximion> if it's Debian, it would have been nice if it would've been activated on multiarch packages only.
[13:23] <ximion> I guess this package is not the only one which FTBFS now
[13:25] <tseliot> pitti: ^^^
[13:25] <pitti> tseliot: erm, what, qmake, what?
[13:26] <tseliot> pitti: I wrote you about my packages in natty-proposed
[13:26] <tseliot> pitti: (at 02:46)
[13:27] <tseliot> pitti: or I can copy and paste the message if you prefer
[13:27] <pitti> tseliot: hm, here? I don't see it
[13:27] <pitti> tseliot: if you can re-paste in /msg, that'd be appreciated
[13:27] <tseliot> pitti: can you approve nvidia-graphics-drivers-96 in bug #741930 and nvidia-common in bug #825259 (both in natty-proposed), please? (I did what RAOF and slangasek requested)
[13:28] <tseliot> oh, sorry, you said in /msg
[13:28] <pitti> tseliot: yep, I'll get to it; doing SRU review right now
[13:28] <tseliot> pitti: great, thanks
[13:30] <pitti> mterry: rejecting your p-distutils-extra SRU, no bug ref in changelog
[13:31] <pitti> mterry: you can reupload with -v to include the previous chagnelog
[13:31] <mterry> pitti, ah, whoops.  OK
[13:36] <pitti> tseliot: why was the debconf bit disabled?
[13:40] <pitti> SpamapS: FYI, can't accept mdadm natty-proposed; it's already in -proposed, and bug 778520 is v-failed
[13:41] <tseliot> pitti: because there can be nasty interactions when dist-upgrading and it's obsolete anyway
[13:41] <pitti> tseliot: ok
[13:48] <debfx> ximion: it's a configure option of Qt
[13:48] <debfx> ximion: Debian hasn't converted Qt for multiarch (yet)
[13:50] <ximion> debfx: ah, okay :)
[14:01] <SpamapS> pitti: oops I forgot to mention that the new upload actually fixes the regression that caused 778520 to fail
[14:02] <pitti> SpamapS: ah, can you then please reupload with -v to include the previous changelog?
[14:02] <pitti> SpamapS: I rejected your current upload, so you can re-use the version number
[14:02] <SpamapS> pitti: sure, I thought that was only necessary if it had actually been removed.
[14:03] <pitti> SpamapS: no, it needs to have all chagnelogs which have been piling up in -proposed until it gets into -updates
[14:09] <SpamapS> pitti: alright, re-uploaded with full changelog
[14:15] <mterry> ev, you around?  I think the recent live cd problems are ubiquity problems
[14:19] <ev> mterry: which ones, specifically?
[14:20] <mterry> ev, sorry, the one where X doesn't come up
[14:20] <mterry> ev, seems to be a gir problem in ubiquity-dm
[14:20] <mterry> GdkPixbuf.render_pixmap_and_mask isn't being found
[14:21] <ev> ah indeed, that's definitely on my list
[14:21] <ev> just sorting out the unicode issues in usersetup and friends first
[14:22] <cjwatson> mterry: bug 830892
[14:22] <cjwatson> (dup, but it has my first non-working sketch at a fix ...)
[14:23] <mdeslaur> slangasek, infinity: does this look sane to you? http://paste.ubuntu.com/674544/
[14:24] <seb128> ev, btw it's probably on your list as well but you still use gconf keys which are deprecated rather than gsettings
[14:25] <seb128> just saying it as a reminder, it will create bugs for proxy and things like that if you rely on gconf
[14:25] <ev> okay, thanks for the reminder
[14:26] <mterry> cjwatson, thanks!
[14:27] <shnatsel> Hi everybody! I'm making an Ubuntu derivative and I'm trying to generate dependency lists using Germinate. All existing seed-based packages are limited to Ubuntu repositories; is there a way to make Germinate use several repositories, e.g. Ubuntu + PPAs?
[14:29] <shnatsel> s/all existing packages/all the packages I could find/
[14:32] <shnatsel> I couldn't find any docs about such things, and all the examples use Ubuntu repositories only
[14:34] <mterry> shnatsel, I really feel like it is possible.  I think I've done it before, but that was a long time ao
[14:35] <mterry> shnatsel, I don't remember details or where to point you, so that's useless info, sorry  :-/
[14:39] <doko> Daviey, will nova reach main before the beta freeze?
[14:40] <shnatsel> that looks like bug 571793 also
[14:41] <Daviey> doko: no
[14:41] <shnatsel> Ah, I've found the format but bug 634831 will kill my attempts anyway
[14:41] <Daviey> doko: Well.. unless python-carrot can be thrown in main just to be demoted when a bug we are blocked on is satisifed.
[14:42] <Daviey> Or, just c-m stick on python-carrot.. either way
[14:54] <cjwatson> shnatsel: oh, yeah, I was going to deal with that for Oneiric
[14:55] <ahasenack> how do I get a verbose debian/rules file nowadays? dh_make just creates that two liner one now (%:\n\tdh $@)
[14:55] <shnatsel> cjwatson: so, when can one expect the patch to land?
[14:55] <cjwatson> shnatsel: over the next week or so
[14:55] <azeem> ahasenack: the longer templates are still in the dh_make package I think
[14:56] <cjwatson> ahasenack: dh_make -r old, but why would you want to ...
[14:56] <ahasenack> azeem: dpkg -L dh-make | grep rules only gave me the short ones
[14:56] <shnatsel> cjwatson: great, thanks! It's blocking all the fun in elementary OS ISO testing atm :(
[14:56] <shnatsel> (luckily we have Glimpse)
[14:56] <ahasenack> cjwatson: I need to customize this build a lot
[14:57] <ahasenack> I have 3 setup.py scripts I have to call, and produce 3 binary packages
[14:57] <ahasenack> hmm, no such option -r
[14:57] <ahasenack> I'm on lucid
[14:58] <ahasenack> hmm, wait
[14:58] <ahasenack> -r, --createorig
[14:58] <ahasenack> doesn't sound related
[14:58] <shnatsel> and`:
[14:58] <shnatsel> sorry
[14:59] <shnatsel> ahasenack: I assume you want to get a list of all the actions taken by debhelper and override some of them with custom ones, right?
[14:59] <ahasenack> shnatsel: right, but it's not just override, I need to insert more actions in the middle
[15:00] <ahasenack> shnatsel: so when overriding, I actually want to preserve what was there already and just add new things
[15:00] <shnatsel> ahasenack: in such cases I usually override the action with itself and some added stuff
[15:00] <ahasenack> shnatsel: like dh_install_override: (stuff), but how to call the original dh_install?
[15:01] <cjwatson> this is documented ...
[15:01] <cjwatson> man dh
[15:01] <cjwatson> YM override_dh_install: and then you can just call dh_install, it won't infinite-recurse
[15:02] <ahasenack> ok, that was a bad (simple) example
[15:02] <ahasenack> what about binary-indep:
[15:02] <ahasenack> it expands into a whole lot of dh_* commands
[15:02] <cjwatson> you don't override binary-indep en masse
[15:02] <cjwatson> you override individual ones
[15:02] <shnatsel> ahasenack: --before and --after ?
[15:03] <cjwatson> those are deprecated
[15:03] <shnatsel> oh, I have an outdated man, sorry
[15:03] <ahasenack> exactly, so I need to know the individual ones
[15:03] <shnatsel> ahasenack: that's documented
[15:03] <cjwatson> sure, but that's easy ...
[15:03] <cjwatson> and you normally only need to override the ones that are relevant to your package
[15:03] <shnatsel> To see what commands are included in a sequence, without actually doing
[15:03] <shnatsel>        anything:
[15:03] <shnatsel>                dh binary-arch --no-act
[15:03] <ahasenack> shnatsel: that's why I wanted a template rules file with this filled in already
[15:04] <cjwatson> shnatsel: http://packages.qa.debian.org/d/debhelper/news/20110806T234709Z.html
[15:05] <cjwatson> ahasenack: I'm definitely not saying it's always easy, and there are cases where using the minimal rules file is more effort than it's worth; so far your case doesn't sound like one of those, though
[15:06] <ahasenack> cjwatson: I need to basically loop over three setup.py, located in three different directories. For some reason, upstream chose to have everything in one branch, but they distribute 3 separate tarballs
[15:06] <ahasenack> cjwatson: and I want to build from this branch
[15:06] <cjwatson> so override dh_auto_build and dh_auto_install
[15:06] <cjwatson> that's all it takes to do that
[15:07] <ahasenack> cjwatson: ok,I will see what other actions dh_auto_build and dh_auto_install do, so I can preserve them where appropriate and insert my own
[15:07] <shnatsel> gtg; cjwatson, thanks for your help!
[15:08] <cjwatson> dh_auto_build is a generic per-buildsystem equivalent of 'make' and dh_auto_install is a generic equivalent of 'make install'
[15:09] <cjwatson> if you still want a better dh_make then it might be worth just grabbing the dh-make package from oneiric
[15:11] <ahasenack> I guess I need to look at an example with multiple binary packages and just using overrides in rules
[15:11] <ahasenack> no "expanded" rules file
[15:12] <dholbach> pitti, does the work item tracker add bugs that are linked to blueprints as work items?
[15:12] <apw> ogasawara, just a heads up i've just discovered we didn't make a WI for reviewing compcache and family; came up cause its also not working as is.  Have added a new WI on delta-review for it
[15:12] <ogasawara> apw: ack
[15:12] <apw> bah wrong channel
[15:14] <cjwatson> ahasenack: in roughly ascending order of complexity from my own packages: libpipeline, putty, groff (I'm afraid I have no python ones to show you off the top of my head, but python-ness and multi-binary-ness are pretty orthogonal really)
[15:16] <ahasenack> cjwatson: ok, and you control which file goes into which package with <package>.install files
[15:17] <cjwatson> right, generally
[15:17] <ahasenack> no need for -p <package> command line option to some dh_* tool
[15:17] <ahasenack> but if there is, then you would need to put that in the rules file somewhere
[15:17] <cjwatson> occasionally you need those, but I find it's best to regard that as exceptional
[15:18] <ahasenack> I guess I was looking at older packages, I saw -p being used and thought I would need that and didn't look at <package>,install files
[15:19] <ahasenack> cjwatson: thanks, that helps
[15:20] <ahasenack> putty is "expanded" already
[15:20] <cjwatson> not in oneiric
[15:20] <cjwatson> you should take all my references as referring to the most current version, not whatever's in lucid
[15:20] <ahasenack> ah, right, sorry :)
[15:21] <cjwatson> http://anonscm.debian.org/loggerhead/pkg-ssh/putty/trunk/annotate/head:/debian/rules
[15:24] <ahasenack> cjwatson: looks much simpler indeed
[15:25] <pitti> dholbach: yes
[15:25] <ahasenack> cjwatson: I looked at this the other day and panicked: http://bazaar.launchpad.net/~therve/twisted/debian/view/head:/rules
[15:26] <ahasenack> maybe it's possible to build that with just overrides, maybe not
[15:26] <cjwatson> yeah, I wouldn't have picked twisted as an example myself :)
[15:26] <cjwatson> I would expect rather a lot of that could disappear if modernised
[15:27] <ahasenack> cool, hopefully one day I'll know enough to do that :)
[15:27] <cjwatson> it is possible to build anything with just overrides; I'm pretty certain they're formally equivalent
[15:27] <slangasek> pitti: php5 has a FTBFS I can't reproduce locally, preventing the binary sqlite0 dep being dropped
[15:27] <cjwatson> in some cases it produces something that's longer / harder to read than the original, and so isn't worth it; I don't *think* twisted would be such a case but I'd have to try it to be sure of that
[15:28] <pitti> slangasek: ah, thanks for the info
[15:28] <cjwatson> switching d-i from long-form files to dh7 was a vast improvement in readability in almost all cases, because now the rules files only described what was unusual
[15:28] <slangasek> pitti: sure - guesses as to the cause of the FTBFS are welcome...
[15:29] <tgardner> so whats the story on this? Its kind of got my desktop hosed.
[15:29] <tgardner> The following packages have unmet dependencies:
[15:29] <tgardner>  ubuntu-desktop : Depends: unity but it is not going to be installed
[15:29] <tgardner>                   Depends: unity-2d but it is not going to be installed
[15:29] <tgardner> E: Unable to correct problems, you have held broken packages.
[15:30] <seb128> tgardner, don't use dist-upgrade without reading what it wants to do
[15:32] <tgardner> seb128, with the torrent of package updates daily, I'm unlikely to notice. the basic question, though, is why unity is uninstallable ?
[15:34] <seb128> tgardner, use upgrade instead of distr-upgrade or read what it wants to uninstall before saying yes
[15:34] <seb128> tgardner, because nux is abi instable and unity needs to be updated in the same upgrade run when there is a nux update
[15:35] <cjwatson> http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html unity isn't uninstallable right now but unity-2d is
[15:35] <seb128> tgardner, unity needs the new nux to build though so during the nux is built and unity is building you get those issues
[15:35] <seb128> cjwatson, yeah, cf #ubuntu-release ;-)
[15:35] <seb128> unity-2d needs either a no change update or a ffe for the new version
[15:35] <andy753421> Could I trouble someone in ubuntu-sponsors to finish a sync request for me for launchpad bugs 832611, 832613, and 832614?
[15:35] <seb128> that's being worked
[15:36] <cjwatson> Sweetshark: can openoffice.org-l10n-be-by and openoffice.org-l10n-ns be removed from their source package?  their dependencies are uninstallable and I think removed
[15:36] <tgardner> seb128, hrmph. I think I'll just go away and wait until its unf*cked.
[15:36] <andy753421> The feature freeze was approved, so i think it just need to be synced? (sorry for the last minute rush)
[15:36] <seb128> tgardner, you can get the unity debs on https://launchpad.net/ubuntu/+source/unity/4.10.0-0ubuntu1
[15:40] <slangasek> mdeslaur: I would suggest not changing the debconf template names / var dir names as part of the transition (that way, previously-answered cache values can be reused); the "debconf" dependency should be replaced with ${misc:Depends} (noticed because you've dropped the | debconf-2.0 from the hand-written dep, which is incorrect); you seem to have dropped the versioned dependencies on libnss3-1d and libnspr4-0d, which were presumably there
[15:40] <slangasek> ... reason; I think the Conflicts/Replaces on flashplugin-installer should be Breaks/Replaces (per policy); flashplugin-installer shouldn't be Multi-Arch: same (i386 and amd64 packages shouldn't be co-installable); prerm has some dead update-rc.d code that can be dropped, there is no flashplugin-downloader init script to clean up
[15:41] <slangasek> mdeslaur: that's it, just minor issues
[15:44] <mdeslaur> slangasek: the versioned deps on libnss3-1d and libnspr4-0d were for versions older than any release we support. Why can't debconf-2.0 be removed?
[15:46] <cjwatson> because sooner or later we will manage to switch to cdebconf, and anything without | debconf-2.0 will impede that
[15:46] <slangasek> mdeslaur: debconf-2.0 is the virtual package refering to the debconf *interface* in use; there are two packages in the archive implementing it, debconf and cdebconf, and what cjwatson said
[15:46] <cjwatson> we went to all that effort to add it to everything ...
[15:46] <cjwatson> I agree, just use ${misc:Depends}
[15:47] <mdeslaur> oh! ok, I see
[15:47] <Sweetshark> cjwatson: *sigh* does that have to be prebeta?
[15:49] <cjwatson> Sweetshark: I don't *think* so, although it's possible it will necessitate some annoying workarounds
[15:49] <cjwatson> but it needs to be done for release
[15:49] <mdeslaur> slangasek: do you'd keep installing everything in the /*/share/flashplugin-installer directories?
[15:49] <mdeslaur> s/do/so/
[15:49] <Sweetshark> cjwatson: wont be a problem till the release
[15:53] <cjwatson> Sweetshark: thanks
[15:54] <cjwatson> Sweetshark: I think there are a few others too - check http://people.canonical.com/~ubuntu-archive/nbs.html
[15:55] <slangasek> mdeslaur: if you keep the same directories for /var, we can reuse the existing debconf settings with minimal work; I think that's more important than having consistency in the directory names under /var, but I don't feel too strongly about this
[15:56] <mdeslaur> slangasek: no, I agree now that I've thought about it. Thanks for your review!
[15:56] <slangasek> mdeslaur: actually, I would change the /var/lib and /usr/lib directory names to match the current package name - it's only /var/cache that gets referenced in the debconf question
[15:56] <slangasek> mdeslaur: no problem :)
[15:58] <mdeslaur> slangasek: nspluginwrapper has some special case handling for /*/lib/flashplugin-installer, so I'll keep it as-is for now
[15:58] <Laney> cjwatson: added tasks to bug 803978
[15:58] <slangasek> mdeslaur: ah, ok
[15:58] <apw> pitti, i wonder if you'd have a few mins to review an initramfs-tools fix to fix up our utterly broke compcache support and switch it to zram drive: https://code.launchpad.net/~apw/ubuntu/oneiric/initramfs-tools/compcache-zram
[15:58] <Laney> we'll be coming up with some more removals soon to complete the transition
[15:58] <Laney> also db4o is NEW if you fancy it
[16:00] <apw> (pitti of course that would not be something we'd want uploaded before b1 is out)
[16:06]  * ahasenack -> lunch
[16:07] <doko> siretart, x264 ping
[16:11] <Laney> all punted to -archive except for nlog removal which is coming up
[16:22] <mdeslaur> slangasek, infinity: flashplugin-nonfree uploaded. thanks!
[16:23] <Daviey> Does this mean we can all have glorious flash agin?
[16:23] <Daviey> again?
[16:24] <ion> FSVO glorious
[16:28] <siretart> doko: hi
[16:57] <infinity> mdeslaur: New binary accepted.  Please submit it to rigorous upgrade testing.  Pretty please? :)
[16:58] <mdeslaur> infinity: I tested it before uploading
[16:58] <infinity> mdeslaur: I assumed.
[17:09] <slangasek> mdeslaur: thanks for taking care of it :)
[17:27] <mdz> kees, Keybuk, pitti, will you be attending techboard in 30 minutes?
[17:27] <mdz> (cjwatson and sabdfl sent apologies already)
[17:32] <sgnb> infinity: you can sync ocaml-extunix from sid now
[17:45] <pitti> mdz: yes
[17:46] <pitti> mdz: who is chairing today?
[17:47] <mdz> pitti, I am
[17:56] <ScottK> slangasek: I have this feeling https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+build/2697906/+files/buildlog_ubuntu-oneiric-i386.korundum_4%3A4.7.0-0ubuntu1_FAILEDTOBUILD.txt.gz is multiarch related.  I'd appreciate any hints you might have to offer.
[17:58] <slangasek> ScottK: has akonadi been rebuilt yet for multiarched qt?  It embeds paths in its cmake files, so at minimum needs a no-change rebuild
[17:59] <slangasek> (debfx commented the other day that he'd like to fix this "properly" in cmake, but that's a tall order)
[17:59] <slangasek> ah yes, you did that rebuild on the 18th
[18:00] <ScottK> slangasek: Yep.
[18:00] <slangasek> could be the same problem in another library further up the stack.  libsoprano, probably?
[18:00] <ScottK> I'll try it.
[18:13] <shbk> does anybody have experience with compiling of modules for kernel?   I've described problem detailed here : http://gekannt.narod2.ru/       .thanks in advance
[18:13] <pitti> drat, ubiquity seems to silently crash with new pygobject
[18:14] <pitti> ev: ^ did you happen to try ubiquity with the pygobject 2.90 packages already? I'm going to look into this, but want to avoid double work in debugging
[18:15] <shbk> I can't find linux/module.h,  do I need to recompile kernel?
[18:16] <cjwatson> apt-get install linux-headers-$(uname -r)
[18:17] <Daviey> For dh python2 transitions, is python > 2.6.6-3~ a requirement or a recommendation... and could i have some more detail on the reasoning please?
[18:17] <shbk> I have done this
[18:17] <sladen> shbk: install linux-headers-*  http://packages.ubuntu.com/search?searchon=contents&keywords=linux/module.h
[18:17] <shbk> sh@sh-laptop:~$ uname -r
[18:17] <shbk> 2.6.32-33-generic
[18:17] <shbk> I have headers
[18:17] <cjwatson> perhaps your module's build system is broken then
[18:17] <shbk> I didn't do nothing them yet, honestly
[18:17] <cjwatson> it should (IIRC) be passing -I/lib/modules/$(uname -r)/build/include to the compile
[18:18] <cjwatson> *compiler
[18:18] <cjwatson> and if you're running gcc by hand, you'll need to do that
[18:18] <shbk> I'm trying
[18:18] <ScottK> slangasek: Seemed to help.  I'll clean this up and go for it.  Thanks.
[18:19] <slangasek> ScottK: cool-o
[18:22] <mdz> pitti, cjwatson, Keybuk, who chaired the previous meeting? no minutes went out
[18:22] <shbk> I 've done,  nevertheless,I 'am receiving new errors   : gcc  -DMODULE -D__KERNEL__ -I/lib/modules/$(uname -r)/build/include hello.c -o hello.o
[18:22] <shbk> In file included from /lib/modules/2.6.32-33-generic/build/include/linux/list.h:6,
[18:22] <shbk>                  from /usr/src/linux-headers-2.6.32-33/include/linux/module.h:9,
[18:22] <shbk>                  from hello.c:1:
[18:22] <shbk> /lib/modules/2.6.32-33-generic/build/include/linux/prefetch.h:14:27: error: asm/processor.h: No such file or directory
[18:22] <shbk> /lib/modules/2.6.32-33-generic/build/include/linux/prefetch.h:15:23: error: asm/cache.h: No such file or directory
[18:22] <shbk> In file included from /usr/src/linux-headers-2.6.32-33/include/linux/module.h:9,
[18:22] <pitti> mdz: I'm not sure, I was on the desktop summit and couldn't attend
[18:22] <shbk> and futher futher futher...
[18:22] <Keybuk> mdz: I did
[18:22] <shbk> here is full listing http://gekannt.narod2.ru/ on the right side
[18:22] <shbk> any ideas?
[18:23] <cjwatson> I suggest that either #ubuntu or #ubuntu-kernel would be more appropriate
[18:23] <shbk> I was sent from ubuntu)
[18:23] <cjwatson> they were wrong
[18:23] <cjwatson> sorry, but this isn't an escalated support channel and they should know that ...
[18:24] <shbk> may it will be better to reinstall ubuntu or  reinstall headers?
[18:24] <shbk> may it help?
[18:24] <cjwatson> vast overkill and will not help.
[18:24] <cjwatson> you just need a fixed module build system, but (a) I don't know the exact details and (b) this isn't the right place
[18:25] <shbk> well , nevetheless thanks for #ubuntu-kernel)
[18:26] <cjwatson> you might look for a competently maintained module and borrow its build system
[18:26] <cjwatson> I suspect it might end up including /lib/modules/$(uname -r)/build/Makefile somewhere along the way, but I haven't looked at any of this for ages
[18:26] <cjwatson> rolling your own build system is unlikely to be a good use of time, anyway
[18:30] <sladen> shbk: http://lwn.net/images/pdf/LDD3/ch02.pdf
[18:45] <shbk> I 've started from this book, authors are Alessandro Rubini && jonatan Corbet, I'm in a circle)
[19:08] <sgnb> infinity: and oasis should be rebuilt as well
[19:31] <doko> Daviey, soren: rampart seems to belong to the eucalyptus stack, but is still in main. could you have a look?
[19:31] <doko> same for axis2c
[19:32] <soren> AFAIK, they were only there for Eucalyptus' sake. If nothing else needs them, I don't see any reason not to demote them.
[19:38] <Daviey> doko: Oh, that can go.  Infact, i'd like to kill our debain delta on that.. but that is unrelated.
[19:43] <doko> Daviey, well, find out what keeps it in main ...
[19:50] <Daviey> doko: I can't see that anything is, it's not directly seeded - and it's rdepends are all universe. :/
[19:51] <stgraber> doko: where do you see it still in main? A quick lookup here shows me that source is in universe and all its binaries too
[19:52] <stgraber> doko: same with axis2c actually, source and binaries appear as being in universe here (up to date oneiric)
[19:52] <Daviey> doko: where are you seeing it in main?
[19:52] <Daviey> stgraber: yeah, that is what i am seeing.
[19:54] <doko> stgraber, ahh, fooled by the test rebuild page
[20:16] <pitti> darn LibO FTBFS, seems to stumble over new libpq-dev from today :/
[20:19] <ahasenack> is there a mailing lest to send basic packaging questions to? Perhaps motu?
[20:23] <jtaylor> ahasenack: the best place to ask is probably debian-mentors@lists.debian.org or #ubuntu-packaging on freenode and #debian-mentors on irc.debian.org
[20:24] <ahasenack> jtaylor: cool, didn't know about #ubuntu-packaging either, thanks
[20:37] <Quintasan> How do I disable multiarch?
[20:42] <tjaalton> Quintasan: install i386 version, or another distro ;)
[20:43] <slangasek> Quintasan: what about multiarch is it that you want to disable?
[20:43] <tjaalton> actually, i386 is equally multiarch so scratch that..
[20:43] <infinity> i386 has multiarch too.  But I assume he meants "how do I make it stop downloading Packages files for another arch?"
[20:43] <infinity> meant*
[20:43] <tjaalton> right
[20:44] <Quintasan> infinity: yeah, this is confusing to say at least
[20:44] <Quintasan> Like getting conflicts on installing pbuilder
[20:44] <infinity> Eh?
[20:45] <slangasek> that's not multiarch's fault
[20:45] <Quintasan> Well, maybe not pbuilder
[20:46] <Quintasan> Well, let me put it other way -> http://wstaw.org/m/2011/08/25/plasma-desktopJN2047.jpg <-- this doesn't look helpful no matter how I look at it
[20:46] <slangasek> yep
[20:47] <slangasek> so if you're sure you want to disable multiarch, edit /etc/dpkg/dpkg.cfg.d/multiarch and comment out the line
[20:47] <infinity> slangasek: Oh.  Do you know if there a bug filed (or a dpkg patch in the works) for why wildcard matches on dpkg -l don't show foreign arch packages?
[20:47] <Quintasan> slangasek: Can bad things happen when I disable it?
[20:47] <infinity> slangasek: (Compare the output of "dpkg -l zlib\* | grep ^i" with "dpkg -l | grep '^ii  zlib'")
[20:47] <slangasek> though if you were to help improve aptitude to do more sensible things with multiarch, that would be better :)
[20:47] <slangasek> infinity: dpkg -l zlib:* - not a bug but a deliberate design decision
[20:48] <slangasek> sorry, dpkg -l zlib*:*
[20:48] <slangasek> Quintasan: you won't be able to install flashplugin, nspluginwrapper, or skype (from partner)
[20:48] <slangasek> if you don't care about those things, there are no other consequences for you currently :)
[20:48] <Quintasan> Urgh
[20:48] <infinity> slangasek: Hrm.  That's deliberate?  Seems a bit goofy and unintuitive to me.  But okay.
[20:48] <slangasek> infinity: it's a backwards-compatibility thing
[20:49] <slangasek> buxy can explain in detail :)
[20:49] <infinity> slangasek: Yeah, I guess I can see that.  Still wildly unintuitive.
[20:49] <infinity> slangasek: I don't need detail, I can see why.
[20:49] <tumbleweed> aptitude seems to want to get rid of all my i386 packages, whenever there's any dependency problems *anywhere* (not related to the i386 packages) :/
[20:50] <slangasek> yep, sorry about that
[20:50] <micahg> tumbleweed: bug 831768
[20:50] <slangasek> update-manager and software-center both do better
[20:50] <infinity> And apt.
[20:50] <slangasek> synaptic, aptitude, dselect all still have gaps
[20:50] <infinity> I wonder how dselect's coping.
[20:50] <infinity> Ahh. :)
[20:50] <slangasek> infinity: except for the lack of interactivity for apt :)
[20:50] <infinity> slangasek: Yeah.
[20:50] <Quintasan> slangasek: so flashplugin-installer pulling i386 libs is normal now?
[20:50] <tumbleweed> slangasek: sure, but none of them handle interactive upgrades (like we all need every day)
[20:51] <infinity> Well, if I want interactive, I still prefer dselect (I know, I'm weird), but I very rarely need that sort of thing anyway.
[20:51] <tumbleweed> ah, that was mentioned :)
[20:51] <infinity> Quintasan: It always has, it just used to do it via the gian ia32-libs blob, and now it does it correctly. :P
[20:51] <slangasek> Quintasan: yes - ia32-libs is die-die-die-deprecated
[20:51] <infinity> s/gian/giant/
[20:51] <Quintasan> I see
[20:51] <slangasek> it was an unmaintainable stopgap solution
[20:52] <slangasek> tumbleweed: actually, update-manager does me fine for daily interactive upgrades
[20:53] <infinity> I have no real issues with apt for my daily oneiric upgrades...
[20:53] <Quintasan> http://paste.kde.org/114355
[20:53] <Quintasan> Uhm
[20:53] <infinity> But then again, I tend to feed it the same sort of info I'd give an interactive package manager.
[20:53] <Quintasan> Is this also normal?
[20:53] <micahg> slangasek: update-manager doesn't show the change in package sizes, which is why I like aptitude
[20:53] <infinity> (apt-get --purge install add1 add2 remove1- remove2-)
[20:54] <slangasek> Quintasan: that's an oft-reported bug, it may have to do with missing i386 libraries; which version of flashplugin-installer do you have currently?
[20:54] <slangasek> (4ubuntu4 was uploaded today which should fix this)
[20:54] <slangasek> infinity: shorter: apt-get purge add1+ add2+ remove1 remove2
[20:55] <infinity> slangasek: Oh right, because purge is actually just "--purge remove" now, isn't it?
[20:55] <Quintasan> slangasek: I see, my mirror must be out of date then
[20:55] <Quintasan> 4ubuntu3 here
[20:55] <infinity> slangasek: And remove is actually just negative install.  Clever.
[20:56]  * Quintasan changes to us mirror
[20:56] <slangasek> Quintasan: yes - so you have the 4ubuntu3 amd64 flashplugin-installer, which relies on ia32-libs for the libraries and that no longer works.  Upgrading should fix that
[20:56] <slangasek> mdeslaur: I don't suppose you closed the million open bugs on flashplugin-nonfree when you uploaded? :)
[20:57] <mdeslaur> slangasek: I just closed the one I was subscribed to...let me take a look
[20:58] <Quintasan> us mirror ++
[20:58] <Quintasan> slangasek: Indeed, that worked.
[21:01] <slangasek> mdeslaur: actually, I guess they're probably filed against nspluginwrapper... bug #833558, bug #830784
[21:01] <slangasek> Quintasan: good good.  I'll do an upload of ia32-libs to make the upgrade a bit more seamless too.
[21:02] <mdeslaur> slangasek: I've just duped a bunch of flashplugin-nonfree bugs, I'll take a look at nspluginwrapper
[21:02] <slangasek> mdeslaur: ta :)
[21:02]  * Quintasan is not sure how multiarch is better but he can help with testing
[21:03] <slangasek> Quintasan: because when a security upload is done for a library, it becomes available to all users immediately via the i386 package instead of requiring somebody to upload an ia32-libs source package the size of a CD
[21:04] <Quintasan> Well, I can't dispute with that ^_^
[21:05] <slangasek> here, you can watch me blather on about multiarch at length if you like. :) meetings-archive.debian.net/pub/debian-meetings/2011/debconf11/high/747_Multiarch_in_Debian_6_months_or_6_years_on.ogv
[21:11]  * Quintasan downloads
[21:11] <Quintasan> Woah, 540MB
[21:11] <Quintasan> slangasek: You must have had a hard time talking so long :P
[21:12] <slangasek> you clearly haven't met me
[21:12] <slangasek> ;)
[21:12] <Quintasan> Maybe we can meet at UDS
[21:12] <slangasek> are you coming to this one?
[21:13] <Quintasan> No idea, I need sponsorship to go there :)
[21:13]  * Quintasan is just a high school student
[21:13] <infinity> You don't want to listen to slangasek speak.  It's a trap.  Don't do it.
[21:14] <Quintasan> :O
[21:14] <stgraber> slangasek: and there go my next 40 minutes ;) needed a break anyway
[21:19] <slangasek> stgraber: hey, slacker, I didn't say *you* should watch it! :)
[21:20] <slangasek> Quintasan: did you apply for sponsorship?  I believe the sponsorship queue is closed now
[21:20] <Quintasan> slangasek: I did apply, waiting for result :P
[21:21] <slangasek> yeah, the queue *just* closed, decisions haven't been made yet
[21:21] <stgraber> slangasek: :)
[21:21] <infinity> pitti: You have a sync sitting unflushed on cocoplum, did you plan to do something with that? (pygobject-2)
[21:22] <slangasek> I guess that's the one he was still trying to work out whether it breaks ubiquity
[21:23] <infinity> pitti: Err, nevermind, was just a crufty source package, not an upload.
[21:23] <infinity> pitti: Ignore me. :)
[21:23] <infinity> slangasek: Yeah, it didn't have a changes file.  flush-syncs (helpfully?) deleted it on cleanup though. :P
[21:23] <slangasek> ok :)
[21:29] <ScottK> doko: Would you please retry korundum in the archive rebuild?
[22:09] <astraljava> Stumbling with germinate, how do you guys test seeds locally? I can't seem to get the command just right.
[22:12] <astraljava> Figured that I need to use the --bzr option, but now I stumble on missing platform.oneiric seed.
[22:14] <infinity> astraljava: -S http://people.canonical.com/~ubuntu-archive/seeds/ -d oneiric -s ubuntu.oneiric
[22:14] <infinity> astraljava: (For example)
[22:14] <infinity> astraljava: The manpage is reasonably verbose.
[22:16] <infinity> astraljava: Or are you running it against a local bzr branch that's incomplete?
[22:18] <astraljava> infinity: Not a local one, but one that's in LP.
[22:18] <astraljava> But not yet uploaded for spinning the images.
[22:19] <infinity> astraljava: Well, if you have a seed that depends on another branch (like ubuntu.oneiric depends on platform.oneiric), I suspect you'll need side-by-side branches of both.  But don't quote me on that, I've never tried.
[22:20] <astraljava> infinity: Right. I see from germinate logs, that it tries to fetch platform.oneiric when building Studio images, but continues even when not finding such. But it doesn't seem to work locally.
[22:20] <infinity> I don't recall it having any clever fallback code for dependencies, though, so you probably need to copy all the deps.
[22:23] <astraljava> Actually, it does fallback on ~ubuntu-core-dev's platform. How can I do that locally?
[22:25] <astraljava> Couldn't find that bit of information from the manpages, while admittedly they're pretty elaborate, like you mentioned.
[22:27] <infinity> Not entirely sure.  You might be able to specify -S more than once.  Like I said, never tried.  I have a local mirror of all the seeds anyway.
[22:29] <astraljava> Thanks, that was all I needed. Just branched platform.oneiric, and I'm good to go. Cheers! :)
[22:29] <astraljava> Just have to remember to bzr update it regularily, I suppose.
[22:35] <doko> ScottK, done
[22:59] <kees> slangasek: so... multiarch silliness.
[22:59] <kees> my system doesn't seem to acknowledge that :i386 exists.
[22:59] <kees> $ cat /etc/dpkg/dpkg.cfg.d/multiarch
[22:59] <kees> foreign-architecture i386
[22:59] <kees> yet:
[22:59] <kees> E: Unable to locate package flashplugin-downloader:i386
[23:01] <slangasek> kees: apt-get update'd?
[23:02] <kees> slangasek: yup. it's up to date.
[23:02] <kees> though it's as if apt is ignoring i386
[23:02] <slangasek> kees: mv /var/cache/apt/pkgcache.bin* /somewhereelse?
[23:02] <slangasek> (&& apt-get update again)
[23:04] <kees> slangasek: nope :(
[23:04] <infinity> kees: apt-get update doesn't even show i386 Packages files being downloaded?
[23:05] <slangasek> kees: is your local mirror amd64-only?
[23:05] <kees> infinity: it doesn't show i386 being fetched, no. slangasek: my mirror is both.
[23:05] <kees> (but I'm pulling from the main archive too)
[23:05] <slangasek> hmm
[23:05] <vista_killer> hi
[23:06] <slangasek> kees: local apt config settings that are overriding dpkg?
[23:06] <kees> there used to be a second apt config to turn on multiarch...
[23:06] <slangasek> kees: apt *defaults* to what dpkg uses, but you can override it
[23:07] <vista_killer> i have this bug with kernel module nv_tco https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791089
[23:07] <slangasek> kees: $ apt-config dump | grep APT::Architectures
[23:07] <vista_killer> i have the same bug to 11.04 and now after the upgrade i find that the bug still exists
[23:08] <kees> slangasek: ah-ha. that's it. when "getting rid" of the apt multi-arch config, I left it _defined_ as amd64. I need to drop the entire line.
[23:09] <kees> muuuuch better
[23:09] <kees> thanks!
[23:10] <slangasek> vista_killer: this is not a support channel; you could try asking on #ubuntu-kernel, you'd at least be more likely to reach the right audience for your question there
[23:10] <slangasek> kees: aha :)
[23:10] <vista_killer> ok sorry
[23:11] <kees> slangasek: wow. that is a lot of :i386 to install. :)
[23:14] <slangasek> kees: software is complicated :P
[23:14] <kees> slangasek: ia32-libs is huge ;)
[23:15] <StevenK> It used to be bigger ...
[23:15] <RAOF> Boo.  wine's broken.
[23:15] <SpamapS> Hm, if something is open source (eucalyptus) but only works properly with sun java .. is it appropriate to move it to multiverse?
[23:16] <micahg> SpamapS: is this new? wasn't it in main?
[23:17] <SpamapS> micahg: eucalyptus was dropped to universe for 11.10
[23:17] <micahg> SpamapS: right, I meant the java dep
[23:17] <SpamapS> and now bug 791607 is apparently stumping their engineers or something
[23:17] <SpamapS> Actually I think the deal was that they wanted to do euca 3.0 but that release date is slipping.
[23:22] <micahg> slangasek: can you please copy an update for me?
[23:26] <micahg> SpamapS: is it a build or run time dependency?
[23:27] <micahg> SpamapS: ah, I see the comment in the bug, I don't think it would need to move to multiverse if it recommends non-free software, but you wouldn't be able to add a depends on something in partner AFAIK
[23:35] <kees>  libssl1.0.0:i386 1.0.0d-2ubuntu2 (Multi-Arch: same) is not co-installable with libssl1.0.0:amd64 1.0.0d-2ubuntu1 (Multi-Arch: no) which is currently installed
[23:36] <micahg> kees: did you enable multiarch?
[23:36] <kees> micahg: I did. seems dpkg is unhappy. doing some manual per-package installs now...
[23:37] <kees> wow, it's blowing up on all kinds of stuff :(
[23:38] <micahg> kees: I assume you're dist-upgrading?
[23:38] <kees> yeah :)
[23:40] <kees> heh,    while ! apt-get dist-upgrade ; do apt-get -f install ; done   ;)
[23:46] <doko> kees: add a dpkg --configure --pending in between
[23:46] <kees> doko: ah, yeah, good idea.
[23:48] <micahg> StevenK: are you available for an archive copy?
[23:50] <StevenK> micahg: What are you after?
[23:50] <micahg> StevenK: ubuntu-mozilla-security thunderbird 3.1.12+build1+nobinonly-0ubuntu0.10.04.1 to lucid-security
[23:52] <slangasek> RAOF: wine broken how?
[23:52] <slangasek> SpamapS: yeah, I think a depends on sun-java would translate to multiverse :/
[23:52] <slangasek> micahg: sure, what's the update?
[23:53] <micahg> slangasek: ah, I ask StevenK already, but thanks
[23:53] <slangasek> oh, did StevenK take this one?
[23:53] <slangasek> ok
[23:54] <StevenK> I haven't yet
[23:56] <slangasek> got it then
[23:56] <slangasek> micahg: done
[23:56] <micahg> slangasek: thanks
[23:57] <cnd> have we entered beta freeze yet?
[23:58] <cnd> or can I push a small ftbfs fix still
[23:59] <cnd> hmm… looks like I just missed it
[23:59] <micahg> cnd: if it's needed for beta, I believe so