=== dendro-afk is now known as dendrobates [00:16] zyga: ping === EvilJackyAlcine is now known as JackyAlcine === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [02:04] \o/ it's done: https://launchpad.net/builders: armhf 11 empty [02:04] woot === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [05:20] Do we prefer P-A-S to hacking debian/control to allow/disallow archs? [05:34] micahg: They're for different jobs, aren't they? p-a-s is for... um... :) [05:36] exactly :), well, it makes it easier if there's a downstream distro with support for other archs [05:49] RAOF: just found this: https://lists.ubuntu.com/archives/ubuntu-devel/2008-December/027076.html [05:49] micahg: P-a-s is for arch decisions that shouldn't be made by the source. [05:50] micahg: For instance. If you have a package that's obviously x86-specific (like, it's all i386 ASM), then "Architecture: amd64 i386" in the .dsc is appropriate. [05:50] infinity: so, if it can be made by the source, the source is the correct place? i.e. I know chromium won't build on powerpc, so marking it !powerpc is appropriate [05:51] micahg: But wvdial (to pick a completely different example) works everywhere but arm*, and the reason it breaks on arm is a failing in arm kernel interfaces, which may some day be fixed. linux-any is the right answer in the package, and !armel !armhf in P-a-s. [05:51] micahg: chromium not building on PPC sounds more like "too lazy to port". :P [05:51] infinity: indeed :) [05:51] micahg: Neither P-a-s nor Arch lines are meant to be used for that. [05:52] I'd honestly rather see the failure as a reminder. [05:52] ok [05:52] It's not something that can't be ported, just something no one's bothered to port. [05:55] wow, Debian's not even trying chromium on ![i386,amd64,armel] [05:56] Indeed. [05:57] That may be an indication of some knowlede of upstream's intent there. [05:57] Meh. [05:57] I should talk to jbailey. [05:57] I know he does chrome(ium) build mangling internally. [05:58] well, their targets are x86 desktops and android, so it makes sense [05:59] it would be nice just to have armel work consistently :) [05:59] And have it work for armhf too. [05:59] (hint, hint) [05:59] yeah, that'll probably happen during my vacation :), I don't see much time before then to play with cross-compiling chromium on arm [06:00] infinity: jbailey is probably trying to port chromium to hppa. [06:00] StevenK: That seems unlikely. :P [06:00] 17 months until no more hppa in Ubuntu :) [06:01] * infinity sheds a tear. [06:01] oh, and no more lpia as well [06:01] No tears for hppa [06:01] I will not miss lpia [06:01] lpia, I don't care about. [06:02] I do actually still use my J6750, though. [06:02] I guess it's time to move it to a Debian base. [06:03] Or turn it into a stylish coffee table. [06:07] Good morning [06:12] slangasek: they aren't upstream apparently, so if we need them, we need to do it ourselves === mbiebl_ is now known as mbiebl [06:25] Riddell, ScottK: so I hear koffice is being replaced with something newer -- koffice-l10n has zero rdepends left, ok to remove/blacklist that package? [06:25] Can someone answer a multi-arch question? https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages says that " This means that for an Architecture: all package to satisfy the dependencies of a foreign-architecture package, it must be marked Multi-Arch: foreign or Multi-Arch: allowed. " -- Does this mean the dependency needs to be Multi-Arch: allowed, or the depending package? [06:25] YokoZar: the arch: all package itself needs to be M-A: foreign [06:25] pitti: or M-A allowed [06:26] i thought dpkg didn't actually support m-a allowed yet [06:26] presumably (I've never seen "allowed" in practice so far) [06:26] pitti: annoyingly, then, our fonts package don't appear to be M-A: allowed... [06:26] just not sure why they need to be explicitly declared so [06:26] I've got an i386 app that depends on a font and it's not letting me install it on amd64 with dpkg because it wants to insist on i386 version of font package :/ [06:27] I'd expect an Arch: all package to be "M-A: foreign" pretty much by design [06:27] slangasek: ^ I guess there are corner cases where this wouldn't work? [06:28] pitti: That was my thought, I naively assumed we'd treat all arch:all packages as M-A: foreign, but then I ran into my font issue [06:28] wait..."i386 version of font package" [06:28] ...are you *sure* it's arch: all? [06:28] ttf-mscorefonts-installer [06:28] yes [06:28] because "i386 version" of an arch: all package sounds meaningless to me [06:29] ah, wait. /me re-reads the spec [06:29] anyway, it sounds like you want multi-arch: foreign [06:30] http://paste.ubuntu.com/770848/ [06:30] broder: my question was do I want that on the font itself then, or can I just put it on my package? [06:30] on the font [06:30] I'm sure there was a reason for non-MA arch:all packages being treated that way, but damned if I can remember what the reason was... [06:31] infinity: see the link that YokoZar posted at the beginning of this :) [06:31] "architecture-dependent packages may depend on Architecture: all packages and assume that the transitive dependencies will be resolved using packages of the same architecture or other packages that are Architecture: all" [06:31] * YokoZar isn't liking the idea of pushing an SRU to ttf-mscorefonts-installer that doesn't do anything other than let my package install.... [06:32] Someone should clean up that specific paragraph I linked to though, it is an ambiguous "it", hence my question [06:37] * infinity goes to bed and hopes he doesn't wake up to a bunch of eglibc build failures and/or critical bugs. [06:37] infinity: you are brave :) [06:37] * YokoZar changed "it" to "the dependency" on the multi-arch page [06:37] micahg: If it breaks, I'm sure pitti will fix it for me. He's magical when I'm asleep. [06:37] That sounded dirty. [06:37] Hrm. [06:38] * micahg guesses he's almost as crazy with a bzip2 sync a few hours before bed [06:38] micahg: I dunno. Did your sync involve a 4MB diff in debian/* ? [06:38] infinity: heh, no :) [06:38] I strangely feel better now [06:45] Ok, next multi-arch question: can I work around my issue by depending on ttf-mscorefonts-installer:any ? [06:46] answer: no [06:46] I don't think ':any' works [06:47] Yeah, just tested that experimentally [06:47] Well this sucks [06:47] YokoZar: :any is a m-a: allowed thing, and you're using m-a: foreign [06:47] also i still don't think m-a: allowed works [06:47] broder: I'm trying to not modify the font at all at the moment, and just my package depending on it (an i386-only binary package that otherwise installs and runs fine on amd64 on oneiric) [06:47] i don't believe that's possible [06:48] Right, which is why I have declared this sucks [06:48] Fixable with an SRU to ttf-mscorefonts-installer though (ugh) [06:48] packages can't force other packages to be m-a [06:48] armhf 11 empty [06:48] err, wow! [06:48] doko, infinity: ^ congrats :) [06:49] broder: actually maybe ttf-mscorefonts-installer isn't fixable this way, since it's an odd font that depends on binaries that aren't M-A like wget [06:49] infinity: is it possible to steal some armhf builders for armel? we accepted a bunch of SRUs, and there's eglibc, webkit, etc. [06:50] YokoZar: wget should be m-a: foreign [06:50] infinity: I know how to switch them in the web ui, I just don't know which builders will actually work [06:50] pitti: Yeah, some don't. ;) [06:50] pitti: I'll toss a few over. [06:50] cf. the recent genip debacle [06:50] infinity: cheers [06:51] broder: in Oneiric? [06:51] YokoZar: i don't know about oneiric. i'm just saying conceptually it should be [06:51] infinity: so it seems LibO is indeed still the only offender for http://people.canonical.com/~ubuntu-archive/testing-ports/precise_probs.html [06:51] broder: it's non-MA in oneiric (/usr/bin/wget), and I'm pretty sure it should be M-A: allowed since you can install it on its native arch :) [06:52] pitti: Hopefully, that gets fixed soonish. [06:52] * pitti tries to pronounce liboktetakastencontrollers4 without getting a knot in his tongue [06:52] YokoZar: no, you're thinking about it wrong. it should be m-a: foreign because anything that *depends on it* has to be shelling out [06:52] so it doesn't matter if they're the same arch [06:55] Oh, right, foreign means not coinstallable, but still installable on build arch [06:55] pitti: There. You have buildds. [06:55] for a moment I thought M-A foreign meant that it could _only_ be foreign [06:56] (eg ia32-libs-multiarch is M-A:foreign as it only made sense to install it on amd64, but I suppose it is installable on i386) [07:03] YokoZar: arch all only being built on i386 is a bug ATM [07:04] Debian has no such restriction [07:04] micahg: I suppose that's related yeah [07:04] micahg: huh? i don't see how that's relevant here [07:05] micahg: but my specific problem isn't where it's actually built, it's that dpkg thinks it can't install my i386 package because it depends on an arch:all package that I already have [07:05] broder: I thought I saw something that implied it's i386 [07:06] micahg: broder: well it means that if we relax the assumption that's causing me issues we're unlikely to have new bugs since every arch:all package was the same anyway (ie, the built on i386 one) [07:06] YokoZar: no, it's not confused because the package was built on i386 [07:06] it's confused because it's treating the arch: all package as only satisfying amd64 dependencies, so it tries to get and i386 version which is just nonsense [07:06] broder: I know, it's confused because it thinks it needs font:i386 but I have font:all and they're not m-a [07:07] right. but where the package was built has nothing to do with that [07:07] broder: rereading, I don't see why I thought that was relevant anymore :) [07:07] broder: well if arch:all packages were built on different arches then hypothetically they might differ somehow and this restriction requiring explicit M-A allows might not be so nonsensical [07:08] but they'd still only be built once [07:08] and differences wouldn't actually matter, because all arches would still get the same specific build [07:08] fair enough [07:09] methinks a tech board proposal might be prudent here [07:10] since the alternative is 1) leaving it broken to things like this and 2) manually M-Aing all the arch:all packages, which would be the same effect anyway [07:10] YokoZar: you need to get consensus in Debian first or this will cause a lot more pain [07:11] YokoZar: you want to drop the requirement that arch: all packages be explicitly marked m-a: foreign? [07:11] the wiki outlines a fairly compelling reason why that needs to be the case [07:12] broder: Well, I want to relax it in the case that the transitive dependencies are all either MA allowed or themselves all. If a binary depends on an MA: all package that in turn depends on a non MA package then we can leave it as it is. This would get the fonts, for instance, which have no dependencies at all. [07:13] *except ttf-mscorefonts-installer, of course which properly should require multiarching of its dependencies [07:14] my instinct is that the number of arch: all packages that depend only on arch: all packages all the way down is going to be small enough to not be worth re-policy-ing over [07:14] broder: this would also prevent the ridiculous need of M-Aing arch:all packages (instead we would just MA their dependencies if they have them) [07:14] (and more importantly, reimplementing) [07:14] oh, m-a; foreign too [07:15] (seriously, stop talking about m-a allowed because it's confusing and, more importantly, not real) [07:15] broder: what about arch: all packages that depend on M-A'ed packages though? [07:15] As we continue MAing things that's going to be more and more the case [07:16] pitti: can I target some stuff as -security and some stuff as -proposed for the Firefox migration for Lucid/Maverick? Just trying to be intellectually honest about what might actually migrate to -security FWIW [07:19] YokoZar: fwiw, i appear to be spreading misinformation. m-a allowed is implemented [07:19] Fair enough :) [07:20] anyway, if you wanted to propose something like this, the TB is the wrong place to do it. you'd want to talk to the multiarch implementors, who are for the large part in #multiarch on OFTC [07:21] without thinking exceptionally hard about it, i would guess their response will be that the implementation is nasty [07:21] or alternatively http://alioth.debian.org/mail/?group_id=30462 [07:24] broder: alternatively, I can talk to slangasek and hope he takes up the issue :P [07:25] well, you know, that's basically equivalent to what i proposed [07:25] True [07:25] :) [07:42] pitti: corner case where Arch: all M-A: foreign doesn't work: python [07:42] (basically the canonical corner case) [07:59] infinity: cheers! [08:00] micahg: what would be the -proposed part? [08:00] good morning [08:00] pitti: firefox and maybe mozvoikko I think [08:01] micahg: ah, so the new langpacks are enough in -updates for now as well then [08:01] micahg: but as soon as we'll do the first firefox -security we need to remember to copy the langpacks, too [08:01] pitti: right, so maybe the langpacks should target -security or is that not necessary? [08:02] micahg: no, we can just copy them once needed [08:02] they usually target -proposed, and should [08:02] ok, but my selective targetting is ok then? [08:03] micahg: sure [08:03] pitti: thanks [08:10] micahg: Oh, are you doing firefox uploads tonight? [08:10] infinity: I wanted to :-/ [08:10] it'll be later today though [08:10] infinity: you've got at least 8 hours i think [08:10] micahg: Oh, I was just wondering if I should give some buildds back to armel again. But there seem to be enough idle ones. Carry on. [08:19] micahg: hm, if firefox goes to -updates, will it still be in https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages ? I don't see it there [08:20] pitti: I haven't uploaded it yet [08:20] was waiting for beta 6, if it's not uploaded by morning, I'll just grab beta 5, I should only need ~17 hrs I think [08:20] micahg: ah, ok; so I'll only prepare the tarballs right now, to have everything ready which doesn't depend on firefox [08:21] micahg: but that's the correct PPA? [08:22] pitti: yes, but I thought you weren't using the PPA [08:22] micahg: just for pointing langpack-o-matic against it, to see which languages have a firefox-l10n-* package [08:22] I can use the PPA or -proposed, whichever hits first [08:23] pitti: ok, that should for sure be ready by tomorrow when you come online (at least the i386 one) [08:23] cool === smb` is now known as smb [08:37] janimo: good morning [08:37] janimo: I suppose you saw the linux-ac100 FTBFS on armel? [08:38] (armhf worked fine) === bladernr_afk is now known as bladernr_ === jibel_ is now known as jibel [09:48] cjwatson: https://launchpad.net/ubuntu/+source/gnutls26/2.12.14-4 NBSed gnutls-bin [09:48] cjwatson: it moved to gnutls28; do you have an opinion whether or not we should pull that into precise and to the transition? [09:49] if not, we can just revert the previous upload (I'm happy to do that) [09:49] jamespage: ^ FYI (it's on NBS) [09:49] $ apt-cache rdepends libgnutls26|wc -l [09:49] 148 [09:49] it's not exactly small [09:49] pitti: yes - spotted that late yesterday - was going to ask the same question [09:50] gnutls28 is in testing now I think [09:50] the recent haskell transition is done buildd-wise now, so if we want to do it, we should do it over the weekend [09:51] we still have gnutls26, so it wouldn't immediately result in lots of NBS [09:51] but we certainly don't want to ship precise with two versions [09:52] hm, libgnutls-dev is still for 26 [09:52] so we'd actually need to change the source === _salem is now known as salem_ [10:42] jibel, jamespage: are the precise-upgrade jobs running ATM, or can we poke them? [10:44] pitti, they didn't start for some reason. I just started them manually. [10:44] jibel: presumably because the lab was still offline at their regular start time? [10:44] jibel: merci [10:44] jibel: let's see how far they get this time :) [10:45] pitti, no, the lab was ok but I think jenkins didn't like the network incident at all. [10:46] right, that's what I meant [10:53] hey guys, is there a common envvar where i can find tmp dir location? [10:56] mhr3, check is $TMDIR is set and if not fallback to /tmp as the default location? [10:56] check i*f* [10:57] mhr3, or g_get_tmp_dir() if you use glib [10:57] "Gets the directory to use for temporary files. This is found from inspecting the environment variables TMPDIR, TMP, and TEMP in that order. If none of those are defined "/tmp" is returned on UNIX and "C:\" on Windows" [10:58] mhr3, that's what the glib function does [10:58] pitti, main-all upgrade failed but it was expected. iodbc2 is not blacklisted yet. [10:58] of course glib has something for that... why didn't i check first :) [10:58] jibel: ah, ok; that's tdsodbc which needs blacklisting, I think [10:58] thx seb128 [10:59] mhr3, yw [10:59] pitti, ok. [11:00] pitti, 6 jobs are still queued, I'll do that right after. [11:00] jibel: cool, thanks [11:00] jibel: let's see how far they get now :) [11:01] pitti, mvo fixed main-all-amd64, I'll run it as well [11:01] jibel: I don't even see that on https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/ [11:02] pitti, it will be published to the public instance on the first run. [11:03] infinity, ogra: do you know which of the armel buildds are still babbages? I'll need to rebuild the postgresql stable updates on those, as they fail on the pandas (still on my list to debug this) [11:04] pitti, not off the top of my head, but since you will likely need lamont anyway to assign the builds (or can you do that yourself?), he knows which are which [11:04] ogra: I can assign them [11:05] ogra: I think actinidiaceae is still an old one, does that ring a bell? [11:05] ogra: and araceae; both are armhf buildds now, but I can temporarily switch them over [11:06] i think the aeae ones are, yep [11:07] pitti, iirc buttercup is a babbage [11:07] ogra: ah, thanks [11:07] and crabapple [11:08] pitti: I'd rather you wait until I test the upgradees work, which needs an archive admin to let the replacement into the archive [11:08] ogra: ok, started a build on buttercup [11:09] good luck :) [11:09] Riddell: ack [11:19] pitti: sounds to me like we should probably move forward to gnutls28, unless you have a reason not to [11:28] Is it a bug if the icon that appears in the unity side panel isn't the same as the icon that was in the .desktop file that launched it? [11:29] Also why that happens is a bit of a mystery to me... [11:29] cjwatson: I'm only afraid of ending up with two gnutls in main because the third-last package doesn't port to 28 or so [11:29] cjwatson: but in general I agree [11:30] I think we probably have enough time to sort that kind of thing out still [11:36] cjwatson: fresh install on an X220. installer/window manager have crashed twice so far. Is there anything I can get you before I reboot/try other stuff? [11:36] cjwatson: (precise daily) [11:36] pitti, i uploaded the nvidia-tegra driver to NEW yesterday, it will land in multiverse since we dont support it officially, is there a way to tell jockey to look for such stuff or does it do main only ? [11:36] sladen: does it leave a crash report such that you can file a bug with apport? [11:36] sladen: if the WM has crashed it may well not be my problem though. [11:36] depending exactly what crashed ... [11:36] cjwatson: yes, after I restarted the WM, I've filed the installer crash [11:37] ogra: jockey doesn't care about components; if they are enabled in apt, they'll be available [11:37] ogra: well, there's no handler for it, of course [11:37] cool, thanks [11:37] i'll take a look once the package is accepted [11:38] cjwatson: sorry, I don't have the bug number (it should arrive in a moment). The WM crashed again, so I'm on the console [11:38] sladen: don't need any more information, it's a dup of something I'll find in a bit [11:38] sladen: to get past it, deselect "third-party software" [11:39] alternatively it will go away by itself once eglibc is back in sync between amd64 and i386 [11:40] which it should be now, actually [11:40] cjwatson: I ticked that ages earlier. It crashed during the slideshow [11:43] sladen: sure, but nevertheless [11:44] (actually, it may not go away by itself until the next CD build) [11:44] is there a way around pulling in gtk3 on the kubuntu image? gstreamer0.10-plugins-good -> gstreamer0.10-gconf -> gconf2 -> libgtk-3-0 [11:44] duped now [11:46] in oneiric the gstreamer0.10-gconf dependency wasn't there but it is now: "Let gstreamer0.10-plugins-good depend on gstreamer0.10-gconf for wheezy to guarantee correct upgrades to wheezy (Closes: #625567)." [11:52] debfx, we can probably drop the gconf->gtk3 recommends [11:52] debfx, or you would like to not get gconf either? === bladernr_ is now known as bladernr_afk [11:55] seb128: I don't want gconf on the cd but since it's relatively small it wouldn't be a big issue [11:56] debfx, let me read that debian bug that made them add the depends [11:58] debfx, not sure how problematic dropping that depends would be for upgrades [11:59] but we have at least gnome-media which depends on gstreamer0.10-gconf in Ubuntu [11:59] debfx, so I would say feel free to drop the added Depends [12:03] we already shipped oneiric without that dependency so theoretically we'd have at least bug reports about packages that need to depend on gstreamer0.10-gconf [12:07] Are we aware that the cd build logs on http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/precise/ have been useless for a month and a half? [12:07] cjwatson: ^ [12:08] Sorry, not hte cd build logs. [12:08] The wubi ones. [12:11] soren: that's all the logging that the CD build side of it produces. The filesystem build is http://people.canonical.com/~ubuntu-archive/livefs-build-logs/precise/ubuntu-wubi/ [12:12] cjwatson: Oh, sorry. I thought the failed ssh attempts at the end meant that it had failde to grab the fs build log. [12:27] soren: no, that's one of the cdimage/releases mirrors failing, probably unimportantly (it's usually because the machine has been reassigned; that pool is rather fluid) [12:28] s/one/some/ === yofel_ is now known as yofel === kenvandine is now known as kenvandine_afk === MacSlow is now known as MacSlow|lunch === bladernr_afk is now known as bladernr_ [14:56] pitti: The Pandas are helpfully marked as (arm panda) instead of just (arm), so you should be able to differentiate that way. :) === dendro-afk is now known as dendrobates [15:24] slangasek, hiya - do you know if there's a TODO list of packages that need to be converted so ia32-libs-multiarch:i386 becomes installable again? :) [15:36] cjwatson: could you please add polkit-kde-1 to the kubuntu packageset? [15:37] debfx: please mail me [15:37] just our of curiosity, are only build-dependencies (and not dependencies/recommends) of seeded packages considered for the packageset? [15:37] cjwatson: I already have some months ago [15:37] no; all of deps, recommends, build-deps [15:38] ah, let me have a look then [15:39] when my external disk gives me some I/O to read mail with ... [15:42] I wonder why it's not pulled in, maybe because kde-workspace-bin recommends polkit-kde-1 | policykit-1-gnome [15:42] because it's in core [15:42] presumably because something fairly central wants it [15:43] debfx: done [15:43] cjwatson: thanks [15:43] (lp:~cjwatson/+junk/packageset has the code for determining this, if you don't mind going blind) === kenvandine_afk is now known as kenvandine === bladernr_ is now known as bladernr_afk === davmor2_ is now known as davmor2 [16:32] slangasek: is it possible to *un*multiarch a precise system? ;) [16:35] barry: Define un-multiarch... [16:36] infinity: i want to get rid of all the i386 packages and not be prompted to install or upgrade them anymore. [16:37] barry: apt-get purge `dpkg -l \*:i386 | grep ^i | awk '{print $2}'` && rm /etc/dpkg/dpkg.cfg.d/multiarch [16:37] barry: dpkg -l *:i386 | awk '{print $2}' | xargs sudo dpkg -P [16:38] pitti: Snap. [16:38] ah, and what infinity said about removing that conffile [16:38] infinity: ok, you beat me :) [16:38] infinity, pitti thanks. the biggest problem right now (for this machine) is that multiarch is incompatible with landscape. [16:38] && apt-get update [16:39] pitti: Mine also won't try to purge a package called Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend [16:39] pitti: :P [16:39] *shrug* easy to ignore :) [16:41] pitti: fwiw: [16:41] dpkg: error: package name in specifier 'Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend' is illegal: character `=' not allowed (only letters, digits and characters `-+._') [16:41] [16:41] * infinity giggles. [16:41] barry: so, add the "grep ^i" :) [16:41] :) [16:44] dpkg-query -W \*:i386 | cut -f1 :-P [16:44] machine-readable output FTW [16:45] cjwatson: dpkg-query -W lists packages that aren't installed but once were. Not that that matters for feeding to apt/dpkg, I suppose. They'll just skip over them. [16:45] true [16:46] (And dpkg -l is totally machine-readable, you just need the right machine!) [16:46] One with grep. :P === Ursinha is now known as Ursinha-lunch [16:56] pitti: the lack of xklavier bindings is blocking us for fixing an installer usability issue, so it would be nice if we could get that this cycle... does someone on desktop have time to implement that? [16:56] cjwatson: hey, I'm trying to merge edubuntu-fonts into edubuntu-meta (moving it form its own source to being part of our seeds), the problem I have is its version number (11.02.4) being quite a bit higher than that of our meta package (1.96), so I see two easy way out, either bump the epoch in edubuntu-meta or switch edubuntu-meta to using the same .. version number. Is there anything wrong with either of these option [16:57] slangasek: I might get to it in January when I'm off the hook for stable+1; is there a bug for it already (against ubiquity or so)? [16:58] broder, pitti, YokoZar: dpkg does support M-A: allowed, but the Debian archive doesn't support :any dependencies yet AFAIK so it's disallowed there currently; and the reason for Arch: all packages not being implicitly M-A: foreign is that this fails for things like Arch: all metapackages for language interpreters (e.g.: 'python') [16:58] pitti: the bug for that is bug #800561 on ubiquity, yes [16:58] Launchpad bug 800561 in ubiquity (Ubuntu Precise) "No way to add other keymap than english on Live CD" [High,Triaged] https://launchpad.net/bugs/800561 [16:59] stgraber: neither will cause a problem; do whatever feels most natural [16:59] slangasek: added an xklavier task and assigned it to me, thanks [17:00] actually, that purging doesn't work completely. i'm still left with a handful of i386 libraries that can't be removed: http://pastebin.ubuntu.com/771328/ === deryck is now known as deryck[lunch] [17:04] pitti: would you like to reply to comments #22 etc. on bug 556293? They seem to be in reply to you [17:04] Launchpad bug 556293 in apt (Ubuntu) "apt/aptitude need to take global proxy settings into account" [Undecided,Confirmed] https://launchpad.net/bugs/556293 [17:05] cjwatson: queued, will do (currently having some /msg discussions) [17:15] cjwatson: I responded, but not quite sure what the complaint is about -- people insisting that sudo must take user's proxy configuration into account (-> wontfix) or that our package management tools don't get along with the proxy settings (that'd be a bug we need to fix indeed) [17:15] pitti, infinity, cjwatson so it seems there's still some mix of i386 that can't be purged [17:16] barry: ? [17:16] barry: Shouldn't be. [17:16] infinity: http://pastebin.ubuntu.com/771328/ [17:16] barry: Use apt instead of dpkg. [17:16] barry: (ie: use my line) [17:17] apt-get purge `dpkg -l \*:i386 | grep ^i | awk '{print $2}'` [17:17] It'll actually do proper depedency resolution... [17:17] perhaps he has some M-A: foreign i386 packages installed [17:17] Perhaps. [17:17] apt might sort that sanely. [17:17] bug 850264 might cause that [17:17] Launchpad bug 850264 in apt (Ubuntu Precise) "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Triaged] https://launchpad.net/bugs/850264 [17:17] pitti: I have to say I'm not really comfortable with your proposed resolution either, and have a lot of sympathy for the people replying; sudo may be wontfix from our point of view but I can see why they're asking for it [17:18] cjwatson: well, it's not a "proposed" resolution -- it's meant to be working like that for several years already [17:18] (and once was -- it might have regressed, of course) [17:18] and surely /etc/environment is nonsense, that's system-wide! [17:18] infinity: no, unfortunately, apt doesn't help: http://pastebin.ubuntu.com/771355/ [17:18] ITYM PAM environment [17:19] cjwatson: if you apply the proxy settings globally, that goes into /etc/environment or something similar [17:19] * pitti checks ubuntu-system-service [17:19] when running in a user session we want what the user has configured [17:19] and I suspect a lot of people are working with scripts that set http_proxy in older ways, anyway [17:19] in fact some people even say as much in the bug [17:20] barry: Looks like you got in a curious situation. [17:20] well, sudo is not meant to take all your user settings with it, and even if it does, it still wouldn't work with software-center and everything else using aptdaemon [17:20] #28 probably has a point, architecturally, but that's a fairly giant change [17:20] pitti: I'm not convinced that we can fix everything in a single place [17:20] we know quite well that lots of people use sudo apt-get, not aptdaemon [17:20] right, it writes it into /etc/environment [17:20] barry: apt-get install gvfs-daemons:amd64 libsane-common:amd64 gvfs-daemons:i386- libsane-common:i386- [17:21] barry: ? [17:21] infinity: worth a shot... ;) [17:21] cjwatson: right, and our fault was to ever allow that hack to get into sudo :( [17:21] barry: (ie: remove the i386 ones and replace with amd64 ones) [17:22] cjwatson: anyway, if you really want it back in sudo, I won't start a flamewar over it, I'm just convinced that it is both wrong and also insufficient [17:22] the whole environment variable thing in sudo is a disaster, largely because it keeps changing [17:22] if you set a proxy and apply it system-wide, _both_ sudo apt-get and software-center and whatnot should just work [17:23] and developers often configure it differently for themselves and then forget what the defaults are like ... [17:23] infinity: how weird is this: [17:23] E: Unable to locate package gvfs-daemons:i386 [17:23] E: Unable to locate package libsane-common:i386 [17:23] [17:23] barry: Did you already delete the multiarch conffile and update? Cause those packages would be hard to find in that state. [17:23] infinity: :( yes [17:24] barry: If not, well. apt is a sad panda. And we need a better way to deal with multiarch upgrading in devel releases. [17:24] barry: echo "foreign-architecture i386" > /etc/dpkg/dpkg.cfg.d/multiarch && apt-get update [17:24] barry: And then try again? [17:24] infinity: thanks. trying... [17:24] cjwatson: btw, if you want it back in sudo, you'd also need to add https_proxy, ftp_proxy, and the blacklist; I think back then we only added http_proxy [17:25] I guess I don't see why *_proxy are security-critical [17:25] but again, that would only aggravate the problem [17:25] I don't see why, really [17:25] because you teach people that this actually works [17:25] if the process is receiving data from the network, it needs to treat that as untrusted *anyway* [17:25] why shouldn't it actually work? [17:25] i. e. that system-level software would take into account some user setting [17:25] because it _only_ works with sudo [17:25] untrusted> so adding a proxy doesn't change things [17:26] cjwatson, you did write the dh_installdocs --link-doc patch; how is this supposed to work with dh7 and up? [17:26] I don't think of it as system/user, it's environment passthrough [17:26] hey guys [17:26] a cron job, d-bus spawned program or anything else won't [17:26] if you want system-level operations to use a proxy, you need to set it system-wide [17:26] that's my fairly strong opinion [17:27] pitti: so? those aren't typically subprocesses of the terminal window in which you run things after export http_proxy= [17:27] what is the general view on maintaining backward compat for package building (in debian/foo), inside source package branches in ubuntu/debian proper? [17:27] cjwatson: exactly [17:27] doko: groff uses it with dh7 [17:27] cjwatson: so they won't see the user's $http_proxy [17:27] pitti: and so I simply don't see that as a problem [17:27]