[00:08] <psusi> how long does it usually take to become a member of ubuntu after being approved by the dmb?
[00:11] <micahg> service apport status
[00:11] <micahg> psusi: ^^ should've been in -desktop
[01:56] <smoser> anyone aware of something like: https://wiki.ubuntu.com/UbuntuDevelopment/Merging that handles UDD ?
[01:58] <slangasek> smoser: it's in the Ubuntu Packaging Guide now: http://people.canonical.com/~dholbach/packaging-guide/html/
[01:59] <slangasek> http://people.canonical.com/~dholbach/packaging-guide/html/udd-merging.html
[01:59] <slangasek> barry: ^^ could you do some backlinks checking on those pages you've deleted? :)
[02:04] <RAOF> slangasek: Is there any particular reason not to merge the ubuntu-multiarch branch of mesa into oneiric?  It looks like the i386 package should properly handle being included in ia32-libs for now.
[02:05] <RAOF> Bah!  Stupid git-autocomplete-killing-zsh.
[02:05] <slangasek> RAOF: only that it requires coordination because it will break the X server :)
[02:05] <slangasek> RAOF: I meant to do it right after UDS; didn't happen; I'll likely get to it this week
[02:05] <RAOF> Oh, of course.  The X server will need a rebuild to pick up the new location.
[02:06] <slangasek> source changes and a rebuild, I think
[02:06] <slangasek> also, I know of one outstanding bug in that branch which I should probably fix... since it renders the -dev packages useless
[02:06] <RAOF> Heh.
[02:06] <RAOF> I'm merging mesa now (so that it builds against libdrm 2.4.25 again); I'd be happy to merge in the multiarch branch myself if you like.
[02:08] <slangasek> RAOF: well, you can, but caveat mergetor :)
[02:08] <RAOF> No-one will notice if I accidentally break indirect rendering!
[02:08] <slangasek> heh
[02:20] <hallyn> slangasek: bug 783541, user wants to run pam_smbpass as non-root.  I assume it requires things other than access to /etc/shadow or otherwise is unsafe?
[02:20] <slangasek> hallyn: it requires access to something even worse than /etc/shadow :)
[02:20] <slangasek> hallyn: for non-root, they ought to use pam_winbind instead
[02:21] <hallyn> that's what the readme said, wasnt' sure if htat did the same thing
[02:21] <hallyn> I'll recommend it, thanks.
[02:21] <slangasek> /var/lib/samba/passdb.tdb contains hashes that are plaintext-equivalent wrt the CIFS protocol, and are also in general easier to brute force than the ones in /etc/shadow.  pam_winbind requires running winbind locally, but... them's the breaks
[02:32] <hallyn> slangasek: thx
[02:34] <highvoltage>  
[03:04] <wcchandler> Does testdrive need to be run as root?
[03:10] <micahg> wcchandler: no
[05:13] <broder> ScottK: what was the process for getting dh 7 backported to hardy? i'm starting to wonder if we're going to want dh 8 backported to lucid soon
[06:22] <pitti> Good morning
[06:54] <pitti> hmm, I just got a whole lot of expiry emails from Launchpad, including me getting thrown out of ~ubuntu-sponsors without any prior warning
[06:54]  * TheMuso saw that also.
[06:55] <pitti> all ~work-item-tracker-hackers members also expired
[06:56] <TheMuso> Oh wow.
[06:56] <TheMuso> Something broke.
[06:56] <Simira> uh
[06:56] <Simira> my Ubuntu membership expired?
[06:57]  * TheMuso is asking in #launchpad.
[06:58] <wgrant> Hmm.
[06:58] <wgrant> The expiry script has been broken for a week or so... but I thought it was still sending warnings.
[06:58] <wgrant> (a fix was just deployed)
[06:58] <pitti> thanks
[06:59] <wgrant> All the expiries were legitimate, just without warning :/
[06:59] <wgrant> Let's see.
[06:59] <Simira> I didn't get any warning... but off to work now, will take it to #launchpad later
[06:59] <Simira> I'm not doing that little, although my local work doesn't show in launchpad :P
[07:01] <wgrant> Looks like about 300 memberships would have expired without warning.
[07:03] <Simira> ouch
[07:04] <didrocks> good morning
[07:16] <lifeless> win!
[07:16] <RAOF> lifeless: 32?
[07:21] <lifeless> 42
[07:30] <sladen> wgrant: just seen that on the papercuts team too.  ~30 people expired
[07:31] <ttx> cjwatson: me filing the patch on newpki-server implied no interest whatsoever. The bug was caught by one of my "what brings X libs to server installs" scripts.
[07:31] <wgrant> sladen: Exactly 30 :)
[07:31] <ttx> cjwatson: I actually never installed it :)
[07:33] <sladen> wgrant: 1 from ~papercutters; 26 from ~papercutters-ninjas I think.  Suspect more will arrive soon
[08:14] <cjwatson> ttx: OK, good :)
[10:02] <doko_> seb128: do you have an idea why the python3-doc documentation isn't shown in devhelp?
[10:02] <seb128> not off hand no
[10:08] <pitti> it's not?
[10:09] <pitti> I see "Python 3.2 documentation" in devhelp here
[10:41] <apw> cjwatson, FYI I just booted up the daily from yesterday on i386 and ...well it sort of boots.  the EMS is working fine, root is moutned.  comiz seems to be crashing
[10:41] <pitti> is that already using live-helper?
[10:41] <apw> pitti, no idea how i would tell
[10:42] <pitti> I wondered because it's not oversized although we added some packages (GTK3, etc.)
[10:42] <pitti> ISTR that live-helper uses a more efficient squashfs building, saving 5 MB
[10:43] <doko_> seb128, pitti: hmm, install python-doc too, and you won't see python3-doc anymore ...
[10:43] <pitti> Package: python-doc
[10:43] <pitti> Status: install ok installed
[10:43] <pitti> this one?
[10:43] <doko_> yes
[10:43] <pitti> hm, it's an empty package by and large (just /usr/share/doc/)?
[10:44] <doko_> pulls in python2.7-doc
[10:44] <pitti> indeed, I don't see python 2.7 docs in devhelp, only 3.2
[10:44] <doko_> do you see both 2.7 and 3.2 in devhelp?
[10:44] <apw> cjwatson, if i run X applications by hand they work so things are half there ... compiz/unity are just dumping core of course
[10:44] <pitti> doko_: is that an alternative?
[10:45] <doko_> pitti: no
[10:45] <pitti> lrwxrwxrwx 1 root root 21 2011-03-03 18:34 /usr/share/doc/python/html -> ../python2.7-doc/html
[10:45] <pitti> lrwxrwxrwx 1 root root 24 2011-05-06 07:24 /usr/share/devhelp/books/python3.2 -> ../../doc/python3.2/html
[10:46] <pitti> but that dir also has a python2.7 symlink, and I don't see that in devhelp
[10:46] <doko_> $ ls -l /usr/share/devhelp/books/
[10:46] <doko_> total 0
[10:46] <doko_> lrwxrwxrwx 1 root root 24 2011-05-26 11:43 python2.7 -> ../../doc/python2.7/html
[10:46] <doko_> lrwxrwxrwx 1 root root 24 2011-05-18 13:18 python3.2 -> ../../doc/python3.2/html
[10:47] <doko_> ?
[10:47] <pitti> same here
[10:49] <hrw> should apparmor 'profile_load' and 'profile_replace' messages appear in dmesg?
[10:54] <didrocks> ogra_: hey, small question on unity-2d: did you have a script to pack the changelog from the vcs commits?
[11:01] <ogra_> didrocks, nope, did that manually, best would be to train the guys to add changelog entries with their commits though, since the packaging is in the branch anyway
[11:03] <didrocks> ogra_: right, or having tarmac doing that during the merge req. ok, thanks for the answer!
[11:03] <ogra_> its not like i did 100s of uploads so manual was ok
[11:06] <didrocks> ogra_: yeah, it wasn't the list of bug fixes I had with unity-3d :-)
[11:07] <ogra_> kaleo usually has a nice list of bugs for each of their milestones
[11:07] <ogra_> so it should be easily scriptable to pull from that
[11:07] <kaleo> we were slacking :;)
[11:07] <kaleo> or not
[11:08] <didrocks> ogra_: well, that's what I'm doing for unity-3d, take from milestones all "fix committed", retarget to next one, and such…
[11:08] <ogra_> yeah, i thought so
[11:08] <didrocks> ogra_: but as the vcs is clean for unity-2d, I prefer taking from the source, luke :-)
[11:08] <ogra_> heh
[11:08] <ogra_> k
[11:19] <pitti> ev, cjwatson: will I break anythign in the installer by removing all langauge-support-* packages from oneiric?
[11:19] <pitti> (they are now entirely obsolete, replaced with check-language-support)
[11:36] <doko> pitti: see bug #741675, apport seem to be broken again to assign these bugs to the correct package
[11:36] <pitti> PythonArgs: []
[11:36] <pitti> hmm
[11:37] <pitti> doko: I'll have a look, thanks
[11:51] <ev> pitti: yes, it will break things, but we can fix that.
[11:51] <cjwatson> apw: no point telling me about compiz stuff :)
[11:51] <cjwatson> pitti: we aren't using live-build yet, no
[11:51] <pitti> I promised cjwatson to not break CDs, that's why I ask
[11:52] <ev> err actually, perhaps not
[11:52] <pitti> ev: do you know what to fix? can I add a WI for you on https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-clean-up-language-support to rip out installation of l-support-*?
[11:52] <ev> I was looking at a chunk of code that's a fallback for when check-language-support doesn't exist :)
[11:52] <pitti> ev: ISTR that ubiquity only installs it if it's available
[11:53] <cjwatson> pitti,ev: as far as I know we don't rely on language-support-* any more; but how were you planning to seed things on those images that have more than trivial language support?
[11:53] <pitti> but I better want to check before I purge all those
[11:54]  * cjwatson does a fresh round of CD builds
[11:54] <pitti> cjwatson: I replaced -en in the seeds for alternate/desktop I'd actually prefer a more dynamic solution using check-language-support in the CD build, but until then I'd just build the seed from check-language-support output
[11:54] <apw> cjwatson, :) indeed, am happy it boots at all myself
[11:54] <cjwatson> apw: incidentally, what's the "EMS"?
[11:54] <apw> cjwatson, ahh EHS, emergency holographic shell
[11:54] <cjwatson> pitti: about three UDSes ago I suggested using extra overrides
[11:54] <cjwatson> apw: ah :)
[11:55] <apw> i mixecd it up with EMH
[11:56] <pitti> cjwatson: we currently have -support for 5 extra languages on the DVD, it's not too painful to replace them with the full package list right now; it's not very elegant, of course
[11:56] <doko> cjwatson: was the debian-installer rebuilt in oneiric?
[11:56] <pitti> cjwatson: extra overrides?
[11:58] <doko> launchpad is spamming with bug mails for new imports from upstream trackers
[11:59] <cjwatson> doko: yes
[11:59] <cjwatson> pitti: like Task only not
[12:00] <cjwatson> pitti: I guess you haven't looked at other flavours then?
[12:00] <cjwatson> edubuntu has dvd-live: * /^language-support-[^-]+$/
[12:01] <pitti> I need to convert those before removing l-s, yes; currently doing ubuntu, the other flavours are on the list
[12:01] <doko> cjwatson: wondering about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623710
[12:03] <pitti> cjwatson: could I add a dvd-langsupport and dvd-live-langsupport file, generate that with check-language-support, and add these to STRUCTURE as dvd/dvd-live dependency?
[12:03] <pitti> might be cleaner than editing it in-place
[12:03] <doko> Daviey: please could you merge sysvinit?
[12:07] <cjwatson> pitti: I guess, yeah
[12:07] <cjwatson> doko: I'll have a look at that today
[12:07] <cjwatson> seems more likely to be a mklibs problem, but we'll see
[12:07] <pitti> cjwatson: then we'll actually include the full set of necessary packages (l-s was quite incomplete, it didn't catch the conditional depends from check-language-support)
[12:08] <cjwatson> pitti: or else get the live builder to run check-language-support and install stuff from that; but it's probably better to do that after switching to live-build
[12:08] <cjwatson> rather than doing the work twice
[12:08] <pitti> *nod*
[12:08] <pitti> until then a generated seed will do
[12:13] <Daviey> doko, I didn't plan to :/
[12:15] <Daviey> doko, Is it unfair for me to suggest this is a foundations area?
[12:20] <doko> Daviey: is it unfair to suggest the axis2c and erlang build failures to be a server area?  ;-P  and maybe other build failures
[12:20] <Daviey> doko, no, axis2c is a linaro area :)
[12:21] <doko> Daviey: eucalyptus is linaro? interesting ...
[12:22] <Daviey> doko, no, but they fixed the FTBFS for axis2c.
[12:25] <Daviey> doko, It does look like more of a complex merge than we'd prefer.  I am happy to help.
[12:27] <doko> Daviey: sorry, I don't see the linaro relationship, just because janimo did fix a failure, which the server team didn't address. please see the history of this package
[12:28] <cjwatson> doko: no more than sysvinit has a server relationship :)
[12:28] <cjwatson> let's not get all team-oriented about merges when we don't need to
[12:29] <cjwatson> we're all developers
[12:29] <cjwatson> sysvinit seems likely to be bound up with the /run transition; I haven't checked lately where Keybuk has got to with that
[12:30] <doko> right, I won't touch this then for now
[12:35] <Daviey> doko, Seems like this merge would greatly benefit from UDD... sadly the package-importer is blocked on it.  bum.
[12:40] <Daviey> doko, I've prodded the UDD admins into fixing the bzr branch..  Hopefully that'll be resolved by the time we have some news from Keybuk.
[12:40] <www2> hi i have a problem with cmake in my x68-64
[12:40] <doko> Daviey: thanks!
[12:40] <www2> * x86-64
[12:50] <mvo> DktrKranz: hey, when you have a bit of time I would appreciate a quick look at lp:~mvo/gdebi/gtk3
[13:03] <cjwatson> doko: I don't seem to be able to reproduce #623710 on unstable/i386; but it's possible that it was slightly more architecture-specific than claimed in the bug.  Asking Jurij ...
[13:04] <doko> cjwatson: and maybe joey too? it wasn't only seen on powerpcspe
[13:06] <cjwatson> well, I asked on #debian-boot, so others can chime in
[13:06] <cjwatson> the original report was amd64
[13:06] <cjwatson> I don't have a suitable testbed to hand for that right nw
[13:06] <cjwatson> *now
[13:06] <soren> xen is failing to build on Ubuntu apparantly because for some reason -Wl,-Bsymbolic-functions is being passed to ld (rather than GCC). Before I go diving into that, is that a common well-understood problem?
[13:07] <geser> soren: sound like $(LD) $(LDFLAGS) in the makefile instead of $(CC) $(LDFLAGS)
[13:08] <geser> when linking
[13:08] <soren> geser: That would make it fail in Debian, too, wouldn't it?
[13:08] <cjwatson> there are a few packages that do that.  If it's impractical to have them use gcc as the linker instead, then 'unexport LDFLAGS' in debian/rules is a workaround
[13:08] <cjwatson> no, Debian doesn't default to -Wl,-Bsymbolic-functions in dpkg-buildpackage
[13:08] <soren> No but..
[13:08] <soren> err..
[13:08] <soren> That is our default for... what? LDFLAGS?
[13:09] <cjwatson> yes
[13:09] <soren> Oh
[13:09] <soren> Wow, ok.
[13:09] <cjwatson> which the vast majority of packages give to gcc, so it's formatted for use by gcc
[13:09] <doko> soren: as cjwatson says. ld is directly used in xen. or you strip the -Wl, from LDFLAGS
[13:09] <cjwatson> but of course the -Wl, breaks ld
[13:09] <soren> I wouldn't have expect "-Wl," in LDFLAGS :)
[13:09] <geser> soren: it would fail in Debian too if LDFLAGS would contain -Wl,... there too
[13:09] <cjwatson> soren: if you don't put -Wl, in LDFLAGS (and it's non-empty), then most of the rest of the archive breaks
[13:10] <cjwatson> xen is one of the exceptions
[13:10] <mterry> kees, can you please add me back to ubuntu-sponsors?  I got expired without noticing
[13:10] <soren> Right, it makes sense now. I just thought LDFLAGS is what would passed to ld, not what would be passed to gcc to get it to pass it on to ld.
[13:10] <soren> No problem, I just misunderstood LDFLAGS, apparently.
[13:11] <soren> mterry: Just fyi, not your fault. The "you're about to expire" thing in LP has been broken for the last week, iirc.
[13:11] <mterry> soren, ah, odd
[13:11] <soren> mterry: (cf a conversation a few minutes ago in #launchpad)
[13:12] <jml> hello
[13:12] <jml> some community contributors are interested in implementing a wiki within Launchpad
[13:12] <soren> jml: \o/
[13:13] <jml> I thought, gosh, Ubuntu has a big wiki and might be able to help us avoid some of the problems that they've had
[13:14] <jml> who specifically should I speak with in order to get that kind of information?
[13:18] <soren> cjwatson: I'm not completely sure what -Bsymbolic-functions does. Instead of just unexporting LDFLAGS, should I instead tweak it to just read "-Bsymbolic-functions" (i.e. strip off the "-Wl,")?
[13:20] <cjwatson> it's documented in ld(1)
[13:21] <cjwatson> I don't feel all that strongly either way though.  Across the whole distro, it's an efficiency win; for a single package, meh
[13:22] <cjwatson> jml: isn't that the kind of scope creep you're trying to avoid?
[13:22] <cjwatson> I'd be pretty worried about implementing YA wiki rather than e.g. borging in some existing software
[13:22] <soren> In this day and age, people seem to consider a wiki a required part of a project hosting site.
[13:22] <jml> cjwatson: oh yeah, I probably want the solution to be borging in some existing software
[13:23] <jml> cjwatson: but I also want it to be a much, much better borging than loggerhead was for code browsing
[13:23] <cjwatson> jml: I'm not sure whom you'd want to speak with.  Maybe the sysadmins?
[13:23] <jml> so getting clear on requirements is a good first step
[13:23] <elmo> step #1: avoid moin
[13:23] <elmo> step #2: see step #1
[13:23] <jml> heh
[13:24] <elmo> :-P
[13:24] <cjwatson> I think "avoid plone" ought to be in there somewhere too
[13:24] <soren> cjwatson: Thanks for your help!
[13:24] <jml> elmo: what about moin makes it so bad?
[13:24] <doko> cjwatson: I would like to modify vendor flags in dpkg to pass -D__BUILDD_<random-string>__  in CFLAGS, CXXFLAGS, FFLAGS, and -Wl,-z,buildd-<random string> in LDFLAGS, to catch packages which don't honour the vendor flags
[13:24] <jml> cjwatson: that's a given for any Launchpad work.
[13:25] <cjwatson> doko: I'd prefer that go through #debian-dpkg I think
[13:25] <cjwatson> though I'm a bit concerned that that sounds like it adds a certain amount of footprint to every compiled binary
[13:25] <doko> well, to the log, not to the binary
[13:26] <elmo> jml: I'm mostly being facetious - we're stuck on an old version of moin (not for long) and it hurts.  but moin doesn't have many wikis running at ubuntu scale and has lots of painful areas in terms of scaling (search, page subscriptions, page layout on disk)
[13:26] <cjwatson> doko: hmm, well, that's better
[13:26] <cjwatson> doko: still, once multiarch lands, we should be in sync with Debian dpkg at long last, so it would be nice to preserve that property :)
[13:26] <doko> and debian could argue, that you can change the config file
[13:27] <cjwatson> doko: no, Debian is much more likely to argue that it should go into the Ubuntu vendor hooks maintained as part of the dpkg repository
[13:27] <cjwatson> same place -Wl,-Bsymbolic-functions lives
[13:27] <jml> elmo: thanks. it's good to know. I'm not sure whether I should be insisting that whatever these guys come up with has to be Ubuntu scale.
[13:27] <doko> ok, so add it to the vendor hooks, and then submit it to debian
[13:27] <elmo> jml: oh - and how the hell did I forget this - it's very bad at being cachable for anonymous users
[13:27] <jml> (if I put the wiki page in /dev/null, does that make it Ubuntu scale?)
[13:28] <elmo> we had to do some truly sick things to get it to cache as much as we have it caching now
[13:28] <cjwatson> doko: other way round would be nice, to avoid churn in case they suggest changing the name :)
[13:28] <Alexqw> Does anyone know if apt 0.7.26 will be released for Lucid?  My labs are affected by bug #250909, and we cannot deploy some of our software as a result.
[13:28] <doko> well, ok ...
[13:29] <cjwatson> Alexqw: in general, new versions don't get released directly, but asking for a particular fix to be backported is different
[13:29] <cjwatson> mvo: ^-
[13:30] <cjwatson> I've created a lucid task on that bug
[13:30] <Alexqw> cjwatson: ok.  that makes sense.  Should I open a new bug in this case?  it seems redundant.
[13:30] <Alexqw> cjwatson: oh, excellent ;-)
[13:30] <cjwatson> Alexqw: please do not open a new bug
[13:30] <jml> elmo: thanks.
[13:30] <Alexqw> cjwatson: I'll be sure not to.  Thanks for your help
[13:30] <cjwatson> (I mean, for this. :-) )
[13:30] <Alexqw> heh
[13:32] <bluefoxicy> heh I don't actually know what cflags stuff is compiled with on Ubuntu
[13:35] <jdstrand> hrw: re apparmor> yes, that is completely normal
[13:36] <bluefoxicy> ah well, I guess it doesn't much matter as long as everything is -O2 -fomit-frame-pointer -fstack-protector -Wl,-O1 and executables are -Wl,-pie
[13:37] <bluefoxicy> although some silly people like to use -fstack-protector-all o_O
[13:38] <doko> maybe you should turn on verbose build logs, then you see what you get
[13:39] <bluefoxicy> if I build something here it'll build it exactly as it's built on the build servers?
[13:40] <bluefoxicy> doko wa doko desu ka?
[13:40] <DktrKranz> mvo: hi! sure, I'll have a look this evening
[13:40] <bluefoxicy> heh... doko wa doko ni sundeimasu ka?
[13:43] <mvo> Alexqw: hi, we can make a SRU of this particular fix
[13:44] <Alexqw> mvo: great.  I'm glad to hear
[13:45] <mvo> Alexqw: I need to look at this though, it maybe that it actually requires a abi break in which case its not something we can do easily
[13:46] <Alexqw> mvo: ok.  I appreciate you taking the time to look at it.  Hopefully it doesn't cause problems.
[13:50] <real_ate_> hi all... i'm just wondering, what is the "correct" way for a deb to replace default configurations? I'm creating an ubuntu deb for on of our company's applications and it needs to replace the default configuration of one of its dependancies... but i keep getting a message: trying to overwrite '/etc/tilecache.cfg', which is also in package tilecache 0:2.10-1~jaunty1
[14:01] <hrw> jdstrand: thx
[14:06] <lool> mvo: BTW thanks for the apt upload to lucid-proposed!
[14:13] <mvo> lool: yw
[14:17] <mvo> pitti: quick question, is there anything holding back software-center from entering natty-updates?
[14:17] <pitti> mvo: no, it's past 7 days now, should be fine
[14:17] <pitti> mvo: hm, why is bug 776706 not fixed in oneiric, but the other three are?
[14:18] <pitti> I can't copy it to oneiric, it's got a newer version
[14:18] <chrisccoulson> pitti - could you copy the firefox update in natty-proposed to natty-updates please? :)
[14:19] <pitti> ah, you guys got me; ok, dropping stuff and doing SRU :)
[14:20] <geser> broder: Hi, can libassuan2 be dropped in favour of libassuan0 (now also at version 2.0.1 in oneiric)? see also bug #788473
[14:21] <mvo> pitti: that bug is fixed in oeniric, its a leftover, sorry
[14:21] <pitti> great, thanks for checking
[14:45] <pitti> cjwatson: FYI, all seeds updated to drop language-support-* (mythbuntu and ustudio don't pull in any, so I left those untouched)
[14:46] <pitti> cjwatson: so what I'd like to do now is to drop l-s-* from oneiric, then wait for the next daily CD build, and test them to see what breaks
[14:46] <pitti> cjwatson: but you wanted to build a CD right now, so I better postpone the removal for a bit?
[14:50] <smoser> if a debian package (python-boto) does not use a patch system, would it be generally preferable to continue that in ubuntu delta? or would it be better to add a patch system to maintain the debian->ubuntu delta more easily.
[14:50] <pitti> stgraber: btw, to remove a branch from teh sponsors list, set the status to "work in progress" (if it needs fixing), or "rejected" (if it's broken)
[14:53] <stgraber> pitti: how can I dod that when I'm not part of ubuntu-branches or ubuntu-sponsors? Is simply adding a review enough to have it gone?
[14:53] <stgraber> *do
[14:53] <pitti> stgraber: ah, you can't change the status?
[14:53] <pitti> stgraber: I changed https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/mountall/natty-201104141818/+merge/57748 to "rejected" now
[14:54] <stgraber> pitti: right, you need to be in ~ubuntu-branches to do it apparently (you are a member of it through the TB)
[14:54] <pitti> ugh, that would be qutie strong
[14:55] <pitti> I think you only need to be able to upload the package
[14:55] <pitti> well, that's how it should be, anyway
[14:55] <pitti> set https://code.launchpad.net/~holizz/ubuntu/natty/gnome-terminal/cursor-blink-mode-ui/+merge/58904 to rejected as well
[14:56] <stgraber> I agree, seems like we're missing some LP bits to have that working :)
[14:56] <pitti> stgraber: for the bugs, it should be enough to unsubscribe the sponsors team
[14:56] <stgraber> which you can only do when you are part of the team, right?
[14:56] <pitti> ah, right
[14:56] <pitti> and I'm not any more since this morning, when LP unhelpfully kicked out tons of people without prior warning
[14:57] <pitti> and no DJ Holy Holbach around to add me back
[14:58] <stgraber> kees, TheMuso and nhandler are also administrators of ubuntu-sponsors so they should be able to add you back to it
[14:58] <cjwatson> pitti: I did a CD build earlier today
[14:58] <pitti> nhandler, kees: can you please add me back to ~ubuntu-sponsors? thank you in advance!
[14:59] <pitti> cjwatson: ah, good; I don't see one in http://cdimage.ubuntu.com/daily-live/ (just a failure email)
[14:59] <cjwatson> pitti: let me check then
[14:59] <stgraber> nhandler, kees: Can you also add me to that team? would be quite useful when doing patch pilot. Thanks!
[14:59] <geser> smoser: if a package doesn't use a patch system it's preferred to keep it that way (else you end with some patches applied directly while others through the patch system)
[14:59] <cjwatson> smoser: we've generally considered (a) adding a patch system to be a change in packaging style (b) changing packaging style in an Ubuntu delta to be rude)
[15:00] <cjwatson> pitti: ah, yeah, it failed due to the same seed breakage
[15:00]  * cjwatson tries again
[15:00] <stgraber> pitti: thanks for rejecting the merge proposals
[15:01] <smoser> geser, cjwatson thank you.
[15:03] <smoser> so, in that case, would it still be preferred to carry the list of ubuntu delta in the changelog ?
[15:06] <broder> geser: the soname is going...down? that seems odd. but i don't know anything about the package - the changes i was making were just for multiarch stuff and didn't actually touch the software
[15:08] <cjwatson> smoser: yes, that should be done regardless
[15:08] <geser> broder: libassuan was for a  long time on version 1.0.5-1 and got only recently updated to 2.0.1, while Ubuntu in between packaged it as libassuan2
[15:09]  * broder shrugs
[15:10] <broder> pitti, stgraber: there's a bug where people that can upload a pkg can't change the status of MPs against the release pocket branches post-release, but i can't find the bug at the moment
[15:11] <geser> broder: I hoped you know if we can drop libassuan2 (and move any delta to libassuan) as you were one of two person touching it
[15:11] <broder> pitti, stgraber: ah - bug 612391, there it is
[15:11] <broder> geser: i was only applying a rote change to it along with a bunch of other packages. i didn't dig into it any more than that
[15:12] <geser> ok, thanks anyways
[15:12] <stgraber> broder: thanks for the link!
[15:16] <bdmurray> mvo: do you know if bug 659438 is really fixed?
[15:47] <mvo> bdmurray: let me check
[15:49] <bdmurray> mvo: thanks some duplicates have been coming in recently
[15:50] <mvo> bdmurray: oh, ok :/ that is bad
[15:50] <pitti> hey, a working classic gnome on the current oneiric live CD in kvm
[15:50] <bdmurray> mvo: yes, that's what I'd thought
[15:55] <dpm> hi pitti, I've just been talking to kyleN re: the conversation of selectively enabling the translation of universe packages in LP, and he was telling me that this would be useful for OEM. There is no WI for that on the China ISO spec for that, but given that you mentioned that it'd be a 15 m change in pkgbinarymangler, do you think we could go for it? If so, shall I add a WI or file a bug for it? I'd then coordinate it with the LP guys for the work that
[15:55] <dpm>  would be needed on the LP side
[15:56] <pitti> dpm: fine for me to add these WIs to the cleanup-language-support spec, fits better there
[15:56] <pitti> or just file it as a wishlist bug and assign to me
[15:56] <pitti> I don't mind which, whatever you prefer
[15:56] <pitti> with a bug we could also have a LP translations task
[15:56]  * pitti -> bbl
[15:57] <dpm> pitti, cool thanks. I'll do that now, then.
[16:02] <chrisccoulson> bdrung_, is mozilla-devscripts broken in oneiric? https://launchpadlibrarian.net/72460854/buildlog_ubuntu-oneiric-i386.webfav_1.17-0ubuntu6_FAILEDTOBUILD.txt.gz :)
[16:03] <stgraber> cjwatson: just talked with dpm, the reason why edubuntu-live's translation template isn't imported in LP is because the package is in universe. I'll have to file a MIR for it apparently.
[16:04] <cjwatson> ok
[16:04] <bdrung_> chrisccoulson: that looks like a bug in python-librdf
[16:04] <chrisccoulson> bdrung_, do you want to take a look at that, or shall i?
[16:05] <bdrung_> chrisccoulson: you. it's outside of my scope.
[16:05] <chrisccoulson> ok, no problem
[16:06] <james_w> jamespage, hi, https://blueprints.launchpad.net/ubuntu/+spec/server-o-jonas refers to "fbenoit", which isn't a valid LP account. Does that person have an LP account?
[16:11] <soren> james_w: ~florent-benoit probably
[16:11] <soren> james_w: seeing as he's subscribed to that very blueprint it seems like a reasonable guess :)
[16:12] <james_w> soren, ah, good thinking!
[16:12] <james_w> thanks
[16:13] <Alexqw> mvo: I read the updates in bug 250909.  Does this mean that it's a low likelihood that the fix will be back-ported to Lucid?
[16:14] <mvo> Alexqw: unfortuantely yes, it should be straightforard to apply the diff, but I don't think we can make this a official SRU as it will break unreleated software (without rebuilds and patches)
[16:15] <mvo> Alexqw: in what context do you need the feature? i.e. large scale deployment or just one (or a small number) of machines?
[16:15] <Alexqw> mvo: hmm. ok.  Do you have any suggestion for how I should deploy packages larger than 2.5 GB to 64bit lucid clients then?
[16:15] <Alexqw> mvo: deploying to dozens of machines
[16:15] <Alexqw> mvo: so not hundreds, but enough to be a pain manually
[16:15] <mvo> Alexqw: would it be a option to build the updated apt in a PPA just for those machines?
[16:16] <Alexqw> mvo: yes
[16:16] <mvo> Alexqw: I'm happy to assist with that so that the other people suffering from the bug can use the PPA
[16:16] <mvo> too
[16:17] <Alexqw> mvo: excellent.
[16:18] <Alexqw> mvo: I don't have a public ppa setup, just an internal repo
[16:39] <SpamapS> If the UDD branch for a package is out of date, is the only way to bring it back up to date to go through the publishing history, manually doing package imports?
[16:43] <lool> juliank: Hey there, I am looking at fixing https://bugs.launchpad.net/update-manager/+bug/610820 in natty/maverick but it's not yet fixed in oneiric; do you have an ETA for oneiric?  Should I grab the patch and apply it on top of current oneiric sources?  I understand it's a matter of replacing all Py_BuildValue("k", ...) with MkPyNumber?
[16:47] <juliank> lool: It's in Debian (experimental, 0.8.0~exp2), so it basically needs to be merged. But as 0.8 breaks API, you may want to do something else
[16:47] <lool> juliank: I was wondering whether there is a plan to merge 0.8 in Ubuntu this cycle
[16:47] <lool> mvo: Might also be something you track?  ^
[16:48] <juliank> lool: Better this cycle than next one.
[16:48] <lool> that's right
[16:49] <juliank> lool: APT 0.8 will hit unstable soon, oneiric could follow afterwards
[16:49] <lool> juliank: Ok; thanks
[16:49] <lool> juliank: Is it ok if I upload something like your patch in the mean time?
[16:49] <juliank> lool: There's also always the option to reenable the 0.7 API. The code still exists.
[16:50] <mvo> lool: I have a local branch with the 0.8 merge that keeps the old api around
[16:50] <lool> adjusting the Py_BuildValue("k", ...) call sites
[16:50] <mvo> I used it for local test, but it should be fine
[16:50] <lool> mvo, juliank: To clarify, I'm contemplating SRU-ing this bug, first step is getting it fixed in oneiric, which is why I'm asking about timeline etc.
[16:52] <juliank> lool: You can always just cherry pick the patch. It should work on 0.7.100 as well, the differences to 0.8 are not really large.
[17:01] <lool> ok thanks
[17:01] <tkamppeter> sabdfl, ping
[17:01] <mvo> lool: SRU should be fine, but given the nature of it we need to carefully regression test
[17:01] <fta> doko, hi, is ld-gold still experimental?
[17:01] <doko> fta: I don't know; maybe I should do daily builds of binutils and gcc-4.x on all series to find out
[17:01] <fta> doko, for chromium, ld-bfd is way too slow, it takes so long to link the final binary that it makes the builders timeout and ftbfs
[17:01] <lool> mvo: yes; is the python-apt testsuite a good base for that?  it seems it's run during build
[17:01] <fta> doko, and upstream chromium now uses it anyway, so i just moved my dailies to use it too
[17:01] <mvo> lool: it should be, but I'm not sure how well this part if covered by the tests
[17:01] <doko> fta: well, then you have the answer. if you see issues, please file reports both upstream and for ubuntu
[17:01] <fta> doko, ok. i'm slightly concerned by dists i don't use / can't check
[17:18] <mvo> lool: fwiw I upload my merge now, but its ftbfs because of some py3 issue, I need to look into that
[17:20] <juliank> mvo: I also just wanted to upload 0.8 to unstable, but the Alioth changes broke the pre-build script - is this not happening in the ubuntu branch?
[17:20] <lool> mvo: I pushed python-apt with the patch some minutes ago
[17:21] <lool> mvo: about 4 minutes before you said you're uploading your merge; would you mind including the diff?
[17:21] <lool> mvo: will provide a debdiff in a sec
[17:21] <juliank> lool: mvo: The ubuntu branch seems to run utils/get_debian_mirrors.py > data/templates/Debian.mirrors as well and should thus be broken as well.
[17:21] <lool> mvo: http://paste.debian.net/118065/
[17:21] <lool> juliank: is thata different bug?
[17:23] <juliank> lool: We can't fetch the Debian mirror list from Alioth, as their redirects are broken and checkout is disabled; pre-build.sh thus fails. This makes me wonder how you got it to build, if the pre-build stage fails
[17:23] <juliank> lool: OK, it's commented out now, my branch was outdated.
[17:24] <lool> mvo: sorry, ignore the debdiff, you have the changes from 0.8
[17:24] <mvo> juliank: I disabled the update-mirror for debian too, indeed. I looked briefly into this but it seems its disbled completely on alioth to just get the raw file from cvs instead of the markup version. kind of anoying
[17:24] <lool> juliank: I didn't testbuild it
[17:26] <mvo> juliank: just fyi https://launchpadlibrarian.net/72473733/buildlog_ubuntu-oneiric-amd64.python-apt_0.8.0~exp4ubuntu1_FAILEDTOBUILD.txt.gz - the bug itself looks like a py3 issue, I wonder why 2to3 did nt catch it
[17:26] <mvo> lool: sorry for the duplication, I should have pushed my branch earlier
[17:27] <juliank> mvo: It took the wrong file. It should look in ../build/lib.linux-x86_64-3.1, but looked in ../
[17:28] <juliank> mvo: 3.2 in this case
[17:28] <lool> mvo: are you using the UDD branch?
[17:28] <mvo> lool: I use lp:~ubuntu-core-dev/python-apt/ubuntu, thats a branch from the upstream debian bzr
[17:29] <lool> mvo: You might want to put that in Vcs-bzr
[17:33] <juliank> lool: It's at least documented in the "Contributing to python-apt" part of the documentation.
[17:33] <bdrung_> RoAkSoAx: is the sponsorship still too slow even with the patch pilots?
[17:35] <RoAkSoAx> bdrung_: sometimes. Depends who;s piloting
[17:35] <lool> juliank: you presuppose I would read any kind of package specific doc before uploading a patch  :-)  if anything, debian/README.source could mention it
[17:35] <RoAkSoAx> bdrung_: at the moment, I have couple merges sitting there for a week
[17:36] <RoAkSoAx> bdrung_: maybe everybody is busy with other stuff due to UDS, but I've faced this before until the point that I had to nag ppl a lot to be able to get my fix uploaded
[17:37] <RoAkSoAx> bdrung_: it has obviosly improved a lot when patch pilot was introduced
[17:37] <bdrung_> urg, the sponsors queue is full again (110 items)
[17:39] <seb128> bdrung_, new cycle, UDS, dholbach not being around recently and james_w buggy requests contributed to put it back there yes
[17:40] <bdrung_> seb128: what should i do with james_w requests like https://code.launchpad.net/~ubuntu-branches/ubuntu/feisty/gnumeric/feisty-201105201650/+merge/61811 ?
[17:41] <seb128> not sure, cjwatson wrote some details about those in his previous piloting summary, maybe read his email
[17:44] <james_w> bdrung_, given that no-one is going to be uploading to feisty that can likely be rejected without looking at it
[17:45] <james_w> bdrung_, generally though look at the diff and see if it brings in something useful
[17:46] <james_w> if there is something odd (like in this case that it has no unmerged revisions), please file a bug at https://bugs.launchpad.net/udd/+filebug and point to the merge proposal
[17:50] <bdrung_> RoAkSoAx: but sync request are processed fast ;)
[17:50] <RoAkSoAx> bdrung_: hehe :)
[17:58] <bdrung_> james_w: bug #788731 - should i do that for the other ones too?
[17:59] <james_w> bdrung_, anything that is an empty merge for an old release is likely the same problem. If you see other symptoms then another bug is probably appropriate
[17:59] <james_w> thanks!
[18:00] <bdrung_> james_w: what should i do if there is a commit, but no changed content?
[18:01] <james_w> that's likely not wanted either, so a bug and rejection is likely appropriate
[18:10] <kees> pitti, stgraber, nhandler, mterry: yikes, I saw all the unsub emails. should I just subscribe everyone back to it?
[18:11] <mterry> kees, seems right
[18:11] <lool> juliank, mvo_: I tested the oneiric package and a maverick build with the patch, both fixed the issue exposed by lp610820.py in the bug; thanks!
[18:29] <bdrung_> RoAkSoAx: you should mark your debdiffs as patches
[18:35] <lool> mvo_, juliank: Uploaded python-apt to natty-proposed and maverick-proposed -- pending approval etc.
[18:37] <RoAkSoAx> bdrung_: I usually do (and wait long to get sponsored :)) Today testing something different hehe
[18:41] <bdrung_> RoAkSoAx: i recommend to ask the cluster-glue maintainers to run wrap-and-sort
[18:56] <RoAkSoAx> bdrung_: will do
[18:56] <RoAkSoAx> thanks for looking at it
[18:57] <bdrung_> np
[19:01] <RoAkSoAx> bdrung_: guess he didn't look that there was a bug filed against cluster-glue cause my merge bug report is older than that
[19:01] <bdrung_> RoAkSoAx: yes
[19:02] <smoser> anyone know what colors mean at https://merges.ubuntu.com/main.html ?
[19:02] <bdrung_> smoser: IIRC the complexity
[19:02] <bdrung_> the greener the simpler
[19:04] <smoser> i'm sure its not perfect, but 'hostname' (merge at https://code.launchpad.net/~smoser/ubuntu/oneiric/hostname/merge-debian) surely woulldn't have earned a "pink"
[19:05] <bdrung_> right
[19:06]  * micahg thought it was based on priority/essential
[19:06] <bdrung_> that sounds more plausible
[19:06] <micahg> hostname is priority: required
[19:07] <cjwatson> yes, it's priority
[19:20] <smoser> i was looking to merge adduser , it has conflicts (http://paste.ubuntu.com/613393/) that are all translations (http://paste.ubuntu.com/613394/)
[19:21] <smoser> how should those be handled ? does launchpad translations affect that ? I'm complete newbie to translations.
[19:30] <geser> hmm, for fixing bug 788473, is a Conflicts enough or should it be Conflicts+Replaces?
[19:33] <micahg> geser: I think the policy manual says Breaks + Replaces in cases like this actually
[19:34] <micahg> geser: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
[19:47] <SpamapS> re libassuan .. isn't the bug that libassuan2-0 shouldn't have that file?
[19:48] <geser> SpamapS: yes and no, libassuan2 should get removed now from the archive but this doesn't automagically remove it from systems where is installed, libassuan0 needs to be told to replace libassuan2-0
[19:49] <SpamapS> Replaces should be enough then..
[19:50] <SpamapS> though yeah, Breaks + Replaces is probably a more complete solution.
[19:50] <geser> ideally libassuan2-0 should get removed from those systems having it installed
[19:59] <micahg> SpamapS: replaces just replaces files, not remove packages
[20:07] <SpamapS> micahg: right, he wants it off.. Breaks+Replaces it is then.
[20:10] <geser> thanks, Breaks+Replaces does what I need
[20:27] <micahg> bdrung_: BTW, libnet-ssleay-perl was promoted to main in oneiric, so it could remain a recommends of devscripts now
[20:31] <bdrung_> micahg: i will remember it for the next merge
[21:02] <NCommander> @pilot on
[21:02] <udevbot_> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[21:02] <NCommander> @pilot in
[21:02] <NCommander> *ALWAYS does that*
[21:02] <NCommander> bah
[21:02] <JFo> :)
[21:03] <NCommander> Anyone need anything sponsoring before I go fishing in the queues :-)?
[21:10] <geser> NCommander: bug 788473 if you want
[21:18] <ssweeny> hey folks, can anyone tell me if aufs is still the preferred unioning solution for the livecd?
[21:19] <broder> ssweeny: it is currently, although my understanding is that overlayfs is close to being merged into the kernel, at which point it sounds like we might switch to that
[21:20] <ssweeny> broder, cool, thanks. does it look like that will happen for oneiric?
[21:21] <broder> ssweeny: i couldn't say
[21:21] <ssweeny> broder, fair enough. appreciate the help
[21:33] <achiang4> micahg: ping, question about firefox in lucid. the only updates in recent history have been security updates, not anything like performance improvements or such, right?
[21:33] <achiang4> micahg: i'm trying to find the delta between 3.6.15 and 3.6.17
[21:34] <micahg> achiang4: well, they've been minor version updates, which include security fixes
[21:34] <micahg> achiang: firefox includes bug fixes as well
[21:34] <micahg> achiang: is there a regression?
[21:34] <achiang> micahg: no regression, don't be scared. :)
[23:05] <broder> Laney: did you test the backport in bug #622836 or just change the title?