=== robbiew is now known as robbiew_
=== tomreyn_ is now known as tomreyn
bdmurraykirkland: could passwd somehow warn about bug 579876?00:14
ubottuLaunchpad 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/57987600:14
kirklandbdmurray: would take some pam hackery, should probably talk to slangasek00:15
kirklandbdmurray: i could probably make pam_ecryptfs say something00:15
bdmurraythat seems nicer than hoping people find an answer in Launchpad00:15
slangasekdoes pam_ecryptfs stack before or after pam_{unix,krb5,fwibble} for password changes?00:15
* kirkland checks00:16
kirklandslangasek: that's common-password?00:16
kirklandslangasek: ecryptfs is last00:16
slangasekhmm, ok00:17
kirklandslangasek: if old password is empty, i was thinking i could throw a warning message00:17
slangasekand how's it marked?  optional, requisite, etc?00:17
kirklandpassword        optional        pam_ecryptfs.so00:17
slangasekyeah, I'm thinking you could downright abort the stack instead, if you wanted :)00:17
kirklandslangasek: i deliberately did not, in the beginning00:18
kirklandslangasek: more and more people are complaining about this00:18
slangasekwell, I guess giving no option for root to change the password would get a different set of people complaining00:21
slangaseka prompt that has to be explicitly acked might be the best00:22
slangasekso 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
kirklandslangasek: correct00:28
slangasekshould it?00:28
=== yofel_ is now known as yofel
CardinalFangHi 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
CardinalFangThe 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
jcastrokees: can you add ~hughhalf to ~uds-planners?01:12
CardinalFangI 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/76023601:20
ubottuUbuntu bug 760236 in desktopcouch (Ubuntu) "desktopcouch answers DBus before plugins are completed" [High,In progress]01:20
CardinalFangsmoser, 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
kenvandineCardinalFang, i'll look01:55
dtiguehey 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 be02:09
kenvandineCardinalFang, sponsored02:13
soreauHey 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
soreauSorry, did I miss a response?02:25
dtiguei know you can remove the kernals not needed in synaptic02:26
soreauYes but that gets old after awhile02:26
soreauIn specific, I'm looking for a one-liner that automatically removes all but the currently running kernel02:26
soreauOr even a gui way to automatically do it02:27
soreauI'm thinking maybe there's some clever way to do it with aptitude or apt-get02:29
dtigueim sure there is but i dont know it02:29
ionRemove linux packages from aptitude’s “don’t autoremove” patterns.02:31
soreauion: How can you do that?02:31
ionAptitude settings02:31
CardinalFangkenvandine, thank you, sir!02:31
soreauion: How to get to aptitude settings02:32
Sarvattsoreau: /etc/apt/apt.conf.d/01autoremove02:32
soreauAh ok02:32
kenvandineCardinalFang, np02:33
soreauSarvatt: 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 remove02:38
soreauIs there a special command needed to make it recognize the change?02:39
Sarvattit'll just affect future upgrades02:39
dtigueso has anyone else seen the top panel go to a light grey color after updating to beta 2??02:40
soreauSarvatt: Well that's not exactly what I needed :P02:40
CardinalFangsoreau, do you have "linux-image-generic" installed?02:40
CardinalFangsoreau, if so, this should do it:  $ dpkg -l linux-image-[0-9]\* |egrep ^ii |while read status pkg cdr; do sudo dpkg -P $pkg; done02:41
CardinalFangThe most recent, a dependency of a metapackage, will fail to be uninstalled.02:42
soreauCardinalFang: 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 work02:50
soreauor hmm.. maybe it did02:51
soreauWhat does 'pi' mean in dpkg -l output?02:52
soreauthe output from the command said it wasn't removing any header packages due to dependency problems02:53
soreaudpkg: 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
soreauall say the same02:55
ionYou don't want to use dpkg like that. Use aptitude instead. It'll handle dependencies.02:58
soreauion: How though?02:58
soreaudpkg man page doesn't even tell what 'rc' 'ii' 'pi' etc mean02:59
CardinalFangsoreau, it's in the header of the output.02:59
soreauCardinalFang: That's not too intuitive because 1) most times you're grepping dpkg -l and 2) the terminal default is only 200 lines scrollback03:01
soreauand 3) it doesn't explicitly explain what the letters mean03:01
CardinalFangsoreau, I'm just telling you where you can find what "pi" means.  Purge wanted.  Now Installed.03:01
soreauAh ok03:01
soreauSo the package manager took note the packages were attempted to be removed03:02
soreauSo how can I remove header and header-generic packages too03:02
soreauAh hm03:05
soreauThis 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
soreauHmm, seems to remove headers for currently running kernel too03:09
soreauWell hm03:13
soreauIf there is a 'pi' package, how to make it go back to 'ii'?03:13
soreauSeems a simple reinstall does the trick03:15
SMG1hello, 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
SMG1hello, anyone04:24
holsteinSMG1: is that a support question?04:25
=== dendro-afk is now known as dendrobates
holsteinyou can try #ubuntu like the topic suggests04:27
holsteinor #ubuntu+1 for 11.0404:27
holsteinor #ubuntu-beginners if those are too busy or too slow04:27
=== gerard0 is now known as javamaniac
=== javamaniac is now known as gerard0
ohsixsmoser: 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 done06:32
ohsixsmoser: no technical justification or anything has been made for its removal (btw, it's proxy support for transmission)06:33
ohsixsmoser: or can transmission be pinned back to 2.1106:50
ohsixman 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
keesjcastro: added!07:37
ohsixhttps://bugs.launchpad.net/ubuntu/+source/evince/+bug/651931 does this need an SRU to get into natty?08:37
ubottuUbuntu bug 651931 in evince (Ubuntu) "evince crashed with SIGSEGV in clear_job_selection()" [Medium,Fix committed]08:37
ohsixhttps://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
ubottuUbuntu bug 629258 in DeviceKit-Power "Battery life estimation never comes around" [Medium,In progress]08:39
bradmohsix: my laptop has had that estimating battery bug for a while :-/08:59
ohsixits pretty clear cut if you drill down in the bug09:00
ohsixchech 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 number09:01
bradmwould make sense to remove the "estimating" if it can't do it anymore, I guess09:02
ohsixwell if the estimao\tor was back in there for batteries without rate readings then the battery historty would be stored/calculated as normal09:04
ohsixand i think i saw it mentioned that there used to be an interpolator in upower too but it was never used09:06
ohsixthe battery applet doing statistics should work without the data present tho, so it doesn't compound the error09:06
=== akshatj_ is now known as akshatj
bdrungdoko_: i finally fixed lintian (now tested on i386 too)11:02
=== doko_ is now known as doko
TapisIs 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
sladenTapis: https://help.ubuntu.com/community/LiveCDCustomization  FSVO "easy"14:18
sladenTapis: basically unpack the CD, replace the kernel packages, re-pack14:18
sladenTapis: (the kernel for the LiveCD is stored outside of the Squashfs IIRC14:19
Tapisi 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
Tapisso, 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
dobeyTapis: 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
Tapisdobey: 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 Kernel15:08
Tapisdobey: 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 complete15:11
sladenTapis: https://help.ubuntu.com/community/LiveCDCustomization15:16
sladenTapis: mount -o loop image.iso .../somewhere15:16
sladenTapis: cd .../somewhere && do_stuff_like_replace_the_kernel15:17
Tapisyes, 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
dobeywell 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 page15:19
dobeyrebuilding the live image isn't as easy as copying the .deb over, modifying the manifest, and repacking the .iso15:20
dobeybut it's doable, and i'm sure the wiki pages will point you in the right direction15:20
Tapisok 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 .iso15:22
sladenTapis: ------>  https://help.ubuntu.com/community/LiveCDCustomization  <-----15:22
Tapisanyway, thanks dobey and sladen for the help, i'm going to RTFM and try to do this15:22
sladenTapis: if you're wanting to change the boot kernel, but not the installed kernel, it's  in /install/vmlinuz  on the CD15:23
Tapissladen: ok, i've already find this, well...if this way works, it's perfect ! :)15:24
sladenTapis: 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*.deb15:24
Tapissladen: no, i don't care about the installed kernel, i can do this later, i just want to replace the "booted kernel"15:26
sladenTapis: 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 .iso15:26
Tapisthanks again sladen and dobey15:27
Tapisbye everyone15:27
ScottKmdz: There are four josm uploads in the queue are they all the same?15:40
ScottKmdz: Unping.  Accepted.17:09
hyperairjcastro: ping. do you know who i can direct my complaints about paste.ubuntu.com to?17:11
hyperairs/complaints/bug reports/17:11
LLStarksis there any chance the apt-sync/delta-deb proposal will actually be mentioned at uds-o?18:23
soreauHey 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
mdzScottK, yes, sorry for the noise19:38
mdzScottK, 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
ScottKmdz: Yes.  It's an LP bug that they are aware of.19:39
ScottKlifeless: ^^^19:39
ScottKApparently Soyuze and the Ubuntu keyserver aren't always on speaking terms.19:40
mdzScottK, thanks for accepting the fix19:40
ScottKNo problem.19:40
infinity(Both the bug, and spelling Soyuz with an 'e'...)19:41
ScottKI know how to spell it, just not how to type.19:44
infinityScottK: I probably should get a t-shirt made up with that on it.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
infinityMaybe I should just fix soyuz instead of looking for packages to fix.19:57
slangasekinfinity: want to teach soyuz to have a policy for multiarch build-dependencies? :)20:09
infinityslangasek: Oh?20:11
infinityslangasek: Elaborate?20:11
slangasekinfinity: well, if someone could fix it so those qemu firmware packages no longer had to be arch: all, that would solve the problem20:11
infinityslangasek: Err, but multiarch only helps you there if you can actually emulate the arch on another.20:12
slangasekalthough 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 soyuz20:13
infinityslangasek: Can i386 actually build ppc and sparc binaries in the current state of the world?20:13
slangasekinfinity: not at all - I was suggesting that you make openbios-sparc an Architecture: sparc package, and have qemu depend/recommend/whatever openbios-sparc:sparc20:14
infinityslangasek: 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
slangasekoh, but we don't have sparc in the archive anymore, so I guess that wouldn't work, hmm20:14
infinityslangasek: Oh.  THAT solution is entirely packaging toolchain.  Done.20:14
infinityslangasek: (Except for that)20:15
slangasekwe do have an armel cross-toolchain in the archive these days; could do the same for powerpc and sparc I guess20:15
slangasekexcept that I was hoping we'd soon be able to convert that toolchain over to use multiarch instead of rebuilding libs :)20:15
infinityOh, yeah, sparc's completely gone now.  That bug should just be closed then.20:16
infinityGiven that we insist on building from source at SOME point in the process, we really can't maintain a sparc binary...20:16
slangasekmight still be the preferred solution for powerpc though20:17
infinityFor PPC, the multi-arch thing sounds clever, but how does that work at the apt level?  I haven't looked.20:18
infinityDoes it just do magic to find other arches, or do you need to specify them in sources.list?20:18
slangasekwell, 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
infinityAnd if the former, does Ubuntu's apt have extra magic on top of the magic to deal with archive/ports?20:18
slangasekyou specify your supported archs in /etc/dpkg/dpkg.cfg, then frob /etc/apt/sources.list if needed20:18
slangasekno magic for archive/ports20:18
slangasekif we were going to do that, I would want that to be in a front-end for managing sources.list, not in apt itself20:19
infinitybuildds need no knowledge of this, at least in this use case.20:19
infinityopenhackware-whatever is a binary dependency of qemu, not a build-dep.20:19
slangasekbut 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 building20:19
slangasekyeah, if we go that route that's true20:20
slangasekbut then the question is, do we allow packages in the archive to have dependencies on $package:$foreignarch20:20
infinitySuggests/recommends, seems sane for certain cases like this.20:20
infinityWould allow us to finally make PALO arch:hppa too. :P20:21
slangasekyep, openhackware is somewhat to the side of the other cases where we're going to need policy20:21
slangasekultimately I'd like to see multiarch obsolete all our biarch/triarch toolchains20:21
slangasekbut the mechanics are TBD20: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
infinityslangasek: Anyhow, returning to the meat of the discussion, can you think of a legit use-case for needing multi-arch build-depends?20:23
slangasekinfinity: if we want to drop gcc-multilib, then... everything that currently build-depends on gcc-multilib :)20:23
slangaseki.e., no more lib32gcc1+lib32gomp1+libc6-dev-i386 pulled in - just libgcc1:i386, libgomp1:i386, libc6-dev:i38620:24
slangasekmight still call the metapackage gcc-multilib, but it would stitch it together differently20:25
infinityOkay, but aren't most of those in existence currently because we don't have multiarch. :P20:25
infinityAs in, we need to be able to do cross-arch builds specifically to produce those packages.20:25
infinityThis netbook doesn't have deb-src lines.  Hrm.  I should get me a Sources.gz20:26
slangasekso 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 users20:27
infinityBut 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
slangasekif 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 -m3220:28
infinityOh, hrm.  gcc -m32 will still insist on lib32 madness?20:28
infinityCan't that just be... Fixed?20:28
slangasekpackages currently shipping 32-bit code in amd64 packages include such things as fakeroot, mknbi, mkvmlinuz, valgrind20:28
slangasekfixed> to do that we have to decide we're going to allow it to depend on :i386 packages20:29
infinityI 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
slangasekwell, it might - but is it better to get rid of the biarch lib packages as a first step along that path?20:30
infinityAnd 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
slangaseksure - but once we allow such a dep, do people start abusing the facility20:30
infinityProbably.  That's why we have policy.  And fascist ftpmasters.20:30
infinitySo, yes, a discussion about what that policy should be would be worth getting into.20:31
infinityThough, 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
slangaseka 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
slangasekoh I couldn't find the flex you asked for so here's one for mipsel, hope that's ok20:34
infinityIs that how apt deals with it?20:34
slangasekif 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, yeah20:35
infinityBut 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
infinityAnd there's also pinning, yes.20:35
infinityCombine 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
slangasekyep, could be20: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
infinityMuch like the special-casing for experimental.20:39
infinityAny 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
slangasekhow do you think that should work for the nspluginwrapper package here, then?  https://launchpad.net/~vorlon/+archive/multiarch/+packages20:40
slangasekah, you would want nspluginwrapper Depends: nspluginviewer:i38620:41
slangasekcould work20:42
slangasekI don't think the :i386 syntax has been implemented yet, but that's a minor concern20:42
infinityslangasek: Yeah, that would be what seems most sane to me.20:42
infinityslangasek: Cause that is explicitely saying "I want the i386 version of this", not "fulfill with whatever you happen to find".20:43
* slangasek nods20:43
infinityGranted, 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
infinityOh 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. :P20:45
infinityAnd 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
slangasekwhat, you mean like qemu-user-static+binfmt-support gives you out of the box? :)20:48
infinityHey, I'm old skool.  Last time I did it, I had to do it by hand. :P20:48
infinityWell, there's our buildd solution right there.  Just build enormous amd64 machines, install every toolchain for every arch, and qemu-user-static.20:52
infinityOh, and then audit the archive and fix the 20,000 packages that call "gcc" instead of gcc-linux-$arch20:53
slangasekthbbt :)20:58
infinityNone 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
infinityThere'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
infinityslangasek: Err, looking at your multi-arch PPA... Why would the arch:all ca-certificates need a Multi-Arch: foreign stanza?21:14
infinityslangasek: Doesn't arch:all sort of imply the same thing that MA:foreign specifies?21:15
slangasekinfinity: because of arch:all packages like python21:15
slangaseki.e., arch-specific dependencies masked by an arch:all metapackage21:16
slangasekthe only way to be reliably backwards-compatible with existing packages is to require M-A: foreign for arch: all as well21:16
infinityslangasek: So, that means that (nearly) all arch:all packages need MA:foreign?21:17
slangasekif we care enough to add it, probably21:17
infinityslangasek: Except for those metapackage-to-pull-in-native-package cases...21:17
slangasekbut it's really only interesting for packages that are arch: all and have libs as revdeps21:17
slangasekinfinity: round-one spec is here, fwiw: https://wiki.ubuntu.com/MultiarchSpec21:19
infinityslangasek: That's what I was reading to figure out what MA:foreign meant before I asked about the redundancy. :P21:22
slangasekah, buried in there somewhere is the explanation of MA:foreign+arch:all21:22
lifelesspitti: yo21:24
infinityslangasek: Ahh, I see the note about why arch:all needs the foreign, except... I still don't buy it. :P21:26
infinityOh, 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
infinityI 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
infinityYeah, 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
infinitySo, 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
infinityslangasek: Oh, we still haven't gotten to the co-installable headers stage yet?  We might be slightly premature in discussing buildd impact, then. :P21:36
* infinity is wishing he hadn't missed the last year of discussion on this.21:39
slangasekinfinity: 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 time21:54
slangaseklibc6-dev is not coinstallable in the archive solely because some packages get upset when they can't find crt*.o in /usr/lib21:55
infinityslangasek: 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
infinityslangasek: 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? :P21:56
infinityOr, rather, creates symlinks.  Shipping wouldn't work.21:57
infinityBut whatever.21:57
slangasekemacs 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 Prudent21:57
slangasekwe can tackle that again soon enough in oneiric21:57
infinityAnd 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
infinityMaybe I'll get one of those gamer keyboards, so I can macro it.21:58
arandinfinity: 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!