[00:01] <Riddell> doko: hmm probably my fault with delay caused by my injury, I should take a look tomorrow
[00:02] <doko> Riddell, strange, it seems to be just installable. just did give it back
[00:13] <doko> Riddell, infinity looks like a temporary uninstallability. package started to build
[00:53] <infinity> doko: Does compiz correctly find its own lib with the build-dep dropped, you didn't need to mangle the CMake mojo at all?
[00:53] <infinity> doko: (I was about to look into the same thing, since webkit's getting close to done)
[00:54] <infinity> doko: Oh, I guess the successful builds say yes. ;)
[03:03] <broder> slangasek: interested in uploading http://web.mit.edu/broder/Public/libsigc++-2.0_2.2.10-0ubuntu2.debdiff ?
[03:03] <broder> (i'm writing up the corresponding debian bug report now)
[07:09] <micahg> pitti: did you decide chromium was sitting in -proposed long enough?
[07:09] <pitti> micahg: there was a v-done on it
[07:09] <micahg> orly?
[07:09] <pitti> was that wrong?
[07:11] <micahg> pitti: oh, that was on one of the other bugs in the changelog :), meh, I just never got to testing it on oneiric since I had to update it to a newer release anyways, there was an issue with M15 which I was hoping was fixed in a newer stable release that I haven't pushed yet
[07:11] <pitti> micahg: it seems Pedro tested it quite extensively
[07:11] <micahg> I think I pushed it to lucid though, and there was only the one complaint
[07:12] <micahg> pitti: ah, let's run with that then :)
[07:12] <pitti> micahg: so, should the SRU team generally refrain from pushing chromium until you say the word?
[07:12] <micahg> pitti: well, there were multiple bugs, not all v-done, I would think it's the same as any other SRU in that regard
[07:12] <micahg> pitti: but in general, it needs someone to ACK that it's been tested
[07:12] <micahg> in this case, i'd say pedro's testing can suffice
[07:18] <SpamapS> anybody want to try pounding on this website? curious to see how much punishment it can take and whether or not I can get juju to scale it up fast enough tomeet demand..
[07:18] <SpamapS> http://ec2-50-16-128-14.compute-1.amazonaws.com/
[07:19] <SpamapS> nijaba: ^^ your limesurvey charm BTW ;)
[07:54] <dholbach> good morning
[08:22] <Laney> bdmurray: Morning, looks like your ubuntu-reviewers automated notice talks about unsubscribing ubuntu-sponsors ;-)
[09:10] <pitti> so, the next precise_probs.html will look like http://people.canonical.com/~pitti/tmp/precise_probs.html
[09:13] <infinity> pitti: Including teeny-tiny fonts?
[09:13] <pitti> infinity: oh, are they too small in your browser?
[09:13] <pitti> I can bump them from x-small to small
[09:13] <pitti> but it reads quite fine here
[09:14] <infinity> I can read it, but I also have fairly good eyesight. :P
[09:16] <infinity> pitti: Also, when the apt message is "not going to be installed" instead of "not installable", you may want to drill down further to find the root cause.
[09:17] <pitti> indeed I also played with -o Debug::pkgProblemResolver=true, but it's not particularly helpful
[09:17] <pitti> but yes, trying to install both will give a better error message then
[09:17] <pitti> I'll look into this
[09:18] <infinity> If "apt-get install foo" gives you "Depends: bar, but it is not going to be installed", then "apt-get foo bar" will give you the next level of icky.
[09:18] <infinity> I also had some nice Perl lying around that does all this by parsing package files.
[09:18] <pitti> right, that's what I usually do
[09:19] <infinity> Was written by wouter to do sane dep-wait detection in sbuild.. And I never integrated it into the Ubuntu sbuild (don't ask me why).  I can dig it up.
[09:19] <infinity> I really should polish it off and get it in lp-buildd.
[09:19] <infinity> pitti: http://grep.be/blog/en/computer/debian/dep-wait-parser
[09:22] <pitti> infinity: at that point it's pretty much recursive britney :)
[09:22] <pitti> thanks for the link
[09:22] <infinity> pitti: Yeah, reuse of britney's code in britney would lead to similar results (and, I assume, less forking).
[09:22] <infinity> pitti: Was just example code. ;)
[09:23] <infinity> pitti: (And a reminder to myself to jam it into launchpad-buildd... Three years late isn't too late, is it?)
[09:54] <cjwatson> pitti: precise_probs> nice one
[09:54] <pitti> http://people.canonical.com/~ubuntu-archive/testing/precise_probs_hack.html
[09:54] <pitti> cjwatson: ^ more useful apt output now
[09:54] <pitti> kubuntu-full is still a mystery to me (it doesn't have apt output because it succeeds)
[09:55] <cjwatson> I didn't understand that either; I assumed it must be a bug somewhere inside britney, but couldn't see what
[09:55] <cjwatson> you probably need to step through it to figure that out
[09:55] <pitti> *nod*
[10:04] <pitti> jamespage: taking libxalan2-java FTBFS
[10:04] <jamespage> pitti, ack
[10:04] <pitti> infinity: ^ FYI (as you were the last uploader)
[10:22] <jamespage> pitti: OK if I grab the merge for debian-science?
[10:22] <pitti> jamespage: please
[10:22] <jamespage> pitti: great
[10:29] <Laney> does the britney run for precise_probs only consider main packages?
[10:29] <pitti> Laney: yes
[10:29] <Laney> I'm wondering if we can get the raw uninstallable data out somehow, even better for the whole archive
[10:30] <pitti> Laney: IIRC running it on the whole universe would take weeks, it's an O(n^2) or worse problem
[10:30] <cjwatson> I believe it's NP
[10:30] <Laney> yeah, it is
[10:30] <cjwatson> but there's debcheck already
[10:30] <pitti> Laney: apt-cache unmet with some filtering might do perhaps
[10:30] <cjwatson> http://qa.ubuntuwire.org/debcheck/
[10:31] <Laney> yeah
[10:31] <Laney> why isn't that used for probs?
[10:31] <cjwatson> err because different software stacks and no time
[10:31] <Laney> ok I was just wondering if one was different somehow
[10:31] <cjwatson> (also I don't know how long it takes to do a full run; precise_probs is hourly and needs to be quick
[10:31] <cjwatson> )
[10:32] <Laney> also "broken" on debcheck doesn't mean uninstallable
[10:33] <Laney> priority mismatch too
[11:24] <pitti> @pilot in
[11:25]  * dholbach hugs pitti
[11:25]  * pitti hugs dholbach
[11:26] <dholbach> :)
[11:31] <dholbach> siretart, hey Reinhard - ready to sync xine-lib? :)
[11:31] <dholbach> (just asking because it's in testing now and we should able to close 835437)
[11:31] <pitti> meh, armel buildds are severely underpowered now that we lent many of them to armhf
[11:37] <tsdgeos> pitti: i think you guys don't understand that poppler-data is not only for CJK languages
[11:38] <pitti> tsdgeos: I do understand it
[11:38] <tsdgeos> pitti: so? why cripple pdf viewing by default?
[11:38] <pitti> tsdgeos: but the chance that e. g. an English speaker needs it is quite small, whereas in the CJK area you pretty much need it all the time
[11:39] <pitti> tsdgeos: as I said, we don't put it on the CD because it's quite large and not needed in areas with latin languages
[11:39] <pitti> tsdgeos: we could certianly have language-selector install it for all languages, though
[11:39] <pitti> that should provide a better compromise
[11:39] <tsdgeos> "an English speaker needs it is quite small" <- why?
[11:40] <pitti> tsdgeos: well, because they don't usually read Chinese documents?
[11:40] <tsdgeos> and as i told you
[11:40] <tsdgeos> you do not understand that poppler-data is not only for chinese documents
[11:40] <tsdgeos> there is English documents
[11:40] <tsdgeos> that need it
[11:40] <tsdgeos> to be properly viewed
[11:40] <pitti> cmap-adobe-{gb1,cns1,korea1,japan1,japan2}
[11:40] <tsdgeos> yes
[11:40] <tsdgeos> that's just a mapping
[11:40] <pitti> all these encodings apply to CJK langauges only
[11:40] <tsdgeos> no
[11:40] <tsdgeos> it's a mapping
[11:41] <tsdgeos> it's "usually" used for CJK languages only
[11:41] <pitti> right
[11:41] <pitti> e. g. I never looked at a document which needed it
[11:41] <tsdgeos> well
[11:41] <tsdgeos> i have
[11:41] <tsdgeos> differene i'm the poppler maintaner and you are not ;-)
[11:41] <pitti> yes, I believe you
[11:42] <pitti> I did NOT say that no non-CJK speaker would ever need it
[11:42] <pitti> I said that the chance is considerably smaller
[11:42] <tsdgeos> ok
[11:42] <pitti> so we install it from the network for langauges with a high chance of needing them
[11:42] <tsdgeos> fair enough
[11:42] <pitti> and as I said, we could extend that to install it for all languages
[11:43] <pitti> it's an additional 11 MB for everyone then, which will rarely, if ever, be used, but it would provide that support for legacy encodings
[11:44] <tsdgeos> it's up to you
[11:44] <tsdgeos> i can only say that there is regular bug reports about people not being able to read documents because poppler-data is not installed
[11:44] <doko_> libproxy (0.3.1-2ubuntu2) natty; urgency=low
[11:44] <doko_>   * debian/control:
[11:44] <doko_>     - Drop KDE from build-deps on ARM to workaround FTBFS due to KDE stack
[11:44] <doko_>       being broken due to toolchain issues. This will be reverted after
[11:44] <doko_>       Alpha 1 (LP: #683072)
[11:44] <doko_>  -- Michael Casadevall <mcasadevall@ubuntu.com>  Mon, 29 Nov 2010 16:00:27 -0800
[11:44] <tsdgeos> i only wanted you guys to know it
[11:44] <tsdgeos> if you can live with that
[11:44] <tsdgeos> good
[11:44] <doko_> we need a better way to track work-arounds
[11:45] <pitti> tsdgeos: right, thanks; I'll go with installing it for all languages, as it keeps coming up occasionally
[11:45] <seb128> tsdgeos, hi
[11:45] <tsdgeos> seb128: hi
[11:45] <seb128> tsdgeos, could the pdf viewer detect when opening a document that poppler-data is needed to view some glyphs?
[11:45] <seb128> tsdgeos, like could we do some "install on demand" in i.e evince?
[11:46] <tsdgeos> seb128: yes it could
[11:47] <tsdgeos> but then you'd need to add that
[11:47] <tsdgeos> to pdftotext too
[11:47] <tsdgeos> :D
[11:49] <seb128> tsdgeos, ;-)
[11:51] <doko_> pitti, did you fix openoffice.org for armhf as well?
[11:51] <pitti> doko_: yes, it wasn't an exclusion but an inclusion
[11:51] <pitti> doko_: i. e. -base only gets built on the arches that libo-base actually exists for, i. e. i386 amd64 powerpc
[11:52] <pitti> seems to make more sense to me
[11:52] <pitti> even if it exists on arm* some day, the oo.o-base transitional isn't needed as oo.o-base never existed on arm* before
[11:52] <pitti> the oo.o source can go away entirely after precise
[11:54] <infinity> pitti: Erm, you fixed it by making the source not build on arm at all?
[11:54] <pitti> infinity: yes, so that it'll become NBS
[11:54] <infinity> pitti: Oh, derp.  It's all arch:all.
[11:54] <infinity> pitti: Nevermind. :)
[11:54] <pitti> infinity: not any more :)
[11:54] <infinity> pitti: I was just wondering why there were only 3 arches building, then brain kicked in.
[11:54] <pitti> it should be NBS after the next publisher
[11:55] <pitti> then I'll remove it
[11:55] <infinity> pitti: Yeah, I meant "all the packages arm cares about are arch:all".
[11:55] <cjwatson> infinity: ~ubuntu-archive/public_html/armhf/ doesn't seem to be owned by ubuntu-archive throughout
[11:56] <infinity> cjwatson: I've been rsyncing to it as me, so yeah, seems possible.
[11:56] <cjwatson> infinity: could you 'mkdir -p dists/precise/main/debian-installer/binary-armhf && touch dists/precise/main/debian-installer/binary-armhf/Packages' in there, please?
[11:56] <cjwatson> oh, and possibly regenerate Release
[11:57] <infinity> My hackish Release gen script won't do that.  But can fix.
[11:57] <cjwatson> that'll help the debian-installer build
[11:57] <cjwatson> Ah, if you've scripted it, possibly best that I couldn't write to it directly.
[12:04] <infinity> cjwatson: Regenerating now.
[12:09] <cjwatson> pitti: I fixed the ordering in archive-reports a bit so that the chdist update is guaranteed to complete before precise_probs is generated, since you're relying on that now
[12:09] <pitti> cjwatson: oh, thanks
[12:10] <shnatsel> cjwatson: thanks again for your help on the doc about building large-scale derivatives! Really appreciated.
[12:11] <cjwatson> glad it helped
[12:11] <infinity> cjwatson: That look good?
[12:11] <cjwatson> infinity: should be, I'll give d-i a shot again
[12:12] <infinity> cjwatson: Was it just barfing because it expects a main/d-i component matching every line in sources.list?
[12:12] <cjwatson> yep
[12:12] <cjwatson> and it's easier to adjust the bootstrap archive for that than to filter it out in d-i
[12:12]  * infinity nods.
[12:12] <cjwatson> (and arguably less wrong)
[12:18] <infinity> cjwatson: And... I broke my own Releases file somehow.
[12:19] <cjwatson> wuh
[12:20] <cjwatson>  e659416b35f5f28f15a677eaa8411ba5    1666282 main/binary-armhf/Packages
[12:20] <cjwatson>  d41d8cd98f00b204e9800998ecf8427e  0 main/debian-installer/binary-armhf/Packages
[12:20] <infinity> Yeah, wuh indeed.
[12:20] <cjwatson> two missing spaces maybe?
[12:20] <infinity> Maybe?  Is it that picky?
[12:20] <cjwatson> oh, I see
[12:20] <cjwatson> SHA256:
[12:20] <cjwatson>  22a0ff9ffeb9ff014eec2543adeb78a71d810fd64969fbf4a24af4b94a71ed26    1666282 main/binary-armhf/Packages
[12:20] <cjwatson>  e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  1666282 main/binary-armhf/Packages
[12:20] <cjwatson> pretty sure that's not what you meant
[12:20] <infinity> Oh, err.  Oops.
[12:20] <infinity> Except, that shouldn't matter.
[12:20] <infinity> Cause it's not checking the d-i bits...
[12:21] <infinity> At that point.
[12:21] <cjwatson> But it might well pick the last of two claimed distinct SHA256 sums for a given file.
[12:21] <cjwatson> Which would make the checksum of main/binary-armhf/Packages incorrect.
[12:21] <infinity> Oh.
[12:21] <infinity> I missed the duplicate filename. :)
[12:22] <infinity> la la la.
[12:22] <cjwatson> Should reduce the build queue length really quickly, though.
[12:22] <infinity> And how!
[12:24] <infinity> You'd think lillypilly would be faster than my Panda for this.
[12:24] <shnatsel> pitti: I came here to bug you about bug 899568, but you've approved the merge before I even pinged you ^^ Thanks!
[12:24] <infinity> I should have just hand-edited the Release file. :P
[12:24] <infinity> (But wanted to make sure the script was right)
[12:24] <pitti> shnatsel: heh :) thanks
[12:24] <pitti> shnatsel: I also uploaded the package
[12:24] <shnatsel> oh, that's why it's "fix released" already
[12:25] <shnatsel> pitti: twice the thanks then! :D
[12:25] <infinity> Oh, there's a germinate eating all my CPU.
[12:25] <infinity> Kay, fixed.
[12:25] <pitti> shnatsel: see /topic, I'm patch pilot ATM :)
[12:25] <cjwatson> Maybe I'll convert update-germinate to something like the prospective Launchpad multi-germinate magic at some point.
[12:26] <cjwatson> Although I think it spends a lot of its time writing out giant rdepends listings anyway ...
[12:29] <infinity> cjwatson: That seems happier.
[12:31] <infinity> cjwatson: And d-i is happy with the fake indexes. \o/
[12:31] <infinity> .. and fails right after.
[12:32] <infinity> Rather mysteriously and non-verbosely...
[12:33] <cjwatson> Not a giant surprise.  (Is there a porter chroot around somewhere?  I was flying blind.)
[12:33] <infinity> I don't think lamont's got one on scheat yet.
[12:33] <infinity> You could ask nicely, now that precise/armhf is actually debootstrappable.
[12:33] <infinity> There's a ticket for it.
[12:34] <infinity> RT#49685
[12:34] <cjwatson> Maybe it doesn't like empty Packages files or something
[12:34] <infinity> You want some udebs in there for the lolz?
[12:34] <infinity> I happen to have some.
[12:35] <infinity> Though that sounds a lot like writing an actual apt-ftparchive config.
[12:35] <lamont> infinity: it's debootstrappable now?
[12:35] <infinity> Or, I could just generate a one-off.
[12:35] <infinity> lamont: Should be.
[12:35] <infinity> lamont: But please don't replace my buildd chroots. :P
[12:35] <lamont> I shall attempt this
[12:35] <cjwatson> infinity: It really ought not to need them.  It's a bug if it does.
[12:35] <lamont> infinity: are they dirty dirty little chroots/
[12:35] <infinity> lamont: Not really.  Not anymore. :P
[12:36] <infinity> lamont: But still, I'll let you know when we're ready to swap them for scripted versions.
[12:36] <cjwatson> infinity: In fact, I see where it might be.  I can test it once lamont's done. :-)
[12:36] <infinity> lamont: porter chroot on scheat, however, would be lovely.
[12:36] <cjwatson>                 grep-dctrl -! -rFKernel-Version . $KV_COND "$packages" > "$packages.tmp"
[12:36] <cjwatson> ^- probably needs || true
[12:37] <infinity> That seems likely.
[12:37] <infinity> Shouldn't that fail on building against proposed/updates too?
[12:37] <infinity> Or do we never rebuild against post-release pockets until we have new kernels? :P
[12:37] <infinity> (ie: we get lucky)
[12:38] <cjwatson> That's probably so.
[12:41] <infinity> lamont: Oh, not to put undue pressure on you or anything, but Nafallo led me to believe that rescuing gourd and acorn would have to be a group effort between the two of you.  If you could make that happen, I'll love you forver (until the next time I want something).
[12:42] <lamont> you are so ephermal that way
[12:42] <Nafallo> infinity: only gourd.
[12:42] <infinity> Nafallo: Oh, you can make acorn happy all by yourself?
[12:42] <infinity> Nafallo: Even better.
[12:42] <Nafallo> infinity: potentially.
[12:43] <Nafallo> infinity, lamont: nvm. gourd is happy this time.
[12:43] <Nafallo> lamont: ^-- cleanup of these two however.
[12:44] <infinity> Nafallo: Oh, huzzah.
[12:44] <infinity> adconrad@cocoplum:~$ suite-diff.py /srv/launchpad.net/ubuntu-archive/ubuntu/dists/precise/main/binary-arm*/Packages.gz gt | wc -l
[12:44] <infinity> 243
[12:44] <infinity> ^-- Getting there.
[12:46] <lamont> nasl has 109
[12:46] <infinity> Thanks.
[12:47] <infinity> Can worry about the rest when we do the mass 110 rollout.
[12:47] <infinity> Which will hopefully be after armel is done building several multi-day builds... :/
[12:48] <infinity> In retrospect, stealing all the pandas for armhf may have been cruel.
[12:48] <lamont> armel still has nasl... :)
[12:48] <infinity> Yeah. ;)
[12:48] <infinity> I gave it to armel when I realised it had an outdated lp-buildd.
[12:48] <infinity> I'll leave it there for now.
[12:49] <infinity> And maybe give them one more too.
[12:50] <cjwatson> infinity: Better d-i uploaded now, though it'll dep-wait on a few u-boot-ish things that haven't been arwoofed yet.
[12:51] <infinity> arwoofication incoming shortl.
[12:51] <infinity> y
[12:53] <infinity> lamont: Say, where's the 10th Panda?
[12:53] <infinity> lamont: Oh, that's the one you asked Nafallo to wiggle cables on, right?
[12:53] <lamont> altais hates us all
[12:53] <infinity> Check.
[12:53] <lamont> caph is the 11th though
[12:53] <cjwatson> K observed (or possibly passed on an observation) this morning that Scotland now has more pandas than Tory MPs
[12:53] <cjwatson> though that's a different kind of panda ...
[12:53] <lamont> heka also hates us all
[12:54] <lamont> cjwatson: heh
[12:54] <infinity> adconrad@scheat:~$ dchroot -c precise-armhf
[12:54] <infinity> (precise-armhf)I have no name!@scheat:~$
[12:54] <infinity> Nice hostname. ;)
[12:54] <lamont> I suspect it may be true for our kind of pandas, too
[12:54] <lamont> infinity: I'm still building it, and your bits are clearly broken. :-p
[12:54] <infinity> lamont: They are?
[12:55] <lamont> infinity: please score libnss-db through the roof
[12:55] <infinity> Oh, libnss-db.  Right.
[12:56] <infinity> lamont: Err, it's built.
[12:56] <infinity> lamont: 6 days ago.
[12:56] <infinity> lamont: Which would explain why it's installed in the chroot. :P
[12:56] <infinity> lamont: Any more simple requests?
[12:57] <lamont> I just installed it manually :-p
[12:57] <infinity> Sure, blame my archive for your script.
[12:57] <infinity> I bet it was special-cased out for armhf by dannf.
[12:58] <siretart> dholbach: thanks for the reminder, I can do that in a minute
[13:02] <cjwatson> lamont: I don't suppose I could get RT#49745 (germinate/mawson) done too?  I have a dependency stack a mile deep for this and would like to start whittling it away. :-)
[13:02] <cjwatson> Or is that a webops thing?
[13:03] <mthaddon> nope, that's a GSA thing
[13:03] <mthaddon> cjwatson: anyone in #canonical-sysadmin should be able to help
[13:03] <mthaddon> actually...
[13:04] <mthaddon> yeah, I'd better defer to the GSAs there
[13:05] <cjwatson> k
[13:05] <lag> A little help: My panel resets to default on reboot and I can't change my clock display settings (related?)
[13:09] <infinity> doko_: Why the build-dep change for libproxy?
[13:09] <doko_> mozjs not in main
[13:10] <infinity> Ahh, didn't notice it getting dropped.  Fair enough.
[13:11] <infinity> And after I put in a whole 5 minutes of effort to make it build, too.
[13:17] <siretart> dholbach: done
[13:22] <doko_> Daviey, what's the story about squid/squid3? I assume squid3 is used, but squid is still in the archive (and fails to upload for armhf). should it be removed?
[13:25] <doko_> infinity, do you work on u-boot-linaro?
[13:25] <chrisccoulson> pitti, you might like bug 900280 ;)
[13:25] <chrisccoulson> is there any way to blacklist all packages with pkg-mozext-maintainers as the maintainer?
[13:26] <cjwatson> Not as yet.
[13:26] <chrisccoulson> i feel like this is a game of cat and mouse every cycle now
[13:26] <cjwatson> I thought I saw a bug for that earlier
[13:26] <cjwatson> I mean for this batch of removals
[13:26] <cjwatson> We may be able to do more fine-grained blacklisting once we have autosyncing moved over to the API, but that still has at least one blocking Launchpad bug in the way.
[13:27] <chrisccoulson> oh, i did look and didn't see any
[13:27] <cjwatson> chrisccoulson: bug 891484
[13:27] <cjwatson> Overlapping set of packages.
[13:27] <chrisccoulson> oh, it doesn't contain most of them, that's why i didn't see it
[13:28] <infinity> doko_: I was going to get jcrigby to to the Linaro stuff, but if he doesn't have the time, I will.
[13:28] <Daviey> doko_: fails to upload?  As in a Launchpad buildd issue?
[13:28] <Daviey> doko_: squid is planned to still be in universe, with squid3 in main.  The was the last plan i heard.
[13:28] <infinity> Daviey: Fail to upload usually means a package building a binary older than what's in the archive.
[13:29] <Daviey> Ahhh, i'm going to bet there is a transitional package in squid3 causing this
[13:29] <infinity> Daviey: In other words, if you want that source around, kick out the offending binaries that were replaced elsewhere.
[13:29] <Daviey> infinity: thanks
[13:30] <Daviey> doko_: I think squid can actually go, but i'd like to confirm with zul who was mostly handling the transition - i believe.
[13:32] <cjwatson> That's what I understood to be the plan when I NEWed squid3, I think
[13:40] <pitti> chrisccoulson: heh, yay cleanup
[13:43] <pitti> debfx: ah, so your upload of step counteracts my upload of meta-kde :) so we can probably revert the latter
[13:43] <doko_> Daviey, yes launchpad issue, both packages build the squid binary
[13:44] <debfx> pitti: first let's see if it really builds ;)
[13:44] <infinity> debfx: It builds in experimental on armel.
[13:44] <infinity> debfx: I like our odds.
[13:45] <cjwatson> doko_: Not a Launchpad issue in the sense that this isn't a Launchpad bug, though.
[13:46] <debfx> infinity: Debian's Qt uses OpenGL on all architectures so that's no indication that it builds on Ubuntu
[13:46] <infinity> debfx: Ahh.
[13:46] <zul> squid can go
[13:48] <infinity> debfx: https://launchpad.net/ubuntu/+source/step/4:4.7.3-0ubuntu2/+build/2986704
[13:48] <infinity> debfx: Looks good.
[13:48] <pitti> cjwatson, doko_: docbook5-xml is a newer version of docbook-xml, docbook-xsl b-deps on that now; just data files; I'd just promote it, or do you want a full MIR?
[13:49] <infinity> pitti: step on armhf built.  Probably fair to assume armel will too.
[13:50] <dholbach> siretart, thanks! :)
[13:50] <doko_> pitti, sure
[13:55] <pitti> superm1: can you please have a look at https://code.launchpad.net/~pitti/mythtv/font-rename/+merge/83047 ?
[14:06] <Daviey> pitti: I believe it has landed, http://bazaar.launchpad.net/~mythbuntu/mythtv/mythtv-fixes/revision/450
[14:06] <pitti> Daviey: oh, thanks; so apparently it wasn't "formally" merged, closing my MP then
[14:07] <Daviey> pitti: I think it was proposed against lp:mythtv rather than, lp:~mythbuntu/mythtv/mythtv-fixes
[14:10] <Daviey> pitti: So, i think Mario rebased, which is why it didn't auto close.
[14:10] <pitti> Daviey: anyway, as long as it's fixed, I'm happy :)
[14:10] <Daviey> \o/
[14:10] <pitti> just wanted to prevent longer-term uninstallability
[14:47] <pitti> @pilot out
[14:59] <pitti> cjwatson: is there an easier trick to build britneymodul.so  than scp'ing the whole dir to local workstation, building there, and scp'ing back?
[14:59] <pitti> (lillypilly doesn't have apt -dev stuff)
[15:00] <infinity> pitti: My guess is that, until you started hacking on it, it hadn't been rebuilt in years. :P
[15:00] <infinity> (But I could be wrong)
[15:01] <pitti> 240522 2011-11-23 17:38 britneymodule.so
[15:01] <pitti> not _that_ long ago :)
[15:01] <infinity> I stand corrected. ;)
[15:01] <infinity> Or sit.
[15:01] <pitti> I'm ok with the rsync-twice dance, just wondered whether I'm missing something obvious
[15:02] <infinity> You could be missing the part where Colin just has a local tree for it and builds and pushes in one direction.
[15:02] <infinity> (again, guessing)
[15:02] <pitti> probably that, yes
[15:02] <pitti> kubuntu-meta 1.241 kubuntu-full (amd64) uninstallable
[15:03] <pitti> I want to see why it's telling this lie
[15:04] <pitti> ooh, I bet I know
[15:04] <pitti> it depends on nvidia-current
[15:04] <pitti> main -> restricted dependency
[15:04] <infinity> Ew.
[15:04] <pitti> well, recommends:
[15:04] <infinity> So, not a lie.
[15:04] <infinity> Or, that reports on recommends?
[15:05] <pitti> and it sounds wrong, too -- this would break all non-nvidia systems
[15:05] <infinity> Yeah...
[15:05] <infinity> Need to get 1278 MB of archives.
[15:05] <infinity> After this operation, 3399 MB of additional disk space will be used.
[15:05] <infinity> Note to self: never actually install kubuntu-full.
[15:07] <pitti> debfx, ScottK, Riddell: ok if I drop this: dvd: * (nvidia-current)
[15:07] <pitti> debfx, ScottK, Riddell: it breaks non-nvidia systems (as it diverts libGL) and also is a main -> restricted dependency which counts as uninstallable
[15:08] <debfx> pitti: yes and fglrx too
[15:09] <pitti> debfx: thanks for confirming; seed updated, rebuilding -meta now
[15:17] <doko_> Daviey, MIR for suds needed (pulled in by fence-agents, which looks serverish)
[15:20] <debfx> pitti: what's the exact result of the image size debate this cycle? can each flavor decide if they want 750 MB images?
[15:21] <pitti> debfx: I guess so; sabdfl said he was ok with 750 MB images, but for ubuntu itself we want to try and stick to 700 MB for precise
[15:22] <Daviey> doko_: that is raised, isn't it?
[15:23] <Daviey> doko_: bug 898268
[15:23] <doko_> Daviey, yes, but incomplete, and needed for armhf
[15:23] <Daviey> doko_: ok
[15:29] <debfx> pitti: so ubuntu desktop is sticking with the 700 MB as the default installation medium? would it be an option for kubuntu to have a 700MB cd image but use a 1.5 GB usb/dvd image as the default?
[15:29] <pitti> debfx: I guess so
[15:30] <debfx> ok, thanks
[15:36] <jbicha> over 900,000 bugs!
[15:36] <pitti> jamespage, jibel: do you see what's wrong in https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/lastFailedBuild/ or https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/lastFailedBuild/PROFILE=lts-server-amd64,label=upgrade-test/ ?
[15:37] <pitti> for the first URL, I looked at the "ubuntu" profile
[15:37] <pitti> I can't see any error in apt-term.log or main.log
[15:38] <pitti> ooh, it's probably the tests after that
[15:38] <pitti> console output has some stuff
[15:40] <jamespage> pitti: it looks like something went wrong during the test to me "Connection to localhost closed by remote host...."
[15:40] <jamespage> https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/lastFailedBuild/PROFILE=ubuntu,label=upgrade-test/console
[15:41] <jibel> pitti, server doesn't restart after upgrade,  it can't find the rootfs anymore after the upgrade
[15:42] <jibel> jamespage, ubuntu upgrade is fine, it just the status on the public jenkins that is not updated.
[15:43] <jibel> jamespage, it failed last night because I tried to run 2 tests simultaneously on the same server but there was conflicting ports to communicate with the testbed.
[15:44] <pitti> ah, thanks
[15:51] <psusi> smoser: I've worked up some patches to util-linux now for the online resize support... including a simple wrapper command
[15:52] <psusi> smoser: also an update mode to partx
[15:53] <smoser> psusi, you're too kind.
[15:53] <smoser> that is awesome.
[15:53] <psusi> hehe
[15:53] <smoser> do you have a bug for this ? or blueprint or something?
[15:54] <psusi> it just dawned on me that is kind of the canonical reference implementation of the user side of the blkpg ioctls
[15:54] <psusi> I filed a bug against the kernel and attached the patch asking that it be added, and I have proposed a branch of parted for merging
[15:55] <smoser> bug number ?
[15:56] <psusi> actually I also filed one to fix the loopback device to clean up partitions when you detach the backing file.  bugs #899717 and #899723
[15:57] <smoser> psusi, are/were you going to send util-linux upstream ?
[16:01] <psusi> smoser: going to as soon as I finish a bit more testing
[16:02] <psusi> smoser: but with these changes, you will either be able to run partx -u /dev/sda or respart /dev/sda start size
[16:04] <psusi> smoser: after using sfisk to update of course
[16:04] <cjwatson> pitti: it's annoying; I think I built it in a porter-amd64 chroot.
[16:04] <psusi> so basically when sfdisk complains about BLKRRPART, just run partx -u and you're done
[16:05] <cjwatson> [5~/wg 295
[16:05] <cjwatson> gah
[16:05] <Laney> impressive number of windows
[16:06] <Daviey> or a really intelligent walking across the keyboard.
[16:06] <l3on> cjwatson, hey! :) ... I'm looking at libparse-http-useragent-perl ... last entry in changelog says:
[16:06] <l3on>   * Pre-Depends: dpkg (>= 1.15.6) for xz compression support.  Needed until
[16:06] <l3on>     after Ubuntu 12.04 LTS.
[16:07] <l3on> Do you think we still need it ?
[16:07] <stgraber> l3on: that's needed for 10.04 => 12.04 upgrade IIRC
[16:07] <psusi> xz is required anyhow
[16:07] <stgraber> l3on: to force dpkg to upgrade itself first before trying that one
[16:07] <psusi> dpkg pre-depends on it
[16:08] <l3on> ah ok, cjwatson I can take it ? (last change has done by you)
[16:08] <l3on> thanks stgraber and psusi  :)
[16:08] <cjwatson> l3on: When I said we needed it until after 12.04 LTS, I meant it.  Please keep that change.
[16:08] <cjwatson> psusi: You missed the point, I'm afraid.
[16:09] <psusi> cjwatson: I figured that a moment later ;)
[16:09] <cjwatson> l3on: If you dropped that change, then Launchpad would refuse to accept the upload of any binaries built from that package.
[16:10] <cjwatson> l3on: I left that very specific note in the changelog so that people wouldn't need to ask when they could drop it.
[16:11] <l3on> thanks cjwatson :)
[16:13] <psusi> smoser: by the way, yesterday I played around with getting my desktop to boot without an initrd.. got boot time on my ssd down to just under 8 seconds from about 12... had to build the achi module into the kernel though, and of course, without the uuid kernel patch, the root= argument is fragile...
[16:13] <cjwatson> l3on: You can take that merge if you like.
[16:13] <l3on> I took :)
[16:13] <smoser> yeah. thats cool.
[16:15] <psusi> smoser: I was wondering about those cloud images... what vm are they running under?  qemu?  and when they boot, do they use grub, or just directly load the kernel?
[16:17] <tedg> What's the default optimization level in Ubuntu?  -O2?
[16:19] <smoser> psusi, they boot from grub. and will boot under kvm or xen (xen with pv-grub)
[16:20] <smoser> https://help.ubuntu.com/community/UEC/Images#Ubuntu_Cloud_Guest_images_on_Local_Hypervisor_Natty_onward
[16:20] <smoser> you can play with an image by following that.
[16:24] <psusi> smoser: could probably shave off a bit more boot time skipping grub
[16:25] <smoser> skipping ?
[16:26] <psusi> I'm pretty sure qemu-kvm had a switch where yuo can pass it the kernel image to boot directly rather than have it load and execute the MBR in 16 bit mode
[16:32] <smoser> psusi, yes, you can.
[16:33] <smoser> and that is actually how uecalyptus loads... but then you have to deal with the host knowing the kernel parameters of the guest, and you can't (easily) update your guest kernel and reboot.
[16:34] <smoser> so... grub makes lots of sense. timeout is zero on EC2 images, but we do have a 5 second (i think) timeout in the images by default. that could be addressed. the reason is to allow the user to get in if they're booting in kvm. thats less important now than it used to be, thoug. previously the only way you could reasonably use the image in kvm was to modify the command line parameters.
[16:35] <psusi> true...
[16:38] <doko_> bryceh, you did merge libdvdread, but didn't fix the ftbfs on amd64
[16:40] <pitti> cjwatson: so kubuntu-full still pulls in sl-modem-daemon and bcmwl-kernel-source in the "dvd" seed, but these packages are in restricted
[16:40] <pitti> cjwatson: this is what makes kubuntu-full uninstallable
[16:41] <pitti> cjwatson: I don't think bcmwl should be in that metapackage, as the installer will automatically pull it, right?
[16:41] <pitti> cjwatson: should these two perhaps go in to dvd-live?
[16:43] <pitti> cjwatson: handled bcmwl, already in kubuntu's ship-live
[16:44] <pitti> so I wonder what to do with sl-modem
[16:46] <pitti> moving it to dvd-live would take it out of kubuntu-full and should fix the problem
[16:53] <doko_> didrocks, please could you look at the unity-lens-files build failure on armhf? such a pkgconfig file doesn't exist. https://launchpadlibrarian.net/86366105/buildlog_ubuntu-precise-armhf.unity-lens-files_0.6.12-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:53] <doko_> should fail on intel too?
[16:54] <jimbauwens> Anyone here that works on the Ubuntu installer?
[16:54] <didrocks> doko_: yeah, we discusssed it with lool, the new zg doesn't contain it and it will be fixed in the next u-l-f upload
[16:54] <doko_> didrocks, when about?
[16:54] <didrocks> doko_: which is not there yet, but will happen at some point
[16:54] <didrocks> doko_: next unity release, still under discussion when it will be
[16:55] <doko_> didrocks, could it be fixed for the armhf bootstrap in the mean time?
[16:55] <didrocks> doko_: I can distro-patch which is a little bit ackward for me right now, but if you need it urgently…
[16:56] <doko_> didrocks, not urgent, but then the gnome desktop would be complete :-)
[16:57] <didrocks> doko_: will do it shortly then, if we can't release that week
[16:57] <doko_> thanks
[16:57] <ogra_> would surely speed us up in starting to build images
[16:57]  * infinity picks up the librest FTBFS.
[16:57] <didrocks> yw
[16:57]  * ogra_ was glaring at that ... weird xml trash
[16:58] <infinity> ogra_: Nah, it's just stuff trying to hit the internet.
[16:58] <infinity> ogra_: Easy fix.
[16:58] <ogra_> oh, i probably titnd scroll far enough up yet :)
[16:59] <didrocks> ogra_: you have weird stuff to glare at :)
[16:59] <ogra_> heh
[16:59] <pitti> jamespage: FYI, fixing the python3-gobject NBS
[17:00] <pitti> jamespage: and I'll commit the python-gobject-cairo bits into ubiquity/software-center bzr
[17:01] <pitti> ah, ubiquity already has it
[17:02] <pitti> mvo, tremolux: I can't commit to lp:software-center/5.0; can you please s/python-gobject-cairo/python-gi-cairo/ ?
[17:04] <pitti> ok, really leaving now, good night!
[17:04] <tremolux> pitti: hello! yep, will do
[17:04] <tremolux> pitti: have a good night  :)
[17:04] <jimbauwens> The ubuntu installer sets too big swap partitions on modern machines. The system will become quite unstable before it can even use the half of it.(for most applications)
[17:04] <mvo> pitti: why for 5.0? does this need to go into oneiric?
[17:06] <jimbauwens> Should I make a report on launchpad about this?
[17:07] <jimbauwens> s/sets/creates/
[17:07] <doko_> cjwatson, infinity: is there an easy way to look for packages in main, which are not yet built on armhf? promoted packages keep their low build score, and starve to build ...
[17:21] <tremolux> pitti: if you are still around, about your request, seems you mean for us to change the dep in trunk, no in the 5.0 (Oneiric) branch, correct?
[17:24] <seb128> tremolux, he left it seems but yes, that's for precise only
[17:24] <seb128> tremolux, the renaming didn't happen in oneiric ;-)
[17:24] <tremolux> seb128: yep, thanks for confirming!  :)
[17:37] <cjwatson> pitti: dvd-live has a confusing name - that's analogous to live (i.e. on the live filesystem) rather than to ship-live (i.e. in a pool alongside the live filesystem)
[17:38] <cjwatson> pitti: we could abuse or rename dvd-live-langsupport, if it's not suitable for ship-live ...
[17:39] <cjwatson> doko_: I guess this is what quinn-diff is for, although I don't know if anyone runs it for Ubuntu
[17:40] <cjwatson> doko_: shame the build queue doesn't seem to be exposed in the API
[18:23] <doko> Laney, https://launchpadlibrarian.net/86705706/buildlog_ubuntu-precise-armhf.gnome-desktop-sharp2_2.26.0-6_FAILEDTOBUILD.txt.gz
[18:26] <infinity> I'll never understand why people think it's sane to patch *after* you autoreconf.
[18:28] <Laney> infinity: it's a legacy ltmain.sh --as-needed patch
[18:28] <Laney> doko: thanks, I'll just replace it with dh_autoreconf
[18:48] <lifeless> I have a q about apt & debtags: do the tags need to be in the packages file, or is there a lookaside file that can be used ?
[18:48] <broder> i didn't think debtags were published in the main archive at al
[18:49] <lifeless> they are not currently
[18:49] <broder> oh, is that changing?
[18:49] <lifeless> What I want to know is where apt etc look for them today
[18:50] <lifeless> software centre would like them published; we're trying to see what can be done
[18:50] <tumbleweed> on debian, they are in Packages
[18:50] <Laney> doko: uploaded, sync when LP knows about -7
[18:50] <Laney> or I will
[18:51] <enrico> lifeless: apt looks for them in the Packages file; software-centre uses apt-xapian-index for searches, and apt-xapian-index can be fed using plugins
[18:51] <enrico> lifeless: however, I'm not sure what software-centre does for visualization of tag data
[18:51] <lifeless> enrico: doesn't today as they aren't published
[18:51] <enrico> lifeless: tags can be extracted from apt-xapian-index rather easily
[18:51] <lifeless> enrico: so apt can't use a lookaside file ?
[18:52] <enrico> lifeless: a-x-i can read them from /var/lib/debtags/package-tags using its debtags.py plugin, for example
[18:52] <enrico> lifeless: apt can't use a lookaside file afaik
[18:52] <enrico> lifeless: for the record, the procedure to extract them from a-x-i is to look for all terms starting with 'XT' in a document
[18:53] <enrico> lifeless: the document can be looked up searching the term 'XPpackagename'
[18:53] <lifeless> https://dev.launchpad.net/LEP/DebTags
[18:54] <lifeless> that lep talks about using a separate file
[18:54] <lifeless> I guess based on this discussion that that is science fiction?
[18:55] <enrico> lifeless: I don't know APT or software-centre's code enough to be able to tell, I recon you'd have to talk to the respective authors
[18:56] <enrico> lifeless: tags don't change that often, so pdiffs would have little size difference with/without tags
[18:57] <enrico> lifeless: but I'm more the right person for tag algorithms, or for setting up tag feeds from Debian to Ubuntu and vice versa, for example, rather than for apt or software-centre work
[18:58] <slangasek> I don't believe Ubuntu is currently doing pdiffs at all, though
[18:58] <slangasek> or is that part of the proposal?
[18:58] <lifeless> its not
[18:58] <enrico> slangasek: it's not. Sorry for mentioning them, I didn't know Ubuntu wasn't doing them
[18:58] <lifeless> the question revolves around the cost of change for the publisher
[18:59] <slangasek> yes, we'd like faster publishing, not slower, please ;)
[18:59] <lifeless> adding in a new table, API's to maintain it, and retuning the publisher to snarf the additional data is a bit of work
[18:59] <lifeless> doing an async snarf-and-emit of a tag set to a separate unsigned file would have less impact and be easier I suspect
[19:01] <lifeless> the more we shove into the publisher the tighter the critical section is
[19:57] <iamfuzz> any openssl gurus about?  I'm having some linkage troubles
[20:01] <Ampelbein> iamfuzz: Might be useful to include such things as error message, linker command etc ;-)
[20:02] <iamfuzz> Ampelbein, http://pastebin.com/dNNw98sf
[20:02] <iamfuzz> :-)
[20:02] <iamfuzz> it's a strange thing. It never happened against 0.9.8
[20:02] <iamfuzz> but the symbols ARE  present in libcrypto.a
[20:03] <iamfuzz> and -lcrypto is being passed
[20:03] <cjwatson> link order matters
[20:03] <Ampelbein> iamfuzz: objects go before libs
[20:03] <cjwatson> you need to put -l<foo> after anything that uses symbols from it
[20:04] <roadmr> foo :)
[20:04] <cjwatson> this isn't an OpenSSL change; but more recent Ubuntu versions are stricter about this
[20:04] <cjwatson> http://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
[20:05] <iamfuzz> cjwatson, ah ok, I'll switch the order around and see if I can sort it out
[20:05] <iamfuzz> the libs are needed
[20:05] <cjwatson> indeed, but the purpose of this linker change was to allow us to drop DT_NEEDED entries for libraries that weren't needed
[20:06] <cjwatson> https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition also
[20:07] <cjwatson> essentially the linker used to be doing loads of extra work both at build time and at run time to support people linking things backwards :-)
[20:08] <iamfuzz> cjwatson, but it allowed people like me to be lazy!
[20:09] <cjwatson> that's nice, but. :-)
[20:09] <iamfuzz> ;-)
[20:09] <iamfuzz> cjwatson, many thanks, that's all it was
[21:10] <psusi> hrm... it appears that util-linux isn't using a patch system.. so if I cherry pick an upstream commit and commit it in bzr, won't that cause a conflict on future merge that will be a pita to resolve?
[21:19] <infinity> psusi: Don't really care if it's in bzr or not.
[21:19] <roadmr> Hi, SRU versioning question! I want to SRU some changes to checkbox 0.12.8, what should the new version number be? is 0.12.8ubuntu1 OK? (trunk has moved on and is now at 0.13, my changes are cherry-picked from that)
[21:19] <infinity> psusi: But converting it to 3.0 (quilt) is on my todo.
[21:20] <infinity> psusi: When I can sneak it past lamont. ;)
[21:21] <broder> roadmr: i probably wouldn't introduce an "ubuntu" component since there wasn't one there before. i think i would pick something like 0.12.8.1
[21:21] <roadmr> broder: oh that looks nicer
[21:22] <infinity> Err.
[21:22] <infinity> No.
[21:22] <stgraber> roadmr: I usually use the example from https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging as they cover most use cases. So based on that it should be 0.12.8ubuntu0.1, but as broder said, as your package is native to Ubuntu and not Debian, just adding .1 is probably fine
[21:22] <infinity> Oh, if it's Ubuntu-native, then yeah.  No ubuntu needed.
[21:22] <roadmr> stgraber: yep, that's the example I'm looking at
[21:22] <stgraber> infinity: yeah, checkbox is one of these weird ubuntu-native packages that's not a meta package :)
[21:23] <infinity> stgraber: One of the three? ;)
[21:23] <roadmr> infinity: yep, native (i.e. we're the upstream anyway) - but I don't think I can do a "microrelease" as our 0.12 branch is up to 0.12.11 and has some non-sruable changes
[21:23] <roadmr> infinity: so ubuntu's 0.12.9 would be different from upstream's 0.12.9 (feels wrong)
[21:23] <infinity> roadmr: Right, that would be wrong.
[21:23] <infinity> roadmr: 0.12.8.1 is fine.
[21:23] <broder> that being said, it's pretty weird that checkbox is versioned as debian/ubuntu-native
[21:24] <infinity> If it has "upstream" releases, it shouldn't be natively-packaged, no.
[21:24] <infinity> But fixing that in an SRU is also wrong. :P
[21:24] <broder> agreed :)
[21:24] <stgraber> yeah, checkbox really should split its packaging out of the upstream branch, actually make proper release tarball and have a nice -0ubuntuX version number like the rest of the world
[21:25] <stgraber> but I know I've already been complaining a few times about it (every time I have to review/sponsor it) without much changing so far...
[21:25] <roadmr> stgraber: sorry, I'll try to have a look at the versioning for this cycle, I'm just getting acquainted with how versioning works
[21:25] <infinity> stgraber: Offer to maintain it in Debian, but only if you can have shiny upstream tarballs?
[21:26] <roadmr> Oooo, checkbox in debian!
[21:26] <infinity> Original-Maintainer: Marc Tardif <marc@ubuntu.com>
[21:26] <infinity> I take it back.
[21:26] <stgraber> roadmr: that'd be great if you could fix that this cycle indeed. Would make packaging by other distros much easier and also make reviewing/sponsoring easier because you'd be like the rest of the world :)
[21:27] <roadmr> stgraber: but we want to be different, just like everyone else :P
[21:27] <infinity> Well, "other distros" won't happen unless it has pluggable backends or something, I suspect.
[21:27] <roadmr> stgraber: hehe no, seriously, I'll definitely have a look
[21:27] <broder> i thought the LP-submission was the only thing ubuntu-specific
[21:28] <broder> i'm using checkbox at work and just tore that out :)
[21:28] <stgraber> infinity: I thought checkbox was all about flexibility and you just need something parsing/pushing the xml output
[21:29] <infinity> stgraber: Maybe.  I've never looked at the code. ;)
[21:29] <roadmr> stgraber, broder, infinity: I'll go with 0.12.8.1 then, and I'll look into versioning / debianizing things too. Thanks!
[21:29] <broder> roadmr: sounds awesome :-D
[21:50] <lamont> infinity: util-linux will not implement a VCS in the source package.  and that's all 3.0 (quilt) is
[21:50] <lamont> infinity: :-p
[21:54] <infinity> lamont: Yeah, yeah.
[21:55] <infinity> lamont: Give me write access to git, then. :P
[21:55] <psusi> lamont: so if I make changes, just make them directly?  won't that cause a conflict when merging the same change from upstream later though?
[21:55] <infinity> psusi: Not if it's identical to an upstream commit, no.
[21:55] <psusi> right, but if there is the slightest little difference...
[21:56] <infinity> Then there's a conflict.  We're smart people.
[21:56] <infinity> Ish.
[21:58] <psusi> hrm... trying to figure out how to effectively deal with that... I mean, as far as I know, you can't see ohh, local commit foo and remote commit foo are the problem... they look the same, so drop local foo, the way you can with quilt patches
[21:59] <infinity> Of course you can.
[21:59] <lamont> psusi: it's doable.  sometimes it sucks, but mostly it's not so bad
[22:00] <infinity> psusi: We import your change as a revision in git.  We merge upstream git.  Conflict.  Resolve.  It's obvious which was from where.
[22:00] <psusi> how?  I mean, bzr just tells you there's a conflict, go fix it.. but not the conflict is between local commit foo, and remote commit bar
[22:00] <infinity> psusi: (Granted, it's even better if you just tell lamont which upstream commit you want, and he can cherry-pick the actual commit)
[22:00] <infinity> psusi: Cause then that will retain ancestry and auto-resolve its own damned self.
[22:01] <psusi> it's not committed yet, just posted to the ml today :)
[22:01] <infinity> Ahh. ;)
[22:37] <dr3mro> hello , I am trying to create a ppa for daily build of a project i am not the owner of it hosted on google code but it fails when i enter the repository address in launchpad https://code.google.com/p/plowshare
[22:38] <micahg> dr3mro: you probably #launchpad for recipe help
[22:38] <micahg> * want
[22:48] <htorque> bdmurray: hi! about bug 899683 - are you sure it should be a dupe of the no space left master bug?
[22:49] <htorque> bdmurray: i installed oneiric a couple of times with the same settings during the last six months, now precise fails with that weird partition sizes.
[22:53] <bdmurray> htorque: nope, I'll fix it
[22:59] <slangasek> cjwatson: hi, question on bug #771372
[23:00] <slangasek> cjwatson: why does this only show up when the installer is upgrading the package, vs. initial install?
[23:01] <slangasek> cjwatson: i.e., is there an installer bug there too, which causes diversions to be removed between the install and upgrade bits?
[23:02] <slangasek> hmm, looks like debootstrap diverts initctl, after which it's restored
[23:03] <cjwatson> slangasek: Possible, but fixing that in a stable release seems even sketchier ...
[23:03] <cjwatson> chroot-setup.sh is supposed to divert initctl too
[23:04] <slangasek> right; I'm not proposing fixing that in a stable release, but I want to understand what's actually happening here - and make sure the bugs get fixed for precise if need be
[23:04] <bdmurray> htorque: could you elaborate regarding what you choose when partitiioning?
[23:05] <htorque> bdmurray: the default "erase all and use whole disk"
[23:08] <cjwatson> slangasek: There is something odd there, indeed.  I don't quite see what; visually, the code seems right
[23:08] <slangasek> cjwatson: should I raise a bug on debian-installer?
[23:08] <cjwatson> slangasek: yes please
[23:09] <slangasek> ok
[23:09] <cjwatson> (probably belongs on either pkgsel or debian-installer-utils, but debian-installer is the place to start)
[23:27] <robert_ancell> @pilot in
[23:36] <slangasek> cjwatson: bug #900526
[23:38] <cjwatson> thanks
[23:39] <cjwatson> incidentally, it's not technically impossible to fix post-release, just difficult to ensure that the fix goes everywhere relevant ...
[23:43] <slangasek> cjwatson: right :)
[23:44] <slangasek> oh heh; I've just realized that the procps change that was being SRUed is broken on lucid/maverick/natty anyway.  Guess I'll rescind that