[00:04] is the kernel frozen for 12.04? [00:08] eightyeight: https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule lists kernel freeze as april 5th [00:36] slangasek, :-( no. [00:36] i'm sorry. [00:37] smoser: hmm. are there any tests in particular you'd like us to do before landing it in the archive? [00:37] (ones that we can get done before FF, I hope) === Ursinha_ is now known as Guest63174 [00:47] i dont have a lot of expectancy of failure. [00:47] for it. [00:47] cloud-init is generally fairly light on it. uses mounted event nof '/'. [00:48] Has there been a security bug filed for seclists.org/fulldisclosure/2012/Feb/254 [00:50] smoser: sure; we're being very cautious this time around, owing to the two previous false starts [00:51] so if you don't think there's anything special we need to test, I can just go ahead with the upload [00:52] slangasek: thoughts on https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/858122/+attachment/2683183/+files/insserv_1.14.0-2.1ubuntu1.unstable.debdiff ? it seems reasonable (modulo needing quilt and changelog adjustments) [00:52] Launchpad bug 858122 in sysvinit (Ubuntu Precise) "incomplete migration to /run (shutdown script order has been demolished)" [High,Triaged] [00:53] if it's ok with you i can upload it and prep/upload an oneiric sru [00:54] slangasek, i'll start an instance and install right now. [00:54] ppa link ? [00:55] smoser: ppa:jamesodhunt/upstart-job-logging [00:55] broder: YES PLEASE [00:55] [00:56] slangasek: haha, ok. any thoughts about attempting to unwind the damage? [00:56] broder: I think I sketched something out on the bug about manually putting the key bits of /etc/rc{0,6}.d back where they belong if we detect this kind of massive breakage on upgrade [00:57] broder: we might not get all of it right, but we can at least get the core initscripts stuff [00:57] ok. i'll sketch something up. it'd be nice to have you review it, since complex maintainer scripts are easy to screw up [00:58] :) [01:00] what could go wrong [01:00] mwhudson: little more than already has done P [01:00] :P [01:00] look, i'm absolutely terrified of uploading insserv. that's why i'm forcing slangasek to sign off on anything i do - so i can at least spread the blame :) [01:04] slangasek, ok. initial snif done. [01:04] smoser: thanks :) [01:04] no kittens sacrificed. 2 instances booted twice each. [01:13] slangasek: ok, that actually seemed a little more straightforward than expected. how does http://paste.ubuntu.com/843826/ look to you? [01:15] broder: I had been thinking in terms of the fix-up being done in initscripts, as the owner of both the scripts in question and the /run transition that's gotten clobbered; are you sure that doing the fixup from insserv will dtrt everywhere? [01:16] hmm, not really. i hadn't thought about it all that hard [01:16] i guess i figured that correcting the shutdown sequence from anybody's postinst -> initscripts shutdown script will do the right thing next time you reboot [01:17] ScottK: bug 634215 - why are all-numeric host names prohibited? I mean, I get that they might be considered unwise in some contexts, but my reading of RFCs 952 and 1123 in conjunction is that all-numeric host names are permitted, and indeed I think 1123 indicates that host software MUST support them [01:17] Launchpad bug 634215 in ubiquity (Ubuntu) "ubiquity-kde install allows invalid hostnames" [Wishlist,Triaged] https://launchpad.net/bugs/634215 [01:17] broder: two other things: 1) if the runlevel's been broken, you'll see S0{1,2,3}reboot; maybe it's better to check for one of these values instead of just !90, in case the admin had some other reason for renumbering (e.g., having fixed up all their init scripts so insserv actually works for them)? 2) the fix-up needs to handle rc0 in addition to rc6 [01:18] cjwatson: hmmm, stgraber brought that one up the other day and I asserted that all-numeric is illegal; perhaps I should dig up a real reference :) [01:18] cjwatson: in *practice*, an all-numeric hostname gets butchered by various unix tools, which will helpfully interpret it as a decimal encoding of an IP [01:19] slangasek: ok. i guess i need to s/reboot/halt/ for rc0, but other than that fix up the same scripts in the same way? [01:19] slangasek: but if you'd rather have this in initscripts, i'll drop the postinst from insserv and upload it, then we can work on getting initscripts fixed [01:19] slangasek: I'm not necessarily opposed to making the installer forbid them, but I feel I'd like to have chapter and verse here :) [01:20] especially since netcfg has the same algorithm [01:20] broder: yes, s/reboot/halt/ should be the only change... and yeah, I have a slight preference for putting this in initscripts, rather than embedding knowledge of another package's init scripts in the insserv postinst [01:20] slangasek: i'm fine with that [01:21] cjwatson: from my last RFC reading (last week), there's nothing explicitly prohibiting the use of all-numeric host names, as long as they aren't also used as part of a DNS record (where a DNS label can't be made of all-numeric) [01:21] stgraber: where does that restriction come from? [01:22] cjwatson: 1912 IIRC [01:24] cjwatson: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=65041#34 ? [01:24] Debian bug 65041 in libc6 "glibc does not allow numeric hostnames" [Normal,Open] [01:24] rfc2181 pretty much throws it all out the window, and only keeps the 63-byte restriction. [01:25] But there's no reason systems can be more restrictive than the RFC (and, in our case, reasons why we need to be). [01:26] well, gethostbyname() is a deprecated interface, but we either have to modify its behavior or accept that anything using it will be broken with numeric hostnames [01:26] ah, gotcha [01:26] that's probably enough for me to change netcfg too then [01:27] (also, not sure if the glibc implementations of the ipv6-friendly interfaces actually do a better job with them?) [01:30] * infinity figures the summary at the top of http://www.zytrax.com/books/dns/apa/names.html is a fair representation of the pre-2181 rules, and probably not an awful constraint for installers to impose. [01:30] cjwatson: ^ [01:33] cjwatson: The hostname itself can be all numeric (the machine name), but the top level domain (at least historically can't). Says so in RFC 1123 paragraph 2.1. [01:34] That point's clear (although the RFC is mainly making an observation about the existing set of TLDs, I think ...), but you aren't entering an FQDN in ubiquity. [01:35] slangasek: do you have an opinion on whether or not i should also move /usr/sbin/{update-rc.d-insserv,update-bootsystem-insserv}? [01:35] infinity: I don't see anything in 2181 that changes that. [01:35] * slangasek looks at broder blankly [01:35] broder: not knowing what these are or why they exist, I don't have an opinion :) [01:35] cjwatson: It used to be that all numeric wasn't allowed for the machine name, but that changed, so maybe I was confused. [01:36] "update-rc.d-insserv is an obsolete implementation [...]" [01:36] seems like upstream should move that one to /dev/null [01:36] and the other one is a trivial script we don't need to care about [01:36] broder: ^^ so I think it's not worth moving them [01:36] The gethostbyname problem is somewhat persuasive. [01:36] ScottK: We weren't talking about FQDNs until just now... [01:36] slangasek: ok. sounds good [01:36] OK. [01:36] never mind me then. [01:45] I've mailed debian-boot to ask if anyone cares if I make such a restriction [01:53] * infinity remembers the bad old days when various operating systems used to tell him that his domain name was invalid. [01:54] You were just testing them, right? [01:56] cjwatson: NT4 had hissy fits about 0c3.net until SP3, I believe. [01:56] cjwatson: Which caused me some grief. [02:00] oh what the heck. why does insserv ftbfs, but only in sbuild [02:00] ...with fopen(file_the_test_suite_just_wrote_out): Operation not permitted [02:00] broder: In your local sbuild, you mean? [02:00] infinity: yeah [02:00] broder: Is that running on top of an overlayfs-using schroot? [02:00] broder: If so, that's your answer. [02:00] ...seriously? [02:01] ugh [02:01] broder: The good news is that the buildds won't fail that way. :P [02:01] broder: The bad news is you need to test without overlayfs locally. [02:01] wait, but why does it not happen if i build it with schroot dpkg-buildpackage, but not using sbuild? [02:02] oh, i guess that would be hitting one of the bind mounts [02:02] what is overlayfs doing wrong? [02:02] broder: overlayfs plays fast and loose with inodes in ways that can confuse tools that assume that inodes don't (or do) change based on certain actions. [02:03] oww [02:03] broder: The tools (or, in this case, test suite) are usually wrong, not overlayfs, but... [02:04] ok. since i *can* build it without copying the source into the overlayfs, i'll go ahead and move forward [02:04] infinity: out of curiosity, is there documentation of usual overlayfs issues? [02:04] I have a local buildd that I was just about to switch from LVM chroots to overlayfs one of these weekends... [02:04] geofft: Mostly in apw's head, and scattered around to others who've had to deal with it. :P [02:05] geofft: If you have a working LVM setup, I see no compelling reason to switch. [02:05] infinity: "working" is a bit much, it randomly panics during rebuilds every so often [02:05] Special. [02:06] also LVM snapshot-based chroots are borderline unusably slow, especially when there are a lot of them in action [02:08] Anyhow, other than "some software makes stupid assumptions about filesystems that it shouldn't" and "overlayfs doesn't support inotify", I can't think of any other known gotchas. [02:08] (hm, I'm misremembering, we switched it to aufs IIRC because of the slowness, and aufs brings the panics) [02:35] is it possible to request a sync from a PPA instead of from debian (or maybe not a sync, but something along those lines?) [02:35] andy753421: raise a sponsorship bug and link to the PPA. [02:40] man, Daviey is still awake? [02:40] * nigelb looks at the clock and gets confused [02:41] nigelb: yes [02:41] Daviey: Go to bed you crzy person.. err, I mean.. Hi! [02:41] nigelb: heh [02:41] :) === Sir_Konrad is now known as ValkyrieMissle [02:55] * dobey wonders if he could possibly get someone to review https://code.launchpad.net/~dobey/ubuntu/precise/twisted/backport-gireactor/+merge/93329 tonight [03:32] slangasek: that insserv fix technically needs to be sru'd to lucid through oneiric, right? [03:54] err, that's a dumb question that i know the answer to, since i hit the bug after installing vmplayer 4 on natty [04:40] Good morning [05:07] broder: it's beneficial to SRU it to lucid through oneiric, but the most important is oneiric because that's where things go wrong with initscripts... for the other releases, nobody's reported any bugs yet === soren_ is now known as soren [05:29] soren`: ?!?!? [05:29] soren`: You're officially freaking me out. [05:30] Oh! That thing! [06:35] slangasek: i installed vmplayer 4 on natty before upgrading to oneiric, triggering the bug [06:38] broder: and the fixed initscripts cleaned it up suitably? [06:39] slangasek: err, haven't made it that far in testing yet [06:39] ok :) [06:39] at the time, i think i went for the "nuke it from orbit" approach of rm /etc/rc*.d/[SK]* && dpkg --reconfigure --something-clever [06:45] broder: --force-confmiss probably? [06:45] i thikn i just had a complicated one-liner to figure out all the packages that had scripts in /etc/rc*.d and then reconfigure them to run update-rc.d [07:04] slangasek: whoa!! vmware fixed their installer in 4.0.2! [07:04] it checks for update-rc.d before insserv now [07:08] slangasek: anyway, if i run insserv in my precise vm by hand and then install http://paste.ubuntu.com/844050/, it does seem to fixup the symlinks as expected [07:09] it didn't seem like there was a particular spot in the postinst the code needed to live, so i picked a point a bit above the /run transition code, since it seemed like this should probably be fixed up before then === tkamppeter_ is now known as tkamppeter [07:26] pitti, am I reading this right? Feature Freeze is today, but only a few problems (all armel) in the archives, and all of the ISO smoke tests but one are passing? [07:26] that's pretty cool [07:26] rickspencer3: yes, the recent compiz upload broke armel unfortunately :( [07:27] rickspencer3: otherwise it's holding up pretty well indeed [07:28] well, I think it's a great result, especially for the week of feature freeze [07:29] not sure whether didrocks has a trick up his sleeve to fix compiz on armel, though [07:29] pitti: the issue is in kelibs [07:29] kdelibs* [07:29] I ask Riddell to look at it [07:30] rickspencer3: just to be clear, compiz FTBFS on armel is due to kdelibs which ship a broken header, Riddel is already aware about it [07:30] thanks for the update didrocks [07:31] just to be clear, I wasn't actually complaining, as I don't recall being close to this tight on previous FF days ;) [07:31] yeah, it's just on this one "not compiz fault" :) (most of the time, it is, not one that though ;)) [07:32] bdrung: do you care about the vlc FTBFS on powerpc? if not, we could just remove the powerpc binaries === jodh is now known as jhunt [08:15] mvo: sorry, was in the wrong channel, can I drop the intltools patch from aptitude? it's commented out, but it's a 50k line diff [08:19] micahg: yeah, if po and source are in sync again that is really not needed anymore [08:19] mvo: is there an easy way for me to check that? [08:21] micahg: well, I guess what it comes down to is if there are no po file diffs in the other patches it is fine [08:21] mvo: ah, ok, I'll check, thanks [08:23] nope, no po diffs, so I can drop it from the source then (I assume it's easy to recreate again)? [08:23] didrocks: as I said on the bug report nobody knows how to solve that compiler error, either get someone to port the code or drop the compiler -Werror or drop the kde compiz bits, alas I don't have time for much non-Kubuntu while I'm still allowed to work on it [08:25] Riddell: ok, I'll drop the kde build from compiz then [08:25] not sure anyone is using it anyway [08:25] if* [08:26] micahg: yeah, thats fine [08:26] micahg: its auto generated [08:26] anyway [08:26] ok, thanks [08:26] ta! [08:27] I still need to finish it, the patches need refreshing, but I'm hopeful :) [08:29] didrocks: just be gentle so we don't get "you don't care about kde" comments! [08:30] Riddell: hum? I just meant that people using kde are on kwin I guess, not compiz [08:30] Riddell: I'll make it clear in the changelog, no worry :) [08:30] didrocks: yes you're right. but if one troll sees it differently it could go down badly [08:31] Riddell: right, will take great care on the changelog ;) [08:31] (and I've had to do more than enough media and community management recently as it is!) [08:56] RAOF, Laney: do you have an idea about https://launchpadlibrarian.net/93054472/buildlog_ubuntu-precise-i386.tomboy_1.9.5-1ubuntu2_FAILEDTOBUILD.txt.gz ? it built fine locally [08:56] I guess there's a missing build dep which I have installed locally; cli-common-dev ? [08:56] * apw wonders how long before the archive might not remove every :i386 package he has installed [08:57] did that change recently? the previous tomboy built fine without it [08:57] apw: gcc-4.6/i386 still building :/ [08:58] the compiler causes this mess, we really should build that in a PPA and copy it in if its going to cause utter uninstall every time [08:58] apw: we had a lot of similar cases recently (webkit, compiz, glibc, etc.) [08:58] pitti, i take it that means the compiler triggers a multi-arch missmatch if amd64 and i386 don't hit together [08:59] apw: we discussed using precise-proposed for this, so that we have ONE staging area instead of dozens of PPAs, and we can copy binaries (which is really a main point) [08:59] apw: correct [08:59] pitti, hehe thats funny, thats was my solution too :) [08:59] we just need a LP tweak to allow this [08:59] using ppa doesn't work, or we need non virtual ones [08:59] but yeah, -proposed would be better [09:01] great, and now the buildds are all firefoxed [09:01] pitti, i guess one needs to be able to copy your own packages from devel -proposed [09:01] for that work work any [09:02] apw: yes, but I don't consider that a blocker [09:02] initially we'd only use it for a few packages which are huge and known to cause major damage if they FTBFS or go out of sync [09:02] such as yesterday's mysql, or glibc, or webkit [09:03] pitti, yeah that is a reasonable plan indeed if its optional like that [09:03] pitti: vlc will build on powerpc once the final 2.0.0 is released. [09:03] apw: and for the time being it's a simple script invocation by any archive admin [09:03] sru-release precise glibc [09:04] (we might rename it for this) [09:04] bdrung: ah, thanks; I have a local build prepared that disables altivec for now, want me to try that? [09:05] pitti: no. can you grab 2.0.0+git20120215+r81-0~r28~oneiric1 from https://launchpad.net/~videolan/+archive/stable-daily and try to build that on powerpc? [09:06] bdrung: that's more effort/responsibility than I'm willing to take [09:06] I don't care AT ALL about powerpc, just about getting rid of the NBS dependencies :) [09:06] (in fact, I think we should have killed it long ago, but *shrug*) [09:08] pitti: you could either wait a few days or remove the powerpc binaries in the meantime. do what you prefer [09:08] bdrung: ok, thanks [09:16] oh how I love php's crappy multiarch [09:17] RAOF, Laney: ah, tomboy does b-dep on cli-common-dev, so it's not that [09:18] so, I'm lsot :/ [09:18] pitti: It's the DLLMap in debian/ [09:18] WebSyncServiceAddin.dll.config probably [09:18] the soname needs fixing there [09:18] did you build on a system with libproxy0 installed? [09:19] Laney: yes, it's still installed here [09:19] Laney: but the source diff was a no-change upload (http://launchpadlibrarian.net/93053939/tomboy_1.9.5-1ubuntu1_1.9.5-1ubuntu2.diff.gz) [09:19] the DLLMap references the soname, it needs to be updated [09:20] Laney: ah, so that's why it worked locally [09:20] yeah, it probably would have failed in a chroot [09:20] Laney: thanks, doing this [09:20] np === directhe` is now known as directhex [09:40] hey [09:41] where is app development channel? [09:43] gotwig: look at the topic: #ubuntu-app-devel for app development on Ubuntu [09:45] bdrung: it will be an app for ubuntu [09:45] I know, what ever [09:59] hi guys, I'm running precise on my laptop and did a partial upgrade this morning, [10:00] I encountered http://pad.lv/933343 and after reboot I can only login with the recovery console (Unity and Unity 2D are not presented anymore in the lightdm menu) [10:00] Error: Could not gather data from Launchpad for bug #933343 (https://launchpad.net/bugs/933343). The error has been logged [10:01] I also encounter transient connection issues during 'apt-get update' for extras.ubuntu.com and archive.canonical.com [10:02] apt-get -f install failed with... ha, it was failing on the flash stuff but has just started downloading... hold on ;) [10:29] ok, with archive.c.c letting download the flash upgrade, everything is back to normal, more fear than harm ;) [10:49] Hi, We released Onboard 0.97.0 yesterday and it has been accepted as onboard 0.97.0-0ubuntu1 into Ubuntu main. Shortly afterwards, a bug with translations appeared, we already fixed it in trunk and are going to release 0.97.1 today. My question: Are micro releases (i.e.: 0.97.1-0ubuntu1) accepted in feature freeze or should I rather submit it as patch creating onboard 0.97.0-0ubuntu2? [10:50] frafu: bug fix only releases aren't a problem generally [10:50] well, at least at this point [10:56] They're really not a problem up until beta [10:56] really, beta2 === Guest18047 is now known as zumbi [11:01] micahg, SpamapS : So bugfix micro release updates are accepted until beta2. These were the pieces of information I was looking for. Thanks to both of you. [11:04] frafu: its not a hard and fast rule.. but generally yes, fixing bugs up until the betas are out is a good idea [11:04] frafu: after beta2 .. its up to the release team [11:10] SpamapS: Maybe a few more words to the procedure to get it accepted until beta2: I should file a bug containing a debian source package based on the new micro release and add the Ubuntu Sponsor Team to the bug; correct? [11:11] frafu: correct. Make sure you reference upstream bug comments/commits/etc. [11:12] the procedure should be the same as before FF (perhaps just mention in the bug that it's a bugfix release and adds no new features) [11:12] * SpamapS wills the PHP test suite to pass, so he can sleep [11:13] SpamapS, geser: Thanks [11:22] alright.. latest (sane) version of PHP uploaded.. [11:22] Isn’t that an oxymoron? :-P [11:23] PHP is perfectly sane. Its the users who keep using it expecting a different result (non-suckage) [11:24] SpamapS: did the new sbuild help for dependency resolution? [11:24] micahg: nope, still have to use aptitude resolver [11:25] micahg: I haven't dist-upgraded since Friday.. was a new one uploaded this week? [11:25] SpamapS: I uploaded it tonight, commented on your bug :) [11:25] micahg: I'm sure I'll have to build php5 again this cycle. :) [11:26] especially if we go to 5.4 :) [11:27] micahg: high degree of liklihood there will be *another* RC [11:27] SpamapS: did php manage to get 5.4.0 out yet? :) [11:27] micahg: they broke signal handling, badly [11:27] aha [11:27] ajmitch: they promised "late December", or "at the latest January" when I proposed 5.4.0 at UDS [11:27] the neverending story of php releases, and even then x.y.0 isn't really LTS materiel :) [11:27] well [11:27] promise is a strong word [11:28] they thought they could hit that [11:28] ajmitch: agreed [11:28] It would take a lot to convince me that 5.4.0 will have less regressions than 5.3.10 [11:28] * ajmitch should keep 5.4 merged in his PPA [11:29] I fully expect we will ship 5.4 in 12.10 [11:29] even if 5.4.0 has no regressions, there are plenty of other packages that it can break [11:30] so mariadb vs mysql might get sorted at UDS? === _salem is now known as salem_ [11:30] * micahg hopes it gets sorted before release [11:31] Heh, its a hot button item. definitely needs wide discussion. [11:31] that'd be preferable, with the 5 year support thing :) [11:32] I had hoped to sort it by today, but I'd rather go the FFE route than jump blindly into something we don't fully understand. [11:39] What do I need to do, to try to make sure, a specific package is pulled from upstream (debian) into precise? This particular package is not a base/core package, but something that really should be in repo in a modern version... (pmacct - version 0.12.5 - http://packages.debian.org/sid/pmacct) [11:41] tmus: it needs to be merged [11:42] tmus: actually.. it looks like it can be synced [11:44] tmus: requestsync unless SpamapS is already processing it [11:44] SpamapS, can I somehow "suggest" such a sync somewhere? [11:44] micahg, aah, googl'ing requestsync [11:44] tmus: yes there is a program, 'requestsync', that will file a bug [11:44] tmus: install ubuntu-dev-tools (available in debian as well) [11:44] syncpackage: Request succeeded; you should get an e-mail once it is processed. [11:45] yes, sorry.. next time.. use requestsync. :) [11:46] SpamapS, Does that mean you requested a sync of it right now? :-) [11:46] alright and with that, I will retire to my tempurpedic [11:46] * micahg wonders if SpamapS can build something that fast [11:46] micahg: pmacct is tiny [11:46] micahg: and the Ubuntu delta was my own, which was applied in Debian. :) [11:47] heh, previous experience ftw :) [11:47] I should go back through all the libmysqlclient bugs I filed and sync back up [11:47] awesome! :-) [11:47] anyway, right now, I will retire to the tempurpedic [11:47] thanks [11:49] tmus: should be available within 60 minutes in precise [11:49] tmus: I stand corrected.. should be available on i386 within 60 minutes in precise ;) [11:49] more like 3 - 4 hours on amd64 [11:50] FF always backs up the buildds :-P [11:50] yeah, someone's hogging a lot of the buildds :) [11:50] micahg: *stare* [11:50] SpamapS, perfect... I know of a few minor issues with it - already resolved locally - and communicated upstream. Will it simply be re-sync'ed later on or do I need to file bugs and patches for the ubuntu version as well? [11:50] :D [11:51] * micahg is actually surprised at the lack of feature freeze uploads [11:51] * micahg will upload aptitude when he wakes up [11:51] must be the LTS-nature of this release [11:52] Yeah we're actually trying not to break this one ;) [11:52] tmus: You will need to use requestsync if things are fixed in Debian [11:53] tmus: auto-syncing will resume after precise is released [11:53] SpamapS, okay, cool - I'll make sure things are fixed in debian [11:53] Thanks a lot [11:53] tmus: if Debian can't get them fixed.. then feel free to file a bug w/ a patch in Ubuntu as well, and subscribe ubuntu-sponsors .. [11:53] ok [11:53] sleep [11:53] now === tomreyn_ is now known as tomreyn === MacSlow is now known as MacSlow|lunch [12:38] yes! finally gcc-4.6 landed in archive [12:39] time to rebuild cross toolchain === Tonio__ is now known as Tonio_ [13:25] bdrung: FYI your vlc package (that you were talking about with pitti this morning) fails to build on powerpc; are you already aware of that or do you want the log? [13:25] cjwatson: I talked to bdrung about it this morning [13:26] he says the final release will fix it === MacSlow|lunch is now known as MacSlow [13:27] I read that discussion, and he said to try a PPA package which should fix it. I tried it and it didn't. That's why I'm mentioning it to him [13:27] Looks like missing -maltivec when building the altivec module, possibly. [13:32] Hi All, I'm planing an update of the Inkscape package to the latest upstream version (the Debian maintainer is inactive). My issue is that the Debian package uses the now-obsolete dpatch system, and this is giving me a lintian error (not warning). Do I just ignore the error, or should I convert the package to using quilt? [13:33] It's best not to do major packaging rearrangements as Ubuntu deltas, on the whole [13:33] The purpose of the Lintian error is to encourage Debian maintainers to stop using dpatch [13:34] At this point it's not a big deal for Ubuntu, except in that we'd generally like to reduce the breadth of alternatives in our packaging tools; but not urgent, anyway [13:35] Great, thanks for the explanation. I'll just update the upstream component of the package then, and leave the patch system alone. === doko_ is now known as doko [14:48] slangasek: dpkg-reconfigure doesn't know about $DPKG_MAINTSCRIPT_ARCH? [14:53] mvo: hi. have some time today to talk about bug 876298 ? [14:53] Launchpad bug 876298 in update-manager (Ubuntu) "[MASTER] We need to better handle external payloads (Flash, msttcorefonts) not being available." [High,Triaged] https://launchpad.net/bugs/876298 [14:58] barry: I have a meeting now, maybe later? [14:59] mvo: devx? me too (if i can get it to work this time ;). after would work [15:03] barry: yeah, devx - its in g+ === arand_ is now known as arand [15:04] mvo: i think i need to be invited. i don't see it [15:07] barry: oh, sorry === albrigha is now known as Guest39130 [15:10] cjwatson / doko: Please don't scream.. but the experimental python udeb.. still an option? [15:10] (^ roaksoax: fyi) [15:11] Daviey, it's in the archive [15:14] it is?! I thought it was still a 'maybe' [15:14] it's only there for python3.2 [15:14] rmadison -s precise -S python3.2 [15:16] ahh [15:17] shouldn't be that hard to use python3 for a new project [15:22] cjwatson: right === Guest39130 is now known as albrigha [15:28] bah, the new Xorg with nividia drivers is so unstable ... getting logged out every 2h [15:30] doko, use a tegra ;) thats stable nvidia ;) [15:36] cjwatson, i have an initramfs-tools update to include hyper-v modules to allow root to be on paravirualised disks, i am wondering if you might be able to look it over: lp:~apw/ubuntu/precise/initramfs-tools/add-hyper-v-drivers [15:40] apw: looks good to me [15:44] TheMuso: I am getting lots of reports of "Failure: Module initalisation failed" on start-pulseaudio-kde, can you check? [15:46] mdeslaur: dpkg-reconfigure> correct [15:48] what does linux-source synaptic's package do? [15:48] slangasek: ok, so I have to get rid of $DPKG_MAINTSCRIPT_ARCH in the flash packages then. So...would having the rules file sed a "postinst.in" file with $DEB_BUILD_ARCH be the right way? [15:49] mdeslaur: oh bah. well, it should be DEB_HOST_ARCH [15:51] cjwatson, would you be able to upload that puppy [15:51] slangasek: why DEB_HOST_ARCH vs DEB_BUILD_ARCH? [15:51] (and thanks for reviewing) [15:51] mdeslaur: because of the definitions of host and build in the C standards :) [15:51] mdeslaur: DEB_BUILD_ARCH is the architecture you're building the source package on; DEB_HOST_ARCH is the architecture you're building for. They differ in the case of cross-compiling [15:51] mdeslaur: host is always the arch that the code is hosted on; while it's unlikely anyone will ever need to cross-build a flash package, we should still use the right variable [15:52] ev: hey [15:52] m4n1sh: hi [15:52] cjwatson, slangasek: ah! thanks for the explanation, that makes sense [15:52] ev: you got any update about contributor agreement? [15:55] apw: done [15:55] cjwatson, thanks a lot [15:55] m4n1sh: nothing yet. I'll keep you posted [15:55] ev: so if I integrate it in alm, then what about the code in whoopsie? [15:55] duplicated? [15:56] m4n1sh: can you elaborate? I don't follow. [15:56] means [15:56] I take those two files [15:56] and integrate it [15:56] then this functionality is in two pakages [15:56] *packages [15:56] are you going to disable that in whoopsie? [15:57] ev: is whoopsie going to be enabled by default? right? [15:59] m4n1sh: the idea is that we'll take the preferences page code from whoopsie, put it in a GtkNotebook page in activity-log-manager, and then remove the code from whoopsie. [15:59] hmmm [15:59] yeah, I am working on it [15:59] looks fine [15:59] it uses gtkbuilder [16:00] m4n1sh: I'm not sure if it falls under the contributor agreement or not yet, and given that today is feature freeze, I'll be doing an upload of whoopsie where the page it creates in GNOME Control Center is called "Diagnostics" rather than its current "Privacy" [16:00] okay [16:00] as per Colin this falls outside FF [16:00] indeed [16:00] so should be fine to move it from one to other [16:00] so it is in main? [16:01] it will be by the end of the day [16:02] okay [16:24] ev: hm, does 'test/run local' work for you in your whoopsie apport branch? [16:25] ev: I get a ton of errors in apport/ui [16:25] ev: 'NoneType' object has no attribute '__getitem__' [16:25] eep [16:25] I had been running test/{gtk,kde} manually [16:25] yay ... unity now rendering the archive uninstallable [16:25] Hi everyone, I'm looking for an archive admin to look at two new packages in the universe queue. [16:25] will fix now [16:26] ev: thanks; reviewing in the meantime [16:26] cheers [16:26] ev: I need to run out in about 10 mins, I'd rather finish this tomorrow morning than crowbaring it in today [16:26] skaet: ^ if that's alright with you [16:26] skaet: (these are the apport GUI and logic changes for whoopsie) [16:26] pitti: sure thing [16:26] ev: I'll test this locally in the meantime [16:27] cheers [16:27] pitti, ev =1 [16:31] I have a line that creates a .so with: 'gcc -shared -Wl,-soname=lib$$i-openmpi.so.1 -o lib$$i-openmpi.so.1.1 -L/usr/lib/openmpi/lib/ -lmpi -lmpi_f77 $$(find tmp -name "*.o")'. The generated .so does not declare dependencies on libmpi and libmpi_f77. I know order matters, so I tried moving the -l's to the front, and also tried -Wl,-E. What am I doing wrong? [16:32] pitti: weird. I only get two failures in ./test/run local. Both relate to add_gdb_info: readelf: Error: /tmp/core: Failed to read file's magic number. [16:32] ev: hmm, weird; I'll have a look at this tomorrow morning then [16:33] pitti: cheers [16:36] FWIW, I just did a bzr export /tmp/apport-whoopsie; ./setup.py build; ./tests/run local and it worked just fine (well, with the same two errors) [16:40] ev: I followed up to the MP with various bugs [16:40] pitti: okay, reviewing now [16:41] I'll look at the ui.py test crash tomorrow then [16:41] need to run now, sorry (theater tonight) [16:43] Calculating upgrade... Done [16:43] The following packages will be REMOVED: [16:43] unity [16:43]