[00:17] <BUGabundo> ahhh my pillow called... she wants me back. see you tomorrow µfriends
[01:34] <RoAkSoAx> Hi all i was wondering if we can file SRU's already
[01:35] <poolie> i'd like to know that too; https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/513432 is getting a lot of dupes and i'd love to get the sru into maverick updates
[01:37] <TheMuso> Yes we can, there are already SRUs in the proposed queue.
[01:39] <RoAkSoAx>  cool thanks for the tip TheMuso :)
[01:40] <poolie> TheMuso: what do we have to do to actually get it sponsored?
[01:40] <poolie> posting on the bug doesn't seem to be enough
[01:41] <TheMuso> poolie: Go through the process to get the bug ready for an SRU, upload a debdiff/point to a branch, and subscribe ubuntu-sponsors. This is from the top of my head, so the wiki page on SRUs may say otherwise.
[04:38] <hyperair> okay, this is getting annoying. why do i have to answer the same debconf questions thrice during do-release-upgrade?
[04:40] <ScottK> Which ones?
[04:49] <persia> hyperair, In each and every case that's surely a bug.  The cases I've found previously were usually an artifact of the maintainer assuming "no answer" and "unanswered" were identical semantically (which is especially annoying for drop down selections that invite "None" as an option)
[04:51] <hyperair> ScottK: flashplugin-installer.
[04:53] <micahg> there's a debconf question in flashplugin-installer?
[04:53]  * ScottK doesn't recall seeing any.
[04:53] <micahg> there is a debconf config...
[04:54] <micahg> I don't recall ever seeing it ask a question though
[04:57] <hyperair> micahg: there's one asking whether or not to download
[04:58]  * ScottK wonders what the priority of the question is?
[04:58] <hyperair> ScottK: not sure, but it kept popping up during do-release-upgrade
[04:58] <ScottK> hyperair: Right, but it doesn't for others, so I'm wondering if you've got a non-standard priority set.
[04:58] <persia> hyperair, And you answered it each time?  It's probably worth replicating the experience with DEBCONF_DEBUG=developer to find out why it couldn't remember what you said the first time.
[04:59] <hyperair> persia: i'll give it a go later.
[04:59] <hyperair> i've finished answering the questions.
[04:59] <hyperair> ScottK: i didn't do anything funky with my env
[04:59] <hyperair> or set anything in /etc
[04:59] <hyperair> how do you change it besides that env var persia said anyway?
[04:59] <ScottK> OK.
[04:59] <ajmitch> ScottK: on lucid the priority looks to be medium
[04:59] <persia> hyperair, You'd have to create a new environment and redo the upgrade: you can't easily reconstruct later, as the DB state changed.
[05:00] <persia> My environment variable is about cluttering output, not about setting priority.
[05:00] <hyperair> persia: i'll redo it later, i've a btrfs snapshot.
[05:01] <hyperair> persia: i screwed my upgrade last night, so i'm really thankful for btrfs snapshots right now =p
[05:01]  * ajmitch would tend to blame btrfs for all problems in that case :)
[05:02] <hyperair> ajmitch: heheh i don't think btrfs has anything to do with debconf.
[05:02]  * ScottK may be using adobe-flashplugin now, so perhaps that's the difference.
[05:03] <ajmitch> I think 'debconf-show debconf' will show the priority that's being used, unless do-release-upgrade changes that
[05:03] <hyperair> maybe.
[05:05] <hyperair> honestly speaking, i use the 64-bit flash cp'd directly, so i'll probably manually undo all that later
[07:39] <pitti> Good morning
[07:43] <\sh> good morning pitti
[07:45] <pitti> apw: got tons of WI tracker spam during the night; found the problem now
[07:46] <pitti> fixed, db purged
[07:55] <slangasek> pitti: hey there
[07:56] <slangasek> pitti: had a question - do you have an existing Best Practices example for the use of dpkg --path-{in,ex}clude?
[08:03] <pitti> slangasek: indeed I have: https://wiki.ubuntu.com/ReducingDiskFootprint#Drop unnecessary files
[08:04] <slangasek> pitti: awesome, thanks!
[08:04] <pitti> slangasek: the test suite has some more, but with above example it's really everything it's meant to do
[08:06] <slangasek> pitti: you don't see any reason to include changelog files?  I don't remember if the GPL's requirements to mark modifications apply to binary packages or just to source
[08:07] <pitti> slangasek: well, if you apply this to a server of your's, you probably won't sue anyone because you removed them yourself?
[08:07] <pitti> slangasek: if we apply that to systems that we distribute, we need to check that, of course
[08:07] <pitti> I don't know off-hand
[08:07] <pitti> if it's sufficient to provide an easy way to display the changelog, that'd be nice
[08:07] <slangasek> pitti: my current proposed use case is distributed Linaro images :)
[08:08] <pitti> it's high on my list to investigate for lowering the default footprint
[08:08] <slangasek> default?
[08:08] <pitti> Ubuntu standard install, I mean
[08:09] <pitti>     a) The work must carry prominent notices stating that you modified
[08:09] <pitti>     it, and giving a relevant date.
[08:09] <pitti> that's what I see in the GPL
[08:09] <slangasek> I'm not particularly keen on the idea of removing all this stuff from a default install
[08:10] <pitti> slangasek: oh, just talking about changelogs for now
[08:10] <slangasek> yeah, I'm not keen on *those* being removed from a default install either
[08:10] <pitti> the wiki page is meant for customized projects which are really tight on space
[08:11] <slangasek> ohwell, the wiki page at least gets me where I'm going for right now - thanks
[08:11] <pitti> slangasek: but changelogs are taking several MBs, and are something most users really don't care about; so if we can provide a seamless way for those wo do, they would be a good candidate IMHO
[08:12] <slangasek> pitti: in the case of local packages, the changelog is the only place that records the origin of the package after the fact
[08:12] <slangasek> since dpkg doesn't track origin info, and apt can only tell you about currently-downloadable packages
[08:12] <pitti> ah, I see what you mean
[08:12] <pitti> slangasek: no, my intention is not to use dpkg filters for those
[08:13] <pitti> if we do that, it should be for ubuntu packages only
[08:13] <slangasek> I'm not sure how the dpkg filter can distinguish
[08:13] <slangasek> but ok, at least it's on the radar :)
[08:13] <pitti> like, pkgbinarymangler could remove them and add a stanza and a link to the online changelog to copyright, and/or we provide a script "pkg-changelog <pkgname>" or similar
[08:13] <slangasek> ah, sure
[08:14] <pitti> slangasek: I don't think dpkg filters are approriate for a standard Ubuntu install, due to the reason you stated
[08:14] <pitti> this was written for OEM projects primarily
[08:16] <pitti> kees: ok, can pocket-copy
[08:17] <dholbach> good morning! :)
[08:27] <pitti> hey dholbach, wie gehts?
[08:27] <dholbach> hey pitti, sehr gut - ist nur irgendwie schnell etwas kalt geworden hier :)
[08:28] <pitti> indeed *shudder*
[08:29] <\sh> well, it's getting warmer again here in KA
[08:30] <\sh> good morning dholbach :)
[08:30] <dholbach> hey \sh
[08:30] <dholbach> highvoltage, I'm getting more edubuntu-bugs mails now :)
[08:30] <dholbach> and while I like more edubuntu bugs activity... :-P
[09:32] <persia> pitti, slangasek: just FYI: there exist several packages in Ubuntu where the changelog for just that package is measured in megabytes.
[10:26]  * cjwatson fixes MoM to handle multiple entries with different versions in a single Sources file (as often happens in Debian now)
[11:14]  * ogra hopes persia doesnt refer to anything shipped on the CD
[11:15] <persia> ogra, I didn't check: I just unpacked every binary package, extracted the changelog, put the size in a report, and sent it to the LP folks arguing about whether it belongs in librarian or the DB.  I couldn't even say which packages have that issue.
[11:20]  * pitti wonders whether we should just have an ubuntu-changes@ ML
[11:24] <geser> +1 on this, I've to resubscribe for the next -changes ML after each release
[11:25] <persia> can we have both?
[11:25] <pitti> YokoZar: question for you in bug 622220
[11:25] <persia> I believe several folks like having the SRU changes going to release-specific lists.
[11:25] <doko> pitti: could you look at the cdbs merge for natty?
[11:25] <pitti> doko: yes, can do
[11:25] <geser> I'd be even happy if the new -changes list is initialized with the subscribers of the previous one
[11:26] <pitti> geser: *nod*
[12:09] <pitti> doko, cjwatson: cdbs merge done, tested, uploaded
[12:10] <pitti> doko, cjwatson: if it's alright with you, I'd like to prepare and upload a new pkgbinarymangler, too, before we open the floodgates?
[12:11] <cjwatson> sure
[12:46] <tkamppeter> pitti, hi
[12:47] <pitti> hello tkamppeter
[12:50]  * hyperair looks at his never-ending ubuntu upgrade and thinks that dpkg should totally be made into a libdpkg which can be used by apt directly instead of execving
[12:55] <tkamppeter> pitti, there is a small problem with CUPS, bug 485383.
[12:56] <tkamppeter> the CUPS PPD generator /usr/share/cups/drv/sample.drv needs the /usr/share/cups/ppdc/*.h files which are in cups-ppdc and there is no dependency or seed assuring that this package is installed.
[12:57] <tkamppeter> pitti, there are principally two possibilities to fix: Moving the files to cups-common or making cups-common depending on cups-ppdc.
[12:58] <tkamppeter> pitti, both solutions have no regression potential (it is only adding some data files), so I think this should be done as an SRU for Maverick. WDYT?
[12:59] <pitti> tkamppeter: what other files are in cups-ppdc?
[12:59] <pitti> it's tiny, so instead of pulling it in by default (and adding another changelog, package entry, etc.) we could just merge it into cups-common indeed
[12:59] <pitti> (for natty onwards)
[12:59] <pitti> for SRUs, a dependency change sounds fine
[13:00] <tkamppeter> pitti, some executables to manipulate PPDs, but they are never called by the PPD listing and extraction processes of CUPS.
[13:02] <pitti> tkamppeter: hm, then moving the two .h sounds fine to me
[13:02] <pitti> tkamppeter: I'm just confused, I thought we now ship pre-built compressed PPDs for everything?
[13:04] <tkamppeter> pitti, not everywhere, only if one saves a significant amout of space. If there are already PPD generators (CUPS, HPLIP non-PostScript, ...) with efficient source data or only very few PPD files (pxljr) I did not introduce compressed archives.
[13:06] <tkamppeter> pitti, moving the .h files from cups-ppdc to cups-common would be sufficient, but needs appropriate versioned conflicts, so that it goes smoothly through an update.
[13:06] <pitti> tkamppeter: ah, I see
[13:07] <pitti> tkamppeter: sure, moving files sounds fine then (and they shoudl be Replaces:, not Conflicts:)
[13:07] <tkamppeter> pitti, for the SRU I sugges simply letting cups-common depend on cups-ppdc.
[13:07] <pitti> tkamppeter: I agree
[13:07] <cjwatson> Replaces> yes, I was about to say the same thing.  You should generally also add Breaks, per current Debian policy
[13:07] <pitti> tkamppeter: erm, cups, not cups-common? not necessary for client side only, or is it?
[13:08] <pitti> cjwatson: pkgbinarymangler uploaded
[13:08] <cjwatson> ta
[13:08] <pitti> it removes the buildinfo.gz files for now (to counteract the new cdbs)
[13:08] <cjwatson> still need to fix perl before we can open
[13:08] <pitti> I hope I can get to adding the PNG/SVG compression into this soon, too
[13:08] <pitti> but no time yet
[13:09] <pitti> but I expect most desktopish packages to get rebuilt several times anyway
[13:09]  * cjwatson nods
[13:09] <tkamppeter> pitti, is really only needed by the CUPS server, I came to cups-common as /usr/share/cups/drv/sample.drv and /usr/share/cups/ppdc/*.defs are in cups-common (which is probably not correct).
[13:09] <pitti> lamont: do we have pkgbinarymangler version pinned right now? I uploaded a new version for natty
[13:10] <pitti> tkamppeter: right, seems these should all be moved to cups then?
[13:10] <pitti> lunch, bbl
[13:24] <lool> Is natty open for any upload?
[13:25] <persia> lool, Not yet, but that just means you get stuck in UNAPPROVED.  This might be fine, or it might mean you unexpectedly FTBFS because the environment changed since you test-built.
[13:25] <bilalakhtar> lool: no, toolchain is being uploaded
[13:25] <persia> You can check the current status at https://launchpad.net/ubuntu/natty
[13:26] <persia> (there's likely also some way to do that with the LP API, if you want to make a little indicator widget that shows the current state of the current development target)
[13:28] <lamont> pitti: dunno - let me go look
[13:28] <lamont> pitti: no holds on pkgbinarymangler since you promised to not mangle it
[13:30] <lamont> doko: so about this openjdk-6/armel thing...  what all needs to be built on the panda board to make things happy, and can we arrange to do that for natty?
[13:31] <highvoltage> stgraber: which team do we have to update contact address for to stop the edubuntu-spam?
[13:31] <doko> lamont: do all the buildds already run on panda boards?
[13:32] <doko> the change is easy, just undo the reversion of the upstream change
[13:35] <persia> highvoltage, Just the bugs team ought to work: if not you probably want to clean up which teams are subscribed to stuff.
[13:35] <persia> highvoltage, Actually, you might need one for the -dev team if you assign bugs to that team.
[13:40] <lamont> doko: I have one buildd that is a panda board.  it falls over regularly and is completely not ready for production.  hence we get to coordinate the upload and build.  OTOH, if your upload is known to fail on bbg3 boards, that simplifies things a little, since if it tries there, it won't succeed and require a re-upload
[13:41] <lamont> I tried building openjdk-6 on the panda board (in a ppa) with just the debian/rules blocker removed, and that was insufficient, so I decided to wait for you
[13:42] <highvoltage> dholbach: I think it will be right now, let me know if you get more spam
[13:42] <doko> lamont: that doesn't work. as soon as I upload eglibc with the upstream patch reverted, java fails on *every* buildd
[13:42] <doko> so we have to delay this until we change all buildds to the panda boards
[13:43] <lamont> ogra: so that panda board, not so much use ^^
[13:43] <ogra> lamont, you tried running from SD as i suggested ?
[13:44] <ogra> i know it will be slow as hell but should be stable
[13:44] <ogra> i guess you have some HW issue with your USB on that board, all boards we tried yet didnt expose the hdparm issues for example
[13:44] <dholbach> highvoltage, rock on! :)
[13:50] <lamont> ogra: the issue is that once we build java with the panda, then you get no java-using builds that succeed on any bbg3 board.
[13:50] <lamont> or so doko tells me
[13:50] <lamont> and one panda board, with or without SD, isn't gonna cut it
[13:52] <persia> doko, Is the problem bbg3-specific or imx51-wide?
[13:52] <doko> ogra, lamont: apparently the java failures are only seen with the babbage kernel. as long as we have these as buildds, we can't do anything. I don't have any feedback from the kernel team yet
[13:52] <ogra> doko, right, it seems nobody there has a clue
[13:53] <ogra> thats why i sent lamont the panda
[13:53] <ogra> but he has USB issues with it
[13:53] <lamont> ogra: well, it's been doing ok for a while now, maybe it settled down
[13:53] <lamont> the threats seem to be working
[13:53] <ogra> and the prob is that its a 6 layer board for which we dropped support with the latest kernel, so he cant upgrade the image we gave him
[13:54]  * ogra wonders why his IRC connection is so bad
[13:56] <ogra> great
[13:56] <ogra> the only purpose of that board was to build java once
[13:58] <persia> But how would that help, if the result wouldn't be able to run on anything else?
[13:59] <ogra> after that we can send it back to TI, we cant use it much anyway
[14:01] <doko> lamont: so you could try to install the binaries from https://launchpad.net/ubuntu/+source/eglibc/2.12.1-0ubuntu3/+build/1948672 to check if it is fixed with the kernel you are running on the omap board
[14:01] <lamont> doko: and beyond that we just need the debian/rules blocker gone?
[14:02] <doko> lamont: ?
[14:08] <pitti> lamont: cheers, thanks for checking
[14:10] <lamont> doko: once I install the binaries from eglibc, then what do I do to test whatever it is you want me to test?
[14:11] <lamont> it'll be a bit later today - breakfast plans
[14:11] <doko> lamont: java -version should not segfault
[14:11] <lamont> awesome
[14:11] <lamont> I like the simple tests
[14:11] <doko> :-)
[14:14] <lamont> doko: save me grepping Contents.gz?  where does java-version come from?
[14:16] <doko> lamont: <space>
[14:16] <doko> openjdk-6-jre-headless
[14:16] <lamont> ta
[14:16] <lamont> dpkg -S had nothing to say to me on the subject
[14:20] <tgardner> Riddell, could you have a look at linux-lts-backport-maverick in Lucid? It should have gone to main, not universe.
[14:21] <pitti> tgardner: the source was in universe, so I NEWed the binaries to universe, too
[14:22] <tgardner> pitti, what should I have done to direct the package to main?
[14:22] <cjwatson> pitti: ???  I put the source in main!
[14:22] <cjwatson> at least I'm sure I did
[14:22] <cjwatson> tgardner: not your fault.
[14:23] <cjwatson> you couldn't have done anything differently
[14:23] <pitti> linux-lts-backport-maverick | 2.6.35-22.34~lucid1 | lucid-proposed/universe | source
[14:23] <tgardner> cjwatson, also, does it need to be seeded so it doesn't get reaped?
[14:23] <cjwatson> pitti: blink.  I agree with tgardner, it should just be moved en-masse to main
[14:23] <pitti> cjwatson: sure, no problem; doing now
[14:23] <cjwatson> tgardner: no, because the component-mismatches stuff doesn't run on lucid any more
[14:23] <pitti> tgardner: ^
[14:23] <cjwatson> (I mean, theoretically maybe, but it isn't going to fall out if you don't.)
[14:24] <tgardner> cjwatson, pitti: thanks. I'll be uploading a meta package as well later today.
[14:24] <pitti> tgardner: done
[14:24] <cjwatson> hmm.  looking through shell history, there's no evidence that I put it in main, so it's probably my fault
[14:25] <pitti> cjwatson: I usually use the +queue page for that, you didn't use that?
[14:25] <cjwatson> no, because reviewing it involved diffing against the current linux source package in maverick and I didn't want to download that over ADSL.
[14:25] <cjwatson> the "do everything through the web interface" shtick does rather assume good bandwidth
[14:26] <pitti> cjwatson: I mean for overriding
[14:26] <cjwatson> I was already logged in at a shell, so I just accepted it there
[14:26] <pitti> cjwatson: I generally use +queue for overriding kernel binaries, since it's much faster/easier than with kernel-overrides
[14:26] <cjwatson> kernel-overrides is very fast these days.
[14:26] <pitti> (different use case, I know)
[14:27] <cjwatson> and +queue will get it wrong if we ever have to override sections in advance of kernel source, so I'd really rather you used kernel-overrides, and at some point we'll port that to be an API script
[14:27] <pitti> anyway, /me creates natty chroot to find out what broke pkgbinarymangler in natty
[14:28] <apw> oh no, not pkgbinarymangler ... seal that back in the 9th circle
[14:28] <pitti> apw: well, it just FTBFSed, thanks to the picky test suite
[14:29] <apw> pitti, there is a god :)
[14:47] <superm1> achiang, if you need it for an oem project, go ahead and apply it  there on your OEM repos
[14:48] <superm1> achiang, but keep in mind that some drivers you can't ship in pre-built form anyway
[14:49] <hyperair> huh, how did /var/crash disappaer >_>
[14:50] <hyperair> what are the permissions and ownership of /var/crash?
[14:54] <pitti> hyperair: the upstart job creates it if apport is enabled
[14:54] <pitti> (which it isn't for the final maverick)
[14:54] <pitti>     mkdir -p -m 1777 /var/crash
[14:54] <doko> tgardner, apw: will there be a new linux-libc-dev before opening natty?
[14:54] <hyperair> pitti: well, ubuntuone-client or something had a script failin due to missing /var/crash.
[14:55] <apw> doko, a good question, thats a little chicken and egg i guess as we make new ones as part of the kernel build
[14:56] <tgardner> doko, seems like there ought to be. note that it'll change at least once more when the kernel rolls to 2.6.37
[14:58] <doko> apw, tgardner: well, I would like to see build problems with new kernel headers from the start, I wouldn't care if the kernel is untested or not working at all ;)
[14:58] <tgardner> doko, actually, it works pretty good. apw and I have been running it for weeks
[14:58] <doko> it's these time when I whish the headers would be built from a separate source
[14:58] <doko> tgardner: then just upload?
[14:58] <apw> yeah well one of us needs to blink first :)
[14:59] <tgardner> apw, you wanna fire up the first package to make the upload rights are working?
[14:59] <tgardner> make sure*
[14:59] <apw> tgardner, sure thing
[14:59] <doko> apw: note that gcc-4.5 is the default now
[15:00] <tgardner> apw, you might wanna think about dropping the brcm staging patches. it doesn't work well enough yet for the real world
[15:13] <pitti> mdeslaur: can you please forward the patch for bug 456710 to Debian? I just merged the package (I was TIL)
[15:13] <pitti> mdeslaur: and you know better what exactly the patch was for
[15:14] <mdeslaur> pitti: hmm...I thought I did...let me search for it
[15:14] <cjwatson> apw: we checked packageset permissions, BTW, so your upload permissions should work fine
[15:14] <pitti> mdeslaur: the other fix for comments in apt sources was accepted
[15:15] <apw> cjwatson, thanks :)
[15:34] <mdeslaur> pitti: done, thanks!
[15:34] <pitti> mdeslaur: great, thanks
[15:35] <raphink> hi guys
[15:36] <raphink> I've got a question about linking bindings to a shared library that was produced in the same source package
[15:37] <raphink> as in, the install target wasn't called yet, so the .so is still in .libs, but I need to link the bindings (a PHP module in that case) to it, but libtool ignores stuff in .libs
[15:37] <raphink> I ended up copying the .so in obj/ to build the PHP module and removing it afterwards
[15:37] <raphink> is there a cleaner way to do this?
[15:47] <mdeslaur> pitti: what does "TIL" mean?
[15:47] <pitti> mdeslaur: touched it last
[15:47] <mdeslaur> oh, hehe...thanks
[15:50] <raphink> anyone has an answer?
[15:51] <persia> Could you do something with the library loading environment variables at build time, or would that result in undesireable path elements later at runtime?
[15:52] <raphink> I've tried to add a -I flag
[15:52] <raphink> but libtool ignores it
[15:52] <raphink> I've checked libtool's code, it specifically removes anything that contains .libs
[15:52] <raphink> another option would be to have two different install targets, but it gets the packaging quite more complicated
[15:57] <raphink> persia: see, you get to be the one answering ;-)
[15:57] <cjwatson> raphink: I thought you were supposed to pass the .la file to libtool when linking
[15:57] <cjwatson> that's how it works for me anyway ...
[15:57] <raphink> well that works for i386
[15:57] <persia> raphink, Sure, but other, wiser, folk correct me when I make mistakes.
[15:57] <raphink> but not with amd64
[15:57] <raphink> because it complains about -fPIC
[15:58] <cjwatson> so build the shared objects with -fPIC :-)
[15:58] <cjwatson> they generally should be anyway
[15:58] <raphink> which is set and works with .so, but fails with .la (I have no idea why, I spent hours trying to figure out why the static lib didn't inherit the -fPIC)
[15:58] <cjwatson> linking with the .la shouldn't normally cause linking against the static library
[15:58] <raphink> ah, right it's .a right?
[15:59] <cjwatson> .a => static library, .la => libtool archive
[15:59] <raphink> right
[15:59] <raphink> ok, so .la and .so are in .libs after the build
[15:59] <raphink> so I pass -I/path/to/.libs
[15:59] <raphink> and it's ignored by libtool
[15:59] <cjwatson> why -I?
[15:59] <raphink> sorry
[15:59] <raphink> -l I mean
[16:00] <cjwatson> that doesn't make sense either
[16:00] <raphink> wait, let me check before I say more stupid things ;-)
[16:00] <Laney> MoM should probably exclude *build*
[16:00] <cjwatson> -L would make some sense, but it's more usual to just put /path/to/.libs/libfoo.la on the link line directly
[16:00] <raphink> yes, -L
[16:00] <persia> Does that not create a path entry in the library?
[16:00] <Laney> although I guess it won't be a problem after autosync happens
[16:01] <cjwatson> Laney: bug 366532.  and indeed not
[16:01] <raphink> but then libtool ignores .libs, so it ends up linking against the .a which doesn't work for amd64 because of -fPIC
[16:01] <persia> Laney, It's a feature that MoM doesn't exclude *build* because it helps us catch stuff on the blacklist, stuff that failed-to-sync, etc.
[16:01] <cjwatson> raphink: there should be a .la file outside .libs for you to use
[16:01] <raphink> ok
[16:01] <raphink> let me check
[16:01] <raphink> I'll have to rebuild to see I think
[16:02] <cjwatson> for instance in bzr trunk of man-db, src/Makefile.am sets LIBMAN = $(top_builddir)/lib/libman.la
[16:02] <Laney> persia: It's a misappropriation of the merge list, though. We have MDT to catch these cases (or if unsuitable, should modify it to do so).
[16:02] <raphink> ok
[16:02] <raphink> let me check cjwatson
[16:02] <persia> Laney, I guess.  I use MDT to determine what to merge most of the time anyway.  But for folk who like their merges predigested, I'm not sure MoM isn't more useful for blacklist stuff anyway.
[16:03] <cjwatson> I'm inclined to agree with Laney; AFAICT it's an oversight that we don't exclude *build*
[16:03] <raphink> persia: you mean chdist ?
[16:03] <cjwatson> especially since one bit of MoM already does
[16:03] <cjwatson> ./generate-patches.py:78:            if search(".*build[1-9]+$", our_source["Version"]):
[16:04]  * Laney branches
[16:05] <cjwatson> too late ;-)
[16:05] <Laney> :)
[16:05] <hyperair> hmmm
[16:05] <hyperair> i see some interesting new things in /etc/default/grub
[16:05] <Laney> 1-9+ isn't quite right though
[16:05] <hyperair> what's BadRAM?
[16:05] <Laney> build10?
[16:06] <cjwatson> hyperair: info grub
[16:06] <persia> [0-9]+ might be better.
[16:06] <hyperair> cjwatson: okay thanks.
[16:06] <cjwatson> Laney,persia: fixed
[16:06] <cjwatson> let me know if that works out ok
[16:06] <persia> cjwatson, Thanks for the quick change.
[16:06] <Laney> thanks
[16:07] <Laney> I wish I could remember how to show the diff introduced by the latest commit in bzr
[16:07] <Laney> cf `git show'
[16:07] <cjwatson> if it causes a practical issue with blacklisted stuff, we can figure something out
[16:08] <cjwatson> bzr di -clast:
[16:08]  * Laney memorises
[16:08] <cjwatson> or 'bzr alias show="log -v -p -n1 --long"' and then 'bzr show -rlast:'
[16:08] <persia> 95% of blacklisted stuff is because we pull upstream faster than Debian, and Debian pulls from us.
[16:08] <persia> The other 5% is probably caught by MDT, and needs manual merging anyway.
[16:08] <ari-tczew> hey, what's the status of toolchain?
[16:09] <cjwatson> ari-tczew: nearly done, just waiting for gcc-4.5 to finish on armel and I needed to reupload perl with a fairly obscure fix
[16:10] <cjwatson> oh, and python is going in first too apparently
[16:11] <ari-tczew> ok thanks
[16:11] <Laney> can we upload stuff to the queue?
[16:11] <cjwatson> Laney: yes
[16:11] <Laney> good to know
[16:11] <persia> Laney, You won't be able to know it builds with gcc-4.5 on armel though :)
[16:11]  * Laney now has armel hardware ;-)
[16:12] <Laney> reminds me to poke at ghc there
[16:13] <persia> heh
[16:25] <\sh> micahg: pingeling -> zend-framework 1.10.8 official backports??? :)
[16:25] <micahg> \sh: as in the backports pocket?
[16:27] <\sh> micahg: yepp...from 10.10.10 to 10.04
[16:29] <joaopinto> cjwatson, could you please look at bug 568067 ? I believe you were the one checking it about 6 months ago, it was pre-release time so it did not get any attention
[16:38] <tgardner> cjwatson, I've uploaded linux-meta-lts-backport-maverick. Is the package name linux-image-server-lts-backport-maverick sufficient for the point release DVD ?

[16:41] <SpamapS> http://jira.mongodb.org/browse/SERVER-1764
[16:41]  * hyperair pings cwillu_at_work 
[16:41] <SpamapS> "Now I don't mean fully static, i.e. pthread, libc, etc.. are still dynamic. but boost, pcre, spidermonkey will by default be not only static, but the source will be in the mongo repo so we can pin to versions, etc.."
[16:41] <SpamapS> Something has to be done
[16:41] <hyperair> cwillu_at_work: were you the one who worked on the btrfs + grub issue? it seems to be around with maverick =(
[16:41] <SpamapS> Every single upstream thinks its ok to embed library source code in their tarballs now. :-/
[16:43] <raphink> there, finally reproduced my issue :-)
[16:43] <raphink> cjwatson, persia
[16:44] <raphink> http://pastebin.com/YTcFjfeN
[16:44] <raphink> it tries to link against the .a
[16:44] <raphink> even though there is a .la
[16:44] <raphink> not with the exact same name though
[16:45] <raphink> rpinson@condor:~/packages/db/db5.0-5.0.26$ ls obj/*.la
[16:45] <raphink> obj/libdb-5.0.la  obj/libdb_cxx-5.0.la  obj/libdb_java-5.0.la  obj/libdb_tcl-5.0.la
[16:45] <raphink> maybe that's the issue cjwatson?
[16:48] <raphink> hmm no, symlinking libdb_cxx.la doesn't help
[16:49] <raphink> cjwatson, persia: the problem is that the following line seems to search for a .a
[16:49] <raphink> libtool: relink: cc -shared  .libs/db4.o   -L/home/rpinson/packages/db/db5.0-5.0.26/obj -L/lib -L/usr/lib -ldb_cxx -lstdc++  -Wl,-rpath -Wl,/lib   -Wl,-soname -Wl,db4.so -o .libs/db4.so
[16:49] <ari-tczew> cjwatson: hmm, does your last change did this on MoM? Updated Merges: 0
[16:50] <cjwatson> tgardner: should be
[16:51] <cjwatson> raphink: dunno any more, sorry.  maybe one of the .la was built with libtool disable-shared or something?  hard to tell from here.
[16:52] <tgardner> cjwatson, cool
[16:52] <raphink> ok cjwatson, thanks
[16:52] <raphink> I end up having to copy the .so to get it to work though
[16:52] <raphink> for some reason
[16:52] <cjwatson> ari-tczew: what's wrong with that?
[16:53] <cjwatson> that's what I'd expect given that no universe merges have been uploaded yet
[16:53] <raphink> persia: any idea ?
[16:53] <Laney> It doesn't look like there has even been a run since the latest changes anyway
[16:53] <cjwatson> shouldn't think so, no
[16:53] <persia> cjohnston, Why does main/universe matter in that context?  the relatively small number of merges + the squeeze freeze is likely more significant.
[16:54] <persia> raphink, Sorry, you were at the edge of my knowlege of library packaging when you started,and I'm lost.
[16:54] <ari-tczew> cjwatson: I didn't say wrong. I just saw refresh in MoM.
[16:54] <cjwatson> persia: YM cjwatson HTH
[16:54] <raphink> persia: ok, my ack copying the .so to build the PHP module works fine, I don't know if that's acceptable
[16:54] <cjwatson> persia: it matters because the page that displays "0 updated merges" is https://merges.ubuntu.com/universe.html.
[16:54] <ari-tczew> cjwatson: I never understood what's the difference between outstanding and updated merges.
[16:54] <raphink> s/ack/hack/
[16:54]  * persia finds egg,and carefully applies to face
[16:55] <cjwatson> ari-tczew: "outstanding" => never uploaded this cycle; "updated" => uploaded this cycle, but there's been another change on one side or the other.
[16:55] <raphink> o_O
[16:56] <ari-tczew> cjwatson: hmmm, did this one worked in the past, or you fixed this in MoM trunk?
[16:56] <cjwatson> ari-tczew: that's how it's been for years
[16:56] <cjwatson> (and working for years in my experience)
[16:56] <Laney> MoM's interface is really rather stable
[16:57] <ari-tczew> cjwatson: So I'm not too perceptive.
[16:57] <cjwatson> https://code.launchpad.net/+branch/merge-o-matic shows what I changed recently
[16:57] <ari-tczew> cjwatson: are you interested in merging proposed changes to MoM?
[16:57] <ari-tczew> yes I know and I'm looking on this right now
[16:58] <cjwatson> ari-tczew: not desperately, I was just trying to get it minimally working for natty opening
[16:58] <cjwatson> I don't know the code that well; if you can get hold of Keybuk he's better to review actual work
[16:59] <ari-tczew> cjwatson: ok, I only asked, because MoM looks like orphaned.
[16:59] <cjwatson> "maintenance mode"
[17:03] <achiang> superm1: well, i'm more interesting in finding out why you think my approach is wrong
[17:05] <superm1> achiang, i seem to remember running into issues on an early rhel 5.x version where modules were compiled for i386 but certainly wouldn't load into an i686 kernel (errors while modprobing saying it didn't match).  since you and mjg say that it should work,  i want to determine why I was running into that behavior first
[17:05] <ari-tczew> cjwatson: about revision 182. does it should prevent produce *buildX versions in MoM?
[17:06] <superm1> trunk isn't stable for dkms right now anyhow, haven't had enough time to fix it yet either
[17:07] <cjwatson> joaopinto: I've filed a sysadmin ticket
[17:07] <cjwatson> ari-tczew: yes, after the next time it regenerates
[17:08] <ari-tczew> cjwatson: so next MoM update will remove *buildX packages?
[17:08] <cjwatson> ari-tczew: should do
[17:08] <ari-tczew> ok understand
[17:08] <achiang> superm1: if you build the module on an i386 host, i could see *maybe* it wouldn't load  on an i686 install. but then again, my patch doesn't change that anyway
[17:09] <achiang> superm1: passing ARCH=i386 to a kernel makefile *doesn't* say "use i386 vs i686 compiler flags". it *does* say, "use 32 bit build, not 64-bit build"
[17:09] <achiang> superm1: to understand why, you just need to go read the top-level kernel makefile
[17:27] <bdmurray> pitti: is there a natty branch for apport yet?  I'm not finding one and would like to propose a merge.
[17:28] <pitti> bdmurray: it hasn't changed, lp:~ubuntu-core-dev/ubuntu/maverick/apport/ubuntu
[17:28] <pitti> oops, sorry
[17:28] <pitti> I  keep forgetting that I use the package branches
[17:28]  * pitti pushes
[17:29] <pitti> bdmurray: pushing lp:~ubuntu-core-dev/ubuntu/natty/apport/ubuntu now
[17:29] <pitti> will still take a bit, though; not sure why those don't get stacked
[17:29] <pitti> finished
[17:31] <cjwatson> bdmurray,pitti: jml is working on sorting out package branches in general, too
[17:31] <pitti> cjwatson: this one is a bit special; it's not lp:ubuntu/apport (although having that would be nice)
[17:31] <pitti> same like udev
[17:34] <bdmurray> pitti: thanks
[17:35] <cjwatson> pitti: right, I realised that part-way through typing but figured my comment was still useful
[17:36] <pitti> cjwatson: yes, it's still good to hear
[17:36] <pitti> but right now we don't really have a perfect story about packages whose upstreams are in bzr
[17:37] <pitti> bdmurray: got the MP, thanks
[17:48] <ari-tczew> yay, toolchain is not ready yet and developers have done some merges! greetz to pitti and cjwatson
[17:48] <ari-tczew> or maybe these packages are a part of toolchain?
[17:50] <cjwatson> ari-tczew: the merges that have landed in the archive are part of the toolchain (in the wider sense; packages we'd like to have in place before opening the floodgates)
[17:50] <cjwatson> ari-tczew: why are you being confrontational about it, though?
[17:50] <cjwatson> or possibly s/confrontational/sarcastic/
[17:51] <ari-tczew> cjwatson: ekhm, there is no sarcasm
[17:51] <cjwatson> ok, I read it as such; apologies then
[17:51] <hyperair> oh for the love of.. why is ureadahead a dependency of ubuntu-minimal?
[17:52] <hyperair> it was recommends before!
[17:53] <cjwatson> it was never recommends as far as I can see
[17:54] <hyperair> hmm? really?
[17:54] <hyperair> i remember managing to remove it.
[17:54] <cjwatson> I just went back through the bzr logs of the seeds
[17:54] <cjwatson> it used to be more desktopish.  but anyway, you can remove ubuntu-minimal ...
[17:54] <cjwatson> ari-tczew: well, in that case, there are *lots* more merges from me in the queue waiting to be flushed. ;-)
[17:56] <ari-tczew> cjwatson: so hearing about planning a lot of merges is beauty for my ears.
[17:56] <hyperair> cjwatson: ah, i see. ubuntu-minimal got installed for some reason or other.
[17:57] <ari-tczew> I love to looking how number of remaining merges is falling down.
[17:57] <cjwatson> ari-tczew: right, earlier I thought you were saying something like "why are you guys doing merges when the toolchain isn't ready yet?". :-)
[17:58] <pitti> ari-tczew: no, the merges that I uploaded will wait until natty is thawed; not part of the toolchain (except for cdbs and pkgbinarymangler, these are in)
[17:58]  * bilalakhtar got pinged for ^^
[17:58] <cjwatson> https://launchpad.net/ubuntu/natty/+queue?queue_state=1 is what's waiting to be flushed, FWIW
[17:59] <bilalakhtar> People have begun uploading for natty? But the toolchain is still being uploaded, right?
[17:59] <ari-tczew> cjwatson: I just looked on this page. :)
[17:59] <cjwatson> bilalakhtar: you can upload, it just gets held in the queue
[17:59] <bilalakhtar> cjwatson: Of course one can upload, but there are high chances of FTBFS
[17:59] <ari-tczew> hmmm, I'm not convinced to uploading packages if toolchain is not ready. It can output FTBFS.
[17:59] <cjwatson> probably not that high
[17:59] <ari-tczew> oh, bilalakhtar :)
[17:59] <cjwatson> relatively simple C packages aren't that likely to regress
[18:00] <cjwatson> personally I'd rather get a jump on merges as soon as possible in order to try to get the initial pass done by UDS
[18:00]  * bilalakhtar checks the release process
[18:00] <cjwatson> anyway, we should be open tomorrow evening with any luck.  if that works out then it'll be the fastest opening I can remember
[18:01] <cjwatson> though the weekend timing helped there
[18:01] <cjwatson> dinner
[18:02] <ari-tczew> so natty is longer development cycle than other releases :)
[18:02] <ari-tczew> due to earlier maverick's release date
[18:03] <bilalakhtar> ari-tczew: yes, and that's good news for us
[18:03] <ari-tczew> bilalakhtar: do you plan work on reduce merges?
[18:04] <bilalakhtar> Just like jono started Operation Cleansweep for maverick, we should have another operation to reduce the number of merges down to 5 or below
[18:04] <bilalakhtar> ari-tczew: yes, that's what I was thinking about
[18:04] <ari-tczew> nice
[18:04] <seb128> lamont, there?
[18:04] <lamont> sup?
[18:04] <bilalakhtar> OC was for patches, this operation should be for natty merges
[18:04] <seb128> lamont, can you stop https://edge.launchpad.net/~ubuntu-desktop/+archive/gnome3-builds/+build/1994816?
[18:04] <seb128> lamont, it built in 19 minutes on i386
[18:05] <seb128> lamont, seems it's building again and again on amd64 for some reason or that the build is having an issue
[18:05] <seb128> lamont, the log is updating but it never finish building
[18:07] <lamont> seb128: one gtk+3.0/amd64 build slapped upside the head.  sadly, I have little-to-no visibility to see what it's really doing
[18:07] <seb128> lamont, ok thanks
[18:07] <seb128> I will do another upload in a bit let's see how that one goes
[18:39] <scott-work> Ng: hi!  Allow me to introduce myself, I am currently project lead for Ubuntu Studio.  Cory Kontros told me to talk to you about getting access the ubuntustudio.org website in order to change the release information/notes for Maverick
[18:48] <YokoZar> pitti: I could upload icoutils to lucid for SRU then
[22:21] <BUGabundo> oias
[22:52] <misha680> quick question: does the Ubuntu _merge_ process merge _new_ packages in unstable or _only those already present in Ubuntu_? Thank you
[22:52] <cjwatson> misha680: both
[22:53] <misha680> cjwatson: oh thank you, good to know
[22:54] <misha680> cjwatson: sorry one more quick question. I am working on a package that is going into a Debian Pure Blend (Debian Med). Do you by any chance know if "Debian Pure Blends" are included in this process? I believe they use standard repos but not 100% sure
[22:54] <cjwatson> misha680: I'm going to have to look up exactly what Debian Pure Blends do
[22:55] <cjwatson> misha680: as a general rule we only merge from the Debian archive (there are exceptions, but the Debian archive is the only one we actively track)
[22:55] <schwarzkopf> is there a linux tool for full tilt poker ?
[22:56] <cjwatson> misha680: http://blends.alioth.debian.org/blends/ch-about.en.html indicates that Debian Pure Blends are strict subsets of the Debian archive, so in that case yes they'll be included
[22:57] <misha680> cjwatson: thank you so much!
[22:57] <cjwatson> schwarzkopf: this is a channel for development of Ubuntu; please try #ubuntu, https://answers.launchpad.net/ubuntu, or http://ubuntuforums.org/
[23:17] <wgrant> Does anybody use dput's don't-upload-to-the-same-place-twice feature?
[23:18] <cjwatson> I don't use dput, but it's saved me mistakes in dupload a few times.  (Of course I also know how to override it when it's wrong.)
[23:19] <RAOF> No.  In fact, I should probably work out how to override that, 'cause I push to places which don't mind overwriting quite frequently.
[23:19] <wgrant> Right.
[23:19] <wgrant> And won't everything be smart enough to reject duplicate uploads this decade?
[23:25] <cjwatson> In my case I like it not because the server is going to fall over, but because it occasionally saves me time-consuming uploads
[23:26] <cjwatson> oh yegods, careless of me to end up TIL on ppp
[23:26]  * cjwatson pushes that firmly to the back of his merge queue
[23:27] <wgrant> Hah.
[23:28] <ajmitch> wgrant: REVU happo;y accepts duplicate uploads, for a good reason
[23:28]  * ajmitch cannot type either
[23:28] <wgrant> Well, true
[23:29] <wgrant> But that's not a case for preserving dput's behaviour.
[23:40] <SpamapS> does anyone else find the tracks for UDS-N completely perplexing?
[23:42] <kklimonda> what do you mean?
[23:42]  * cjwatson unbreaks MoM
[23:43] <SpamapS> Well, the ideas I have for UDS sessions are "enhance upstart for server usage" .. is that "cloud" or "other" ?
[23:43] <RoAkSoAx> SpamapS: other :) I put mine under "Other"
[23:43] <SpamapS> Also I'd like to discuss the idea of upstream-managed ppa's ... is that Application Selection Defaults or Ubuntu the Project ?
[23:43] <smoser_> why isn't that foundations ?
[23:43] <SpamapS> there is no foundations track
[23:44] <SpamapS> or server track
[23:44] <smoser_> err... i forget what the topics are
[23:44] <smoser_> have to see my list
[23:44] <SpamapS> http://summit.ubuntu.com/uds-n/
[23:44] <RoAkSoAx> SpamapS: as long as you appoint jib as the reviewer...
[23:45] <SpamapS> I think I'll just treat "Cloud" as "Cloud & Server" .. other is already HUGE
[23:46] <kklimonda> SpamapS: isn't there a "Application Developers" track? upstream-managed PPAs would fit it perfectly
[23:46] <RoAkSoAx> SpamapS: i put mine under "other" and set jib as the reviewer
[23:46] <SpamapS> kklimonda: Yes there is. I guess I hadn't thought of Drizzle or MongoDB as an application.. but thats what it is.
[23:48] <RoAkSoAx> btw... Natty is not yet open for development yet right?
[23:48] <SpamapS> No, but soon IIRC
[23:48] <RoAkSoAx> ok thanks :)
[23:49] <SpamapS> It shows up as an actual distro now
[23:50] <cjwatson> hopefully tomorrow
[23:50] <cjwatson> (late, not early)
[23:51] <RoAkSoAx> awesome :)
[23:51] <SpamapS> cjwatson: so, do you just get all of your sleep during a winter hibernation period, or have you discovered a way to avoid it altogether?
[23:51] <cjwatson> I do it in the mornings, when hackers are all asleep and don't notice
[23:55] <SpamapS> I'd tell hackers that too if I had discovered the secret. They'd all want it.
[23:58] <gtm> hi...is there someone able to export a driver from jaunty to be imported in lucid or maverick?
[23:59] <TheMuso> gtm: If its an open source driver, it should already be in lucid or maverick no?