=== salem_ is now known as _salem [00:13] micahg: thanks, yea its targetted for 12.04.1 but ill keep an eye on it and if you can't get to it by next week ill make sure to get it handled [00:16] stokachu: well, if you just make sure the current debdiff works on quantal so when I go to sponsor, I don't run into issues, that would be great [00:16] micahg: sure ill do that [00:16] stokachu: thanks [00:16] np thank you :) [00:21] micahg: Looks like firefox/thunderbird is another case of "using the buildd to determine the target arch". [00:21] micahg: Which means they're getting it wrong on armhf too (I see a NEON define in there, for instance) [00:22] infinity: awesome :), well, cross building probably isn't a priority for upstream, but they'd probably take patches [00:23] Building for a generic target isn't "cross-building". [00:23] If all their Windows builds emitted SSE3 instructions, they'd be just as miffed. :P [00:24] But people seem to make these mistakes on ARM a lot more than x86. [00:24] Anyhow, I might look at it later. The build log just showed me it was doin' it wrong. [00:24] infinity: heh, ok, well, I'm sure chrisccoulson would love a patch for that === jalcine is now known as Jacky === BenC__ is now known as BenC === BenC__ is now known as BenC === gerard0 is now known as gerardo === gerard0 is now known as gerardo [01:23] cjwatson: doh. sorry about that. uploading fix now === gerardo is now known as gerard0 === jbicha is now known as Guest34968 [02:18] micahg: i got that debdiff attached to 977940, let me know if there is anything else I can do to help === gerard0 is now known as gerardo === gerardo is now known as gerard0 [02:51] stokachu: oh, thanks, I just wanted to make sure it built :) [02:54] micahg: yea it builds === Guest34968 is now known as jbicha_ [03:16] cjwatson: you there? [03:18] * xnox at 4AM ?! [03:19] Ah, Time Zones :( [03:20] Timezone, timeschmones. [03:21] For the insane among us perhaps, but I like my sleep. [03:21] heh, sleep, was nice once upon a time [03:22] I guess one factor for me is that I am a morning person. [03:22] TheMuso: well, I'm up at 4AM ;-) [03:22] * xnox went to bed at 8PM and now woke up [03:22] As I said, for the insane among us. :) [03:22] * xnox is fiddling with cdbs [03:22] ah, are you in ~ 4AM as well ? =)))) [03:22] xnox: you're still asleep, stuck in a nightmare :) [03:22] No, its 13:22. [03:23] On a Thursday. [03:23] TheMuso: are in australia / japan or something? [03:24] Sydney Australia. [03:24] micahg: =(((( [03:24] Its 9 Am here [03:24] xnox: that's what fiddling with cdbs at 4AM sounds like to me :) [03:24] micahg: s/4AM/any time/ [03:25] ajmitch: lol [03:25] nigelb: hehe [03:28] micahg: you are so judgemental =) [03:32] xnox: Being judgemental doesn't make him wrong. [03:35] xnox: I would think 90% of maintainers agree :) http://upsilon.cc/~zack/stuff/dh-vs-cdbs/ [03:35] Good morning [03:35] morning pitti [03:36] hrm ,about 15% of main uses cdbs [03:37] micahg: cdbs supports flavors. Running VPATH builds with different configure flags for each build: e.g. full, minimal, udeb, etc... [03:37] micahg: simply specify a list of flavours & configure flags for each one ;-) [03:37] xnox: that doesn't mean that it's not a bear to use :) [03:37] * xnox =( [03:38] pitti: Good morning, I'm about to go back for my second half of sleep ;-) [03:38] hey xnox, how are you? [03:38] * micahg just read an article about that [03:38] pitti: good good, went to bed early woke up in the middle of night =) [03:41] * vibhav wonders how large coffee cups devs have [03:41] * micahg goes to get some tea [03:44] vibhav: 0.35ltr [03:44] http://shop.canonical.com/product_info.php?products_id=828 [03:44] I also have the previous cup, it's less capacity [03:45] was a nice upgrade =) [03:46] * vibhav drools [03:46] xnox: congratulations to your new core-dev badge! [03:47] pitti: thank you. [03:48] although i would still like code review before uploading core stuff [03:48] * xnox doesn't want to be the guy who broke quantal [03:48] xnox: Don't worry, that's me currently. [03:49] xnox: knowing when to ask for help is important, no one knows everything [03:49] infinity: By breaking, you mean dpkg, right? [03:50] vibhav: Indeed. [03:50] infinity: don't worry, it falls under the title of uploader of eglibc :) [03:51] micahg: I only break eglibc in Debian. [03:51] micahg: Well, so far. [03:51] hehe [03:51] vibhav: technically, whoever merged early multi arch support way back in precise (??) broke dpkg [03:51] Maybe I'll break it in Ubuntu with the next upstream. Stay tuned. [03:51] infinity: I meant breaking the archive, it's all encompassing :) [03:51] xnox: natty. [03:51] infinity: was it still you?! [03:51] xnox: We've been multiarching for a long time. [03:51] xnox: And no, it wasn't me. [03:51] * xnox BINGO! [03:52] xnox: nope, not at all, the dpkg implementation multiarch changed after we introduced it [03:52] And what he said. [03:52] I'm still trying to sort out what the guard is preventing. [03:52] So, if you have a non-ma-same package in an rc state, and you want to install an ma-same version from another arch, it flips out. [03:53] That seems fair. [03:53] infinity: I think the brain damage of having 3 packages installed: pkg pkg:i386 pkg:amd64 [03:53] * ajmitch should try & upload some packages tonight [03:53] But wouldn't that be exactly the same situation if you have an old ma-same version in rc, and want to install a new on from another arch? [03:53] There's still a chance of whacky conflict. [03:53] xnox: But if it's just a mapping issue, we can kludge it the same way we did for triggers. [03:53] xnox: noarch = native, done. [03:54] yeap, but the files in the non-multiarch location must be identical [03:54] across all architectures [03:54] xnox: Yes, but they're NOT identical in the ma-same-rc plus ma-same-install case either. [03:54] noarch = native, will not help with triple arch [03:54] xnox: Eh? it's not triple arch once you've mapped it. [03:55] infinity: if they are not, then it's an RC bug against the package. There were a few of those recently [03:55] xnox: pkg = pkg:native [03:55] xnox: No, no. You're missing the point. [03:55] infinity: as it pkg = pkg:native will not help if you have i386, amd64 and armhf multiarches enabled [03:55] xnox: You remove libfoo:i386, it poops conffiles. You later install a NEWER version of libfoo:amd64. That's no guarantee of identical anything anymore. [03:56] xnox: If you have ma-same stuff installed this doesn't trigger. It's only for the old skool pre-ma packages this is an issue, which is where you map noarch=native. [03:56] true [03:56] xnox: And, in that case, I fail to see how it's then any different from the scenario I paint above, with different versions. [03:57] * xnox needs to read multiarch spec again, what ma-same means [03:57] xnox: M-A:same means paclages can be co-installed. [03:57] xnox: So, most multiarch libraries. [03:58] infinity: I think the issue is without the package being marked m-a:same, there's no guarantee the conf files won't conflict [03:58] xnox: And this error specifically trips on M-A:same + pre-M-A-rc [03:58] micahg: There isn't anyway. [03:58] micahg: It's tripping on a REMOVED (but not purged) package. [03:58] infinity: yes, but I think that's what it's trying to guard against [03:58] micahg: You can't enforce the contents of mismatched packages. [03:59] and one of the requirement is that they (a) do not install anything in non-multiarch qualified locations (b) if the do install anything outside => they must be identical across all arches. So yeah, I see your point that rc should not matter, unless it's in like /usr/lib/$ANY_TRIPLET/libc6.so [03:59] micahg: Like i said, this is (afaict), no different than having a removed libfoo1:i386_1.2.3-1 and then installing a new libfoo1:amd64_1.2.3-2 [03:59] * xnox wants to create config file /usr/lib/$ANY_TRIPLET/libc6.so for giggles [04:00] infinity: right, but maybe it's trying to do some conf file handling in some futile fashion (my best guess ATM) [04:01] infinity: well multiarched libraries do not ship conf / conffiles [04:01] xnox: I'm trying to wrap my head around how noarch=native would break things here (or, be any worse than the situation I've outlined above), but I suspect it's the way forward for now. [04:01] infinity: so dpkg should regard the m-a: same package as implicitly replacing, and therefore taking over, any conffiles? [04:01] micahg: Even if it is, I don't see how the arch matters. [04:01] slangasek: Why not? That's what it does on newer-same -> older-same? [04:01] slangasek: If so, I don't see why new-same -> old-non-same should be different. [04:02] infinity: it might be worried about the old conf file being broke in the multiarch world [04:03] * xnox want's to look at the sample dpkg tarball from the bug to see what library shipped a conf file in the first place [04:03] slangasek: Whatever it's doing in the old->new (but both same) scenario, that seems the sane thing to do for non-same->same. [04:03] micahg: That's just weird speculation. It's a package's job to upgrade its broken conffiles, not dpkg's job to guess. [04:04] infinity: will that break upon people trying to use multiarch to do a cross-arch dist-upgrade / reinstall to migrate from i386 -> amd64 [04:05] xnox: For one, that's not even remotely supported. For two, how does it break it? [04:05] * xnox ponders [04:06] infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676496 ? [04:06] Debian bug 676496 in dpkg "dpkg: premature removal of "Multi-arch:" leads to all dpkg commands failing" [Grave,Fixed] [04:06] it won't because there is only on :native at a time. [04:06] it won't because there is only one :native at a time. [04:08] micahg: Hrm. That isn't the same bug/misfeature, is it? :P [04:08] infinity: not exactly, but looks like it might be close [04:09] No, definitely not the same bug. [04:11] I figured it might give some hint on where to look [04:13] Don't think it relates, really. [04:13] But I should merge that version... [04:23] infinity: if the new libfoo:native does not ship the config file anymore, and for example that file got moved into an foo:all package, that stale rc file will be removed? [04:24] libfoo:native is now ma-same, old libfoo is not. [04:24] xnox: To be honest, I'm not sure what happens, but I don't see why it should be any different than in the mismatched-versions-of-ma-same-packages case, do you? [04:25] There's no reason to assume that a migration a removed libfoo between and old non-ma version and a new ma-enabled version will be significantly more broken than between, say, two wildly skewed but both ma-same versions. [04:26] s/migration a/migration of a/ [04:26] infinity: have you seen that in the bug 1015616 the problem got resolved by adding :native to the culprit packages [04:26] Launchpad bug 1015567 in dpkg (Ubuntu Quantal) "duplicate for #1015616 upgrade failed: mixed non-coinstallable and coinstallable package instances present" [High,Triaged] https://launchpad.net/bugs/1015567 [04:27] xnox: Actually, he added M-A:same headers, but the end result internally in the pkgset logic would be the same. [04:28] xnox: Anyhow, I've thought too much about this for today, but if you come up with any snazzy ideas that you want to talk over, I'll be awake sometime tomorrow. ;) [04:29] infinity: the kicker is that the conffile was not modified, it's untouched in both packages of the bugreporter [04:30] infinity: i'd just pre-purge those packages [04:30] xnox: I don't see why modified or not should matter, really. [04:30] no data loss ;-) [04:31] There's no data loss if you do a conffile takeover either. [04:31] if it fails with an rc package, would it also fail with an installed one? [04:31] Which is exactly what happens if you go "old i386 package removed" -> "new amd64 package installed" of different versions, with a modified and shared conffile. [04:31] xnox: With an installed one, it will force the upgrade. [04:31] xnox: Cause the versions have to match. [04:32] right. [04:32] * xnox has no concerns about going for rc -> :native [04:32] It seems like the sane way to go. [04:32] Might make your eyes bleed a bit sorting out where to do that. [04:33] infinity: are you doing the new merge first though? [04:33] Tracing back from the error message, and stepping back through every function until you get to the one that seems reasonable to fix. :P [04:33] or not. [04:33] xnox: I won't be merging tonight. Shouldn't impact your fix anyway. [04:34] ok [04:34] * xnox off to sleep for shorter second half, before starting my day [04:34] xnox: Or, you can just merge if you like. MoM actually got it right, except for a conflict in control. [04:34] hmmm. ok [04:34] xnox: (I assume due to the fiddling with xz-utils and lockfile deps) [04:35] Actually, since MoM got it right and I just need to eyeball it, I'll just upload this now. [04:35] still needed after precise, or is it to be backports safe? [04:35] And you can do your stuff when you wake up. [04:35] great. deal. [04:35] We don't aim to backport dpkg. [05:13] infinity: MoM has a useful ../merge-buildpackage script :) [05:14] micahg: Hrm? [05:14] it calls its useful merge-genchanges script to auto add the -v from the previous Ubuntu verison :) [05:14] *version [05:15] micahg: Oh, I missed the -v after I went and added more changes. Silly me. [05:15] micahg: Oh well. [05:18] jbicha_: Thanks for updating UML! [05:24] But there *are* to AAs who have been active in #ubuntu-release in the last 10 minutes or so ☺ [05:24] Imagine that went into #ubuntu-desktop, where it was intended. [05:27] RAOF: Hahaha. [05:27] RAOF: What needs AAing? [05:28] infinity, new package bug 1011361 [05:28] Launchpad bug 1011361 in Ubuntu "[needs-packaging] libpwquality" [Wishlist,Triaged] https://launchpad.net/bugs/1011361 [05:30] robert_ancell: Ahh, doing a NEW source review probably isn't on my list of things to do at 23:30, I'll punt. [05:30] infinity, fair enough [05:30] robert_ancell: But if no one's looked at it before tomorrow, you can give me a gentle nudge. [06:14] dobey: thanks [06:40] pitti, the crash I get while reporting a bug seems to be https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1015788 [06:40] Launchpad bug 1015788 in apport (Ubuntu) "All the apport crash reports are now "*** Error: Invalid problem report" - TypeError: startswith first arg must be bytes or a tuple of bytes, not str" [Undecided,Confirmed] [06:41] jibel: ah, that's not the one in DKMS again [06:41] jibel: I just fixed bug 1007826, currently fixing dkms, will then look at that one [06:41] Launchpad bug 1007826 in apport (Ubuntu) "crash with AssertionError: file stream must be in binary mode when trying to save report to file" [High,Fix committed] https://launchpad.net/bugs/1007826 [06:42] jibel: could you please add what command you were trying to run? [06:42] pitti, right, it's different. dkms crashes which triggers apport which in turn crashed with the "invalid problem report" dialog [07:01] good morning [07:08] Why is http://paste.ubuntu.com/1052137/ requiring me to log into launchpad to download the patch as text? [07:08] so that you cannot abuse it to anonymously store tons of data there (a la filesharing) [07:10] pitti: couldn't that have been done like any other pastebind does, or requiring the login only for contents >100Kb? I've been pushed that patch to be applied in Debian, not Ubuntu, and I find it ridiculous that I need to have a launchpad account in order to have a version that I can feed to patch [07:10] >100 kB sounds sensible indeed [07:11] enrico: need the patch? I can put it someplace else for you [07:12] pitti: thanks, copypaste seems to have done TRT [07:18] enrico: #canonical-sysadmin would be the place to complain about it - #ubuntu-devel doesn't admin the pastebin [07:21] cjwatson: any reasonable place I could file a bug instead? [07:21] I don't know, sorry [07:22] If there were, it would require a Launchpad account ;-) [07:22] dupondje, For the Xen package I am waiting for the review of my merge. The current version in Quantal is only there because of the initial pocket copy done. It would not compile in Q. [07:22] cjwatson: I should still have a launchpad account I can use to report bugs; my problem is being forced to use it when doing things that are not ubuntu-specifc [07:23] sure [07:34] enrico: cjwatson: I once filed an RT about that and it was denied [07:36] Laney, for what reason? I'm curious, because I've got complaints from my upstream friends about it too. [07:36] anyone know why Quickly is install two versions of glade and potentially two versions of the depends for each version of glade? [07:36] on Quantal [07:37] diwic: enrico: https://rt.ubuntu.com/Ticket/Display.html?id=18758 [07:37] (yes, you probably need to log in to see that …) [07:37] guest/guest IIRC [07:38] or maybe ubuntu/ubuntu [07:38] the latter [07:38] ... oh. it used to be. I guess it's all SSO now? [07:38] cjwatson: none of those. Now trying to work out how SSO works [07:38] using the same credentials as LP [07:40] Laney: found it, and sigh. [07:40] I just default to paste.d.n now [07:41] I'm sure most people supplying pastes would be happy to do so in a more convenient way if requested [07:41] Laney: I did indeed resolve to ask the person not to use paste.ubuntu when sending stuff to non-ubuntu developers [07:41] Laney, thanks [07:44] Laney, although I'm a little surprised that the spammers can't use the non-login version as well (just strip away some html code) [07:45] barry: do you know why might be installing two versions of glade? [07:45] quickly* [07:55] smb: ok great :) [07:56] cjwatson: yay, thanks for change-override [07:59] good morning =) [08:00] pitti: You're welcome :-) [08:00] pitti: Do you know if it's been necessary to run firefox-overrides in recent times? I have a feeling that the override ancestry bug that prompted that has been fixed [08:01] cjwatson: I have never used that oen [08:01] one [08:01] chrisccoulson, micahg: ^ do you know about this? [08:01] https://wiki.ubuntu.com/ArchiveAdministration#Publishing_packages_from_the_ubuntu-mozilla-security_public_PPA FWIW [08:02] That script needs to be moved to client-side, but if it's no longer needed then I would be just as happy to remove it [08:02] pitti: I didn't know there was such a thing :) [08:02] OK, I'm going to take a punt and say that this has been fixed - the LP copying code looks up the new ancestry of binary packages it copies and tries to apply matching overrides [08:03] at least in precise and quantal, all binaries are in main anyway [08:03] hello [08:03] This doesn't work for the kernel because package names tend to change, but it should be fine for firefox [08:03] cjwatson: lately, the only thing that needs overrides are new binaries [08:03] in oneiric, -mozsymbols is in universe [08:03] and so it is in oneiric-updates [08:03] so whavever is done for those, it works without that script apparently [08:03] cjwatson: *nod* [08:04] * cjwatson looks up the publishing history for that to check [08:04] cjwatson: even for the kernel, all packages that don't change keep their component [08:06] well, there was some work done to make copies to the archive end up in the proper component [08:07] or rather make copies respect existing components [08:07] I think that's what I'm referring to above [08:07] Assuming you mean work in LP as opposed to per-upload work [08:08] I'll bb [08:08] yes [08:10] lib/lp/soyuz/adapters/overrides.py:UbuntuOverridePolicy is applied to binary copies, and looks like it should be right [08:16] And I've confirmed that none of the BPPHs for firefox-mozsymbols in oneiric since at least mid-March have been anywhere except universe [08:27] hi [08:28] cjwatson: that's good news re: binaries ending up where they belong [08:42] I am looking for a simple way to update with packages coming from another machine (a place where the connection is much faster). I failed when trying to just copy the apt directory from /var/cache : is there a simple way to do that ? [08:43] /usr/share/doc/apt-doc/offline.html/index.html talks about this [08:44] Don't know how current it is but my guess is it should require at most minor adjustments [08:44] hi cjwatson, I look, thanks [08:47] cjwatson: there is no "apt-doc" directory in /usr/share/doc in precise [08:49] I am going to try to cheat and put the packages in the "partial" directory [08:50] melodie_: That's because you don't have the apt-doc package installed. [08:50] It looks like it wants to work. [08:57] cjwatson: you are probably right. well, putting the packages from /var/cache/apt/archives to /var/cache/apt/archives/partial, then "apt-get update && apt-get dist-ugrade" seems to work. I'll know in a moment when the unpacking and replacing will be finished. [09:12] bbl [09:17] rbelem: And progress on the new snapshot for plasma-mobile? [09:37] cjwatson: fyi, I wrote that bit in AA for firefox some time ago. while firefox hasn't needed it for quite sometime, it seems I have had to use it on rare occasion for non-kernel stuff [09:37] cjwatson: however, I think it is fine to remove it-- it is really just my team and the SRU team that use it [09:38] my team knows about it and the SRU team has a documented process for the kernel still anyway [09:43] jdstrand: Well, you have find-bin-overrides still; firefox-overrides was hardcoded to firefox so was clearly of no use [09:43] jdstrand: When you next see this for something that isn't the kernel, I'd like to hear about it [09:43] jdstrand: There's still a section below explaining the use of find-bin-overrides [09:45] cjwatson: oh, I missed we were talking about firefox-overrides and not find-bin-overrides. yes, I haven't used firefox-overrides in ages [09:45] and yeah, the section below on find-bin-overrides was what I was referring to with "the SRU team has a documented process for the kernel" [09:46] I'd still like to know about non-kernel cases. My reading of the code is that manual overrides should never be necessary when copying from PPAs, *unless* the binary packages in question are new to that distroarchseries [09:46] noted [09:47] We do sometimes get new packages in SRUs and security updates that aren't kernels. [09:47] I don't have specifics atm. I want to say openjdk-6, but it has been too long [09:47] mozilla.org sources introduce new translationy bits, if I recall. [09:47] infinity: re secureity updates> on occasion [09:48] bind9 might be another [09:48] Yeah, it does happen now and again. My feeling is that fixing bug 192076 will sort out most of it, and for the rest, manual overrides would be OK. [09:48] Launchpad bug 192076 in Launchpad itself "component of new binary packages should default to source component" [Critical,Triaged] https://launchpad.net/bugs/192076 [09:48] Yeah, I'm happy with doing it manually when it comes up anyway. [09:48] And fixing that ancient bug would just make that process simpler. [09:48] I have a test case for half of it now. [09:49] There are two pieces: firstly, the override policy doesn't implement this suggestion; secondly, normal uploads (as opposed to copies) don't use the override policy as extensively as they should [10:02] pitti, http://paste.ubuntu.com/1052388/ does that look sane to you ? [10:04] ogra_: if you really want to match the names that precisely, sure [10:04] ogra_: I don't have "Hardware" in my /proc/cpuinfo (amd64), all keys are lower-case; is that really right? [10:05] pitti, well, once we get omap3 drivers there will be many boards our kernels work on but the pvr driver likely wont [10:05] yeah, HArdware isnt in x86 but on all arm SoCs [10:05] ogra_: stick the file into /usr/share/ubuntu-drivers-common/detect/ and run "ubuntu-drivers debug", to ensure that it's working [10:05] unfortunately, /proc/cpuinfo is completely different across archs [10:06] ah., great, thats what i was missing, i just added a main() function and ran it with prints for testing [10:06] tumbleweed, yeah, but luckily reliable at least on arm :) [10:09] pitti, http://paste.ubuntu.com/1052397/ looks fine [10:09] ogra_: yep [10:09] seems panda even has a modalias (most other arm paltforms wont though) [10:14] * Daviey tries to use apport to report an apport bug [10:15] sadly, it fails.. and i'm expecting apport to try to report a bug, about the bug that i encountered a bug when trying to report a bug.. GOTO 10 === jml is now known as jml_ === jml_ is now known as jml [10:17] Daviey: please update to apport 2.2.4, I fixed two major bugs this morning [10:17] pitti: i'm running 2.2.4-0ubuntu1 [10:17] ok, then I need more information, I'm afraid [10:18] pitti: I'll raise a bug, but looks like a py3 issue... "" [10:18] startswith first arg must be bytes or a tuple of bytes, not str [10:19] bug 1015788 [10:19] Launchpad bug 1015788 in apport (Ubuntu Quantal) "All the apport crash reports are now "*** Error: Invalid problem report" - TypeError: startswith first arg must be bytes or a tuple of bytes, not str" [High,Fix released] https://launchpad.net/bugs/1015788 [10:20] Daviey: hm, that's what I fixed this morning, or at leat I thought I did [10:20] Daviey: can you please attach your .crash file there? It might stumble over a different code path; I tested with jibel's and that works for me now === paulliu is now known as paulliu-dinner === zyga-afk is now known as zyga [10:24] running apt-get dist-upgrade, is there a way to specify "don't ask me any (debconf) questions?" [10:24] this is for an automated process to spin up a new 12.04 server === yofel_ is now known as yofel [10:25] jml: With the -y option it should assume yes to questions. [10:25] astraljava: That doesn't affect debconf. [10:25] jml: DEBIAN_FRONTEND=noninteractive [10:25] My apologies, I mixed things up. [10:26] But you do want -y as well for unattended apt-gettery. [10:26] infinity: thanks. I'll try that out. [10:27] nope. [10:27] jml: There's also --force-yes, but I'd contend that if your archive or system are in a state where that would be required, you're usually better off with the error. :P [10:28] I still get prompted by console-setup [10:28] I guess there I need to use debconf-set-selections or something? [10:28] Er [10:28] It shouldn't be able to prompt if you've *correctly* set DEBIAN_FRONTEND=noninteractive [10:28] Exactly what command line did you use? [10:29] export DEBIAN_FRONTEND=noninteractive; sudo apt-get update -q; sudo apt-get dist-upgrade -q -y --force-yes [10:29] sudo filters the environment. [10:29] ah right. [10:29] sudo apt-get update -q; sudo DEBIAN_FRONTEND=noninteractive apt-get dist-upgrade -q -y --force-yes [10:29] * jml man sudo [10:30] (Though personally I wouldn't use --force-yes, for the reasons explained in apt-get(8).) [10:30] jml: And yeah, I'd skip --force-yes [10:30] jml: The error is almost always better than having it solve it for you. [10:30] so, just -y [10:30] Yeah [10:30] * infinity nods. [10:30] ok. [10:30] sudoers(8) → "env_reset" [10:31] that bit is cargo-culting. I'll check out the man page so I can learn this proper. [10:31] Holy crap, → is a compose set? [10:31] yeah [10:31] This changes everything. [10:31] -> [10:32] → ← [10:32] infinity: it's magical _and_ revolutionary. [10:32] Right. That shouldn't excite me. For the fifth attempt tonight, nap time. [10:33] pitti: attached [10:34] Daviey: btw, I fixed that dkms bug this morning, too [10:34] i. e. the one that generated _usr_share_apport_package-hooks_dkms_packages.py.0.crash in the first place [10:35] pitti: wine is for fglrx rather than virtualbox.. i marked the bug back to Confirmed.. I didn't think you'd want a seperate bug [10:36] s/wine/mine [10:36] yes, the bug was in dkms' apport hook; not driver specific at all [10:37] Daviey: can you please check the version in dpkg -l python-apport ? [10:37] your .crash works for me (and in fact, it's the exact same as jibel's) [10:38] pitti: ii python-apport 2.2.4-0ubuntu1 [10:38] ok, then I'm officially clueless why it still happens for you :/ [10:39] pitti: I upgraded, rebooted to get the fresh kernel.. and the timestamp on the .crash file is that of first boot. [10:39] Daviey: are you using apport-cli, and the "view report" option? [10:39] pitti: i've not touched apport-cli, this was the gui error raised on first boot [10:40] ok, tested apport-gtk as well; but shouldn't make a difference, it's all the same backend code [10:42] pitti: Okay, should i rm the .crash file and reboot, see if i get the same result? [10:42] followed up to the bug [10:42] Daviey: the .crash file is not the issue here [10:42] it's apport crashing if you try to report the DKMS bug [10:43] pitti: well, i can confirm that apport-cli does work. [10:43] Daviey: if you run apport-bug /var/crash/_usr_share_apport_package-hooks_dkms_packages.py.0.crash, what happens? [10:45] pitti: huh, problem cannot be reported... The problem happened with the program /usr/share/apport/package-hooks/dkms_packages.py which changed since the crash occurred. [10:45] ah, right [10:45] that wouldl be the fixed dkms :) [10:45] but I haven't upgraded since... [10:45] dpkg -l dkms ? [10:45] 2.2.0.3-1ubuntu4 [10:45] Daviey: that's the new one from this morning [10:45] https://launchpad.net/ubuntu/+source/dkms/2.2.0.3-1ubuntu4 [10:46] which fixed that very bug (bug 1008092) [10:46] Launchpad bug 1008092 in dkms (Ubuntu) "dkms_packages.py crashed with AssertionError in _assert_bin_mode(): file stream must be in binary mode" [High,Fix released] https://launchpad.net/bugs/1008092 [10:46] pitti: Yes, but i am saying that i upgraded, rebooted, then hit this issue.. So how did it change without touching apt? [10:47] Anyway, if this is gone for others.. and an oddity, i'm happy to ignore it.. just very peculiar. [10:47] so it seems the apport crash is confirmed fixed for you as well [10:48] Daviey: perhaps you opted to not report the dkms crash in the session where you did the upgrade? [10:48] pitti: that sounds likely, and makes sense. [10:48] thanks. [10:48] anyway, I'm fairly confident that both bugs are fixed now [10:49] Daviey: and on top of that, I wrote an ubuntu-drivers-common autopkgtest which will exercise the binary drivers, to ensure that they build, install, and work :) [10:49] I didn't add the virtualbox ones, though, but that's easy [10:49] Daviey: virtualbox-dkms, right? [10:51] jibel: speaking about this, do you have an idea how the u-d-common adt test can be triggered for each new kernel upload? I could add a linux-y dependency to it, but which depends do you parse exactly? debian/control b-deps, binary deps, or debian/tests/control ? [10:51] pitti: no, my failure was fglrx. [10:52] * pitti -> lunch, bbl & [10:58] barry, is the goal for Quantal to have python3-only on only the Ubuntu Desktop CD or also the Ubuntu Server CD? [11:00] Ah, desktop I see in the blueprint [11:00] pitti, I added another case to reproduce 1015788 with apport 2.2.4-0ubuntu1 this time with accerciser. [11:08] mterry: confirmed it's not a target for server this cycle. [11:35] pitti, binary deps [11:36] dupondje: Do you think you could take the courier merge from me, please? You did the last substantive merge - all I did was rebuild it for a Perl transition [11:40] pitti, hmpf, so to contribute to ubuntu-drivers-common i need a github account ? why is that not on LP as a bzr branch ? [11:41] tseliot, ^^^ [11:42] ogra_: a matter of taste [11:42] no, a matter of workflow imho ... i cant just file a merge request now [11:42] pitti, more precisely binary depends of all the binaries built from a source package. for u-d-common that'd be binary deps of u-d-common, dh-modaliases and nvidia-common [11:43] nor will UDD work with it in any way [11:48] ogra_: I can just put in the file for you [11:50] jibel: hm, so we could only add a dependency like linux-generic to u-d-common [11:52] pitti, tseliot bug 1016006 [11:52] Launchpad bug 1016006 in ubuntu-drivers-common (Ubuntu) "please incluse arm-gles.py since impossible to commit new code to the ubuntu project as ubuntu-core-dev" [Undecided,New] https://launchpad.net/bugs/1016006 [11:52] ogra_: thanks, will do [11:52] * ogra_ finds that massively annoying btw [11:54] it is indeed [11:55] but well, if someone will just upload or use UDD, it's always possible to import that into the git, too [11:55] sure [11:56] what bothers me is that it is a tool we ship on the CD and provide as a core component, there should at least be a bzr import from the github branch that we can work with on LP [11:57]