[00:17] ahhh my pillow called... she wants me back. see you tomorrow µfriends === ion_ is now known as ion === vorian is now known as master === master is now known as vorian [01:34] Hi all i was wondering if we can file SRU's already [01:35] 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:35] Launchpad bug 513432 in bzr (Ubuntu) "AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo'" [Undecided,Confirmed] [01:37] Yes we can, there are already SRUs in the proposed queue. [01:39] cool thanks for the tip TheMuso :) [01:40] TheMuso: what do we have to do to actually get it sponsored? [01:40] posting on the bug doesn't seem to be enough [01:41] 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. === RonIn_ is now known as Guest60469 === ScottL_ is now known as ScottL [04:38] okay, this is getting annoying. why do i have to answer the same debconf questions thrice during do-release-upgrade? [04:40] Which ones? [04:49] 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] ScottK: flashplugin-installer. [04:53] there's a debconf question in flashplugin-installer? [04:53] * ScottK doesn't recall seeing any. [04:53] there is a debconf config... [04:54] I don't recall ever seeing it ask a question though [04:57] micahg: there's one asking whether or not to download [04:58] * ScottK wonders what the priority of the question is? [04:58] ScottK: not sure, but it kept popping up during do-release-upgrade [04:58] hyperair: Right, but it doesn't for others, so I'm wondering if you've got a non-standard priority set. [04:58] 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] persia: i'll give it a go later. [04:59] i've finished answering the questions. [04:59] ScottK: i didn't do anything funky with my env [04:59] or set anything in /etc [04:59] how do you change it besides that env var persia said anyway? [04:59] OK. [04:59] ScottK: on lucid the priority looks to be medium [04:59] 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] My environment variable is about cluttering output, not about setting priority. [05:00] persia: i'll redo it later, i've a btrfs snapshot. [05:01] 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] 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] I think 'debconf-show debconf' will show the priority that's being used, unless do-release-upgrade changes that [05:03] maybe. [05:05] honestly speaking, i use the 64-bit flash cp'd directly, so i'll probably manually undo all that later === almaisan-away is now known as al-maisan [07:39] Good morning [07:43] <\sh> good morning pitti [07:45] apw: got tons of WI tracker spam during the night; found the problem now [07:46] fixed, db purged [07:55] pitti: hey there [07:56] pitti: had a question - do you have an existing Best Practices example for the use of dpkg --path-{in,ex}clude? === diwic is now known as diwic_afk [08:03] slangasek: indeed I have: https://wiki.ubuntu.com/ReducingDiskFootprint#Drop unnecessary files [08:04] pitti: awesome, thanks! [08:04] slangasek: the test suite has some more, but with above example it's really everything it's meant to do [08:06] 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] 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] slangasek: if we apply that to systems that we distribute, we need to check that, of course [08:07] I don't know off-hand [08:07] if it's sufficient to provide an easy way to display the changelog, that'd be nice [08:07] pitti: my current proposed use case is distributed Linaro images :) [08:08] it's high on my list to investigate for lowering the default footprint [08:08] default? [08:08] Ubuntu standard install, I mean [08:09] a) The work must carry prominent notices stating that you modified [08:09] it, and giving a relevant date. [08:09] that's what I see in the GPL [08:09] I'm not particularly keen on the idea of removing all this stuff from a default install [08:10] slangasek: oh, just talking about changelogs for now [08:10] yeah, I'm not keen on *those* being removed from a default install either [08:10] the wiki page is meant for customized projects which are really tight on space [08:11] ohwell, the wiki page at least gets me where I'm going for right now - thanks [08:11] 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 === dapal is now known as hanska === hanska is now known as dapal [08:12] 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] since dpkg doesn't track origin info, and apt can only tell you about currently-downloadable packages [08:12] ah, I see what you mean [08:12] slangasek: no, my intention is not to use dpkg filters for those [08:13] if we do that, it should be for ubuntu packages only [08:13] I'm not sure how the dpkg filter can distinguish [08:13] but ok, at least it's on the radar :) [08:13] 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 " or similar [08:13] ah, sure [08:14] slangasek: I don't think dpkg filters are approriate for a standard Ubuntu install, due to the reason you stated [08:14] this was written for OEM projects primarily [08:16] kees: ok, can pocket-copy [08:17] good morning! :) [08:27] hey dholbach, wie gehts? [08:27] hey pitti, sehr gut - ist nur irgendwie schnell etwas kalt geworden hier :) [08:28] indeed *shudder* [08:29] <\sh> well, it's getting warmer again here in KA [08:30] <\sh> good morning dholbach :) [08:30] hey \sh [08:30] highvoltage, I'm getting more edubuntu-bugs mails now :) [08:30] and while I like more edubuntu bugs activity... :-P === diwic_afk is now known as diwic === bombadil is now known as spy6 [09:32] pitti, slangasek: just FYI: there exist several packages in Ubuntu where the changelog for just that package is measured in megabytes. === DrPepperKid is now known as MacSlow === al-maisan is now known as almaisan-away [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] 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] +1 on this, I've to resubscribe for the next -changes ML after each release [11:25] can we have both? [11:25] YokoZar: question for you in bug 622220 [11:25] Launchpad bug 622220 in icoutils (Ubuntu Lucid) "some .exe files do not show icon" [Undecided,New] https://launchpad.net/bugs/622220 [11:25] I believe several folks like having the SRU changes going to release-specific lists. [11:25] pitti: could you look at the cdbs merge for natty? [11:25] doko: yes, can do [11:25] I'd be even happy if the new -changes list is initialized with the subscribers of the previous one [11:26] geser: *nod* === MacSlow is now known as MacSlow|lunch [12:09] doko, cjwatson: cdbs merge done, tested, uploaded [12:10] 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] sure === almaisan-away is now known as al-maisan === tkamppeter_ is now known as tkamppeter [12:46] pitti, hi [12:47] 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] pitti, there is a small problem with CUPS, bug 485383. [12:55] Launchpad bug 485383 in cups (Ubuntu) "Zebra driver not found AMD64" [Undecided,Incomplete] https://launchpad.net/bugs/485383 [12:56] 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] pitti, there are principally two possibilities to fix: Moving the files to cups-common or making cups-common depending on cups-ppdc. [12:58] 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] tkamppeter: what other files are in cups-ppdc? [12:59] 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] (for natty onwards) [12:59] for SRUs, a dependency change sounds fine [13:00] pitti, some executables to manipulate PPDs, but they are never called by the PPD listing and extraction processes of CUPS. [13:02] tkamppeter: hm, then moving the two .h sounds fine to me [13:02] tkamppeter: I'm just confused, I thought we now ship pre-built compressed PPDs for everything? [13:04] 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] 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] tkamppeter: ah, I see [13:07] tkamppeter: sure, moving files sounds fine then (and they shoudl be Replaces:, not Conflicts:) [13:07] pitti, for the SRU I sugges simply letting cups-common depend on cups-ppdc. [13:07] tkamppeter: I agree [13:07] Replaces> yes, I was about to say the same thing. You should generally also add Breaks, per current Debian policy [13:07] tkamppeter: erm, cups, not cups-common? not necessary for client side only, or is it? [13:08] cjwatson: pkgbinarymangler uploaded [13:08] ta [13:08] it removes the buildinfo.gz files for now (to counteract the new cdbs) [13:08] still need to fix perl before we can open [13:08] I hope I can get to adding the PNG/SVG compression into this soon, too [13:08] but no time yet [13:09] but I expect most desktopish packages to get rebuilt several times anyway [13:09] * cjwatson nods [13:09] 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). === MacSlow|lunch is now known as MacSlow [13:09] lamont: do we have pkgbinarymangler version pinned right now? I uploaded a new version for natty [13:10] tkamppeter: right, seems these should all be moved to cups then? [13:10] lunch, bbl [13:24] Is natty open for any upload? [13:25] 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] lool: no, toolchain is being uploaded [13:25] You can check the current status at https://launchpad.net/ubuntu/natty [13:26] (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] pitti: dunno - let me go look [13:28] pitti: no holds on pkgbinarymangler since you promised to not mangle it [13:30] 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] stgraber: which team do we have to update contact address for to stop the edubuntu-spam? [13:31] lamont: do all the buildds already run on panda boards? === zyga is now known as zyga-break [13:32] the change is easy, just undo the reversion of the upstream change [13:35] highvoltage, Just the bugs team ought to work: if not you probably want to clean up which teams are subscribed to stuff. [13:35] highvoltage, Actually, you might need one for the -dev team if you assign bugs to that team. === hunt0r is now known as huntz0r [13:40] 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] 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 === bladernr is now known as bladernr_ [13:42] dholbach: I think it will be right now, let me know if you get more spam [13:42] lamont: that doesn't work. as soon as I upload eglibc with the upstream patch reverted, java fails on *every* buildd [13:42] so we have to delay this until we change all buildds to the panda boards [13:43] ogra: so that panda board, not so much use ^^ [13:43] lamont, you tried running from SD as i suggested ? [13:44] i know it will be slow as hell but should be stable [13:44] 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] highvoltage, rock on! :) [13:50] 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] or so doko tells me [13:50] and one panda board, with or without SD, isn't gonna cut it === ogra_ is now known as ogra [13:52] doko, Is the problem bbg3-specific or imx51-wide? [13:52] 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] doko, right, it seems nobody there has a clue [13:53] thats why i sent lamont the panda [13:53] but he has USB issues with it [13:53] ogra: well, it's been doing ok for a while now, maybe it settled down [13:53] the threats seem to be working [13:53] 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] great [13:56] the only purpose of that board was to build java once [13:58] But how would that help, if the result wouldn't be able to run on anything else? [13:59] after that we can send it back to TI, we cant use it much anyway [14:01] 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] doko: and beyond that we just need the debian/rules blocker gone? [14:02] lamont: ? === zyga-break is now known as zyga [14:08] lamont: cheers, thanks for checking [14:10] 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] it'll be a bit later today - breakfast plans [14:11] lamont: java -version should not segfault [14:11] awesome [14:11] I like the simple tests [14:11] :-) [14:14] doko: save me grepping Contents.gz? where does java-version come from? [14:16] lamont: [14:16] openjdk-6-jre-headless [14:16] ta [14:16] dpkg -S had nothing to say to me on the subject [14:20] Riddell, could you have a look at linux-lts-backport-maverick in Lucid? It should have gone to main, not universe. === dendro-afk is now known as dendrobates [14:21] tgardner: the source was in universe, so I NEWed the binaries to universe, too [14:22] pitti, what should I have done to direct the package to main? [14:22] pitti: ??? I put the source in main! [14:22] at least I'm sure I did [14:22] tgardner: not your fault. [14:23] you couldn't have done anything differently [14:23] linux-lts-backport-maverick | 2.6.35-22.34~lucid1 | lucid-proposed/universe | source [14:23] cjwatson, also, does it need to be seeded so it doesn't get reaped? [14:23] pitti: blink. I agree with tgardner, it should just be moved en-masse to main [14:23] cjwatson: sure, no problem; doing now [14:23] tgardner: no, because the component-mismatches stuff doesn't run on lucid any more [14:23] tgardner: ^ [14:23] (I mean, theoretically maybe, but it isn't going to fall out if you don't.) [14:24] cjwatson, pitti: thanks. I'll be uploading a meta package as well later today. [14:24] tgardner: done [14:24] hmm. looking through shell history, there's no evidence that I put it in main, so it's probably my fault === yofel_ is now known as yofel [14:25] cjwatson: I usually use the +queue page for that, you didn't use that? [14:25] 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] the "do everything through the web interface" shtick does rather assume good bandwidth [14:26] cjwatson: I mean for overriding [14:26] I was already logged in at a shell, so I just accepted it there [14:26] cjwatson: I generally use +queue for overriding kernel binaries, since it's much faster/easier than with kernel-overrides [14:26] kernel-overrides is very fast these days. [14:26] (different use case, I know) [14:27] 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] anyway, /me creates natty chroot to find out what broke pkgbinarymangler in natty [14:28] oh no, not pkgbinarymangler ... seal that back in the 9th circle [14:28] apw: well, it just FTBFSed, thanks to the picky test suite [14:29] pitti, there is a god :) === cmagina is now known as cmagina-afk === cmagina-afk is now known as cmagina [14:47] achiang, if you need it for an oem project, go ahead and apply it there on your OEM repos [14:48] achiang, but keep in mind that some drivers you can't ship in pre-built form anyway [14:49] huh, how did /var/crash disappaer >_> [14:50] what are the permissions and ownership of /var/crash? [14:54] hyperair: the upstart job creates it if apport is enabled [14:54] (which it isn't for the final maverick) [14:54] mkdir -p -m 1777 /var/crash [14:54] tgardner, apw: will there be a new linux-libc-dev before opening natty? [14:54] pitti: well, ubuntuone-client or something had a script failin due to missing /var/crash. [14:55] 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] 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] 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] doko, actually, it works pretty good. apw and I have been running it for weeks [14:58] it's these time when I whish the headers would be built from a separate source [14:58] tgardner: then just upload? [14:58] yeah well one of us needs to blink first :) [14:59] apw, you wanna fire up the first package to make the upload rights are working? [14:59] make sure* [14:59] tgardner, sure thing [14:59] apw: note that gcc-4.5 is the default now [15:00] apw, you might wanna think about dropping the brcm staging patches. it doesn't work well enough yet for the real world === bjf[afk] is now known as bjf [15:13] mdeslaur: can you please forward the patch for bug 456710 to Debian? I just merged the package (I was TIL) [15:13] Launchpad bug 456710 in aide (Ubuntu Karmic) "aide chokes on UTF-8 characters in pathnames in config file" [Undecided,Fix released] https://launchpad.net/bugs/456710 [15:13] mdeslaur: and you know better what exactly the patch was for [15:14] pitti: hmm...I thought I did...let me search for it [15:14] apw: we checked packageset permissions, BTW, so your upload permissions should work fine [15:14] mdeslaur: the other fix for comments in apt sources was accepted [15:15] cjwatson, thanks :) === zyga is now known as zyga-afk === diwic is now known as diwic_afk [15:34] pitti: done, thanks! [15:34] mdeslaur: great, thanks [15:35] hi guys [15:36] I've got a question about linking bindings to a shared library that was produced in the same source package [15:37] 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] I ended up copying the .so in obj/ to build the PHP module and removing it afterwards [15:37] is there a cleaner way to do this? === cking is now known as cking-afk === ivoks-afk is now known as ivoks === diwic_afk is now known as diwic [15:47] pitti: what does "TIL" mean? [15:47] mdeslaur: touched it last [15:47] oh, hehe...thanks [15:50] anyone has an answer? [15:51] 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] I've tried to add a -I flag [15:52] but libtool ignores it [15:52] I've checked libtool's code, it specifically removes anything that contains .libs [15:52] another option would be to have two different install targets, but it gets the packaging quite more complicated === deryck is now known as deryck[lunch] [15:57] persia: see, you get to be the one answering ;-) [15:57] raphink: I thought you were supposed to pass the .la file to libtool when linking [15:57] that's how it works for me anyway ... [15:57] well that works for i386 [15:57] raphink, Sure, but other, wiser, folk correct me when I make mistakes. [15:57] but not with amd64 [15:57] because it complains about -fPIC [15:58] so build the shared objects with -fPIC :-) [15:58] they generally should be anyway [15:58] 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] linking with the .la shouldn't normally cause linking against the static library [15:58] ah, right it's .a right? [15:59] .a => static library, .la => libtool archive [15:59] right [15:59] ok, so .la and .so are in .libs after the build [15:59] so I pass -I/path/to/.libs [15:59] and it's ignored by libtool [15:59] why -I? [15:59] sorry [15:59] -l I mean [16:00] that doesn't make sense either [16:00] wait, let me check before I say more stupid things ;-) [16:00] MoM should probably exclude *build* [16:00] -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] yes, -L [16:00] Does that not create a path entry in the library? [16:00] although I guess it won't be a problem after autosync happens [16:01] Laney: bug 366532. and indeed not [16:01] Launchpad bug 366532 in Merge-o-Matic "Please don't list xbuildy packages on merges.ubuntu.com" [Undecided,Confirmed] https://launchpad.net/bugs/366532 [16:01] but then libtool ignores .libs, so it ends up linking against the .a which doesn't work for amd64 because of -fPIC [16:01] 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] raphink: there should be a .la file outside .libs for you to use [16:01] ok [16:01] let me check [16:01] I'll have to rebuild to see I think [16:02] for instance in bzr trunk of man-db, src/Makefile.am sets LIBMAN = $(top_builddir)/lib/libman.la [16:02] 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] ok [16:02] let me check cjwatson [16:02] 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] I'm inclined to agree with Laney; AFAICT it's an oversight that we don't exclude *build* [16:03] persia: you mean chdist ? [16:03] especially since one bit of MoM already does [16:03] ./generate-patches.py:78: if search(".*build[1-9]+$", our_source["Version"]): [16:04] * Laney branches [16:05] too late ;-) [16:05] :) [16:05] hmmm [16:05] i see some interesting new things in /etc/default/grub [16:05] 1-9+ isn't quite right though [16:05] what's BadRAM? [16:05] build10? [16:06] hyperair: info grub [16:06] [0-9]+ might be better. [16:06] cjwatson: okay thanks. [16:06] Laney,persia: fixed [16:06] let me know if that works out ok [16:06] cjwatson, Thanks for the quick change. [16:06] thanks [16:07] I wish I could remember how to show the diff introduced by the latest commit in bzr [16:07] cf `git show' [16:07] if it causes a practical issue with blacklisted stuff, we can figure something out [16:08] bzr di -clast: [16:08] * Laney memorises [16:08] or 'bzr alias show="log -v -p -n1 --long"' and then 'bzr show -rlast:' [16:08] 95% of blacklisted stuff is because we pull upstream faster than Debian, and Debian pulls from us. [16:08] The other 5% is probably caught by MDT, and needs manual merging anyway. [16:08] hey, what's the status of toolchain? [16:09] 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] oh, and python is going in first too apparently [16:11] ok thanks [16:11] can we upload stuff to the queue? [16:11] Laney: yes [16:11] good to know [16:11] 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] reminds me to poke at ghc there [16:13] heh [16:25] <\sh> micahg: pingeling -> zend-framework 1.10.8 official backports??? :) === cking-afk is now known as cking [16:25] \sh: as in the backports pocket? [16:27] <\sh> micahg: yepp...from 10.10.10 to 10.04 [16:29] 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:29] Launchpad bug 568067 in geoip (Ubuntu) "Default timezone for the country 'PT' is wrong, should be 'Europe/Lisbon'" [Undecided,New] https://launchpad.net/bugs/568067 === zyga-afk is now known as zyga [16:38] 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:40] [16:41] http://jira.mongodb.org/browse/SERVER-1764 [16:41] * hyperair pings cwillu_at_work [16:41] "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] Something has to be done [16:41] cwillu_at_work: were you the one who worked on the btrfs + grub issue? it seems to be around with maverick =( [16:41] Every single upstream thinks its ok to embed library source code in their tarballs now. :-/ [16:43] there, finally reproduced my issue :-) [16:43] cjwatson, persia [16:44] http://pastebin.com/YTcFjfeN [16:44] it tries to link against the .a [16:44] even though there is a .la [16:44] not with the exact same name though [16:45] rpinson@condor:~/packages/db/db5.0-5.0.26$ ls obj/*.la [16:45] 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] maybe that's the issue cjwatson? [16:48] hmm no, symlinking libdb_cxx.la doesn't help [16:49] cjwatson, persia: the problem is that the following line seems to search for a .a [16:49] 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] cjwatson: hmm, does your last change did this on MoM? Updated Merges: 0 [16:50] tgardner: should be [16:51] 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] cjwatson, cool [16:52] ok cjwatson, thanks === al-maisan is now known as almaisan-away [16:52] I end up having to copy the .so to get it to work though [16:52] for some reason [16:52] ari-tczew: what's wrong with that? [16:53] that's what I'd expect given that no universe merges have been uploaded yet [16:53] persia: any idea ? [16:53] It doesn't look like there has even been a run since the latest changes anyway [16:53] shouldn't think so, no [16:53] cjohnston, Why does main/universe matter in that context? the relatively small number of merges + the squeeze freeze is likely more significant. [16:54] raphink, Sorry, you were at the edge of my knowlege of library packaging when you started,and I'm lost. [16:54] cjwatson: I didn't say wrong. I just saw refresh in MoM. [16:54] persia: YM cjwatson HTH [16:54] persia: ok, my ack copying the .so to build the PHP module works fine, I don't know if that's acceptable [16:54] persia: it matters because the page that displays "0 updated merges" is https://merges.ubuntu.com/universe.html. [16:54] cjwatson: I never understood what's the difference between outstanding and updated merges. [16:54] s/ack/hack/ [16:54] * persia finds egg,and carefully applies to face [16:55] 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] o_O [16:56] cjwatson: hmmm, did this one worked in the past, or you fixed this in MoM trunk? [16:56] ari-tczew: that's how it's been for years [16:56] (and working for years in my experience) [16:56] MoM's interface is really rather stable [16:57] cjwatson: So I'm not too perceptive. [16:57] https://code.launchpad.net/+branch/merge-o-matic shows what I changed recently [16:57] cjwatson: are you interested in merging proposed changes to MoM? [16:57] yes I know and I'm looking on this right now [16:58] ari-tczew: not desperately, I was just trying to get it minimally working for natty opening [16:58] I don't know the code that well; if you can get hold of Keybuk he's better to review actual work [16:59] cjwatson: ok, I only asked, because MoM looks like orphaned. === deryck[lunch] is now known as deryck [16:59] "maintenance mode" [17:03] superm1: well, i'm more interesting in finding out why you think my approach is wrong === sconklin1 is now known as sconklin [17:05] 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] cjwatson: about revision 182. does it should prevent produce *buildX versions in MoM? [17:06] trunk isn't stable for dkms right now anyhow, haven't had enough time to fix it yet either [17:07] joaopinto: I've filed a sysadmin ticket [17:07] ari-tczew: yes, after the next time it regenerates [17:08] cjwatson: so next MoM update will remove *buildX packages? [17:08] ari-tczew: should do === diwic is now known as diwic_afk [17:08] ok understand [17:08] 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] 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] superm1: to understand why, you just need to go read the top-level kernel makefile [17:27]