[12:08] <zyga> hey
[12:08] <zyga> how can one debug hibernation issues?
[12:08] <azeem> you ask mjg59 about them, AFAIK ;)
[12:08] <zyga> I can hibernate okay with pure main system, but after poweron there is no sign of hibernation (regular boot)
[12:08] <zyga> mjg59: awake?
[12:10] <Lure> zyga: you may try #ubuntu-laptop...
[12:51] <dholbach> good night everybody
[01:54] <bddebian> How peoples
[01:54] <tseng> hi bddebians
[01:55] <bddebian> Hi tseng
[01:57] <MrRio> hey
[01:57] <bddebian> Hello MrRio
[02:09] <dAndy_> is there a known issue with lots of printers crashing the printer dialog? I cant seem to find a bug, trying to pin down which bit is causing it so I can submit one
[02:14] <mjg59> elmo: Hi
[02:16] <dAndy_> I went ahead and filed a new bug, I wasnt sure what to file it against: #42676
[02:16] <bddebian> Oh, elmo: I know you're busy but if you get a free second, could you plesae look at my @ubuntu.com e-mail?  cprov said you were the man to speak to..
[05:29] <stub> Launchpad is going down in 15 mins for a regular code update. Estimated down time is 10 minutes. Wikis will be in read only mode during this period.
[05:33] <LaserJock> stub: thanks for the heads up
[06:32] <desrt> daniels is in pc magazine today
[06:32] <mdz> infinity: how is that review of initramfs-tools bugs going?
[06:33] <bddebian> OMG PC Magazine is still around?
[06:36] <infinity> mdz: Getting some more stuff fixed and uploaded in initramfs-tools is next on my TODO after finishing up some security stuff for pitti.
[06:53] <bddebian> Gnight folks
[08:14] <pygi> Mithrandir: around?
[08:24] <pitti> Good morning
[08:29] <pygi> mornin' pitti
[08:29] <pitti> hi pygi 
[08:31] <dholbach> good morning
[08:34] <highvoltage> morning mr holbach
[08:35] <dholbach> highvoltage: how do you do?
[08:35] <highvoltage> dholbach: fine thank you. how are you?
[08:36] <dholbach> highvoltage: I'm just getting ready for the bug day - so I'm fine.
[08:37] <highvoltage> :)
[08:42] <kagou> infinity: around
[08:42] <infinity> kagou: Vaguely.
[08:43] <kagou> oh i need big attention :)
[08:43] <infinity> ?
[08:43] <kagou> :p
[08:43] <kagou> infinity: we have many bugs for samba, concerning sharing/user security
[08:43] <infinity> Yes, I know.
[08:44] <kagou> we have to decide what is the default use for gnome-share. Is there a discussion anywhere on lists ?
[08:44] <infinity> And switching to security=share breaks a whole host of other things, so I'd prefer if people stopped recommending it.
[08:44] <G0SUB> infinity: hello :)
[08:45] <kagou> infinity: so if security=user we have Bug #24184
[08:45] <Ubugtu> Malone bug 24184 in samba "Samba and system passwords should be synchronized." [Wishlist,Unconfirmed]  http://launchpad.net/bugs/24184
[08:45] <pitti> infinity: I had this problem with a friend of mine, too; either switching to share, or fiddling with smbbpasswd, either way there seems to be no way to get it working just OOTB or with GUI tools, right?
[08:45] <infinity> kagou: As it stands, no massively amazing changes will go in before release anyway, so this is probably better specced out as "something we can improve on for Edgy", with people like G0SUB (hi!) who seem to be interested in better GUI toold for samba.
[08:46] <G0SUB> yay!
[08:46] <infinity> pitti: Yeah, the user needs a password.
[08:46] <infinity> pitti: (switching to share breaks the world for a lot of other samba use cases, so it's a non-starter, IMO)
[08:46] <G0SUB> infinity: I have written another spec ... this time for offline-updates
[08:46] <G0SUB> https://wiki.ubuntu.com/OfflineUpdateSpec
[08:47] <infinity> pitti: The easiest route to get the user a password would be to ask them for one when they create a share iff they don't already have a password set, but that means mangling the GNOME dialogs pretty late in the cycle.
[08:47] <G0SUB> I would like to implement both of them for Edgy
[08:47] <infinity> pitti: The dialog already needs root anyway (since it's fiddling with smb.conf), so tossing in an smbpasswd call isn't rocket science, I suspect.
[08:48] <G0SUB> JaneW: Good Morning :)
[08:48] <JaneW> hi G0SUB 
[08:48] <G0SUB> JaneW: I am the one who mailed you about the Samba config gui idea
[08:49] <JaneW> G0SUB: yes I just /whois'ed you :) G0SUB is somewhat easier to say :)
[08:49] <G0SUB> JaneW: haha
[08:49] <JaneW> infinity: did you check the spec?
[08:49] <infinity> G0SUB: The service pack idea sounds rational, but when you start digging in, it gets a bit uglier.  When you say "it downloads its dependencies", you realise that you'll end up with half the archive in each "service pack", right?
[08:50] <infinity> (Well, you'll end up with GTK, glib, a bunch of X libraries, glibc...)
[08:50] <G0SUB> infinity: I agree. I must put in some sort of heuristics into it
[08:50] <infinity> The only way to avoid that is to generate the package list on the target machine, so it knows what it already has installed.
[08:51] <G0SUB> infinity: one idea might be to show ALL deps and let the user choose which deps to download
[08:51] <infinity> That would be far too unfriendly to work for the target audience.
[08:51] <infinity> Most don't even know (or want to know) what libc6 or libx11 is.
[08:51] <G0SUB> infinity: the pack creator is not a newbie I assume :)
[08:52] <G0SUB> infinity: or, we can download only first level deps?
[08:53] <infinity> There's no way to know which are the "right" ones to download, honestly.
[08:53] <G0SUB> or, we always remember what's there in the 1st CD and never download those?
[08:53] <infinity> Not without running a "service pack diagnostic" on the machine you intend to install to.
[08:53] <infinity> (Which would pretty much just be a "dpkg -l" output, but whatever)
[08:54] <G0SUB> hmm
[08:54] <infinity> Yes, culling dependencies that are on the install CD isn't a bad idea either.
[08:54] <G0SUB> whatever the method, we must find out something. my friends who don't have internet are screaming at me
[08:54] <infinity> But that's only part of the problem, since you're talking about doing "update" CDs, etc, which won't have a clue what updates the user may already have.
[08:54] <G0SUB> infinity: the 1st CD idea is reasonable IMHO
[08:55] <kagou> infinity: may be the script used to create users can be hacked to create smb password too ?!
[08:55] <infinity> (For a while, dapper-security will be under 650MB, so you can just grab it all, but that won't last)
[08:55] <G0SUB> infinity: it'd be date based
[08:55] <G0SUB> it can be
[08:55] <infinity> JaneW: I've not had time to give it a thorough check, no, though I'm now discussing his other spec. :)
[08:55] <G0SUB> say all updates after this date
[09:00] <kagou> infinity: may be we have not the time to hack gnome-user-share to ask for the samba password creation. So we may have to set security=share . Doing that we have to remove the default share of home directory in smb.conf
[09:00] <JaneW> infinity: oic.
[09:01] <infinity> kagou: I see no reason why we MUST do one or the other.
[09:01] <infinity> kagou: This misfeature has been there forever.  It's not new in dapper.
[09:01] <kagou> infinity: simply because without choosing, gnome-user-share don't work
[09:01] <Mithrandir> pygi: yes
[09:01] <infinity> kagou: I appreciate that it's annoying, but I don't want to break security= just to "fix" the desktop use case.
[09:01] <pygi> Mithrandir: have you responded to that guy about n-a ?
[09:02] <Mithrandir> pygi: no, sorry.
[09:02] <Mithrandir> pygi: mdz did, though
[09:02] <pygi> Mithrandir: I just saw he applied for SoC, but his presentation was ... huh, how do I put it :-/
[09:02] <infinity> kagou: I'd be happy (as I've mentioned before), however, to audit a patch to gnome-user-share that does the smbpasswd invocation for the user.
[09:03] <G0SUB> pygi: are you a mentor?
[09:03] <infinity> It'll such that it may be a new untranslated string (unless I can cleverly pull a string from somewhere else and re-use it), but we may be able to make an argument for letting it in anyway.
[09:03] <kagou> infinity: so we may  be can remove gnome-user-share installation by default, and add in README how to work with smb password. Of course i'd be happy too for this patch :)
[09:03] <infinity> s/such/suck/
[09:03] <pygi> GOSUB: for n-a thingy? nop
[09:03] <G0SUB> pygi: for SoC
[09:03] <pygi> GOSUB: yup
[09:04] <infinity> G0SUB: Have you been following this conversation?
[09:04] <Mithrandir> pygi: got an url to it?
[09:04] <G0SUB> pygi: did you check my application? 
[09:04] <pygi> Mithrandir: have you looked it over?
[09:04] <G0SUB> infinity: yes, I am
[09:04] <pygi> GOSUB: what is ur application?
[09:04] <G0SUB> pygi: SAMBA GUI
[09:04] <infinity> G0SUB: If you want to prove that you've got the m4d GUI sk1llz required for the SoC stuff you're proposing, maybe you could look at this gnome-user-share issue? :)
[09:04] <infinity> G0SUB: I suspect that for someone with the right background (ie: not me, I don't touch GUIs), it may be a 10-minute hack.
[09:05] <G0SUB> infinity: heh, I agree
[09:05] <pygi> GOSUB: oki, I'll look into it
[09:05] <Mithrandir> pygi: got an url?
[09:05] <G0SUB> pygi: thanks a lot
[09:05] <pygi> Mithrandir: I sent you to pm the url
[09:05] <Mithrandir> oh, thank
[09:05] <infinity> G0SUB: A patch would make me a very happy camper (and pretty keep on being your mentor for the actual SoC project)... <hint, hint>
[09:06] <G0SUB> infinity: is there any bug report? I came in just now :)
[09:06] <kagou> infinity: for Bug #27608 can i propose a simple patch to remove default home share in smb.conf
[09:06] <Ubugtu> Malone bug 27608 in samba "Entire home dir is shared within another in samba!" [Normal,Needs info]  http://launchpad.net/bugs/27608
[09:06] <Mithrandir> pygi: uh, aren't the students supposed to write something about themselves and their skill set?
[09:06] <pygi> Mithrandir: indeed 
[09:07] <infinity> G0SUB: There is a bug report or 12, but the jist of it is what's been said above.  When you create a new share with gnome-user-share, you can't actually ACCESS it, cause no one's ever run "smbpasswd -a <yourusername>"
[09:07] <G0SUB> infinity: ah!
[09:07] <G0SUB> infinity: now I got it the whole context
[09:08] <pygi> Mithrandir: make a comment stating all your remarks about that application (a lot of them), and publish it to the student
[09:08] <infinity> kagou: I don't really see that one as a bug, TBH.  Not after the followup comments, which seem to lead me to believe that he shared a directory with a sharename matching his username.
[09:09] <infinity> kagou: But maybe you can convince me to comment out the user shares by default in Ubuntu.
[09:09] <G0SUB> infinity: a patch will come soon
[09:09] <pygi> Mithrandir: considering the complexity of that spec, we can't allow something like this :-/
[09:10] <infinity> kagou: I'm still weighing the options between "being gratuitously different from most Samba installations" and "desktop user won't confuse themselves"
[09:10] <pygi> GOSUB: seems nice on first sight
[09:11] <G0SUB> pygi: thanks
[09:11] <kagou> infinity: i must go away now. I will think at this and contact you later. It's a HUG DAY http://fridge.ubuntu.com/node/363 so i want to close samba bugs ;)
[09:12] <G0SUB> infinity: I don't see any gnome-user-share, it's called shares-admin which comes under gnome-system-tools I guess
[09:13] <pygi> infinity: will you be mentoring that samba thingy if it's accepted?
[09:13] <infinity> G0SUB: Err, that thing.  Blame kagou for me naming it incorrectly. :)
[09:14] <G0SUB> infinity: hehe :)
[09:14] <infinity> pygi: If G0SUB's up to the task, and we add some polish to his spec, I'll likely mentor him, yes.
[09:14] <jdub> (that said, samba integration for gnome-user-share might be interesting)
[09:14] <pygi> infinity: nice
[09:17] <infinity> jdub: What *is* gnome-user-share? :)
[09:17] <infinity> jdub: Oh, webdav.
[09:17] <Mithrandir> infinity: "share this folder on the network" clicky in nautilus.
[09:17] <jdub> Mithrandir: not quite
[09:17] <Mithrandir> jdub: oh?
[09:17] <infinity> Mithrandir: No, that's shares-admin
[09:18] <jdub> it runs apache for webdav serving ~/Public with avahi love
[09:19] <pygi> Mithrandir: will you have enough time to comment?
[09:20] <jdub> (i think ~/Public style serving is a better model than the windows-style 'randomly choose stuff to serve' model)
[09:22] <Mithrandir> pygi: I've already done it.
[09:22] <Mithrandir> pygi: basically saying "please provide more information or I can't evaluate your application"
[09:24] <G0SUB> infinity: gnome-system-tools is in C ... I need more time to look at it
[09:24] <ajmitch> when is edgy's feature freeze likely to be? around the time SoC work ends?
[09:24] <G0SUB> ajmitch: lol
[09:25] <Mithrandir> ajmitch: two days after UiP. ;-P
[09:25] <ajmitch> G0SUB: generally any SoC project for ubuntu will have to be ready by feature freeze to make it in
[09:26] <G0SUB> ajmitch: I agree. SoC will end on 23 August btw.
[09:31] <pygi> Mithrandir: oki, nice
[12:05] <holycow> hey guys
[12:06] <holycow> hey, i want to deploy ubuntu for a few regular users, and would like to set it up so that if they screw up their box, they can powercycle, and from startup select a backup image to restore the to / partition
[12:07] <holycow> how would one go about setting this up?
[12:08] <HiddenWolf> holycow: if you can't trust them with administrator-rights, why give it to them?
[12:08] <holycow> HiddenWolf, ultimately that is the answer, HOWEVER, i'm thinking useablity here
[12:09] <holycow> there are certain functions non codemonkeys could use to make their computing environment nicer ... restore to base install is one
[12:09] <holycow> snapshot +1 would be another 
[12:11] <Kamion> you could use LVM snapshots
[12:11] <Kamion> some assembly required, though
[12:11] <lifeless> HiddenWolf: windows machines from vendors come with such a easy-restore option
[12:11] <lifeless> HiddenWolf: it can be nice
[12:12] <holycow> *hmmm* thats not a bad idea, my initial thought was partimage 
[12:12] <HiddenWolf> lifeless: I know.
[12:12] <Kamion> it was discussed at UDU in relation to the OEM installer, but never really made it as far as a design
[12:12] <pygi> Kamion: there is a suggestion for doing app like that in SoC
[12:12] <holycow> is lvm the right idea tho? i've read many an issue with dealing with lvm restores
[12:12] <Kamion> oh, well, it sort of did
[12:13] <Kamion> https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/OEMRescue
[12:13] <holycow> my intuitition would say something like using partimage, and doing a diff restore/backup
[12:13] <Kamion> but I think it would be necessary to rethink it anyway
[12:13] <pygi> Kamion: https://wiki.ubuntu.com/GoogleSoC2006#head-6f1deddcffc4e286e0bbd987f3a424b4b3a82479
[12:13] <Kamion> holycow: nothing wrong with using partimage, it just takes more disk space
[12:13] <holycow> okay so i guess the idea has been brought up but not worked ona whole lot ... 
[12:14] <Kamion> pygi: bit vague though
[12:15] <leo> hi , I'am modifying a live cd - i changed my gdm.conf but i looks like a script is overwriting my gdm.conf with a default when the live session is prepared? Someone an idea which script is responsible for this?
[12:16] <holycow> btw kamion, some of those ideas on that page are great
[12:16] <HiddenWolf> holycow: and some are hilarious
[12:17] <holycow> :)
[12:17] <holycow> the oem rescue thing is a good idea
[12:17] <HiddenWolf> holycow: there is a suggestion to make xgl work on S3 graphics solutions and such. ;)
[12:17] <holycow> that i guess would be a step of last resort, would be also nice to setup something like allowing users to snapshot environment at will as per wiki suggestions
[12:18] <holycow> HiddenWolf, ehehe :)
[12:18] <holycow> classic
[12:19] <HiddenWolf> Things like parental control however, seem like great things.
[12:19] <HiddenWolf> specially considering edubuntu
[12:19] <holycow> ah yes i would agree, that would be excellent
[12:19] <holycow> my only question is what does parental control mean
[12:20] <HiddenWolf> holycow: preventing kids from doing kid-unfriendly-stuff on their pc's
[12:20] <holycow> its a hard thing to define, i would guess the most meaningfull aspect of pare ntal control would be total logging, including mouse movements and system use playback
[12:20] <pygi> well, by looking at current applications for that, it seems people think parental control is only web filtering
[12:20] <ogra> holycow, a (probably transparent) filtering proxy for web content 
[12:20] <ogra> pygi, thats the main purpose
[12:21] <holycow> call it heresy, i think that probably should be a paid for subscription service
[12:21] <pygi> ogra: true, but not only one 
[12:21] <ogra> you can indeed extend that by something like logging out the kid on schedule (after 1h for example) etc
[12:21] <holycow> i would really say as well that it requires complete logging of environment use
[12:21] <holycow> including ability of playback of kids useof system
[12:22] <holycow> i have parents at the company ask me for that many many times
[12:22] <tseng> pygi: false
[12:22] <pygi> ogra: the suggestion is talking about Dansguardian + Squid, and considering we'll be using willow :-/
[12:22] <tseng> pygi: http://spectresoft.com/
[12:22] <tseng> pygi: commercial products cover alot more than web
[12:22] <pygi> tseng: and what have I said ? :P
[12:22] <pygi> that it's not the only purpose =P
[12:23] <holycow> tseng, ah neat, thats cool, good bookmark.
[12:23] <tseng> you claimed most products dont do anything else, or so
[12:23] <pygi> tseng: I claimed SoC applications mostly claim that 
[12:23] <tseng> oh.
[12:23] <ogra> pygi, dansguardian is crap (as squidguard is) and indeed parental control is more than proxying, but a contentfilter is an essential bit 
[12:24] <pygi> ogra: agreed...so please take your time to comment on that application, or should I?
[12:24] <ogra> pygi, which application ? 
[12:24] <pygi> ogra: Parental control, SoC
[12:24] <pygi> want a url?
[12:24] <siretart> Kamion: I normally don't beg for these kind of things, but could you please  NEW freealut? I already uploaded a couple of package build depending on freealut-dev, and I'd like to get the transition over quickly
[12:25] <ogra> pygi, i dont see it on the official SoC wikipage
[12:25] <Kamion> getting pretty late in the day for transitions, isn't it? :)
[12:25] <pygi> ogra: the mentors part 
[12:26] <pygi> ogra: want a link?
[12:26] <Kamion> siretart: source accepted
[12:27] <siretart> Kamion: thanks!
[12:28] <pygi> ogra: or have you found it?
[12:47] <ogra> pygi, commented it
[12:48] <pygi> ogra: thanks, I'll look into it now
[12:48] <ogra> i'll also update the willow description a bit now 
[12:48] <ogra> (if Amaranth doesnt mind :) )
[12:49] <pygi> ogra: have you commented on mentors page? cause I can't see the comment :P
[12:49] <ogra> pygi, nope, in the SoC page
[12:49] <pygi> ogra: bah, you need to comment on mentors page =P
[12:49] <ogra> why ?
[12:49] <pygi> and make it public so student can see it
[12:49] <pygi> well, so student can improve application? 
[12:51] <flurble> Kamion: riddell says, his internet is broken this morning and hell be on as soon as its fixed
[12:52] <Kamion> flurble: thanks
[12:53] <Kamion> flurble: passed on to the Canonical talk mailing list
[12:54] <flurble> ok
[12:59] <nags> when I try to build this source http://mutt.in/~nagappan/ldtp-tmp-source.tar.bz2 in SuSE / FC4 its working fine, But unable to build it in Ubuntu. I feel I miss something in configure.in, how could I fix it ?
[12:59] <nags> some assistance will be of great help :)
[12:59] <Kamion> that depends on what the failure is
[01:00] <nags> Kamion: okay...
[01:00] <nags> Kamion: G0SUB tried it building...
[01:01] <Kamion> perhaps you could put the output in a pastebin
[01:01] <nags> G0SUB: can you please ? and give the link to Kamion ?
[01:01] <ogra> i test built it during breezy time ... shouldnt be impossible 
[01:02] <Kamion> don't give the link to me personally, give it to the channel
[01:02] <nags> Kamion: right :)
[01:02] <G0SUB> nags: in a sec
[01:02] <nags> G0SUB: okay
[01:02] <nags> ogra: you tried building ldtp source ?
[01:03] <G0SUB> nags: this is the special tmp code btw. not ldtp proper
[01:03] <nags> G0SUB: right
[01:03] <G0SUB> nags: and with all symlinks removed
[01:03] <G0SUB> http://pastebin.com/695874
[01:03] <nags> G0SUB: soon this will be checked in
[01:03] <nags> G0SUB: right
[01:03] <ogra> nags, yes, shortly after the stuttgard guadec
[01:04] <nags> ogra: oh okay :)
[01:04] <ogra> quite some time ago :)
[01:04] <nags> ogra: lot of changes recently ;)
[01:04] <nags> ogra: okay
[01:04] <nags> Kamion: looks like the source files are not properly taken for compiling ?
[01:06] <pitti> Diziet: yay new gs-esp; how many bugs does that close? :)
[01:06] <Kamion> yum, a source tarball that requires you to run autoreconf
[01:06] <soumyadip> ok it looks like the libtool package is required
[01:06] <ivoks> how many opens? :)
[01:07] <nags> soumyadip: do I need to mention the libtool some where ?
[01:07] <pitti> Diziet: ah, just saw your bug mail
[01:08] <soumyadip> nags: yes when you build the package, libtool should be in build-dependencies in the debian/control file
[01:09] <nags> soumyadip: oh okay
[01:09] <nags> soumyadip: is it required even if we do ./autogen.sh ?
[01:09] <soumyadip> yes
[01:09] <nags> soumyadip: hmmm
[01:09] <soumyadip> because autogen.sh calls libtoolize, which is in the libtool package
[01:09] <Kamion> especially if you do ./autogen.sh
[01:10] <nags> kagou / soumyadip: okay
[01:10] <nags> the issue comes on doing make
[01:10] <nags> after this change things are not working http://webcvs.freedesktop.org/ldtp/ldtp/configure.in?r1=1.4&r2=1.5
[01:11] <Kamion> that's extremely unlikely to matter
[01:11] <Kamion> it's just a version number bump
[01:11] <soumyadip> eh ? why does gcc complain of no input files when I run make after autogen.sh ?
[01:12] <Mithrandir> infinity: care to disable the daily livefs builds?
[01:12] <Kamion> investigate the Makefile and trace back the missing bits through Makefile.in and Makefile.am if necessary
[01:12] <nags> Kamion: sorry one more... 
[01:12] <nags> Kamion: I have modified this line
[01:12] <nags> Kamion: enable_localization=yes
[01:12] <nags> Kamion: to enable_localization=no
[01:13] <Kamion> nags: I'm totally unfamiliar with this package; I'm trying to help *you* investigate rather than investigating myself
[01:13] <Amaranth> ogra: cool, be nice to know what i'm getting myself into :)
[01:13] <nags> Kamion: okay :)
[01:13] <Kamion> there should be a something_OBJECTS that gets substituted into the gcc link line
[01:13] <Mithrandir> Riddell: when you get around, please do start testing current install images for flight-7.
[01:14] <Mithrandir> ogra: please test current install images for flight-7
[01:14] <ogra> Mithrandir, this week ???
[01:14] <Mithrandir> ogra: yes.
[01:14] <ogra> when are we supposed to work on stuff ? 
[01:14] <nags> Kamion: http://pastebin.com/695882
[01:14] <ogra> i cant always loose 2 days of a week for iso tests
[01:14] <Mithrandir> ogra: before FF. :-)
[01:15] <Mithrandir> ogra: well, previous release was special because of the crazy beta bug.
[01:15] <ogra> so we'll keep the 2 week schedule ? 
[01:15] <Kamion> you shouldn't be spending two days on Flight testing
[01:15] <ogra> (apart from the beta2 exception)
[01:15] <Kamion> ogra: depends
[01:15] <Mithrandir> ogra: two or three; depending.
[01:16] <ogra> Kamion, if i discove a bug i need to change it takes me half the day to wait for LP
[01:16] <Kamion> we need to get good installer testing, and that has been hampered by bugs that affected lots of people
[01:16] <Mithrandir> ogra: if you don't want flight-7 for edubuntu, that's fine with me, though.
[01:16] <Kamion> ogra: I have three weeks to get a working installer; I can't do that without occasional releases
[01:16] <Kamion> ogra: do something else while you're waiting, then
[01:16] <ogra> Kamion, fully understood, but iso testing means i need to postpone my artwork changes again etc
[01:17] <ogra> Kamion, all i need to do would affect the isos, thats my prob (artwork docs etc)
[01:17] <Kamion> you shouldn't be losing days of work due to this. you might have to queue uploads for a while, but that's not losing days of work.
[01:17] <Kamion> you can upload them all in a batch the next day
[01:18] <ogra> i need to test the changes, probably need to build a test iso etc thats all blocked then ... but well, i'lll start my rsyncs
[01:18] <ivoks> Kamion: am... rebuild of package with unmet deps is automatic or needs manual push? (now, when all deps are ok)
[01:18] <Kamion> Mithrandir: I have two things in progress; one is a ubiquity upload to fix a few bugs and save /var/log/partman to the installed system for better debugging; the other is a partman-* change for bug 21655
[01:18] <Ubugtu> Malone bug 21655 in partman-basicfilesystems "Installer doesn't change disk labels as appropriate" [Wishlist,Confirmed]  http://launchpad.net/bugs/21655
[01:19] <Kamion> ivoks: depends on the circumstances, ask infinity
[01:19] <ivoks> ok, tnx
[01:19] <ivoks> bye all
[01:19] <Mithrandir> Kamion: sure, I'll wait for those.
[01:19] <Mithrandir> Kamion: (hence my "test install cds" not "test cds")
[01:19] <Mithrandir> I should tell janimo too.
[01:20] <Kamion> the partman change would affect install CDs too
[01:20] <Mithrandir> oh, true.
[01:20] <Mithrandir> (topicdiff: add "to main"; I don't want to review uploads to universe. :-)
[01:21] <ogra> so what made my install CDs explode ?
[01:21] <ogra> *sigh*
[01:21] <ogra> *sigh*
[01:22] <Amaranth> who handles accepting/rejecting SoC applications?
[01:22] <Kamion> I'd have liked to get in a fix for the problem that ubiquity doesn't handle partman exceptions, but I doubt I have time
[01:22] <ogra> Amaranth, JaneW 
[01:22] <ogra> Amaranth, i updated the featurelist for willow on the wiki, would you mind making a LP spec out of it ?
[01:23] <Amaranth> i'll see what i can do
[01:23] <Amaranth> it'd be nice to know if it's going to be accepted/rejected though so i can know if i should look at other projects
[01:24] <ogra> Amaranth, the more work you put into it now, the more likely it will be *your* project ;)
[01:24] <Amaranth> heh
[01:24] <ogra> (according to JaneW writing the spec is a major step here)
[01:25] <Amaranth> ok
[01:38] <nags> Kamion: when doing autogen.sh, I get this error message
[01:38] <nags> src/Makefile.am:16: ldtp_SOURCES defined both conditionally and unconditionally
[01:38] <nags> src/Makefile.am:76: ldtp_LDADD defined both conditionally and unconditionally
[01:38] <nags> what this means ?
[01:38] <Kamion> I suggest you talk to upstream
[01:38] <nags> Kamion: okay
[01:39] <Kamion> you could also look at info automake and search for "conditional" if you are upstream :-)
[01:39] <herzi> mvo: you wanted me to remind you of https://launchpad.net/bugs/36127
[01:39] <Ubugtu> Malone bug 36127 in grub "ESC menu doesn't work" [Normal,Needs info]  
[01:40] <mvo> herzi: right, thanks
[01:40] <nags> Kamion: okay :)
[01:44] <G0SUB> mvo: ping
[01:44] <mvo> G0SUB: pong
[01:45] <infinity> Mithrandir: Doing so.
[01:45] <G0SUB> mvo: can I PM?
[01:45] <Kamion> Mithrandir: it's also worth noting that we're half-way through a kernel ABI change at the moment
[01:45] <mvo> G0SUB: sure
[01:45] <pitti> fabbione: alright, current dapper doesn't crash any more with the test
[01:46] <Kamion> the last kernel upload didn't build on sparc, and l-r-m/linux-meta/debian-installer haven't been uploaded to match yet
[01:46] <Mithrandir> Kamion: argh. :-/  Any idea when that'll be fixed?
[01:46] <Kamion> Mithrandir: no ...
[01:46] <Kamion> BenC: around?
[01:47] <BenC> Kamion: yeah
[01:47] <Kamion> BenC: did you notice the kernel FTBFS on sparc?
[01:47] <infinity> I pinged him about it, but I think he was asleep. :)
[01:47] <BenC> yeah, fixing it for next upload
[01:47] <Kamion> ok, thanks
[01:48] <infinity> Kamion: Can you just go ahead without the ABI bump, or does the mismatched source offend you terribly? :)
[01:48] <Kamion> Mithrandir might want to know roughly when to expect it :)
[01:48] <Mithrandir> BenC: what's the ETA of that upload?
[01:48] <BenC> later today
[01:48] <Kamion> infinity: hmm, it rather annoys me for Flight releases - gets messy
[01:48] <Mithrandir> BenC: 'k, thanks.
[01:48] <Kamion> although it's probably technically possible to go ahead without, if the seeds haven't been changed yet
[01:48] <infinity> BenC: As in, the end of your workday. Ish?
[01:49] <BenC> nah, probably more like my lunch time ish
[01:49] <pitti> hi BenC 
[01:49] <BenC> hey pitti
[01:49] <BenC> pitti: I have that upload ready too
[01:49] <pitti> \o/
[01:49] <infinity> So, if you need to just do the ABI bump in my absense, go nuts, I guess.
[01:50] <Mithrandir> infinity: we can just postpone until tomorrow.
[01:50] <BenC> infinity: ok, I will probably just do an abi bump upload with this upload, so I can get linux-meta done, and people can start testing this last upload
[01:50] <BenC> I want some feedback on ipw3945
[01:50] <Kamion> hmm. if I've got a bit of clearance, I'll start looking at the ubiquity/partman work again; would be nice to have all the top diagnosed crashers fixed
[01:51] <infinity> Mithrandir: I'm cool with that too, since I plan to do some mad initramfs-tools bugfixing during *my* tomorrow, which would means they'd get in for flight-7 your tomorrow. :)
[01:51] <BenC> brb, gotta walk to the bus stop
[01:51] <Mithrandir> infinity: ok, let's build the images and stuff tomorrow then.
[01:51] <infinity> s/means/mean/
[01:51] <infinity> Mithrandir: It's a date.  You have me as a flunky after I polish up initrafms-tools and LRM tomorrow.
[01:52] <ogra> yeah, it would be great to have some preparation time
[01:52] <Mithrandir> I'll leave the topic as is so we don't get any gung-ho uploads, though.
[02:07] <Lathiat> hrm
[02:07] <Lathiat> anyoejn got a pointer to a discussion on moving removable media into a sub menu of places?
[02:13] <infinity> pitti: In the name of having rebuildable flight releases (okay, just cause I'm a pedant), care to upload that fixed m-f-l-a package sometime between now and tomorrow? :)
[02:14] <Riddell> Mithrandir: is flight 7 just text-install or text-install and desktop CD?
[02:14] <pitti> infinity: oops, yes, will do right now if Mithrandir ack's
[02:14] <Mithrandir> Riddell: we've decided to wait building the cd images until tomorrow.
[02:14] <infinity> pitti: I ack. :P
[02:14] <Mithrandir> Riddell: since Kamion wants a few fixes into partman and we're in the middle of a kernel ABI transition
[02:15] <Riddell> Mithrandir: ok
[02:15] <herzi> mjg59: ping
[02:16] <pitti> infinity: uploaded
[02:17] <Kamion> Riddell: both, though
[02:17] <Kamion> priority is on desktop if anything
[02:22] <mjg59> herzi: Hi
[02:22] <herzi> mjg59: you did some wacom stuff in ubuntu, can you take a look at https://launchpad.net/bugs/42653 please?
[02:22] <Ubugtu> Malone bug 42653 in wacom-tools "Please add on-the-fly-rotation support" [Normal,Unconfirmed]  
[02:22] <mjg59> Uh. We have that code.
[02:22] <mjg59> Or did, last time I checked
[02:42] <Hadaka> ah, right, tjanks
[02:46] <Diziet> pitti: yay indeed.  It probably fixes other bugs too but we're relatively short of reports against gs-esp.
[03:24] <pitti> StevenK: could you find out the reason for the empty pot file?
[03:32] <infinity> dholbach: On my way to bed, but I'm bugging you first, so nya nya. :)
[03:33] <highvoltage> dholbach: how's bugday?
[03:33] <infinity> dholbach: In the latest goffice, the new package "libgoffice-1-2-dbg" doesn't have a Description field, which leads to soyuz rejecting the binary upload from my buildds.  Please fix. :)
[03:33] <Mithrandir> dholbach: popcon seems to work now.
[03:34] <janimo> nomed: meeting in #xubuntu
[03:34] <janimo> Gloubi|AFK: meeting. when you stop being AFK :)
[03:34] <Mithrandir> janimo: are you ok with releasing xubuntu flight-7 tomorrow?
[03:34] <LaserJock> Mithrandir: cool, now if we can just get people to use it :-)
[03:34] <janimo> Mithrandir:hmm. I am I guess
[03:34] <janimo> ok
[03:34] <nomed> janimo, #xubuntu or #ubuntu-meeting ?
[03:34] <janimo> nomed: meeting
[03:35] <janimo> sorry
[03:35] <janimo> Mithrandir: tomorrow evening?
[03:35] <Mithrandir> janimo: I'd need to have one of you test the images and such, but we'll do that tomorrow after kernel abi bump and such.
[03:35] <Mithrandir> janimo: sounds good to me.  I'll make xubuntu images when I do the other images tomorrow morning.
[03:35] <janimo> Mithrandir: sure. I can test the live at least
[03:35] <Mithrandir> thanks.
[03:35] <nomed> i can do that me too if needed
[03:36] <janimo> Mithrandir: so the flight7 candidate is approximately todays iso + new kernel and such?
[03:36] <janimo> nomed: sure.
[03:36] <infinity> janimo: Dude, care to look at why thunar fails to build on amd64 and powerpc sometime in the next 24 hours?
[03:36] <infinity> janimo: Just so your sources and binaries agree for Flight-7.
[03:36] <janimo> infinity: I'll look tahnks
[03:36] <Mithrandir> janimo: approximately, yes, but I'll roll image tomorrow and would appreciate to have the right set of images tested. :-)
[03:37] <janimo> Mithrandir: ok
[03:38] <Kamion> janimo: there'll be at least one new ubiquity upload before then with (if I get them done in time) one or two fairly substantial changes
[03:38] <infinity> janimo: The sooner, the better, if you want Mithrandir to let it in. :)
[03:39] <janimo> infinity: ok :)
[03:39] <TheMuso> Mithrandir: http://www.themuso.id.au/ubuntu/casper -- Final bugfixes. Everything finally seems to check out here. No hurry as we do not know yet how we are going to get ubiquity to be fully accessible.
[03:39] <Kamion> Mithrandir: (for a laugh, try selecting Vietnamese in a current image's ubiquity. You might need to 'echo SET debian-installer/locale en_US.UTF-8 | sudo debconf-communicate' afterwards to recover ...)
[03:39] <janimo> otherwise it means no amd64 images, hence flight 7 postponed?
[03:39] <janimo> xubuntu flight I mean
[03:40] <Kamion> only if thunar is currently uninstallable on amd64/powerpc as a result
[03:40] <Kamion> which, according to http://people.ubuntu.com/~cjwatson/testing/dapper_probs.html, it isn't
[03:40] <Kamion> isn't uninstallable, that is
[03:41] <Mithrandir> TheMuso: "no hurry" as "I would like this into flight-7" or "this should go in whenever"?
[03:42] <infinity> janimo: Yeah, it's not the end of the world if it doesn't build, but you have a better idea of the bugs beta testers are seeing if the versoins are the same on all arches and you have a baseline.
[03:42] <infinity> janimo: So, it's in your best interest to make sure it builds, but not critical for Flight-7.
[03:42] <TheMuso> Mithrandir: No hurry, as it should go in whenever.
[03:42] <janimo> infinity: oh ok got it. I think upstream has just commited some fixes wrt 64bit 
[03:42] <infinity> janimo: It /is/ critical for the final release, of course, we don't want to ship packages that don't build.
[03:43] <infinity> janimo: 64-bit may explain amd64, that doesn't explain powerpc... (and you can't explain powerpc failing with endianess either, since hppa and sparc are also big-endian and they built fine)
[03:43] <infinity> janimo: But, good luck anyway. :)
[03:43] <janimo> infinity: thanks. I'll poke upstream if I can't figure it out
[03:50] <tritium> simira: re: your question in #ubuntu, perhaps gnome-system-tools
[03:50] <simira> tritium: thanks
[03:52] <tritium> simira: the package description claims there's a tool for managing bootloaders, although I don't seem to find it...
[03:53] <simira> tritium: I can't even find the package yet...
[03:53] <tritium> ok
[03:54] <infinity> tritium: We intentionally don't include said tool because it can muck up the user's grub config in ways that don't play nicely with our automagic updating stuff, IIRC.
[03:55] <tritium> infinity: ah, okay.  Thanks.  Sorry, simira.
[03:55] <simira> infinity: how can I play with grub without editing menu.lst directly, then?
[03:55] <simira> tritium: np, I blame infinity, not you
[03:59] <infinity> simira: At the moment, you can't, really.
[04:01] <simira> infinity: I'm not really satisfied with that answer
[04:02] <infinity> zul: I assume your xlockmore changelog doesn't actually match the source?
[04:02] <infinity> zul: (Seems to imply that the binary is installed in /usr/X11R6/bin, when it should just be in /usr/bin)
[04:04] <Kamion> simira: unfortunately, until somebody fixes boot-admin not to cause more serious bugs every time somebody runs it, the alternative is worse
[04:06] <simira> Kamion: ok, I'll make Tollef fix it, then. Or make him teach me how to. :D
[04:08] <zul> infinity: it should be /usr/bin yes
[04:08] <zul> whoops..typo that should be /usr/bin in the changelog
[04:17] <abattoir> Kamion: hello... I'd like to make a Kubuntu OEM Installer as part of Google SoC... I'd like to know if the "OEM installation mode" in the CD requires a blank harddisk, or can it use a partition?
[04:19] <tepsipakki> Kamion: just wanted to tell you that the multiverse/local-repository-support in apt-setup works like a charm, thanks :)
[04:22] <Kamion> tepsipakki: great, good to hear
[04:22] <Kamion> abattoir: it's the same as any other Ubuntu installation mode; you can get to the manual partitioner if you want
[04:23] <Kamion> abattoir: a fair chunk of the work in doing a Kubuntu OEM installer is in making the core code frontend-independent, much the same way as Ubiquity does
[04:23] <Kamion> also, my feeling is that once you do that it stops being worth having separate glade files for each component, and maybe the OEM installer's UI should just all be in the oem-config package
[04:24] <Kamion> which would reduce our diff from Debian in the component packages so would probably be a good thing anyway
[04:25] <abattoir> Kamion: I havent looked at the Ubuntu Installer yet... but I was thinking of an application which runs under KDE, which helps the OEMs tweak 'their Version' of the OS...
[04:26] <abattoir> eg. install drivers, configure KDE, change elements of the Desktop etc...
[04:33] <Kamion> abattoir: that's rather different to the OEM installer
[04:33] <Kamion> abattoir: the OEM installer is something that is run when the end user first starts up their new computer, and asks them for personal details
[04:33] <Kamion> abattoir: I'm sure what you describe is useful, but could you call it something else? :-)
[04:34] <ogra_> i think thats rather near to my branding tool proposal
[04:34] <zakame> hmm what's up with https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/BugReportingRoadmap ?
[04:34] <abattoir> Kamion: My proposal consists of twin applications, the second one is what you describe.....
[04:34] <infinity> dholbach: Merry Christmas, I just uploaded the fix for that goffice bug.  You may disregard my previous messages. :)
[04:35] <Kamion> abattoir: ok
[04:35] <Kinnison> infinity: I thought I told you to go to bed
[04:35] <infinity> Kinnison: I told myself to do that too.  I keep not getting around to it.
[04:36] <abattoir> Kamion: I have a mockup http://abattoir.4t.com/Images/hlada.png
[04:36] <abattoir> is this what you are referring to?
[04:37] <Kamion> abattoir: that looks similar to the OEM installer, yes, although we don't have any provision for network configuration in it yet
[04:37] <Kamion> partly because I figured just assuming DHCP would do for the majority ...
[04:37] <Kamion> what's the "Register" step?
[04:38] <pitti> seb128: his dog ate him
[04:38] <abattoir> That depends on the OEM, they could make the user register w/ them if they want...
[04:38] <Kamion> if you'll take my advise, don't do "First Name" and "Last Name"
[04:38] <abattoir> do you want to see my proposal?
[04:38] <Kamion> advice, rather
[04:38] <seb128> pitti: probably something like that ;)
[04:38] <abattoir> Kamion: ok...
[04:38] <infinity> I prefer freeform "Full name", and they can fill it out however they like.
[04:39] <Kamion> names are complicated when you consider conventions in different countries; trying to split them up is more pain than it's worth
[04:39] <pitti> seb128: if you miss him, shall I call him?
[04:39] <Kamion> abattoir: feel free to e-mail it to me, cjwatson@ubuntu.com; though I don't promise to reply immediately :)
[04:39] <pitti> infinity: did you plan to update mysql to 5.0.21 in dapper?
[04:39] <seb128> pitti: no, no real hurry, I've just some bugs where I could use his opinion but that can wait :)
[04:39] <infinity> pitti: Yes, I got the UVF exception from mdz yesterday.
[04:39] <pitti> infinity: cool; it fixes a security issue; I'll toss you the CVE as soon as I have it
[04:40] <pitti> infinity: (patch is relatively easy, I'll care for stables)
[04:40] <seb128> pitti: hum, I've just noticed you are not on #ubuntu-bugs for the bug day ... :)
[04:40] <infinity> pitti: Oh, thanks, if you get it to me before the Debian upload, I'll make sure it's in the Debian changelod for 5.0.21-1
[04:40] <pitti> seb128: check again :)
[04:40] <abattoir> Kamion: I have already submitted it through Google, I just wanted some doubts cleared :) ...
[04:40] <seb128> pitti: hehe
[04:40] <seb128> pitti: german slackers!
[04:40] <pitti> seb128: I just fixed your gdm, dude :) (in stables)
[04:41] <seb128> ah, nice
[04:41] <Kamion> abattoir: I think you probably want to start looking at oem-config to get an idea of what's available/doable. (Ignore the crap UI. If Ubiquity weren't taking up so much of my time I'd fix it up before Dapper, but I think it'll have to wait until Edgy now.)
[04:43] <seb128> pitti: fort that .ICEauthority permissions bug?
[04:43] <abattoir> Kamion: Ok, thanks :)
[04:44] <pitti> seb128: yes
[04:44] <seb128> pitti: be careful, you want that change too: http://cvs.gnome.org/viewcvs/gdm2/daemon/slave.c?r1=1.325&r2=1.326
[04:45] <pitti> seb128: I know, I have it
[04:45] <seb128> pitti: that was an issue with 2.14.4 which has been fixed monday, without it the gid was not set correctly
[04:45] <seb128> k
[04:45] <pitti> seb128: and I tested it over and over again in a clean real breezy
[04:45] <seb128> better to make sure so you don't have to do it again in case you didn't nice ;)
[04:45] <seb128> should be fine so
[04:45] <pitti> seb128: right, thank you
[04:46] <pitti> seb128: I just don't understand why all this mess is necesary in the first place; just rm'ing the file should work, too, or not?
[04:46] <seb128> not sure, I've not tried to understand that code to be honest ;)
[04:46] <seb128> I just updated to new version which was marked as fixing the issue for dapper
[04:47] <pitti> I understood the old and new code, and I think the new one is reasonable, but it still seems way too complicated to me
[04:47] <pitti> seb128: yep, 2.14.4 + that patch should be fine
[04:48] <seb128> feel free to open a bug against gdm on bugzilla.gnome.org
[04:48] <seb128> upstream is really nice, and open to discussion
[04:49] <seb128> a little too verbose to my taste (like you have a quick question and you get several pages of details explanations for it) :)
[05:13] <ogra_> Amaranth, hey cool, thanks a lot :)
[05:13] <Amaranth> ogra_: ?
[05:13] <Amaranth> my spec writing skills are bad, was hoping you could flesh out any details that might be needed
[05:15] <ogra_> Amaranth, just having that as a base is already enough for now
[05:15] <Amaranth> had a comment on my application, said i needed to show my skill-set :)
[05:15] <ogra_> i'll flesh it out later, it was just important that we have *anything*
[05:15] <ogra_> point them to alacarte ...
[05:15] <Amaranth> i did :)
[05:15] <Amaranth> it was from pygi, i think
[05:15] <Amaranth> crap, going to be late for school
[05:16] <Amaranth> back later
[05:16] <ogra_> ciao and thanks again
[05:16] <simira> mvo: is kernels supposed to be updated with update-manager?
[05:17] <jsgotangco> yeah it could
[05:24] <pitti> Mithrandir: oops, shit, my autofingers stroke me
[05:25] <pitti> Mithrandir: I uploaded a security fix of libnasl
[05:25] <pitti> Mithrandir: shouldn't be on the CD, and is not disruptive; sorry, though, I thought too late
[05:25] <Mithrandir> pitti: sure, no problem.
[05:25] <Mithrandir> pitti: as a penance, you'll have to develop a tool called autofingers which does something cool.
[05:26] <simira> hmmm
[05:26] <pitti> heh, several things come to my mind at once :)
[05:28] <Kamion> pitti: SURELY you mean "struck" or something. :-)
[05:29] <lamont> Kamion: that changes the whole meaning though.....
[05:29] <pitti> yay my ISP
[05:29] <pitti> Kamion: the autofinger tool Mithrandir wants should really be something that autocorrects my Denglish
[05:29] <pitti> hey lamont 
[05:37] <dholbach> Mithrandir: you rock
[05:37] <Mithrandir> dholbach: it'll rock even more when we have a css that doesn't suck
[05:37] <dholbach> probably :)
[05:43] <simira> popcorn?
[05:43] <simira> hm
[05:43] <thom> tseng: not so much installing as turning it on :-)
[05:43] <tseng> simira: no, popcon.
[05:44] <tseng> hey thom 
[05:44] <tseng> hows things?
[05:44] <thom> good ta. you?
[05:44] <tseng> good.
[05:44] <LaserJock> anybody know what "touch: missing file operand" means when I do dpkg -i ?
[05:45] <tseng> LaserJock: could you be more specific? is that from a failing postinst?
[05:45] <simira> oh, popcon.
[05:45] <simira> hm, wll
[05:45] <simira> hi thom :)
[05:46] <LaserJock> tseng: post-remove
[05:46] <tseng> LaserJock: there you go. blame the package
[05:46] <tseng> their script is broken
[05:47] <LaserJock> tseng: it isn't in the package, it must be one of the added ones
[06:17] <bddebian> Howdy peoples
[06:17] <pitti> hi bddebian 
[06:17] <bddebian> Hi pitti
[06:22] <Tonio_> hi
[06:25] <kyr0> hi
[06:26] <bddebian> Hello kyr0
[06:27] <kyr0> are there package cd's/dvd's with all packages from a currently stable ubuntu(breeze) avaliable for download?
[06:33] <kyr0> the main problem is, that many people dont have a working internet connection or dont want to download X GB of data from the internet. If it would be possible to burn all available packages on 4 or 5 dvd's it would be much easier to share this great distribution!
[06:34] <stratus> kyr0, http://cdimage.ubuntu.com/releases/breezy/release/
[06:35] <zul_> is there a template for writing a spec?
[06:36] <kyr0> stratus: hmm is this dvd really including all packages? 
[06:36] <stratus> zul_, https://wiki.ubuntu.com/SpecTemplate ?
[06:36] <stratus> kyr0, it includes the supported packages, nothing from 'universe' btw.
[06:36] <zul_> thanks
[06:37] <stratus> zul_, you're welcome
[06:40] <bddebian> Kamion: What does Reason NBS mean in the removal of python2.1?
[06:41] <kyr0> stratus: ah okay :) 
[06:44] <ogra> hey stratus 
[06:44] <stratus> ogra, pong :)
[06:45] <ogra> some days ago a guy asked me for help how to set up debians new ltsp
[06:45] <ogra> i told him to use ltsp-build-client which he couldnt find apparently, why did you rename it ?
[06:45] <stratus> we didn't
[06:45] <ogra> seemed its called -make-client
[06:46] <ogra> hmm
[06:46] <ogra> thats strange
[06:46] <ogra> i have manpages btw
[06:46] <stratus> ltsp-make-client looks like something in debian-edu (skolelinux)
[06:46] <ogra> just merging them in my package
[06:46] <ogra> aha !
[06:46] <ogra> peres fault !
[06:46] <stratus> i think it's a pere script, but ltsp-build-client is there
[06:47] <stratus> i think he was going to merge ltsp-make-client features in ltsp-build-client, but it's debian-edu only
[06:47] <ogra> yep, but then i understand
[06:47] <desrt> is there any way to see a list of packages that are current ftbfs?
[06:47] <ogra> desrt, LP
[06:47] <desrt> google is really bad at finding stuff on lp
[06:48] <ogra> teach it !
[06:48] <ogra> https://launchpad.net/distros/ubuntu/+builds
[06:48] <desrt> nice.
[06:48] <ogra> there is also a dapper link i think
[06:48] <stratus> ogra, ltsp-server 0.82debian2 (latest in Debian) has no ltsp-make-client. I've checked again. It seems that the guy was installing a branch that is being used in debian-edu, but i dunno
[06:48] <ogra> https://launchpad.net/distros/ubuntu/dapper/+builds
[06:48] <ogra> thats it
[06:49] <desrt> a hah.  sparc ftbfs
[06:49] <ogra> stratus, its fine, i just thought you had renamed it everywhere
[06:49] <stratus> ogra, no way, not with me alive btw. heh
[06:49] <ogra> :)
[06:50] <stratus> ogra, are you still subscribed in pkg-ltsp-devel ?
[06:50] <ogra> yep
[06:50] <ogra> i saw youre going for local swap as the main feature ?
[06:50] <stratus> did you see my message about pkg-ltsp work during debcamp?
[06:50] <ogra> yep
[06:51] <ogra> i wont be there, too much edubuntu prerelease workv 
[06:51] <stratus> no, the local swap thing was just a comment in a bug pere opened
[06:51] <ogra> ah, k
[06:51] <stratus> oh, it would be good
[06:51] <ogra> my biggest target for next release is localdev support
[06:51] <desrt> alef-null; nice nick
[06:51] <ogra> but without reinventing the wheel with ldm
[06:51] <ogra> err
[06:51] <ogra> lbus, sorry
[06:52] <stratus> we would like to implement the profiles thing in ltsp, splitting the source in more sane binaries and organize ltsp-build-client
[06:52] <ogra> i also agree with vagrant that we should redo -update-kernels
[06:52] <stratus> the major goal during debcamp is share even more code between the projects, with the 'profile' thing, so every hack you need to apply into ltsp-build-client should go in a separate subdirectory 'ubuntu'
[06:53] <stratus> sure
[06:54] <stratus> do you think it's possible that we reach a point where we've basically the same source package in debian, ubuntu (edubuntu), sacix and debian-edu but with different 'profiles' ?
[06:54] <ogra> two other things i'd like to have are thick client support (running all of the desktop on the client) and a quasi kiosk mode (running firefox fullscreen locally instead of a real session)
[06:54] <ogra> stratus, sure
[06:54] <stratus> i think today it's just a matter of clean up the code and organize stuff to read the changes (or run scripts) from a subdirectory per profile
[06:55] <ogra> but i wont be able to look into it much before release anyway
[06:55] <stratus> ogra, great.
[06:55] <stratus> ogra, well but it seems that at least me and otavio will hack on it during debcamp, probably vagrantc will join us too.
[06:56] <stratus> ogra, otavio told me about revamp the 'localapps' thing once we had in the package, i dunno if it will be possible to run all of the desktop on the client, but it should be.
[06:56] <ogra> it is, i know highvoltage did it in breezy already
[06:56] <stratus> ogra, i had a chat with otavio for some hours and we even discussed write some stuff from scratch in python, but vagrant can't code in python. :(
[06:56] <ogra> its just some tweakage to ltsp-build-client to install the desktop in the chroot
[06:57] <ogra> bah, so he's refusing progress ?
[06:57] <ogra> :)
[06:57] <stratus> ogra, this kind of tweakage in ltsp-build-client that we want to move to a 'profile' thing, the basic profiles should be 'auto discovered' (lsbrelease), the rest are 'localapps' and stuff like that
[06:57] <ogra> i'd like to be able to use an --option to ltsp-build-client
[06:58] <stratus> ogra, no, it seems that otavio tried to teach him without too much success. Well, i think he can handle the 'subdirectory' thing that we should keep in shell script, we've a lot of code and we don't need to trash everything. The best thing we can do is write ltsp-build-client itself again.
[06:58] <ogra> so some of it needs to be hardcoded i guess ... (a bunch of default modes)
[06:58] <ogra> indeed there can be profile files for it
[06:59] <ogra> whats wrong with ltsp-build-client in shell ? 
[06:59] <stratus> we were thinking about profile directories and not files, so you can drop a shell script there and it will run
[06:59] <ogra> i wouldnt rewrite the existing stuff
[06:59] <stratus> that's ugly
[06:59] <ogra> but its shell now and works fine 
[06:59] <highvoltage> ogra: do you think ldap is likely to happen for edgy on edubuntu?
[06:59] <stratus> the idea is move ltsp-build-client to that directories and write a new ltsp-build-client to run that code from scratch, do you see?
[07:00] <ogra> i see no reason to put time into rewriting it
[07:00] <stratus> we will need to write (at least in part) code to run the profiles in their directories
[07:00] <ogra> highvoltage, no idea ... write a spec ;)
[07:00] <highvoltage> ogra: the biggest problem with dislkless fat when i tried it was proper authentication. if ldap works easily in edubuntu then it's much easier
[07:00] <highvoltage> ogra: ok :)
[07:00] <stratus> see, we will move and split ltsp-build-client shell script code into subdirectories
[07:01] <stratus> we need code to identify what needs to be processed and run in each subdirectory, so... ;}
[07:01] <ogra> stratus, i'd really like to rather put my limited time into getting the whole thing feature complete before rewriting half the world
[07:01] <stratus> ogra, we won't really.
[07:02] <stratus> ogra, ltsp-build-client would be for example: "common/ ubuntu/ debian/ ltsp-build-client.py"
[07:02] <stratus> ogra, common/ contains almost all the current code in ltsp-build-client (shell script)
[07:02] <ogra> i understand what you say, but i dont really understand the reason 
[07:02] <ogra> whats wrong with enhancing the current way the script works ?
[07:02] <stratus> share all the code, except for the project subdirectories
[07:03] <ogra> we already cover three distros with the same codebase
[07:03] <stratus> the code is wrong, that's the problem
[07:03] <Riddell> Kinnison, Kamion: in ubiquity does gparted not do any formatting any more?
[07:03] <stratus> almost the same codebase
[07:03] <ogra> i dont see where its wrong
[07:03] <ogra> my codebase is at least identical with peres and vagrants bzr archives
[07:03] <stratus> well, if i want to implement 'localapps' now i won't share that with you instantly
[07:04] <ogra> not if you move away from our common codebase 
[07:04] <ogra> thats right
[07:04] <stratus> i could just drop some shell scripts in debian/ subdirectory or write a new profile 'localapps/'
[07:04] <stratus> that would be saner, imho
[07:04] <ogra> yes, but nobody apart from debian could benefit from it
[07:05] <stratus> no, you would benefit instantly just merging from my bzr repo
[07:05] <ogra> i'd rather see us collaborating on the same code and getting it right for us all instead of splitting up development
[07:05] <stratus> no, we aren't splitting really ogra
[07:05] <stratus> we're organizing it better, imho
[07:05] <ogra> it looks to me like a split 
[07:06] <ogra> everybody will work in his subdir
[07:06] <ogra> over time we'll part 
[07:06] <stratus> no, everybody will work in common <-
[07:06] <ogra> instead of finding a solution to the problem that *just works* for everyone
[07:06] <stratus> the bits that are different (that can't be merged) will go into debian/ or ubuntu/ or sacix/
[07:06] <stratus> there's no solution that *just works* for everyone
[07:07] <ogra> until now that worked
[07:07] <stratus> see, i want epiphany as default browser in 'localapps' and you want firefox, what we're going to do in our current scenario?
[07:07] <ogra> i dont see why it should change
[07:07] <stratus> just an example
[07:07] <ogra> i can set that in the config file pere implemented
[07:08] <stratus> in my view, it would be better not install any browser in 'localapps/' profile and subdirectory and let you install FF in 'ubuntu/', and i do the epy install in 'sacix/'
[07:08] <ogra> we wont have idenical packages
[07:08] <stratus> sure
[07:08] <ogra> so my config can differ from yours
[07:08] <ogra> but we can still use the same code atm
[07:09] <stratus> i see, but what you said isn't much different than keep something like
[07:09] <stratus> 'common/ localapps/ ltsp-build-client'
[07:09] <stratus> right?
[07:09] <ogra> nope
[07:09] <stratus> what's wrong with that?
[07:09] <ogra> why should i have debian/ sacix/ dirs in ubuntu ? 
[07:09] <ogra> there is no need for me
[07:09] <stratus> no, no
[07:10] <stratus> 'common/ localapps/ ltsp-build-client'
[07:10] <stratus> there's no debian/ or sacix/ above
[07:10] <ogra> as there is no need for debian to have an ubuntu subdir
[07:10] <ogra> and i dont see the need for the two other sibdirs either
[07:10] <ogra> i run ltsp-build-client once and never again
[07:11] <ogra> so it can read its config from a conffile i ship in the package+
[07:11] <ogra> and do the stuff we need in the code 
[07:11] <ogra> whats the purpose of the subdirs in that scenario ?
[07:11] <stratus> well, i think ltsp-build-client code is rather ugly and could be splitted in a 'foo/' subdirectory like we do with patches in packages, imho
[07:11] <ogra> lest clean the code then, but not add complexity
[07:12] <stratus> there's no complexity there, it's just using our approach with packages
[07:12] <ogra> but ltsp-build-client is a one time script, not a package
[07:12] <stratus> we don't have just a patch file in debian/ and a simple config file
[07:13] <stratus> you can consider that debian/rules is a 'one time script' too
[07:13] <ogra> no we even have a bunch of different patch systems
[07:13] <ogra> thats what makes packaging and ugly job sometimes
[07:13] <ogra> s/and/an
[07:14] <ogra> yes, but debian/rules and the patches have a totally different target
[07:15] <stratus> ogra, well ok, it would be good if you drop a message in pkg-ltsp-devel  replying to my 'ltsp modularization' thing to let the others know about your opinion, please. I've a meeting in minutes.
[07:15] <ogra> ok
[07:15] <ogra> i'd be sad if we fragmented our development, really
[07:16] <ogra> over time the subdirs will be the placew we do our work
[07:17] <stratus> imo yes, but we can opt for a 'common' subdir and not 'debian/ and ubuntu/' as you pointed out, it was just open room for stuff like 'localapps', but if you think we could implement that without using subdirs to drop small shell scripts, i would like to hear the others.
[07:18] <ogra> yep
[07:18] <stratus> we're too closer to the debcamp to start writing code that won't be used by others.
[07:18] <ogra> we just had an impressing amount of collaboration during this release, i'd not like to loose that
[07:19] <stratus> cool.
[07:20] <stratus> btw, what's your opinion on debian #365578 ?
[07:20] <Ubugtu> Debian bug 365578 in ltsp-client "Subject: ltsp-client: Should usage local swap partitions when found" [Wishlist,Open]  http://bugs.debian.org/365578
[07:20] <ogra> sure, lets do that, i think thats implementable in less than 5 lines of conde
[07:21] <ogra> but it will slow down the boot
[07:21] <ogra> ugh
[07:21] <stratus> it should be configurable then
[07:21] <ogra> especially if you explicitly run mkswap on every boot 
[07:22] <stratus> mkswap will run just if there's a swap partition, did you see?
[07:22] <stratus> there's a sfdisk call to check for swap partitions
[07:22] <alef0> solaris 9 and older had partition type 82, too. that's not a nice patch...
[07:22] <ogra> yes, but if there is one and for what reason ever thats a 1G partition on a slow 2G drive, your boot will last eternal
[07:23] <ogra> alef0, agreed 
[07:23] <stratus> ogra, sure, it's a option candidate IMHO.
[07:23] <ogra> but you can check for the swap keyword or something
[07:23] <ogra> thats easily fixed
[07:23] <highvoltage> ogra: this will of course be disabled by default in ubuntu ltsp, right?
[07:23] <ogra> highvoltage, yes
[07:23] <stratus> ogra, i've 15 telecentres around that contain only real thin-clients so no need to even call sfdisk to probe.
[07:23] <ogra> should be a lts.conf option
[07:24] <stratus> ogra, the sfdisk call greps for the swap keyword, yes.
[07:24] <stratus> ogra, the problem as you pointed out if there's a huge swap partition and the drive is too slow.
[07:24] <ogra> not in the patch in the bug
[07:25] <stratus> ogra, read the "awk '/ 82 /" bit. I asked pere, why not used the word 'swap'. sfdisk outputs both the type no. (82) and the name (swap)
[07:26] <ogra> yep
[07:26] <ogra> so it should match swap and not 82 :)
[07:27] <stratus> ogra, that was my comment in the bug yesterday :P
[07:28] <ogra> ohoel, sorry i only looked at the patch :)
[07:28] <stratus> ogra, np heh
[07:28] <ogra> grmbl
[07:28] <ohoel> mohaha
[07:28] <ogra> oh indeed
[07:32] <mxpxpod> pitti: !
[07:32] <Kinnison> Riddell: No formatting, no
[07:32] <mxpxpod> pitti: I heard you have n-m working with an airport extreme
[07:32] <Kinnison> Riddell: It passes on the desire for the formatting to ubiquity which is then responsible for formatting during the installation phase
[07:33] <Riddell> Kinnison: but it does change the partition tables presumably?
[07:33] <Kinnison> Riddell: aye, mostly because I couldn't get it to spew instructions instead
[07:33] <mxpxpod> shoot
[07:33] <nomed> i've seen the entry #12 on "Ubuntu SoC Projects" .. nobody considered pinot+xapian?
[07:34] <Riddell> Kinnison: and it passes on the instructions with the "- FORMAT /dev/hda5 ext2" strings on stdout?
[07:34] <nomed> who's the person i should contact to suggest it ?
[07:35] <Kinnison> Riddell: aye
[07:36] <Kinnison> Riddell: or at least it did last time I had anything to do with it
[07:36] <Kinnison> Riddell: which was many weeks ago
[07:40] <Riddell> Kinnison: thanks
[07:40] <mxpxpod> pitti: are you there?
[07:40] <mxpxpod> arg
[07:41] <Riddell> mdz: what happened to the anastacia review?
[07:41] <mdz> Riddell: it's looking a lot better: http://people.ubuntu.com/~cjwatson/anastacia.txt
[07:42] <mdz> Keybuk seems to have executed the changes we discussed
[07:42] <Riddell> mdz: could you promote wlassistant and knetworkmanager?
[07:43] <mdz> Riddell: do they have approved reports for main?
[07:43] <Riddell> mdz: they do
[07:43] <mdz> Riddell: what's the difference between knetworkmanager and network-manager-kde?
[07:44] <Riddell> knetworkmanager is the upstream name, network-manager-kde is the package name used by debian which is a meta package current in ubuntu
[07:44] <mdz> Riddell: I'm in a meeting right now; I'll have a look after it's over (probably ~1 hour)
[07:44] <Riddell> sure
[07:44] <highvoltage> OMG, on the South African "the weakest link", they just asked, "Who founded the Ubuntu Foundation, a fund to provide support for the Ubuntu Linux distribuion, in 2005" !!!
[07:45] <Riddell> oh actually pitti, did you look at knetworkmanager?
[07:45] <bddebian> Hmm, I don't think I can touch kmail/kdepim :-(
[07:45] <Riddell> bddebian: why not?
[07:45] <pitti> Riddell: I thought I did
[07:46] <pitti> Riddell: ah, yes, there was some confusion because I saw two different wifi managers
[07:46] <pitti> Riddell: I'd be fine with either, a bit less fine with both, though
[07:46] <mxpxpod> pitti: I heard you got n-m to work with an AE
[07:46] <jjesse> knetworkmanager gets my vote :)
[07:46] <Riddell> pitti: it's not marked as approved on https://wiki.kubuntu.org/MainInclusionReportKNetworkManager
[07:46] <pitti> mxpxpod: temporarily; now it requires wpasupplicant again, so it doesn't any more for me
[07:47] <mxpxpod> pitti: suck
[07:47] <pitti> Riddell: please regard it as approved, I just forgot to do it
[07:47] <Riddell> pitti: wlassistant is replacement for kwifimanager, knetworkmanager isn't installed by default
[07:47] <Riddell> pitti: thanks
[07:47] <bddebian> Riddell: I think it's over my head for bug #39944
[07:47] <Ubugtu> Malone bug 39944 in kdepim "Set filters are ineffective" [Normal,Needs info]  http://launchpad.net/bugs/39944
[07:47] <mxpxpod> pitti: what's the deal with wpasupplicat? why doesn't it work with AE?
[07:48] <pitti> mxpxpod: don't ask me, but it didn't work with my netgear either
[07:48] <pitti> anyway, I have to go, sorry
[07:48] <pitti> Taekwondo time
[07:48] <mxpxpod> pitti: later
[07:53] <bluefoxicy> Hey any ideas on forcing synaptic to list all orphaned packages?
[07:54] <bluefoxicy> I tried moving /usr/bin/deborphan to /usr/bin/deborphan.real and making deborphan a script that does "deborphan $* -a" but synaptic just displays a blank deborphan tag then
[07:54] <mvo> bluefoxicy: my experience with deborphan -a was that it gives you a lot of false positives
[07:54] <mvo> bluefoxicy: but you can always patch the source
[07:55] <bluefoxicy> mvo: it gives me things like ubuntu-desktop
[07:55] <bluefoxicy> I'm aware of how it operates
[07:55] <LaserJock> mvo: does it work better than aptitude, do you know?
[07:55] <mvo> bluefoxicy: if you patch synaptic, please make it a config option (using the _config->Find() system of apt/synaptic) so that people can easily overwrite the options in their configs
[07:56] <mvo> LaserJock: aptitude generally has more knowledge and works better (because it knows about automatic installs and tracks them)
[07:57] <bluefoxicy> oh wow, it's in C?  I thought apt and dpkg and friends were python o.o
[07:57] <mvo> bluefoxicy: c++
[07:57] <bluefoxicy> ah
[07:57] <LaserJock> bluefoxicy: hehe, maybe if sabdfl wrote them ;-)
[07:58] <bluefoxicy> it still seems to be deliberately making sure you don't do anything besides libraries.  :/
[07:59] <Kinnison> some packages seem to depend on 'mailx' which often pulls MTAs in
[07:59] <bluefoxicy> ah
[07:59] <bluefoxicy> but exim left without complaint of other packages
[08:07] <glatzor> mvo: could you give me a bug number with a milestone?
[08:07] <mdke> Kinnison: around?
[08:07] <Kinnison> ish
[08:08] <mdke> Kinnison: ok, if not maybe you can respond later. Are you still taking care of gpm? If so, can you take a look at https://launchpad.net/bugs/39448 ?
[08:08] <Ubugtu> Malone bug 39448 in gnome-power-manager "Screen is not locked when it should be" [Normal,Confirmed]  
[08:09] <Kinnison> mdke: One sec
[08:10] <Kinnison> mdke: it is working as designed. however I can see the response to that
[08:10] <mdke> Kinnison: yes, the bug is about the design.
[08:11] <Kinnison> mdke: g-p-m can be asked to override the screensaver's lock choice
[08:11] <Kinnison> mdke: You need to get mjg59 and/or mdz to agree if you want me to change the default
[08:11] <Kinnison> mdke: to test it, open gconf-editor and go to /apps/gnome-power-manager
[08:11] <Kinnison> mdke: change the lock_use_screensaver_settings to false
[08:11] <mdke> Kinnison: mdz replied on the mailing list at the link on the bug report (but I'm not sure of his view). mjg59 has no view.
[08:12] <Kinnison> yeah, adding UI at this point is a no-go
[08:12] <ogra> mdke, he just doesnt tell you
[08:12] <Kinnison> but I can change the default of the lock_use_screensaver_settings key
[08:13] <Kinnison> mdke: please try that and tell me if it behaves as you want subsequently
[08:13] <mdke> Kinnison: I will, thanks
[08:13] <Kinnison> mdke: comment on the bug if it turns out right
[08:13] <Kinnison> I had over 650 from my illness, no way I can catch that up, ever
[08:14] <Kinnison> so I'll notice if you add new comments :-)
[08:14] <mdke> Kinnison: will do. Btw, I tried to work around it and turned "lock screen" on in my screensaver preferences. now my screen gets locked even when I unplug the AC adapter ;)
[08:14] <mdke> kinda two extremes
[08:14] <Kinnison> mdke: impressive
[08:14] <Kinnison> 2.14.3-0ubuntu1 should stop a lot of the random screenlocking issues from g-p-m
[08:15] <Kinnison> so if you've not upgraded g-p-m in a while, do so
[08:15] <Kinnison> I have to go shopping now, ciau
[08:15] <mdke> i'm up to date. ciao
[08:16] <mdz> mdke: I thought I made my position clear in the bug report
[08:17] <mdke> mdz: ah, I didn't see your comment on the bug
[08:17] <mdke> lemme check
[08:19] <mdke> mdz: you didn't comment. You said this on the mailing list: https://lists.ubuntu.com/archives/ubuntu-devel/2006-April/017321.html but I wasn't sure whether you meant that the default should be changed or not.
[08:28] <pygi> GOSUB: around?
[08:35] <dholbach> Diziet: _jason on #ubuntu-bugs might need your help to debug firefox
[09:01] <Amaranth> pygi: Did you get my updated application?
[09:01] <Amaranth> pygi: Travis Watkins
[09:05] <pygi> Amaranth: what have you applied for ? name of application?
[09:05] <Amaranth> pygi: willow
[09:05] <pygi> Amaranth: ah, indeed...I'll look into it now 
[09:05] <Amaranth> i added some info about projects i've worked on and a link to the launchpad spec
[09:11] <pygi> Amaranth: ah, oki
[09:11] <pygi> got it 
[09:11] <mdke> oh god, it's catching
[09:11] <Amaranth> cool
[09:11] <Amaranth> mdke: ?
[09:11] <pygi> Amaranth: thanks for that 
[09:11] <mdke> the  symbol
[09:11] <Amaranth> mdke: the abuse of katakana for a smiley?
[09:11] <mdke> ah, it's a smiley eh?
[09:12] <mdz> mdke: the default is not very important to me
[09:12] <pygi> mdke: want me to stop ? :P
[09:12] <mdz> mdke: so long as there is a preference
[09:12] <mdz> mdke: if we can't trivially add a preference, the old default should be restored
[09:12] <pygi> Amaranth: if I have any other remarks, I'll make sure you know them :P
[09:12] <Amaranth> pygi: ok, thanks
[09:12] <mdke> mdz: yay. that's my view too.
[09:13] <highvoltage> mdz: we need some help on ubuntu kernels, and you're the best person i can think of to ask, are you terribly busy, would would you mind joining #ubuntu-server?
[09:13] <mdke> mdz: it looks to me like there are gconf keys for it, but I'm not sure they are doing what they say.
[09:13] <mdke> pygi: nah, was just kidding
[09:13] <mdke> mdz: I'm gonna play with them and post on the bug. If we find a way to restore the default, I'll cite you as approving it in the absence of a preference.
[09:28] <Surak> http://www.ubuntu.com/testing
[09:28] <Surak> ops, the http://www.ubuntu.com/testing misses dapper beta 2. Who's the one we should notify about this?
[09:30] <mdke> Surak: #ubuntu-doc
[09:30] <Surak> thanks
[09:31] <ivoks> mdz: ping
[09:32] <ivoks> mdz: what's procedure for sources in queue which now have solved deps?
[09:36] <Kamion> bddebian: "Not Built from Source", i.e. binary that's no longer built
[09:36] <Kamion> Riddell: that's correct; all the formatting is left to partman
[09:36] <Kamion> Riddell: (oh, Kinnison already answered you)
[09:36] <Kinnison> how's the househunt?
[09:37] <Kamion> Kinnison: offer accepted :-)
[09:42] <Kinnison> Kamion: excellent
[09:42] <Kinnison> Kamion: mortgage sorted?
[09:42] <mdke> congrats Kamion 
[09:42] <Kinnison> Kamion: if you manage to move before me, I will have to murder you mercilessly in your sleep
[09:42] <Kamion> Kinnison: got a promise from the bank some time ago for about 1.4 times as much as I now need, so it should be OK, but I'll go and talk to them tomorrow
[09:42] <mdke> Kinnison: unsetting that gconf key works for resuming from sleep, but not the lock screen function button
[09:43] <Kinnison> mdke: the lock-screen function button belongs to the screensaver iirc
[09:43] <mdke> Kinnison: oh.
[09:44] <mdke> Kinnison: so it's not possible you think to have the lock screen button actually lock the screen, but have the screensaver not lock when it kicks in?
[09:50] <mdz> Kamion: I just did an amd64 ubiquity install (2006-05-02) and noticed that lines were still being commented out in sources.list based on failures.  did that fix not make it into that build?  the verification also took a long time for some reason; I wonder if we shouldn't just skip it, if that isn't what you did already
[09:51] <_ion> What's the correct channel to discuss the development of dapper+1?
[09:51] <Kamion> mdz: I'm afraid I don't immediately know what the problem is; can you please file a bug and describe your environment as accurately as possible?
[09:52] <pygi> _ion: well, still this one =P
[09:52] <_ion> pygi: Ok. :-)
[09:52] <Kamion> mdz: I have a change in my local choose-mirror tree already to skip the verification, but haven't tested it yet
[09:52] <Kamion> well, to skip part of the verification anyway
[09:53] <Kamion> mdz: I did test a rather older build and couldn't reproduce the problem, so it must be transient in some odd way
[09:53] <_ion> Will using zsync be considered for the "apt-get update" function in dapper+1?
[09:54] <mdz> _ion: if someone is personally interested in working on it, yes
[09:55] <mdz> Kamion: should I rather wait for your new choose-mirror and test that?
[09:55] <_ion> I might try, if i'm feeling good enough soon enough.
[09:55] <Kamion> mdz: no, that will have no effect on this particular problem
[09:55] <Kamion> on the commenting out, that is
[09:55] <pygi> _ion: still not good? :-/
[09:55] <mdz> hmm, weird
[09:55] <mdz> ok
[09:55] <_ion> pygi: Nope.
[09:56] <pygi> _ion: arghh
[09:56] <mdz> Kamion: choose-mirror or apt-setup?
[09:56] <Kamion> mdz: apt-setup
[09:57] <Kamion> both choose-mirror and apt-setup attempt to talk to the mirror
[09:57] <Kamion> disabling both is feasible but we have to be careful not to break error messages on custom mirror setups as opposed to ones from the masterlist
[09:57] <Kamion> it should still contact and verify custom mirrors
[09:58] <Surak> There are some untranslated strings in isolinux directory. How are those translated? Are they in malone?
[09:58] <kagou> see you later
[09:59] <Kamion> Surak: gfxboot-theme-ubuntu and debian-installer help
[09:59] <Kamion> Surak: and s/malone/rosetta/
[09:59] <Surak> ops!
[09:59] <Kamion> any other untranslated strings are probably untranslatable and too late to change at this point in time
[09:59] <pygi> _ion: have you added that about zsync to SoC page?
[10:00] <Surak> There's only one untranslated in pt_BR, which seems quite odd. I'll take a look. Thanks, Kamion. And oh by the way, thanks for yesterday at #ubuntu-meeting.
[10:00] <_ion> pygi: No, i haven't. A good idea.
[10:00] <bddebian> Kamion: Ah, OK, thx
[10:01] <pygi> _ion: it's added already ;p
[10:01] <_ion> Oh. :-)
[10:01] <pygi> _ion:that's why I am asking
[10:01] <Kamion> Surak: there are a couple of strings in gfxboot-theme-ubuntu that were introduced after the last time I imported translations from Rosetta
[10:01] <_ion> Apparently i'm not the only one who has had that idea. :-)
[10:01] <Kamion> if it's up to date in Rosetta, it probably just needs me to import those, which I will do soonih
[10:01] <Kamion> soonish
[10:01] <pygi> _ion: https://wiki.ubuntu.com/GoogleSoC2006#head-7b2fda01123e6f781ea1ba762a2ba24a1175033d
[10:01] <Kamion> "Start Ubuntu in safe ^graphics mode" might be the one you're seeing
[10:01] <Surak> indeed
[10:04] <_ion> tiff (3.7.4-1ubuntu2) dapper; urgency=low
[10:04] <_ion>   * SECURITY UPDATE: DoS and arbitrary code execution with crafted TIFF files.
[10:04] <_ion> Shouldn't such updates have urgency=high?
[10:05] <Kamion> probably, but it makes little difference in Ubuntu
[10:05] <tseng> he probably forgot
[10:06] <Kamion> to my knowledge there are two things urgency= is used for, apart from humans looking at the changelog: (1) propagation into Debian's testing distribution, (2) sorting of changelog entries presented by apt-listchanges
[10:06] <Kamion> without (1), people often don't worry much about (2)
[10:07] <Surak> Kamion: this and the help.
[10:09] <pygi> _ion: feel free to make a detailed spec tho
[10:09] <seb128> mdke: around?
[10:12] <Kamion> woo, I have ubiquity displaying partman errors now
[10:12] <Kamion> (after a fashion)
[10:13] <Kamion> need to check that I got the KDE frontend changes right though
[10:17] <dholbach> night guys
[10:17] <mvo> good night dholbach
[10:17] <seb128> 'night dholbach
[10:18] <seb128> mdz: do we need an approval to break string,UI freeze or just to warn l10n teams and documentation team?
[10:19] <mdz> seb128: for string freeze we agreed that notification was enough
[10:19] <mdz> seb128: for stuff which affects the doc team, we haven't discussed it yet
[10:19] <mdz> perhaps ask mdke
[10:19] <seb128> mdz: the issue is http://people.ubuntu.com/~seb128/gnome-keyring-password.png
[10:19] <seb128> mdz: the entries on that dialog are "_Password:" and "_Confirm password:"
[10:20] <seb128> mdz: but they have no label atm, which is sort of weird ... that's fixed upstream I was considering taking the patch
[10:20] <seb128> I'll ping mdke (I did some min ago but looks like he's not around atm)
[10:21] <mdz> seb128: and there are no translations for those strings yet?
[10:21] <seb128> mdz: not to gnome-keyring no
[10:21] <mdz> seb128: I think it should be OK with the doc team, they probably don't have screenshots of that dialog, but best to confirm I think
[10:21] <seb128> k, I'll wait on mdke then
[10:25] <opi> who, beside JDub, manages mailman at Canonical?
[10:26] <jdub> opi: i'm about :)
[10:26] <opi> ah :-)
[10:28] <Burgwork> mdz, seb128 afaik, we have no screenshots of  even documentation of that, but upstream gnome might
[10:28] <opi> Burgwork: jdub's at service :-)
[10:28] <mdz> Riddell: I don't see the reports; did someone else already process your request?
[10:28] <opi> Burgwork: ignore that ;-)
[10:29] <seb128> Burgwork: upstream GNOME did that to his stable branch 1 month ago
[10:29] <seb128> that change
[10:29] <seb128> so I think it's fine for upstream
[10:29] <Burgwork> seb128, then I think we are good
[10:29] <seb128> cool
[10:29] <seb128> Burgwork: I'll do the change and mail the documentation and l10n lists then
[10:29] <Surak> duh. X won't start on a machine with some onboard ati x200 if it's set to 16mb. 32mb works. Who's the poor x guy? :-)
[10:30] <Burgwork> seb128, cheers
[10:34] <mdke> seb128: sup?
[10:34] <seb128> mdke: cf discussion we just had
[10:34] <mdke> seb128: oh yeah, what Burgwork said
[10:39] <mdz> Riddell: they're not on the approved list; are you sure they were approved? by whom?
[10:59] <seb128> mdz: atm gdm Depends on "ubuntu-artwork | edubuntu-artwork | xubuntu-default-settings", any objection to move that to Recommends and desktop-seed ubuntu-artwork?
[11:00] <mdz> seb128: does gdm work without ubuntu-artwork now?  I thought we did that because it needed the theme
[11:01] <seb128> mdz: if that's a Recommends seeded it'll be installed by default and people can switch to an another theme and remove the package if they want to
[11:02] <seb128> mdz: it fallbacks on the graphical default upstream theme after displaying a message if the Human theme is not installed
[11:13] <mdz> seb128: if it falls back gracefully, i see no problem
[11:14] <seb128> mdz: ok, I'll do the change now then :)
[11:15] <Surak> Kamion, will bug #38718 be fixed until dapper? it seems a simple one, and confusing to some people.
[11:15] <Ubugtu> Malone bug 38718 in ubiquity "Espresso should select the language first, and then give information" [Normal,Confirmed]  http://launchpad.net/bugs/38718
[11:20] <Mithrandir> seb128: unless you've already done it, please don't until flight-7 is out.
[11:21] <seb128> Mithrandir: when is flight7?
[11:21] <Mithrandir> seb128: tomorrow
[11:21] <seb128> Mithrandir: was ready to dput that after a reboot to make sure it's alright
[11:21] <seb128> hum
[11:21] <seb128> I've some other fixes to that upload
[11:21] <seb128> should I delay everything of the just the artwork change?
[11:22] <Mithrandir> seb128: do you have the debdiff somewhere?
[11:24] <seb128> Mithrandir: no, forget about it, I'll go to bed now and delay the bug fixes I've planned to after flight-7, there is no hurry
[11:24] <Mithrandir> seb128: ok, thanks.
[11:24] <seb128> and better to get some sleep before the 4am meeting anyway ;)
[11:24] <Mithrandir> I'm going to sit up and hack casper, I think.
[11:25] <seb128> good luck with that ;)
[11:25] <Mithrandir> I'm pondering finding a cup of coffee, but not sure if that's a good idea.
[11:26] <seb128> Mithrandir: should http://cvs.gnome.org/viewcvs/gtk%2B/gtk/gtkfilechooserdefault.c?r1=1.282.2.17&r2=1.282.2.18&only_with_tag=gtk-2-8 be delayed to after flight too?
[11:27] <seb128> it makes the fileselector uses standard icons for remote folders not it doesn't block on IO every time you open a fileselector when you have network bookmarks listed
[11:27] <Mithrandir> seb128: I'm ok either way.  Looks safe enough.
[11:27] <seb128> s/not it/so it
[11:27] <seb128> Mithrandir: ok, I'll still push that change then ;)
[11:27] <Mithrandir> ok
[11:30] <mdke> seb128: OMG that's a massive fix, awesome!
[11:30] <seb128> mdke: the GTK one? yeah, that's a nice one ;)
[11:35] <Surak> hum. regression in ubiquity. :-(
[11:41] <mvo> Mithrandir: I have a pending pango upload that fixes a race on a upgrade? do you want it postponed as well?
[11:42] <Mithrandir> mvo: debdiff?
[11:42] <mvo> http://librarian.launchpad.net/2454793/pango1.0_1.12.2-0ubuntu2.debdiff
[11:42] <mvo> ^-- Mithrandir
[11:43] <Mithrandir> mvo: how is this a race earlier?
[11:44] <seb128> Mithrandir: pango module versionning changed, they are moved from 1.4.0 to 1.5.0 but the index is updated by the postinst
[11:44] <mvo> Mithrandir: https://launchpad.net/distros/ubuntu/+source/update-manager/+bug/41297 has the details (the last two-three comments). in a nutshell, its what seb128 said
[11:44] <Mithrandir> oh, indeed.
[11:44] <Ubugtu> Malone bug 41297 in update-manager "dist-upgrade fails when debconf-gnome is invoked during the upgrade" [Major,Unconfirmed]  
[11:44] <seb128> Mithrandir: so between the upgrade and the configure the index point to the wrong place, and gtk stuff don't like that
[11:45] <Mithrandir> mvo: I think it's ok, but let me read through the debdiff once more
[11:47] <Mithrandir> mvo: you'll end up having an md5sum mismatch for /var/lib/pango/pango.modules, won't you?
[11:47] <mvo> Mithrandir: yes, possible (if you have additional modules installed, currently only pango-libthai does this) 
[11:48] <mvo> so I guess we need to exclude it from the dh_mdsums
[11:48] <Mithrandir> mvo: I think that'd be good.  Apart from that, I'm ok with it.
[11:50] <Kamion> Surak: 38718> yes, as I explained in the bug; but not until shortly before release candidate
[11:50] <mvo> Mithrandir: thanks, I'll do a upgrade test before I upload too (just to be sure that nothing breaks and it actually fixes the bug)
[11:51] <Mithrandir> mvo: thanks.
[11:51] <Surak> Kamion: ok - just triaging some correlated bugs for you now. However, bug #40364 is appearing again (with yesterday's amd64 live), so I can't really test ubiquity today.
[11:51] <Ubugtu> Malone bug 40364 in ubiquity "language selection broken" [Major,Needs info]  http://launchpad.net/bugs/40364
[11:52] <Kamion> Surak: please get me /var/log/installer/syslog after running 'UBIQUITY_DEBUG=1 sudo ubiquity'
[11:52] <Kamion> (and reproducing the problem, obviously)
[11:52] <pygi> night all
[11:52] <Surak> Sure