| === dendro-afk is now known as dendrobates | ||
| int_ua | zyga: ping | 00:16 |
|---|---|---|
| === 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 | ||
| doko | \o/ it's done: https://launchpad.net/builders: armhf11empty | 02:04 |
| SpamapS | woot | 02:04 |
| === dendro-afk is now known as dendrobates | ||
| === dendrobates is now known as dendro-afk | ||
| micahg | Do we prefer P-A-S to hacking debian/control to allow/disallow archs? | 05:20 |
| RAOF | micahg: They're for different jobs, aren't they? p-a-s is for... um... :) | 05:34 |
| micahg | exactly :), well, it makes it easier if there's a downstream distro with support for other archs | 05:36 |
| micahg | RAOF: just found this: https://lists.ubuntu.com/archives/ubuntu-devel/2008-December/027076.html | 05:49 |
| infinity | micahg: P-a-s is for arch decisions that shouldn't be made by the source. | 05:49 |
| infinity | 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 |
| micahg | 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:50 |
| infinity | 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 |
| infinity | micahg: chromium not building on PPC sounds more like "too lazy to port". :P | 05:51 |
| micahg | infinity: indeed :) | 05:51 |
| infinity | micahg: Neither P-a-s nor Arch lines are meant to be used for that. | 05:51 |
| infinity | I'd honestly rather see the failure as a reminder. | 05:52 |
| micahg | ok | 05:52 |
| infinity | It's not something that can't be ported, just something no one's bothered to port. | 05:52 |
| micahg | wow, Debian's not even trying chromium on ![i386,amd64,armel] | 05:55 |
| infinity | Indeed. | 05:56 |
| infinity | That may be an indication of some knowlede of upstream's intent there. | 05:57 |
| infinity | Meh. | 05:57 |
| infinity | I should talk to jbailey. | 05:57 |
| infinity | I know he does chrome(ium) build mangling internally. | 05:57 |
| micahg | well, their targets are x86 desktops and android, so it makes sense | 05:58 |
| micahg | it would be nice just to have armel work consistently :) | 05:59 |
| infinity | And have it work for armhf too. | 05:59 |
| infinity | (hint, hint) | 05:59 |
| micahg | yeah, that'll probably happen during my vacation :), I don't see much time before then to play with cross-compiling chromium on arm | 05:59 |
| StevenK | infinity: jbailey is probably trying to port chromium to hppa. | 06:00 |
| infinity | StevenK: That seems unlikely. :P | 06:00 |
| micahg | 17 months until no more hppa in Ubuntu :) | 06:00 |
| * infinity sheds a tear. | 06:01 | |
| micahg | oh, and no more lpia as well | 06:01 |
| StevenK | No tears for hppa | 06:01 |
| StevenK | I will not miss lpia | 06:01 |
| infinity | lpia, I don't care about. | 06:01 |
| infinity | I do actually still use my J6750, though. | 06:02 |
| infinity | I guess it's time to move it to a Debian base. | 06:02 |
| infinity | Or turn it into a stylish coffee table. | 06:03 |
| pitti | Good morning | 06:07 |
| pitti | slangasek: they aren't upstream apparently, so if we need them, we need to do it ourselves | 06:12 |
| === mbiebl_ is now known as mbiebl | ||
| pitti | 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 |
| YokoZar | 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 |
| pitti | YokoZar: the arch: all package itself needs to be M-A: foreign | 06:25 |
| YokoZar | pitti: or M-A allowed | 06:25 |
| broder | i thought dpkg didn't actually support m-a allowed yet | 06:26 |
| pitti | presumably (I've never seen "allowed" in practice so far) | 06:26 |
| YokoZar | pitti: annoyingly, then, our fonts package don't appear to be M-A: allowed... | 06:26 |
| pitti | just not sure why they need to be explicitly declared so | 06:26 |
| YokoZar | 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:26 |
| pitti | I'd expect an Arch: all package to be "M-A: foreign" pretty much by design | 06:27 |
| pitti | slangasek: ^ I guess there are corner cases where this wouldn't work? | 06:27 |
| YokoZar | 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 |
| broder | wait..."i386 version of font package" | 06:28 |
| broder | ...are you *sure* it's arch: all? | 06:28 |
| YokoZar | ttf-mscorefonts-installer | 06:28 |
| YokoZar | yes | 06:28 |
| broder | because "i386 version" of an arch: all package sounds meaningless to me | 06:28 |
| broder | ah, wait. /me re-reads the spec | 06:29 |
| broder | anyway, it sounds like you want multi-arch: foreign | 06:29 |
| YokoZar | http://paste.ubuntu.com/770848/ | 06:30 |
| YokoZar | broder: my question was do I want that on the font itself then, or can I just put it on my package? | 06:30 |
| broder | on the font | 06:30 |
| infinity | 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:30 |
| broder | infinity: see the link that YokoZar posted at the beginning of this :) | 06:31 |
| broder | "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:31 | |
| YokoZar | Someone should clean up that specific paragraph I linked to though, it is an ambiguous "it", hence my question | 06:32 |
| * infinity goes to bed and hopes he doesn't wake up to a bunch of eglibc build failures and/or critical bugs. | 06:37 | |
| micahg | infinity: you are brave :) | 06:37 |
| * YokoZar changed "it" to "the dependency" on the multi-arch page | 06:37 | |
| infinity | micahg: If it breaks, I'm sure pitti will fix it for me. He's magical when I'm asleep. | 06:37 |
| infinity | That sounded dirty. | 06:37 |
| infinity | Hrm. | 06:37 |
| * micahg guesses he's almost as crazy with a bzip2 sync a few hours before bed | 06:38 | |
| infinity | micahg: I dunno. Did your sync involve a 4MB diff in debian/* ? | 06:38 |
| micahg | infinity: heh, no :) | 06:38 |
| micahg | I strangely feel better now | 06:38 |
| YokoZar | Ok, next multi-arch question: can I work around my issue by depending on ttf-mscorefonts-installer:any ? | 06:45 |
| YokoZar | answer: no | 06:46 |
| pitti | I don't think ':any' works | 06:46 |
| YokoZar | Yeah, just tested that experimentally | 06:47 |
| YokoZar | Well this sucks | 06:47 |
| broder | YokoZar: :any is a m-a: allowed thing, and you're using m-a: foreign | 06:47 |
| broder | also i still don't think m-a: allowed works | 06:47 |
| YokoZar | 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 |
| broder | i don't believe that's possible | 06:47 |
| YokoZar | Right, which is why I have declared this sucks | 06:48 |
| YokoZar | Fixable with an SRU to ttf-mscorefonts-installer though (ugh) | 06:48 |
| broder | packages can't force other packages to be m-a | 06:48 |
| pitti | armhf 11 empty | 06:48 |
| pitti | err, wow! | 06:48 |
| pitti | doko, infinity: ^ congrats :) | 06:48 |
| YokoZar | 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 |
| pitti | infinity: is it possible to steal some armhf builders for armel? we accepted a bunch of SRUs, and there's eglibc, webkit, etc. | 06:49 |
| broder | YokoZar: wget should be m-a: foreign | 06:50 |
| pitti | infinity: I know how to switch them in the web ui, I just don't know which builders will actually work | 06:50 |
| infinity | pitti: Yeah, some don't. ;) | 06:50 |
| infinity | pitti: I'll toss a few over. | 06:50 |
| pitti | cf. the recent genip debacle | 06:50 |
| pitti | infinity: cheers | 06:50 |
| YokoZar | broder: in Oneiric? | 06:51 |
| broder | YokoZar: i don't know about oneiric. i'm just saying conceptually it should be | 06:51 |
| pitti | 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 |
| YokoZar | 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:51 |
| infinity | pitti: Hopefully, that gets fixed soonish. | 06:52 |
| * pitti tries to pronounce liboktetakastencontrollers4 without getting a knot in his tongue | 06:52 | |
| broder | 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 |
| broder | so it doesn't matter if they're the same arch | 06:52 |
| YokoZar | Oh, right, foreign means not coinstallable, but still installable on build arch | 06:55 |
| infinity | pitti: There. You have buildds. | 06:55 |
| YokoZar | for a moment I thought M-A foreign meant that it could _only_ be foreign | 06:55 |
| YokoZar | (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) | 06:56 |
| micahg | YokoZar: arch all only being built on i386 is a bug ATM | 07:03 |
| micahg | Debian has no such restriction | 07:04 |
| YokoZar | micahg: I suppose that's related yeah | 07:04 |
| broder | micahg: huh? i don't see how that's relevant here | 07:04 |
| YokoZar | 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 |
| micahg | broder: I thought I saw something that implied it's i386 | 07:05 |
| YokoZar | 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 |
| broder | YokoZar: no, it's not confused because the package was built on i386 | 07:06 |
| broder | 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 |
| YokoZar | 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:06 |
| broder | right. but where the package was built has nothing to do with that | 07:07 |
| micahg | broder: rereading, I don't see why I thought that was relevant anymore :) | 07:07 |
| YokoZar | 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:07 |
| broder | but they'd still only be built once | 07:08 |
| broder | and differences wouldn't actually matter, because all arches would still get the same specific build | 07:08 |
| YokoZar | fair enough | 07:08 |
| YokoZar | methinks a tech board proposal might be prudent here | 07:09 |
| YokoZar | 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 |
| micahg | YokoZar: you need to get consensus in Debian first or this will cause a lot more pain | 07:10 |
| broder | YokoZar: you want to drop the requirement that arch: all packages be explicitly marked m-a: foreign? | 07:11 |
| broder | the wiki outlines a fairly compelling reason why that needs to be the case | 07:11 |
| YokoZar | 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:12 |
| YokoZar | *except ttf-mscorefonts-installer, of course which properly should require multiarching of its dependencies | 07:13 |
| broder | 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 |
| YokoZar | 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 |
| broder | (and more importantly, reimplementing) | 07:14 |
| broder | oh, m-a; foreign too | 07:14 |
| broder | (seriously, stop talking about m-a allowed because it's confusing and, more importantly, not real) | 07:15 |
| YokoZar | broder: what about arch: all packages that depend on M-A'ed packages though? | 07:15 |
| YokoZar | As we continue MAing things that's going to be more and more the case | 07:15 |
| micahg | 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:16 |
| broder | YokoZar: fwiw, i appear to be spreading misinformation. m-a allowed is implemented | 07:19 |
| YokoZar | Fair enough :) | 07:19 |
| broder | 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:20 |
| broder | without thinking exceptionally hard about it, i would guess their response will be that the implementation is nasty | 07:21 |
| broder | or alternatively http://alioth.debian.org/mail/?group_id=30462 | 07:21 |
| YokoZar | broder: alternatively, I can talk to slangasek and hope he takes up the issue :P | 07:24 |
| broder | well, you know, that's basically equivalent to what i proposed | 07:25 |
| YokoZar | True | 07:25 |
| broder | :) | 07:25 |
| cjwatson | pitti: corner case where Arch: all M-A: foreign doesn't work: python | 07:42 |
| cjwatson | (basically the canonical corner case) | 07:42 |
| pitti | infinity: cheers! | 07:59 |
| pitti | micahg: what would be the -proposed part? | 08:00 |
| dholbach | good morning | 08:00 |
| micahg | pitti: firefox and maybe mozvoikko I think | 08:00 |
| pitti | micahg: ah, so the new langpacks are enough in -updates for now as well then | 08:01 |
| pitti | micahg: but as soon as we'll do the first firefox -security we need to remember to copy the langpacks, too | 08:01 |
| micahg | pitti: right, so maybe the langpacks should target -security or is that not necessary? | 08:01 |
| pitti | micahg: no, we can just copy them once needed | 08:02 |
| pitti | they usually target -proposed, and should | 08:02 |
| micahg | ok, but my selective targetting is ok then? | 08:02 |
| pitti | micahg: sure | 08:03 |
| micahg | pitti: thanks | 08:03 |
| infinity | micahg: Oh, are you doing firefox uploads tonight? | 08:10 |
| micahg | infinity: I wanted to :-/ | 08:10 |
| micahg | it'll be later today though | 08:10 |
| micahg | infinity: you've got at least 8 hours i think | 08:10 |
| infinity | 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:10 |
| pitti | 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:19 |
| micahg | pitti: I haven't uploaded it yet | 08:20 |
| micahg | 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 |
| pitti | micahg: ah, ok; so I'll only prepare the tarballs right now, to have everything ready which doesn't depend on firefox | 08:20 |
| pitti | micahg: but that's the correct PPA? | 08:21 |
| micahg | pitti: yes, but I thought you weren't using the PPA | 08:22 |
| pitti | micahg: just for pointing langpack-o-matic against it, to see which languages have a firefox-l10n-* package | 08:22 |
| pitti | I can use the PPA or -proposed, whichever hits first | 08:22 |
| micahg | pitti: ok, that should for sure be ready by tomorrow when you come online (at least the i386 one) | 08:23 |
| pitti | cool | 08:23 |
| === smb` is now known as smb | ||
| pitti | janimo: good morning | 08:37 |
| pitti | janimo: I suppose you saw the linux-ac100 FTBFS on armel? | 08:37 |
| pitti | (armhf worked fine) | 08:38 |
| === bladernr_afk is now known as bladernr_ | ||
| === jibel_ is now known as jibel | ||
| pitti | cjwatson: https://launchpad.net/ubuntu/+source/gnutls26/2.12.14-4 NBSed gnutls-bin | 09:48 |
| pitti | cjwatson: it moved to gnutls28; do you have an opinion whether or not we should pull that into precise and to the transition? | 09:48 |
| pitti | if not, we can just revert the previous upload (I'm happy to do that) | 09:49 |
| pitti | jamespage: ^ FYI (it's on NBS) | 09:49 |
| pitti | $ apt-cache rdepends libgnutls26|wc -l | 09:49 |
| pitti | 148 | 09:49 |
| pitti | it's not exactly small | 09:49 |
| jamespage | pitti: yes - spotted that late yesterday - was going to ask the same question | 09:49 |
| jamespage | gnutls28 is in testing now I think | 09:50 |
| pitti | the recent haskell transition is done buildd-wise now, so if we want to do it, we should do it over the weekend | 09:50 |
| pitti | we still have gnutls26, so it wouldn't immediately result in lots of NBS | 09:51 |
| pitti | but we certainly don't want to ship precise with two versions | 09:51 |
| pitti | hm, libgnutls-dev is still for 26 | 09:52 |
| pitti | so we'd actually need to change the source | 09:52 |
| === _salem is now known as salem_ | ||
| pitti | jibel, jamespage: are the precise-upgrade jobs running ATM, or can we poke them? | 10:42 |
| jibel | pitti, they didn't start for some reason. I just started them manually. | 10:44 |
| pitti | jibel: presumably because the lab was still offline at their regular start time? | 10:44 |
| pitti | jibel: merci | 10:44 |
| pitti | jibel: let's see how far they get this time :) | 10:44 |
| jibel | pitti, no, the lab was ok but I think jenkins didn't like the network incident at all. | 10:45 |
| pitti | right, that's what I meant | 10:46 |
| mhr3 | hey guys, is there a common envvar where i can find tmp dir location? | 10:53 |
| seb128 | mhr3, check is $TMDIR is set and if not fallback to /tmp as the default location? | 10:56 |
| seb128 | check i*f* | 10:56 |
| seb128 | mhr3, or g_get_tmp_dir() if you use glib | 10:57 |
| seb128 | "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:57 |
| seb128 | mhr3, that's what the glib function does | 10:58 |
| jibel | pitti, main-all upgrade failed but it was expected. iodbc2 is not blacklisted yet. | 10:58 |
| mhr3 | of course glib has something for that... why didn't i check first :) | 10:58 |
| pitti | jibel: ah, ok; that's tdsodbc which needs blacklisting, I think | 10:58 |
| mhr3 | thx seb128 | 10:58 |
| seb128 | mhr3, yw | 10:59 |
| jibel | pitti, ok. | 10:59 |
| jibel | pitti, 6 jobs are still queued, I'll do that right after. | 11:00 |
| pitti | jibel: cool, thanks | 11:00 |
| pitti | jibel: let's see how far they get now :) | 11:00 |
| jibel | pitti, mvo fixed main-all-amd64, I'll run it as well | 11:01 |
| pitti | jibel: I don't even see that on https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/ | 11:01 |
| jibel | pitti, it will be published to the public instance on the first run. | 11:02 |
| pitti | 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:03 |
| ogra | 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 |
| pitti | ogra: I can assign them | 11:04 |
| pitti | ogra: I think actinidiaceae is still an old one, does that ring a bell? | 11:05 |
| pitti | ogra: and araceae; both are armhf buildds now, but I can temporarily switch them over | 11:05 |
| ogra | i think the aeae ones are, yep | 11:06 |
| ogra | pitti, iirc buttercup is a babbage | 11:07 |
| pitti | ogra: ah, thanks | 11:07 |
| ogra | and crabapple | 11:07 |
| Riddell | 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 |
| pitti | ogra: ok, started a build on buttercup | 11:08 |
| ogra | good luck :) | 11:09 |
| pitti | Riddell: ack | 11:09 |
| cjwatson | pitti: sounds to me like we should probably move forward to gnutls28, unless you have a reason not to | 11:19 |
| YokoZar | 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:28 |
| YokoZar | Also why that happens is a bit of a mystery to me... | 11:29 |
| pitti | 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 |
| pitti | cjwatson: but in general I agree | 11:29 |
| cjwatson | I think we probably have enough time to sort that kind of thing out still | 11:30 |
| sladen | 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 |
| sladen | cjwatson: (precise daily) | 11:36 |
| ogra | 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 |
| cjwatson | sladen: does it leave a crash report such that you can file a bug with apport? | 11:36 |
| cjwatson | sladen: if the WM has crashed it may well not be my problem though. | 11:36 |
| cjwatson | depending exactly what crashed ... | 11:36 |
| sladen | cjwatson: yes, after I restarted the WM, I've filed the installer crash | 11:36 |
| pitti | ogra: jockey doesn't care about components; if they are enabled in apt, they'll be available | 11:37 |
| pitti | ogra: well, there's no handler for it, of course | 11:37 |
| ogra | cool, thanks | 11:37 |
| ogra | i'll take a look once the package is accepted | 11:37 |
| sladen | 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 |
| cjwatson | sladen: don't need any more information, it's a dup of something I'll find in a bit | 11:38 |
| cjwatson | sladen: to get past it, deselect "third-party software" | 11:38 |
| cjwatson | alternatively it will go away by itself once eglibc is back in sync between amd64 and i386 | 11:39 |
| cjwatson | which it should be now, actually | 11:40 |
| sladen | cjwatson: I ticked that ages earlier. It crashed during the slideshow | 11:40 |
| cjwatson | sladen: sure, but nevertheless | 11:43 |
| cjwatson | (actually, it may not go away by itself until the next CD build) | 11:44 |
| debfx | 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 |
| cjwatson | duped now | 11:44 |
| debfx | 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:46 |
| seb128 | debfx, we can probably drop the gconf->gtk3 recommends | 11:52 |
| seb128 | debfx, or you would like to not get gconf either? | 11:52 |
| === bladernr_ is now known as bladernr_afk | ||
| debfx | seb128: I don't want gconf on the cd but since it's relatively small it wouldn't be a big issue | 11:55 |
| seb128 | debfx, let me read that debian bug that made them add the depends | 11:56 |
| seb128 | debfx, not sure how problematic dropping that depends would be for upgrades | 11:58 |
| seb128 | but we have at least gnome-media which depends on gstreamer0.10-gconf in Ubuntu | 11:59 |
| seb128 | debfx, so I would say feel free to drop the added Depends | 11:59 |
| debfx | 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:03 |
| soren | 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 |
| soren | cjwatson: ^ | 12:07 |
| soren | Sorry, not hte cd build logs. | 12:08 |
| soren | The wubi ones. | 12:08 |
| cjwatson | 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:11 |
| soren | cjwatson: Oh, sorry. I thought the failed ssh attempts at the end meant that it had failde to grab the fs build log. | 12:12 |
| cjwatson | 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:27 |
| cjwatson | s/one/some/ | 12:28 |
| === 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_ | ||
| infinity | pitti: The Pandas are helpfully marked as (arm panda) instead of just (arm), so you should be able to differentiate that way. :) | 14:56 |
| === dendro-afk is now known as dendrobates | ||
| dholbach | 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:24 |
| debfx | cjwatson: could you please add polkit-kde-1 to the kubuntu packageset? | 15:36 |
| cjwatson | debfx: please mail me | 15:37 |
| debfx | just our of curiosity, are only build-dependencies (and not dependencies/recommends) of seeded packages considered for the packageset? | 15:37 |
| debfx | cjwatson: I already have some months ago | 15:37 |
| cjwatson | no; all of deps, recommends, build-deps | 15:37 |
| cjwatson | ah, let me have a look then | 15:38 |
| cjwatson | when my external disk gives me some I/O to read mail with ... | 15:39 |
| debfx | I wonder why it's not pulled in, maybe because kde-workspace-bin recommends polkit-kde-1 | policykit-1-gnome | 15:42 |
| cjwatson | because it's in core | 15:42 |
| cjwatson | presumably because something fairly central wants it | 15:42 |
| cjwatson | debfx: done | 15:43 |
| debfx | cjwatson: thanks | 15:43 |
| cjwatson | (lp:~cjwatson/+junk/packageset has the code for determining this, if you don't mind going blind) | 15:43 |
| === kenvandine_afk is now known as kenvandine | ||
| === bladernr_ is now known as bladernr_afk | ||
| === davmor2_ is now known as davmor2 | ||
| barry | slangasek: is it possible to *un*multiarch a precise system? ;) | 16:32 |
| infinity | barry: Define un-multiarch... | 16:35 |
| barry | infinity: i want to get rid of all the i386 packages and not be prompted to install or upgrade them anymore. | 16:36 |
| infinity | barry: apt-get purge `dpkg -l \*:i386 | grep ^i | awk '{print $2}'` && rm /etc/dpkg/dpkg.cfg.d/multiarch | 16:37 |
| pitti | barry: dpkg -l *:i386 | awk '{print $2}' | xargs sudo dpkg -P | 16:37 |
| infinity | pitti: Snap. | 16:38 |
| pitti | ah, and what infinity said about removing that conffile | 16:38 |
| pitti | infinity: ok, you beat me :) | 16:38 |
| barry | infinity, pitti thanks. the biggest problem right now (for this machine) is that multiarch is incompatible with landscape. | 16:38 |
| cjwatson | && apt-get update | 16:38 |
| infinity | 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 |
| infinity | pitti: :P | 16:39 |
| pitti | *shrug* easy to ignore :) | 16:39 |
| barry | pitti: fwiw: | 16:41 |
| barry | 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 |
| barry | 16:41 | |
| * infinity giggles. | 16:41 | |
| pitti | barry: so, add the "grep ^i" :) | 16:41 |
| barry | :) | 16:41 |
| cjwatson | dpkg-query -W \*:i386 | cut -f1 :-P | 16:44 |
| cjwatson | machine-readable output FTW | 16:44 |
| infinity | 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 |
| cjwatson | true | 16:45 |
| infinity | (And dpkg -l is totally machine-readable, you just need the right machine!) | 16:46 |
| infinity | One with grep. :P | 16:46 |
| === Ursinha is now known as Ursinha-lunch | ||
| slangasek | 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 |
| stgraber | 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 <year>.<month>.<revision> version number. Is there anything wrong with either of these option | 16:56 |
| pitti | 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:57 |
| slangasek | 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 |
| slangasek | pitti: the bug for that is bug #800561 on ubiquity, yes | 16:58 |
| ubottu | 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:58 |
| cjwatson | stgraber: neither will cause a problem; do whatever feels most natural | 16:59 |
| pitti | slangasek: added an xklavier task and assigned it to me, thanks | 16:59 |
| barry | 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/ | 17:00 |
| === deryck is now known as deryck[lunch] | ||
| cjwatson | pitti: would you like to reply to comments #22 etc. on bug 556293? They seem to be in reply to you | 17:04 |
| ubottu | Launchpad bug 556293 in apt (Ubuntu) "apt/aptitude need to take global proxy settings into account" [Undecided,Confirmed] https://launchpad.net/bugs/556293 | 17:04 |
| pitti | cjwatson: queued, will do (currently having some /msg discussions) | 17:05 |
| pitti | 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 |
| barry | pitti, infinity, cjwatson so it seems there's still some mix of i386 that can't be purged | 17:15 |
| infinity | barry: ? | 17:16 |
| infinity | barry: Shouldn't be. | 17:16 |
| barry | infinity: http://pastebin.ubuntu.com/771328/ | 17:16 |
| infinity | barry: Use apt instead of dpkg. | 17:16 |
| infinity | barry: (ie: use my line) | 17:16 |
| infinity | apt-get purge `dpkg -l \*:i386 | grep ^i | awk '{print $2}'` | 17:17 |
| infinity | It'll actually do proper depedency resolution... | 17:17 |
| pitti | perhaps he has some M-A: foreign i386 packages installed | 17:17 |
| infinity | Perhaps. | 17:17 |
| infinity | apt might sort that sanely. | 17:17 |
| pitti | bug 850264 might cause that | 17:17 |
| ubottu | 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 |
| cjwatson | 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:17 |
| pitti | cjwatson: well, it's not a "proposed" resolution -- it's meant to be working like that for several years already | 17:18 |
| pitti | (and once was -- it might have regressed, of course) | 17:18 |
| cjwatson | and surely /etc/environment is nonsense, that's system-wide! | 17:18 |
| barry | infinity: no, unfortunately, apt doesn't help: http://pastebin.ubuntu.com/771355/ | 17:18 |
| cjwatson | ITYM PAM environment | 17:18 |
| pitti | 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 | |
| cjwatson | when running in a user session we want what the user has configured | 17:19 |
| cjwatson | and I suspect a lot of people are working with scripts that set http_proxy in older ways, anyway | 17:19 |
| cjwatson | in fact some people even say as much in the bug | 17:19 |
| infinity | barry: Looks like you got in a curious situation. | 17:20 |
| pitti | 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 |
| cjwatson | #28 probably has a point, architecturally, but that's a fairly giant change | 17:20 |
| cjwatson | pitti: I'm not convinced that we can fix everything in a single place | 17:20 |
| cjwatson | we know quite well that lots of people use sudo apt-get, not aptdaemon | 17:20 |
| pitti | right, it writes it into /etc/environment | 17:20 |
| infinity | barry: apt-get install gvfs-daemons:amd64 libsane-common:amd64 gvfs-daemons:i386- libsane-common:i386- | 17:20 |
| infinity | barry: ? | 17:21 |
| barry | infinity: worth a shot... ;) | 17:21 |
| pitti | cjwatson: right, and our fault was to ever allow that hack to get into sudo :( | 17:21 |
| infinity | barry: (ie: remove the i386 ones and replace with amd64 ones) | 17:21 |
| pitti | 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 |
| cjwatson | the whole environment variable thing in sudo is a disaster, largely because it keeps changing | 17:22 |
| pitti | if you set a proxy and apply it system-wide, _both_ sudo apt-get and software-center and whatnot should just work | 17:22 |
| cjwatson | and developers often configure it differently for themselves and then forget what the defaults are like ... | 17:23 |
| barry | infinity: how weird is this: | 17:23 |
| barry | E: Unable to locate package gvfs-daemons:i386 | 17:23 |
| barry | E: Unable to locate package libsane-common:i386 | 17:23 |
| barry | 17:23 | |
| infinity | barry: Did you already delete the multiarch conffile and update? Cause those packages would be hard to find in that state. | 17:23 |
| barry | infinity: :( yes | 17:23 |
| infinity | 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 |
| infinity | barry: echo "foreign-architecture i386" > /etc/dpkg/dpkg.cfg.d/multiarch && apt-get update | 17:24 |
| infinity | barry: And then try again? | 17:24 |
| barry | infinity: thanks. trying... | 17:24 |
| pitti | 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:24 |
| cjwatson | I guess I don't see why *_proxy are security-critical | 17:25 |
| pitti | but again, that would only aggravate the problem | 17:25 |
| cjwatson | I don't see why, really | 17:25 |
| pitti | because you teach people that this actually works | 17:25 |
| cjwatson | if the process is receiving data from the network, it needs to treat that as untrusted *anyway* | 17:25 |
| cjwatson | why shouldn't it actually work? | 17:25 |
| pitti | i. e. that system-level software would take into account some user setting | 17:25 |
| pitti | because it _only_ works with sudo | 17:25 |
| cjwatson | untrusted> so adding a proxy doesn't change things | 17:25 |
| doko | cjwatson, you did write the dh_installdocs --link-doc patch; how is this supposed to work with dh7 and up? | 17:26 |
| cjwatson | I don't think of it as system/user, it's environment passthrough | 17:26 |
| dobey | hey guys | 17:26 |
| pitti | a cron job, d-bus spawned program or anything else won't | 17:26 |
| pitti | if you want system-level operations to use a proxy, you need to set it system-wide | 17:26 |
| pitti | that's my fairly strong opinion | 17:26 |
| cjwatson | pitti: so? those aren't typically subprocesses of the terminal window in which you run things after export http_proxy= | 17:27 |
| dobey | 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 |
| pitti | cjwatson: exactly | 17:27 |
| cjwatson | doko: groff uses it with dh7 | 17:27 |
| pitti | cjwatson: so they won't see the user's $http_proxy | 17:27 |
| cjwatson | pitti: and so I simply don't see that as a problem | 17:27 |
| cjwatson | the sort of people who want sudo to pass through these variables very often don't care about that stuff | 17:27 |
| pitti | cjwatson: hm, perhaps we are talking about two different things here then? | 17:27 |
| cjwatson | no, we're talking about the same things, we just disagree :) | 17:27 |
| pitti | cjwatson: I'm talking about the complaint that apt doesn't use the user's proxy settings | 17:28 |
| cjwatson | pitti: yes, I know | 17:28 |
| pitti | so, crowbaring it into sudo will not do anything to actually fix it in software-center, aptdaemon, jockey, and whatnot | 17:28 |
| cjwatson | DISPLAY is a user setting too, and 'sudo sudo -V' tells me that's preserved | 17:29 |
| pitti | sure, but that's unrelated to apt not using your proxy? | 17:29 |
| cjwatson | it is related in that it's a user setting that sudo preserves despite this supposed policy that sudo doesn't pass through user settings | 17:30 |
| cjwatson | I'm not saying aptdaemon shouldn't do what it can *as well* | 17:30 |
| cjwatson | and it may not be able to pick up http_proxy from the environment of the process that caused it to be d-bus-autolaunched; fine | 17:31 |
| barry | infinity: that looks like it finally purged all i386 packages from the system, and apt/dpkg appears happy again. thanks for your help! | 17:31 |
| cjwatson | but I don't see why that means users of 'sudo apt-get' shouldn't get what they expect | 17:31 |
| infinity | barry: \o/ | 17:31 |
| pitti | I'm saying that if this is fixed properly (and it might actually work), then we don't _need_ to change sudo, because "sudo apt-get ..." will just work because apt knows the system-wide proxy | 17:31 |
| cjwatson | and it's very clear, IMO, what they expect | 17:31 |
| pitti | hm, not to me | 17:31 |
| cjwatson | the people who say they have scripts that set http_proxy and then try to run sudo apt-get won't be covered by desktop fixes | 17:31 |
| pitti | it doesn't seem very obvious that sudo apt-get should use a different proxy than aptdcon/aptdaemon/s-c | 17:31 |
| pitti | cjwatson: well, I'm not trying to fix each and every broken script out there | 17:32 |
| cjwatson | nor will people who don't even run an Ubuntu desktop at all who set http_proxy in their ordinary-user server environment shell and then try to run sudo apt-get | 17:32 |
| cjwatson | neither sudo nor apt is a desktop component; I don't see why they should rely on desktop behaviour | 17:32 |
| pitti | in a script you can just call sudo http_proxy=... apt-get | 17:32 |
| doko | cjwatson, thanks | 17:33 |
| cjwatson | sure, but it's clear from the bug that people don't find that natural; and I'm not sure I can blame them | 17:33 |
| cjwatson | again: why is *_proxy security-critical, such that sudo should filter it out? | 17:33 |
| cjwatson | I do think this is an important question | 17:33 |
| pitti | I don't think it's that security critical | 17:33 |
| pitti | you need to defend against spoofing etc. by other ways | 17:34 |
| pitti | but it's causing unexpected behaviour, is different from other systems/platforms (as it's an ubuntu specific hack), and we never implemented it properly | 17:34 |
| cjwatson | exactly; so what is filtering them achieving, in isolation? | 17:34 |
| cjwatson | lots of things in Ubuntu are different from other systems :-) | 17:34 |
| pitti | it's achieving consistency in apt's behavioru | 17:34 |
| cjwatson | consistency with what people don't want, sure | 17:34 |
| pitti | in that it always usees the same proxy, whether it's being called from the daily cron job or from a d-bus backend or from sudo | 17:35 |
| cjwatson | if you've set http_proxy in your exported shell environment, that is a blindingly clear signal that you want the proxy to be used for anything you start from that terminal | 17:35 |
| pitti | well, for your own user account, yes | 17:35 |
| pitti | I set lots of things in my environment which I don't want to impose to other users or admin operations | 17:36 |
| cjwatson | *_proxy feels like a totally sensible one to pass through | 17:36 |
| pitti | $EMAIL, $EDITOR, GPG_AGENT, etc. | 17:36 |
| cjwatson | requiring things to be set in files is clumsy, too | 17:36 |
| cjwatson | take the situation in the Canonical datacentre | 17:36 |
| cjwatson | you need to use a proxy to access things outside of your network segment | 17:37 |
| cjwatson | but in some cases, if you try to use a proxy, it will actually break stuff | 17:37 |
| pitti | so we actually expect every user to set that on their own? | 17:37 |
| cjwatson | wait | 17:37 |
| pitti | shouldn't we set the proxy in /etc/environment to fix it for everyone? | 17:37 |
| cjwatson | if you are in this kind of environment, which is *totally outside Ubuntu's control*, you may well quite reasonably occasionally export http_proxy in a shell while doing something | 17:38 |
| cjwatson | and corporate networks are weird, they're full of this kind of nonsense | 17:38 |
| cjwatson | quite often | 17:38 |
| cjwatson | I just feel we're needlessly getting in people's way | 17:38 |
| cjwatson | anyway, it sounds like we're at a stalemate | 17:39 |
| pitti | yeah, I guess so | 17:39 |
| cjwatson | I don't particularly want to force my point of view if there's no consensus, and it does sound as though there's something to be fixed in apt/ubuntu-system-service/whatever | 17:40 |
| pitti | cjwatson: as I said, if you prefer to change sudo to pass through the environment, I won't start an upload war over it | 17:40 |
| cjwatson | but I think we have totally failed to articulate our reasoning to users | 17:40 |
| cjwatson | at the very least | 17:40 |
| cjwatson | and explain to them why they're better off this way | 17:40 |
| pitti | I just personally find it unexpected and also won't actually fix the problem in many of these kind of bug reports, but at least it doesn't make the latter any worse | 17:40 |
| pitti | a proxy which should apply to everythign in the system should simply not be set in an user's .profile IMHO; that will always lead to unexpected things | 17:41 |
| pitti | (that applies to any configuration setting, not just proxy) | 17:41 |
| cjwatson | but that's a different argument from what we should do given that we have found that it *is* set in a user's .profile or similar | 17:42 |
| pitti | cjwatson: anyway, thanks for sharing your POV; I think I at least see now more clearly why some people might expect it to work that way | 17:43 |
| cjwatson | I think we're onto a loser trying to tell users what they can and can't put in their dotfiles :-) | 17:43 |
| infinity | cjwatson: BTW, I reverted your revert of the C.UTF-8 collating issue before merging to the latest Debian eglibc that should fix your concerns (it now follows POSIX for collation of old skool C symbols, and then strict numerical order for everything after that) | 17:43 |
| pitti | (also, welcome distraction from armel panda __test_and_set FUBAR :) ) | 17:43 |
| cjwatson | infinity: yeah, I was expecting that patch to be superseded, thanks | 17:43 |
| infinity | cjwatson: But since you were the one who was actively involved in both debugging and reverting, I'd appreciate if you could give it a once-over and make sure it's sane now? :) | 17:43 |
| cjwatson | infinity: I looked at youpi's patch for that at the time, I think | 17:43 |
| * infinity nods. | 17:44 | |
| cjwatson | and I was happy with it | 17:44 |
| cjwatson | POSIX then numerical is exactly right | 17:44 |
| cjwatson | (in fact that's just numerical all the way through, isn't it? | 17:44 |
| cjwatson | ) | 17:44 |
| infinity | It might be. Does C not do any reordering for non-alphabet chars? | 17:45 |
| * infinity never remembers, he just knows that the subtle differences between locales drive him batty. | 17:45 | |
| cjwatson | I don't *think* so | 17:45 |
| slangasek | dholbach: the TODO list of packages to be converted is roughly the output of this command on amd64: for pkg in $(apt-cache show ia32-libs-multiarch |sed -n -e'/^Depends: / { s/Depends://; s/, /\n/g; p }'); do echo $pkg $pkg:i386; done | xargs sudo apt-get install -y | sed -n -e'/The following packages have unmet dependencies/,$p' | less | 17:50 |
| dholbach | slangasek, great, I'll take a look | 17:51 |
| dholbach | slangasek, should bugs be filed or it be made a bit more obvious that work needs to be done there? :) | 17:51 |
| slangasek | barry, pitti, infinity: dpkg -l '*:i386' | awk '/^i/ { print $2 }' | xargs sudo apt-get -y purge, anyway - enough with the useless use of grep ;) | 17:53 |
| kees | (strickly speaking, shouldn't the awk be /^.i/ ? | 17:54 |
| kees | ) | 17:54 |
| slangasek | dholbach: eh, filing bugs for it would just be paperwork, and it wouldn't even give a comprehensive overview | 17:54 |
| slangasek | kees: no, because you want to get packages you've asked to install but are currently half-installed | 17:54 |
| slangasek | fsvo "you've asked" | 17:54 |
| kees | slangasek: oh! right | 17:54 |
| dholbach | slangasek, ok :) | 17:55 |
| slangasek | dholbach: I generally just start again from the top of that command's output each time I get a chance to poke at it | 17:55 |
| dholbach | ok :) | 17:55 |
| kees | slangasek: the list is getting short! | 17:56 |
| slangasek | broder: did you decide what the right thing to do was with gstreamer0.10-gconf / gconf? Should gstreamer0.10-plugins-good revert the dep? | 17:56 |
| slangasek | kees: yep - a couple of days' work should get us down to the last handful of issues | 17:57 |
| === Ursinha-lunch is now known as Ursinha | ||
| kees | slangasek: yeah. and ibus was uploaded in debian last night, so that's one to just sync | 18:02 |
| kees | slangasek: have you heard back from the other folks that signed up for stuff at the BSP? I was thinking I was going to grind through those today if possible. | 18:03 |
| slangasek | kees: no, nor have I had a chance to chase them down | 18:05 |
| slangasek | I guess at this point we should assume their patches disappeared in a puff of cloud smoke | 18:06 |
| * kees agrees | 18:06 | |
| kees | slangasek: oh, btw, you said to stay away from the libpam/libnss bits at the BSP, but I forgot why. I've done a pam module M-Aing already, is there something more evil in libpam-ldap? | 18:07 |
| slangasek | kees: pam and nss aren't really shared libs so don't follow the recipe, I didn't want anyone to be confused | 18:07 |
| slangasek | pam modules also technically need to have a versioned dependency on the libpam that looks in the multiarch dir | 18:08 |
| slangasek | (I think Russ filed a bug on pam in Debian about this) | 18:08 |
| dobey | can one do "Depends: foo | (bar & baz)" ? | 18:08 |
| slangasek | kees: *and*, the maintainer scripts don't DTRT on removal of the package for only one of the archs | 18:08 |
| slangasek | dobey: sure, expands to Depends: foo | bar, foo | baz | 18:08 |
| kees | slangasek: versioned dep and maint scripts. heh. I suspect I did my pam module incorrectly. /me will go examine it before continuing. | 18:09 |
| dobey | hmm | 18:09 |
| slangasek | kees: the nss is easy though, provided you understand it's not really a shared lib | 18:09 |
| * kees nods | 18:10 | |
| broder | slangasek: i couldn't come up with any way to multiarchify gconf, so dropping the dep may be the best option | 18:14 |
| pitti | good night everyone | 18:17 |
| slangasek | broder: ok | 18:19 |
| slangasek | pitti: 'night! | 18:19 |
| l3on | doko, around? could you explain me why in package tagsoup you set ant1.7 ? | 18:20 |
| doko | l3on, likely because it didn't build. have a look at the publishing history | 18:26 |
| l3on | ah ok :) | 18:26 |
| === deryck[lunch] is now known as deryck | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| YokoZar | slangasek: Should I file a massive bug linked against every font and tag it multiarch then? :/ | 18:42 |
| YokoZar | (and perhaps other arch: all packages that are ok in all circumstances) | 18:45 |
| slangasek | YokoZar: huh? why would we care about doing this for "every font"? | 18:46 |
| slangasek | it's only worth doing for Arch: all packages that have reverse-dependencies that are interesting under multiarch | 18:46 |
| YokoZar | slangasek: Right, this all started cause I'm packing up commercial i386 binary packages for the app store and came across one that has a hard dependency on a font | 18:47 |
| slangasek | yeah - the number of font packages that are going to have such reverse-dependencies is pretty small | 18:48 |
| YokoZar | And I expect I'll run into more of them | 18:48 |
| slangasek | in fact, msttcorefonts might be the only one | 18:48 |
| slangasek | (there are other font packages that have been marked M-A: foreign already due to revdeps on the Ubuntu desktop, but I don't expect third-party commercial packages to be specifying dependencies on odd fonts) | 18:48 |
| YokoZar | I'm not sure we can categorically say that. I'll admit the non default, non-MS fonts are a bit less likely though | 18:49 |
| YokoZar | (except the ones I need for Wine...) | 18:50 |
| slangasek | they're sufficiently unlikely that I think it's a misuse of time to go tagging other font packages before we find packages that need them | 18:50 |
| slangasek | I certainly wouldn't want to carry an Ubuntu delta for them | 18:50 |
| debfx | slangasek: the phonon (binary) package is used to pull in a phonon backend. When building phonon for multiarch I need to change it from arch:all to arch:any/multi-arch:same so the backend is pulled in from the correct arch, right? | 18:50 |
| YokoZar | Yeah the idea would be to get this into debian. I'm just worried I'll have some commercial app packed up 2 years from now and I'll have to deal with this headache for some stupid font that we could have fixed now | 18:50 |
| slangasek | debfx: that looks like the right thing to do, yes | 18:51 |
| debfx | ok thanks, will do that | 18:53 |
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| nemo | cjwatson: damn. forgot to file that bug when I got home. I'll try to remember again today. unless you already filed one somewhere of course :) | 18:57 |
| cjwatson | I didn't | 18:57 |
| cjwatson | thanks | 18:57 |
| === dendrobates is now known as dendro-afk | ||
| infinity | pitti: I thought you wanted/needed your postgres builds on non-pandas? | 19:10 |
| === dendro-afk is now known as dendrobates | ||
| dobey | is there an easy way to tell pbuilder to also pull packages from a certain PPA for a single build? | 19:26 |
| dobey | more specifically, with pbuilder-dist | 19:29 |
| slangasek | cking: don't keep us hanging in suspense! what's causing the disk wakeups? :) | 19:52 |
| cking | slangasek, that's for my format report :-) | 19:52 |
| slangasek | aww | 19:52 |
| cking | s/format/formal | 19:53 |
| cking | dang typos | 19:53 |
| kees | format c:/ | 19:53 |
| kees | hah, I can't even get that right | 19:53 |
| kees | format c:\ | 19:53 |
| kees | there! | 19:53 |
| slangasek | format c:\\ of course | 19:53 |
| kees | heh | 19:54 |
| mdeslaur | that would be format c: | 19:54 |
| mdeslaur | (at least, that's what my muscle memory tell me...) | 19:56 |
| mdeslaur | s/tell/tells/ | 19:56 |
| slangasek | yeah ;) | 19:56 |
| slangasek | because you're specifying a drive, not a directory | 19:56 |
| mdeslaur | kees: as punishment, you need to modify config.sys with edlin | 19:57 |
| kees | echo "jmp f000:ffff" | debug.com | 19:58 |
| kees | that was a well-timed exit and quick msg by cking | 19:59 |
| kees | s/quick/quit/ | 19:59 |
| mdeslaur | kees: hehe :P | 19:59 |
| === dendrobates is now known as dendro-afk | ||
| cr3 | if I want to dynamically generate a version file in a project by using bzr version-info --format=python, would it preferable to have the output directly to a file imported by the rest of the project or symlink another file to the output and commit the symlink? | 20:33 |
| === dendro-afk is now known as dendrobates | ||
| micahg | stgraber: since Bug #876829 has now been fixed in Debian, would it be possible to get it in precise/SRUd to oneiric? | 21:29 |
| ubottu | Launchpad bug 876829 in ifupdown (Ubuntu Precise) "Oneiric's ifupdown breaks ip aliases" [High,Triaged] https://launchpad.net/bugs/876829 | 21:29 |
| stgraber | micahg: is that you volunteering for the ifupdown merge in Precise? :) | 21:29 |
| micahg | stgraber: I could do that if smoser doesn't want it | 21:30 |
| * micahg figures beta will be more stable than alpha | 21:30 | |
| stgraber | ifupdown has been on my to-merge list because of that bug and possibly a few others (dhcpv6 support, making sure dhclient uses /var/lib/dhcp and not /var/lib/dhcp3, ...) | 21:31 |
| smoser | micahg, feel free. i'm not going to do it today. | 21:31 |
| stgraber | I was planning on getting to it in January (at the sprint), but if you have time to do the initial merge, I definitely won't stop you :) | 21:32 |
| micahg | smoser: I'm not going to do it today either :), weekend at earliest, most likely next week sometime though | 21:32 |
| micahg | stgraber: ah, so if I get the merge done over vacation, you can do the SRU at the sprint? | 21:32 |
| stgraber | micahg: yep, can definitely do that | 21:33 |
| micahg | stgraber: cool, thanks | 21:34 |
| === calc is now known as Guest64986 | ||
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| SpamapS | hm, when using 'bzr merge' on packaging branches, how does one turn off the merge-changelogs step? apache2's changelog is horribly broken and can't survive such a step. :-/ | 22:30 |
| SpamapS | aha, BZR_DISABLE_PLUGINS | 22:33 |
| === salem_ is now known as _salem | ||
| cjwatson | SpamapS: I just do the merge, 'bzr shelve --destroy debian/changelog', and hunt-and-destroy the diff hunks I don't want :) | 23:25 |
| === dendrobates is now known as dendro-afk | ||
| SpamapS | cjwatson: I have forgotten about bzr shelve about 6 times now. :-P | 23:32 |
| * SpamapS is starting to think all those years playing hockey may have had more negative impact than he thought | 23:33 | |
| === dendro-afk is now known as dendrobates | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!