[00:23] <RAOF> Is anyone here familiar with the archive side of the kernel SRU process?  It looks like the final step of copying from proposed→{updates,security} is just a job for a regular sru-release.py, but I'm not sure of that.  And the combination of “unsure” and “copying to -updates” is not one I'm comfortable with ☺.
[01:10] <RAOF> Laney: Actually, here's probably more relevant :)
[01:12] <lifeless> is there anyone in this tz familiar with apt internals ?
[01:14] <RAOF> That's a fairly specific skillset; I don't know of anyone.  I generally shout at slangasek.
[01:15] <RAOF> Laney: Also, how hard would it be to remove the darcs noise?
[01:29] <micahg> oh is StevenK around?
[01:30] <StevenK> micahg: FSVO.
[01:30] <micahg> StevenK: heh, could you remove the libglew1.5-dev binary, it's blocking anything trying to build-dep on libglew-dev?
[01:30] <micahg> I can file a bug if you like?
[01:30] <StevenK> Yes, can haz bug
[01:32] <micahg> StevenK: Bug #819087
[01:32] <micahg> StevenK: It technically needs a core-dev ACK (IANA core-dev)
[01:33] <StevenK> "Meh" :-)
[01:34]  * ajmitch can ack it if you really need to tick the boxes :)
[01:34] <StevenK> I just wanted a paper-trail -- but then micahg said the magic word 'NBS', which doesn't require one
[01:36] <StevenK> micahg: Done
[01:36] <micahg> StevenK: thanks :)
[02:05]  * micahg goes to clean up the mess he created for others before they find out...
[02:11] <RAOF> Laney: I've rejected the haskell-platform upload from natty-proposed queue that points at bug 711366; I presume that's correct.  I'd like to see the darcs changes cleaned out, though.
[05:19] <didrocks> good morning
[06:52] <mdke> Laney: that works perfectly. Thanks *so* much
[07:24] <fhd> If I've created a merge proposal on Launchpad, do I have to find and add reviewers manually for it to be reviewed?
[07:25] <fhd> Or will someone (project owner?) get notified of my proposal automatically?
[07:26] <RAOF> fhd: Depends on the project; the owner of the branch will get some notification, but there's no guarantee that goes anywhere.
[07:26] <geser> fhd: if it's listed on http://reports.qa.ubuntu.com/reports/sponsoring/index.html one of the sponsors should pick it up
[07:26] <fhd> RAOF: It's something for Unity (2D)
[07:26] <RAOF> That'll get on someone's radar.
[07:26] <fhd> I just remember that for Google projects, you always have to add reviewers manually
[07:26] <fhd> Or you can wait for months
[07:27] <geser> fhd: is this merge proposal for an upstream branch or an ubuntu packaging branch?
[07:28] <fhd> geser: Um, the unity branch
[07:28] <fhd> geser: This is the issue: https://code.launchpad.net/~fhd/unity-2d/fix-for-bug-795422/+merge/69919
[07:31] <geser> fhd: ok, I don't know how (upstream) projects handle merge proposals, especially unity-2d but I hope someone from the unity-2d team will pick it up
[07:31] <fhd> geser: OK, I'll just wait then :)
[07:34] <Laney> RAOF: you want me to retain it in the package?
[07:35] <RAOF> Laney: After thought I decided that removing it is fine; it's accepted.
[07:35] <Laney> awesome, thanks
[07:35] <Laney> it disappeared because I have -I..._darcs in my DEBUILD_DPKG_BUILDPACKAGE_OPTS
[07:35] <RAOF> You're welcome to review & upload colord to sid in return :)
[07:36] <Laney> sure, moving today but I can do that
[07:36] <Laney> give me a link to the .dsc :-)
[07:36] <RAOF> http://anonscm.debian.org/gitweb/?p=collab-maint/colord.git
[07:36] <Laney> even better, ta!
[07:38] <RAOF> Gah!  Too much X!  I just thought “bzr ci -m” and typed “git ci”
[07:39] <Laney> mr commit -m :-)
[09:22] <Daviey> Are any AA's looking at sync's atm?
[09:23] <seb128> Daviey, not really I think, I did an hour or so of cleaning and syncing previous week but that's about it
[09:25] <nigelb> Daviey: I think it was because of Debconf.
[09:31] <Daviey> nigelb: yeah, guessed so
[09:32] <Daviey> seb128: My oldest sync request was placed 2011-07-20. :/
[09:32] <seb128> Daviey, yeah, well I spent over an hour and I had to do other things so I didn't get to the bottom of the stack
[09:33] <Daviey> seb128: I understand, thanks.
[09:35] <geser> Daviey: there was also an accidental auto-sync last week. If you also requested sync of unmodified packages, you might want to check if it perhaps got already synced.
[09:40] <Daviey> geser: Already have :)
[09:40] <Daviey> One of my syncs was done by accident. \o/
[10:38] <fhd> Ubuntu 11.10 has lightdm instead of gdm - is that just temporary or will it be the new default dm?
[10:39] <geser> fhd: lightdm is the new default dm
[10:41] <fhd> geser: I see. But the theme probably isn't finished yet, huh?
[10:42] <Amaranth> fhd: clearly :)
[13:22] <tjaalton> pbuilder create fails on oneiric, aborts when it notices /proc is mounted already
[13:22] <tjaalton> anyone seen that?
[13:31] <infinity> tjaalton: Known mount misfeature.
[13:32] <infinity> tjaalton: I need to find some round tuits to look at it, I think.
[13:34] <tjaalton> infinity: ok, good
[13:38] <infinity> tjaalton: I have a basic idea of what's going wrong, just haven't found the time to dig deeper and fix it yet.
[13:38] <tjaalton> infinity: is there a bug # open yet?
[13:39] <infinity> tjaalton: There's a Debian bug, no idea if there's a launchpad one, but it seems likely.
[13:39] <infinity> tjaalton: I need to fix it in Debian anyway, so it'll make it to UBuntu when I do.
[13:41] <geser> tjaalton, infinity: bug #805886
[13:41] <tjaalton> infinity: bug 805886 it seems
[13:41] <tjaalton> echo :)
[13:43] <infinity> geser: Thanks.
[14:02] <tkamppeter> seb128, seems that a simple patch can make PackageKit optional. Will apply the patch, remove the dependency and suggest the patch upstream.
[14:02] <seb128> tkamppeter, thanks
[14:17] <tkamppeter> seb128, problem fixed upstream, taking new GIT snapshot ...
[14:17] <seb128> tkamppeter, excellent, thanks
[14:17] <seb128> jibel, ^
[14:18] <jibel> tkamppeter, seb128 thanks!
[14:20] <seb128> jibel, we can probably ask skaet to trigger a CD build once the fixed package will be published
[14:21] <jibel> didrocks, is the upload of unity/compiz stack ready for a3 ?
[14:21] <didrocks> jibel: compiz has been uploaded with some reverts for alpha3
[14:21] <jibel> seb128, what is the ETA ?
[14:21] <didrocks> jibel: unity/nux release will be there in 9 minutes normally, so then, time to test/release/package
[14:22] <seb128> jibel, s-c-p? time to get upload, build and published it should be available in 1:28
[14:23] <jibel> thanks. So we could respin with s-c-p and unity.
[14:23] <seb128> jibel, well the publisher run around the hour and take some 45 minutes, so if the upload is built before 5pm which seems likely it should be published around 5:45 pm
[14:23] <seb128> european time
[14:23] <stgraber> jibel: I also just pushed the set of packages I needed for edubuntu alpha-3 and fixing LTSP on both edubuntu and ubuntu alternate.
[14:23] <seb128> unity is going to take some 3 hours it needs to go through 2 publisher cycles
[14:23] <seb128> jibel, but yeah, maybe better to wait a few hours and ask for a respin then
[14:24] <didrocks> indeed, plan on 3 hours the time to get it and it's plublished
[14:32] <jibel> stgraber, ack.
[14:32] <jibel> I'll ask for a respin around 1800UTC
[14:33] <seb128> jibel, I will watch unity uploads, build, etc and let you know when it's published
[14:33] <jibel> seb128, thanks
[14:34] <didrocks> I'll tell you when I have a release and I can upload :)
[14:41] <infinity> So, is there a reason the Super+(number) shortcuts in Unity no longer actually launch applications?
[14:41] <seb128> infinity, known bug
[14:42] <seb128> should be fixed with the next update
[14:42] <infinity> seb128: Cool, thanks.  Was just curious if I'd broken something inadvertently.
[14:42] <diwic> infinity, it's intermittently broken in Natty (at least for me)
[14:43] <jibel> infinity, bug 813359
[14:43] <infinity> diwic: It worked fine for me in natty, broke completely in oneiric.  Well, for some value of "fine", I suppose.
[14:44] <seb128> tkamppeter, how is the s-c-p upload going?
[14:45] <diwic> infinity, for me the super+{s|a|f|t} are always working whereas the 1-9 are sometimes broken.
[14:46] <infinity> On the other hand, someone (perhaps accidentally) fixed the misfeature where compiz/unity was trapping ALL super modifiers.
[14:47] <infinity> So I can use Super+L for screen lock again.
[14:47] <infinity> I wonder if that will get unfixed when Super+# is fixed. :P
[14:48] <directhex> i just revoked unity's access to super. don't have time for games.
[14:48] <smoser> slangasek, around ?
[14:51] <tkamppeter> seb128, nearly ready.
[14:51]  * infinity glares at base-files giving him spurious conffile prompts.
[14:54] <tkamppeter> seb128, uploaded. Two bugs will close soon ...
[15:54] <tkamppeter> seb128, we talked about a package rename in foomatic-db last Friday. OdyX from Debian did not like it, because it is a very complicated thing to rename packages in Debian.
[15:56] <tkamppeter> seb128, so I made him the suggestion to get back into sybc by renaming foomatic-db-xml back to foomatic-db and let the drivers build-depend on foomatic-db but build-conflict with foomatic-db-compressed-ppds. Would the build handle this correctly then, installing foomatic-db and uninstalling foomatic-db-compressed-ppds if it is already installed?
[15:57] <seb128> tkamppeter, yes, that would work
[15:58] <tkamppeter> tkamppeter, I have also suggested the alternative to let foomatic-db Provide foomatic-db-xml. Would this also work, meaning that the build-depends on foomatic-db-xml then install foomatic-db and uninstall foomatic-db-compressed-ppds if it is already installed?
[15:59] <tkamppeter> seb128, ^^ if that alternative also works, then I would not need to modify the driver packages.
[16:00] <seb128> tkamppeter, that would work but provides are not versioned
[16:01] <seb128> tkamppeter, so if you do that you couldn't have a build-depends on a specific foomatic-db-xml version
[16:01] <seb128> or you would need to build-depends on foomatic-db (>= version), foomatic-db-xml
[16:01] <seb128> which works as well
[16:01] <seb128> tkamppeter, so basically your call, or whatever Debian prefers
[16:02] <tkamppeter> seb128, so I will do the former, it is easier for versioned dependencies.
[16:02] <seb128> right
[16:06] <tkamppeter> seb128, will I need a transitional package named foomatic-db-xml to get correct updates for the few people who have taken my last foomatic-db package? And how long do I have to keep this transitional package?
[16:08] <geser> tkamppeter: did you had a transitional package from -db to -db-xml?
[16:09] <tkamppeter> geser, yes.
[16:09] <geser> tkamppeter: I guess you could drop the transitional package for -db-xml to -db in a couple of weeks (but before release) as till then hopefully all affect alpha users should got it updated
[16:10] <tkamppeter> geser, OK, thanks.
[16:13] <seb128> tkamppeter, right, do one and drop it in a few weeks
[16:15] <tkamppeter> seb128, I am doing this now, thanks.
[16:17] <seb128> tkamppeter, thank you
[16:31] <ScottK> If there's an archive admin with a moment: Can you do a binary promotion of smoke-dev-tools.  It's Universe binary from Main source now needed in Main to build other stuff due to package splits.
[16:54] <Quintasan> Anyone has any idea what might be going on with pbuilder? When building anything dpkg-buildpackage uses -j1 even when I call with -j12
[17:15] <mterry> @pilot in
[17:15] <mterry> micahg, ping, I'm on
[17:16] <micahg> jtaylor: can you show mterry what you need?
[17:16] <jtaylor> mterry: please merge the branch attached to bug 780305
[17:17] <mterry> jtaylor, looking
[17:17] <jtaylor> it sould also be SRU'd
[17:17] <jtaylor> affects oneirc and natty
[17:17] <jtaylor> thx
[17:39] <tkamppeter> seb128, all changes concerning foomatic-db are uploaded now.
[17:39] <seb128> tkamppeter, thanks
[17:41] <ScottK> seb128:  Can you do a binary promotion of smoke-dev-tools. It's Universe binary from Main source now needed in Main to build other stuff due to package splits.
[17:41] <ScottK> We're kind of stuck on KDE 4.7.0 stuff on that right now.
[17:41] <seb128> didrocks, ^
[17:42] <didrocks> seb128: sorry, not really the time right now with this unity thing
[17:42] <seb128> ScottK, can do a bit later, the box I'm on now doesn't have my ssh key
[17:42] <seb128> jdstrand, ^
[17:42] <ScottK> OK.
[17:42] <ScottK> Thanks.
[17:42] <seb128> ScottK, I will do after dinner if nobody else does it
[17:42] <ScottK> Great.
[17:50] <ScottK> Maybe slangasek can do it?
[17:51] <slangasek> lookin'
[17:51] <ScottK> Thanks.
[17:53] <slangasek> ScottK: what needs it in main?  Doesn't show up on components-mismatches yet
[17:53] <ScottK> slangasek: https://launchpad.net/ubuntu/+source/smokekde/4:4.7.0-0ubuntu1/+build/2659970
[17:54] <slangasek> strange
[17:57] <slangasek> ScottK: promoted, now we just need to figure out why it's not on the component-mismatches list...
[17:57] <ScottK> slangasek: Thanks.
[18:01] <hallyn> it seems DEB_DH_INSTALLINIT_ARGS is deprecated, but it doesn't tell me what replaces it
[18:02] <hallyn> oh, i see.  that's cdbs doing all DEB_DH*
[18:33]  * negronjl is away: out to lunch
[18:47] <mterry> cyphermox, do you really need libsoup2.4 2.34.4 or can we just sync with Debian's 2.34.3?
[18:48] <micahg> mterry: the merge is for 2.35.4 unless it was a typo
[18:48] <mterry> micahg, right, sorry.  I meant do you really need 2.35.4 or can we just sync with Debian's 2.34.3?
[18:49] <cyphermox> bah, no reason to necessarily go with 2.35.4; I guess you can sync
[18:50] <micahg> shouldn't that wait until alpha3 though?
[18:51] <mterry> micahg, sure, probably.  I'm not going to push the button, just sort out this merge and file a sync request
[18:51] <micahg> mterry: k, there's one already you can resurrect (from ricotz)
[18:51] <micahg> bug 818569
[18:52] <mterry> micahg, thanks!
[18:53] <seb128> mterry, why not updating to the current version?
[18:53] <mterry> seb128, because it's a delta, and I don't see a particular feature/bugfix wanted from the new one
[18:54] <seb128> mterry, you could apply that to half of GNOME 3.1
[18:54] <seb128> but fair enough, your call, we will update when something update its configure requirements
[18:54] <mterry> seb128, :)  GNOME is a special case.  libsoup2.4 has historically been in sync, we only broke it for a security fix
[18:54] <mterry> I mean, it was recently in sync, I don't recall its actual history
[18:55] <seb128> mterry, but libsoup is a GNOME component ;-)
[18:55] <mterry> seb128, barely  :)
[18:56] <mterry> seb128, hrm... it does show prominently red in versions.html
[18:56] <seb128> mterry, well as said there is a good stack of components in such cases we updated
[18:57] <mterry> you're right seb128, I like to sync too much.  I'll go with cyphermox's merge
[18:57] <cyphermox> heh, we could merge in debian's changes too, the small ones that aren't yet included
[18:57] <seb128> mterry, i.e gdl, libgnome-keyring,gtksourceview3
[18:58] <mterry> cyphermox, yeah, ricotz requested that in the merge comments
[18:58] <seb128> mterry, trust me I like to sync, it's just that we follow unstable cycle and they don't, we will be back in sync for 3.2
[18:59] <seb128> mterry, but i've to say versions push me to do those updates, I really dislike red on version :p
[18:59] <mterry> seb128, yup.  I just didn't realize libsoup2.4 was in versions.html (i.e. among the set ubuntu-desktop cares about).  I thought it was a lesser-cared-for-by-us output of GNOME
[18:59] <seb128> mterry, well version is basically 'what is in the default installation'
[19:12] <slangasek> ScottK: so the reason for smoke-dev-tools not showing up as a mismatch is because smokekde wanted to be demoted
[19:12] <slangasek> I guess that fixes itself once built and the seeded binaries show up
[19:12] <ScottK> OK.  Thanks.
[19:13] <ScottK> We've got layers of bindings dependencies now that kdebindings is split, so it may take a little bit of time yet to sort out.
[19:29] <hallyn> Does anyone see anything telling in bug 818105?  Seems to be a general system fault (do i read this right, that it says stdin is 'file or directory not found'?)
[19:52] <mterry> @pilot out
[20:02] <lifeless> slangasek: hi; do you have a sec to talk about bug 816606 ?
[20:04] <SpamapS> hm, how can I get bzr bd -S to ignore this situation: dpkg-source: warning: Version number suggests Ubuntu changes, but there is no XSBC-Original-Maintainer field
[20:06] <slangasek> lifeless: I do, though if you're looking to me because of RAOF's comments yesterday I fear he's steered you to the wrong person as I'm no expert on apt internals :)
[20:06] <lifeless> slangasek: well, I guess I just need someone to agree on a path-to-fix
[20:06] <SpamapS> lifeless: isn't it just as likely that the bug lies in debootstrap's dependency resolver which is , by its own man page's admission, quite limited?
[20:06] <slangasek> SpamapS: unset DEBEMAIL in the environment for the build; but not for uploads to Ubuntu proper, as that warning shouldn't be ignored
[20:07] <SpamapS> slangasek: its been a problem on the upstart package for a long time
[20:07] <lifeless> SpamapS: no, its a recommends when as written it must be a predepends
[20:07] <SpamapS> slangasek: I believe stemming from the fact that there are two maintainers listed. :-P
[20:07] <lifeless> SpamapS: either the dep is wrong, or the code is wrong.
[20:07] <lifeless> SpamapS: it affects upgrades as well
[20:07] <slangasek> SpamapS: oh, right, that's an illegal maintainer field :)
[20:08] <SpamapS> lifeless: indeed.. I think last I looked it was a Depends ..
[20:08] <slangasek> SpamapS: mark the maintainer as James, move Scott to Uploaders: ?
[20:08] <SpamapS> slangasek: that doesn't fix the gripe.. :-/
[20:08] <slangasek> lifeless: um, certainly not a pre-depends if it's a postinst failure
[20:08] <slangasek> SpamapS: why doesn't it?  provided that the Maintainer: field lists ubuntu.com, there should be no complaints about XSBC-Original-Maintainer IIRC
[20:09] <micahg> well, it should change to a warning vs an error
[20:09] <lifeless> slangasek: well, it seems to want it configured vs just unpacked. IMBW.
[20:09] <SpamapS> slangasek: bug in the check maybe?
[20:09] <slangasek> lifeless: ... which is the definition of Depends
[20:09] <lifeless> slangasek: so, thoughts - disable the call, put an || true on the call, or change the relation ?
[20:10] <SpamapS> I wonder, was ubuntu-keyring in base packages before and now isn't ?
[20:10] <slangasek> lifeless: having a look at the history, one sec
[20:10] <lifeless> slangasek: bah, its been too long since I refreshed my predepends definitions :) - sorry.
[20:12] <SpamapS> please ignore.. that was a warning, but not what was failing my build
[20:20] <slangasek> lifeless: looks like the Recommends: ubuntu-keyring is entirely inconsistent with Debian (which has Depends: debian-archive-keyring), so I'd say we should promote it to a Depends
[20:25] <lifeless> ok
[20:26] <lifeless> I'll see about tossing a bzr branch up later today; for now I have to take lynne down for a checkup
[20:34] <hallyn> hm, python won't update in oneiric vm
[20:34] <hallyn> debconf: DbDriver "config": could not open /var/cache/debconf/config.dat
[20:34] <highvoltage> Daev: /win last
[20:34] <highvoltage> (eek, sorry)
[21:04] <jtaylor> hi, how can I mark a package as "should-not-be-merged"? argparse introduced a change in an upload which should not make it to ubuntu oneiric
[21:05] <micahg> jtaylor: file a sponsorship request to have it blacklisted
[21:05] <micahg> jtaylor: how permanent is the need to not sync?  there shouldn't be any more auto syncs until P opens
[21:08] <jtaylor> depends on when the underlying issue is fixed, should probably be done before P
[21:08] <jtaylor> it would need merging currently, but marking somewhere that it should not be done yet would be nice
[21:09] <micahg> jtaylor: MoM would be the place for that, but there's not a lot of room to explain why
[21:10] <jtaylor> I probably can't add comments there
[21:10] <jtaylor> can someone comment, don't merge, would introduce problem in 793695
[21:11] <jtaylor> for package argparse
[21:11] <micahg> jtaylor: anyone can add a comment
[21:12] <micahg> jtaylor: done anyways
[21:13] <micahg> jtaylor: are you sure that's the correct bug #?
[21:14] <jtaylor> thx
[21:14] <jtaylor> it would probably introduce the same problem as in that bug
[21:15] <jtaylor> its the same problem foolscap had, I think you sponsored my fix for that in foolscap
[21:15] <jtaylor> argparse 1.2.1 added build-dependency on setuptools + dh_python2 => upgrade failure depending on file ordering in data.tar.gz in binary packages
[21:16] <jtaylor> due to egg file -> egg folder
[21:16] <micahg> k
[21:21] <jtaylor> will python 2.6 still be in oneiric?
[22:47] <ScottK> Depends on Debian
[22:47] <ScottK> jtaylor: ^^^
[22:48] <ScottK> jtaylor: The plan had been to wait for Debian to make 2.7 default before we dropped 2.6, but now that the Debian release team has dropped the 2.7 transition as a release goal, I doubt that makes sense.
[22:49] <jtaylor> is there so much stuff only running with 2.6?
[22:49] <broder> ScottK: I thought Debian release team dropped 2.7 as a "release goal", because it was too limited in scope
[22:49] <ScottK> Look at Debian 622279
[22:49] <broder> maybe i misread the bits e-mail
[22:50] <DooMMasteR> hui
[22:50] <DooMMasteR> got my ubuntu down to 7,5sec boot time incl. XBMC startup :P
[22:51] <micahg> ScottK: wait, for wheezy they're sticking with 2.6? ugh
[22:51] <DooMMasteR> on an AMD E-350
[22:51] <ScottK> broder: It doesn't change the fact that it puts it on a "Meh, whenever" schedule since there's no mechanism for NMUs to ease the transition (unless, of course, I decided to just make 2.7 default and who cares what it breaks)
[22:51] <broder> ScottK: ah, i see
[22:51] <ScottK> micahg: No, they decided switching wasn't a release goal.  It doesn't mean the switch can't happen, just that something preventing it isn't RC.
[22:52] <ScottK> Now figure the odds of that.
[22:52] <micahg> well, it just means that we'll be driving most of the transition as I think regardless we're dropping 2.6 for P
[22:52] <ScottK> Yep.
[22:54] <slangasek> hmm, my understanding of release goal is "the release team blesses NMUing for this under the same rules as for RC bugs", not quite "this is RC"
[22:55] <slangasek> I think we could provide the necessary cover for NMUs without it being a release goal, too
[22:57] <slangasek> (though the release team deciding it's not a release goal is certainly not helpful here)