| === robbiew is now known as robbiew_ | ||
| === tomreyn_ is now known as tomreyn | ||
| bdmurray | kirkland: could passwd somehow warn about bug 579876? | 00:14 |
|---|---|---|
| ubottu | Launchpad bug 579876 in ecryptfs-utils (Ubuntu) "encrypted home directory isn't mounted if password changed by another user" [High,Won't fix] https://launchpad.net/bugs/579876 | 00:14 |
| kirkland | bdmurray: would take some pam hackery, should probably talk to slangasek | 00:15 |
| kirkland | bdmurray: i could probably make pam_ecryptfs say something | 00:15 |
| bdmurray | that seems nicer than hoping people find an answer in Launchpad | 00:15 |
| slangasek | does pam_ecryptfs stack before or after pam_{unix,krb5,fwibble} for password changes? | 00:15 |
| * kirkland checks | 00:16 | |
| kirkland | slangasek: that's common-password? | 00:16 |
| slangasek | yes | 00:16 |
| kirkland | slangasek: ecryptfs is last | 00:16 |
| slangasek | hmm, ok | 00:17 |
| kirkland | slangasek: if old password is empty, i was thinking i could throw a warning message | 00:17 |
| slangasek | and how's it marked? optional, requisite, etc? | 00:17 |
| kirkland | password optional pam_ecryptfs.so | 00:17 |
| slangasek | yeah, I'm thinking you could downright abort the stack instead, if you wanted :) | 00:17 |
| kirkland | slangasek: i deliberately did not, in the beginning | 00:18 |
| kirkland | slangasek: more and more people are complaining about this | 00:18 |
| slangasek | well, I guess giving no option for root to change the password would get a different set of people complaining | 00:21 |
| slangasek | a prompt that has to be explicitly acked might be the best | 00:22 |
| slangasek | so pam_ecryptfs will never prompt for a password of its own in the event that the login credentials don't match the ecryptfs creds? | 00:22 |
| kirkland | slangasek: correct | 00:28 |
| slangasek | should it? | 00:28 |
| === yofel_ is now known as yofel | ||
| CardinalFang | Hi all. I have a package for upload that fixes a bug found in integration testing. May I have an uploader take a look? | 00:56 |
| CardinalFang | https://code.edge.launchpad.net/~cmiller/ubuntu/natty/desktopcouch/1.0.7-0u2/+merge/57972 | 00:56 |
| CardinalFang | The new ubuntuone-control-panel-gtk exposed a race condition when desktopcouch is used ever for the first time. | 00:57 |
| * CardinalFang winks sexily at kees and kenvandine. | 01:10 | |
| jcastro | kees: can you add ~hughhalf to ~uds-planners? | 01:12 |
| CardinalFang | I attached a debdiff to the bug report, in case someone doesn't like source-package branches. https://bugs.edge.launchpad.net/ubuntu/+source/desktopcouch/+bug/760236 | 01:20 |
| ubottu | Ubuntu bug 760236 in desktopcouch (Ubuntu) "desktopcouch answers DBus before plugins are completed" [High,In progress] | 01:20 |
| CardinalFang | smoser, hi. I see you're named patch pilot. ^~1h ago, can this make it today? | 01:46 |
| * CardinalFang steps AFK to retrieve food. | 01:48 | |
| kenvandine | CardinalFang, i'll look | 01:55 |
| dtigue | hey i updated to beta 2 today and now my top status bar has turned a light grey color and will not change back to the nice dark color it used to be | 02:09 |
| kenvandine | CardinalFang, sponsored | 02:13 |
| soreau | Hey guys, ubuntu upgrades installs new kernels but it never removes older kernels, leaving a mess of grub list after awhile. Is there some way (a one-liner?) to remove all but the currently running kernel (and related packages for those kernel versions) | 02:16 |
| soreau | Sorry, did I miss a response? | 02:25 |
| dtigue | i know you can remove the kernals not needed in synaptic | 02:26 |
| dtigue | kernels | 02:26 |
| soreau | Yes but that gets old after awhile | 02:26 |
| soreau | In specific, I'm looking for a one-liner that automatically removes all but the currently running kernel | 02:26 |
| soreau | Or even a gui way to automatically do it | 02:27 |
| soreau | I'm thinking maybe there's some clever way to do it with aptitude or apt-get | 02:29 |
| dtigue | im sure there is but i dont know it | 02:29 |
| dtigue | sorry | 02:29 |
| ion | Remove linux packages from aptitude’s “don’t autoremove” patterns. | 02:31 |
| soreau | ion: How can you do that? | 02:31 |
| ion | Aptitude settings | 02:31 |
| CardinalFang | kenvandine, thank you, sir! | 02:31 |
| soreau | ion: How to get to aptitude settings | 02:32 |
| Sarvatt | soreau: /etc/apt/apt.conf.d/01autoremove | 02:32 |
| soreau | Ah ok | 02:32 |
| kenvandine | CardinalFang, np | 02:33 |
| soreau | Sarvatt: ion: I removed linux-image line from /etc/apt/apt.conf.d/01autoremove and ran apt-get update but apt-get autoremove still doesn't show anything to remove | 02:38 |
| soreau | Is there a special command needed to make it recognize the change? | 02:39 |
| Sarvatt | it'll just affect future upgrades | 02:39 |
| dtigue | so has anyone else seen the top panel go to a light grey color after updating to beta 2?? | 02:40 |
| soreau | Sarvatt: Well that's not exactly what I needed :P | 02:40 |
| CardinalFang | soreau, do you have "linux-image-generic" installed? | 02:40 |
| CardinalFang | soreau, if so, this should do it: $ dpkg -l linux-image-[0-9]\* |egrep ^ii |while read status pkg cdr; do sudo dpkg -P $pkg; done | 02:41 |
| CardinalFang | The most recent, a dependency of a metapackage, will fail to be uninstalled. | 02:42 |
| soreau | CardinalFang: Well that worked to remove the linux-image packages, but not linux-headers. I tried the same command with linux-headers-[0-9]\* but it didn't work | 02:50 |
| soreau | or hmm.. maybe it did | 02:51 |
| soreau | What does 'pi' mean in dpkg -l output? | 02:52 |
| soreau | the output from the command said it wasn't removing any header packages due to dependency problems | 02:53 |
| soreau | dpkg: dependency problems prevent removal of linux-headers-2.6.35-23: \n linux-headers-2.6.35-23-generic depends on linux-headers-2.6.35-23. | 02:54 |
| soreau | all say the same | 02:55 |
| ion | You don't want to use dpkg like that. Use aptitude instead. It'll handle dependencies. | 02:58 |
| soreau | ion: How though? | 02:58 |
| soreau | dpkg man page doesn't even tell what 'rc' 'ii' 'pi' etc mean | 02:59 |
| CardinalFang | soreau, it's in the header of the output. | 02:59 |
| soreau | CardinalFang: That's not too intuitive because 1) most times you're grepping dpkg -l and 2) the terminal default is only 200 lines scrollback | 03:01 |
| soreau | and 3) it doesn't explicitly explain what the letters mean | 03:01 |
| CardinalFang | soreau, I'm just telling you where you can find what "pi" means. Purge wanted. Now Installed. | 03:01 |
| soreau | Ah ok | 03:01 |
| soreau | So the package manager took note the packages were attempted to be removed | 03:02 |
| soreau | So how can I remove header and header-generic packages too | 03:02 |
| soreau | Ah hm | 03:05 |
| soreau | This seems to be working 'dpkg -l linux-image-[0-9]\* |egrep ^ii |while read status pkg cdr; do sudo dpkg -P $pkg; done && dpkg -l linux-headers-[0-9]\* |egrep ^ii |while read status pkg cdr; do sudo aptitude purge -y $pkg; done' | 03:08 |
| soreau | Hmm, seems to remove headers for currently running kernel too | 03:09 |
| soreau | Well hm | 03:13 |
| soreau | If there is a 'pi' package, how to make it go back to 'ii'? | 03:13 |
| soreau | Seems a simple reinstall does the trick | 03:15 |
| SMG1 | hello, can anyone help me, "My Computer" does not open when clicked and no drives show up on the left pane of windows, but they show up in gparted and disk utility. | 04:16 |
| SMG1 | hello, anyone | 04:24 |
| holstein | SMG1: is that a support question? | 04:25 |
| SMG1 | yes | 04:26 |
| holstein | 11.04? | 04:26 |
| === dendro-afk is now known as dendrobates | ||
| holstein | you can try #ubuntu like the topic suggests | 04:27 |
| holstein | or #ubuntu+1 for 11.04 | 04:27 |
| holstein | or #ubuntu-beginners if those are too busy or too slow | 04:27 |
| jbicha | quit | 04:59 |
| === gerard0 is now known as javamaniac | ||
| === javamaniac is now known as gerard0 | ||
| ohsix | smoser: where can i get someone to advocate something upstream? an important feature has been removed from a package and they will not budge on adding it back, ubuntu could easily patch it back in with a few hundred line patch; but as i understand it that is usually not done | 06:32 |
| ohsix | smoser: no technical justification or anything has been made for its removal (btw, it's proxy support for transmission) | 06:33 |
| ohsix | smoser: or can transmission be pinned back to 2.11 | 06:50 |
| ohsix | man i miss not knowing anything about this crap, was much easier just to throw my hands up; now i know where to contact the people and how to read the code, just pisses me off more often than not :[ | 07:03 |
| kees | jcastro: added! | 07:37 |
| ohsix | https://bugs.launchpad.net/ubuntu/+source/evince/+bug/651931 does this need an SRU to get into natty? | 08:37 |
| ubottu | Ubuntu bug 651931 in evince (Ubuntu) "evince crashed with SIGSEGV in clear_job_selection()" [Medium,Fix committed] | 08:37 |
| ohsix | https://bugs.launchpad.net/bugs/629258 would be nice if this was a papercut again :\ i've got 4 machines that never show more than "estimating ..." | 08:39 |
| ubottu | Ubuntu bug 629258 in DeviceKit-Power "Battery life estimation never comes around" [Medium,In progress] | 08:39 |
| bradm | ohsix: my laptop has had that estimating battery bug for a while :-/ | 08:59 |
| ohsix | its pretty clear cut if you drill down in the bug | 09:00 |
| ohsix | chech the output of upower --dump for energy-rate, aiui hal would estimate it if the battery didn't report it, so when hal went away so did the number | 09:01 |
| bradm | would make sense to remove the "estimating" if it can't do it anymore, I guess | 09:02 |
| ohsix | well if the estimao\tor was back in there for batteries without rate readings then the battery historty would be stored/calculated as normal | 09:04 |
| ohsix | and i think i saw it mentioned that there used to be an interpolator in upower too but it was never used | 09:06 |
| ohsix | the battery applet doing statistics should work without the data present tho, so it doesn't compound the error | 09:06 |
| === akshatj_ is now known as akshatj | ||
| bdrung | doko_: i finally fixed lintian (now tested on i386 too) | 11:02 |
| === doko_ is now known as doko | ||
| Tapis | hi | 14:14 |
| Tapis | Is there an "easy way" to change the Kernel of an existing .iso in order to make the installation via ubuntu-installer with a newer Linux Kernel ? | 14:17 |
| sladen | Tapis: https://help.ubuntu.com/community/LiveCDCustomization FSVO "easy" | 14:18 |
| sladen | Tapis: basically unpack the CD, replace the kernel packages, re-pack | 14:18 |
| sladen | Tapis: (the kernel for the LiveCD is stored outside of the Squashfs IIRC | 14:19 |
| Tapis | i don't want to change any other packages, or "customize" the .iso, i want to make the ubuntu-installer use another Kernel during the installation, for a spécific hardware ( i've already got the my-new-kernel.deb ) | 14:21 |
| Tapis | so, i do this way, i can install my-new-kernel.deb and repack the .iso, and everything sould be fine ? | 14:21 |
| Tapis | ( thanks for your help sladen, can you just "confirm" what i've just say ) | 14:25 |
| dobey | Tapis: it sounds like you'd need to rebuild the squashfs for the Live system; and sladen was telling you how to change the package that would be installed during install (but not booted on the image) | 15:04 |
| Tapis | dobey: ok, so sladen' proposition is not compatible with what i want to do, i want my .iso boot with my custom kernel in order to make ubuntu-installer use this custom Kernel | 15:08 |
| Tapis | dobey: is there any documentation about this ? i found some in the debian wiki, about rebuild debian-installer, make the .iso image, but it's not very documented and complete | 15:11 |
| sladen | Tapis: https://help.ubuntu.com/community/LiveCDCustomization | 15:16 |
| sladen | Tapis: mount -o loop image.iso .../somewhere | 15:16 |
| sladen | Tapis: cd .../somewhere && do_stuff_like_replace_the_kernel | 15:17 |
| Tapis | yes, i already understand that, but dobey said that it's for INSTALL a custom kernel with ubuntu-installer, not BOOT on this custom kernel FOR the installation ( what i want to do ) | 15:18 |
| dobey | well i mean only copying the .deb will only let you install it, not boot the cd from it. there's a lot more to do for that. read the wiki page | 15:19 |
| dobey | rebuilding the live image isn't as easy as copying the .deb over, modifying the manifest, and repacking the .iso | 15:20 |
| dobey | but it's doable, and i'm sure the wiki pages will point you in the right direction | 15:20 |
| Tapis | ok ok... i've already find some documentation on debian wiki, i know it's doable to build from scratch a custom .iso, but i wanted to know if a "easy way" was possible from an EXISTING .iso | 15:22 |
| sladen | Tapis: ------> https://help.ubuntu.com/community/LiveCDCustomization <----- | 15:22 |
| Tapis | anyway, thanks dobey and sladen for the help, i'm going to RTFM and try to do this | 15:22 |
| sladen | Tapis: if you're wanting to change the boot kernel, but not the installed kernel, it's in /install/vmlinuz on the CD | 15:23 |
| Tapis | sladen: ok, i've already find this, well...if this way works, it's perfect ! :) | 15:24 |
| sladen | Tapis: if you're wanting to change the installed kernel, then it's a couple of steps easier to do on the alternate CD and is in pool/main/l/linux/linux-image*.deb | 15:24 |
| Tapis | sladen: no, i don't care about the installed kernel, i can do this later, i just want to replace the "booted kernel" | 15:26 |
| sladen | Tapis: if you're wanting to change the installed kernel on the main/LiveCD, then it's slightly harder because you need to unpack, mount, chroot, dpkg -i the .deb, resquashfs, rebuild the .iso | 15:26 |
| Tapis | ok | 15:26 |
| Tapis | thanks again sladen and dobey | 15:27 |
| Tapis | bye everyone | 15:27 |
| ScottK | mdz: There are four josm uploads in the queue are they all the same? | 15:40 |
| ScottK | mdz: Unping. Accepted. | 17:09 |
| hyperair | jcastro: ping. do you know who i can direct my complaints about paste.ubuntu.com to? | 17:11 |
| hyperair | s/complaints/bug reports/ | 17:11 |
| LLStarks | is there any chance the apt-sync/delta-deb proposal will actually be mentioned at uds-o? | 18:23 |
| ScottK | Yes | 18:25 |
| soreau | Hey guys, I am confused by driconf GUI. There used to be a lot of options but now there is almost none, even in expert mode. Is there some additional package that needs to be installed? | 18:26 |
| mdz | ScottK, yes, sorry for the noise | 19:38 |
| mdz | ScottK, the first three seemed to be rejected with "550 Changes file must be signed with a valid GPG signature: Verification failed 3 times" but apparently they went through? | 19:39 |
| ScottK | mdz: Yes. It's an LP bug that they are aware of. | 19:39 |
| ScottK | lifeless: ^^^ | 19:39 |
| ScottK | Apparently Soyuze and the Ubuntu keyserver aren't always on speaking terms. | 19:40 |
| mdz | ScottK, thanks for accepting the fix | 19:40 |
| infinity | Shocking. | 19:40 |
| ScottK | No problem. | 19:40 |
| infinity | (Both the bug, and spelling Soyuz with an 'e'...) | 19:41 |
| ScottK | I know how to spell it, just not how to type. | 19:44 |
| infinity | ScottK: I probably should get a t-shirt made up with that on it. | 19:55 |
| ScottK | ;-) | 19:55 |
| * infinity is annoyed that when he does a quick LP bugs search for "ftbfs", the first two that pop are the qemu firmware arch:all affinity bugs from, like, 3 decades ago. | 19:56 | |
| infinity | Maybe I should just fix soyuz instead of looking for packages to fix. | 19:57 |
| slangasek | infinity: want to teach soyuz to have a policy for multiarch build-dependencies? :) | 20:09 |
| infinity | slangasek: Oh? | 20:11 |
| infinity | slangasek: Elaborate? | 20:11 |
| slangasek | infinity: well, if someone could fix it so those qemu firmware packages no longer had to be arch: all, that would solve the problem | 20:11 |
| infinity | slangasek: Err, but multiarch only helps you there if you can actually emulate the arch on another. | 20:12 |
| slangasek | although that may not be multiarch build-dependencies in this case, but simply cross-arch dependencies, for which I suppose the policy might not need to live in soyuz | 20:13 |
| infinity | slangasek: Can i386 actually build ppc and sparc binaries in the current state of the world? | 20:13 |
| slangasek | infinity: not at all - I was suggesting that you make openbios-sparc an Architecture: sparc package, and have qemu depend/recommend/whatever openbios-sparc:sparc | 20:14 |
| infinity | slangasek: And yeah, none of that would actually need soyuz support, per se. launchpad-buildd/sbuild support, but that's much less hassle. | 20:14 |
| slangasek | (something to be coordinated with Debian, to be sure) | 20:14 |
| slangasek | oh, but we don't have sparc in the archive anymore, so I guess that wouldn't work, hmm | 20:14 |
| infinity | slangasek: Oh. THAT solution is entirely packaging toolchain. Done. | 20:14 |
| infinity | slangasek: (Except for that) | 20:15 |
| slangasek | we do have an armel cross-toolchain in the archive these days; could do the same for powerpc and sparc I guess | 20:15 |
| slangasek | except that I was hoping we'd soon be able to convert that toolchain over to use multiarch instead of rebuilding libs :) | 20:15 |
| infinity | Oh, yeah, sparc's completely gone now. That bug should just be closed then. | 20:16 |
| infinity | Given that we insist on building from source at SOME point in the process, we really can't maintain a sparc binary... | 20:16 |
| slangasek | might still be the preferred solution for powerpc though | 20:17 |
| infinity | For PPC, the multi-arch thing sounds clever, but how does that work at the apt level? I haven't looked. | 20:18 |
| infinity | Does it just do magic to find other arches, or do you need to specify them in sources.list? | 20:18 |
| slangasek | well, that's part of the question - what would we want a buildd to allow a package to pull in from other architectures as part of a build? | 20:18 |
| infinity | And if the former, does Ubuntu's apt have extra magic on top of the magic to deal with archive/ports? | 20:18 |
| slangasek | you specify your supported archs in /etc/dpkg/dpkg.cfg, then frob /etc/apt/sources.list if needed | 20:18 |
| slangasek | no magic for archive/ports | 20:18 |
| slangasek | if we were going to do that, I would want that to be in a front-end for managing sources.list, not in apt itself | 20:19 |
| infinity | buildds need no knowledge of this, at least in this use case. | 20:19 |
| infinity | openhackware-whatever is a binary dependency of qemu, not a build-dep. | 20:19 |
| slangasek | but we need to have a policy (and hopefully align with Debian on that policy) about what buildds should be allowed to grab from foreign archs for building | 20:19 |
| slangasek | yeah, if we go that route that's true | 20:20 |
| slangasek | but then the question is, do we allow packages in the archive to have dependencies on $package:$foreignarch | 20:20 |
| infinity | Suggests/recommends, seems sane for certain cases like this. | 20:20 |
| infinity | Would allow us to finally make PALO arch:hppa too. :P | 20:21 |
| slangasek | yep, openhackware is somewhat to the side of the other cases where we're going to need policy | 20:21 |
| slangasek | ultimately I'd like to see multiarch obsolete all our biarch/triarch toolchains | 20:21 |
| slangasek | but the mechanics are TBD | 20:21 |
| infinity | (Though, I find it entertaining that Ubuntu dropped hppa eons ago, and still has PALO in the archive, thanks to the weird arch:all hack) | 20:22 |
| infinity | slangasek: Anyhow, returning to the meat of the discussion, can you think of a legit use-case for needing multi-arch build-depends? | 20:23 |
| slangasek | infinity: if we want to drop gcc-multilib, then... everything that currently build-depends on gcc-multilib :) | 20:23 |
| slangasek | i.e., no more lib32gcc1+lib32gomp1+libc6-dev-i386 pulled in - just libgcc1:i386, libgomp1:i386, libc6-dev:i386 | 20:24 |
| slangasek | might still call the metapackage gcc-multilib, but it would stitch it together differently | 20:25 |
| infinity | Okay, but aren't most of those in existence currently because we don't have multiarch. :P | 20:25 |
| infinity | As in, we need to be able to do cross-arch builds specifically to produce those packages. | 20:25 |
| infinity | s/don't/didn't/ | 20:26 |
| infinity | This netbook doesn't have deb-src lines. Hrm. I should get me a Sources.gz | 20:26 |
| slangasek | so you're saying we should drop the out-of-the-box support for building 32-bit code on 64-bit installs? Sounds to me like a regression for users | 20:27 |
| infinity | But yeah, from what I recall, gcc-multilib kinda existed to be able to produce those icky pseudo-multiarch packages on non-native builds. That use-case goes away with multi-arch, where all builds can be native again. | 20:27 |
| infinity | No? | 20:27 |
| slangasek | if we enable i386 multiarch by default on amd64, sure, we probably don't need it for the archive anymore; we still have to sort through if that's sane in all cases; but that still doesn't help users who want to do 32-bit compiles with gcc -m32 | 20:28 |
| infinity | Oh, hrm. gcc -m32 will still insist on lib32 madness? | 20:28 |
| infinity | Can't that just be... Fixed? | 20:28 |
| slangasek | packages currently shipping 32-bit code in amd64 packages include such things as fakeroot, mknbi, mkvmlinuz, valgrind | 20:28 |
| slangasek | fixed> to do that we have to decide we're going to allow it to depend on :i386 packages | 20:29 |
| infinity | I mean, I'm not saying this will all resolve itself in 6-12 months, but I had assumed multiarch would, ultimately, make all this non-native binaries in native packages mess go away. | 20:29 |
| slangasek | well, it might - but is it better to get rid of the biarch lib packages as a first step along that path? | 20:30 |
| infinity | And yeah, I would find allowing gcc to depend on libc6:i386 to be less disgusting that having it depend on libc6-i386_amd64.deb which, suprise, isn't an amd64 deb at all! | 20:30 |
| slangasek | sure - but once we allow such a dep, do people start abusing the facility | 20:30 |
| infinity | Probably. That's why we have policy. And fascist ftpmasters. | 20:30 |
| infinity | So, yes, a discussion about what that policy should be would be worth getting into. | 20:31 |
| slangasek | :) | 20:31 |
| infinity | Though, to be fair, I'm not sure I see too many abuse vectors, except for the guy who thinks that having a "firefox32" metapackage that just depends on "firefox:i386" is a good idea. And that's easily noticed and wrist-slapped. | 20:32 |
| slangasek | a large part of it might just be "how do we make sure the buildds do what we meant when resolving build-deps/deps" | 20:33 |
| slangasek | oh I couldn't find the flex you asked for so here's one for mipsel, hope that's ok | 20:34 |
| infinity | Is that how apt deals with it? | 20:34 |
| slangasek | if you enable mipsel in your multiarch config, and you don't specify which arch you want the package for, and you don't have pinning in place that prevents it, yeah | 20:35 |
| infinity | But it would be simple enough to make sbuild more pedantic. It (still) doesn't use apt's resolver for initial build-dep parsing. | 20:35 |
| infinity | And there's also pinning, yes. | 20:35 |
| infinity | Combine a non-auto pin for !native with explicit requests for package:arch as found in build-deps, and you should probably get the behaviour you wanted. | 20:36 |
| slangasek | yep, could be | 20:37 |
| infinity | (Although, I would be inclined to argue, perhaps, that the non-auto pin priority for non-native should actually be the baked-in default in apt...) | 20:39 |
| infinity | Much like the special-casing for experimental. | 20:39 |
| infinity | Any explicit request, whether a manual "apt-get install foo:arch" or a binary dependency on foo:arch would override that pin, but I think accidentally fulfilling a package request with a non-native one just feels... Wrong. | 20:40 |
| slangasek | how do you think that should work for the nspluginwrapper package here, then? https://launchpad.net/~vorlon/+archive/multiarch/+packages | 20:40 |
| slangasek | ah, you would want nspluginwrapper Depends: nspluginviewer:i386 | 20:41 |
| slangasek | could work | 20:42 |
| slangasek | I don't think the :i386 syntax has been implemented yet, but that's a minor concern | 20:42 |
| infinity | slangasek: Yeah, that would be what seems most sane to me. | 20:42 |
| infinity | slangasek: Cause that is explicitely saying "I want the i386 version of this", not "fulfill with whatever you happen to find". | 20:43 |
| * slangasek nods | 20:43 | |
| infinity | Granted, in the grand scheme of multiarch utopia, where the developer might not know that my s390 system can execute alpha code, but nothing else, I guess there's an argument for the auto-fallback. | 20:44 |
| infinity | Meh. | 20:44 |
| infinity | Oh course, as the owner of that bizarre s390/alpha setup, I'm not sure I'd expect much sympathy from defaults, and could fiddle with stuff myself. :P | 20:45 |
| infinity | And I suspect the nspluginviewer case is going to be the norm anyway. You generally want multiarch because binary X only works on foo, not because it's built for 5 architectures, but not your own. | 20:46 |
| infinity | (I do still expect the uber-nerds to have a system with various binfmt hooks to run 8 or 9 architectures on one, just cause they can) | 20:47 |
| slangasek | what, you mean like qemu-user-static+binfmt-support gives you out of the box? :) | 20:48 |
| infinity | Hey, I'm old skool. Last time I did it, I had to do it by hand. :P | 20:48 |
| infinity | Well, there's our buildd solution right there. Just build enormous amd64 machines, install every toolchain for every arch, and qemu-user-static. | 20:52 |
| infinity | Oh, and then audit the archive and fix the 20,000 packages that call "gcc" instead of gcc-linux-$arch | 20:53 |
| infinity | HTH. | 20:53 |
| slangasek | thbbt :) | 20:58 |
| infinity | None of this fixes openbios-sparc on Ubuntu, mind you. The only two possible solutions at this point are "drop it from the archive" or "build it on Debian and massage it in with blinders on", cause Ubuntu's multiarch can't support architectures we don't ship. | 20:58 |
| infinity | There's value in option 2, since you might still want a sparc VM on an Ubuntu machine. It's icky, though. | 20:59 |
| infinity | (Though that same icky solution is how we have palo in the archive by accident, it was built on the Debian uploader's machine and synced) | 21:00 |
| infinity | slangasek: Err, looking at your multi-arch PPA... Why would the arch:all ca-certificates need a Multi-Arch: foreign stanza? | 21:14 |
| infinity | slangasek: Doesn't arch:all sort of imply the same thing that MA:foreign specifies? | 21:15 |
| slangasek | infinity: because of arch:all packages like python | 21:15 |
| slangasek | i.e., arch-specific dependencies masked by an arch:all metapackage | 21:16 |
| slangasek | the only way to be reliably backwards-compatible with existing packages is to require M-A: foreign for arch: all as well | 21:16 |
| infinity | slangasek: So, that means that (nearly) all arch:all packages need MA:foreign? | 21:17 |
| slangasek | if we care enough to add it, probably | 21:17 |
| infinity | slangasek: Except for those metapackage-to-pull-in-native-package cases... | 21:17 |
| slangasek | but it's really only interesting for packages that are arch: all and have libs as revdeps | 21:17 |
| slangasek | infinity: round-one spec is here, fwiw: https://wiki.ubuntu.com/MultiarchSpec | 21:19 |
| infinity | slangasek: That's what I was reading to figure out what MA:foreign meant before I asked about the redundancy. :P | 21:22 |
| slangasek | ah, buried in there somewhere is the explanation of MA:foreign+arch:all | 21:22 |
| lifeless | pitti: yo | 21:24 |
| infinity | slangasek: Ahh, I see the note about why arch:all needs the foreign, except... I still don't buy it. :P | 21:26 |
| infinity | Oh, wait. I was thinking at the apt level, not the dpkg level. | 21:26 |
| infinity | "To avoid breaking this assumption, Architecture: all packages will, at least initially, be treated as equivalent to packages of the native architecture for all dependency resolution." | 21:27 |
| infinity | I read that to mean "since the arch:all package exists in Packages.gz for all your architectures, you still win", but it literally means "all occurences of foo_all.deb will internally be treated as foo_native.deb", doesn't it? | 21:27 |
| slangasek | yes | 21:28 |
| infinity | Yeah, fair enough. Seems like an odd way to do it, mind you, since it would be trivial at the higher (ie: apt and friends) level to feed it to dpkg as non-native. But that breaks the "dpkg -i *deb" use-case. | 21:29 |
| infinity | So, I suppose I understand why you specced it that way. Just looks like a lot of busy-work to make all the legitimately arch:all packages have the new stanza. | 21:29 |
| infinity | slangasek: Oh, we still haven't gotten to the co-installable headers stage yet? We might be slightly premature in discussing buildd impact, then. :P | 21:36 |
| * infinity is wishing he hadn't missed the last year of discussion on this. | 21:39 | |
| slangasek | infinity: linux-libc-dev is coinstallable in the archive; discussions on debian-policy; that spec is based on a two-year-old UDS session, I've not been updating it for topics that were deemed out of scope at the time | 21:54 |
| slangasek | libc6-dev is not coinstallable in the archive solely because some packages get upset when they can't find crt*.o in /usr/lib | 21:55 |
| infinity | slangasek: Oh. You're going to make me read -policy to catch up with the current state of things? Well, at least it's not -legal... | 21:55 |
| slangasek | heh | 21:55 |
| infinity | slangasek: What gets grumpy about crt*.o? And could that be temporarily worked around with an arch:all (oh hey, look, a weird use-case for all being considered native-only) package that ships symlinks? :P | 21:56 |
| infinity | Or, rather, creates symlinks. Shipping wouldn't work. | 21:57 |
| infinity | But whatever. | 21:57 |
| slangasek | emacs got grumpy. We didn't look farther - already in feature freeze at that point and it was an unintended side-effect, so rolling back was considered Prudent | 21:57 |
| slangasek | we can tackle that again soon enough in oneiric | 21:57 |
| infinity | And yeah. Agreed. Trying to do this sort of thing on a 6-month release schedule has its drawbacks. | 21:57 |
| infinity | (Side note: is anyone expected to be able to successfully type oneiric with reasonable frequency?) | 21:58 |
| * slangasek shrugs :) | 21:58 | |
| infinity | Maybe I'll get one of those gamer keyboards, so I can macro it. | 21:58 |
| lifeless | one^Xl | 21:59 |
| arand | infinity: I've adopted "oo" as the name to use for this cycle.. | 22:02 |
| === skaet is now known as skaet_afk | ||
| === skaet_afk is now known as skaet_ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!