[01:31] <nanley> Hello World! Is it safe to upgrade the hardy kernel to 2.6.24?
[01:31] <ScottK> nanley: If you want safe, don't run Hardy.
[01:31] <nanley> lol
[01:31] <nanley> point taken
[01:31]  * ScottK is not kidding.
[01:32] <nanley> well, safe as in the kernel is the same one that will be in alpha 2?
[01:32] <nanley> or something ready for testing
[01:37]  * ScottK doesn't know (not running it), but since a lot of kernel stuff is hardware specific, even if I said it worked for me, I don't know what that would really tell you.
[01:37] <nanley> alrighty =]
[04:21]  * Hobbsee stabs add & remove programs
[04:21] <Hobbsee> and apport fails too.  hurrah
[04:26] <jdong> Hobbsee: but does apport handle its own crashes? :)
[04:28] <minghua> If it doesn't crash repeatedly, maybe it will.
[04:28] <wasabi> weird apt-get problem.... dpkg is hanging around defunct for ages after each package.... apt-get is blocking on read(18, ), which is /dev/ptmx
[05:14] <TheMuso> 0So far, only 8 packages have FTBFS, which is a good sign.
[05:16] <Hobbsee> surely there should be 0 FTBFS packages?
[05:22] <TheMuso> Hobbsee: You would hope so, but I haven't investigated the exact reasons yet. I'll get as many cleared as ok building and uploaded as I can, then fix up those that FTBFS.
[05:49] <slomo> TheMuso: scary how many packages we still have that depend on glib1.2...
[05:49] <StevenK> slomo: They're fighting for buildd attention, I bet
[05:51] <TheMuso> slomo: Yes, there are heaps.
[05:51] <TheMuso> 220 odd source packages that need rebuilding.
[05:51] <slomo> they should just disappear *shrug* :)
[07:33] <MacSlow> greetings everybody!
[07:33] <ion_> Hola
[07:38] <MacSlow> hi mpt
[07:38] <mpt> hello MacSlow
[07:42] <Burgundavia> hey MacSlow, mpt
[07:43] <MacSlow> hi Burgundavia
[07:44] <Burgundavia> how goes facebrowser?
[07:46] <MacSlow> spec is place... now time for research and devel
[07:46] <mpt> MacSlow, I have a question about Visual Effects
[07:46] <mpt> I remember back in the 1990s it was a huge advance when OSes got live resizing for windows
[07:47] <mpt> and with Visual Effects set to "None", windows have live resizing
[07:47] <mpt> but with the more blingy settings, they don't
[07:48] <mpt> Any particular reason for that?
[07:49] <MacSlow> mpt, there was no spec or planning at all for the whole set of settings for compiz-plugins
[07:49] <MacSlow> mpt, I think to remember that some people replied that window-resizing got "terribly slow" for them
[07:49] <mpt> oh, ok
[07:49] <mpt> So live resizing is slower with Compiz than with Metacity?
[07:50] <MacSlow> mpt, the way the compiz-folks "fixed" it was setting it to this rectangle-mode
[07:50] <mpt> I see
[07:50] <MacSlow> mpt, only for some GPUs/drivers
[07:51] <MacSlow> mpt, e.g. on i915 and i965 I don't see the issues
[07:54] <MacSlow> mpt, I'm certain that the issue people complain about regarding live-resizing windows under compiz will be a thing of the past once the new DRI2 and other Xorg-related things are fully implemented.
[07:54] <MacSlow> mpt, it will e.g. also provide "zero copy" texture-from-pixmap
[07:57] <mpt> ok
[08:07] <MacSlow> mpt, there are also some ideas floatint around to speed up live-resize under compiz before those DRI2/Xorg-related pieces are in place... one of them is to allocate larger textures for holding the redirected windows, thus a texture does not have to be reallocated if a window is resized, which in turn speeds up the resizing-process under compiz
[08:07] <MacSlow> hi pitti
[08:09] <lool> Hi MacSlow
[08:09] <pitti> Good morning
[08:09] <pitti> hey MacSlow, hi lool
[08:10] <MacSlow> Salut lool
[08:12] <lool> keescook: Congrats!
[08:20] <sleepster> how do I contribute to the awesome project known as Ubuntu
[08:20] <pochu> sleepster: it depends on what you want to do :) http://www.ubuntu.com/community/participate
[08:22] <dholbach> good morning
[08:23] <gaspa> you too...<ronf>
[08:23] <ion_> good Chuck Norris
[08:24] <gaspa> question: can I invalid a bug, even if i'm not a member of anything in particular?(bugsquad or whatelse...)
[08:26] <sleepster> pochu I want to do everything
[08:27] <sleepster> pochu I want to make this the best dang OS in the WORLD
[08:27] <sleepster> where do I sign up?
[08:28] <pochu> no need to sign up anywhere, just do it ;-)
[08:28] <Fujitsu> gaspa: Yes.
[08:28] <gaspa> Fujitsu: ok, thanks.
[08:30] <dholbach> hey mvo, hey seb128
[08:30] <seb128> good morning Daniel
[08:31] <mvo> hey dholbach!
[08:31] <mvo> hey seb128
[08:32] <sleepster> how do I get involved with a project?
[08:32] <sleepster> I read throught he wiki
[08:32] <sleepster> s/he/the
[08:32] <seb128> mvo: I didn't do the vte merge so if you want to work on it today ;-)
[08:32] <seb128> sleepster: do you mean a project in Ubuntu?
[08:33] <mvo> seb128: sure, I can do it today
[08:34]  * seb128 hugs mvo
[08:37] <pitti> good morning mvo!
[08:40]  * pitti hugs The"♪ I shot the buildd! ♫"Muso
[08:41] <seb128> TheMuso: wouldn't it make sense to use some delay between uploads for such transitions?
[08:42]  * persia wonders why
[08:43] <seb128> persia: why what?
[08:43] <persia> Why delay between uploads for a transition.
[08:43] <seb128> to not overload buildds and let a chance to normal uploads to build
[08:46] <pitti> seb128: well, most of the stuff is universe, so main packages will be built first anyway
[08:47] <seb128> pitti: right but still
[08:47] <pitti> it's more a question of mirror load
[08:47] <seb128> pitti: I though it was good practice to not upload hundred in packages in a row
[08:47] <pitti> right, it still is
[08:48] <pitti> speaking of mirror load, I moved OO.o to gutsy-updates yesterday; the DC will love me, I'm sure
[08:49] <seb128> pitti: do you know if there is any hardy language pack update scheduled?
[08:49] <pitti> seb128: in fact the export was started last week, let me check
[08:49] <pitti> https://translations.edge.launchpad.net/ubuntu/hardy/+language-packs
[08:49] <pitti> nothing yet
[08:50] <seb128> oki
[08:51] <LaserJock> pitti: does language-pack-gnome-*-base get updated in -updates?
[08:52] <pitti> LaserJock: -base is generally stable in a release
[08:52] <pitti> LaserJock: we did a refreshing in dapper because the update packages got too big
[08:52] <pitti> but it's seldom
[08:52] <LaserJock> ok, so if there are updates they should go in language-pack-gnome-* ?
[08:52] <pitti> right
[08:53]  * pitti puts a strawberry and a piece of chocolate on top of bug 163794 for mvo :)
[08:54] <LaserJock> pitti: do they install to the same place? doesn't that create a conflict?
[08:54] <ubotu> Launchpad bug 163794 in tzdata "New timezone data 2007j" [Undecided,Fix committed] https://launchpad.net/bugs/163794
[08:54] <pitti> LaserJock: they do, that's why they Replace: each other
[08:54]  * mvo hugs pitti
[08:54] <LaserJock> ah
[08:55] <LaserJock> pitti: I'm trying to track down why gcompris was not included in the latest lang pack updates
[08:55] <pitti> hm, but it was in the final gutsy ones?
[08:56] <LaserJock> yes
[08:56] <LaserJock> I'm told it's in -base but not in the latest updates
[08:57] <pitti> ./language-pack-gnome-sv/data/sv/LC_MESSAGES/gcompris.po
[08:57] <pitti> hm, that's the only one
[08:57] <pitti> (in -updates)
[08:58]  * pitti does the magic dance to summon carlos
[08:58] <LaserJock> hmm
[08:58] <LaserJock> I gave carlos the .pot and I think he said it should be included in the next update
[08:59] <\sh> keescook, jdstrand : bug #164501 , gutsy fixes attached...ready for review...thx :)
[09:00] <ubotu> Launchpad bug 164501 in wireshark "more security issues with wireshark from 0.99.6 down to ..." [Undecided,In progress] https://launchpad.net/bugs/164501
[09:01] <seb128> pitti: carlos is on holidays for the month I think
[09:06] <TheMuso> seb128, pitti: Point taken. They were done in batches, 5 or so minutes appart, once I had confirmed that the packages had built. I still have more left, and I will make an effort to stagger them moreso from now on.
[09:07] <seb128> TheMuso: well, some minutes will make no difference
[09:09] <TheMuso> seb128: Fair enough, as I said, I'll stagger what I have left moreso than what I tried to do earlier.
[09:09] <seb128> thanks
[09:10] <LaserJock> pitti: well, I guess I'll email the Rosetta admins and make sure we can make the next lang pack update
[09:11] <pitti> LaserJock: right
[09:11] <LaserJock> I'll make sure to check the PPA language-pack-gnome-* earlier ;-)
[09:12] <pitti> speaking of which...
[09:12]  * pitti reenables the dailies
[09:13]  * LaserJock apologizes to upstream again
[09:53] <mvo> pitti: #163794 is done
[09:54]  * pitti hugs mvo
[09:55] <seb128> bug #163794
[09:55] <ubotu> Launchpad bug 163794 in tzdata "New timezone data 2007j" [Undecided,Fix committed] https://launchpad.net/bugs/163794
[10:05] <ogra> pitti, are you caring for the pulse transition ? and are you aware that flash wont work with pulse ?
[10:06] <pitti> ogra: transition> ted will do the remainign desktop bits (which mixers to install by default, etc.)
[10:06] <pitti> ogra: flash> no, I'm not; can you please tell my flash plugin that it isn't supposed to work?
[10:06] <ogra> we'll need libflashsupport if we want to use it as default
[10:06] <pitti> ogra: IOW how do you mean?
[10:07] <kagou> Hi
[10:07] <ogra> pitti, http://www.pulseaudio.org/ticket/43
[10:08] <ogra> there is a lib that fixes the issue, but its very badly packaged upstream and links against lgpl and libssl ... crimsun has a branch linking against tls we should put in the distro https://code.edge.launchpad.net/libflashsupport-pulse
[10:08] <pitti> ogra: doesn't it work for you? flashplugin-nonfree works like a charm for me
[10:08] <ogra> pitti, not on ltsp where we use pulse transport ...
[10:09] <ogra> i'm assuming with pulse as default for the whole desktop the prob will be similar
[10:09] <pitti> ah, then it probably works for me because I don't play anythign over pulse while watching a youtube video, or so
[10:10] <pitti> ogra: can you add that to https://wiki.ubuntu.com/DesktopTeam/Specs/CleanupAudioJumble ?
[10:10] <ogra> i'm not sure, its probably only netwrok transport related (the bug doesnt say much about that))
[10:10] <ogra> yup, adding
[10:10] <ogra> i'll package the lib anyway, just thought i should point you guys to it
[10:10] <pitti> ogra: thanks
[10:11]  * TheMuso is actually looking to use padsp to get espeak using portaudio v19 to work via pulse. Initial testing looks good, but I need to play some more.
[10:11] <TheMuso> ogra: Is setting up LTSP for hardy different to how its done for gutsy et al?
[10:11] <ogra> TheMuso, nope
[10:12] <TheMuso> ogra: Great, thanks.
[10:12] <TheMuso> This release, I *REALLY* want speech for that environment to work.
[10:12] <ogra> TheMuso, sudo apt-get install ltsp-server ltsp-server-standalone && sudo ltsp-build-client
[10:12] <ogra> well, it only needs to use the virtual alsa device we have in the users session ...
[10:12] <TheMuso> ogra: And what needs to happen on the client side?
[10:12] <ogra> nothing
[10:13] <TheMuso> Ok.
[10:13] <ogra> ltsp-build-client sets up everything for you
[10:13] <ogra> the client just needs to PXE or etherboot from the network
[10:13] <TheMuso> Ok thanks.
[10:14]  * TheMuso will obviously have to take down his DHCP server temporarily for this to work, unless theres a way for it to play nice with an existing server
[10:14] <ogra> if i find the time i'll put up a wikipage how to set up a virtualbox thinclient with sound so you can test (indeed its hard to find out if the sound really comes from virtualbox there :) )
[10:14] <TheMuso> ogra: Thats why I'd rather use real hardware.
[10:15] <ogra> yea, me too, but i travel a lot and there virtalbox comes in handy ... ;)
[10:15] <TheMuso> Yep understandable.
[10:15] <ogra> and a thin client in VB doesnt take much (no disk involved)
[10:16] <TheMuso> Yep.
[10:17] <TheMuso> ogra: SO does ltsp set up its own DHCP? If so, can that be disabled and adjusted to use an existing server? I'd rather not take down my home network DHCP server if I can help it.
[10:18] <ogra> yup, it can
[10:18] <TheMuso> Ok thanks.
[10:18] <pitti> ogra: hm, maybe set up the mixer in the VB instance so that it only outputs to the left channel or so? :)
[10:18] <ogra> to make it easier, change my above command to:
[10:19] <ogra> sudo apt-get install ltsp-server  libasound2-plugins ltspfs openssh-server nbd-server && sudo ltsp-build-client :)
[10:19] <ogra> that will avoid dhcpd to be installed at all
[10:20] <ogra> but indeed you need some manual work on the existing dhcp server then
[10:20] <pitti> ogra: but then you certainly have to set up your existing dhcp server to have the tftp?
[10:20] <ogra> no, you only need a next-server directive to point to your ltsp server
[10:20] <ogra> so the clients pull their tftp stuff from there
[10:20] <pitti> oh, handy
[10:21] <TheMuso> ogra: Ok great. What is this virtual alsa device you create, how is it created, and I assume all pulse utilities will see the pulse server anyway and just work?
[10:22] <ogra> thats actually all you need nowadays, since we dont use nfs anymore you dont even need rootpath set :)
[10:22] <Fujitsu> ogra: Oh, much nicer!
[10:22] <Chipzz> ogra: what do you uuse then?
[10:23] <ogra> TheMuso, pulse runs on the client listening for connections from the server ... in the users session we a) set PULSE_SERVER to point to the client on login and b) run asoundconf set-pulseaudio which creates a virtual alsa device for that etwork tunnel ... usually apps only need to make use of this alsa device then
[10:24] <TheMuso> Right.
[10:24] <ogra> Chipzz, nbd+squashfs+unionfs :) imagine a liveCD netbooting :)
[10:24] <Chipzz> oh :)
[10:25] <ogra> th only prob here is that you actually need to reboot all clients if you make changes to the image .... so we keep nfs as an option, but the default is ndb ... which makes ltp booting 10x faster (literally)
[10:25] <ogra> *ltsp
[10:30] <Fujitsu> ogra: nbd == network block device?
[10:32] <ogra> Fujitsu, yep
[10:33] <Fujitsu> I haven't tried LTSP recently... I probably should soon.
[10:33] <ogra> yeah :)
[10:34] <ogra> its just in a massive change though since we make the code ready for fedora upstream ... so things might break along the way to hardy ...
[10:35] <Fujitsu> Is the new stuff in Gutsy?
[10:36] <ogra> yep
[10:38] <soren> Phew.. I think the dpkg merge is done now.
[10:38]  * soren wipes sweat off of his brow
[10:40] <StevenK> Heh
[10:42] <Fujitsu> soren: Yay!
[10:44] <Amaranth> eep
[10:44] <Amaranth> remind me to not upgrade dpkg for a couple days ;)
[10:44]  * pitti hugs soren
[10:44] <pitti> soren: how bad is the remaining diff?
[10:45] <pitti> soren: debian bug #308285 mentions triggers, but doesn't point to iwj's patch
[10:45] <ubotu> Debian bug 308285 in dpkg "Implement triggers to allow running ldconfig" [Wishlist,Open] http://bugs.debian.org/308285
[10:46] <soren> pitti: Not all that bad now. A lot of this merge was formatting changes that I needed to inspect to see if they snuck some other bits in that way.
[10:46] <pitti> (nor in any of the 5 duplicates)
[10:47] <soren> pitti: It's been discussed a bit on the dpkg-dev list. I don't know what the status is, though.
[10:47] <soren> pitti: I honestly don't know what's keeping it back.
[10:49] <pitti> http://www.mail-archive.com/debian-dpkg@lists.debian.org/msg11922.html
[10:49] <pitti> is the start of the thread, ah
[10:50] <soren> Yeah. Don't waste your time reading all of it. :)
[10:51] <soren> It branches off into a discussion about whether git is clever or not. :)
[10:51] <pitti> yeah, I noticed
[10:51] <pitti> but at least the guys are well aware of its existence, and there were a lot of "I want it, too" replies :)
[10:59] <soren> pitti: Right. I was kind of hoping they'd adopt it before I had to do the merge, but no such luck. With my luck, they'll probably upload a new version tomorrow with trigger support. :(
[11:00] <StevenK> ... that doesn't use iwj's implementation
[11:00] <pitti> soren: still better than uploading in half a year :)
[11:00]  * StevenK watches soren run screaming
[11:00] <soren> pitti: point :)
[11:05] <pitti> pedro_: do you have some time today to verify bug 163794? it's rather urgent
[11:05] <ubotu> Launchpad bug 163794 in tzdata "New timezone data 2007j" [Undecided,Fix committed] https://launchpad.net/bugs/163794
[11:06] <pitti> pedro_: sorry, wrong bug; I mean bug 116193
[11:06] <ubotu> Launchpad bug 116193 in tzdata "error upgrading tzdata_2007e to tzdata_2007f" [Medium,Fix committed] https://launchpad.net/bugs/116193
[11:06] <pedro_> pitti: sure i'll do it now
[11:06] <pitti> pedro_: thanks a lot
[11:08] <pedro_> pitti: in the test case it say have a clean feisty and then upgrade to current gutsy updates is that correct?
[11:08] <ogra> ArneGoetje, ping
[11:08] <pitti> pedro_: you don't need to upgrade the entire distro; merely upgrading tzdata to gutsy final or -proposed is sufficient
[11:09] <pitti> pedro_: (i. e. to gutsy final to reproduce the bug, and feisty->gutsy-proposed to check the fix)
[11:09] <pedro_> ok cool
[11:09] <pitti> pedro_: unfortunately feisty->gutsy-final will ruin /etc/timezone, so you have to reconfigure it when reverting to feisty version for the second test
[11:13] <pedro_> pitti: ok, thanks you
[11:25] <geser> pitti: please give-back: urca unison. Thanks.
[11:25] <pitti> geser: done
[11:35] <pedro_> pitti: we're done!
[11:35] <pedro_> verification done
[11:35] <pitti> pedro_: rock, thanks!
[11:36] <pedro_> you're welcome :-)
[11:42]  * Hobbsee waves
[11:43] <soren> Hi, Hobbsee!
[11:43] <Hobbsee> hey soren!  how's it going?
[11:43] <soren> Better now that I (think I) am done merging dpkg.
[11:44] <seb128> hey Hobbsee ;-)
[11:44] <Hobbsee> soren: hah.  how'd you get stuck with it?  TIL principle?
[11:44] <Hobbsee> hey again seb128 :)
[11:44] <soren> Hobbsee: I honestly don't know.
[11:44] <pitti> Hobbsee: that applies from now on :)
[11:44] <Hobbsee> heya pitti!
[11:44] <Hobbsee> pitti: heh
[11:44] <soren> Hobbsee: Ian TIL, but he's not around.
[11:44] <Hobbsee> ahhh
[11:47] <seb128> TheMuso: there is a new at-spi available, it has been uploaded to debian experimental if you want to merge the new version
[11:48] <seb128> TheMuso: the only ubuntu change has been commited to the debian svn too so it'll be syncable after the next update
[11:49] <TheMuso> seb128: I knew about the at-spi release, I'm on gnome-announce now. I filed a bug with the bits needed for upload, but I'll merge with Debian and adjust the bug accordingly.
[11:49] <seb128> TheMuso: ok, thanks
[11:49] <seb128> TheMuso: no need to bother
[11:50] <seb128> TheMuso: if you already did the update I'll sponsor this one, there is no debian change
[11:50] <TheMuso> seb128: Ok.
[11:51] <highvoltage> anyone know who maintains ubuntustats.com?
[11:52] <Hobbsee> oh dear, they're in trouble
[11:53] <Fujitsu> Haha.
[11:58] <elkbuntu> highvoltage, see info in footer at: http://209.85.173.104/search?q=cache:VCatX8TNPdsJ:bugs.ubuntustats.com/+contact+site:ubuntustats.com&hl=en&ct=clnk&cd=1&gl=au&client=firefox-a
[11:58]  * elkbuntu <3's google caching :)
[11:59] <Hobbsee> mvo: any plans to make command-not-found work for zsh?
[11:59] <Hobbsee> (and why doesn't it already?)
[11:59] <dholbach> highvoltage: beuno is here :)
[12:00]  * Hobbsee pokes infinity with a large stick
[12:02]  * Hobbsee hopes for some l-u-m soon
[12:03] <\sh> lol
[12:03]  * Hobbsee would like some wifi
[12:04] <pitti> Riddell: oh, did you NEW the linux binaries?
[12:04] <pitti> Riddell: they FTBFSed on most arches, so I'd rather have rejected them
[12:05] <pitti> (just in case something is wrong in e. g. linux-libc-dev)
[12:08] <Riddell> pitti: mm, which ones?
[12:09] <pitti> seb128: weird, your devhelp upload just seems to work; when I built it locally with that change I got a segfault, which is why I didn't upload it
[12:09] <pitti> Riddell: https://launchpad.net/ubuntu/+source/linux/2.6.24-1.1
[12:09] <seb128> pitti: dunno why you had a segfault, it was working correctly for me so I uploaded
[12:09] <pitti> yeah, and the debs from the archive work fine as well
[12:09] <pitti> *shrug*
[12:10] <Riddell> pitti: I'm pretty sure that wasn't me
[12:10]  * Hobbsee looks innocent
[12:10] <pitti> Riddell: ah, ok
[12:11] <pitti> seb128: "Who always understands what he is doing stays below his capabilities" :)
[12:11] <StevenK> pitti: I prefer the other side of that quote.
[12:11] <seb128> I didn't new linux
[12:12] <Riddell> it was slangasek's archive day before mine, possibly him
[12:12] <pitti> seb128: I alluded to me not understanding the devhelp crash, not NEWing
[12:12] <soren> slangasek has archive days? Which day is that?
[12:12] <pitti> soren: Monday
[12:12] <seb128> you guys have been doing some good job, NEW was empty yesterday evening
[12:12] <Hobbsee> all of 'em
[12:12] <Hobbsee> still is.  gotta upload more crack, i think
[12:12] <soren> pitti: Mithrandir doesn't have archive days, then?
[12:13]  * pitti restrains Hobbsee; it was hard hard work to get it like that :)
[12:13] <pitti> soren: not any more
[12:13] <seb128> pitti: I know, I was just pointing it because I though I might be next on the list of people who could have accepted it ;-)
[12:13]  * Hobbsee tickles pitti
[12:13] <soren> pitti: Ok. I didn't know.
[12:13] <Riddell> seb128: when I have an archive day, I don't stop until the job is done :)
[12:13] <pitti> seb128: it's all GTK's fault anyway, and so is the linux FTBFS!
[12:13] <seb128> doh
[12:13] <mvo> Hobbsee: I don't use zsh, the readme has some hints on how to make it work. yeah, we should do that by default I guess
[12:13] <seb128> ;-)
[12:14] <Riddell> soren: Mithrandir hasn't done regular archive days since mobile started taking all his time, as far as I know
[12:14] <Hobbsee> mvo: right, will look then
[12:14] <pitti> Riddell: http://people.ubuntu.com/~ubuntu-archive/testing/hardy_outdate.txt KTHXBYE :)
[12:14] <soren> Riddell: Oh. I should stop bothering him about that sort of thing then :)
[12:14] <Hobbsee> soren: it's him you want to bug about givebacks
[12:14]  * pitti nudges soren to upload dpkg to resolve some of the depwaits on hardy_outdate.txt
[12:15] <soren> pitti: Dude, that shit is scary.
[12:15] <pitti> soren: (just joking)
[12:16] <Hobbsee> soren: so how about the cdbs merge, for some light relief?
[12:16] <StevenK> "Light"
[12:16] <soren> pitti: I'm pushing it to my ppa in a few minutes.
[12:16] <pitti> Hobbsee: but your long pointy stick is now long enough to reach to the buildd's retry knobs, too
[12:16] <Hobbsee> pitti: indeed :P
[12:16] <Hobbsee> pitti: people seem to know this far too well
[12:16] <pitti> cdbs merge? isn't that mine?
[12:16] <Hobbsee> pitti: did you merge it first for hardy?
[12:17] <pitti> ages ago AFAIK
[12:17] <Hobbsee> oh goody
[12:17] <StevenK> cdbs was like the first thing uploaded after the toolchain
[12:17] <Hobbsee> geser: was supposed to.  *shakes fist*
[12:17] <soren> Hobbsee: I've got plenty of merges on my list already, thank you very much. :)
[12:17] <pitti> http://merges.ubuntu.com/c/cdbs -> 404
[12:17] <Hobbsee> pitti: well, thankyou.  that means i can continue to ignore the idea of cdbs and merging :)
[12:17] <pitti> Hobbsee: it's one of my pet packages and it's rather toolchainish, so it went in very early
[12:18] <Hobbsee> excellent!  next time, i'll make you sponsor the changes :P
[12:18] <Hobbsee> pitti: oh yes, that's right, because i called you out on the changelog.
[12:18] <pitti> Hobbsee: did that happen? I didn't see anything in bzr
[12:18] <Hobbsee> pitti: when did it go in bzr?
[12:18] <DktrKranz> pitti, could you please give-back cdd on hardy?
[12:18]  * Hobbsee did the sponsorship in late feisty
[12:18] <Hobbsee> DktrKranz: i'll do it
[12:19] <Hobbsee> DktrKranz: given back
[12:19] <DktrKranz> Hobbsee, thanks
[12:19] <pitti> Hobbsee: erm, dunno, must be years
[12:19] <Hobbsee> pitti: then there are 2 changes that i have never merged in then, sorry :)
[12:19] <Hobbsee> pitti: does it not have a vcs link, or did i ignore it?
[12:20] <pitti> $ asrc cdbs|grep Bzr
[12:20] <pitti> Vcs-Bzr: https://code.launchpad.net/~ubuntu-core-dev/cdbs/ubuntu
[12:20] <Hobbsee> hmmm
[12:20]  * Hobbsee wonders why she didn't see this
[12:21] <Hobbsee> pitti: why asrc, btw?
[12:21] <soren> pitti: asrc == apt-cache showsrc ?
[12:21] <pitti> right, sorry
[12:21]  * Hobbsee uses showsrc
[12:21]  * pitti believes in Huffmann encoding for often-used aliases
[12:22]  * Hobbsee wonders how long it's going to take before she's learned that the rmadison aliases have changed
[12:22] <StevenK> pitti: Take almost every letter until every person needs to ask what it expands to?
[12:22] <Hobbsee> doesn't help that i occasionally have to do stuff on gutsy, where it's reversed
[12:23] <StevenK> How did rmadison change?
[12:23] <Hobbsee> the default distro
[12:23] <pitti> StevenK: I don't normally paste them in alias form in IRC, was just a mistake
[12:23]  * Hobbsee was using rmadison and urmadison
[12:23] <Hobbsee> you should know, you merged it.
[12:23] <StevenK> I did not.
[12:23] <StevenK> soren did
[12:23] <sladen> I think irssi nick completion does this;  it expands a substr to the most used version of the complete nick.  However, that isn't as predicatable (for the human) as pure maximum prefix expansions
[12:24] <StevenK> I just changed the default distro since cjwatson said it probably should
[12:24] <soren> Hobbsee: Ubuntu was the default already. I just updated rmadison --help to actually show that that was the case.
[12:24] <Hobbsee> StevenK: it's your name on the changelog.  you cant blame soren, i'm afriad.
[12:24] <sladen> and Ctrl-R in bash already gets you more recent, most unique substr completition
[12:24] <Hobbsee>   * Change the default URL parameter of rmadison to be ubuntu. The old
[12:24] <Hobbsee>     behaviour can be used by 'rmadison -u debian'.
[12:24] <Hobbsee>  -- Steve Kowalik <stevenk@ubuntu.com>  Sun, 11 Nov 2007 08:14:51 +1100
[12:25] <soren> Hobbsee: Oh, it's that recent? I thought I had gone mad!
[12:25] <StevenK> Bwahaha
[12:25] <sladen> StevenK/cjwatson: if you fixed it, can you mark the bug report as closed... bug #152424
[12:25] <ubotu> Launchpad bug 152424 in devscripts "rmadision should default to 'ubuntu' URL when under Ubuntu." [Wishlist,New] https://launchpad.net/bugs/152424
[12:25] <Hobbsee> soren: it's changed in hardy and gutsy
[12:25] <Hobbsee> er, between hardy and gutsy
[12:25] <Hobbsee> so gutsy uses old behaviour, hardy uses changed.
[12:25] <StevenK> sladen: Aye, thanks
[12:26] <soren> Hobbsee: I see.
[12:26]  * soren curses dholbach for not telling him about listadmin a *long* time ago.
[12:27] <pitti> listadmin FTW!
[12:27] <Hobbsee> soren: *g*
[12:27] <soren> You all knew?
[12:27] <soren> And noone told me?
[12:27] <soren> I hate you all.
[12:27] <StevenK> Right.
[12:27] <Hobbsee> cjwatson: enlightened me when giving me access to ubuntu-devel
[12:27] <StevenK> soren: Kiss kiss
[12:27]  * Hobbsee did u-u-s all by hand though, for ages
[12:27]  * soren feels Hobbsee's pain
[12:27]  * Hobbsee would prefer not to see StevenK and soren kissing, thanks.
[12:27]  * Hobbsee covers eyes
[12:27]  * sladen does u-u-e-n-c-o-d-e- by hand though...
[12:28] <StevenK> Hobbsee: Did what? It was what, one message every two weeks?
[12:28] <Hobbsee> StevenK: before you sanitized the filter
[12:28] <StevenK> Oh on revu
[12:28] <StevenK> Yeah well
[12:28] <StevenK> sladen: bug 152424 nailed shut, thanks
[12:28] <ubotu> Launchpad bug 152424 in devscripts "rmadision should default to 'ubuntu' URL when under Ubuntu." [Wishlist,Fix released] https://launchpad.net/bugs/152424
[12:28] <Treenaks> StevenK: now try jpeg in your head
[12:29] <StevenK> Treenaks: u-u-s, ubuntu-universe-sponsors, smartalec
[12:29] <Treenaks> StevenK: uhr, I meant to say sladen:
[12:29] <Hobbsee> StevenK: just steal his camera.
[12:29] <Treenaks> StevenK: pressed tab too often
[12:30] <Treenaks> Hobbsee: Ha, still scared of that? :)
[12:30] <Hobbsee> Treenaks: cameras are evil!
[12:30]  * soren goes to lunch
[12:30]  * Hobbsee is not photogenic, and therefore hates all cameras.
[12:30]  * StevenK isn't either
[12:30] <Hobbsee> unless, somehow, the sky falls in, and they manage to take decent pictures, whcih don't make me look like i'm on drugs or something.
[12:30] <StevenK> So I switched sides of the camera, I like them better that way
[12:31] <Treenaks> StevenK: why do you think I'm behind the camera :)
[12:32]  * StevenK grins
[12:32] <sladen> StevenK: fixed in 2.10.10ubuntu1, *documented* in 2.10.10ubuntu2  :-P
[12:33] <StevenK> Actually, it was changed in 2.10.10ubuntu2
[12:34] <sladen> maybe the changelog is lying;  I could ask the person who did the update
[12:37] <seb128> TheMuso: could you try to include the LP number in the changelog so the bugs are closed on upload?
[12:37] <seb128> TheMuso: I did sponsor your at-spi and gnome-orca updates, thanks for the work on those
[12:45] <asac> ogra: Re: "certificate exception workflow in ffox 3" ... its now like this: http://people.ubuntu.com/~asac/ogra/
[12:46]  * Hobbsee waves to asac
[12:46] <asac> hi Hobbsee !!
[12:46] <Hobbsee> asac: any chance of getting firefox addons upgraded at some point, so it works with ff3?
[12:47] <ogra> asac, is there a chance to skip shot 3 and 4 ? like it was before ?
[12:47] <asac> ogra: no
[12:48] <asac> ogra: imo it does a good job
[12:48] <asac> ogra: its not just "click through" anymore.
[12:49] <asac> Hobbsee: yes ... I wanted to sort out xulrunner and the gecko embedders first
[12:49] <Hobbsee> asac: ahhh, okay.  cool.
[12:50] <pitti> well, the clicking-through just becomes more lengthy and frustrating now :)
[12:50] <asac> Hobbsee: of course it depends on extension authors supporting ffox 3
[12:51] <Hobbsee> asac: well, of course.  most of them appear to work (more or less) fine when forced.
[12:51] <Hobbsee> the extensions, that is, not the authors.
[12:51] <ogra> asac, id the url prefilled in the dalog ?
[12:51] <ogra> *dialog
[12:51] <asac> ogra: yes
[12:53] <stdin> mvo: ping
[12:54] <ogra> asac, perfect then :)
[12:55] <asac> ogra: good.
[12:56] <asac> pitti: hmmm ... remember that you don't add exceptions every day ... so making it a bit harder isn't that bad on its own. imo this solution does a good job in getting users attention while not getting in their way
[12:56] <pitti> asac: I agree
[12:56] <pitti> asac: the root problem is still that people got used to the fact of bad certificates
[12:57] <pitti> asac: however, I see a huge benefit in making a big fuss if a cert *changes*
[12:58] <pitti> accepting the initial one should be much less painful than overiding an unverifieable changed one
[12:58] <asac> haven't tested what happens in that case
[12:58] <mvo> stdin: hello
[12:58] <stdin> mvo: hi, can you take a look at bug #151005 in compiz for me, it's been bugging kde users for a while
[12:59] <ubotu> Launchpad bug 151005 in compiz "Compiz should use kwin as fallback in KDE" [Low,Confirmed] https://launchpad.net/bugs/151005
[12:59] <Treenaks> pitti: well, sites change keys all the time.. I wouldn't want a pop-up every year for ssl sites I go to often :)
[12:59] <mvo> stdin: oh, yeah - this one. do you want this is gutsy? or only in hardy? are you familar what needs to be done to make compiz work on kde out of the box? I would like to suport kde better, but lack knownledge about it
[12:59] <pitti> Treenaks: well, but you should want it
[13:00] <pitti> Treenaks: sites which don't have a trusted-path SSL key are bad enough, but if they change their key every other day it's completely pointless
[13:00] <Hobbsee> mvo: what do you need to konw?
[13:00] <stdin> mvo: well, for that bug it should work in both, it's just changing the /usr/bin/compiz script to choose kwin if metacity isn't there
[13:01] <mvo> Hobbsee: how to change the default window manager in the kde session for a start :)
[13:01] <stdin> mvo: as for making compiz support kde properly, that's a bit harder :p
[13:01] <pitti> but right now Firefox bothers me everytime with certs I already ack'ed a thousand times; if it would stop doing that and just cry out if it actually changed, that would be a huge improvement IMHO
[13:01] <mvo> stdin: right
[13:01] <Hobbsee> mvo: as in, to default to compiz?
[13:02] <mvo> Hobbsee: yes. I would like to have it so that if you install e.g. compiz-kde (or some other package that is not installed by default) the default kde window manager is compiz
[13:02] <highvoltage> elkbuntu: oh, cool
[13:03] <stdin> making kde choose compiz over kde would involve setting $KDEWM somewhere when startkde is called
[13:03] <stdin> *over kwin
[13:03] <Hobbsee> stdin: does it call it in startkde, or does it call it from kdm?
[13:04] <mvo> odes kdm run startkde?
[13:04] <Hobbsee> wait a sec
[13:04]  * Hobbsee looks at the kde4 versions
[13:04] <Hobbsee> Exec=/usr/lib/kde4/bin/startkde
[13:05] <stdin> Hobbsee: afaik, kdm runs startkde "TryExec=/usr/bin/startkde" /usr/share/xsessions/kde.desktop
[13:05] <Hobbsee> yeah, as above :)
[13:05] <Hobbsee> mvo: right, so yes, it's startkde
[13:06] <mvo> aha, nice. thanks
[13:06] <stdin> we could also check for $KDE_FULL_SESSION in the compiz script to always choose kdm as fallback in kde sessions
[13:07] <Hobbsee> #   For $KDE_FULL_SESSION:
[13:07] <Hobbsee> #     if test -n "$KDE_FULL_SESSION"; then ... whatever
[13:08] <Hobbsee> looks doable
[13:08] <stdin> yep, that's my thinking
[13:08] <Hobbsee> bingo.
[13:08] <Hobbsee> # if the KDEWM environment variable has been set, then it will be used as KDE's
[13:08] <Hobbsee> # window manager instead of kwin.
[13:09] <stdin> the way I did it in the patch was to say if matacity doesn't exist then use kwin, but that ^ is a better approach
[13:09] <Hobbsee> so, there you go, check if compiz does, if it does, export KDEWM in startkde
[13:09] <Hobbsee> otherwise, leave it as is.  problem solved.
[13:10] <Hobbsee> mvo: so we'll have a working compiz in kde by noon?  :)
[13:13] <Hobbsee> stdin: i presume that wouldnt' cover someone who had kde and gnome, where compiz failed.
[13:16] <stdin> Hobbsee: the way my patch from the bug works it chooses kwin if it can't find metacity (not great if you have both and are in a kde session), but if you check for $KDE_FULL_SESSION then you can tell if they are in KDE or not
[13:16] <Hobbsee> stdin: hmmm.  is it guarenteed to be running the full session, whenever starting kde via startkde?
[13:17] <stdin> startkde sets that variable, so if startkde is ran then it'll be set
[13:17] <Hobbsee> right
[13:17] <stdin> if you start kde manually "kwin & kdesktop & kicker..." then you can clean up your own mess :p
[13:18] <Hobbsee> yeah well
[13:18] <Hobbsee> you have to be kinda desperate to do that
[13:29] <Riddell> mvo: you can add export KDEWM at the top of startkde or in /etc/X11/Xsession.d/foo
[14:04] <Hobbsee> totem + hardy != love.
[14:05] <seb128> Hobbsee: why?
[14:07] <ogra> Hobbsee, i dont think thats totems fault .. rather the gstreamer codecs
[14:07]  * ogra has some probs as well with rhythbox here
[14:07] <ogra> rhythmbox
[14:07] <Hobbsee> even with metacity, it occasionally jsut freezes X entirely.
[14:08] <ogra> oh, but i have 270 pending updates ... :)
[14:08]  * ogra updates
[14:08] <Hobbsee> it may well still be -intel, which does have a tendancy to freez
[14:08] <Hobbsee> e
[14:09] <ogra> bah, n-m is a liar ... it were actually 320 packages
[14:09] <ogra> s/n-m/u-m/
[14:15] <soren> ogra: Everything gstreamer related has been broken on my system too. After yesterday's updates, all is back in working order.
[14:15] <ogra> ah, great
[14:16]  * ogra hopes then he can listen to weenradio again after the upgrade :)
[14:16] <soren> ...both alsa and gstreamer got updated, so I didn't know who to hug :)
[14:16] <ogra> this oldie station we ship with RB gets boring over time :)
[14:16] <ogra> "classic rock" sorry :)
[14:17] <soren> Heh :)
[14:17] <ogra> even though it has intresting suggestions for the next canonijam i think :)
[14:17] <soren> Either Exaile or Listen has a fairly long list of stations, some of which are almost half decent.
[14:19] <ogra> ah, well, i'm somewhat stuck to my favorite :) but that usues mp3 streaming exclusively ...
[14:20]  * pitti discovers that hardy's RB now shows magnatune and jamendo music shops
[14:21] <soren> pitti: I've never looked into that. Does it have music you could buy at your local music dealer, or is it more undergroundy kind of stuff?
[14:22]  * ogra discovered that as well today but didnt look through the titles
[14:22] <pitti> soren: nothing in the list looks very familiar to me
[14:22] <pitti> I just browsed through magnatune
[14:22] <ogra> soren, just try it
[14:22] <soren> pitti: That could be both good and bad. :)
[14:22] <pitti> cool, you can just click on it and listen, and if I want I can click the 'buy' button
[14:23] <ogra> oh you can actually listen for free ?
[14:23] <ogra> nice
[14:23] <ogra> i didnt click anything ...
[14:23] <soren> pitti: What does it give you extra if you buy it?
[14:23] <ogra> soren, keep it on your disk ?
[14:23] <pitti> soren: you don't have the "magnatune blabla" ads at the end of each song, apparently
[14:23] <soren> Oh.
[14:23] <pitti> and mental peace, too
[14:24] <pitti> maybe better quality, too, I don't know
[14:24] <pitti> soren: I just tried it for about 60 seconds :)
[14:24] <soren> pitti: That makes you the expert :)
[14:24] <ogra> heh
[14:25] <soren> "Magnatune - We are not evil"
[14:25] <soren> That's reassuring.
[14:25] <pitti> wow, you can select the price yourself
[14:25] <ogra> cool
[14:25]  * pitti discovers some blues/country which actually sounds quite nice
[14:26]  * ogra looks for "canonical all stars" or canonijam ...
[14:26]  * pitti thinks that THIS is a good way to motivate me to spend 10 bucks
[14:26] <ogra> hmm
[14:26] <pitti> ogra: we need to add the Canonical music shop for that :)
[14:26] <ogra> nothing yet ... i guess our marketing didnt have the right idea yet :)
[14:27] <ogra> ah, indeed
[14:27] <ogra> it will become part of shop.ubuntu-com :)
[14:27] <ogra> (lets walk in apples footprints :P )
[14:30] <\sh> pitti, jamendo is doesn't have this advert stuff...and ogg is nice to have :) CC lic music, too
[14:31] <pitti> \sh: I just bought an album from Magnatune, downloading now (I got .ogg, too)
[14:31] <pitti> \sh: right, just browsing that; but it's a different platform
[14:31] <pitti> i. e. distributing free music for promotion instead of selling albums
[14:32] <\sh> pitti, jepp...but it has my favorite songs (jamendo://pornophonique , c64+gameboy+guitar+vocals, germany ... cool stuff...)
[14:34] <pitti> ah, Jamendo has a 'donate to artist' button :)
[14:37] <\sh> pitti, and you will get a "thx for your cheers" from artists too :)
[14:51] <ogra> hmm, thats funny, why did u-m forcefully install nfs-kernel-server during the upgrade just to tell me it will remove it after the upgrade
[14:52] <ogra> grrr ... and leave portmap behind
[15:03] <ogra> gah, apport is noisy on reboots
[15:03] <ogra> asks the same question about 5 times for every app that was open when u-m told me to reboot
[15:07] <geser> Hobbsee: what was I supposed to do?
[15:07] <Hobbsee> geser: merge cdbs, but pitti beat you to it
[15:07] <geser> why should I merge cdbs?
[15:08] <pitti> MoM clearly assigned it to me, so I didn't make any effort of contacting anyone else
[15:08] <geser> Hobbsee: I touched scons but not cdbs
[15:09] <geser> scons is waiting on the next upstream release
[15:09] <Hobbsee> geser: oh, scons.  whoops
[15:09] <Hobbsee> pitti: out of the block of evil packages with similar names....
[15:09] <broonie> scons can be updated now.
[15:09] <pitti> lol
[15:10] <broonie> I got fed up waiting for upstream and dumped a snapshot into debian unstable on Monday.
[15:10] <geser> broonie: is it suitable for a merge or sync?
[15:10] <broonie> Should be.
[15:11] <Hobbsee> pitti: where's the dunce cap?
[15:11]  * Hobbsee can't find it
[15:11] <broonie> It at least resolves the problem with things that use Configure().
[15:11] <Hobbsee> pitti: actually, it was the "list of packages that i don't want to do uploads for again"
[15:11] <Hobbsee> which include things like apt, dpkg, scons, cdbs...
[15:12] <StevenK> Hobbsee: Ah, the "I feel dirty every time I touch this package" list?
[15:12] <Hobbsee> StevenK: that's the one
[15:12]  * StevenK has one of those, too
[15:13] <ogra> uuuh, ff-3.0 now uses the same icon as ff-2.0 ... how confusing if you have them both
[15:13]  * geser will investigate the scons merge and let Hobbsee sponsor it :)
[15:13] <Hobbsee> dream on.
[15:13] <StevenK> geser: If packages are on that list, we don't sponsor them either
[15:13] <Hobbsee> i don't even remember what the original one was - or why i ended up sponsoring it
[15:14] <Hobbsee> geser: or make broonie take the changes if appropriate
[15:16] <broonie> The change you've got is a workaround for an issue which nobody except launchpad buildds is likely to run into.
[15:16] <broonie> I'd rather see a proper fix done upstream for it, TBH.
[16:00] <slangasek> Riddell, pitti: heh, no, I didn't NEW process linux
[16:01] <pitti> slangasek: good morning
[16:01] <slangasek> the only NEW stuff I got through was some KDE universe stuff
[16:01] <slangasek> pitti: morning
[16:01] <pitti> well, not a biggie now, it doesn't matter much except for linux-libc-dev
[16:07] <Riddell> it's a mystery then
[16:25] <wasabi> slangasek, latest samba update broke,    adduser: The user `ISI\jhaltom' does not exist.
[16:25] <wasabi> No idea why it cares about me. ;)
[16:26] <wasabi> Ahh.
[16:26] <wasabi> I see. Ubuntu specific patch.
[16:27] <wasabi> Funny. Since Winbind is stopped when this is running, it can't resolve me. :0
[16:28] <wasabi> Guess a better solution would be to not use adduser... or provide adduser some sort of 'don't check' swithc.
[16:34] <slangasek> wasabi: hrm, which Ubuntu-specific patch?
[16:34] <wasabi> Adding sysadmin to something
[16:34] <wasabi> hold on
[16:34] <slangasek> oh
[16:34] <slangasek> to the sambashare group
[16:34] <cjwatson> pitti: I processed linux once alpha-1 was safely out; I think it's important to get boot testing of the new kernel as soon as possible, even if there are some temporary problems
[16:34] <wasabi> Yeah, that.
[16:34] <cjwatson> since we'd like to be able to make it the default in hardy over the next few days
[16:34] <slangasek> yeah, "don't use adduser" isn't really the right answer AFAICS
[16:35] <wasabi> Sorry, right as I was typing that out I got a phone call. My mind melted.
[16:35] <wasabi> Heh. Something feels totally wrong about killing Winbind in the middle of an upgrade while the user is using his desktop, too.
[16:35] <wasabi> Maybe that should be adjusted so the time winbind is gone is minimized.
[16:36] <wasabi> "You have no name!"
[16:36] <slangasek> well, all the solutions for minimizing the downtime of daemons during upgrade are fairly kludgy wrt maintainer script interaction
[16:37] <wasabi> I really dislike how if the winbind upgrade fails, my desktop becomes unusable. =(
[16:37] <wasabi> Since it's stopped. No new apps can launch.
[16:37] <slangasek> er, that's an odd failure mode?
[16:38] <wasabi> Using nss_winbind. Apps taht try to find ~ don't tend to handle it well when you don't exist.
[16:38] <slangasek> and $HOME isn't set?
[16:38] <wasabi> It's set. Not everything uses it in my experience.
[16:40] <wasabi> Hehe. sudo stops working too, so you can't even fix it.
[16:40] <wasabi> Just saying, Winbind has become a very important member of the running desktop. It should be handled with care.
[16:41] <wasabi> Much like dbus.
[16:43] <soren> Not using adduser doesn't smell right to me either, but a --force-something option might make sense.
[16:43] <wasabi> I might be tempted to argue that winbind should not be restarted.
[16:43] <wasabi> And should in fact be treated like dbus
[16:43] <slangasek> I would disagree strenuously with any attempt to argue that
[16:43] <wasabi> Oh?
[16:43] <slangasek> though I might be voted down
[16:44] <soren> slangasek: Which part? Not restarting winbind or adding the --force option?
[16:44] <slangasek> well, I don't even think it's right to pass on restarting dbus
[16:44] <slangasek> soren: the not restarting
[16:44] <soren> slangasek: Ah.
[16:44] <wasabi> I don't really either. It'd be better if it could be safely restarted like upstart.
[16:44] <wasabi> But it can't, can it?
[16:44] <slangasek> if "safe" means "must never fail to restart", then no, nothing is safe ;)
[16:45] <wasabi> Sure. What I mean is that even during normal operation, a stopped winbind is bad.
[16:45] <wasabi> During the time of the preinst and postinst is even bad.
[16:45] <soren> Upgrading dbus displays the "please reboot your system" notification.
[16:45] <wasabi> Yup.
[16:46] <slangasek> and if the logged-in user isn't resolved via winbind, that's an unnecessary delay of the restart
[16:46] <soren> I definitely thinkg winbind should be restarted.
[16:46] <wasabi> Well, then what's the solution to keeping desktops runnign? =/
[16:46] <soren> (how did that 'g' sneak in there?)
[16:47] <slangasek> wasabi: "assume any package upgrade may be disruptive"? hmm, perhaps I'm not on the same page with the rest of the Ubuntu team yet... :-)
[16:48] <soren> wasabi: winbind is different from dbus in that dbus keeps connections open and various stuff breaks if that connection disappears.
[16:48] <soren> wasabi: A winbind not running "just" means that while it's not running, things are... interesting.
[16:48] <soren> wasabi: everything gets back to normal, when it comes back.
[16:48] <wasabi> slangasek, Heh. Well, as long as the system actually presents the user with an option to upgrade, prompting it non stop with little pops up, it should be expected to work right.
[16:49] <soren> wasabi: If the maintainer scripts are not robust enough to reasonably make sure it comes back up, *that's* the problem, we should fix.
[16:49] <wasabi> Alright. So what level of "interesting" are we good with?
[16:49] <slangasek> wasabi: well, anything that dies without ~ when $HOME is set is buggy and should be fixed, for starters
[16:50] <soren> wasabi: What amount of security fixes are you good with not getting applied because you refuse to restart winbind?
[16:50] <wasabi> slangasek, I'd respect sudo's decision to not elevate a user whose name it cannot resolve.
[16:50] <slangasek> wasabi: for another thing, I hope you have a local, non-winbind user on your system who has sudo privs?
[16:50] <wasabi> Yes. I do. It's just a pain to get to it.
[16:50] <slangasek> ok
[16:50] <wasabi> su won't run without a name either
[16:51] <wasabi> Are you sure about that? I don't really think it's unexpected for a piece of software to be able to expect to resolve a uid.
[16:51] <wasabi> Err.
[16:51] <wasabi> I don't think it's unreasonable.
[16:52] <slangasek> I don't think it's reasonable for a piece of software to fail if it can't
[16:52] <wasabi> Hmm.
[16:52] <slangasek> unless it's something that needs to run setuid()
[16:53] <slangasek> then not being able to resolve a name to a uid is fatal, sure :)
[16:53] <wasabi> ISI\jhaltom@station-1:/etc/dbus-1/system.d$ sudo /etc/init.d/winbind start
[16:53] <wasabi> sudo: uid 1786588783 does not exist in the passwd file!
[16:53] <wasabi> =(
[16:54] <wasabi> I dunno. Guess I'm fine with all of that. I retract my statement. The maintainer script still needs to work, though.
[16:55] <slangasek> su my-local-admin -c "sudo /etc/init.d/winbind start" :)
[16:55] <wasabi> su fails.
[16:55] <slangasek> it does?
[16:55] <wasabi> Yes.
[16:55] <wasabi> jhaltom@station-1:/etc/dbus-1/system.d$ su sysadmin
[16:55] <wasabi> ISI\jhaltom@station-1:/etc/dbus-1/system.d$
[16:55] <wasabi> exit code 1
[16:55] <slangasek> hmm
[16:55] <slangasek> maybe worth a bug
[17:03] <wasabi> slangasek, so is it then accurate to say that apps should not use pam to return home and shell, and should instead use the environment?
[17:05] <slangasek> wasabi: apps should not use pam to return home and shell, because pam knows nothing about either ;)
[17:05] <wasabi> su explicitly has a set of code which gets the user's name to ensure he exists.
[17:05] <wasabi> Err, nSs i mean
[17:05] <wasabi> * Get the user's real name. The current UID is used to determine         * who has executed su. That user ID must exist.
[17:05] <slangasek> wasabi: well, it's worth discussing with the shadow maintainers whether this is the Right Thing
[17:06] <wasabi> Could also solve the problem by doing something creative, like ensuring that the current user can always retrieve his information... local nss_winbind cache for the one user.
[17:06] <wasabi> That's basically what windows does.
[17:08] <wasabi> oh, who knows. I don't care.
[17:08] <wasabi> I just want it to work right. heh
[17:08] <soren> You clearly do.
[17:08] <soren> :)
[17:09] <wasabi> Well, I maintain offices of people. I have an interest in it working.
[17:10] <keescook> lool: thanks! :)
[17:14] <slangasek> wasabi: how did winbind upgrading fail?
[17:14] <wasabi> Don't think it did.
[17:14] <slangasek> ok
[17:14] <wasabi> Think winbind was just stopped while the adduser thing ran
[17:14] <slangasek> right
[17:14] <wasabi> and thus the upgrade itself stopped
[17:15] <slangasek> ah, erm
[17:15] <slangasek> well, that's correctable at least
[17:15] <wasabi> I did manually start winbind, and the adduser thing proceeded.
[17:15] <wasabi> Sure. Just worries me that it's so fragile.
[17:15] <slangasek> we can do a if getent passwd $username ; then adduser ...
[17:15] <wasabi> Well, it still needs to be added.
[17:16] <wasabi> Can't skip it completely.
[17:16] <slangasek> hrm?
[17:16] <wasabi> My user is in fact a member of the local admins, and I would expect him to be added to this new group.
[17:17] <wasabi> Just so happens he's a domain user.
[17:17] <slangasek> which isn't possible when he's not resolvable, so your choices are a) have the samba postinst fail, b) skip the user
[17:17] <wasabi> c) work right?
[17:17] <wasabi> =(
[17:17] <slangasek> nope
[17:17] <wasabi> Working right is not an option?
[17:17] <slangasek> you have to decide which of a) or b) is what you consider to be "working right"
[17:17] <wasabi> Urm.
[17:17] <wasabi> This is silly.
[17:18] <slangasek> because those are the only two choices, given the information it's possible to determine from inside the samba postinst
[17:18] <wasabi> I don't see why we have to talk ourselves into these little corners.
[17:18] <wasabi> There is a working right. It should do what it's supposed to do, properly, and especially in a support configuration (using WInbind to let domain users log in)
[17:18] <slangasek> i.e., it's not possible to determine whether a user lookup fails due to a temporary resolution failure, or because there's stale data in /etc/groups
[17:18] <slangasek> /etc/group
[17:19] <wasabi> Again, I'd argue that that's missing the problem. A "temporary resolution failure" is silly.
[17:19] <wasabi> There should be no such thing. Any such thing should be a bug.
[17:20] <wasabi> User's are not supposed to disappear during normal operation.
[17:20] <wasabi> Especially one that's currently logged on.
[17:22] <slangasek> nope, it's not missing the problem.  There are two problems, and one of them is "what do we do if /etc/group references a username that we can't find?"
[17:23] <wasabi> Hmm. You are right, two issues. But you need to define "can't find" clearer.
[17:23] <slangasek> not really
[17:23] <wasabi> can't find because somebody left something left over? or because of a misplanning in how all the software works together?
[17:24] <wasabi> In the first case, I agree. In the second, we should fix the problem that causes it to not be found.
[17:25] <slangasek> "we should fix the problem that" is the separate problem, and has no bearing whatsoever on what the behavior of the samba package should be when it fails to find a user
[17:26] <EtienneG> hey everybody
[17:26] <EtienneG> ?I have a quick question about apport
[17:26]  * slangasek waves to EtienneG 
[17:26]  * EtienneG wave back
[17:26] <EtienneG> I want to use apport-retrace to figure out a segfault
[17:27] <EtienneG> it complained that my crash report do not have the Package field
[17:27] <EtienneG> which is right
[17:27] <EtienneG> how should I make apport write that field when building the crash report ?
[17:27] <slangasek> wasabi: there are *only* two options for what samba can do when it reaches this case - it can bail (the current behavior), or it can ignore the missing user, possibly with a warning
[17:27] <slangasek> if you have an opinion on which is the correct behavior, I'll take that under advisement
[17:27] <EtienneG> (hopefully I make sense, I am not 100% sure I get all the naming convention right)
[17:28] <soren> slangasek: Alternatively, the user migration stuff from admin to sambashare (or whatever) can be done outside of the postinst, but that's really not a very desirable solution either.
[17:29] <soren> slangasek: I was about to say something about an inist script, but that'll get called from the postinst, too.
[17:29] <slangasek> wasabi: but not all temporary resolution failures are bugs in the local system.  You may have shoved a user into /etc/group that can only be looked up via winbind, has never been in the local winbind cache, and at the point of the postinst running you have no network connection.  Doesn't matter then if you avoid stopping winbind.
[17:29] <wasabi> I shall then fail a separate bug: "restarting winbind during upgrade causes desktop mayhem"
[17:30] <wasabi> slangasek, I agree with that.
[17:30] <slangasek> soren: right, and deferring the decision doesn't solve the problem anyway
[17:30] <wasabi> what i mostly fear is that fixing the adduser thing will just hide the other issue.
[17:30] <slangasek> soren: you still have to decide what you think you should do with users you can't find :)
[17:30] <soren> slangasek: Not the inherent one, no.
[17:31] <soren> slangasek: ..but this particular one, yes.
[17:31] <soren> slangasek: The particular problem here is that during the upgrade, we shut down winbind, which causes this migration to fail.
[17:32] <soren> slangasek: The inherent problem, however, is that we have no way to generally deal with users we can't find.
[17:32] <soren> ...which we can work around in this case.
[17:32] <soren> I wouldn't want to that, though. I'm just saying. :)
[17:33] <slangasek> soren: we stop slapd on upgrade too, what if the users are in LDAP? :)
[17:33] <slangasek> right
[17:34] <soren> I'm entirely in favour of just ignoring the user (possibly issuing a warning).
[17:34] <soren> It's commonplace for this sort of thing to not be enabled on upgrades, because (here's a shocker) there's no completely sane way to do it.
[17:34] <mvo> Riddell: thanks for this info, I prepared something, but I think i need to keep it disabled, it does not yet work well enough (also the remaining issues get smaller)
[17:34] <soren> I was surprised to even see an attempt at doing it, actually. :)
[17:35] <slangasek> heh
[17:36] <slangasek> soren: have there been other system groups added since Ubuntu's inception where there was a group that could even be sensibly templated from? :)
[17:39] <soren> slangasek: Well, a lot of packages create system groups that users are supposed to be added to if they should be granted access. In most cases, it wouldn't be a completely braindead assumption that if you're ok with people having sudo powers for your entire system, you'd also be ok with them accessing your scanner or whatnot.
[17:39] <soren> But maybe that's just me.
[17:39] <soren> :)
[17:39] <slangasek> soren: right, but I think in the case of scanners, the relevant group is /older/ than the admin group and created at install time? :)
[17:40] <soren> slangasek: Ok, bad example. fuse, then.
[17:40] <slangasek> ok :)
[17:44] <soren> We talked about this net usershare thing a while ago, by the way. I was against adding that group, but I was clearly too slow to get to have a say in it :)
[17:49] <slangasek> soren: oh?  what would be the alternative to adding the group?
[17:49] <soren> I don't see why anyone would want to specifically grant access to sharing via samba rather than some sort of generic "this user is allowed to share stuff to the network". When the next package comes along that does something like this, perhaps using a different protocol, will we add another group? It's kind of like kvm and virtualbox each adding a group to which you can add users if they should have access to that particular virtualisation techniqu
[17:49] <slangasek> so you would've preferred a generic name for the group?
[17:49] <soren> Yes.
[17:49] <slangasek> it's not too late to change :)
[17:49] <soren> And have it added to base-passwd. (ooh, scary)
[17:52] <soren> slangasek: True, but the barrier of entry grows significantly when you mention base-passwd. <100 gids are a scarce ressource.
[17:52] <soren> brb
[17:54] <slangasek> soren: < 100?  we have way more to play with than that :)
[17:55] <slangasek> there's no reason this group needs to be statically assigned
[17:55] <slangasek> and even if it were, there's the 60000-64999 range we've never touched ;)
[17:56] <soren> slangasek: Well, it's hard to predict the future..
[17:57] <cjwatson> is "never touched" a synonym for "allocated 18 uids and 8 gids in it"?
[17:57] <cjwatson> /usr/share/doc/base-passwd/README :-)
[17:57] <soren> slangasek: At some point, some sort of application that allows you to share stuff over the network might include a sgid binary somewhere.
[17:57] <soren> slangasek: I had another thought, though.
[17:58] <cjwatson> setgid binaries can use dynamic system groups provided that the group is created in the preinst
[17:58] <slangasek> cjwatson: heh, wow, I don't think I've ever seen any of those :)
[17:58] <soren> cjwatson: point
[17:58] <thom> tac-plus has a 6400x user? hhuh
[17:58] <cjwatson> god knows, I just allocate them
[17:59] <cjwatson> there's enough space in the range and a small enough trickle of requests that all I do is double-check that there's a reason that 'adduser --system' isn't good enough
[18:00] <soren> It might make more sense to just add the much-talked-about "users" group.
[18:01] <soren> I think the need for the sambausers group is a technical one rather than a policy related one.
[18:01] <soren> It depends on a directory somewhere that the relevant users can all have write access to.
[18:01] <cjwatson> we have a users group; it's just that nothing adds normal users to it
[18:02] <soren> There are two ways to do that (disregarding acl's): 1) Add a new group and add the relevant users to it or 2) make it world writable.
[18:02] <soren> cjwatson: Wow... You're right. Why arent' we?
[18:02] <cjwatson> but if you're going to add all normal users to a group and give that group write access to something, you almost might as well make that thing world-writable
[18:03] <soren> cjwatson: Not so.
[18:03] <pitti> (except if you care about not having it writeable for www-data etc.)
[18:03] <cjwatson> www-data, granted
[18:03] <soren> cjwatson: You're still protected from various rogue daemons and such.
[18:03] <soren> cjwatson: Exactly.
[18:03] <soren> or ftp
[18:03] <cjwatson> maybe you're right
[18:03] <cjwatson> anyhow, we're not doing it because we never have, AFAIK ;-)
[18:04] <soren> gnome-user-share allows every user to share stuff over the network.
[18:04] <cjwatson> I don't think there's a particular reason
[18:04] <soren> That's because it uses fancy avahi magic to allow each user his own apache daemon on a different port.
[18:04] <soren> No such magic can be done with samba (sanely).
[18:04] <soren> ...which is why it had to be done this way.
[18:05] <cjwatson> it'd be trivial to do with the EXTRA_GROUPS / ADD_EXTRA_GROUPS variables in /etc/adduser.conf
[18:05] <cjwatson> but you'd have to do something about upgrades if you actually wanted to rely on it
[18:05] <soren> ...but since there are loads of ways a user can share stuff to the network anyway, it's kind of odd that you want to add further restrictions because it's done via samba.
[18:05] <cjwatson> and probably check that users-admin DTRT as well
[18:05] <soren> ...this would be solved it all (actual, human) users were members of one common group.
[18:05] <soren> cjwatson: Yes, upgrades are indeed the Achilles heel of this suggestion.
[18:06] <soren> ...and the very reason I didn't take it any further when we were first approached about it, and then it got swapped out of my working memory when I went on honeymoon, I think.
[18:06] <cjwatson> it's not rocket science, I just fear somebody having used gid users for something else
[18:06] <cjwatson> but maybe we can just declare that that's stupid and add a NEWS.Debian item for it
[18:06] <soren> LOL
[18:07] <soren> cjwatson: I'd be fine with that.
[18:08] <slangasek> soren: why would you want all "users" to be able to share things over the network via a samba?  admin users seems a much more sensible default, to me
[18:08] <soren> slangasek: Because they can anyway by loads of other means?
[18:09] <soren> slangasek: gnome-user-share, just to name one.
[18:10] <slangasek> soren: hmm, well, gnome-user-share doesn't give users an opportunity to try to find holes in the samba running as root :)
[18:10] <soren> slangasek: It seems strange to give them 1000 ways to do it, but because of a limitation in the way samba works (it only sensibly works on one port), each user can't have his own samba daemon to much around with.
[18:10] <soren> slangasek: That's indeed true.
[18:10] <soren> hm..
[18:11] <soren> slangasek: Well... The only additional exposure these users get to samba is by way of putting files into a specific directory.
[18:11] <slangasek> sure
[18:11] <soren> It's not like samba is a daemon that's just tucked away in a corner never interacting with users anyhow.
[18:12] <slangasek> btw, samba 3.0.27a-2 just accepted into sid, should cut the Ubuntu delta by half again
[18:12] <soren> If you've enabled the [homes] share, you have much of the same access already, anyway.
[18:13] <soren> And every user has that.
[18:13] <slangasek> soren: mathiaz has argued against enabling [homes] by default :)
[18:14] <soren> slangasek: Erm.. Ok. Regardless, the extra attack vector really isn't that much "extra". That's my point.
[18:16] <soren> Just to clarify: By "And every user has that" I didn't mean "every user has [homes] enabled", but that "if [homes] is enabled, every user has such a share".
[18:17] <slangasek> sure
[18:17] <soren> ...which (assuming samba is sane) should expose the same set of potential vulnerabilities as the net usershare stuff.
[18:18] <slangasek> one difference is that [homes] is commonly configured with valid users = %S, and net usershares can be configured to allow access to any authed user.  I'm not sure this is significant either.
[18:18] <soren> Remind me what %S expands to?
[18:18] <soren> Oh, the owner?
[18:18] <slangasek> "share name"
[18:18] <soren> Same thing. Ok.
[18:18] <slangasek> so for each [homes] share, the only valid user is the one whose name matches the share name
[18:21] <soren> slangasek: Are you pointing this out for the sake of completeness of the discussion, or are you actually saying it's a problem? :)
[18:21] <soren> I.e. should I bother countering the argument?
[18:25] <slangasek> soren: completeness :)
[18:25] <soren> slangasek: Ok, good :)
[18:25] <soren> So.. Should we make samba the first package to actually use the users group?
[18:26]  * soren mumbles TIL and points at slangasek
[18:28] <slangasek> "TIL"?
[18:28] <soren> Touched It Last.
[18:30] <slangasek> well, I'm not personally persuaded that the "users" group has the correct semantics for Debian, there may be sites using it that way who don't want all their users to be able to create shares (namespace pollution?)
[18:30] <soren> The last upload has your name on it. Of course that doesn't de jure means that you're the owner of it, but e.g. for merges, it's often the de facto way to determining who will do it.
[18:30] <soren> slangasek: True. However, you're also an Ubuntu developer these days, though.
[18:31] <slangasek> soren: yes, an Ubuntu developer who just spent a bunch of time reducing the Debian/Ubuntu divergence on the Samba packaging ;)
[18:31]  * soren mumbles TIL again
[18:31] <soren> :)
[18:32] <soren> slangasek: If you're too busy, that's fine. We should just do it sooner rather than later.
[18:32] <slangasek> well, unless that implies I'm also the one who gets to /decide/ whether to use a users group, I'm still going to sit here and raise possible counterarguments :-)
[18:33] <slangasek> making it "users" does make it more complicated to enact alternate policy decisions
[18:33] <soren> That's true.
[18:33] <slangasek> making it "sharing-users" makes it the distro's responsibility to maintain the group
[18:34] <slangasek> but that would already be the case with "users", AFAICS
[19:57] <ogra> StevenK, bug 174213 is a present for you :) (just had to build the modules for the new kernel)
[19:57] <ubotu> Launchpad bug 174213 in virtualbox-ose-modules "cant build with 2.6.24 kernel source" [Undecided,New] https://launchpad.net/bugs/174213
[19:58] <ogra> (looks like you own vboxdrv :) )
[20:01] <micahcowan> Is sporadic loss of keyboard input to GTK+ windows a known issue with Gutsy at this time?
[20:01] <micahcowan> (I'm not sure if it's limited to GTK+, most of my apps happen to be GTK+-based.)
[22:53] <Riddell> doko: could we build icedtea against libungif instead of libgif?  it's the only thing that depends on libgif and the two confict
[22:53] <Riddell> or doko_
[22:54] <doko_> Riddell: ?
[22:54] <Riddell> doko: could we build icedtea against libungif instead of libgif?  it's the only thing that depends on libgif and the two confict
[22:55] <doko_> Riddell: could you file a bug, so that I remember? I never tried
[22:55] <Riddell> sure
[22:56] <mjg59> Riddell: Why is ungif preferable?
[22:57] <Riddell> mjg59: just because everything else in the archive uses it rather than libgif
[22:57] <mjg59> Riddell: That sounds like a bug
[22:58] <Riddell> libungif is in main, presumably to avoid gif patents
[22:59] <mjg59> Riddell: Ungif is unmaintained
[22:59] <mjg59> (upstream)
[22:59] <mjg59> We should migrate everything to libgif
[23:00] <mjg59> Riddell: See http://www.advogato.org/person/badger/diary/51.html
[23:00] <slangasek> wow, that hasn't already been done?
[23:00] <mjg59> It would seem not
[23:01] <mjg59> Given there are bugfixes in libgif that aren't in libungif, I think it's certainly worth it for hardy
[23:01] <Riddell> seems sensible
[23:05] <Riddell> reported as bug 174252
[23:05] <ubotu> Launchpad bug 174252 in libungif4 "transition to libgif" [Undecided,New] https://launchpad.net/bugs/174252