[00:48] <xtknight> for Bug 62230 ... how is the video driver autodetected?  i'd like to force certain problematic cards to go to vesa.  this bug has been here for at laest the past three releases
[00:48] <ubotu> Launchpad bug 62230 in xserver-xorg-video-nv "Corrupt graphics on boot with 7800GT/nv" [Medium,Triaged] https://launchpad.net/bugs/62230
[00:49] <xtknight> safe graphics mode works sure but when you alternate install you get a frozen system
[00:49] <xtknight> actually even when you regular install you do
[01:26] <slangasek> tjaalton: well, I do see /two/ new binaries added by vdr... :)
[01:28] <ScottK> He must want you to leave the other one ;-)
[01:31] <Caesar> Hmm
[01:31] <Caesar> It seems that when gnome-keyring acts as the SSH agent, it can't cope with loading an RSA1 key
[03:09] <Hobbsee> jdong: already back, it looks like
[03:10] <jdong> Hobbsee: magical
[03:10] <jdong> Hobbsee: err, on gutsy-backports?
[03:28] <Hobbsee> jdong: oh, meh.
[03:29] <emgent> heya Hobbsee :)
[03:30] <Hobbsee> heya
[03:31] <Hobbsee> jdong: i'll actually have to use the LP UI for that :(
[03:32] <jdong> Hobbsee: aww so it'll take 10 minutes of your time waiting for LP to load?
[03:34] <Hobbsee> jdong: given back
[03:34] <jdong> whee
[03:34] <jdong> and if it FTBFSes again, can I get an Ubuntu brown paper bag?
[03:35] <ScottK> Flaming?  On a doorstep?
[03:40] <emgent> anteater 1.0 beta is out! :)
[03:41] <bddebian> ScottK: :)
[03:41] <ScottK> I knew someone would get it.  I should've figured you'd be the someone.
[03:41] <bddebian> heh
[03:46] <Hobbsee> jdong: why does it die?
[03:47] <jdong> Hobbsee: it should build-dep on bzrtools >= 1.3
[03:47] <jdong> Hobbsee: but Debian didn't do it, I didn't want to diverge to do it, a rebuild would fix it at worst..
[03:48] <jdong> Hobbsee: this particular FTBFS results when the archive has new bzr, old bzrtools, and tries to build new bzr-builddeb
[03:48] <Hobbsee> hmm
[03:48] <jdong> that leaves new bzr + old bzrtools in uninstallable state
[03:48] <Hobbsee> so you'll need to rebuild bzrtools too, then.
[03:48] <jdong> no, bzrtools built fine
[03:49] <jdong> it just built a matter of MINUTES after bzr-builddeb tried to build
[03:49] <Hobbsee> hang on, i thought you said it all died again.
[03:49] <jdong> Hobbsee: no I said if!
[03:49] <jdong> hypothetical :)
[03:49] <Hobbsee> oh, right.
[03:49] <Hobbsee> i'm confused, apparently
[03:49]  * Hobbsee has been dealing with far too much other shit, apparently.
[03:51]  * jdong gives Hobbsee a hug
[03:51]  * Hobbsee hugs jdong back.  And you're unfortunate enough to know what a great section of it is about, too.
[03:53] <jdong> :( yeah
[03:55] <RAOF> Hm.  SIGXCPU strikes again.  And it's not banshee-trunk-specific, I've just had rhythmbox do it.
[03:55] <RAOF> Maybe it only occurs on battery - I couldn't reproduce yesterday afternoon, and I think the difference was I plugged the lappy in.
[03:56] <jdong> RAOF: isn't SIGXCPU used by mono, specifically, the Boehm GC, to signal collection?
[03:56] <jdong> could there be some bug at that level?
[03:57] <RAOF> jdong: Except that neither pulse nor rhythmbox are mono apps?
[03:57] <jdong> RAOF: oh sorry. you mentioned banshee
[03:57] <jdong> -ECONTEXT
[03:57] <RAOF> Hm.  Rhythmbox _really_ doesn't like pulse dying on it.  1.1GB of memory is not a nice mem usage ;)
[03:59] <RAOF> jdong: I think you're right about mono's usage of XCPU.  At least, debugging banshee suggests that you make gdb pass XCPU through.
[04:02] <pleaseandthankyo> is there a good diet softwares? like for a diabetes guy or a healthy living diet software for person who has heart d eases?
[04:04] <jdong> not the right place to ask.... Please use #ubuntu
[04:05] <lifeless> he just asked in at least channels
[04:10] <tedg> pleaseandthankyo: While this isn't the place to ask, the only diet software I know for Linux is "Shrinkingman" -- but I don't believe it is maintained anymore.
[04:11] <tedg> pleaseandthankyo: http://debain.org/software/shrinkingman/
[05:38] <RAOF> For those playing at home, pulse being killed with SIGXCPU?  Not a on-battery problem.
[05:50] <lamont> meh.  dapper-backports upload of git-core is blocked on cvsps being in universe in dapper.
[05:50] <LaserJock> doh
[06:01] <jdong> LaserJock: lovely
[06:01] <jdong> err lamont
[06:01] <jdong> lamont: do you have closer connections with the soyuz folks than us?
[06:01] <jdong> please I beg of you or someone, do something about it
[06:01] <jdong> I've simply fallen upon deaf ears to fix this several-month-old regression
[06:01] <lamont> does it have a bug?
[06:01] <lamont> number that is
[06:03] <lamont> jdong: because a bug number would be a major step towards escalating the fix.. esp if said bug was several months old...
[06:03] <jdong> lamont: yes it does
[06:04] <jdong> https://bugs.edge.launchpad.net/soyuz/+bug/198936
[06:04] <ubotu> Launchpad bug 198936 in soyuz "Regression: Backports should ignore main-universe split" [Undecided,New]
[06:04] <jdong> note the lovely lack of any activity or acknowledgement it exists
[06:05] <lamont> jdong: I have a couple of things ahead of it (not just pleading for the sync of bind9.4.2-10 (after I upload it...)).  I'll poke someone or 3 about it this week
[06:05] <jdong> lamont: thank you so much
[06:05] <lamont> jdong: I mean, nfc if it'll have any more effect that your efforts...
[06:20] <lamont> hrm... so do I mark a bug 'fix released' when I upload to debian, or when it's synced into hardy?
[06:21] <RAOF> When it's sync'd, surely.  You could mark it as 'fix committed' when you upload to Debian, probably :)
[06:22] <lamont> nah, it get's "fix committed" when the fix is, uh, committed.  (to the vcs)
[06:23] <LaserJock> lamont: well, I suppose the LP ideal would be that it would be Fix Released on a Debian task and probably Fix Committed on an Ubuntu task
[06:25] <slangasek> lamont: you put the LP: line in the Debian changelog, and let the sync close the bug ;)
[06:25] <lamont> slangasek: did that. :)
[06:25] <slangasek> then let LP take care of the rest?
[06:26] <lamont> slangasek: yeah - that was my plan.. the only thing it doesn't take care of is figuring out how to trigger the sync. :-)
[06:26] <lamont> but I'll worry about that after dinstall tomorrow
[06:26] <slangasek> ah, heh
[06:27] <lamont> the upload is 2 ubuntu bugs, zar0 debian bugs. \o/
[06:27] <LaserJock> slangasek: do you think you could push flashplugin-nonfree from the gutsy unapproved queue?
[06:32] <slangasek> LaserJock: can you tag the archive admin on duty, please? :)
[06:33] <LaserJock> I guess
[06:34] <LaserJock> I was just trying to be as quick as possible
[06:34] <LaserJock> but I can sub ubuntu-archive
[06:36] <LaserJock> actually I won't, that'd be mean
[06:36] <LaserJock> I'll poke in the morning if it's not done
[06:36] <LaserJock> night all
[06:37]  * lamont -> sleep
[06:38] <Hobbsee> sleep is banned
[06:42] <tjaalton> slangasek: oh right, vdr-plugin-pictures.. totally harmless, it seems :)
[07:11] <dholbach> good morning
[07:14] <warp10> Good morning
[07:15] <laga> morning
[07:22] <kagou> Good morning
[07:31] <xtknight> is there supposed to be a konqueror-kde4-dbgsym package?  i don't see one.  ditto for konqueror-nsplugins-kde4-dbgsym
[07:44] <TheMuso> 5~/c
[07:44] <TheMuso> ugh
[07:45] <RAOF> :)
[07:46] <slangasek> kagou: bug #208419> did you ever install libpam-smbpass?
[07:46] <ubotu> Launchpad bug 208419 in pam "Integrate samba password in PAM" [Wishlist,In progress] https://launchpad.net/bugs/208419
[07:46] <slangasek> ah, apparently not
[07:46] <kagou> slangasek, i finally installed libpam-smbpass
[07:46] <kagou> :)
[07:46] <xtknight> did it ever work?
[07:47] <slangasek> kagou: right - the pam change makes it optional, so that PAM itself continues to work with or without libpam-smbpass installed
[07:47] <kagou> but now i'm having problems with samba share...
[07:47] <kagou> so i'm investigating
[07:48] <slangasek> kagou: and making libpam-smbpass be installed by default is an additional change to make in support of this, but I want to be darned sure the PAM changes are right first
[07:48] <kagou> indeed
[07:50] <kagou> mmm apparently, since i'v installed libpam-smbpasswd i can not enter in my PC from a windows client. An authentification is needed
[07:51] <slangasek> what do you mean by "enter"?
[07:53] <mdke> BalaamsMiracle: I'm planning to import translations for ubuntu-docs in the next 2 days, time permitting
[07:53] <kagou> from windows, i browse PC, and when I enter (double-click)  in my PC name (to see shared folders), now an athentification is required
[07:54] <kagou> i purge my system and recheck all
[07:57] <mdke> slangasek: is it going to be ok if the final ubuntu-docs upload with imported translations is ready by this weekend (i.e. a couple of days later than the freeze)?
[07:57] <slangasek> mdke: yes
[07:57] <mdke> slangasek: thanks
[08:06] <kagou> slangasek, i suspect patched pam packages to interfer with samba server
[08:07] <kagou> i'm installing a fresh daily image (to ensure that all is clean).
[08:07] <kagou> brb
[08:07] <slangasek> kagou: with or without libpam-smbpass installed?
[08:08] <kagou> without
[08:09] <slangasek> I'd want to see the share config
[08:09] <kagou> slangasek, it's the default, installed by samba package
[08:09] <slangasek> the samba package doesn't ship with any shares enabled by default...
[08:10] <kagou> indeed, i making share using usershare system (nautilus-share). This way smb.conf is not modified
[08:10] <slangasek> ok, and is it set to allow anonymous access?
[08:11] <kagou> what ? smb.conf or usershare folders ?
[08:11] <slangasek> the usershare folder
[08:12] <kagou> no, set to authentification
[08:12] <slangasek> so where's the bug?
[08:13] <kagou> slangasek, i can not enter in my PC (from windows samba browser) to see shares (printer/filders)
[08:14] <kagou> sorry i must go for 10min
[08:14] <kagou> brb
[08:14] <slangasek> ok, I don't see why you expect this to work currently.  You've said that libpam-smbpass wasn't installed, so no Samba password entry was set up... so why would you expect it to work yet?
[08:44] <kagou> seb128, lut. do you have problem on launching gdmsetup. Here it tkae long time to launch, an harddrive have a lot of activity
[08:45] <seb128> kagou: hi, no, but we have several report about it being slow on the first run after installation, the harddrive activity is interesting, could you strace it?
[08:47] <kagou> slangasek, to resume. On a fresh/clean install/with samba/a folder shared for guest with nautilus-share (usershare). Browsing samba from a windows XP client is done like this : Enter workgroup/see PC/enter PC/see shares/ enter shares. Now that i'v played with pam pached/libpam-smbpass, ica n do browse/entre workgroup/see PC/CAN NOT entre PC
[08:47] <kagou> seb128, sure, i'm finishing a fresh install
[08:48] <kagou> seb128, a "strace gdmsetup > info" is enough for you ?
[08:48] <Hobbsee> kagou: erm.  if the folder(s) that you're sharing require authentication, and you're getting a prompt to authenticate....what, exactly, is the problem?
[08:48] <Hobbsee> kagou: you appear to think that you should not have to authenticate, even though you've set it up so it requires authentication.
[08:48] <kagou> Hobbsee, i'm getting a prompt to enter in the PC, not in the share
[08:49] <kagou> this is the problem, as i can't see pdf/folder shares
[08:49] <kagou> this is the problem, as i can't see printers/folder shares
[08:49] <Hobbsee> you're trying to connect to a windows box, i assume?
[08:50] <slangasek> from a windows box, to a Samba server
[08:50] <kagou> from a windows XP client
[08:50] <Hobbsee> oh right
[08:51] <Hobbsee> kagou: why would you expect to have to have to put in your password at the physical samba share, then?
[08:51] <slangasek> kagou: that sounds perfectly normal to me that you would be asked to authenticate when connecting to the server
[08:53] <Hobbsee> having to bash down the server room door, so you can type in a password, so you can pull files from the server room back to your windows machine seems...backwards.
[08:54] <slangasek> ...?
[08:55] <Hobbsee> which appears to be what kagou is saying?
[08:55]  * Hobbsee gives up
[08:55] <xtknight> he just wants to see what shares are broadcast
[08:55] <xtknight> instead of actually getting into a share
[08:55] <xtknight> not sure if you need to auth to do that
[08:55] <slangasek> I believe he's saying that he gets a password prompt trying to browse the host from windows
[08:55] <slangasek> which is normal
[08:55] <Hobbsee> well, yes...
[08:55] <kagou> slangasek, no it's not normal
[08:55] <Hobbsee> ah, right.  so that's what he's saying.
[08:56] <slangasek> er, but it is...
[08:56] <kagou> :p
[08:56]  * mvo waves to xtknight
[08:56] <kagou> sorry but my english is poor and sometimes i'v difficulty to explain well
[08:56] <xtknight> mvo, oh yeah i had another bug to talk to you about
[08:56] <xtknight> Bug 212542
[08:56] <ubotu> Launchpad bug 212542 in compiz-fusion-plugins-main "Drop type=Utility from 01-animation-defaults.patch" [Low,Triaged] https://launchpad.net/bugs/212542
[08:57] <xtknight> get my earlier messages?
[08:58] <slangasek> kagou: when you try to connect to an SMB server, the server will request credentials from the client even if all you're doing is browsing it - and different shares may be visible depending on the credentials used
[08:58] <slangasek> so yes, you will get a password prompt when browsing the host, unless your Windows client already knows credentials to use
[09:00] <kagou> slangasek, since today, connecting SMB server do not requier password prompt, and so i can see shares (printers/shared folders)
[09:01] <Hobbsee> head-->desk.
[09:01] <Hobbsee> (mine)
[09:03] <mvo> xtknight: yeah, that one is scheduled for today
[09:05] <xtknight> mvo, oh ok i didn't even bother to check the page.  looks like you've got that taken care of, then
[09:05] <xtknight> i'm off to get sleep, laer
[09:05] <xtknight> later
[09:06] <slangasek> kagou: by "since today", do you mean "before today"?
[09:06] <mvo> thanks xtknight
[09:06] <xtknight> mvo, thanks for dealing w/ the bugs, your job seems heftier than mine
[09:08] <kagou> slangasek, indeed
[09:09] <slangasek> kagou: what's the value of 'map to guest' in /etc/samba/smb.conf?
[09:11] <kagou> slangasek, i can't say this now. Let me finish install :)
[09:20] <ogra_cmpc> asac, if i dont use dhcp, can it be that NM doesnt show the network at all ?
[09:20] <ogra_cmpc> (the wlan i mean)
[09:21] <slytherin> ogra_cmpc: yes, when you use static ip, NM will pretend as if it doe snot know what the status is. :-)
[09:22] <asac> ogra_cmpc: if you have a config in interfaces, NM will not manage that device
[09:22] <ogra_cmpc> asac, no, thats different
[09:22] <asac> ogra_cmpc: it will instead assume that you are online (so apps don't come up in offline mode)
[09:22] <ogra_cmpc> asac, RichEd doesnt have a dhcp server in his network ... seems he doesnt see his wlan on the cdlassmate
[09:23] <asac> ogra_cmpc: if the interface is managed, network manager cannot know about dhcp or not dhcp before it actually associates. so its unrelated for sure
[09:23] <asac> ogra_cmpc: maybe he has a hidden SSID
[09:23] <ogra_cmpc> no, he said he doesnt
[09:23] <asac> sudo iwlist scan
[09:23] <ogra_cmpc> (was my first question as well :) )
[09:24] <kagou> slangasek, i'v a meeting. I'll be back in 1 hour
[09:24] <asac> ogra_cmpc: if manually scanning doesn't show the network its a driver or AP issue
[09:25] <asac> but since the cmpc works in general, i'd guess that its an AP issue for him
[09:25] <ogra_cmpc> asac, i would guess APv since i havent seen the cmpc break on wlan at all with hardy yet
[09:25] <asac> ogra_cmpc: maybe he uses a standard not supported by the cmpc driver?
[09:25] <asac> like abg
[09:25] <ogra_cmpc> and had no reports from others either
[09:27] <ogra_cmpc> asac, <RichEd> abg ? wtf ?
[09:28] <ogra_cmpc> if he does, he doesnt know i guess :)
[09:29] <asac> ogra_cmpc: my router provides options to select modus "g or b"
[09:30] <asac> ogra_cmpc: maybe some chipsets do not yet support one of abg
[09:30] <asac> thats the only idea i currently have
[09:30] <ogra_cmpc> i dumped all of that on him ... lets see what comes out
[10:23] <kagou> slangasek, still here ?
[10:23] <slangasek> kagou: only barely
[10:23] <kagou> slangasek, with a fresh clean install+samba, browsing from a windows client let me see shares on my ubuntu samba server without password
[10:24] <kagou> i see "PDF" + "Printers..."
[10:24] <slangasek> kagou: this is with 'map to guest = bad user' in /etc/samba/smb.conf?
[10:24] <kagou> yes, this is the default in smb.conf
[10:25] <kagou> now i will install patched pam + libpam and try if this is changing something
[10:25] <slangasek> so the username you've used to log in to the Windows client is one that doesn't exist on the server, right?
[10:25] <kagou> indeed
[10:26] <slangasek> ok; in that case, this is the expected behavior.  Yes, please let me know if something changes just by installing the new pam package
[10:26] <kagou> slangasek, is there files to save before installing patched pam and libpam-smbpass ?
[10:27] <slangasek> the only files that will be changed are /etc/pam.d/common-auth and /etc/pam.d/common-password
[10:27] <slangasek> please install *just* the patched pam first
[10:27] <slangasek> and test
[10:27] <kagou> thanks
[10:27] <kagou> ok
[10:27] <slangasek> and then install libpam-smbpass, and test again
[10:28] <kagou> 3 packages to upgrade...
[10:28] <kagou> ->reboot
[10:29] <slangasek> I have a more complicated PAM configuration on my own machine rather than the proposed default, but I believe that the tests I've done with the local samba are consistent and correct
[10:31] <kagou> slangasek, works the same
[10:31] <slytherin> calc: pitti: Does anyone of you mind if I reopen the bug 205923?
[10:31] <ubotu> Launchpad bug 205923 in openoffice.org "openoffice in hardy doesn't build on powerpc" [Critical,Fix released] https://launchpad.net/bugs/205923
[10:31] <kagou> i install libpam-smbpass
[10:32] <kagou> reboot
[10:34] <slangasek> slytherin: how does that differ from bug #214042?
[10:34] <ubotu> Launchpad bug 214042 in openoffice.org "[Ubuntu] [hardy] OOo FTBFS on powerpc due to timeout" [Critical,In progress] https://launchpad.net/bugs/214042
[10:36] <slytherin> slangasek: I didn't log any of those two. The timeout ones seems to be logged yesterday only.
[10:37] <kagou> slangasek, seems ok too.
[10:37] <slytherin> slangasek: and timeout is the reason I was going to reopen first one. But anyway since calc himself logged another bug and looking into it, I will not intervene. :-)
[10:37] <kagou> i add a usershare for guest now
[10:38] <BalaamsMiracle> mdke: Thanks for the info. But is there an official schedule after which the translations for all documentation are imported? Like once a month, one every 3 months, once a release?
[10:40] <kagou> slangasek, damn seems to work now
[10:40] <kagou> slangasek, i wil add new user, use it to share a folder with password
[10:42] <cjwatson> anyone here in the Ubuntu German translators team? I need somebody to approve the typo correction (Standardspache -> Standardsprache) in https://translations.launchpad.net/ubuntu/hardy/+source/debian-installer/+pots/debian-installer/de/61/+translate for bug 195075
[10:42] <ubotu> Launchpad bug 195075 in ubiquity "Typo in german translation of installer" [Low,Fix committed] https://launchpad.net/bugs/195075
[10:43] <kagou> argll, windows have password+user in cache i must find how to empty this
[10:43] <laga> i think i've applied twice for the german translators team but i havent been approved yet.. i guess i need to bug them in their irc channel
[10:45] <cjwatson> the Launchpad translations team tell me that the translator teams are really supposed to be translation moderator teams, and that casual translators should just use suggestions
[10:45] <cjwatson> the UI isn't clear at the moment
[10:46] <kagou> slangasek, i found my bug !
[10:46] <laga> ah. ok.
[10:46] <laga> cjwatson: how are "suggestions" then merged? by the moderator teams?
[10:46] <cjwatson> I'm told that that's the idea
[10:46] <kagou> slangasek, all seems to work great, before i change my password for the first user. After that i can not more see shares
[10:46] <ogra_cmpc> just out of curiosity, does anyone know why installing xfonts-* packages wants to have /lib/modules/$kvers/modules.dep in place ?
[10:46] <cjwatson> I suspect that a number of translator teams don't actually work this way in practice at the moment, though
[10:47] <ogra_cmpc> FATAL: Could not load /lib/modules/2.6.24-8-generic/modules.dep: No such file or directory
[10:47] <laga> cjwatson: well, i was going to translate a few of "my" apps in rosetta to my native language.. i guess i'll resort to vim then and let rosetta handle other languages
[10:47] <Hobbsee> TheMuso: looks like the launchpad-integration stuff is broken - conflicting file bewteen liblaunchpad-integration0 and liblaunchpad-integration1.  Please fix.
[10:48] <cjwatson> laga: don't let me discourage you
[10:48] <cjwatson> if you're doing serious chunks of translation, it's probably more effective to be in the moderator team anyway
[10:48] <Hobbsee> TheMuso: wait, never mind.  mirror is out of date.
[10:49] <laga> cjwatson: no worries, it's just a different choice of UI for me, the translation will end up in the repos anyways.
[10:49] <cjwatson> true
[10:51] <ogra_cmpc> ARGH
[10:51] <ogra_cmpc> LAGA !
[10:51] <ogra_cmpc> laga,        # do not start ltsp-client-core
[10:51] <ogra_cmpc>         chroot $ROOT update-rc.d -f ltsp-client-core remove || true
[10:51] <laga> i guess i broke something.
[10:52] <ogra_cmpc> laga, could you move that and the following update-rc.d commands inside the if statement ?
[10:52] <laga> ogra_cmpc: yes. sorry :/
[10:52] <ogra_cmpc> so it doesnt get executed on normal ltsp ... its somewhat fatal to not have ltsp-client-core starting :)
[10:53] <kagou> slangasek, bring back the "old" password, and all is ok
[10:53] <slangasek> kagou: what "first user"?  At this point, I don't think this has anything at all to do with the pam changes; either your expectations for Samba are at odds with the intended behavior, or there's a bug in Samba, either way it doesn't correlate with the PAM change
[10:53] <ogra_cmpc> sorry, i should have spotted that the fi sits to far up
[10:53] <kagou> first user ->user created on hardy installation
[10:54] <stgraber> ogra_cmpc: is that bug 214481 ?
[10:54] <ubotu> Launchpad bug 214481 in ltsp "[hardy] ltsp-build-client builds incomplete filesystem" [Undecided,New] https://launchpad.net/bugs/214481
[10:54] <laga> ogra_cmpc: just a debdiff this time? easier for you :)
[10:54] <ogra_cmpc> laga, sure
[10:54] <ogra_cmpc> stgraber, right, looks like it
[10:55] <ogra_cmpc> laga, ^^^
[10:55] <slangasek> laga, ogra_cmpc: could you not use update-rc.d -f, which will be completely undone by any upgrades to the ltsp-client-core package? :)
[10:55] <kagou> slangasek, should I  report this bug to samba
[10:55] <slangasek> kagou: if you think there's a bug, yes.
[10:55] <laga> slangasek: what do you suggest?
[10:56] <slangasek> kagou: in the meantime, I'm off to bed
[10:56] <laga> slangasek: deleting the init script?
[10:56] <ogra_cmpc> slangasek, well, thst the mythbuntu plugin doing that, i.d actually appreciate to have ltsp-client-core starting on ltsp :) but i'm sure laga will take it into account
[10:56] <slangasek> laga: I don't think there's really a proper way to do that to another package's init script
[10:57] <laga> slangasek: echo "exit 0" >> /etc/init.d/ltsp-client-core ;)
[10:57] <kagou> slangasek, thank you for your time, i will remove pam patched and libpam-smb to test if this bug i sstill here. cya
[10:57] <ogra_cmpc> laga, move it to K
[10:57] <cjwatson> laga: the system is designed so that you must get the other package to cooperate, rather than non-consensually fiddling with its bits
[10:58] <laga> cjwatson: that's planned for +1
[10:58] <ogra_cmpc> upcdate-rc.d of the package will do nothing if a K link exists, just dont remove it
[10:59] <laga> ogra_cmpc: so i just remove the S links. i guess for +1, i should write a blacklist function similar to the whitelist one
[10:59] <ogra_cmpc> If  any  files  /etc/rcrunlevel.d/[SK]??name already exist then update-
[10:59] <ogra_cmpc>        rc.d does nothing.  The program was written this way so  that  it  will
[10:59] <ogra_cmpc>        never  change an existing configuration, which may have been customized
[10:59] <ogra_cmpc>        by the system administrator.  The program will only  install  links  if
[10:59] <ogra_cmpc>        none  are  present, i.e., if it appears that the service has never been
[10:59] <ogra_cmpc>        installed before.
[10:59] <ogra_cmpc> from man ...
[11:15] <ogra_cmpc> laga, oh, btw,why did you disable nbd-client ? it wont do any harm (will just fail silently if there is no configuration)
[11:15] <laga> ogra_cmpc: i'm not worried about starting it, i'm worried about it getting killed when the box is shut down
[11:16] <asac> ogra_cmpc: whatfor would libflashsupport require SSL?
[11:16] <ogra_cmpc> ah, right, you should move it
[11:17] <laga> hum, is it "for i in $@; do" or "for i in "$@"; do" - i wonder if i these quotation marks will affect semantics
[11:18] <ogra_cmpc> asac, hmm, i knew that once ... its so long ago that i had to do with actual code there, let me look
[11:19] <Mithrandir> laga: use "$@" or just for i; do ... ; done
[11:19] <asac> communication with sound server? over ssl?
[11:19] <laga> Mithrandir: thanks
[11:19] <asac> ogra_cmpc: please fix it ;)
[11:19] <ogra_cmpc> asac, whats wrong with it ?
[11:19] <asac> ogra_cmpc: from the strace it looks like it invalidates file descriptors and finally crashes firefox/youtube
[11:20] <asac> ogra_cmpc: go to youtube ... select a video with sound ... and push backwards and forwards ... wait till sounds start. repeat
[11:20] <asac> crash!
[11:20] <ogra_cmpc> asac, aha
[11:20] <ion_> laga: sh -c 'set -- "foo bar" "baz x"; printf "%s\n" "$@"' and sh -c 'set -- "foo bar" "baz x"; printf "%s\n" $@'
[11:20] <ogra_cmpc> asac,
[11:20] <ogra_cmpc>   * built with tls support patch from Daniel T. Chen <crimsun@fungus.sh.nu>
[11:20] <ogra_cmpc>     https://code.edge.launchpad.net/~crimsun/libflashsupport-pulse/devel
[11:20] <asac> ogra_cmpc: yeah i disabled that already
[11:20] <asac> by default it uses OPENSSL
[11:21] <ion_> laga: And yeah, as Mithrandir said, plain “for i” is sufficient.
[11:21] <ogra_cmpc> asac, originally it used libssl
[11:21] <asac> that patch switches to gnutls
[11:21] <asac> yeah ... but that didn'thelp
[11:21] <ogra_cmpc> well, then its not ssl related i'd say
[11:21] <asac> i even switched from PULSEAUDIO to ALSA ... in that way the crashes are even more frequent
[11:21] <ogra_cmpc> yeah, flashsupport shouldnt be hooked between flash and alsa
[11:21] <laga> ion_: thanks
[11:22] <asac> ogra_cmpc: well. it was just to evaluate
[11:22] <ogra_cmpc> its really only to work around pulse not closing its handles
[11:22] <ogra_cmpc> err flash
[11:22] <ogra_cmpc> not pulse
[11:22] <asac> ogra_cmpc: and see where the problem might be. so given that neither SSL nor the sound output is responsible i guess that its really in the core of flashsupport
[11:22] <asac> they have a worker thread for instance.
[11:23] <asac> maybe that tries to access filedescriptors after firefox already closed the page or something
[11:23] <ogra_cmpc> did you check the urls listed in the package description ?
[11:23] <asac> ogra_cmpc: i don't see that purpose in the code
[11:23] <asac> ogra_cmpc: for updates? Luke did. there is no new code
[11:23] <ogra_cmpc> but probably info we dont know yet :)
[11:24]  * ogra_cmpc looks
[11:25] <asac> ogra_cmpc: #225  Deadlock/crash in flashsupport closing stream
[11:25] <asac> maybe that ticket
[11:26] <ogra_cmpc> hmm, the only git checkin is a version change to support pulse 0.9.5
[11:26] <cjwatson> laga: as a general rule, double-quote all parameter expansions in shell unless you know that you have an explicit reason not to do so
[11:27] <asac> ogra_cmpc: yeah. thats what luke told me
[11:27] <asac> damn. now gdb crashes if you run firefox from within
[11:28] <asac> doko: ^^
[11:30] <ogra_cmpc> so that looks like there a partial fix already
[11:31] <ogra_cmpc> 6 lines is not that much, but seems there is more to fix ...
[11:33] <asac> ogra_cmpc: where?
[11:33] <asac> in the ticket?
[11:33] <ogra_cmpc> yeah
[11:33] <asac> oh in the mids of the long pastes there is indeed something
[11:33]  * asac reading
[11:34] <asac> let me try that
[11:34] <ogra_cmpc> http://paste.ubuntu.com/6658/
[11:34] <ogra_cmpc> but apparently that doesnt fix it completely yet
[11:37] <asac> hmm
[11:38] <ogra_cmpc> works ?
[11:39] <asac> ogra_cmpc: no, but i had a hacked version trying a clean one now
[11:39] <cjwatson> laga: (cases where you would generally not want to double-quote parameter expansions are when they're the operand to 'case', or when you want to deliberately word-split something)
[11:39] <asac> ogra_cmpc: how is that supposed to fix a dead lock?
[11:40] <laga> cjwatson: i once read a good explanation of all that, but i forgot half of it, hence my question :) thanks for the explanation
[11:41] <cjwatson> laga: http://www.greenend.org.uk/rjk/2001/04/shell.html is a good article by a friend of mine on the subject
[11:42] <asac> ogra_cmpc: now it crashes firefox when playing the video for first time
[11:42] <laga> cjwatson: thanks, bookmarked
[11:44] <ogra_cmpc> asac, as i understand it he tries to kill the thread before it can lock up
[11:45] <doko> asac: architecture specific?
[11:49] <ogra_cmpc> asac, http://www.pulseaudio.org/ticket/225#comment:4 is the relevant info here i think
[11:50] <asac> doko: i don't think so.
[11:51] <asac> doko: can you try to start gdb /usr/lib/firefox-3.0b5/firefox
[11:51] <asac> run
[11:51] <asac> with dbgsym for xulrunner-1.9 and firefox-3.0 installed?
[11:51] <asac> maybe flashplugin-nonfree and libflashsupport-dbgsym as well
[11:52] <asac> ogra_cmpc: hmm. we could use a timed mutex then in shutdown
[11:54] <ogra_cmpc> i wonder if there is simply siomething missing in FPX_SoundOutput_Close
[11:54] <ogra_cmpc> where the heck is p DEFINED
[11:54] <ogra_cmpc> oops
[11:55] <asac> ogra_cmpc: pulse doesn't provide such a timeout lock
[11:55] <asac> ogra_cmpc: unlikely that p is not allocated :)
[11:55] <ogra_cmpc> no, i mean not freed correctly
[11:56] <asac> ogra_cmpc: zeroing is done in line 943
[11:56] <ogra_cmpc> FPX_SoundOutput_Close frees p->mainloop, ->context and ->stream
[11:56] <asac> and alloc in the line before
[11:58] <asac> ogra_cmpc: i think its created in init and then only kept as user_data in the callback
[11:58] <asac> ogra_cmpc: pa_context_set_state_callback(p->context, context_state_cb, p);
[11:59] <ogra_cmpc> hmm, what about p->first ?
[12:00] <asac> welll and a few more callbacks get that
[12:00] <asac> so maybe we really get a call with that as data after free
[12:00] <asac> for instance _write_callback might be  a candidate
[12:01] <asac> maybe we can cancel those explicitly on free?
[12:01] <ogra_cmpc> write_data breaks oif p->first is 1 and then sets it to 0 ... but it doesnt get freed
[12:01] <ogra_cmpc> at least not explicitly anywhere
[12:03] <asac> so what is first?
[12:03] <asac> just a bool thing?
[12:04] <cjwatson> tjaalton: do you know if there's been any progress on bug 184651, or if it needs help? It's assigned to you
[12:04] <ogra_cmpc> it indicates that there is a connection to flash as i understand it
[12:04] <ubotu> Launchpad bug 184651 in xorg-server "Crash when starting gnome-settings-daemon, in SrvXkbFreeGeomRows()" [High,In progress] https://launchpad.net/bugs/184651
[12:05] <cjwatson> tjaalton: setxkbmap (to Brazilian and back) might be an easier way to test it than messing with gnome-settings-daemon
[12:05] <asac> ogra_cmpc: also maybe interesting that we goto fail; instead of goto unlock_and_fail in line 693 even though we have a lock
[12:05] <tjaalton> cjwatson: I'm about to upload it :)
[12:05] <asac> ogra_cmpc: first == no connection to flash?
[12:06] <asac> i cannot map that ;)
[12:06] <cjwatson> tjaalton: hooray :-)
[12:06] <ogra_cmpc> asac, if (!p->first && !pa_stream_get_timing_info(p->stream))
[12:06] <asac> ogra_cmpc: maybe it indicates if its the first write_data ?
[12:06]  * cjwatson blats yet another dup of it
[12:06] <asac> call after _Open?
[12:07] <ogra_cmpc> hmm
[12:07] <ogra_cmpc> line 890: p->first = 0; /* So, we write the first block noch, remember that */
[12:08] <asac> ogra_cmpc: let me try to null out the callbacks before freeing the context
[12:08] <ogra_cmpc> so p->first seems to indicate the first data blck
[12:10] <asac> yeah
[12:10] <cjwatson> does anyone happen to know if there's an appropriate GTK style for warning text that would render it as red? I don't really feel good about hardcoding the colour. Bug 204053
[12:10] <asac> i think first isok
[12:10] <ubotu> Launchpad bug 204053 in ubiquity "Make warning text in Ubiquity red" [Wishlist,Confirmed] https://launchpad.net/bugs/204053
[12:26] <Riddell> evand: erk, ubiquity has stopped being able to change the mount point
[12:28] <cjwatson> Riddell: in bzr?
[12:28] <Riddell> cjwatson: today's daily CD
[12:28] <cjwatson> I expect that's my fault
[12:28] <cjwatson> you said my changes worked ;-)
[12:28] <Riddell> kubuntu
[12:28] <Riddell> cjwatson: yeah, I can't remember if I tested setting the mountpoint
[12:28] <Riddell> I'd have thought I would, but maybe not
[12:28] <cjwatson> I'm syncing the Kubuntu daily now and will check once I've got it
[12:29] <cjwatson> or I can help you fix it if that would be quicker
[12:29] <cjwatson> Riddell: is this while creating a partition, or while editing a partition?
[12:30] <cjwatson> Riddell: and is it by selecting from the dropdown, or by typing it in?
[12:33] <Riddell> cjwatson: selecting the dropdown
[12:33] <Riddell> while editing a partitio
[12:34] <cjwatson> Riddell: and presumably the symptoms are that it accepts it in the dialog, but then doesn't actually change it when you press OK?
[12:35] <Riddell> cjwatson: yes
[12:36] <cjwatson> damn, it's working in gtk and that bit's basically the same
[12:36] <cjwatson> can I have syslog just in case it's a stupid crash or something?
[12:36] <cjwatson> (and /var/log/installer/debug)
[12:37] <Riddell> hang on, jockey seems to have frozen the entire machine while installing broadcom firmware
[12:39] <Riddell> cjwatson: http://kubuntu.org/~jriddell/tmp/syslog
[12:39] <Riddell> running on my installed machine
[12:40] <Riddell> exception near the bottom
[12:40] <Riddell> http://kubuntu.org/~jriddell/tmp/debug
[12:44] <cjwatson> Riddell: whoopsie
[12:44] <Riddell> cjwatson: http://kubuntu.org/~jriddell/tmp/kde_ui.diff
[12:44] <Riddell> seems to sort it
[12:53] <Riddell> cjwatson: committed
[12:58] <ion_> mvo: Has there been any progress with the apt+zsync thing, btw?
[13:03] <cjwatson> Riddell: thanks, I was on the phone so you beat me to it
[13:04] <seb128> $ dpkg --compare-versions 2.22.1 gt 2.22.01; echo $?
[13:04] <seb128> 1
[13:04] <seb128> bah
[13:11] <Riddell> pitti: after using jockey to install broadcom firmware on a live CD session, any process using the network freezes
[13:13] <Riddell> oh, pitti's away
[13:15] <Riddell> cody-somerville: possibly this was intended to go to you https://bugs.edge.launchpad.net/ubuntu/+source/abiword/+bug/202174/comments/30
[13:15] <ubotu> Launchpad bug 202174 in abiword "Please update to version 2.6" [Undecided,New]
[13:16] <cody-somerville> Riddell, thanks. It was.
[13:23] <cjwatson> lamont: in case you don't read bug mail, could you have a look at bug 206113, please?
[13:23] <ubotu> Launchpad bug 206113 in util-linux "Wubi install cannot create swap space (8.04 Beta) [Regression from alpha 6]" [Undecided,New] https://launchpad.net/bugs/206113
[13:25] <lamont> cjwatson: I don't read bug mail generally, thanks
[13:26] <lamont> hrm... although that does leave me wondering where I auto-filed the mail...
[13:27] <lamont> cjwatson: it'll be this afternoon latish sometime, and I'll work on that.  (after 2200UTC)
[13:28] <cjwatson> thanks
[13:29] <lamont> go ahead and assign it to me if you want - either way, it's top of the list when I get my core-dev hat back on.
[13:35] <seb128> asac, pochu: what was this firefox font issue happening when using the xrandr capplet?
[13:37] <pochu> seb128: bug 178558
[13:37] <ubotu> Launchpad bug 178558 in xulrunner-1.9 "Firefox 3.0 makes everything annoyingly huge" [High,Fix released] https://launchpad.net/bugs/178558
[13:38] <seb128> xrandr1.2 seems quite broken
[13:38] <seb128> xorg detects the dpi correctly
[13:38] <seb128> but as soon as you use the new capplet on an intel965 card you get broken dpi values
[13:39] <seb128> ie, xpdyinfo lists 1x1 for example
[13:40] <ogra_cmpc> thats tiny :)
[13:45] <ScottK> mvo: I see you updated my pyspf package for Dapper -> Hardy upgrades.  I'm pretty sure python-dns will also need doing.  I'll take care of that one so you can mark it off your list.
[13:48] <cjwatson> lamont: ok, done
[13:56] <lamont> dear firefox.  please stop stealing focus and let the window manager do its job.  kthx
[14:01] <mvo> ScottK: great, thanks
[14:02] <ScottK> mvo: Actually looking at it now.  The python-dns we have in Dapper was so unmaintained it didn't actually provide python version specific binaries
[14:02] <ScottK> So it looks like due to poor maintenance two years ago we get off easy now.
[14:03] <jdong> asac: what's the least messy way for me to make firefox "open with" a single app for everything?
[14:04] <rrittenhouse> I went to upgrade hardy this morning to grab the latest packages and I'm just wanting to see if this was a problem on my end or your end. When updating it tries to install ia32-libs (im running 64bit hardy) I get an error msg stating that the ia32-libs package is trying to overwrite /usr/lib32/gtk-2.0/2.10.0/loaders/svg_loader.so which is also in package vmware-server
[14:04] <cjwatson> that's a vmware-server bug
[14:05] <rrittenhouse> ah ok
[14:05] <cjwatson> it shouldn't be shipping files in that directory
[14:05] <mvo> ScottK: heh :) good, python-dns dosen't show up in my scanner for the missing conflicts/replaces so that is good news
[14:05] <cjwatson> if it needs to ship them itself for whatever reason (but really, it shouldn't), then it should use a private directory
[14:07] <lamont> dear firefox. when picking a window to use for a "open in browser" thang, please prefer the ONE IN THE CURRENT WORKSPACE
[14:07] <Hobbsee> lamont: it picks the last used one instead?
[14:07] <lamont> yep
[14:08] <lamont> and drags it across several workspaces to get here.
[14:08] <Hobbsee> yeah.  i don't think firefox groks workspaces - or focus.
[14:08] <lamont> not a regression though
[14:08] <lamont> for either
[14:08] <lamont> simply pain
[14:08] <mvo> lamont: are you running the latest metacity? or compiz?
[14:08] <Hobbsee> with kde you could fix that.
[14:08] <Hobbsee> but i don't remember it being a problem (it changing work spaces) with compiz for a long while either.
[14:09] <lamont> mvo: on this machine, I have yet to have compiz come up....  what do I need to tweak where (restarted gdm and X after (re)installing compiz, still no compiz love)
[14:09] <mvo> lamont: click on system/preferences/apperance/desktop effects
[14:09] <lamont> Hobbsee: it doesn't change workspaces, it drags a ffox window from another workspace to here.
[14:09] <Hobbsee> lamont: sorry, that's what i meant.
[14:10] <Hobbsee> (was unclear that it == firefox, in my statement)
[14:11] <rrittenhouse> I'm also getting "no space left on device errors" is that something with hardy?
[14:11] <lamont> meh.  "please reboot so we canz have the closed nv driver, kthx"
[14:11] <lamont> mvo: thanks - I'll reboot later today then
[14:12] <mvo> lamont: yeah, the joy of binary-only drivers
[14:16] <cjwatson> ogra_cmpc: could you reassign bug 207634 to the proper place? I doubt it belongs on ubiquity
[14:16] <ubotu> Launchpad bug 207634 in ubiquity "LTSP amd64 installs 64bit clients software" [Undecided,New] https://launchpad.net/bugs/207634
[14:16] <ogra_cmpc> heh, i wonder how it ended up there first place :)
[14:17] <stgraber> hmm, LTSP assigned to ubiquity ? :)
[14:19] <\sh> cjwatson, TB devices are working
[14:20] <cjwatson> \sh: excellent
[14:20] <cjwatson> \sh: though I hope that's >2TB?
[14:21] <cody-somerville> slangasek, As I suspected, those errors yesterday were just intermittent.
[14:21] <\sh> cjwatson, you can bet on it :)
[14:34] <asac> jdong: hmm
[14:36] <cjwatson> Riddell: bug 203626 looks very ugly; does it show up that way by default?
[14:36] <ubotu> Launchpad bug 203626 in ubiquity "Kubuntu installer: Edit partition dialog rendering error" [Undecided,New] https://launchpad.net/bugs/203626
[14:36] <cjwatson> Riddell: can we just remove all the sizeHints from the .ui files? :-P qt4-designer seems to like to add them from time to time
[14:42] <TheMuso> If anybody happens to be running hardy on a PowerPC, if you could please try this new yaboot package, to fix G5 SATA issues. http://www.themuso.id.au/ubuntu/yaboot_1.3.13a-1ubuntu5_powerpc.deb Works for me on my G4, and the author tested on a few machines, but the more it is known to work on other machines the better. If all is favourable, please ping/message me, and I can then get it uplaoded. Thanks in advance.
[14:43] <Riddell> cjwatson: yes, that would probably work
[14:51] <ogra_cmpc> asac, do we have a bug open for the libflashsupport issue ? i'm just talking to warren in #ltsp (libflashsupport maintainer in fedora)
[14:51] <asac> ogra_cmpc: no, because we cannot get a good backtrace
[14:51] <asac> i have a upstream crash report though
[14:52] <asac> (so its not only us)
[14:52] <ogra_cmpc> yeah
[14:52] <ogra_cmpc> do you know when it broke ?
[14:52] <asac> ogra_cmpc: http://crash-stats.mozilla.com/report/index/49e43885-e464-11dc-8f26-001a4bd43e5c
[14:53] <ogra_cmpc> (or do you mind coming over to #ltsp so i dont need to proxy warren :) )
[14:53] <asac> ogra_cmpc: i think it either was always broken (e.g. we didn't use pulseaudio + flashsupport combo)
[14:53] <ogra_cmpc> i think flash changed
[14:53] <asac> ogra_cmpc: yes. probably wasn't the problem when flash didn't use xembed
[14:53] <ogra_cmpc> ltsp users used that setup in gutsy
[14:53] <asac> which was about 2 flash releases away
[14:54] <ogra_cmpc> (we didnt have it buy default though)
[14:54] <asac> ogra_cmpc: but you said that you cannot reproduce it in ltsp ... so maybe you just didn't see it
[14:56] <ogra_cmpc> asac, well, i had plenty other firefox issues in gutsys ltsp it probably just was hidden behind the ram problems
[14:57] <asac> ;)
[14:57] <asac> ogra_cmpc: question is: can you reproduce it now?
[14:57] <asac> anyone still has a rotting old flash on his disk? (something older than 6 month?)
[14:58] <asac> i'd really like to see if this is a flash regression
[14:58] <\sh> slangasek, any reasons why we didn't sync/merge php 5.2.5 for hardy?
[14:58] <ogra_cmpc> asac, not atm, i'm testing flash on the classmate a lot and the browser runs stable .... i havent tested on ltsp
[14:58] <asac> ogra_cmpc: classmate uses flashsupport + pulse?
[14:59] <asac> that would really go together with the caused-by deadlock thing
[14:59] <asac> most likely classmate has a different thread scheduling due to its constraints :)
[14:59] <lamont> cjwatson: I want an escape in ControlPath for 'source IP' address or some other easy-to-control thing
[15:00] <asac> ogra_cmpc: http://crash-stats.mozilla.com/report/index/49e43885-e464-11dc-8f26-001a4bd43e5c
[15:00] <asac> ogra_cmpc: oh sorry. alrady posted that above
[15:00] <ogra_cmpc> asac, indeed it uses whatever we have by default
[15:00] <cjwatson> lamont: %l for local host name not good enough?
[15:01] <ogra_cmpc> asac, warren asks if you could come over for a sec (#ltsp)
[15:06] <lamont> cjwatson: I have a big-fat-routing hack where there's an additional IP on the host, and packets from that IP get routed/SNATed out a diff ISP...
[15:06] <cjwatson> lamont: bugzilla.mindrot.org would be the best place to ask, then
[15:06] <cjwatson> if I add it locally they'll just do it with a different option letter later ;)
[15:08] <Riddell> cjwatson: today's kubuntu desktop CD has universe disabled in sources.list
[15:10] <lamont> cjwatson: very true
[15:10] <lamont> thanks
[15:11] <cjwatson> Riddell: the live CD itself always has, AFAIK; shouldn't affect what's in place after installation
[15:11] <cjwatson> if you want to change that, livecd-rootfs is the place, but you should probably take care to do that only after installing everything
[15:16] <cjwatson> Riddell: is there time to fix bug 203660 by creating a QMessageBox by hand as described in http://doc.trolltech.com/4.3/qmessagebox.html? I agree with Celeste that the current display is confusing
[15:17] <ubotu> Launchpad bug 203660 in ubiquity "Partition formatting message unclear" [Medium,Triaged] https://launchpad.net/bugs/203660
[15:21] <ogra_cmpc> cjwatson, hmm, is the d-i question for the installer language asked on purpose ?
[15:21] <ogra_cmpc> (i dont mean the gfxboot one)
[15:21] <cjwatson> ogra_cmpc: only if you select English in gfxboot; and yes, that's on purpose in case people just take the default
[15:22] <ogra_cmpc> i selected german
[15:23] <cjwatson> ah, I know, this is because I haven't uploaded debian-installer recently
[15:23] <cjwatson> so it's still using the localechooser without that feature
[15:23] <ogra_cmpc> ah
[15:23] <cjwatson> (I changed how this stuff works in response to bug 85162
[15:23] <cjwatson> )
[15:23] <ubotu> Launchpad bug 85162 in localechooser "installer doesn't permit to set little countries" [High,Fix released] https://launchpad.net/bugs/85162
[15:24] <ogra_cmpc> nice description :)
[15:24] <Riddell> cjwatson: yes that dialogue should be fairly easy to fix, I think it just wasn't possible or I couldn't see how when I first ported it to qt4
[15:24]  * Riddell adds to TODO
[15:25] <cjwatson> thanks
[15:26] <cjwatson> ogra_cmpc: uploading
[15:26] <ogra_cmpc> i'll test with the next build if its gone ...
[15:29] <TheMuso> Keybuk: Do you have a minute to discuss some initramfs/mdadm stuff?
[15:29] <Keybuk> TheMuso: sure, what's up?
[15:30] <TheMuso> Keybuk: Re the initramfs error handling spec at https://wiki.ubuntu.com/HardyInitramfsErrorHandling, I'm trying to get a mount root failure hook to execute for mdadm if a RAID array cannot be brought up. The hook gets executed from the panic function, however this does not happen because the md device node exists even if the array cannot be brought up.
[15:31] <TheMuso> Keybuk: What I'm thinking of doing is making the panic while loop get executed if either the root device node doesn't exist, or vol_id can't identify the device/volume. However I am wondering if there is a better solution, or whether this might break something else.
[15:31] <kagou> pitti, around ?
[15:31] <Keybuk> I'm not entirely sure I follow
[15:32] <Keybuk> the mountroot() function in the initramfs runs alongside udev
[15:32] <Keybuk> which itself runs alongside the kernel which is busy poking and probing for things
[15:32] <Keybuk> so device nodes may show up at any time inside mountroot(), not when you're expecting them
[15:32] <Keybuk> this is why mountroot() has a while loop that waits for the device node to exist
[15:32] <Keybuk> since that's a good indication that the block device has been detected
[15:32] <Keybuk> for mdadm devices, the device node is created when the array is detected
[15:33] <Keybuk> this does not mean that the array is functional
[15:33] <Keybuk> since the array can be detected if metadata is found on another drive about it
[15:33] <Keybuk> or if just one drive of the set has turned up
[15:33] <TheMuso> Keybuk: I gathered as much.
[15:33] <TheMuso> re mdadm
[15:33] <Keybuk> so mountroot() also tests the root device with vol_id
[15:33] <ogra_cmpc> dont you have a uuid you can wait for ?
[15:33] <ogra_cmpc> ah
[15:33] <Keybuk> which actually examines the filesystem on the root device
[15:33] <TheMuso> Waiting for a device is not the issue.
[15:34] <Keybuk> as ogra says, if you have UUID= this is largely irrelevant since you won't have the target filesystem UUID until the array is functioning *anyway*
[15:34] <Keybuk> this is for ROOT=/dev/md1
[15:34] <TheMuso> I'm talking about the point where the script gives up, and panics.
[15:34] <Keybuk> ok
[15:34] <Keybuk> so after a while, the script gives up and panics
[15:34] <Keybuk> if they're using ROOT=UUID=... you're pretty buggered, since you don't know it's on a RAID device
[15:35] <Keybuk> if the UUID has shown up, you wouldn't be panicking
[15:35] <TheMuso> Yep, that I also know. The issue here, is the above spec outlined details of some information being given to the user in the form of a mountroot failure hook, that gets executed before the script drops you to a shell.
[15:35] <Keybuk> ok
[15:35] <ogra_cmpc> long term the panic function should be enhanced imho
[15:35] <Keybuk> in which case, you have several cases
[15:35] <Keybuk> 1) the $ROOT device doesn't exist
[15:35] <Keybuk> 2) the $ROOT device exists, but vol_id fails
[15:36] <Keybuk> for (2), if $ROOT looks like an md device, you can assume the array is broken in some way
[15:36] <TheMuso> Right. At the moment, these hooks are executed in the panic function, if panic is passed an extra argument. However since the md device node exists, the panic doesn't occur, and the script crashes out later anyway.
[15:36] <Keybuk> actually that's only really two cases, not several ;)
[15:37] <Keybuk> the panic should occur?
[15:37] <Keybuk> mountroot() will panic if the array exists, but hasn't been activated
[15:37] <Keybuk> so [ -e $ROOT ] is true
[15:37] <Keybuk> but /lib/udev/vol_id $ROOT will be false
[15:37] <Keybuk> ie. array node exists, but filesystem on it cannot be found
[15:37] <TheMuso> Yes thats right.
[15:37] <Keybuk> at that point, if $ROOT is /dev/md*, you can just use mdadm to probe it and provide useful feedback
[15:38] <Keybuk> oh
[15:38] <Keybuk> I see
[15:38] <Keybuk> there's a bug in the initramfs script ;)
[15:38] <Keybuk> it loops while the device doesn't exist, or vol_id fails
[15:38] <Keybuk> but only panics if the device doesn't exist
[15:38] <Keybuk> thus your problem
[15:38] <Keybuk> :p
[15:38] <TheMuso> Yes.
[15:38] <Keybuk> I honestly think that's just a bug in the initramfs script
[15:39] <Keybuk> vol_id was added later, so was obviously missed on the third point it was needed
[15:39] <TheMuso> Right, I was thinking of adding it to that lop anyway, so panic gets triggered and still gives the user meaningful info.
[15:39] <Keybuk> that second while should match the first while, and the if
[15:39] <Keybuk> yes
[15:39] <Keybuk> that is what I would do
[15:40] <TheMuso> Ok. Was just wonderng if that would be likely to break anything else.
[15:40] <Keybuk> shouldn't think so
[15:40] <TheMuso> I've already tested these changes locally, and they work 100%.
[15:40] <TheMuso> Keybuk: Ok thanks for your time.
[15:41] <Keybuk> could you do me a favour while you're in there?
[15:41] <TheMuso> Keybuk: Sure.
[15:41] <Keybuk> the init script in initramfs
[15:41] <Keybuk> the very last line is exec run-init
[15:41] <Keybuk> it could do with a 2>&1 on the end ;)
[15:41] <TheMuso> Of the whole line?
[15:41] <Keybuk> yeah
[15:41] <Keybuk> should be
[15:41] <Keybuk> exec run-init ${rootmnt} ${init} "$@" <${rootmnt}/dev/console >${rootmnt}/dev/console 2>&1
[15:42] <TheMuso> Yep I can do that. What is this supposed to be fixing?
[15:42] <Keybuk> fixes the long-standing bug that init has no stderr :-)
[15:42] <TheMuso> haha right.
[15:42] <pwnguin> the more i look at initramfs scripts, the more i understand why they're not fixed =(
[15:42] <TheMuso> pwnguin: The whole initramfs infrastructure is not too bad actually, once you get your head around it.
[15:42] <laga> hah
[15:43] <TheMuso> Keybuk: Ok, will do that. Thanks again.
[15:43] <pwnguin> TheMuso: then feel free to have a look at bug #203429
[15:43] <ubotu> Launchpad bug 203429 in initramfs-tools "resume script missing functions" [Undecided,Confirmed] https://launchpad.net/bugs/203429
[15:44] <TheMuso> pwnguin: Ok...
[15:44] <Keybuk> TheMuso: patch looks good to me
[15:45] <TheMuso> Keybuk: Ok, will throw it in as well.
[15:46] <ogra_cmpc> initramfs ... <3
[15:46] <pwnguin> so is initramfs really the kernel team's purvue?
[15:47] <pheld> are there any hardy locale-packages for FF3 somewhere?  or updated locale for FF2?
[15:47] <Keybuk> pwnguin: not really, it's one of those things that doesn't really belong to the kernel or to userspace
[15:47] <Keybuk> one of my long-term goals is to make it just an extension of userspace
[15:49] <pwnguin> oh, btw Keybuk. i haven't been able to reproduce it lately, but thinkfinger in hardy is occasionally triggering an infinite look in hal-input-addon or something. if i can ever get it again, i'll make sure to document it well
[15:49] <Keybuk> interesting
[15:50] <pwnguin> i tried having a look at the package for interesting changes, but the diff.gz includes most/all of upstream svn
[15:50] <Keybuk> I'm not entirely happy with thinkfinger in general
[15:50] <Keybuk> I managed to find all sorts of little threading issues with it
[15:50] <pwnguin> i dont think anyone is
[15:50] <Keybuk> fprint is much better, but nowhere near complete enough
[15:55] <Riddell> ArneGoetje, freeflying: kubuntu-kde4 CDs have started being built again, scim-bridge-client-qt4 seems pretty broken for people who don't use scim.  if you don't have scim installed it delays startup by several seconds and if you do it insists on starting scim-gtk (not skim) and won't let you kill it
[15:56] <freeflying> Riddell: do u have any extra space for scim in cd?
[15:57] <Riddell> freeflying: not really, but it shouldn't force people to run an app they don't need
[15:58] <freeflying> Riddell: if not, I prefer to drop skim scim-bridge out, cause without scim and corresponding IMe, they really useless
[15:58] <Riddell> scim-bridge-client-qt (qt3) has no such problems, if you don't have scim installed it doesn't complain or delay apps starting
[16:15] <ScottK> doko: For python-central I think we are done with fixing everything.  For python-xml, it looks like zsi and pyslide need some additional work.  I'm out of bandwidth to deal with it.
[16:17] <doko> ScottK: thanks, these are still on my list
[16:17] <doko> ScottK: hmm, I did upload zsi ...
[16:18] <ScottK> doko: Yes, but there was some additional feedback on zsi.  I think either the feedback was invalid or additional change was needed.  I haven't have time to investigate.
[16:20] <ScottK> doko: For zsi see https://bugs.launchpad.net/ubuntu/+source/elisa/+bug/199014/comments/94
[16:20] <ubotu> Launchpad bug 199014 in pyslide "python-xml removal: please drop/replace (build) dependencies" [Undecided,In progress]
[16:30] <doko> ScottK: uploaded
[16:32] <ArneGoetje> Riddell: I told you before that you will need 4 packages installed: scim, scim-bridge-agent, scim-bridge-client-qt4, scim-bridge-client-qt.
[16:32] <ArneGoetje> Riddell: otherwise it doesn't work!
[16:32] <TheMuso> Ok, new initramfs-tools uploaded, and I'm off to bed.
[16:33] <Riddell> ArneGoetje: right, but even with scim installed (and we don't like gtk apps in kubuntu of course) it causes problems for non-scim users
[16:33] <Riddell> since it insists on starting scim and won't let you quit
[16:33] <ArneGoetje> Riddell: well, now you cannot use CJK.
[16:34] <Riddell> yes :(
[16:34] <ArneGoetje> Riddell: start skim and select it to be the gui for scim.
[16:36] <ArneGoetje> Riddell: you will need scim running in the background anyways. Skim is the KDE frontend to connect to the scim backend daemon.
[16:39] <Riddell> ArneGoetje: do you know why scim-bridge-client-qt4 insists on starting scim while qt/gtk clients do not?
[16:43] <ArneGoetje> Riddell: scim will always be running and is normally started with the X session. im-switch takes care of that.
[16:45] <ScottK> doko: Cool.  I guess we can mark that off as done then.
[16:47] <geser> keescook, jdstrand: as bug #214194 is marked security, I wanted to ask you if it's ok to set the bug to invalid based on my comment
[16:47] <ubotu> Launchpad bug 214194 in gnupg "GnuPG allows remote attackers to cause a denial of service" [Undecided,Confirmed] https://launchpad.net/bugs/214194
[16:50] <jdstrand> geser: yes-- this was also confirmed (as noted in ubuntu-cve-tracker)
[16:51] <emgent> hi jdstrand
[16:52] <jdstrand> hi emgent
[16:55] <keescook> geser: yeah, please do.
[16:55] <freeflying> ArneGoetje: Riddell also need scim-modules-socket
[16:57] <ScottK> freeflying: Riddell is going to upload the qt3 asian languages patch you pointed me at yesterday.
[16:58] <freeflying> ScottK: have u tested it already?
[16:58] <ScottK> No.  He was looking into it.
[16:58] <Riddell> freeflying: makes chinese characters in konqueror nicely
[16:59] <ScottK> My Kubuntu bandwidth is consumed by kde-guidance at the moment.
[16:59] <freeflying> Riddell: but can not handle it under en_US locale
[16:59] <freeflying> Riddell: oh, u mean ur patch?
[17:00] <Riddell> freeflying: yes, adding the patch fixes chinese characters in konqueror for me
[17:00] <emgent> keescook: have you saw anteater beta?
[17:00] <emgent> hi, btw :)
[17:01] <freeflying> Riddell: cool
[17:04] <doko> Riddell: what is a standard image viewer installed by default on Kubuntu?
[17:06] <Riddell> doko: gwenview
[17:09] <doko> Riddell: thanks
[17:13] <keescook> emgent: hi, took a brief look, seems nice.  :)
[17:13] <emgent> cool :)
[17:14] <doko> Riddell: hmm, but there's nothing like an alternative for a generic image viewer?
[17:17] <Riddell> doko: I don't understand
[17:18] <Riddell> doko: konqueror too of course (using gwenview's kpart)
[17:22] <crevette> who is Soren Hansen ?
[17:23] <crevette> hey I found :)
[17:23] <crevette> soren: around ?
[17:26] <cjwatson> Riddell: I think he means an alternative as in update-alternatives
[17:26] <cjwatson> isn't there an XDG way to spawn an image viewer given a file?
[17:26] <cjwatson> like xdg-open <filename>
[17:27] <ogra_cmpc> cjwatson, do you still se the hang in kvm when the X focus is gone ? apparently my virtualbox decided to behave similar
[17:27] <LaserJock> cjwatson: yep
[17:27] <cjwatson> ogra_cmpc: it was only when switching using Ctrl-Alt-<cursor>, so now I just press/release Ctrl-Alt and use the workspace switcher widget
[17:27] <ogra_cmpc> ah, k
[17:28] <ogra_cmpc> i have it with alt-tab my installs all failed at different points today
[17:28] <ogra_cmpc> its a bit tricky to put windows side by side on the classmate ... so i cant really avoid dropping the focus ...
[17:31] <cjwatson> my kvms are usually maximised
[17:33] <ogra_cmpc> ah
[17:38] <emgent> heya tseliot :)
[17:38] <tseliot> ﻿emgent: hi
[17:39] <LaserJock> who's archive day is it today?
[17:39] <cjwatson> LaserJock: http://wiki.ubuntu.com/ArchiveAdministration
[17:41] <LaserJock> seb128: can you accept flashplugin-nonfree into gutsy-proposed for me, thanks?
[17:43] <seb128> LaserJock: I technically can but it has to be approved by ubuntu-sru first no?
[17:43] <LaserJock> seb128: I approved it
[17:43] <seb128> bug number?
[17:43] <LaserJock> seb128: I just didn't want to sub you guys from a massive bug
[17:44] <seb128> sorry I've to go in a minute and I don't know enough about this update to feel comfortable to push it to stable
[17:44] <seb128> try to grab slangasek or pitti otherwise I'll have a look when I'm back
[17:45] <LaserJock> it's bug #173890
[17:45] <ubotu> Launchpad bug 173890 in flashplugin-nonfree "flashplugin-nonfree fails to install due to md5sum mismatch" [High,In progress] https://launchpad.net/bugs/173890
[17:45] <LaserJock> it's just a md5sum update going to -proposed
[17:45] <LaserJock> not -updates yet
[17:46] <cody-somerville> Which subdirectory of ~ubuntu-archive on p.u.c shows the diffs between what was pulled in yesterday and today to build the cd?
[17:47] <cjwatson> cody-somerville: that's buried in the appropriate CD build log under http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/
[17:47] <jdong> can an archive admin open flood gates on backports binary NEW?
[17:47] <jdong> in particular nexuiz is uninstallable in gutsy-backports because -data passed and the binaries are in NEW
[17:53] <Sveinung> What is the correct procedure to report that I have modified a source package that currently won't build (according to its page in Launchpad) so it builds (at least on my system)? I have filed a bug against it, but if that is the wrong way to do it pleace tell me.
[17:53] <Sveinung> the bug: https://bugs.launchpad.net/ubuntu/+source/dbus-java/+bug/204704
[17:53] <ubotu> Launchpad bug 204704 in dbus-java "dbus-java should work with IcedTea" [Undecided,New]
[17:53] <ScottK> That's the right way.
[17:53] <Sveinung> ok
[17:53] <Sveinung> thanks :)
[17:53] <ScottK> Sveinung: Even better, if you haven't, make a debdiff and attach it to the bug.
[17:54] <cjwatson> (or just an ordinary diff is usually fine.)
[17:54] <Sveinung> how is that different from a normal diff?
[17:54] <ScottK> Which is actually in there already.
[17:54] <infinity> Sveinung: After you "dpkg-buildpackage -S", you can "debdiff old_ver.dsc new_ver.dsc" and get a diff of the source packages.
[17:54] <ScottK> Sveinung: Since it's a multiverse package, #ubuntu-motu is a better channel.
[17:55] <Sveinung> The diff removes the dependency on unfree packages too
[17:55] <LaserJock> pitti: if you have a sec can you allow flashplugin-nonfree into gutsy-proposed?
[17:55] <ScottK> Which means it could be promoted to Universe (and #ubuntu-motu is still the right channel).
[17:55] <cjwatson> For some reason there is an idea floating around that debdiffs are much easier for sponsors to deal with. In practice it makes almost no difference and sometimes introduces extra work since you might well have to rewrite the changelog anyway.
[17:55] <Sveinung> ok. Thank you. I am new to Ubuntu
[17:56] <ScottK> No problem.  Glad to have you.
[17:56] <infinity> cjwatson: I'm 50-50 on changelog diffs, but debdiffing tends to provide more clean diffs than "diff tree-1 tree-2", since one of the trees might accidentally be uncleaned, etc.
[17:56] <ogra_cmpc> LaserJock, dunno if you noticed, i dropped the math, teaching and light desktop categories from edubuntu addon
[17:56] <Caesar> Doh
[17:57] <Caesar> I submitted a bug with the wrong title
[17:57] <toresbe> submit a bug
[17:57] <cjwatson> Caesar: "Edit description/tags"
[17:57] <Caesar> cjwatson: yeah, just saw it
[17:57] <infinity> Sveinung: A minor nitpick, if you're changing it to build-dep on openjdk-6-jdk, you might want to put the openjdk-6-jre dependency first in the ORed list, not last.
[17:57] <toresbe> "Bug #34235 has the wrong description"
[17:57] <ubotu> Launchpad bug 34235 in malone "+editstatus oopses if you clear out the source package name" [Medium,Fix released] https://launchpad.net/bugs/34235
[17:57] <toresbe> and then file a bug against the erroneous description bug when the bug is fixed
[17:58] <cjwatson> infinity: It annoys me when somebody attaches a diff to a bug that's perfectly good, and then some jobsworth comes along and asks them to attach a debdiff instead. That's an excellent way to give contributors the impression that we care more about form than substance.
[17:58] <infinity> Sveinung: (Which also makes it more obviously correct to say "it no longer depends on multiverse packages")
[17:58] <infinity> cjwatson: Oh, yes, I'm not going to insist on "ur diff is teh wrong formatz!!" or anything, I just recommend debdiff to those who aren't supplying useful patches at all.
[17:58] <Sveinung> infinity: thank you
[17:59] <\sh> guys, do we have an up2date software package for controlling powernow or speedstep cpus like athcool or powersaved in main? I wonder if we can get rid of old crap in universe
[17:59] <cjwatson> infinity: sure
[17:59] <cjwatson> I've just been railing against bits of our process that seem to be excessive, lately
[17:59] <infinity> cjwatson: Heh.
[18:00] <LaserJock> ogra_cmpc: yeah,saw something about it, didn't know about math and teaching though
[18:00] <LaserJock> ogra_cmpc: what'd we lose?
[18:00] <johanbr> \sh: That's mostly controlled with kernel governors now, I believe. That control happens in the powernowd package.
[18:00] <\sh> infinity, any update on wine for lpia and p-a-s?
[18:00] <ogra_cmpc> LaserJock, empty categories
[18:01] <ogra_cmpc> we didnt lose any packages
[18:01] <\sh> johanbr, so actually tools like athcool and friends are obsolete? (me doesn't use normally such things ;))
[18:01] <LaserJock> ogra_cmpc: we don't have any math apps?
[18:01] <infinity> \sh: Err, could the update be in the form of "doh, forgot, I'll do it right now"?
[18:01] <ScottK> cjwatson: For me, if I get a debdiff, it's their name in the changelog/their upload that I'm sponsoring.  If I have to write debian/changelog, then it's my name with thanks to.  I'd rather give them credit for the upload if they've done all the work.  That's why I prefer the debdiff.
[18:01] <ogra_cmpc> LaserJock, none in the cd menu at least
[18:01] <ogra_cmpc> what should be there ?
[18:02] <LaserJock> the KDE Edu math apps apps should be in there
[18:02] <LaserJock> tuxmath?
[18:02] <ogra_cmpc> games
[18:02] <cjwatson> ScottK: Nonsense. You can perfectly well edit the changelog trailer to include their name, or put their name in a "[ Happy Contributor ]"-type prefix.
[18:02] <ScottK> I could.
[18:02] <infinity> ScottK: That works for an upload that fixes one thing, but if their patch is being integrated into an upload with many fixes (as is more common for Debian packages, or stuff in main), it's more effort.
[18:02] <cjwatson> ScottK: This takes approximately two extra seconds.
[18:02] <\sh> infinity, i think you need to come to berlin @ linuxtag after UDS to relax a bit :) I know that feeling about forgetting some things, too :) then I need to reset my brain :)
[18:03] <cjwatson> and also what infinity said.
[18:03] <infinity> ScottK: I can see both sides, and I also care approximately 0% about it all, as long as there's SOME sort of usable patch. :)
[18:03] <\sh> infinity, but thx a lot :)
[18:04] <cjwatson> I care deeply about the fact that friends of mine have been put off contributing to Ubuntu because the first patch they send is ignored for months and then they get a request to resubmit it as a debdiff from somebody who clearly doesn't know anything about the software involved.
[18:04] <cjwatson> It doesn't give us a good impression at all.
[18:04] <ScottK> I definitely agree that getting the usable patch is 99% of it.  I guess we can argue about the 1%.
[18:04] <ScottK> Agreed on that.
[18:04] <LaserJock> cjwatson: well, we did have contributors getting upset that their name wasn't in the changelog
[18:04] <johanbr> \sh: I haven't heard of people using athcool nowadays. I'm not even sure it runs on modern AMD processors.
[18:04] <LaserJock> I think that was some of the motivation of trying to get them to do a debdiff we can sponsor straight off
[18:04] <ScottK> So maybe we need a clearer set of sponsoring guidelines.
[18:04] <cjwatson> LaserJock: I have no sympathy for sponsors who fail to credit contributors appropriately. It's not the contributor's fault for using the "wrong format".
[18:05] <infinity> The only other time I kinda like to see a "debdiff" (or, rather, changelog entries in the diff) is if the patch is so mind-numbingly complex and intrusive that I want some verbosity explaining WTF it does, but that can just as easily be done in a bug comment too.
[18:05] <cjwatson> The work should be the sponsor's, not fobbed off onto contributors.
[18:05] <\sh> johanbr, well yeah...debian just updated it for a single line of source change...since feisty imho
[18:05] <LaserJock> cjwatson: it's not failing to credit
[18:05] <LaserJock> cjwatson: it's that they don't show up in -changes or on their Launchpad pages if you don't
[18:06] <cjwatson> LaserJock: That's just dubious expectations, and we should probably reset those. As infinity said, if it had been rolled into a bigger upload they wouldn't have got that either.
[18:06] <LaserJock> and so if they eventually want to apply for MOTU they end up with an underestimate of their work
[18:06] <LaserJock> cjwatson: sure, we just don't have a lot of those in Universe/Multiverse
[18:06] <cjwatson> I think it's a much bigger issue that we're putting off people who might apply for MOTU later on.
[18:06] <LaserJock> cjwatson: most uploads are by a single person
[18:07] <cjwatson> or even who might be useful sources of patches even if they never choose to become developers
[18:07] <infinity> The point here is that unnecessary process is off-putting.
[18:07] <LaserJock> cjwatson: well, I agree but we do have a damned if we do, damned if we don't situation at times
[18:07] <infinity> I can't count the number of times I've reported a very clear bug, with obvious testcases, and had someone respond with "can we see lspci -vvv and dmesg output, please?"
[18:07] <cjwatson> Unnecessary process also slows us down, and in this business agility is pretty critical
[18:07] <infinity> And the same for patches, people insist on debdiffs, diffstats, etc.
[18:08] <cjwatson> diffstats! That was the other thing I was complaining about
[18:08] <LaserJock> I agree guys
[18:08] <cjwatson> What a totally useless metric for anything
[18:08] <LaserJock> but that's policy
[18:08] <\sh> LaserJock, depends....when you are working on a package with several fixes...I think I tend more to "Thx" or "Patch provided by <insert dude here>" ... just because, even if there is another name on the upload...if it breaks somehow, the sponsor get hit by some stone or will be crucified...
[18:08] <cjwatson> Broken policy should be changed.
[18:08] <infinity> The only thing diffstat tells me is "you didn't include 1.5MB of accidentally duplicated source in your patch".
[18:08] <infinity> Which is nice to know, and all, but...
[18:09] <LaserJock> cjwatson: agreed, just we keep changing policy all the time and it confuses people
[18:09] <cjwatson> you can't fall back on "but that's policy" to defend a criticism of policy
[18:09] <cjwatson> it doesn't make sense :-)
[18:09] <LaserJock> well sure it does
[18:10] <LaserJock> if your the MOTU
[18:10] <cjwatson> but I'm not
[18:10] <LaserJock> and can't just change policy
[18:10]  * _MMA_ smells a good UDS topic.
[18:10] <LaserJock> _MMA_: been, there, done that, still stinks
[18:10] <cjwatson> well, I can't "just change policy", that's why I'm complaining about it
[18:10] <cjwatson> or rather I suppose I could but you'd all shout at me :-)
[18:10] <LaserJock> *I* wouldn't ;-)
[18:10] <infinity> Changing policy doesn't change behaviour.
[18:10] <LaserJock> but some people might
[18:11] <infinity> This is a matter of education, not policy.
[18:11] <LaserJock> infinity: well, policy is to attach diffstat
[18:11] <infinity> Educating people that "a good patch is a good patch, don't just parrot 'no debdiff, you lose!'"
[18:11] <ScottK> I think what we really need are more sponsors.
[18:11] <cjwatson> That said, I *would* like (after discussion) to make it very clear that debdiffs and diffstats are not hard requirements for uploads to main
[18:11] <cjwatson> and then we'll be in the frankly bizarre situation that universe's requirements are stricter
[18:11] <LaserJock> cjwatson: Universe is often stricter
[18:11] <infinity> And educating people that if they really don't understand a patch, they should ask someone else to help them look at it, not ask for it in 3 more formats. :P
[18:11] <cjwatson> LaserJock: which is daft
[18:12] <LaserJock> we can't rely on common sense in Universe
[18:12] <LaserJock> so we need strict policies
[18:12] <cjwatson> but the consequences of failure are much less
[18:12] <ScottK> cjwatson: True, but the experience level of the contributors is much lower in many cases.
[18:12] <cjwatson> and increasing strictness does not improve quality, in general
[18:13] <cjwatson> strictness in itself is not a goal to be aimed for
[18:13] <ScottK> Agreed
[18:13] <LaserJock> well, the strictness is a reaction, IMO
[18:13] <cjwatson> reactions are often overcompensatory, and in such cases a counter-reaction is called for
[18:14] <infinity> \sh: Committed.
[18:14] <LaserJock> cjwatson: we've been doing counter-reactions since dapper
[18:14] <LaserJock> one Xorg upload and we've been swinging back and forth on SRUs ever since
[18:14] <cjwatson> look, I nominally own the stable release updates process, I know what excessive strictness does
[18:14] <cjwatson> and no, we actually haven't been swinging back and forth as far as main SRUs are concerned
[18:14] <LaserJock> I'm talking about Universe
[18:14] <cody-somerville> Maybe the strictness is necessary since the group of people working on universe are generally less skilled and have less experience. The strictness forces them to slow down and think and gain that experience to be able to work without such strictness. Just a thought.
[18:15] <cjwatson> the policy has been constant since dapper, with a few minor tweaks
[18:15] <LaserJock> as that seems to be what you are complaining about, correct?
[18:15] <cjwatson> and it's only recently that we're realising that we probably need to simplify it
[18:15] <ScottK> Universe has not been constant.
[18:15] <cjwatson> LaserJock: people apply the debdiff/diffstat madness to my packages in main, if I don't get to them first
[18:15] <cjwatson> so no, it's not just that that I'm complaining about
[18:15] <LaserJock> Universe has had something like 4 "SRU policy revisited" I think
[18:16] <cjwatson> cody-somerville: excessive strictness is not a good thing in itself. Every piece of bureaucracy should be justified
[18:16] <ScottK> We've gone from motu-sru must approve before upload to all MOTUs can upload, and back to motu-sru must approve before upload in Universe
[18:16] <_MMA_> This is also a manpower issue. There's often just not the people to help. So processes get put in place which put the work on new contributors.
[18:16] <LaserJock> cjwatson: ok, well then sorry for being Universe-specific there
[18:16] <cjwatson> what MOTU can do is actually sort of a different issue
[18:16] <cjwatson> I care more about what we're presenting to random drive-by contributors
[18:16] <cjwatson> since those are the people least likely to be interested in putting the effort in to cope with extra bureaucracy
[18:17] <LaserJock> I agree
[18:17] <cjwatson> in almost all cases they'll just give up and go away
[18:17] <LaserJock> look at Planet Gnome or Planet KDE for instance
[18:17] <LaserJock> there are increasingly more "Ubuntu bureaucracy is nuts"
[18:17] <Keybuk> _MMA_: isn't that a self-fulfilling doom?
[18:18] <Keybuk> we don't have enough people to review changes, so we make it harder for people to make them, and thus have even fewer people joining than before
[18:18] <LaserJock> do we have an alternative
[18:18] <cjwatson> commit-then-review and review-then-commit is a fairly long-established dichotomy; the problem is when it gets to (iterate-through-several-different-spurious-requirements)-then-review-then-review-then-commit-then-review
[18:18] <infinity> Or, to bring this home slightly more.  If I didn't have full ubuntu-{core-,}dev rights, I doubt I'd contribute to the distro at all, not because I don't like it, but because sending in a good patch with a good explanation, and being told it's "wrong" because the format is incorrect, or I missed a hoop to jump through is disheartening.
[18:18] <_MMA_> Keybuk: Just an observation since getting into development.
[18:18] <LaserJock> we don't have manpower so somebody else has to do it
[18:18] <\sh> infinity, thx :) when you meet lool in praque, please tell him: greetings from \sh, you owe me a drink , kthx :)
[18:18] <Keybuk> LaserJock: why does it have to be done at all?
[18:19] <_MMA_> Keybuk: There's just not a "best" solution. So processes get put in place and here we are.
[18:19] <cjwatson> LaserJock: we are not the only project of our size. Other projects of our size do not have the same requirements. Therefore there are alternatives, QED. :-)
[18:19] <LaserJock> Keybuk: what's the "it" there
[18:19] <Keybuk> LaserJock: I think that was what I was attempting to ask you ;)
[18:20] <LaserJock> Keybuk: well, some "it"s do need to be done
[18:20] <Keybuk> ?
[18:20] <LaserJock> we have a big list of fixed Debian RC bugs that *aren't* going into Hardy
[18:20] <Keybuk> it's not as if people are sending hand-written instructions to change the code
[18:20] <Keybuk> a patch either applies or doesn't
[18:20] <LaserJock> we have a list of FTBFS, uninstallable packages, etc.
[18:21] <LaserJock> every release we get hammered for not getting fixes in
[18:21] <elmo> Keybuk: there are people who send kernel patches, with mathematical proofs of the change, it's great
[18:21] <LaserJock> so there's quite a bit of pressure to get things in
[18:21] <cjwatson> _MMA_: saying "it's all fixed, might as well live with what we've got" is a pretty defeatist attitude; I think we're smart developers in an interesting and worthwhile project, and should be striving to make it the best we can even if that involves substantial changes
[18:21] <saivann> mjg59 : Do you know the answer to that? https://bugs.edge.launchpad.net/ubuntu/+source/usplash/+bug/205990/comments/28
[18:21] <ubotu> Launchpad bug 205990 in usplash "[hardy] splash screen disappears after a few seconds" [Medium,Confirmed]
[18:21] <_MMA_> cjwatson: Sorry to sound like a dick but are the 'drive by" people really the type of people we want to spend time on? Hell. Looks like Universe has a hard enough time keeping people who have gone through the process around. :)
[18:21] <cjwatson> _MMA_: yes
[18:22] <Keybuk> most of core-dev are what I would consider "drive by" people ;)
[18:22] <cjwatson> _MMA_: only a relatively small number of people actually want to be long-standing contributors to an operating system; but my experience is that there are lots of intelligent and useful contributors outside that fanatical subset
[18:22] <_MMA_> And sure. I've gotten a little jaded. :P
[18:22] <cjwatson> (also, I wouldn't be bringing this up if I weren't repeatedly seeing real examples of intelligent contributors driven away by process)
[18:23] <LaserJock> cjwatson: I think most MOTU appreciate the situation
[18:23] <Keybuk> those processes we have should be to ensure that any contribution, no matter how small or irregular, can make it into the distro
[18:23] <LaserJock> most Ubuntu Developers, period
[18:23] <cjwatson> LaserJock: _MMA_ challenged it, so I responded
[18:23] <\sh> LaserJock, tbh, actually you as contributor should do what you are willing to do...no one forces anyone to do things...if we don't get RC bugs fixed for universe, hell, we don't have the manpower...we are just people and most of us have a real life which is more important sometimes (only sometimes ;))
[18:23] <cjwatson> Keybuk: I'd modify that; we do need to ensure that there is quality control
[18:24] <cjwatson> but process in itself does not produce quality
[18:24] <cjwatson> it just ensures that the people you have are the type who are willing to endure process
[18:24] <LaserJock> \sh: which absolutely doesn't matter to upstreams/users/reviewers
[18:24] <LaserJock> Keybuk: they can
[18:24] <Keybuk> cjwatson: I'm a greater believer in "it's better to ask for forgiveness than permission"
[18:24] <_MMA_> Sure. At least in Universe, the "long-standing contributors" are a finite bunch with much work to do. The processes and barriers to "'drive by contributors" IMO have come out a lack of man-power.
[18:24] <Keybuk> (ie. review after upload)
[18:24] <cjwatson> Keybuk: to take it to extremes, I wouldn't want an automatic system that applied any patch it saw and rolled it into the distro
[18:25] <Keybuk> cjwatson: I know someone who does want that ;-)
[18:25] <_MMA_> *out of a
[18:25] <Keybuk> LaserJock: I don't think that they can.  I think that the amount of effort required to get a patch in is sufficiently great that most people don't bother
[18:25] <\sh> LaserJock, yes, but upstreams don't care about distributions...users don't care about people, and reviewers well, depends what review you want? I'm actually using ubuntu for business...and really, I'm proud about what we produced every release, with less power
[18:26] <Keybuk> (from my own talking to people, especially upstreams)
[18:26] <LaserJock> sure
[18:27] <cjwatson> but review should be based on a developer's brain, not on form; and what we're currently doing is absolutely based on form. It would be better to ignore a patch for years (and that's not good!) than to ignore it for half that time and then bounce back to the contributor with a comment that proves that the commenter isn't qualified to deal with the patch
[18:27] <LaserJock> I'm just saying we aren't throwing away patches
[18:27] <\sh> LaserJock, and if users and upstreams want something badly, I think we can invite them to work on what they want regarding ubuntu :) I don't chase them away :)
[18:27] <cody-somerville> I personally don't see the barrier that high.
[18:27] <cjwatson> people who contribute to free software projects are generally realistic; they know that they might sit there for ages until somebody gets round to them, and that's fine. What they hate is their patch ending up with somebody who knows even less about the code than they do
[18:28] <cjwatson> LaserJock: pretty sure I've seen examples of patches bouncing through process and eventually getting marked Invalid for lack of response by the contributor, without a real developer having time to get involved at any stage
[18:28] <LaserJock> cjwatson: well, that's the way Ubuntu works though
[18:28] <cjwatson> when it would have been better to just leave the patch alone
[18:28] <cjwatson> LaserJock: it shouldn't be!
[18:28] <LaserJock> cjwatson: most MOTU know much less about the software than contributors
[18:28] <james_w> Is there a list that gets notified when any bug has a patch attached?
[18:28] <cody-somerville> cjwatson, Then maybe the issue is the bug team?
[18:28] <LaserJock> we have like 20 people for 4k packages
[18:29] <cjwatson> MOTUs are generally smart and able to learn
[18:29] <cjwatson> that's part of the process
[18:29] <cjwatson> sure, they don't know a lot about it going in
[18:29] <LaserJock> they don't have time to learn
[18:29] <cjwatson> but in the process of dealing with a patch they should learn enough to be able to cope
[18:29] <LaserJock> MOTU is about pushing paperwork
[18:29] <cjwatson> come on, I'm not speaking without experience here
[18:29] <LaserJock> I know
[18:30] <LaserJock> but realistically I'm saying that many of the MOTU don't even know how to test the uploads their doing
[18:30] <cjwatson> being a distribution developer is about integrating other people's code, sure, but when you come to integrate a patch you teach yourself enough about the thing you're working on in order to do it
[18:30] <cjwatson> that's half of what makes it fun
[18:31] <cjwatson> and in any case I wasn't really talking about MOTUs, who from what I've seen generally do a decent job of patches once they're in their hands
[18:31] <LaserJock> a big problem seems to be bug triage
[18:31] <Keybuk> where I used to work, we had an interview test where you were given the code to a network daemon and had to add a "ping" command to it which replied "pong" when received
[18:31] <cjwatson> cody-somerville is right to some extent that it's a triage problem, but the policies on what's needed before a bug with a patch attached is triaged are set by MOTU
[18:32] <Keybuk> the idea being to test how well you could understand code you'd never seen before and how quickly you could modify it as requested
[18:32] <LaserJock> cjwatson: actually they really aren't
[18:32] <Keybuk> it always struck me that the kinds of people who do well as a distribution developer are the kinds that complete that test very quickly indeed
[18:32] <cjwatson> LaserJock: a better job than the problems I'm referring to, at least
[18:32] <LaserJock> cjwatson: bug work policies are mostly set by the QA team
[18:32] <cjwatson> I'm pretty certain the QA team would take advice from MOTU on bugs with patches if it were offered :-)
[18:32] <cody-somerville> People who don't know what they're doing are often triaging bugs and just give "programmed" responses.
[18:33] <cody-somerville> ie. The whole "No one has touched this bug in awhile, wanna see if it still happens just for the sake of it?"
[18:33] <\sh> cody-somerville, which is bad, too
[18:33] <cody-somerville> Why do they do that? Because they're lazy? I dunno.
[18:33] <LaserJock> cody-somerville: or "I'm closing this bug as it's had 30 days of no activity" even if it hasn't had anything from a dev
[18:34] <laga> cody-somerville: well, some/many bug reports can often be triaged by people who just paste canned responses like "what version of ubuntu are you using?" etc.. unfortunately.
[18:34] <zyx386> hi
[18:34] <zyx386> what is happning with my BUG?
[18:34] <zyx386> :)
[18:34] <broonie> laga: That sort of triage does tend to create an unfavourible impression in users if it's done without reading the bug.
[18:34] <saivann> Do you have so many examples of bug which are not correctly triaged?
[18:34] <\sh> laga, which is a bug in the "reporting bug mask in LP" we have many old bug reports with patches attached, which are already fixed upstream...which were reported during dapper times...
[18:35] <Keybuk> LaserJock: I get those
[18:35] <Keybuk> my reply varies from just reopening it again to livid hatred
[18:35] <laga> broonie: that's true.
[18:35] <\sh> laga, problem with those bugs, actually motu needs to take care about deciding if this is worth an SRU...but this means, more work on SRU, less work on latest devel release
[18:35] <Keybuk> or drive-by duppers
[18:35] <Keybuk> my *friends*(
[18:36] <zyx386> i report BUG about usb modem and hardy heron??
[18:36] <laga> \sh: yeah, i hear SRUs are a lot of paperwork.
[18:37] <\sh> laga, yepp...so, what to do? working on latest devel release is fun, and working on SRU is responsibility to not break working releases
[18:37] <\sh> laga, decide for yourself, where the prio will be set by a contributor :)
[18:37] <saivann> Well the ubuntu bug triage wiki documentation is pretty clear, but there is no information about bug that have patches, why not update it?
[18:37] <saivann> https://wiki.ubuntu.com/Bugs/HowToTriage
[18:38] <laga> \sh: especially if you don't get paid :) i'm working a lot with mythtv where there was a new upstream release after about 1.5 years.. all you can do with old bugs is asking if they're still showing up with the latest release because upstream won't support old releases anymore. (and i personally don't care either ;))
[18:38] <zyx386> saivann: that is my bug
[18:38] <zyx386> https://bugs.launchpad.net/ubuntu/+source/gnome-ppp/+bug/212980
[18:38] <ubotu> Launchpad bug 212980 in gnome-ppp "HuaWei E220 and is unknow!?" [Undecided,New]
[18:39] <awalton__> laga, we've got years and years of bugs like that in nautilus.
[18:39] <laga> awalton__: auto expiry for the win.
[18:40] <\sh> laga, see, we have a lack of people for security updates in universe (sometimes, it's less painful then SRUs but many of times, it's even harder) just because you need to know how to reproduce the bugger or sec issue...it's work for people with responsibility and who are taking care...it's difficult, we have special policies..and it's not fun to fix a sec issue in a release from 2006, but it needs to be done...and you always have to fear, that your
[18:40] <\sh>  update is breaking someone else installation...
[18:41] <\sh> laga, and money is not my motivation
[18:42] <zyx386> wel be fixed or not? this bug
[18:43] <laga> \sh: longer releases cycles (and longer feature freezes) would be a nice thing. it's hard to achieve that feeling of polish and shiny with SRUs :)
[18:43] <zyx386> because i have just usb modem to internet connection
[18:44] <saivann> zyx386 : maybe you can speak about this in #ubuntu-bugs
[18:44] <RainCT> zyx386: I've the same thing. I can explain you how to workaround that if you want. (In Gutsy it worked, btw)
[18:45] <cody-somerville> RainCT, Maybe you should post your workaround in the bug report for everyone to find?
[18:45] <zyx386> RainCT: i gutsy worked perfect, with ppp  or gnome-ppp or with vodafone driver for linux
[18:45] <\sh> laga, time doesn't matter
[18:45] <laga> \sh: with regard to what?
[18:46] <\sh> laga, release cycles...
[18:46] <zyx386> cody-somerville: :)
[18:46] <laga> \sh: you get more time to fix bugs
[18:47] <\sh> laga, yes, but for every bug you fix, there will be two new bugs  :)
[18:47] <RainCT> cody-somerville: well, it involves a bash script, wvdial and binary thing. I might create a package for it
[18:48] <zyx386> RainCT: i know that is worked not on hardy
[18:48] <laga> \sh: does that also mean you have less bugs if your release cycle is shorter? ;)
[18:48] <cody-somerville> RainCT, it would be nice if you could do what is required to fix it for Hardy. Is that your intention?
[18:49] <\sh> laga, no..that's what I meant with "time doesn't matter" :) manpower is what matters...and people who are tending to be hidden masochistics ;)
[18:49] <laga> \sh: yeah, that too
[18:49] <zyx386> RainCT: this dont worked on hardy http://wwwu.uni-klu.ac.at/agebhard/HuaweiE220/
[18:49] <RainCT> cody-somerville: I've no idea how to fix it, it seems to be a regression in network-admin (they added GRPS/UMTS support but actually what they did is break it, at least for us poor USB modem users :P)
[18:50] <RainCT> (how to fix it as in how to fix it properly)
[18:50] <\sh> RainCT, hmmm? in hardy?
[18:50] <RainCT> \sh: yes
[18:50] <\sh> RainCT, friend of mine is using his umts card with usb-modem quiet nicely...or are you taking about nozomi stuff?
[18:50] <\sh> s/taking/talking/
[18:50] <james_w> I've just sent a mail to the bugsquad list to hopefully get the ball rolling on getting the first step improved, that is getting patches under the eyes of someone who can have a stab at judging it's suitability.
[18:50] <cjwatson> james_w: thanks!
[18:51] <cjwatson> Let me tell you a story about contribution
[18:51] <RainCT> \sh: well, dunno if other models work, but at least the Huawei E220 isn't working anymore
[18:51]  * ogra_cmpc gets the popcorn
[18:51] <\sh> RainCT, hmm...qualcomm works
[18:51] <cjwatson> About eight or nine years ago, before I was a free software developer to speak of, I was investigating a bug in tar that I'd been bitten by
[18:51] <RainCT> zyx386: run this in a terminal:  cd ~ && wget http://utils.eurion.net/hosted/huaweiAktBbo-i386.out && sudo mv ~/Desktop/huaweiAktBbo-i386.out /usr/local/etc/huaweiAktBbo-i386.out && sudo chmod +x /usr/local/etc/huaweiAktBbo-i386.out
[18:52] <cjwatson> It turned out that this was actually a bug in glibc. I rolled my sleeves up, figured it out, and posted a long explanation with a patch to the glibc bugs mailing list.
[18:52] <zyx386> RainCT: usb modem is now popular modem in sweden danmark norway, because you have more speed 7,2 Mbit download and 1,5 Mbit upload, and i well never change that because ubuntu not suport them, i well change my OS for my Hardware :)
[18:52] <cjwatson> The reply I got didn't consider the patch at all. I was told "if this were a real issue in tar, then why hasn't the tar maintainer told me about it?"
[18:52] <zyx386> RainCT: thanx that is not the answer is very old solution, itr it
[18:53] <cjwatson> The tar maintainer happened to be reading this, and forwarded my mail word-for-word to the same mailing list.
[18:53] <RainCT> zyx386: yeh I know, but that works
[18:53] <cjwatson> The glibc maintainer then applied my patch.
[18:53] <zyx386> no
[18:53] <ogra_cmpc> heh
[18:53] <infinity> cjwatson: "glibc doesn't have bugs, unless you're in the small set of known contributors allowed to say so".
[18:53] <cjwatson> Have I contributed to glibc since? Have I heck.
[18:53] <infinity> cjwatson: I ran into that same pushback the one and only time I found a legit upstream glibc bug.
[18:53] <zyx386> you can put you solution to the bug report
[18:53] <cjwatson> Now, lots of people can tell the same kind of story about glibc. But do you see how this is form over substance?
[18:54] <cjwatson> I wouldn't actually have minded if the glibc maintainer had ignored my patch to this day if he didn't have time to read it. (Well, I'd have minded a bit, but not nearly so much.)
[18:56] <cjwatson> (FWIW, if you're ghoulish enough to want to read an eight-year-old flamewar, the log is in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=59829)
[18:56] <ubotu> Debian bug 59829 in libc6 "libc6: [PATCH] fnmatch() behaves oddly with *s and FNM_LEADING_DIR" [Fixed,Open]
[18:58] <Keybuk> cjwatson: nice Ulrichism there
[18:58] <Keybuk> "I won't even look at this"
[18:59] <cjwatson> my point wasn't to get into an Ulrich-bash-fest, but to point out the analogy of excessive makework in patch review putting off contributors
[19:00] <cjwatson> anyway, I've probably beaten this horse to death for now, and will go and do other things :-)
[19:01] <Keybuk> the trouble with using Ulrich as an analogy is that too many other people have Ulrich stories they wish to share at the bar
[19:01] <zyx386> saivann: what you talking about? https://bugs.launchpad.net/ubuntu/+source/gnome-ppp/+bug/212980
[19:01] <ubotu> Launchpad bug 212980 in gnome-ppp "HuaWei E220 and is unknow!?" [Undecided,New]
[19:01] <cjwatson> Keybuk: ... and a growing number of people have Ubuntu stories they wish to share at the bar :-(
[19:01] <micahcowan> Someone mind reminding me what the "patching system" where the source package rules consist of actually extracting a tarball and patching that (I know Vim uses it, for example)?
[19:01] <qense> wikipedia: "Drepper is known within the free software community for his confrontational style"
[19:01] <Keybuk> cjwatson: indeed
[19:02] <Keybuk> I think we're reaching Max Mosley levels of un-necessary red tape bondage at this point
[19:02] <cjwatson> micahcowan: there are a number of them, including dbs, at least one of the ones in cdbs, and a variety of semi-hand-rolled systems
[19:02] <cjwatson> vim only build-depends on quilt, but IIRC it has a hand-rolled system based on it
[19:02] <broonie> micahcowan: Are you thinking of dbs?
[19:02] <micahcowan> dbs... perhaps that's the one.
[19:03] <cjwatson> I don't think vim uses anything stock
[19:03] <RainCT> zyx386: I explained how to get it working on the bug (bug 212980)
[19:03] <ubotu> Launchpad bug 212980 in gnome-ppp "HuaWei E220 and is unknow!?" [Undecided,New] https://launchpad.net/bugs/212980
[19:03] <micahcowan> cjwatson, hand-rolled... maybe. But it had a name, and was used in at least one more package, IIRC.
[19:03] <cjwatson> dbs may well be what you're thinking of
[19:03] <micahcowan> prolly. Thanks!
[19:04] <qense> is bug 214622 a bug?
[19:04] <ubotu> Launchpad bug 214622 in gnome-system-tools "Can not change username in users-admin" [Undecided,New] https://launchpad.net/bugs/214622
[19:04] <qense> because changing your username would require a lot of changes
[19:05] <RainCT> qense: a bug surely not, at most a feature request
[19:05] <qense> yeah, we thought that too, but we wanted to check it with the developers
[19:05] <qense> because a lot of files will need a change
[19:06] <qense> and $HOME
[19:06] <saivann> zyx286 : Nevermind, RainCT knows this device more than I do and found what necessary piece of software was needed
[19:06] <saivann> zyx386 : Nevermind, RainCT knows this device more than I do and found what necessary piece of software was needed
[19:07] <qense> I'll close the bug and forward him to brainstorm? ;)
[19:08] <james_w> qense: you could file a feature request upstream perhaps.
[19:08] <qense> ok
[19:08] <qense> so that would make it wishlist and add a bug watch
[19:09] <james_w> qense: yeah, wishlist is the easy part :-)
[19:10] <qense> but what about user rights?
[19:10] <qense> Is the ownership per ID or per username?
[19:11] <james_w> on the filesystem?
[19:12] <qense> yes
[19:12] <RainCT> qense: by id
[19:12] <qense> ok, thx
[19:15] <qense> an interesting thought about this bug just popped up when I commented it
[19:16] <qense> it could be a bug caused by policykit
[19:16] <zyx386> RainCT: thanx for your answer i test it. thanx all
[19:18] <cody-somerville> qense, Why not check the upstream changelog?
[19:18] <cody-somerville> qense, Then you'd know if it was done on purpose or not.
[19:18] <qense> someone found this: gtk_widget_set_sensitive (widget, (login == NULL));
[19:18] <qense> (james_w's work)
[19:18] <qense> it means that is only editable when not set
[19:19] <qense> but we're not sure if that has been added recently or is new
[19:22] <qense> it was disabled in revision 4018!
[19:22] <qense>         * user-settings.c (user_settings_dialog_new)
[19:22] <qense>         (user_settings_dialog_get_data): disallow changing login name.
[19:22] <qense>         * group-settings.c (group_settings_dialog_new)
[19:22] <qense>         (group_settings_dialog_get_data): ditto for group name.
[19:22] <qense> oops
[19:22] <qense> I thought the link was still at cliboard
[19:23] <qense> http://svn.gnome.org/viewvc/gnome-system-tools?view=revision&revision=4018
[19:25] <RainCT> then it's a "I want that feature back"-request ^^
[19:26] <qense> yeah
[19:27] <qense> I'm going to mail the developer to ask why it has been removed and decide afterwards if it deserves a feature request
[19:53] <slangasek> keescook: I need a paranoid's opinion
[19:54] <calc> hello :)
[19:55] <keescook> slangasek: haha.  I'm honored/offended.  ;)
[19:57] <emgent> heya calc :)
[19:57] <slangasek> keescook: :)
[19:57] <slangasek> keescook: we're converging on being able to have authenticated filesharing enabled out of the box for hardy after all, but the trade-off is of course that you have to have something creating and keeping NTLM hashes up-to-date
[19:58] <slangasek> keescook: so you now have not one, but two password hashes for each user, weakest link, etc., etc.
[19:58] <keescook> NTLM? ewwwww.  isn't that unsalted md4?
[19:58] <slangasek> keescook: from a security standpoint, is it acceptable to you that we do this by default?
[19:58] <slangasek> no, that's LanMan
[19:58] <keescook> okay, less panic.
[19:58] <slangasek> which, with the current samba package settings, we don't create at all by default
[19:58] <slangasek> (even though smbpasswd supports it)
[19:59] <keescook> what is the underlying hashing system for NTLM?
[20:00] <slangasek> hrm, it's the same as whatever that AD-specific krb5 enctype was... let me check :)
[20:00] <slangasek> I believe it's arcfour-hmac-md5
[20:00] <slangasek> so, "md5"
[20:01] <keescook> unsalted?
[20:01] <keescook> the shadow file is currently 2-byte salted sha1, IIRC
[20:02] <slangasek> it is? when did it change from md5?
[20:03]  * keescook checks... it's been a while since I really looked at this
[20:03] <slangasek> all the passwords I have on hand still use the $1$ signature that was supposed to denote md5 passwords
[20:03] <jdstrand> keescook, slangasek: NTLM is md4 and NTLMv2 is md5 according to: http://www.ubiqx.org/cifs/SMB.html#SMB.8
[20:03] <keescook> yeah, I'm trying to find the $N$ table...
[20:03] <keescook> jdstrand: oh, hm
[20:03] <keescook> slangasek: ah, yeah, you're right, $1$ is md5.
[20:03] <slangasek> jdstrand: that refers to differences in the wire protocol; there are no different NTLM vs. NTLMv2 hashes
[20:03] <keescook> so, shadow is 2byte salted md5
[20:04] <slangasek> I'm still looking for the salting info
[20:04] <jdstrand> ok
[20:05] <jdstrand> (I see that in that link as well-- further down)
[20:05] <slangasek> keescook: right, I don't see any evidence that NTLM is salted
[20:06] <slangasek> keescook: so yes, it's weaker
[20:06] <keescook> slangasek: yeah, I'm not happy with that.  (e.g. I'm currently almost done generating a rainbow table that can crack all alphanumeric (with some special characters) md5 strings 7 or fewer characters.)
[20:07] <keescook> only root would have read-access to it, I assume?
[20:07] <slangasek> the alternative is that we can install libpam-smbpass the same time we install samba if someone wants to enable filesharing, but that's not as seamless because someone has to go back and populate the hashes for any users they want tou se for sharing
[20:07] <slangasek> correct, root-only
[20:07] <slangasek> (not even group shadow)
[20:07] <LaserJock> is pitti on vacation?
[20:07] <keescook> LaserJock: he's at a conference in US timezone.
[20:08] <LaserJock> doh, right
[20:08] <LaserJock> he's in Texas
[20:08] <slangasek> keescook: so, "not happy", but if the desktop team said it was the right thing to do...?
[20:09] <laga> cjwatson: you havent looked at the mythbuntu seeds by any chance?
[20:09] <slangasek> and btw, the reason it's not salted is because the passwords are hashed by the client before being sent across the wire with a separate, unique server-provided salt
[20:10] <keescook> slangasek: so, my basic objection here is that by providing default interoperability to what are fundamentally a proprietary systems, we reduce the security of Ubuntu as a whole, for everyone, even those that stick entirely to networks of free software systems.
[20:10] <slangasek> well
[20:11] <slangasek> it's also the only way to be able to browse from one Ubuntu system to another using Places -> Network :)
[20:11] <keescook> I realize samba is used by Free systems, too, but to force a lowered standard of password protection as a whole due to limitations imposed to remain compatible with windows makes my skin crawl.
[20:12] <slangasek> ok
[20:12] <keescook> I mean, I don't want to be difficult, it's clearly a great feature, but making it the default is unpleasant.
[20:12] <slangasek> but, if anyone installs the samba package, we're ok to pull in the automatic password sync stuff?
[20:13] <slangasek> (i.e., pulls it in via nautilus-share or installs the filesharing task on a server install)
[20:13] <keescook> I think that's a reasonable trade-off, but I'd like to to be noted somewhere non-obscure.
[20:13] <lamont> Apr  9 09:20:20 mix nagios2: Warning: A system time change of 1 seconds (backwards in time) has been detected.  Compensating...
[20:13] <lamont> how very, um, odd.
[20:13] <lamont> I keep seeing those.
[20:13] <lamont> thank you hardy.... NOT
[20:13] <ion_> lamont: cat /var/lib/ntp/ntp.drift
[20:13] <keescook> slangasek: i.e. "installing this reduces the security of your on-disk password storage".
[20:14] <keescook> though, of course, that's just another "Ok" box that people click without reading, so maybe not
[20:14] <slangasek> keescook: right, plus users have always had to do that anyway (and we /know/ no one's setting separate Unix and Samba passwords for their users... :), it was just harder to get to that point
[20:15] <keescook> slangasek: perhaps a note saying "Since NTLM password storage is less secure than Linux passwords, you will need to reset passwords for any uesrs that you want to share files from."
[20:16] <keescook> so, by default, "no, please", and on-install, "okay, ew"
[20:16] <slangasek> but yeah, I realize it's a bit unpleasant to have to have a second password hash on the system, I just wanted to gauge your feel for the unpleasantness since I have a long-running bias :)
[20:16] <slangasek> heh, but that's not true, it's not *because* it's less secure that you have to reset them... :-)
[20:16] <keescook> slangasek: heh.  what's your opinion about it?
[20:16] <lamont> ion_: -95.737
[20:17] <slangasek> also, it's not true because I'm so evil that users won't have to have their passwords reset, they'll just have to log back in. >:)
[20:17] <keescook> slangasek: true, but some note about it would be handy since it won't work for them until they change their password
[20:17] <lamont> interestingly, they are new to hardy AFAIK
[20:17] <keescook> slangasek: ah, cool.
[20:17]  * keescook uninstalls samba
[20:18] <slangasek> keescook: my opinion is that the usability of having it work out-of-the-box outweighs the security risks of having the additional root-only password store, weaker passwords or not
[20:18] <slangasek> keescook: I mean, I've been known to speculate about *replacing* /etc/shadow with /var/lib/samba/passdb.tdb, so :)
[20:18] <ion_> lamont: That's not a very small drift, so ntpd has to compensate quite a bit. Perhaps nagios has just began to track that.
[20:18] <slangasek> keescook: heh, uninstalling samba because I'm evil or because you're done poking at this? :-)
[20:19] <lamont> I supposee
[20:19] <keescook> slangasek: evil evil!  ;)
[20:20] <slangasek> cjwatson: ping
[20:20] <slangasek> jdstrand: also ping
[20:20] <keescook> slangasek: yeah, my paranoia doesn't agree -- I can't currently crack an /etc/shadow entry in 2 minutes, but I could do it for an otherwise "relatively safe" NTLM password
[20:20] <ion_> lamont: That's >4 minutes of drift per month.
[20:20] <jdstrand> slangasek: pong
[20:20] <keescook> slangasek: though it has taken a team of 6 people 2 months to generate the 500G worth of rainbow tables.  ;)
[20:21] <jdstrand> keescook: but once done, they are 'done'
[20:21] <lamont> ion_: yeah, 4:08.8 min/30 days
[20:21] <jdstrand> (and thus handy)
[20:21] <slangasek> jdstrand: hi, if I'm changing the default contents of /etc/pam.d/common-{auth,password}, does auth-client-config need any changes to cope?
[20:21] <keescook> jdstrand: right.  and it's not outside the realm of possibilities for botnets to have a central "look up this md5" server.
[20:22] <jdstrand> slangasek: no
[20:22] <lamont> OTOH, ntp used to not step unless time got kinda really wacko
[20:22] <slangasek> jdstrand: ok
[20:22] <lamont> oh
[20:22] <lamont> heh
[20:22] <lamont> intarwebs FTL
[20:22] <jdstrand> slangasek: it just looks in those files and sees if it has ever managed them
[20:23] <jdstrand> slangasek: if it hasn't it does one thing, if it has, another
[20:23] <slangasek> jdstrand: ok.  if it has managed them, it replaces them wholesale though, right?  so if there were "recommended" changes to the set of default modules, those /should/ be reflected in the alternate configs provided by auth-client-config...?
[20:23] <jdstrand> keescook: and might I say that your 'skin crawl' statement was rather eloquent?
[20:24] <ion_> lamont: Are there "ntpd.*time reset" messages in daemon.log?
[20:24] <lamont> ion_: there's a "oops the intarwebs went splat and so I resynced when they came back" entry. :(
[20:24] <jdstrand> slangasek: if a-c-c has never been run on the files, then it comments out the existing entry in a way that can be undone, and then puts in its changes
[20:25] <awen_> if anybody is using kubuntu hardy and have time for it... please test kde-guidance-powermanager from https://launchpad.net/~andreas-wenning/+archive , it has added support for showing power consumption when on battery; please tell if it works for you (or not)
[20:25] <slangasek> jdstrand: my point is that it would be advisable for the "changes" that a-c-c puts in to also have the "optional smbpass" support..
[20:25] <jdstrand> slangasek: if a-c-c has touched the files, then the commented section would not be touched, and changing the profile updates the uncommented parts
[20:25] <keescook> jdstrand: heh, thanks.
[20:26]  * awen_ go hiding ... wrong channel, sorry
[20:27] <jdstrand> slangasek: a-c-c ships a cracklib profile for pam_password, and an ldap example and kerberos example
[20:27] <jdstrand> slangasek: are you saying you would like this updated?
[20:27] <jdstrand> s/this/these/
[20:27] <mdke> BalaamsMiracle: once a release, normally.
[20:28] <mdke> BalaamsMiracle: anything more than that is a bonus
[20:28] <slangasek> jdstrand: if we're going to include pam_smbpass as an optional module by default, then using a-a-c shouldn't regress that integration, right?
[20:28] <mdke> BalaamsMiracle: we will do at least one import after release in -updates though
[20:29] <jdstrand> slangasek: let me put it this way-- you update the pam files, user runs a-c-c, there is not problem.
[20:29] <jdstrand> slangasek: a-c-c only ships 2 example profiles and the cracklib profile
[20:30] <jdstrand> slangasek: if pam_password is changing in the default, then I think that profile should be adjusted
[20:30] <jdstrand> (that's the cracklib one)
[20:30] <jdstrand> slangasek: can smb_pass be used with cracklib?
[20:30] <slangasek> jdstrand: er, it is a problem, because the default is going to support pam_smbpass syncing and none of your profiles will... :)
[20:31] <slangasek> yes, pam_smbpass is entirely stackable
[20:31] <jdstrand> slangasek: then like I said-- the cracklib one should change
[20:31] <slangasek> why shouldn't *all* of them change?
[20:31] <jdstrand> slangasek: the other are clearly noted as examples, but I wouldn't mind changing them accordingly
[20:31] <slangasek> oh
[20:32] <jdstrand> slangasek: I think we were talking about different things
[20:32] <jdstrand> slangasek: but I now know what you want
[20:33] <jdstrand> slangasek: just tell me what you want and I'll do it
[20:34] <jdstrand> (how is that for easy-to-work-with ?)
[20:34] <slangasek> jdstrand: to port the patch from bug #208419 to the a-a-c profiles :)
[20:34] <ubotu> Launchpad bug 208419 in pam "Integrate samba password in PAM" [Wishlist,In progress] https://launchpad.net/bugs/208419
[20:38] <jdstrand> slangasek: I don't see that common-password has an updated 'Alternate strength checking for password'
[20:38] <jdstrand> slangasek: (ie the cracklib part)
[20:38] <jdstrand> slangasek: I assume 'requisite' is fine there as well?
[20:39] <jdstrand> slangasek: I take that back
[20:39] <jdstrand> slangasek: this should be ok:
[20:39] <jdstrand> pam_password=password required       pam_cracklib.so retry=3 minlen=8 difok=3
[20:39] <jdstrand> password requisite       pam_unix.so use_authtok nullok md5
[20:40] <jdstrand> ?
[20:40] <slangasek> followed by "password optional pam_smbpass.so [...]", yes?
[20:40] <jdstrand> oh right, yes of course
[20:42] <slangasek> then it looks correct to me, yes
[20:42] <jdstrand> ok, I'll make the adjustments
[20:44] <jdstrand> slangasek: the ldap_example and kerberos_example are a bit more involved: http://paste.ubuntu-nl.org/62673/
[20:44] <BalaamsMiracle> mdke: Thanks for the info. I think i've got all my questions answered (although if i could have had my way, the documentation translations would be updated once a month or so :-) )
[20:44] <jdstrand> slangasek: I'd just assume not change them
[20:45] <slangasek> mvo: 213482 isn't fixable in slapd, the issue is that slapd's dependencies have been removed before the preinst of the new package runs, making it impossible to get a reliable dump of the old db...
[20:45] <jdstrand> slangasek: they are meant to be jumping off points anyway and I know that they work in at least one configuration-- if I add pam_smbpass, I won't know that this is still true :)
[20:46] <mvo> slangasek: yeah, I figured that
[20:46] <slangasek> jdstrand: fair enough, I'll kill those off in intrepid with the reorged pam support then :)
[20:46] <slangasek> mvo: before or after you assigned the bug to slapd? :-)
[20:46] <jdstrand> slangasek: I look forward to it
[20:46] <jdstrand> ;)
[20:47] <mvo> slangasek: slightly after that, I just checked the chroot to see what fails. do you have a plan already how this can be fixed?
[20:48] <slangasek> mvo: I have no idea, is there some way that update-manager can fix it by upgrading slapd earlier?
[20:49] <slangasek> (before the libs get pulled out from under it)
[20:49] <mvo> slangasek: unfortunately not, it can not modify the ordering that libapt calculates
[20:49] <slangasek> poo
[20:49] <mvo> indeed
[20:50] <cjwatson> laga: I think I thought I had finished the review. What were you still waiting for from me? (Hm, a tasksel upload maybe?)
[20:50] <cjwatson> slangasek: yo
[20:51] <cjwatson> Riddell: ubiquity r2619 seems like the wrong approach. Why would we want to *add* explicit sizes (that will break with font changes, different languages, etc.)?
[20:51] <cjwatson> Riddell: if the widget set isn't making it big enough, surely that's a widget bug
[20:51] <cjwatson> Riddell: or else there are *too many* explicit sizes constraining it to be smaller
[20:52] <slangasek> cjwatson: hi, would you mind eyeballing the patch in bug #208419 so I can be assured I'm not overlooking anything due to crossed hats?  Tried to grab pitti for it, but Texas isn't doing much for his availability :)
[20:52] <ubotu> Launchpad bug 208419 in pam "Integrate samba password in PAM" [Wishlist,In progress] https://launchpad.net/bugs/208419
[20:52] <cjwatson> Riddell: the use of gettext _("Next") in r2620 isn't great either - it should be using the debconf translation for that
[20:53] <cjwatson> Riddell: maybe the messagebox in question_dialog should have set_icon done on it to give it the question icon?
[20:53] <cjwatson> slangasek: ok, queueing up
[20:53] <slangasek> thanks:)
[20:53] <cjwatson> oh god, do I have to remember what the difference between required and requisite is?
[20:54] <slangasek> requisite = terminate the stack on failure :)
[20:54] <cjwatson> worst naming ever
[20:54] <mvo> slangasek: so the problem is that the database format changed and that is why the database needs to be dumped/reloaded? and the new slapcat can not read the old format?
[20:55] <slangasek> mvo: correct; we've always relied on the preinst being able to use the binaries from the previous version, and there've never been issues with this before now
[20:57] <cjwatson> slangasek: it'll cause some log noise if pam_smbpass.so is missing, won't it? (minor)
[20:58] <LaserJock> slangasek: are you gonna have any time today to look at flashplugin-nonfree sitting in gutsy unaccepted queue?
[20:58] <cjwatson> slangasek: so the change to requisite is so that pam_smbpass is invoked even on failure? Is there any possibility that this might cause unexpected things to happen in other auth stacks, which might now have later modules invoked when they weren't previously?
[21:00] <slangasek> cjwatson: surprisingly no noise if pam_smbpass is missing; I had assumed the same before, Petter Reinholdsen pointed out that it doesn't
[21:00] <cjwatson> hmm, sure I remember that in the past; ok then
[21:00] <slangasek> LaserJock: questionable; is it something another archive admin could poke?
[21:01] <slangasek> cjwatson: the change to requisite is so that pam_smbpass is *not* invoked when the previous module fails
[21:01] <slangasek> the behavior of 'required' is to continue processing the stack, which we don't want because that would set wrong passwords
[21:01] <LaserJock> slangasek: well, I asked seb128 and he said he didn't really want to do and suggested you or pitti
[21:01] <cjwatson> slangasek: apparently I can't read
[21:01] <cjwatson> ok then
[21:01] <infinity> slangasek: Looks correct to me, FWIW.
[21:01] <infinity> slangasek: (I used to do something similar at an old place of employ)
[21:02] <cjwatson> the ordering in /usr/share/doc/libpam-doc/html/sag-configuration-file.html is confusing. I'd have got it right had requisite been above required, since it's a "harder" failure.
[21:02] <slangasek> LaserJock: rats; understandable, but inconvenient timing
[21:02] <LaserJock> it's just after the disaster last time with flash I thought I'd try to get a 0-day SRU through
[21:02] <laga> cjwatson: i was basically wondering how to get the stuff in 'common' included on the alternate disk w/o installing it with the other tasks i've added.
[21:02] <LaserJock> but it's gonna take at least 1 day just to get it into -proposed
[21:02] <cjwatson> slangasek: and yeah, assuming that the pam_smbpass.so options do the right thing, it looks good to me
[21:02] <seb128> LaserJock: I'm back, but I'm still not comfortable accepting a new version into stable
[21:02] <slangasek> cjwatson: thanks, throwing it into the real world then :)
[21:02] <LaserJock> seb128: no problem, I understand
[21:03] <LaserJock> I just need *somebody* that is comfortable :-)
[21:03] <seb128> LaserJock: usually we don't get new version there and it's not clear to me it's a good idea
[21:03] <LaserJock> seb128: it's a new version in name only
[21:03] <LaserJock> all we did is update the md5sums
[21:03] <slangasek> seb128: it's flashplugin-nonfree, there are no good ideas :)
[21:03] <seb128> slangasek: right, better to not touch this thing ;-0
[21:03] <seb128> ;-)
[21:04] <LaserJock> it's got a new upstream version because the version reflects the version of flash that's being downloaded
[21:04] <cjwatson> laga: should be included on your alternates already by virtue of ship inheriting from common
[21:04] <seb128> I could just accept the thing, but I don't want take responsability for whatever regression it can introduce
[21:04] <LaserJock> seb128: for proposed it's not the archive admins responsability
[21:04] <seb128> the bug going on a zillion pages doesn't make thing easier
[21:05] <seb128> LaserJock: not really true, it's somewhat the responsability of whoever approve the update
[21:05] <LaserJock> and I approved the update
[21:05] <seb128> whoever press the button if you prefer rather ;-)
[21:06] <LaserJock> but for -proposed? I don't see any risk
[21:06] <seb128> it's still something pushed to some users
[21:06] <LaserJock> sure
[21:06] <seb128> it should not be obviously broken
[21:06] <LaserJock> and that's why I can understand the objection
[21:06] <seb128> and I don't know how to judge the changes between what gutsy has now and the update
[21:06] <LaserJock> seb128: did you look at the debdiff?
[21:06] <mario_limonciell> slangasek, i was just discussing this with cjwatson, it would appear that dvds suddenly aren't including all the lang packs in the livefs.  compare http://cdimages.ubuntu.com/dvd/20080409/hardy-dvd-i386.manifest and http://cdimages.ubuntu.com/dvd/20080408.1/hardy-dvd-i386.manifest
[21:07] <seb128> so I don't feel comfortable pushing that to users
[21:07] <seb128> LaserJock: the debdiff doesn't tell a lot about what changed in the new flash version
[21:07] <seb128> and no I didn't yet
[21:07] <seb128> but I expect the debdiff not being an issue
[21:07] <seb128> that's rather the closed source version update which is
[21:07] <slangasek> mario_limonciell: I'll bet that's my fault
[21:08] <LaserJock> seb128: well, there's not much you can do about that
[21:08] <mario_limonciell> slangasek, well was it "intended" to go that way?
[21:08] <LaserJock> I don't think anybody expects the archive admin to test the flash version
[21:08] <mario_limonciell> or accidental then
[21:08] <seb128> I can decide to not accept an updated version to stable ;-)
[21:08] <slangasek> mario_limonciell: oh, which lang packs do you see as missing though?  the diff shows me version differences, mostly?
[21:08] <LaserJock> seb128: I'm saying you can't look at the flash source to see what changed
[21:08] <seb128> right
[21:08] <slangasek> mario_limonciell: ah, language-support-*
[21:08] <seb128> that's why I'm not comfortable accepting it
[21:08] <mario_limonciell> exactly
[21:09] <slangasek> mario_limonciell: check the bzr log for the seed, there's a glowing arrow pointing at my mistake :-)
[21:09] <mdke> BalaamsMiracle: I'm afraid that's impossible - too much work is required to correct all the translations
[21:09] <LaserJock> seb128: I had multiple people test it in Firefox and Konqueror before uploading it
[21:09] <mdke> BalaamsMiracle: maybe in the future
[21:09] <LaserJock> seb128: but I understand your objection certainly
[21:10] <LaserJock> but we *do* need to get somebody who can approve it
[21:10] <slangasek> seb128: under the circumstances, I would tend to favor getting it into -proposed sooner rather than later, but I'm also not jumping up to push the button myself :)
[21:10] <mario_limonciell> slangasek, ah rev no 1255.  just taking all the language-support- packages isn't a good idea :)
[21:11] <seb128> LaserJock: why do we need it in the first place?
[21:11] <seb128> LaserJock: I would read the bug if there was not enough to spend one hour reading it
[21:11] <LaserJock> seb128: flash install is broken for Gutsy users
[21:12] <LaserJock> we check the md5sum of the dowloaded flash package
[21:12] <LaserJock> every time Adobe does a new release we have to update the md5sum to check
[21:12] <LaserJock> otherwise postinst bails
[21:12] <BalaamsMiracle> mdke: I didn't realize that after the translations were submitted, more work was needed to correct those again.
[21:12] <seb128> they don't keep the previous version available?
[21:13] <LaserJock> seb128: nope
[21:13] <seb128> somebody should fix the package to display a "version not available" and not break
[21:13] <mdke> BalaamsMiracle: yeah
[21:13] <LaserJock> there's only a "current"
[21:13] <LaserJock> seb128: uh, yeah
[21:13] <LaserJock> but as this is a stable release we haven't done that
[21:14] <seb128> and in hardy? ;-)
[21:14] <mario_limonciell> I personally think a nice warning "this version isn't available", do you want to install it anyway and explain the possible security implications is the way to go
[21:14] <BalaamsMiracle> mdke: Woulkdn't it be a good idea to have the admins of the respective translation teams do the correcting?
[21:14] <LaserJock> seb128: well, nobody's fixed it in hardy so we had to update the md5sum same way
[21:14] <seb128> alright
[21:14] <seb128> let me accept the gutsy proposed one
[21:14] <LaserJock> seb128: you're more than welcome to submit a patch ;-)
[21:15] <seb128> I'm going to be not happy if that breaks
[21:15] <seb128> be warned ;-)
[21:15] <mdke> BalaamsMiracle: it's quite difficult to organise that, generally only a few teams are that well organised
[21:15] <LaserJock> well, all I can say is I had 4 people test it before uploadin
[21:15] <_MMA_> seb128: Cant be any more broken. It doesn't work now.
[21:15] <LaserJock> I'm not going to be happy if it breaks either
[21:15] <slangasek> mario_limonciell: a surprising number of DVD builds over the past couple of days, someone tweaking something?
[21:15] <seb128> _MMA_: that is not true, crashing the machine is broken where not installing is not really
[21:16] <mario_limonciell> slangasek, they kept not being buildable
[21:16] <mario_limonciell> slangasek, due to failures of the livefs generation
[21:16] <slangasek> oh
[21:16] <mario_limonciell> different failures each time around
[21:16] <seb128> _MMA_: right now it seems to not be installable, which at least doesn't break thing at runtime
[21:16] <seb128> _MMA_: no?
[21:16] <mario_limonciell> but they were all transient
[21:16] <_MMA_> seb128: That's just being overly cautious and paranoid.
[21:16] <mario_limonciell> slangasek, you can purge anything than the last one though, those other ones aren't useful with the old livefs
[21:17] <slangasek> mario_limonciell: hmm, but something must've succeeded if there were manifest differences
[21:17] <_MMA_> seb128: If this untrust of Flash is so huge we should just just get rid of the package all together.
[21:17] <mario_limonciell> slangasek, well look at anything before the last one, it uses the livefs from 04-05-08
[21:18] <mario_limonciell> and that older manifest consequently
[21:18] <seb128> _MMA_: I would not be against that but I guess users would not agree ;-)
[21:18] <mario_limonciell> so it was just the very last one that finally had a good livefs
[21:18] <slangasek> mario_limonciell: fair enough
[21:19] <_MMA_> seb128: Then we should give them a working Flash in a timely manner. It's been tested by a trusted member. I just dont see why the need for resistance.
[21:20] <seb128> _MMA_: because working for one person is different of non broken
[21:21] <slangasek> _MMA_: browbeating him for his concerns, /after/ he's already agreed to accept the package, isn't very productive
[21:21] <mvo> slangasek: I added some info to the bugreport for the slapd thing. it seems to me that if the libsasl2-modules-$foo would be called libsasl2-2-modules-foo for libsasl2-2 the problem should go away. but I have no idea about sasl so I leave that to the server team
[21:21] <_MMA_> slangasek: We're all friends here. :) This goes to deeper issues also.
[21:22] <LaserJock> seb128: it worked for like 4 people at least with a variety of browsers
[21:22] <LaserJock> but after last time with the konqueror issue it is good to test flash for sure
[21:22] <slangasek> mvo: great, thanks
[21:23] <_MMA_> It's stunning to me that we've let this wildly important/popular package continue to say broken.
[21:23] <slangasek> _MMA_: er, "continue"?  AIUI it's *newly* broken, because adobe has again overwritten the tarball on their website with a new security update?
[21:23] <_MMA_> I just feel a little bad every time I have to point people to Medibuntu for a working package.
[21:23] <seb128> LaserJock: it could be working for one thousand user it would not mean it's not broken for some others
[21:24] <LaserJock> seb128: no but that's the whole point of -proposed
[21:24] <Nafallo> hmm
[21:24] <_MMA_> slangasek: We should stay up on it then. Issue a new update when they do.
[21:24] <slangasek> seb128: but requiring 1001 testers before accepting it into -proposed is not a reasonable barrier :)
[21:24] <Nafallo> pulseaudio doesn't emulate the microphone or something? my mother can't hear me :-/
[21:24] <slangasek> _MMA_: does medibuntu use the same overall packaging?
[21:24] <seb128> slangasek: no, but having a diff to read make things easier ;-)
[21:24] <Nafallo> I would say that's quite a regression in that case.
[21:25] <_MMA_> slangasek: Best I can say it works. But I would *think* it would be simular yes.
[21:27] <seb128> LaserJock, _MMA_: update accepted now
[21:27] <seb128> jdong: around?
[21:28] <LaserJock> seb128: thanks a ton
[21:28] <seb128> LaserJock: you are welcome
[21:29] <phaeron> mmm where did I see you before seb128 .. anyway it was suggested on bug 211252 that I express my concerns here
[21:29] <ubotu> Launchpad bug 211252 in obex-data-server "Cannot recieve files using bluetooth" [Undecided,New] https://launchpad.net/bugs/211252
[21:30] <slangasek> _MMA_: the flashplugin-nonfree packaging in Ubuntu is lousy, and adobe's policy of overwriting their existing releases is also lousy.  So there's a limit to how much de-lousing can be done here even in theory, but I thought maybe medibuntu had something better rather than just having a policy of blindly applying any upstream updates immediately.
[21:31]  * Caesar hates the name medibuntu, he always thinks "medical" before "media"
[21:31] <_MMA_> DOnt know.
[21:31] <slangasek> Caesar: I associate it with being "half of a buntu" :)
[21:32] <seb128> phaeron: no idea about that one, did you comment on the bug?
[21:33] <phaeron> seb128: nevermind that, about the bug , I reported it. I commented on the bug and was very frustrated so I might have sounded rude. Maybe I was sent here to get punished :P
[21:33] <Caesar> Any chance I can score a bit of sponsorship for #214770 ?
[21:34] <seb128> phaeron: to reply to your question on the bug, ubuntu updated because gvfs and other gnome components required the new obex-data-server
[21:34] <Lutin> slangasek: not sure what you're talking about...medibuntu doesn't have flashplugin-nonfree (haven't read the backlog)
[21:34] <seb128> phaeron: the issue not fixed, the team is small, overworked, and nobody is looking really at bluetooth issue, you are welcome to send patches though
[21:34] <slangasek> Lutin: oh, well, ask _MMA_ then
[21:35]  * _MMA_ looks.
[21:35] <seb128> phaeron: I can't look at this one I've to bluetooth device to do testing and I've already too much to do on GNOME
[21:36] <phaeron> seb128: well everything seems to work with the old version and gnome-obex-server , and yes I'd love to send patches , but I can't seem to find the problem . I asked on #bluez and they said the hcidump means that no services are being offered.
[21:36] <phaeron> seb128: although I am sure that all four servers were running.
[21:36] <seb128> did you try sending a  bug upstream?
[21:37] <phaeron> seb128: and I tried to find any permission denied errors using dbus-monitor because I suspected a policykit issue but didn't find any.
[21:37] <phaeron> seb128: yes I did , one sec
[21:38] <seb128> does gvfs bluetooth browsing works?
[21:38] <phaeron> seb128: yes
[21:38] <phaeron> seb128: last time I tried it does.
[21:39] <seb128> I'm not going to be really useful there, I've no bluetooth experience, no knowledge of this stack and no device to try
[21:39] <seb128> but maybe somebody else has an idea
[21:39] <phaeron> seb128: the new hidd replacement bluetooth input server crashes dbus with an out of memory error
[21:39] <phaeron> seb128: http://bugs.muiline.com/view.php?id=70
[21:40] <seb128> hum, upstream is not responsive either
[21:40] <phaeron> yep
[21:43] <saivann> is it normal that konqueror-kde4 does not have any dbg or dbgsym packages?
[21:44] <mario_limonciell> slangasek, how often is the regular DVD cron job supposed to be running?  is it weekly?
[21:45] <slangasek> mario_limonciell: bi-weekly
[21:45] <slangasek> mario_limonciell: but I'm running another now after (I think) fixing the seed
[21:45] <jdong> seb128: yes, sir
[21:45] <mario_limonciell> on what days then?
[21:46] <seb128> jdong: do you plan to get transmission update in hardy?
[21:46] <slangasek> mario_limonciell: on days "2" and "6"
[21:46] <slangasek> I can never remember cron's base for weekdays :)
[21:46] <seb128> jdong: the menu item needs to be update to the new upstream version one and we were waiting on you to get an update since you said you would either do that or backport changes
[21:46] <mario_limonciell> slangasek, did you already queue that new dvd imm, or you were "about" to?
[21:47] <seb128> jdong: if you are not going to, could you get the menu items changed and notify translators? ;-)
[21:47] <slangasek> mario_limonciell: already building
[21:47] <mario_limonciell> slangasek, er o okay.
[21:47] <mario_limonciell> thanks
[21:47] <jdong> seb128: I don't plan the update; I plan on backporting the changes pending when charles_ gets back to me on splitting out his big-glob patch into individual ones
[21:47] <slangasek> mario_limonciell: if you have other changes, we can always try again later :)
[21:48] <seb128> jdong: could you get the menu item change backport now so translators can work on it?
[21:48] <mario_limonciell> slangasek, yeah just ubiquity's noninteractive frontend broke, but i'll just hold off until evand is ready to do another ubiquity upload for now
[21:49] <jdong> seb128: is there a bugno for that?
[21:49] <jdong> seb128: I assume bug 184238?
[21:49] <seb128> jdong: bug #184238
[21:49] <ubotu> Launchpad bug 184238 in transmission "Menu entry should be named "Transmission BitTorrent Client" Instead of only the unclear "Transmission"" [Undecided,Fix committed] https://launchpad.net/bugs/184238
[21:50] <jdong> seb128: ok lemme prep a debdiff
[21:50] <seb128> jdong: thanks
[21:50] <seb128> jdong: subscribe the main sponsors too ;-)
[21:50] <seb128> jdong: other thing, you were asking about NEW approval before?
[21:50]  * jdong wonders why on earth "VF" set it to fix committed 3 months ago
[21:50] <jdong> seb128: yeah for backports
[21:51] <seb128> jdong: which ones?
[21:51] <jdong> seb128: mainly the nexuiz binaries
[21:52] <seb128> what distro is that, gutsy?
[21:52] <jdong> yes
[21:52] <seb128> ok, looking to that
[21:56] <jdong> seb128: does the translation team care if I use a patchsys to deal with debian/transmission-gtk.menu? I'm going to need to add a patchsys for the backported patches anyway
[21:56] <slangasek> seb128: so, pam is all pimped out now to handle smbpasswd integration; do you want to have a look at bug #208419 as it relates to nautilus-share?
[21:56] <ubotu> Launchpad bug 208419 in ubuntu-meta "Integrate samba password in PAM" [Medium,Confirmed] https://launchpad.net/bugs/208419
[21:57] <seb128> jdong: the only thing the translation team care about it to have the strings listed in the template and imported in rosetta so not really ;-)
[21:58] <seb128> jdong: which means you should make sure that whatever has the _Name and _Comment is changed
[21:58] <slangasek> mathiaz: and do you want to weigh in on the proposed change to the samba-server task? (again, bug #208419)
[21:58] <ubotu> Launchpad bug 208419 in ubuntu-meta "Integrate samba password in PAM" [Medium,Confirmed] https://launchpad.net/bugs/208419
[21:59] <jdong> seb128: it uses debian/transmission-gtk.{menu,mime}... lemme see if the changes have applied logically :)
[22:00] <seb128> jdong: no, the must be a .desktop somewhere, GNOME doesn't use those
[22:00] <jdong> seb128: oh oops I found it. So those two files don't matter?
[22:01] <seb128> jdong: they do for the debian menu and maybe some other environments
[22:01] <jdong> seb128: ah, so change both. Got it :)
[22:01] <seb128> right
[22:02] <jdong> orig: "Transfer files via Peer to Peer". Does "Transfer files via the BitTorrent Peer to Peer Protocol" sound better or worse?
[22:02] <jdong> I think the key word to mention is BitTorrent though this may be redundant
[22:03] <jdong> _Comment=Download and share files over BitTorrent
[22:03] <jdong> ah there we go, upstream's wording
[22:04] <seb128> slangasek: what is to change, make nautilus-share install libpam-smbpass and display a warning about the need to restart the session?
[22:04] <slangasek> seb128: I believe so, yes
[22:04] <slangasek> seb128: do you think this is adequate from a UI perspective?
[22:05] <seb128> yes
[22:05] <slangasek> cool
[22:05] <slangasek> (is anyone else doing this kind of thing with nautilus-share yet, or is hardy going to be the awesomest?)
[22:05] <seb128> I'm wondering if we should display an extra dialog or just add a warning in the current one about the need to restart the session after the installation
[22:06] <seb128> (somebody told me that novell is using nautilus-share but I've no idea if they have pam integration)
[22:07] <slangasek> my feeling is that it should be a dialog displayed after samba is installed
[22:08] <seb128> right, that's my opinion too
[22:18] <jdong> seb128: ok ums subscribed
[22:18] <seb128> jdong: thanks
[22:19] <jdong> sure. thanks for your help :)
[22:22] <slangasek> mvo: just glancing at the package, it looks to me like re-adding a libsasl2 transition package should be enough to fix this?
[22:23] <mvo> slangasek: hm, possible, let me check. I was thinking of this too, but for some reason I discarded it (maybe because it was too easy :P)
[22:23] <slangasek> mvo: heh :)
[22:24] <slangasek> mvo: well, libsasl2 -> libsasl2-2 was a gratuitous rename, so I think it should be sufficient
[22:26] <mvo> let me test, if that is sufficient, I will just upload (change is simple enough)
[22:38] <mvo> slangasek: that seems to be indeed enough, the upgrade works with it, I upload now, someone will have to NEW it
[22:38] <slangasek> no problem :)
[22:38] <mvo> thanks slangasek!
[23:05] <saivann> tedg : Since you are actually assigned to bug 201626 and that Hardy RC will be ready in a few days, can you look if you can upgrade xscreensaver, and if you can't please demote braid from the xscreensaver package since it cause serious crash with the majority of the graphic cards
[23:05] <ubotu> Launchpad bug 201626 in xscreensaver "please merge xscreensaver 5.04-4 from Debian unstable main" [Undecided,New] https://launchpad.net/bugs/201626
[23:05] <saivann> tedg : Don't hesitate to ask if I can do something to assist you in this task, thanks for your work
[23:12] <cody-somerville> Hobbsee, ping
[23:12] <tedg> saivann: Yes, I'll do it tonight.
[23:13] <saivann> tedg : Thank you very much for this
[23:16] <mario_limonciell> slangasek, actually it looks like that livefs build didn't pass: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/hardy/ubuntu-dvd/20080409.1/livecd-20080409.1-i386.out
[23:19] <cody-somerville> slangasek, I'm pretty sure that Martin and Sarah approved the Abiword FFe in our discussion.
[23:20] <slangasek> mario_limonciell: ah, fun.  well, that's tracked on http://people.ubuntu.com/~ubuntu-archive/testing/hardy_probs.html then
[23:20] <slangasek> cody-somerville: the place for a release team member to approve an FFe is in the bug log, which wasn't done
[23:20] <mario_limonciell> slangasek, ah didn't realize it existed
[23:51] <cjwatson> any chance that somebody could look at http://revu.tauware.de/details.py?upid=2177 ? (ttf-ubuntu-title, pulling together the divergent work that's been happening for ages)
[23:52] <Silicium> www.opensnom.org - the Open Snom Implementation
[23:55] <azeem> Silicium: are you spamming?
[23:56] <Silicium> nope
[23:56] <Silicium> iam search interessting peoples :)
[23:56] <azeem> you pasted that link in both #debian and here, I've notified the network ops to kline you
[23:56] <Caesar> kthxbye