[12:12] <Keybuk> Kamion: sure it is, assuming thursday starts at midnight like normal days <g>
[12:12] <Keybuk> oh
[12:12] <Keybuk> wait
[12:12] <Keybuk> it's still Monday
[12:12] <Keybuk> ok, you win
[12:18] <jdub> Riddell: ping
[12:18] <Riddell> hi jdub 
[12:20] <jdub> Riddell: hey, do you track scribus?
[12:21] <Riddell> jdub: not generally, although I have done, edubuntu shipped that last I looked
[12:21] <Riddell> jdub: what's up?
[12:21] <jdub> Riddell: noticed that there was a micro bump, not sure if it's useful or not
[12:21] <Riddell> I'll add it to my todo :)
[12:22] <jdub> thanks
[01:34] <pygi> night all
[01:56] <angasule_> every user can read every other user's files by default
[01:57] <angasule_> ok, don't you all answer at once, people
[01:58] <LaserJock> I think all linux distros I've ever run did that, depending on the group setup
[01:58] <LaserJock> could be wrong though
[01:58] <jdub> default umask
[01:58] <mjg59> angasule_: And?
[01:58] <angasule_> you don't think that broken?
[01:59] <mjg59> No
[01:59] <angasule_> I don't see the purpose of everybody being able to see everybody else's private files, but I can see why people wouldn't want that
[01:59] <angasule_> chat logs, emails, porn, some things are meant to be private
[02:00] <mjg59> If the files are private, then there's mechanisms to provide that functionality
[02:00] <mjg59> emails are, by default, private
[02:00] <mjg59> As are chat logs
[02:01] <mjg59> If that's not the case, it's certainly a bug
[02:01] <angasule_> mjg59: chat logs are indeed readable by anyone
[02:01] <mjg59> angasule_: Please file a bug
[02:01] <mjg59> We'll ensure that that's recitified
[02:01] <angasule_> I don't think all the directories in the way are readable, though
[02:02] <angasule_> but still, what if aunt tillie writes in oo.org writer her secret recipe?
[02:02] <angasule_> is she supposed to know what umask she must use?
[02:02] <angasule_> wouldn't it make a lot more sense to keep everything private by default?
[02:03] <mjg59> Having everything private by default makes certain aspects of file sharing between users *much* harder
[02:03] <mjg59> Some people do disagree. We've had this discussion on the mailing lists in the past.
[02:03] <angasule_> mjg59: anything that sharing a certain folder wouldn't solve?
[02:04] <mjg59> Yes, because if you have the default to be unreadable files then people tend to expect you not to be able to list them either
[02:05] <angasule_> also, most kdm themes don't have userlist support (except the default kdm theme that looks like windows 3.1), probably the same situation in gdm
[02:05] <angasule_> mjg59: but I mean, have a certain folder for sharing files, instead of sharing everything by default (and without warning!)
[02:07] <angasule_> I'm currently setting up a family install, and the multi user settings aren't the best, for example the dialog to add new users doesn't give any advice on what groups should a new user belong to (would cdrom be useful? how about audio?)
[02:07] <mjg59> angasule_: Yes. How do users navigate to that folder?
[02:08] <angasule_> mjg59: it could be /home/common or whatever is proper, here, we use a different partition (so it's in /media )
[02:09] <angasule_> as I said, what would you do about aunt tillie's secret recipe, or cousin stevie's porn stash?
[02:09] <angasule_> I gave up on teaching my family the laws of thermodynamics, I'm certainly not going to try to explain umask...
[02:10] <Kamion> fix the file browser to make it clear when files are public, and easy to change that
[02:10] <angasule_> at the *very* list, it should be made clear that no file is private, and a ~/private_files directory should be visible everywhere
[02:11] <Kamion> we should not be polluting default home directories with more crap
[02:11] <Kamion> the default home directory should be as empty as possible; there are many good reasons for this
[02:12] <HrdwrBoB> or there should be a shared files area
[02:12] <HrdwrBoB> to make it easier to 'share' files
[02:12] <Kamion> just fix the freaking file browser already
[02:12] <angasule_> HrdwrBoB: which I proposed earlier
[02:12] <Kamion> can't be that hard to improve nautilus to make it clearer
[02:12] <HrdwrBoB> and less likely that people will have to go into other peoples home directorys
[02:13] <angasule_> Kamion: that pretty much requires explaning permissions to aunt tillie
[02:13] <Kamion> no, it really doesn't
[02:13] <HrdwrBoB> angasule_: I have my files mounted under /home/storage because there's no real 'proper' place for them
[02:13] <Kamion> "this file is public and may be read by all users" -> right-click -> "mark file private"
[02:13] <angasule_> Kamion: you want that string next to every file by default?
[02:14] <Kamion> obviously not, but it can be done more subtly, for example with well-chosen icons
[02:14] <mjg59> Kamion: Ubiquity seems a touch unstable at the moment
[02:14] <Kamion> UI improvements are preferable to breaking Unix for the rest of us
[02:14] <angasule_> also, the filename itself should be private in many cases, like porn
[02:14] <mjg59> Or, rather, it got quite confused at partitioning
[02:14] <Kamion> angasule_: same concept, only with directories
[02:15] <Kamion> mjg59: you're a bit short on detail ...
[02:15] <mjg59> A dialog appeared telling me that ntfs resizing was impossible before I'd had an opportunity to touch anything
[02:15] <angasule_> Kamion: but you complained about ~/private_files ;)
[02:15] <HrdwrBoB> angasule_: nothing to stop you creating it
[02:15] <Kamion> angasule_: I complained about creating it on EVERYONE's system
[02:16] <mjg59> "private_files" is difficult
[02:16] <Kamion> for one thing, if you're using directory names to convey meaning, remember that you just excluded non-English-speaking users from grasping that meaning
[02:16] <Kamion> "Desktop" is bad enough
[02:16] <angasule_> well, the current system is insecure for the sake of some supposed ease of use, and you know what OS does that...
[02:17] <angasule_> don't get me started on languages
[02:17] <mjg59> It's not insecure
[02:17] <angasule_> who the frack got the idea of installing a 200MB language pack right after install? and cancelling the download breaks the install? brilliant!
[02:17] <Kamion> angasule_: if you have a problem with the installer, file a bug
[02:18] <mjg59> angasule_: If you have problems, please convey them in a helpful manner
[02:18] <angasule_> it's not really the installer
[02:18] <mjg59> angasule_: We're always happy to look at and fix bugs
[02:18] <angasule_> it's the idea of not including any language
[02:18] <angasule_> save english
[02:18] <desrt> it kicks ass being a native english speaker
[02:18] <Kamion> mjg59: I'm more or less aware of that problem; I think it's been there since dapper thoug
[02:18] <Kamion> angasule_: you're wrong about that; that's not the idea
[02:18] <angasule_> desrt: yeah, well, no native english speakers where I live :P
[02:18] <mjg59> But doing so in hostile tones does not encourage people to do anything, and is against the code of conduct
[02:19] <angasule_> sorry, a bit pissed, I've been messing with the install the whole weekend
[02:19] <Kamion> mjg59: it's in ubiquity's partman-auto integration, anyway - it needs to drive partman forward to the resize question in order to find out how to draw the resize bar, but if resizing fails it gets confused
[02:19] <desrt> mjg59; you'll understand if he's feeling a bit edgy...
[02:19] <angasule_> the multi-user support could use a few more things
[02:20] <angasule_> for example, when modifying a user's details, modifying several users at the same time would be nice
[02:20] <Kamion> I do think we could do with attaching descriptions to groups in some way that the users and groups tool could display
[02:20] <angasule_> so that I can create all the users and then add them all to the cdrom, audio, etc, groups, if I want to
[02:20] <Kamion> we already have that documentation in base-passwd - it would just be a matter of exporting it somehow
[02:21] <angasule_> there is, right now, in kubuntu, no indication of what groups are useful to be added to
[02:21] <angasule_> also, the ability to add things to all desktops (for example, a link to a certain folder)
[02:22] <mjg59> angasule_: There is in ubuntu
[02:22] <angasule_> right now, one must modify /etc/skel
[02:22] <mjg59> Also that
[02:22] <angasule_> mjg59: ah :/ I haven't seen it in kubuntu, sorry
[02:23] <Kamion> angasule_: with regard to your comment about cancelling the download breaking the install, is that in the desktop CD installer?
[02:23] <Kamion> because that's really not supposed to happen, and I'd like a bug report with log files if it does
[02:23] <angasule_> Kamion: I believe so, it didn't happen to me, but to a friend
[02:23] <Kamion> it's meant to be possible to cancel that download harmlessly
[02:24] <Kamion> now, if this is dapper (.0, not 6.06.1), then it might well be a known bug
[02:24] <Kamion> (and fixed)
[02:24] <angasule_> anyway, the mere requirement of an extra 200MB pack at that point IS a bug, in my opinion
[02:24] <Kamion> *shrug* only so much you can fit onto the CD
[02:24] <Kamion> the fact that e.g. OOo help, Firefox translations, etc. are incredibly huge isn't one we can do a lot about
[02:25] <angasule_> well, we are just finishing a linux course here, and we had to provide a second CD with extra packages
[02:25] <Kamion> assuming that https://launchpad.net/distros/ubuntu/+spec/larger-livefs gets done by feature freeze, we'll have a better solution for Edgy in the DVD
[02:25] <angasule_> the language pack was probably the largest one
[02:26] <angasule_> DVDs are still not that common around here
[02:26] <mjg59> Kamion: Also, the current network config stuff after install seems to interact badly with upstart
[02:26] <angasule_> unless you're planning to change it to 'linux for human beings in the first world' ;)
[02:26] <Kamion> then it's simply a "can't squeeze a quart into a pint pot" problem
[02:26] <mjg59> Kamion: But that's probably something I need to speak to Scott about
[02:26] <Kamion> we expect and hope that people in other countries will remaster CDs to provide appropriate language packs by default
[02:26] <mjg59> Kamion: One thing that is worth noting is that not all wireless cards automatically associate with the nearest network
[02:27] <Kamion> mjg59: sorry, what network config stuff?
[02:27] <mjg59> Kamion: So if there's no essid specified in the config, they won't associate
[02:27] <angasule_> here, DVDs are not common, and broadband is rare, regular broadband is 256kbps
[02:27] <mjg59> Kamion: Oh - dhcp on all interfaces. upstart seems to block on trying to configure the network before starting X
[02:27] <jdong> mjg59: yes, including the increasingly popular ipw3945
[02:27] <Kamion> oh, yeah, Scott's problem
[02:27] <angasule_> in fact, kubuntu and ubuntu are only for high end systems by our standards
[02:28] <Kamion> I'd like to be able to get network configuration into Ubiquity in some form, but I only just managed to squeeze in grub configuration for edgy, and I doubt I can do netcfg as well befor FFF
[02:28] <Kamion> before FF
[02:28] <angasule_> well, high and kind of med, this pc has 256MB of RAM and it doesn't work so badly
[02:28] <mjg59> Kamion: Yeah, that's a shame
[02:28] <Kamion> I suppose just an ESSID selector *might* be doable, maybe
[02:28] <mjg59> Hm
[02:28] <LaserJock> angasule_: do people use Xubuntu then?
[02:28] <mjg59> Kamion: Of course, the problem with an ESSID selector is that you then hit problems when the machine is moved elsewhere
[02:28] <angasule_> LaserJock: no, they use windows
[02:28] <jdong> Kamion: or you can just networkmanager and call it a day ;)
[02:28] <Kamion> but in reality, I'd have to get it done tomorrow, and livecd-access and sane-installer-keyboard need to happen before that ...
[02:28] <mjg59> But possibly that's desirable
[02:28] <jdong> Kamion: you know it's tempting :)
[02:29] <Kamion> jdong: no, we really can't :P
[02:29] <jdong> aww
[02:29] <Kamion> it's not tempting, having tried it before
[02:29] <Kamion> once bitten, twice shy, and all that
[02:29] <jdong> what was wrong with n-m the first time?
[02:29] <Kamion> mjg59: I think that's OK - it's a configuration tools problem after that
[02:29] <mjg59> Hm. Didn't we have code that automatically enabled sub-pixel anti-aliasing on LCDs?
[02:29] <angasule_> we used Kubuntu for the course, simply because that's what we know (we're all kde people, with one strong debian user), and the course was for Computer Systems Engineering and Electronics Engineering students, who usually have higher than average computers
[02:30] <Kamion> jdong: it had lots of hardware-specific breakage
[02:30] <jdong> Kamion: ah, I see, never mind then :)
[02:30] <Kamion> mjg59: yes, in casper
[02:30] <mjg59> Kamion: It doesn't seem to work now
[02:30] <Keybuk> Kamion: my problem?
[02:31] <Kamion> the casper and ubiquity hooks for that both look correct at a quick glance, unless somebody broke gnome-panel-data itself
[02:31] <mjg59> At least, I just ended up with "best shapes" rather than "sub-pixel"
[02:31] <Kamion> Keybuk: 01:27 < mjg59> Kamion: Oh - dhcp on all interfaces. upstart seems to block on trying to configure the network before starting X
[02:31] <mjg59> Oh, wah.
[02:31] <mjg59> No DRI by default.
[02:31] <mjg59> Oh, oops
[02:31] <mjg59> The crack switch is in the "crack" position, not the "work" position
[02:31] <LaserJock> angasule_: I do most of my Ubuntu development on a 1.3GHz P4 with 256MB ram so I can understand a bit of that, although it runs Gnome,  KDE, and OO.o  quite well
[02:32] <jdong> mjg59: the crack switch?
[02:32] <jdong> is that the sony nvidia/Intel switch?
[02:32] <mjg59> Yeah
[02:32] <angasule_> LaserJock: well, 256MB is mid-high, 128MB and less is common
[02:32] <zul> LarstiQ, ouch..
[02:32] <mjg59> Keybuk: Also, ctrl+alt+del doesn't seem to be doing anything for me
[02:32] <jdong> mjg59: wow.... I've gotta start calling it that :)
[02:32] <zul> doh..
[02:32] <zul> LaserJock, ouch even
[02:33] <Kamion> mjg59: oh - the problem is that laptop-detect isn't in desktop
[02:33] <LaserJock> zul: uh, yeah. That's what I do most of my pbuilder'ing on
[02:33] <angasule_> I'm currently on a 256MB as well (family PC), mine has 512MB, I can't stand this :)
[02:33] <Keybuk> Kamion: explain?
[02:33] <Kamion> hmm, no, it still ought to be installed at that point
[02:33] <mjg59> Kamion: Ah
[02:33] <Keybuk> mjg59: no, it doesn't do anything for anyone yet :)
[02:33] <Kamion> Keybuk: I can't, it's mjg59's problem, I have no idea what it is
[02:33] <Keybuk> mjg59: --> #upstart (it's noisy in here)
[02:35] <Kamion> right, I'm just going to move laptop-detect into desktop - I'm really bored of trying to guess whether it's installed at various random points in the installation
[02:36] <Kamion> hmm, in practice it's actually in minimal now anyway, so obviously it's not that
[02:40] <Kamion> mjg59: ok, having tracked it down further, fontconfig is supposed to default to "Automatic" subpixel rendering as of breezy, which is meant to turn it on only for LCD screens
[02:40] <Kamion> at least so the fontconfig 2.3.1-2ubuntu1 changelog says
[02:42] <mjg59> Right
[02:42] <mjg59> So fontconfig is probably broken
[02:42] <mjg59> Or gnome
[02:42] <mjg59> Sigh
[02:42] <mjg59> And why did dpkg-reconfigure -pcritical xserver-xorg just decide I wanted vesa?
[02:43] <Keybuk> BE ON EDGY!
[02:45] <mjg59> Ok, so compiz is /much/ faster on this hardware
[02:49] <jdong> mjg59: RenderAccel! Water! Trailfocus!
[02:49] <jdong> lol
[02:49] <jdub> craaaaaaaaaaaaaaaaack
[02:53] <Keybuk> jdub: I thought you liked the crack
[03:19] <Keybuk> jdub: interesting ... your font rendering looks *very* different to mine
[03:21] <jdub> Keybuk: sshot taken on windows
[03:21] <welshbyte> hm, someone's claiming that the ~/Examples symlink is owned by root... that's not right, is it?
[03:21] <welshbyte> (in knot 2)
[03:22] <Keybuk> jdub: hmm
[03:22] <Keybuk> I didn't realise that Linux's font rendering what that different
[03:25] <Kamion> welshbyte: worth finding out whether they mean in a live session or after installation
[03:26] <welshbyte> Kamion: good call. will do
[03:26] <jdub> Keybuk: depends which combinatorial clusterfuckage settings you change
[03:27] <Kamion> welshbyte: if it's in the live session, it's a casper bug; if it's after installation, it's probably an adduser bug
[03:28] <welshbyte> ok
[04:06] <neuralis> hmm, edgy pygtk breakage
[04:13] <crimsun> (slomo uploaded fixed ones)
[04:14] <FliesLikeALap> should we be expecting the edgy-desktop and edgy-alternate knot 2 cds to be working properly on server hardware [yet] ?
[04:15] <FliesLikeALap> I suppose I should try the edgy-server before asking, to see if there are bigger issues at hand
[04:16] <dcode> FliesLikeALap: what are you trying to do, exactly
[04:16] <dcode> edgy is alpha
[04:16] <FliesLikeALap> yes, I'm not talking about production
[04:16] <dcode> it's known broken
[04:16] <FliesLikeALap> production boxes*
[04:16] <dcode> okay
[04:16] <FliesLikeALap> I'm talking about for testing purposes, asking whether it is too early to start testing such things
[04:17] <dcode> for server related systems, it's likely more stable than on the desktop...
[04:17] <dcode> I'm running edgy on a desktop right now....it works but there are obviously bugs
[04:17] <dcode> and things crash from time to time
[04:17] <FliesLikeALap> yeah, I am aware of that from when I tried dist-upgrading to degy and it failed last week or the week beore
[04:17] <FliesLikeALap> beforeP*
[04:18] <dcode> it's really meant more for developers
[04:18] <FliesLikeALap> I tried edgy-alternate on one of my spare servers last night and it failed fantastically on boot
[04:18] <FliesLikeALap> alright, I'll wait until a more appropriate testing time then
[04:18] <dcode> dapper was build as a solid platform to be reliable for such things as server and enterprise.....edgy is just that....it's bleeding edge stuff....
[04:18] <dcode> even when it's released, it may not be as stable as dapper....that's not its goal
[04:18] <FliesLikeALap> ah
[04:18] <dcode> that's why dapper was LTS (long time support)
[04:19] <neuralis> crimsun: still broken on an incorrect version check (2.12.0 considered < than 2.11.1 by _gtk.so)
[04:19] <dcode> FliesLikeALap: really though....for future questions relating to non-development...you should try #ubuntu+1
[04:19] <crimsun> neuralis: afaict the newest pygtk isn't "out there" yet; should be available in a few minutes
[04:20] <FliesLikeALap> yes dcode I'm aware of that but was just asking in here to see whether or not it is appropriate to test this on servers yet/at all
[04:20] <FliesLikeALap> didn't mean to bother you, sorry
[04:20] <dcode> no prob
[04:20] <dcode> just trying to help ;-)
[04:20] <neuralis> crimsun: right, it's the comparison that's strange
[04:20] <dcode> FliesLikeALap: I'm in ubuntu+1 too...and I woulda answered there as well
[04:21] <FliesLikeALap> I only asked here because I raised the topic last night in there and nobody answered
[04:21] <dcode> no worries :D
[04:41] <stub> Launchpad will be going down in 15 mins for its regular code update. Estimated downtime is 10 mins.
[08:05] <dholbach> good morning
[08:06] <jamesh> dholbach: you package things quickly
[08:06] <jamesh> on the weekend too
[08:06] <dholbach> jamesh: what do you mean? :-)
[08:06] <dholbach> jamesh: ahhh gnome-gpg - yeah :-)
[08:06] <jamesh> dholbach: I release a tarball on Saturday and you package it on Sunday
[08:07] <dholbach> jamesh: that's not quick - watch me and seb128 do GNOME 2.16 today ;)
[08:07] <desrt> dholbach; word's getting around
[08:07] <desrt> dholbach; keep this up and you're gonna put sebuild out of business
[08:08] <dholbach> not really... he's WAY quicker
[08:08] <dholbach> especially doing bug triage
[08:08] <dholbach> i swear... one of these days they'll have an extra machine in the data centre just to keep up with him
[08:08] <desrt> sebastien is the reason that inotify-over-ftp was created
[08:08] <dholbach> haha
[08:09] <desrt> his polling was causing undue stress on the servers :)
[08:54] <pitti> Good morning
[08:55] <ajmitch> morning pitti 
[08:58] <Burgundavia> morning ajmitch, pitti
[09:05] <shawn_home> Is there plans for a Ubuntu 'sid' ?
[09:05] <HrdwrBoB> er
[09:05] <infinity> shawn_home: Our current development release *is* our equivalent to "sid".
[09:05] <HrdwrBoB> I think you fundamentally misunderstand the ubuntu development process
[09:05] <infinity> shawn_home: We don't have a "testing", just an "unstable" and several aging "stable" releases.
[09:05] <shawn_home> infinity: those would be nice
[09:06] <shawn_home> there is unstable?
[09:06] <infinity> Err, what would be nice?  I was stating fact, not making a proposal.
[09:06] <infinity> shawn_home: "edgy" is our current development release.
[09:07] <shawn_home> but once edgy is 'done', theres nothing else to inbetween
[09:07] <infinity> I'm not sure what you mean.  Once edgy is released, we open a new development release.
[09:07] <infinity> Within a week, generally.
[09:07] <shawn_home> i ment like Debian's sid, where there is a 'release' thats never released
[09:08] <HrdwrBoB> why bother?
[09:08] <infinity> Right, but since we don't use an unstable->testing method, we don't need that.
[09:08] <HrdwrBoB> you can't wait 6 months?
[09:08] <Mithrandir> shawn_home: our model is different, so no, there's no point in doing what you're suggesting.
[09:08] <infinity> shawn_home: We just rolled the state of dapper at release into edgy, then kept going.
[09:08] <shawn_home> HrdwrBoB: well waiting 6 months is a long time as things change so much
[09:09] <infinity> shawn_home: We could always tag our current development release "unstable" to make that clear, but we intentionally didn't do so, to avoid Debian/Ubuntu moneclature confusion.
[09:09] <infinity> nomenclature, too.
[09:09] <shawn_home> but each time you release i have to change my apt configs and apt-get dist-upgrade 
[09:09] <shawn_home> there is no continuous line of packages fed down 
[09:09] <infinity> Is that a big deal?
[09:09] <infinity> It takes 20 seconds.
[09:10] <shawn_home> it can introduce breakage :)
[09:10] <Burgundavia> so can sid
[09:10] <ajmitch> which is why update-manager can do it for you
[09:10] <shawn_home> but sid is on a individual package based level (aptitude hold foo if foo beaks)
[09:10] <infinity> shawn_home: If you follow our DEVELOPMENT releases (which seems to be what you want), you'd get no more breakage than running sid.
[09:11] <infinity> shawn_home: If you're following stable releases (so, only upgrading when we release), then you get to read release notes, and update-manager will try to do a smooth upgrade.
[09:11] <Burgundavia> ajmitch: although I need to make certain that update-manager get updated to allow -d earlier (mvo waited for about a month to turn that feature on in edgy)
[09:11] <infinity> shawn_home: I don't think you're understanding what I'm saying.  If you want something sid-like, you should have been running dapper up until June 1, then you should have switched to edgy.
[09:12] <infinity> shawn_home: Then you get the same "new packages, as we ship them" thing.
[09:12] <infinity> shawn_home: And the same breakage to go with it. :)
[09:12] <shawn_home> which is fine :)
[09:12] <shawn_home> its the wait between when dapper is 'finished' to when edgy gets started
[09:12] <infinity> shawn_home: Right, so now that we're clear on that, there's no problem.  You want edgy, apparently.
[09:12] <mvo> Burgundavia: *cough* that is correct, it probably should be turned on a lot quicker
[09:12] <infinity> shawn_home: There was only a 1-week delay between the two, really.
[09:12] <shawn_home> oh?
[09:13] <ajmitch> mvo: takes awhile for things to be installable though :)
[09:13] <infinity> shawn_home: Give or take.  We opened edgy pretty quickly.
[09:13] <shawn_home> I was using dapper while it was in alpha
[09:14] <shawn_home> im just used to the 'unstable is never released as a distribution' mentality 
[09:14] <shawn_home> what you have is a running cycle 
[09:14] <Burgundavia> ajmitch: installable != upgradeable
[09:14] <infinity> shawn_home: That's a reasonably new concept in Debian, too.  We used to freeze unstable to do releases in Debian, just as we do in Ubuntu.
[09:15] <Burgundavia> ajmitch: I wonder if sid has increased the time between releases, because people are constantly pushing new crap into sid
[09:15] <infinity> shawn_home: And, while the unstable->testing thing works well for Debian, it doesn't work well with our rapid release model, so we're not doing it.  EOT.
[09:15] <shawn_home> infinity: parallel then?
[09:15] <ajmitch> Burgundavia: yes, it's a problem when many developers don't run testing & only care about sid
[09:16] <infinity> shawn_home: Hire us another 30 people?
[09:16] <Mithrandir> shawn_home: we don't have enough manpower to run stuff in parallell.
[09:16] <infinity> mvo: It's certainly a point of contention, yes.
[09:16] <shawn_home> infinity: hire? :) people will do it if asked
[09:17] <infinity> shawn_home: Not the dirty work that would need to be done to develop two distributions in parallel and keep the fixes in sync between both.  It's not terrible fun.  It's very inefficient.  And we don't freeze long enough to make it worthwhile.
[09:17] <shawn_home> hmm
[09:17] <dholbach> I think it's not problematic at all to keep a ~/upload dir in the time where a release is frozen or we're waiting for a new devel branch to open
[09:18] <shawn_home> 'waiting for new dev branch'
[09:18] <dholbach> I don't see which *real problem* the proposal is trying to fix
[09:18] <shawn_home> thats where I want to park myself onto when edgy is done
[09:18] <mvo> releasing always involves some pain. and it is not fun. if we had two parallel branches that would hurt our quality because less people would actually run (and therefore test) the distro that is about to be released
[09:18] <shawn_home> (let's see what GNU libc broke today! branch)
[09:19] <shawn_home> :)
[09:19] <infinity> shawn_home: Then you just change your sources.list to our newly-opened release after we ship edgy and track that.  I'm really not understanding the problem.
[09:19] <dholbach> sudo sed -i 's/dapper/edgy/g' /etc/apt/sources.list      -    is that the problem?
[09:19] <shawn_home> infinity: but that has to be announced beforehand 
[09:19] <shawn_home> whereas sid was just as-is you get whats dumped in
[09:19] <shawn_home> if it works, good, if not,wait til the next package push
[09:20] <infinity> So, as dholbach states, you only issue is the substitution on sources.list?
[09:20] <infinity> s/you/your/
[09:20] <shawn_home> pretty much 
[09:20] <Mithrandir> shawn_home: what you are describing is something like grumpy, which while it haven't been pushed off the ground yet is going to be "latest version of all the crack we can find".  Like, a global build-from-cvs thing.
[09:20] <infinity> We're not putting "unstable" symlinks in our archive, to avoid confusion with Debian's devel model.
[09:20] <infinity> It was a conscious decision.
[09:21] <shawn_home> then call it something else than unstable?
[09:21] <infinity> Mithrandir: Grumpy may be more bleeding edge than what he really wants (or what anyone really wants)
[09:21] <infinity> Mithrandir: I'd be curious to see if anyone will actually attempt to run a grumpy system, if it's ever even bootable.
[09:21] <shawn_home> grumpy eh
[09:21] <dholbach> I think that much discussion about 52 characters is exaggerated :)
[09:21] <shawn_home> infinity: sure, could try grumpy in a VM :)
[09:22] <shawn_home> without worry whatsoever
[09:22] <Mithrandir> infinity: it'll be bootable once every blue moon every blue moon or something.
[09:22] <infinity> Mithrandir: If that. :)
[09:22] <shawn_home> but where is grumpy?  i
[09:22] <ivoks> waiting to be borne
[09:22] <infinity> shawn_home: It doesn't exist.
[09:22] <infinity> shawn_home: It's an infrastructure dream, not a product (yet)
[09:22] <Mithrandir> shawn_home: https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/GrumpyGroundhog is the description of what grumpy could look like.
[09:23] <Burgundavia> shawn_home: grumpy is a long term plan to create something that is even closer to upstream. Building straight out of upstream sources
[09:23] <shawn_home> Burgundavia: interesting
[09:23] <shawn_home> so is it possible ubuntu can develop a symlink thats different that 'unstable' ? 
[09:23] <Burgundavia> however, I emphasize plan, as it is entirely vapourware currently
[09:24] <shawn_home> that way, people who want more bleeding can just stay with whatever that 'name' is and not concern the actual release 
[09:24] <Burgundavia> you want an symlink for unstable to the latest development? as infinity explained to you, that is a decision that was made, not an accident
[09:24] <ajmitch> if people are brave enough to run unstable software, they can handle changing their sources.list
[09:24] <Burgundavia> indeed
[09:25] <shawn_home> ajmitch: no problem changing the list, the question is knowing what to change it to
[09:25] <ajmitch> the name is announced a month or two out from release, usually
[09:25] <ivoks> intorducing unstable would result with noone using stable, and that would result with bad product or delayed resleases
[09:25] <Burgundavia> if you are not following ubuntu development enough to know the next name, I question why you should be running it
[09:26] <shawn_home> Burgundavia: it'd be the same reason I'd run sid
[09:26] <Burgundavia> ivoks: indeed. Sid has some serious systemic issues. If I were DPL, killing sid would be the first thing I would push for
[09:26] <ivoks> Burgundavia: *nod* it's just to tempting to run sid, and not sarge
[09:26] <ivoks> Burgundavia: i mean, how many of us are running dapper?
[09:27] <shawn_home> it does however make it nicer for people who want to develop on ubuntu to have a running distribution that doesn't release though
[09:28] <shawn_home> this is what Grumpy would do for me
[09:28] <shawn_home> GrumpyGroundhog == what im looking for
[09:28] <shawn_home> whats the likely hood it will come true?
[09:28] <ivoks> shawn_home: developting for "unstable" would be risky since your project could or could not end up in stable
[09:29] <shawn_home> well, true but if my package was in unstable i'd have to give the goahead to move it to a released branch
[09:29] <shawn_home> but I like what Grumpy is
[09:29] <shawn_home> Grumpy == sid
[09:30] <Burgundavia> shawn_home: not really
[09:30] <Burgundavia> sid is closer to the lastest devel, which is currently edgy
[09:30] <Burgundavia> look, ubuntu is never going to have a sid, grumpy is a dream
[09:30] <Burgundavia> end of story
[09:31] <shawn_home> im hoping it comes true :)
[09:31] <ajmitch> grumpy would be far more unstable than debian experimental, most likely
[09:31] <Burgundavia> and developers shoudl be developing on for stable versions of ubuntu
[09:31] <Burgundavia> ajmitch: I think the plan is that nobody would run an entire distro of grumpy
[09:31] <Burgundavia> merely one package or so
[09:31] <shawn_home> Burgundavia: that depends on what someone is developing
[09:32] <shawn_home> I may require say GNU libc 2.5 thats in grumpy since it has new userland C APIs to hook into the kernel 2.6.40 or whatever
[09:32] <Burgundavia> right, anyway, this discussion is going nowhere. neither ajmitch nor myself work for canonical
[09:32] <Burgundavia> infinity and Mithrandir, who do work for canonical have very clearly laid out the why and what
[09:33] <Burgundavia> not to be rude, but I think we are talking around in circles here
[09:34] <Mithrandir> shawn_home: in which case you'd pull in that version of libc.  You wouldn't want the latest snapshot of say, your window manager, X, all of gnome, the kernel, etc.  So it's closer to Debian's experimental than Debian's unstable.
[09:34] <shawn_home> i guess so, yes :)
[09:34] <Burgundavia> ajmitch: X not starting in latest edgy live? have you seen this?
[09:34] <ajmitch> Burgundavia: no, I haven't used a live cd for awhile
[09:34] <ajmitch> don't have the bandwidth to fetch them
[09:35] <shawn_home> It being 3:30am of the clock is sleep time, thanks 
[09:35] <Burgundavia> ubiquity has been borked for a while for me, but I need to retest
[09:35] <ajmitch> Burgundavia: you may be one of the few live cd testers this week, I don't know :)
[09:35] <Burgundavia> well, presumably everybody who downloaded knot2 tested it
[09:36] <Burgundavia> it might be an upstart issue
[09:54] <Hobbsee> hey all
[09:54] <Mithrandir> hi dudette
[09:54] <Hobbsee> hey Mithrandir :)
[09:55] <Mithrandir> seems like my kernel is complaining about the dirt, and I who cleaned here just yesterday:
[09:55] <Mithrandir> [ 3744.215125]  cdrom: hda: dirty DVD+RW media, "finalizing"
[09:56] <Hobbsee> heh
[09:57] <sivang> morning
[09:57] <Hobbsee> hey sivang!
[09:58] <Hobbsee> ROFL @ keybuk's message
[09:58] <Hobbsee> it's the init-crack!
[09:58] <Hobbsee> http://rafb.net/paste/results/R1XemI81.html
[10:00] <infinity> Hobbsee: That's nothing to do with Keybuk, that's apt warning you that removing packages marked Essential is a Very Bad Idea.
[10:00] <Hobbsee> infinity: awww....pity
[10:04] <ajmitch> Hobbsee: the only fun I had was getting a login prompt *really* early
[10:04] <Hobbsee> ajmitch: right
[10:05] <ajmitch> apart from that it was disappointingly stable & didn't cause issues
[10:05] <Hobbsee> bah
[10:05] <Hobbsee> heh
[10:05] <infinity> ajmitch: Really early as in, before 'hostname' ran?  Yeah, that's cute.
[10:06] <ajmitch> now we can say we've got a fast boot time
[10:07] <infinity> "We deliver you a useless system in record time"
[10:07] <infinity> "If you'd like to use it, please wait a minute before typing your password"
[10:14] <dholbach> Kamion: Just a headsup - there's gparted 0.3 - I didn't check the ChangeLog yet, but it might be interesting
[10:16] <Burgundavia> dholbach: Kamion said it might pull it in for the ntfs fixes
[10:16] <dholbach> ah ok
[10:17] <sivang> Hobbsee: is there an equivalen flash-plugin-nonfree for konqueror ?
[10:18] <pitti> hi Hobbsee 
[10:18] <Hobbsee> pitti: :) finally
[10:18] <Hobbsee> heya
[10:18] <sivang> Hobbsee: I have it installed, but knonqi won't recongnize it
[10:18] <pitti> hi sivang 
[10:18] <Hobbsee> sivang: er.  not sure on that, i dont use konq much for web browsing
[10:19] <Hobbsee> sivang: libflash-mozplugin apparently
[10:19] <sivang> Hobbsee: thanks
[10:19] <ajmitch> :)
[10:19] <Hobbsee> according to apt-cache search anywya
[10:19] <sivang> Hobbsee: I'm walking on some KDE grounds (notably Konqueror) after having been fed up with firefox
[10:19] <sivang> ;-)
[10:19] <Hobbsee> sivang: hehe, nice
[10:21] <sivang> Hobbsee: I wonder what kills firefox so hard when I enter www.visitscotland.com, same with moz and opera, but with KHTML , it's a different ball game :-)
[10:22] <Hobbsee> sivang: i'm not sure.  firefox beta?
[10:23] <sivang> Hobbsee: possibly. ALthough I had similar choke up behavoirs on several websites with the dapper's one as well
[10:23] <sivang> Hobbsee: I suspect there's something undetected somewhere in gecko if it's still used there.
[10:24] <Hobbsee> ah
[10:35] <Hobbsee> interesting.  apparently my machine had decided to shut down, after reaching the critical temperature of 3430 (or similar) degrees celcius.
[10:35] <ajmitch> Hobbsee: I told you to replace that fan
[10:35] <Mithrandir> Hobbsee: oooh, do you have a nice black hole in your floor now?
[10:35] <Hobbsee> ajmitch: hehe
[10:35] <Hobbsee> Mithrandir: *checks* - i dont think so.
[10:39] <Mocka> I ate a pooh.
[10:42] <doko> Kamion: please approve openoffice.org-l10n for dapper-proposed
[10:48] <mempf-edgy> hey guys
[10:48] <mempf-edgy> im having a major problem with upstart
[10:49] <giftnudel> mpf-edgy: well, keybuk isn't here, can you file a bug?
[10:50] <mempf-edgy> yeah
[10:50] <mempf-edgy> hold on
[10:50] <mempf-edgy> il do that now
[11:19] <G0SUB> pitti: hello
[11:19] <pitti> hi G0SUB 
[11:19] <G0SUB> pitti: can I pm you?
[11:19] <pitti> sure :)
[11:20] <Hobbsee> G0SUB: pitti eats people who pm him
[11:20] <G0SUB> Hobbsee: yeah I know :)
[11:21] <pitti> Hobbsee: phaph iph noph very niphe oph you!
[11:22] <mempf-edgy> sigh
[11:22] <mempf-edgy> i can no longer boot my pc
[11:22] <Hobbsee> pitti: hehe.  i'm evil like thtat
[11:22] <pitti> mempf-edgy: it's all Scott's fault
[11:22] <Hobbsee> pitti: heh..  yeah.  if in doubt, blame scott.  in fact, blame scott anyway
[11:22] <ajmitch> mempf-edgy: missing upstart-compat-sysv or initscripts?
[11:23] <Kamion> doko: only openoffice.org-amd64 is there
[11:23] <mempf-edgy> possibly
[11:23] <mempf-edgy> il give you the link to my bug report
[11:23] <ajmitch> mempf-edgy: I saw it
[11:24] <ajmitch> however I'm not the one who can help with upstart issues
[11:24] <mempf-edgy> oh ok
[11:24] <doko> Kamion: ahh, ok. that one should go in as well
[11:24] <mempf-edgy> is this a known problem?
[11:29] <giftnudel> mempf-edgy: where is your bug report
[11:29] <mempf-edgy> https://launchpad.net/distros/ubuntu/+source/upstart/+bug/58985
[11:29] <Ubugtu> Malone bug 58985 in upstart "Can't boot using upstart" [Untriaged,Unconfirmed]  
[11:30] <giftnudel> mempf-edgy: how long did you wait`
[11:30] <mempf-edgy> im still waiting
[11:30] <mempf-edgy> lol
[11:30] <mempf-edgy> so an hour?
[11:31] <giftnudel> I mean, the system is still in the state you described in the bug?
[11:31] <mempf-edgy> yes
[11:31] <giftnudel> pressing alt-f1-f8 doesn't do anything?
[11:31] <mempf-edgy> il try
[11:31] <giftnudel> alt+f1 then alt+f2 and so on
[11:32] <mempf-edgy> alt-f1 through f6 takes me to a a login screen
[11:32] <mempf-edgy> however its (none) Login:
[11:32] <mempf-edgy> err
[11:32] <mempf-edgy> not login screen
[11:32] <mempf-edgy> login prompt
[11:33] <giftnudel> mempf-edgy: ok, that's ok so far
[11:34] <giftnudel> how often did you reboot?
[11:36] <mempf-edgy> huh?
[11:37] <giftnudel> was this the first reboot after installing upstart
[11:37] <mempf-edgy> yes
[11:37] <mempf-edgy> ive also tried a clean install of the september 5th daily build
[11:37] <mempf-edgy> same problem
[11:38] <mempf-edgy> the september 5th build would have upsstart in by default
[11:38] <giftnudel> ok
[11:39] <giftnudel> mempf-edgy: please mention the clean install of the september 5th build in the bug report, as it's then easier to reproduce
[11:39] <ajmitch> doko: do we want to get plone 2.5 & update all the other zope products in universe?
[11:39] <mempf-edgy> roger that
[11:39] <HiddenWolf> is there a livecd with upstart in it already?
[11:40] <giftnudel> HiddenWolf: mempf-edgy claims sep. 5th is, don't know if it's live
[11:40] <mempf-edgy> i used the alternate
[11:40] <mempf-edgy> but the desktop cd should also have upstart
[11:40] <giftnudel> HiddenWolf: http://cdimage.ubuntu.com/daily-live/20060905/edgy-desktop-i386.manifest claims it is
[11:42] <giftnudel> mempf-edgy: do you know what has started (initscripts) and what not?
[11:43] <mempf-edgy> no
[11:44] <doko> Kamion: it's now there
[11:44] <mempf-edgy> bug report is updated now
[11:44] <doko> ajmitch: yes, low priority
[11:58] <slomo> infinity: please give-back pygtk on sparc/ia64 :)
[12:04] <Kamion> heno: http://people.ubuntu.com/~cjwatson/gfxboot/modplay-experiment.iso - unfortunately I just get beeps, not useful sounds
[12:04] <Kamion> er, sorry, give that a  until scp finishes
[12:04] <Kamion> a minute
[12:04] <heno> Kamion: cool, i'll teast, thanks!
[12:04] <Kamion> I'll tell you when it's all there
[12:05] <heno> Kamion: will it be possible to get polyphonic tones later? :)
[12:05] <Kamion> er. let's make it work at all first? :)
[12:05] <Kamion> I honestly don't know, I don't understand the assembly well enough
[12:05] <heno> we could probably charge 3 for those actually :)
[12:05] <heno> yep, no problem
[12:06] <Kamion> and while I did find a mod file from upstream that I could play in the same way as I played the ones you sent me, I can't find any code anywhere that actually plays that file from upstream
[12:06] <Kamion> which leads me to question how well-tested the mod-playing code in gfxboot is ...
[12:06] <heno> understood
[12:07] <heno> At the same time we are exploring some key and mouse gestures on the desktop that might make the gfxboot options unnecessary in the future
[12:08] <Kamion> I just randomly assigned mod files to items, before having played them
[12:08] <Kamion> having now played them, 6th.mod seems like the best choice for a startup sound
[12:08] <heno> But that requires some fixing of AT-SPI, so it can load dynamically
[12:08] <heno> ok, I'm sure I can have other ones made as well
[12:10] <Kamion> the one comment I'd have on the files that you sent is that they all seem to be 8 seconds or so long for no reason - all the actual sound is in the first couple of seconds
[12:11] <Kamion> not sure if that's a property of the file format or not
[12:11] <ajmitch> doko: ok, I'll look over what we need & get a list to sync
[12:11] <heno> It might just be the way they are made. I'll look into that
[12:12] <Kamion> heno: http://people.ubuntu.com/~cjwatson/gfxboot/modplay-experiment.iso is actually there now
[12:12] <heno> thx
[12:13] <heno> oooh, a 10MB ISO :)
[12:13] <Kamion> it won't do anything much else useful. I could have removed the kernel image and initrd from it too but I usually like to leave those there
[12:46] <dholbach> can somebody liberate liboobs-1-1 and liboobs-1-1-dbg (of liboobs source package) from NEW? it's needed for new gnome-system-tools.
[12:55] <heno> Kamion: ok, on the first machine I heard nothing (a compact shuttle computer, which probably doesn't have a speaker). I rebooted this one and did hear the little chirps from the menu
[12:56] <heno> It might be more useful to have a sound when gfxboot starts up and one upon pressing F5 (the None entry has no sound)
[12:56] <heno> Another great help would be the possibility to activate the menu items with a unique key, like 1-5, within the menu
[12:58] <infinity> dholbach: It would help if it were actually in NEW...
[12:58] <dholbach> uh?
[12:59] <infinity> dholbach: Did you not upload it..?  Or did soyuz lose it?
[12:59] <infinity> 2006-08-30 21:55:43 EST  Published  edgy   Release  main  devel  0.2.0-0ubuntu2
[12:59] <infinity> The current versoin published (above) produces liboobs-1-0.
[12:59] <dholbach> 0.3.0-0ubuntu1 ... "Successfully uploaded ... to upload.ubuntu.com."
[01:00] <dholbach> I'll re-upload, ok?
[01:00] <infinity> Sure.  Did you get a reject message or anything?
[01:01] <dholbach> If so, I must have deleted it in a state of turned-off-brain
[01:01] <infinity> Ahh, no, you wouldn't have.
[01:01] <Hobbsee> infinity: seems that soyuz is losing things again.
[01:01] <infinity> Yeah, it failed on the upload.  Fun.
[01:02] <infinity> dholbach: Just reupload it.  I'm curious to watch it go through.
[01:02] <dholbach> infinity: done
[01:05] <infinity> dholbach: Made it that time.
[01:05] <dholbach> infinity: Yooohooo! :-)
[01:06] <seb128> dholbach: maybe file-roller didn't get accepted neither?
[01:07] <Kamion> heno: there *is* one on startup
[01:07] <Kamion> heno: I think the fact that you didn't hear it is not a good sign ;-)
[01:07] <dholbach> seb128: looks like
[01:07] <dholbach> nghngh
[01:07] <infinity> seb128: file-roller is indeed in the "failed" queue.
[01:07] <Kamion> heno: you're right that there's none on F5 at the moment
[01:07] <seb128> infinity: is there any else gnomish there too?
[01:08] <infinity> seb128: gconf-editor
[01:08] <seb128> I'll reupload that one then
[01:08] <seb128> thank you
[01:09] <heno> Kamion: I tried restarting twice and listened carefully. Of course those chirps can get drowned out by the birds outside 
[01:09] <Hobbsee> Kamion: if you're not terribly busy, can you check what happened to https://launchpad.net/distros/ubuntu/+source/lyx/+bug/57478 please?  it seems to be added, yet there's no package in the archive, and there seems to be no listed builds for it.
[01:09] <Ubugtu> Malone bug 57478 in lyx "Please sync xdg-utils and lyx-common from Debian" [Untriaged,Confirmed]  
[01:09] <Kamion> heno: I definitely heard a small beep here, but it's not what it's supposed to sound like
[01:09] <Kamion> Hobbsee: xdg-utils is in NEW
[01:09] <Hobbsee> Kamion: ah okay.  must have missed that.
[01:09] <heno> Kamion: ok, I might have missed it both times
[01:09] <ajmitch> Kamion: any word on the f-spot UVF bug?
[01:10] <Kamion>        lyx |    1.4.2-4 | edgy/universe | source, amd64, i386, ia64, powerpc, sparc
[01:10] <Kamion> ajmitch: still no mail?
[01:10] <Kamion> Hobbsee: https://launchpad.net/distros/ubuntu/edgy/+queue
[01:10] <ajmitch> Kamion: no, I filed a bug, subscribed ubuntu-release
[01:10] <Hobbsee> Kamion: thanks.
[01:10] <Kamion> ajmitch: oh, my bug mail goes to a different folder which I'm very behind on; I'll dig it out
[01:10] <ajmitch> bug 58968
[01:10] <Ubugtu> Malone bug 58968 in f-spot "UVF Exception for F-Spot 0.2.0 " [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58968
[01:10] <ajmitch> ok, thanks
[01:10] <Kamion> thanks, I'll get back to you on that
[01:11] <Kamion> heno: so, err, not sure what to do here. Is the unhelpful beep better than nothing?
[01:11] <Kamion> I could include the code but not the .mod files and people could experiment
[01:11] <gnomefreak> what package controls sudo /etc/init.d/gdm?
[01:11] <gnomefreak> - sudo
[01:12] <heno> Kamion: I think the very weak and unrealliable beeps may be worse than nothing
[01:12] <Kamion> heno: yeah. I think I'll just include the code and somebody else can try to figure out WTH is wrong
[01:12] <heno> Kamion: any chance we can add some key navigation to that menu instead?
[01:12] <dholbach> ogra: ROCK ON
[01:12] <Kamion> heno: probably - I'll have a look at that now
[01:12] <welshbyte> gnomefreak: gdm :)
[01:13] <gnomefreak> welshbyte: i am kind of glad you said that :)
[01:13] <gnomefreak> ty
[01:13] <heno> That way we can tell people: wait 20 sec. press F5, the press 3 and Enter
[01:13] <dholbach> infinity: thanks a lot
[01:13] <heno> Kamion: that is at least a clear roadmap for them
[01:13] <heno> as opposed to 'you might hear a sound'
[01:14] <ogra> dholbach, :)
[01:15] <heno> Even if we get it working there will still be computers where it fails
[01:27] <slomo> infinity: please give-back gnome-python and gnome-python-desktop on ia64/sparc
[01:48] <Kamion> heno: so, just to confirm, I can change the menu item names per bug 58836 now?
[01:48] <Ubugtu> Malone bug 58836 in gfxboot-theme-ubuntu "F5 options need to be linked to the right casper options" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58836
[01:49] <heno> Kamion: yes please
[01:51] <Kamion> heno: for reference, the option names need to be the same across all flavours, at the moment
[01:51] <Kamion> the above bug is fine with that, this is just a note in case of future requests
[01:52] <Kamion> heno: "Screen reader" or "Screen Reader" (etc.)? you have "High Contrast"
[01:52] <Kamion> I think I'll probably use title case throughout to be consistent
[01:52] <heno> Kamion: cool
[01:52] <Kamion> "On-Screen Keyboard" replaces "Motor Difficulties - pointing devices"?
[01:53] <heno> Kamion: by 'the option names need to be the same' do you mean that Kubuntu/Xubuntu will have an on-screen keyboard entry
[01:53] <heno> which does nothing? (I'm fine with that)
[01:54] <heno> Kamion: it does, yes
[01:54] <heno> The scanning devices one has been abandoned permanently
[01:54] <CyberSnooP> Hi! Is upgrading to edgy using update-manager supposed to work now?
[01:54] <Kamion> heno: I mean that at the moment I don't have the facility to call it "On-Screen Keyboard" in one and "On-Screen Football" in another
[01:55] <heno> Kamion: ok, np. but you can leave options out?
[01:55] <Kamion> at the moment Kubuntu/Xubuntu will have the redundant menu items, though that's somewhat easier to fix
[01:55] <Kamion> I'll see what I can do there
[01:56] <heno> either way It's not a big deal. We hope to add all those features by Edgy+1 in K/Xubuntu
[01:58] <radone> I got error - bash: /dev/dsp: Permission denied
[01:58] <pitti> radone: you aren't in the 'audio' group probably
[02:00] <radone> groups ..... audio ....
[02:00] <radone> crw-rw---- 1 root audio    14,   3 2006-09-05 15:40 dsp
[02:01] <pitti> radone: what does 'id' show for you?
[02:01] <pitti> radone: (and, btw, this is an #ubuntu question)
[02:02] <radone> groups=.....,25(floppy),29(audio),....
[02:03] <radone> ok, thanks. I am just searching for any app where can I read and write sound stream
[02:03] <radone> this has last reboot worked perfectly
[02:03] <radone> but not now :-/
[02:04] <radone> and after running my app it reports this error
[02:05] <seb128> ogra: thank you for the gnome-screensaver update
[02:06] <infinity> slomo: Those both failed again on a retry.
[02:06] <ogra> seb128, as promised ;)
[02:06] <elmo> how does /dev/loop/1 get created?
[02:06] <slomo> infinity: yeah, was too fast... pygobject was already built to fix the build failure but not available to the buildds yet :(
[02:06] <slomo> infinity: sorry for that
[02:06] <infinity> elmo: losetup?
[02:06] <elmo> or should I just mknod it?
[02:06] <elmo> hmm, losetup
[02:07] <pitti> elmo: or mount -o loop
[02:07] <infinity> elmo: Which should be run by mount transparently.
[02:07] <pitti> however, we currently do not load the loop module automagically
[02:07] <elmo> I love how the manpage refers to /dev/loop0
[02:08] <infinity> pitti: Err, we don't?  I've never had troubles with loop moiunts.
[02:08] <elmo> hmm, ok
[02:08] <pitti> infinity: I always need a modprobe loop...
[02:08] <elmo> so 'mount -o loop' doesn't work
[02:08] <infinity> pitti: Weird.
[02:08] <elmo> this is the second loop mount if that matters
[02:08] <infinity> elmo: Wait, is this a udevish system, or static dev?
[02:09] <infinity> elmo: You might just need "cd /dev && ./MAKEDEV loop" if it's static.
[02:09] <ogra> ogra@edubuntu:~$ ls /dev/loop0
[02:09] <ogra> /dev/loop0
[02:09] <elmo> /home/james/edgy-alternate-amd64.iso on /home/james/mount1 type iso9660 (rw,loop=/dev/loop/0)
[02:09] <elmo> wow that's special
[02:09] <elmo> /home/james/edgy-alternate-amd64.iso on /home/james/mount2 type iso9660 (rw,loop=/dev/loop1)
[02:09] <ogra> that appears after i modprobe loop here
[02:09] <elmo> infit's a normal ubuntusystem
[02:09] <elmo> damn it, inf<tab> should work
[02:10] <infinity> I'm offended by infinito's presence without participation.
[02:10] <ogra> infinity, he's busy in -motu ...
[02:10] <infinity> ogra: I've never seen him speak here, and he breaks tab completion. :P
[02:10] <ogra> right :)
[02:10] <Hobbsee> infinity: change your nick then :P
[02:11] <Hobbsaw> Alright.
[02:11] <Hobbsee> heh
[02:11] <Hobbsee> Hobbsaw: i'm suprised you didnt go for calvin or something.
[02:12] <Hobbsaw> Not a war you want to get into.  I think I have more l33t powers with chanserv than you.
[02:12] <Hobbsaw> Though I'm ont positive.
[02:12] <Chipzz> _ion: what's so great about smart?
[02:12] <Hobbsaw> s/ont/not/
[02:12] <StevenK> Hobbsee: Try and boot Hobbsaw and hit yourself instead?
[02:12] <Hobbsee> infinity: same level of access, it seems.
[02:12] <infinity> Ahh, cool.
[02:12] <_ion> chipzz: It resolves complex dependencies very intelligently, where apt fails.
[02:12] <infinity> Shows how much I look or care.
[02:12] <Hobbsee> infinity: heh.  
[02:13] <_ion> chipzz: Of course, it has its own issues (which is probably why it is not the default in edgy ;-) ).
[02:13] <Chipzz> _ion: then fix apt?
[02:13] <infinity> _ion: Whic his why we always tell people to use frontends like dselect, aptitude, synaptic, etc.
[02:13] <infinity> _ion: apt's never been good at complex upgrade scenarios, and never will be.
[02:14] <Chipzz> _ion: I cannot believe you're about to throw out apt for exactly one *extremely* silly reason
[02:14] <Chipzz> that's just stupid
[02:15] <infinito> infinity:sorry, i've got this channel in autojoin... im gonna remove it
[02:15] <infinity> infinito: I was joking. :)
[02:15] <infinity> infinito: Though if you really have no reason to be here, fixing my tab completion will make elmo happy. ;)
[02:15] <pitti> infinity: what about 2^infinity-1? :)
[02:15] <pitti> infinity: that would give us tab completion with just one letter
[02:16] <neuralis> Chipzz: relax, read https://wiki.ubuntu.com/SmartPackageManager etc
[02:16] <infinito> bye and sorry ;)
[02:16] <infinity> pitti: That's still infinity, logically, even if it isn't to crazy mathemeticians and pyshicists. :P
[02:16] <infinity> physicists, too.
[02:16] <pitti> infinity: but it's the most important number in infinite improbability drive science...
[02:16] <Hobbsee> "once you're so far to the right, nothing can save you" yes...
[02:17] <Hobbsee> infinity: a far better nickname would be fortytwo.
[02:17] <neuralis> infinity: pyshicists. like shicists, but written in python. also, we should talk later today. how are things looking?
[02:17] <Chipzz> neuralis: yes, I just read that
[02:17] <Riddell> Kamion: Kubuntu should still have "Motor Difficulties - pointing devices"
[02:17] <infinity> neuralis: When is "today" for you?  It's pretty much over for me.
[02:17] <Chipzz> and it doesn't give me much good reasons to switch to smart
[02:18] <neuralis> infinity: ah, right. what utc offset are you again?
[02:18] <infinity> neuralis: If we could make a date for sometime in my tomorrow, that'd be grand.  Say, in about 12 hours? :)
[02:18] <Hobbsee> hehe
[02:18] <infinity> neuralis: I'm utc+10
[02:18] <Hobbsee> infinity: oh are we?  i thought we were in +11....
[02:18] <Chipzz> if apt doesn't handle complex upgrade scenario's, then that's a bug that should be fixed, not a reason to throw away the child with the bathwaiter
[02:18] <Chipzz> bathwater
[02:18] <infinity> Hobbsee: date --rfc-822
[02:18] <neuralis> Chipzz: a lot of smart people working on package management disagree with you
[02:19] <Hobbsee> infinity: point.
[02:19] <Chipzz> neuralis: more importantly, I think switching to apt may create a giant rift with debian, and make the situation wrt debian even sourer
[02:19] <Chipzz> to smart
[02:20] <infinity> Bouncing between smart and apt should be nearly transparent.
[02:20] <infinity> At least, that's one of the upgrade goals.
[02:20] <infinity> They should co-exist peacefully.
[02:20] <neuralis> infinity: lateish your tomorrow is better here. how's 16ish or so hours from now?
[02:20] <infinity> Afterall, apt's just an acquisition method, not a package manager.
[02:20] <Chipzz> infinity: as I understand it, apt is to be deprecated in the end?
[02:20] <infinity> neuralis: Sounds good to me.
[02:21] <neuralis> infinity: deal
[02:21] <infinity> Chipzz: Eventually, yes.
[02:21] <infinity> Chipzz: I've been fighting against it being replaced until smart can give us a smooth upgrade (and retreat) path.
[02:22] <infinity> Chipzz: Which, for most things, isn't a big deal, since it's the dpkg database that matters.  But for some things (like the auto-dependency removal DB), you need ot be able to sync.
[02:22] <Chipzz> sometimes I wonder what it is with opensource people throwing away stuff instead of fixing it
[02:23] <giftnudel> Chipzz: it's sometimes easier to write sth. from scratch then to try to fix something
[02:23] <infinity> Chipzz: You've not seen the apt codebase.
[02:23] <Chipzz> infinity: wasn't the auto-dependency removal introduced into apt recently?
[02:23] <infinity> Chipzz: Yeah, it was a recent addition.  Yanked from aptitude and massaged into apt.  I assume mvo intends to make it play nicely with smart too.
[02:24] <infinity> Chipzz: At any rate, it takes a special kind of insanity to wrap one's head around apt's code.  I suspect it's been responsible for driving both mdz and mvo completely mad, and perhaps even jgg, who originally wrote it.
[02:24] <infinity> Chipzz: There are very valid reasons for rethinking it from the ground up.
[02:25] <infinity> mvo: Well, this is possible. :)
[02:25] <_ion> :-)
[02:26] <Hobbsee> mvo: or seriously on crack, take your pick :P
[02:26] <Chipzz> possibly :)
[02:26] <Chipzz> but fwiw, imho dpkg needs improvement a lot harder than apt does
[02:26] <infinity> mvo: So, since you appear to be following this, are you planning to make the auto-dep-removal magic seamlessly work between apt and smart, for easy swapping of tools without functionality loss?
[02:27] <infinity> mvo: Cause that would be some kinda spiffy.
[02:27] <mvo> infinity: hopefully, but smart does not have the magic yet (also there is a experimental patch)
[02:28] <pitti> mvo: does aptitude and apt use the same auto-removal db now?
[02:28] <pitti> s/does/do/
[02:28] <infinity> mvo: But once it grows the magic, you can make it sync with apt (or just use the same DB, ideally), so there's no data loss in switching?
[02:28] <mvo> pitti: not yet :( also aptitude will update the apt database
[02:28] <Kamion> Riddell: erm, ok; can you agree this with heno, because he seemed to think differently in bug 58836?
[02:28] <Ubugtu> Malone bug 58836 in gfxboot-theme-ubuntu "F5 options need to be linked to the right casper options" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58836
[02:28] <mvo> infinity: yes, that is the plan. smart will be able to import it
[02:29] <infinity> mvo: s/import/sync/, hopefully, so bouncing back to apt is also possible?
[02:30] <Kamion> Chipzz: generally, my view is that dpkg needs enhancements, while apt needs fixes
[02:30] <infinity> mvo: I'd feel much more comfortable about tossing smart in as the default package acquisition tool if we can easily use both for a while, and switch back if we have to.
[02:30] <mvo> infinity: well, not sure if it will do that automatically, but it will be possilbe too with a command 
[02:35] <Riddell> heno: what do you mean by "mouse keys"?
[02:36] <heno> Riddell: you can use the numeric keypad to move the mouse cursor around
[02:36] <heno> I'm sure KDE has it
[02:36] <Chipzz> is there a comprehensive list of issues with apt somewhere actually?
[02:37] <Kamion> heno: it's an X feature
[02:37] <Kamion> shift-numlock
[02:37] <heno> We had that switched on in the same profile as sticky keys in Dapper
[02:37] <heno> Kamion: Right, AccessX
[02:38] <heno> Both KDE and Gnome have config guis for it, but many other DEs don't
[02:38] <Riddell> heno: we also have kmousetool which clicks the mouse when you hover over something, does that have an equivalent in one of the ubuntu profiles
[02:38] <heno> Riddell: yes, I'd like to make that a global X feature too
[02:39] <heno> Along with mouse-shaking steadying
[02:39] <heno> I spoke with rodarvus about it at the sprint
[02:39] <heno> Edgy+1 material I think
[02:39] <Kamion> heno: ok, I've added an isolinux.cfg option to control the set of access options presented
[02:40] <heno> Kamion: cool, thanks. I can find it in the gfxboot sources if I want to have a look?
[02:41] <Kamion> heno: no, in gfxboot-theme-ubuntu
[02:41] <heno> ok, cool
[02:41] <Kamion> very little is done in gfxboot directly
[02:41] <Kamion> http://people.ubuntu.com/~cjwatson/bzr/gfxboot-themes/Ubuntu/
[02:41] <Kamion> heno: what accessibility options should be presented in Edubuntu?
[02:41] <pitti> okay, so the official requestsync script on people.u.c/~pitti/scripts does not require a local MTA any more
[02:42] <pitti> Hobbsee: ^ thanks for that
[02:42] <Riddell> heno: I think Kubuntu should have 'Keyboard modifiers' with sticky keys, and Keyboard and Mouse Modifiers with sticky keys and keyboard mouse and kmousetool
[02:42] <Hobbsee> pitti: :)
[02:42] <heno> Kamion: As far I remember the tools were left out for space reasons (orga?)
[02:43] <heno> Kamion: so that just leaves themes (possibly) and key modifiers
[02:43] <heno> Riddell: Sounds good.
[02:46] <Riddell> Kamion: 58836 updated
[02:47] <Kamion> Riddell: thanks
[02:47] <Kamion> Riddell: sorry, I can't have different option names at present
[02:47] <Kamion> the set listed there for Ubuntu is the set that it's currently possible to have
[02:48] <doko> seb128: can you erase RW CD's using nautilus?
[02:50] <Riddell> Kamion: hmm, guess we'll just have the 0,1,2 and 3 then and turn on mouse stuff for three
[02:51] <Kamion> Riddell: yeah, I may be able to change this in future but I'm already running rather over time today for gfxboot-theme-ubuntu hacking
[02:54] <slomo> infinity: we could try again gnome-python* now on ia64/sparc if you want ;) the pygobject binaries should finally be available there
[02:56] <Kamion> Riddell: btw, I added an option to ubiquity to configure where grub is installed, which will need some KDE work
[02:56] <Kamion> I left TODOs in the appropriate places
[02:56] <Riddell> Kamion: ok, will try and get to that this week
[02:56] <infinity> slomo: Are you sure? :)
[02:56] <Kamion> Riddell: thanks
[02:57] <slomo> infinity: if not the publisher must've eaten it ;) at least the sparc binary is on archive
[03:07] <infinity> slomo: Let me guess, gnome-python-desktop depends on gnome-python, so I need to wait a publisher cycle to do it? :)
[03:07] <infinity> slomo: Looks like.
[03:08] <slomo> infinity: yes... *sigh* only a problem because the x86 buildd already built the arch all packages it seems...
[03:09] <infinity> slomo: No big deal.
[03:09] <jdong> infinity: why are some of my successfully built backports not showing up on archive?
[03:09] <jdong> infinity: namely xchat and kopete
[03:12] <infinity> jdong: kopete is in the NEW queue.  Not sure about xchat.
[03:12] <jdong> :)
[03:13] <Kamion> jdong: you saw my note about the other effect of the soyuz backports bug, didn't you?
[03:13] <Kamion> namely that you only get binaries for one architecture for any given backport
[03:13] <jdong> Kamion: aah, really?
[03:13] <jdong> yikes
[03:13] <jdong> :)
[03:13] <Kamion> Highlander syndrome
[03:13] <jdong> Kamion: i thought it said I can't do multi-binary-package backports yet
[03:13] <jdong> lol
[03:14] <Kamion> multi-binary should work no worse than single-binary
[03:14] <infinity> Kamion: Err, what?
[03:14] <Kamion> sorry, by binary I meant binary upload, not binary package
[03:14] <infinity> Kamion: We're not publishing all 6 arches correctly?
[03:14] <Kamion> infinity: nope
[03:14] <infinity> Kamion: AWESOME.
[03:14] <Kamion> good, isn't it
[03:14] <infinity> Kamion: So, there's no point in my processing NEW for -backport, I take it?
[03:15] <Kamion> the second and subsequent binary uploads get ">= version already in backports"
[03:15] <Kamion> infinity: not really, no - most of them will bounce
[03:15] <Kamion> well, you could process one of them. :-)
[03:15] <infinity> Kamion: Wait, this bug must be new, though.
[03:15] <Kamion> infinity: it's bug 58144
[03:15] <Ubugtu> Malone bug 58144 in soyuz "Backport is rejected if an older backport is already there" [Critical,In progress]  http://launchpad.net/bugs/58144
[03:15] <Kamion> it's been there for ages - but it ONLY affects backports
[03:15] <infinity> Kamion: Cause when you did the first wave of backports, I was NEWing libraries to get their dependants to build, and that was going fine.
[03:15] <Kamion> infinity: oh, hmm, dunno then
[03:16] <jdong> mjg59: powernowd.... can we make it poll a bit faster, or would that break some CPU's
[03:16] <mjg59> jdong: Should now be ondemand for anything vaguely recent, which avoids the polling necessity
[03:16] <jdong> mjg59: oh really? cool
[03:16] <infinity> Kamion: Maybe that worked purely by chance, since new->accepted of all 6 arches at once is kinda special.
[03:17] <mjg59> Hm.
[03:17] <seb128> doko: yes, doesn't work for you? does it work with cdrecord?
[03:17] <mjg59> There must be /some/ way of getting an interrupt when a Thinkpad hotkey is pressed
[03:17] <doko> seb128: didn't try, never mind, just found some older CD/RW's
[03:19] <infinity> Kamion: Anyhow, I'm going to leave the dapper queue alone until that bug is fixed.  Thanks for the heads-up.
[03:20] <Kamion> Mithrandir: what's the current state of sane-installer-keyboard? I'm about to dive into it ...
[03:20] <Mithrandir> Kamion: needs d-i upload and more testing.
[03:22] <jdong> wow, the eclipse CDT really redefines the meaning of slow and then some, doesn't it?
[03:24] <Kamion> Mithrandir: and the ubiquity code; I don't think we should go ahead with it unless both d-i and ubiquity are doing the same thing
[03:24] <Kamion> we have a day and a half here, so ...
[03:25] <Mithrandir> Kamion: well, I can give it all of tomorrow since my live-cd-write-as-you-go isn't feasible after all.
[03:25] <Kamion> Mithrandir: I've got nothing else to do until FF except rescue other specs, and I have most relevant experience for this one. :-)
[03:26] <Kamion> Mithrandir: so we can tag-team
[03:26] <Mithrandir> Kamion: sounds good to me.
[03:26] <Kamion> infinity: what's happening with live-cd-stacked-filesystems and larger-livefs?
[03:26] <Kamion> I'd really like to have larger-livefs landed by FF ...
[03:27] <infinity> Kamion: Finishing up the former tomorrow when I wake up.  When it's done, the latter is just a question of adding a new seed.
[03:32] <Kamion> infinity: hmm, it's going to be pretty tight to get the necessary support into cdimage and ubiquity before FF
[03:32] <Kamion> we'll see what we can do, I suppose ...
[03:33] <infinity> Kamion: Which one would you prefer I try to hack on?  If I finish my side before you wake up, I can tackle another chunk.
[03:35] <Kamion> infinity: if you can tell me in advance how the filesystems are going to be exported from the buildds, I can do the cdimage/ubiquity stuff in advance
[03:35] <Kamion> if the former is achieveable, I'd prefer that it happened first, since then as you say the latter is reasonably trivial
[03:35] <infinity> Kamion: 01_$mumble.squashfs through NN_$mumble.squashfs
[03:36] <Kamion> what's $mumble?
[03:36] <Kamion> 01_base, 02_desktop, that sort of thing?
[03:36] <infinity> Yeah.
[03:36] <Kamion> o
[03:36] <Kamion> ok
[03:39] <Kamion> iwj: how's the Breaks stuff coming along? just wondering if we're going to need to back it out or forbid packages from using it in edgy
[03:40] <Kamion> seb128: were those patches Henrik sent for sudo-admin-atspi acceptable?
[03:45] <pitti> hi lloydinho 
[03:45] <Tonio_> Kamion: ping ?
[03:45] <Kamion> Tonio_: i
[03:45] <Kamion> hi
[03:45] <Tonio_> Kamion: hey :) While mdz isn't there, can you revu UVF Exception request for katapult please ? bug 58213
[03:45] <Ubugtu> Malone bug 58213 in katapult "0.3.1.2svn20060711 > 0.3.1.3 UVF Exception Request" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58213
[03:46] <Tonio_> it closes 2 major bugs making it simply unusable
[03:47] <pitti> lloydinho: got my mail and SMS?
[03:47] <Kamion> Tonio_: I've added it to my list :-/
[03:48] <Tonio_> Kamion: okay I'll wait then, thanks !
[03:48] <seb128> Kamion: I've looked at the bugs and patches but didn't have time to play with those yet. upstream has some valid concerns about them and delayed that for next cycle so I'm not sure yet, I'll try when GNOME 2.16.0 is packaged (which should be done today or tomorrow morning)
[03:49] <seb128> Kamion: edgy has not so many sudo running app, g-s-t, update-manager, gnome-app-install UI run as user now 
[03:49] <Kamion> seb128: ubiquity is a big one, and it can't change
[03:49] <seb128> ah, right, good point
[03:50] <Kamion> at least not without some major reengineering
[03:50] <seb128> k, it's next on my list after GNOME 2.16.0 (and some mails replying), I'll let you know when I've tried them
[03:50] <Kamion> thanks
[03:50] <iwj> Kamion: Hi.  I have a mail from mvo about update-manager which is vaguely relevant.  Aside from that, I'm working on testing my apt changes.
[03:50] <seb128> np
[03:51] <Kamion> iwj: righto, thanks. Let me know if rescue efforts are needed
[03:51] <iwj> Willdo.
[03:51] <iwj> Is mvo about ?  He doesn't seem to have replied to my email ...
[03:52] <Kamion> mvo_: ping
[03:53] <infinity> Err, how does one reboot (short of hitting the power switch) after upgrading to upstart?
[03:53] <infinity> shutdown/telinit can't connect to init.
[03:54] <slomo> infinity: reboot -f
[03:54] <jdong> infinity: sync; reboot -f
[03:54] <mvo_> Kamion: pong
[03:54] <bddebian> Howdy folks
[03:54] <jdong> or sysrq-u, sysrq-s, sysrq-b
[03:54] <Amaranth> slomo, jdong: Of course, that's basically the same as hitting the power button
[03:54] <Kamion> mvo_: ^-- iwj
[03:54] <jdong> infinity: the sysrq method is a bit safer
[03:54] <jdong> at least it does a remount-ro
[03:54] <tepsipakki> iwj: hi, does #47701 have a chance for edgy?
[03:54] <Kamion> infinity: Keybuk said he's planning to fix that by special-casing shutdown to be able to talk to sysvinit
[03:55] <tepsipakki> bug 47701
[03:55] <Ubugtu> Malone bug 47701 in firefox "enable middlemouse.contentLoadURL" [Medium,Unconfirmed]  http://launchpad.net/bugs/47701
[03:55] <iwj> mvo_: Ah, hello.
[03:55] <iwj> tepsipakki: This has been discussed in ubuntu-devel.  I don't like the current behaviour either but consensus seems to be against us.
[03:55] <jdong> hey, does acpi-support's suspend scripts umount anything?
[03:55] <mvo_> hello iwj, Kamion. sorry, I missed the context. whats up?
[03:56] <iwj> mvo_: Breaks might or might not be.
[03:56] <iwj> Did you see my mail about update-manager ?
[03:56] <Kamion> tepsipakki: while personally I'm with you and iwj, the reason given originally was that if you're trying to middle-click on a URL to open it in a new window/tab and you miss, whatever random stuff happens to be in your X selection gets loaded by firefox
[03:57] <tepsipakki> kamion: yes, I've seen that ;)
[03:58] <mvo_> iwj: yes, I have seen it. your LD_LIBRARY_PATH idea is a bit scary, but I guess it would work
[03:59] <iwj> mvo_: Well, it just seemed an easy way to make it work and it's what LD_LIBRARY_PATH is for, in some sense.
[03:59] <iwj> The alternative would be some weirdo rebuild but I didn't really want to suggest that.
[03:59] <mvo_> iwj: if we really really want to have breaks working for the dapper->edgy upgrade, then this is the way to do it
[04:00] <mvo_> iwj: the alternative would be to use them onyl for edgy->edgy+1
[04:00] <lloydinho> pitti, sorry I was in the middle of an interview.. :-)
[04:00] <tepsipakki> iwj, Kamion: maybe I can paste your responses to the bug, and rename it so it could be left as a placeholder?
[04:01] <infinity> Kamion: Would have been nicer if he did that before he forced the upgrade on me. :)
[04:01] <lloydinho> pitti, so I won't be in Dresden before tomorrow, I hope that's okay. Sorry for the late reply..
[04:01] <infinity> dholbach: My sticky notes are back.  I love you! ;)
[04:01] <Kamion> tepsipakki: sure
[04:02] <iwj> mvo_: Right.  So really I think it has to be your decision since you have to decide whether you want to do that somewhat mad thing in u-m.
[04:02] <slomo> infinity: hrm, same problem for pygtk now at least on amd64 :(
[04:02] <iwj> tepsipakki: Of course, thanks.
[04:02] <Kamion> It doesn't seem too bad at this point to say that we'll only allow Breaks in packages as of edgy+1. The downside of course is that we need to make sure somehow that we've caught all the problems or we won't get it until edgy+2, etc.
[04:02] <iwj> Yes, quite so.
[04:03] <iwj> doorbell
[04:03] <mvo_> iwj: I will have a long look at the source code in the dist-upgrader today and try to think about how it could be integrated without being too messy. does that sound ok?
[04:06] <iwj> back
[04:06] <iwj> (That was the veg box arriving.)
[04:06] <iwj> mvo_: Thanks, that would be very helpful.
[04:07] <iwj> I'm worried by Kamion's point about testing, if we punt on it.
[04:07] <iwj> Also, in general you want to do the upgrade with the latest apt or what have you anyway, so this mad scheme isn't wasted effort :-).
[04:11] <math_b> Concerning upstart, I saw no dependency on the initscripts package, is it a bug ? 
[04:11] <Kamion> math_b: I added that in upstart-compat-sysv this morning
[04:11] <math_b> thanks !
[04:15] <dholbach> infinity: I love you too, honey!
[04:22] <Mithrandir> Kamion: actually, won't we have to not use Breaks until we've released another LTS?
[04:23] <Kamion> Mithrandir: not if the upgrade tool can cope
[04:34] <Tonio_> Kamion: thanks for uvf reviewing
[04:37] <Kamion> pitti: FYI, I'm syncing unicode-data straight into main - it's just data, and it's just split out from console-data
[04:37] <Kamion> (it'll be a new build-dependency of console-data)
[04:39] <_ion> Where (or by whom) is the process of migrating stuff from rcS to upstart jobs coordinated?
[04:46] <pitti> Kamion: sure, sounds good
[04:47] <pitti> lloydinho: alright, I got your sms
[04:47] <pitti> lloydinho: see you tomorrow!
[04:47] <lloydinho> pitti: Cool! See you!
[04:47] <Kamion> _ion: Keybuk's on holiday today - better ask tomorrow
[04:48] <_ion> kamion: Ok, thanks.
[04:49] <pygi> hey pitti 
[04:49] <pitti> hi pygi 
[04:49] <pygi> pitti, have I told you about my little DVD experiments? :)
[04:50] <pitti> pygi: no, what's about it?
[04:51] <pygi> pitti, I tricked libburn to produce a usable dvd :)
[04:51] <pitti> cool
[04:51] <pitti> pygi: by wrapping growisofs, or entirely separate code?
[04:51] <pygi> pitti, by following steps:
[04:51] <pygi> 1)blank disc by growisofs
[04:51] <pygi> 2)burn disc using libburn code
[04:52] <_ion> 4)PROFIT
[04:52] <pygi> _ion, ?!
[04:52] <pygi> sivang, poke?
[04:52] <sivang> pygi: poyke
[04:52] <_ion> pygi: Just a joke. One needs to be familiar with the slashdot meme to get it. :-)
[04:52] <pygi> sivang, can we have packages in universe this weeks pls? :)
[04:52] <pygi> _ion, why 4)? isn't it 3? :P
[04:53] <_ion> pygi: 3) is "???"
[04:53] <pygi> _ion, ah, nothing :P
[04:53] <sivang> pygi: do you have anything done already?
[04:54] <sivang> pygi: I mean, some sort of skeleton package?
[04:54] <pygi> sivang, ehm, well, the code?:)
[04:54] <pygi> no :P
[04:54] <_ion> pygi: It originates from http://en.wikipedia.org/wiki/Underpants_Gnomes#The_gnomes
[04:54] <sivang> pygi: heh
[04:54] <pygi> sivang, what? :)
[04:54] <sivang> pygi: okay, toss me a link to a tarball
[04:54] <pygi> sivang, no tarballs :P
[04:54] <pygi> svn co http://libburn-svn.pykix.org libburn
[04:54] <pygi> that should work :)
[04:55] <sivang> pygi: but then we get the .svn crap in the package :-)
[04:55] <pygi> sivang, remove it :P
[04:55] <_ion> sivang: svn export ../foo-1.2.3; cd ../foo-1.2.3; dpkg-buildpackage ...
[04:55] <sivang> pygi: you should try and alos release "upstream" tarballs :-)
[04:56] <Mithrandir> debuild -i ftw
[04:56] <sivang> _ion: right
[04:56] <pygi> sivang, one day :P
[04:56] <_ion> mithrandir: Yeah, debuild rocks. :-)
[04:57] <sivang> Mithrandir: what's ftw ?
[04:57] <Mithrandir> for the win.
[04:57] <Mithrandir> sivang: -i makes debuild strip out .svn directories and similar.
[04:57] <sivang> Mithrandir: right, I just didn't get the ftw :-))
[04:58] <sivang> Mithrandir: thanks
[04:58] <pygi> sivang, once there is stable version, then you'll get tarball :P
[04:58] <sivang> pygi: ah :p
[04:59] <pygi> sivang, libburn and libisofs might be called 0.2SVN (stable release will be 0.2.1) and cdrskin is 1.5SVN (I don't know what the stable release will be :P)?
[05:01] <pygi> sivang, ergh, actually, the cdrskin is 1.4SVN
[05:02] <sivang> pygi: I'll see what I can do, am not promising anything for this week though...I'm quite busy with stuff
[05:03] <pygi> sivang, I know, but this is important :)
[05:03] <sivang> pygi: I have to clear out some stuff, once I do, I'll sit to see about it's packaging. Should be quite fun.
[05:03] <pygi> sivang, oki, thanks :)
[05:04] <sivang> pygi: my pleasure.
[05:08] <slomo> infinity: :( and now gnome-python-desktop ftbfs because of the same problem with pygtk on those two archs... what a nightmare
[05:10] <Riddell> pitti: any chance of main reviewing python-qt4 sometime this week?
[05:10] <pitti> Riddell: yes, if you need it
[05:12] <Riddell> would mean hwdb wasn't depending on stuff in universe
[05:13] <infinity> slomo: Don't worry about it, dude, I'll take care of it by morning.
[05:14] <infinity> slomo: Patience is a virtue. :)
[05:15] <Hobbsee> infinity: patience?  what's that?
[05:15] <slomo> infinity: ok :) only wanted to help you... and i have a feeling that they let most of gnome FTBFS on those archs again ;)
[05:15] <infinity> slomo: Yeah, new GNOME is always painful.  I'll unsnag it tomorrow.
[05:15] <slomo> infinity: sleep well :)
[05:17] <Hobbsee> hmmm...yeah...bedtime...
[05:18] <pygi> Hobbsee, night
[05:21] <dholbach> infinity: good night!
[05:21] <dholbach> Hobbsee: night Hobbsee
[05:21] <jdong> bed time, it's bright and early
[05:21] <jdong> :)
[05:23] <Hobbsee> no it's not...
[05:23] <Hobbsee> i live in infinity's timezone.  where ti's definetly time for bed.
[05:24] <pygi> Hobbsee, just australia :)
[05:24] <Hobbsee> pygi: heh.  what are you saying. that it's always time for bed here or something?
[05:24] <pygi> Hobbsee, lol, no :)
[05:24] <jdub> Hobbsee: putting posters up at club mac yet?
[05:25] <Hobbsee> jdub: no.
[05:25] <jdub> Hobbsee: SLACKEUR!
[05:25] <Hobbsee> jdub: have you any idea how much i even get there?
[05:25] <jdub> it's club mac
[05:25] <jdub> of course you don't go
[05:25] <Hobbsee> jdub: indeed.  pia was about the last person i expected to be calling me at that point
[05:30] <Riddell> Kamion: I'd say you could merge abattoir's oem-config into your branch now
[05:30] <Riddell> Kamion: http://muse.19inch.net/~abattoir/bzr/mainline/
[05:31] <bluefoxicy> uuuuugh it's 11:30 why am I up
[05:32] <Kamion> Riddell: cool, will do
[05:33] <_ion> Here it's 18:30. :-)
[05:35] <neuralis> neat, i'm pulling from cdimage.u.c at 95mbit/s
[05:36] <heno> seb128, dholbach: obviously feature freeze is drawing near. Just wanted to check: will you be happy to take some patches from me, say tomorrow, for the menu layout of the access stuff? (just to start onboard and orca)
[05:37] <dholbach> heno: so changes to the orca and onboard package?
[05:37] <dholbach> heno: onboard and virtkey are in NEW atm.
[05:38] <heno> dholbach: yes, but also to the gnome assistive technology pref panel (to move it's menu entry and add a checkbox)
[05:38] <heno> dholbach: will look something like this: http://people.ubuntu.com/~henrik/images/access-sub-menu.png
[05:38] <mjg59> Seveas: Around?
[05:39] <Hobbsee> mjg59: unlikely.  he hasnt been before this
[05:39] <dholbach> heno: did you talk to sabdfl about that before?
[05:39] <heno> dholbach: no, just mdz
[05:40] <heno> dholbach: I'll email sabdfl
[05:40] <dholbach> because he had visions for the menu and he was the last instance to ask last time
[05:40] <heno> right
[05:41] <seb128> heno: what dholbach said
[05:42] <heno> seb128: ok, thanks. I'll get clarification
[05:42] <seb128> np
[05:46] <zul> everything is happy
[05:46] <zul> oops..
[05:57] <iwj> OK, I give up.  I tried to make a private apt archive area but apt says `Ign' for it and I can't persuade it to say why.
[05:58] <jdong> iwj: it's because you haven't uploaded firefox 2.0b2 packages to edgy for me to play with yet :)
[05:58] <iwj> jdong: Uh-hu.
[05:58] <Kamion> iwj: did you gzip the Packages/Sources files? Common thing I forget ...
[05:58] <iwj> You have to gzip them or it can't cope ?  FFS
[05:58] <Kamion> apt doesn't like them uncompressed and isn't very helpful about it
[05:59] <_ion> iwj: falcon is very handy, it does all the dirty work.
[05:59] <iwj> That doesn't seem to have helped.
[06:00] <jdong> tsk tsk tsk... I'm telling you.... :)
[06:00] <iwj> Why can't I get this SHIT-FOR-BRAINS program to give me an ERROR MESSAGE ?
[06:02] <iwj> _ion: What is `falcon' ?
[06:03] <Kamion> iwj: I think you're supposed to use that nethack GUI frontend to generate your apt archives
[06:04] <iwj> Kamion: That was what I was thinking ...
[06:04] <LarstiQ> zul: hmm?
[06:05] <zul> LarstiQ: sorry misfire from last night
[06:06] <LarstiQ> zul: ok :)
[06:06] <Seveas> mjg59, I'm here now but not for very long
[06:06] <_ion> iwj: http://www.kaarsemaker.net/software
[06:07] <neuralis> Kamion: is lvm in d-i known broken in knot-2? i see a grub lvm bug, but could've missed an installer one
[06:07] <iwj> _ion: ??  Not in Debian or Ubuntu !
[06:07] <_ion> iwj: Unfortunately.
[06:08] <_ion> Its repository has contained the debian packaging forever.
[06:08] <iwj> You can understand my reluctance.
[06:09] <Kamion> neuralis: yeah - fixed just afterwards. to see if it's the same bug, check whether lvm2.deb is on the CD (it probably isn't)
[06:09] <_ion> iwj: Yes, but i sincerely recommend it; it is far easier to use than anything else i've tried.
[06:09] <Seveas> iwj, 'falcon' is ~9 months old now, didn't yet attempt to have it included
[06:10] <mjg59> Seveas: I've been looking at your branch
[06:10] <Seveas> mjg59, cool! How crackful was it?
[06:10] <mjg59> Seveas: I've tidied up the progress bar pulsation slightly - it wasn't drawing the ends correctly
[06:10] <Kamion> there must be a bug about apt not recognising ungzipped index files - I noticed that years ago
[06:10] <mjg59> That is, there should have been two frames drawn at each end rather than just one, otherwise it looks jerky
[06:11] <Seveas> mjg59, true
[06:12] <Seveas> I'll be pushing a few more revisions tomorrow, support for a -v switch and a kernel command line argument so it can be made to shut up by default but verbose if wanted
[06:12] <Seveas> and some packaging things so creating themes will be easier
[06:12] <mjg59> Seveas: Ok - can you repull from mainline?
[06:12] <Seveas> will do
[06:12] <mjg59> I'm just pushing my changes
[06:13] <neuralis> Kamion: lvm2_2.02.06-2ubuntu2_amd64.deb and matching udeb are there. i wonder if it just failed to load properly; i'll retry.
[06:14] <iwj> Seveas: I don't need easy to use, I need it to work and really what I need is for apt to explain why it is `Ign'oring me.
[06:15] <Seveas> iwj, ign is usually for missing .pgp keys
[06:15] <Seveas> or Release.gpg files
[06:15] <Seveas> (falcon also works by the way, I know several people who use it and are happy with it -- if you want something in Ubuntu proper, I'd suggest reprepro)
[06:17] <iwj> Seveas: Thanks for the tip about .gpg; I had a .sig instead.
[06:18] <neuralis> Kamion: lvm configurator loads and runs, but is still broken; doesn't allow re-entry into lvm group config, and doesn't add the chosen lvm vg(s) to the main partitioning screen
[06:19] <Kamion> neuralis: ok, partman-lvm bugs would be good; we may just need to sync from upstream
[06:19] <neuralis> Kamion: ok, filing.
[06:19] <ivoks> neuralis: this happens on all linux systems
[06:20] <neuralis> ivoks: uh, no. if lvm doesn't add the vgs to the main partman screen, it's unusable.
[06:20] <mjg59> Seveas: So do we get a test 256-colour theme soon?
[06:20] <ivoks> neuralis: i agree, but same thing happens on fedora, too :/
[06:21] <neuralis> ivoks: then their lvm is broken, as well. this works fine in dapper.
[06:21] <ivoks> neuralis: if you don't initialize lvm and remove all vg before creating new one, installer segfaults :/
[06:21] <iwj> 7967  write(2, "Signature made Tue Sep  5 03:33:"..., 70) = -1 EBADF (Bad file descriptor)
[06:21] <Seveas> mjg59, that's part of the things I plan for tomorrow
[06:21] <mjg59> Seveas: Rock
[06:21] <Seveas> 256 colors, png progressbar
[06:22] <Kamion> ivoks: I don't think it's possible for a partman bug to "happen on all Linux systems"
[06:22] <Kamion> seeing as it's inherently specific to Debian and derived distributions
[06:22] <ivoks> Kamion: i don't think it's a partman bug
[06:23] <Kamion> ivoks: I don't understand how you've got enough information from what neuralis said to conclude that
[06:23] <mjg59> If Edgy is a colour, what colour is edgy?
[06:23] <ivoks> Kamion: it's not from what neuralis said, it's from exp. of lots of lvm installations :/
[06:23] <FunnyLookinHat> maroon...  with orange blaze.
[06:24] <Kamion> ivoks: please don't conflate all possible LVM bugs into one
[06:24] <ivoks> Kamion: :) ok
[06:24] <Kamion> I'm quite sure there's room for multiple issues in there
[06:24] <neuralis> Kamion: his theory is easy enough to test, i'll let you know in a minute.
[06:24] <Kamion> neuralis: thanks
[06:25] <Kamion> Mithrandir: did we figure out any way to port console-keymaps-tree to console-setup?
[06:31] <Mithrandir> Kamion: just have console-setup build-depend on treetool (or whatever the tool making the decision trees is called), then generate the c-k-t as part of the c-s build?
[06:31] <Kamion> (keymapper)
[06:31] <Mithrandir> thanks, I always forget that name. :-)
[06:31] <Kamion> "just" - hmm
[06:32] <Kamion> well, I can try, but I'm worried about the timing
[06:34] <Mithrandir> Kamion: how so?  It'll make the build even slower, but apart from that it'd work fine.
[06:35] <Kamion> I mean that it's a day and a bit before FF and I'm not sure of the code :)
[06:36] <iwj> Woohoo!  It works!
[06:50] <iwj> pycentral: pycentral rtremove: installed runtime python2.3 not found
[06:50] <iwj> I can't remove or install python2.3, it seems.
[06:52] <elmo> Kamion/mithrandir: is it known that knot-2's server profile is broken?
[06:52] <Kamion> elmo: no
[06:52] <Kamion> broken how?
[06:52] <elmo> Spads: ?
[06:52] <Spads> hi
[06:53] <Spads> Kamion: oh, when I installed from alternative-i386
[06:53] <Spads> I did "install server"
[06:53] <Spads> and it popped up a warning that it couldn't find the file with the selections
[06:54] <Seveas> iwj, that has been filed in lp about 50 times
[06:56] <iwj> Seveas: No doubt the LP search is maliciously hiding it from me.
[06:57] <Seveas> iwj, heh
[06:57] <Seveas> it's often filed under the dist upgrader
[06:57] <ogra> did it ever reveal something for you ? 
[06:57] <Seveas> since it usually happens when people dist-upgrade from dapper
[06:58] <Seveas> it's a pycentral bug though and most bugs are marked as duplicate of one filed on pycentral
[06:58] <mjg59> \o/
[06:58] <mjg59> Another piece of forum fanservice
[06:59] <iwj> If I search `Bugs in Ubuntu' for `pycentral' it gives me bug 56690 and bug 51718.
[06:59] <iwj> Yay, I killed the bug bot too.
[06:59] <Spads> um, doesn't "fanservice" mean "drawing jiggling body parts to impress young male viewers"?
[06:59] <mjg59> Spads: That's one form of it
[06:59] <iwj> Anyway, neither of them are it.
[07:00] <iwj> No packages matching 'pycentral' are published in Ubuntu.
[07:01] <Kamion> python-central
[07:01] <iwj> Oh, of course.
[07:01] <Riddell> ogra: iz gtk bug with hwdb-client "ImportError: PyGObject version too old, 2.11.1 is required, found 2.12.0."
[07:01] <ogra> meah
[07:01] <iwj> python-central has one bug, 57795, which looks like something different.
[07:02] <slomo> Riddell, ogra: upgrade to -0ubuntu2 of pygtk and pygobject... should fix this one
[07:02] <slomo> Riddell, ogra: that is... 2.12.0-0ubuntu2 of pygobject and 2.10.0-0ubuntu2 of pygtk
[07:03] <ogra> ah, so its not hwdb ...
[07:03] <ogra> great
[07:04] <mjg59> Woo I win
[07:06] <mjg59> Can anyone remember where splashdown is actually triggered?
[07:08] <Riddell> slomo: yep, that fixes it, thanks
[07:08] <Riddell> mjg59: in gdm and kdm
[07:08] <Kamion> Spads: thanks; that was an ubuntu-cdimage bug, which I've now fixed.
[07:09] <mjg59> Riddell: Ta
[07:09] <Spads> Kamion: thanks
[07:19] <homegrown> anyone aware of issues with compiz after dodgy xorg patch?
[07:19] <mjg59> No
[07:32] <dholbach> good night
[07:52] <neuralis> Kamion: in other news, the partman-lvm failure appears to be completely non-deterministic; i've been unable to pin it down across 24 reboots before giving up just now. 
[08:16] <ogra> doko, ping
[08:16] <doko> ogra: away in one minute ...
[08:17] <ogra> doko, see pm
[08:27] <zyga> re
[08:43] <lisi> mjg59, hello, ping.
[08:46] <lisi> mjg59, I would like to ask you about this bug: https://launchpad.net/distros/ubuntu/+source/ttf-bpg-georgian-fonts/+bug/55966, is it possibile to fix that ?
[08:59] <zyga> I'm writing a paper about lisp, if you know and use lisp please /msg me and say what is the most annoying thing about that language and why; thanks
[09:15] <pitti> Hello again
[09:15] <HiddenWolf> hey pitti
[09:20] <ivoks> hi
[09:20] <ivoks> (i know, i'm late :)
[09:22] <Lure> anybody knows where did old ubuntu-artwork package went - latest source only has distributor logo...
[09:23] <LaserJock> Lure: I think themes have been split up into separate packages
[09:24] <Lure> LaserJock: ok, so probaly *human* something (I am Kubuntu user, just need to borrow two icons ;-))
[09:24] <LaserJock> Lure: something like that, I can't remember specifically
[09:25] <Burgwork> yes, I believe it is icon-humans
[09:25] <Burgwork> icons-human, rather
[09:25] <Lure> LaserJock: got it: human-icon-theme
[09:25] <Lure> thanks
[09:25] <Treenaks> Burgwork: We are the icon-humans! We want human-icons!
[09:25] <Treenaks> wait..
[09:28] <Burgwork> Treenaks...
[09:29] <Treenaks> Burgwork: sorry :)
[09:30] <Burgwork> *grin*
[09:30] <HiddenWolf> Burgwork, why is it never Burgfun? :)
[09:31] <Treenaks> HiddenWolf: All Burgwork and no Burgplay makes jack a dull boy ?
[09:31] <HiddenWolf> Treenaks: like that. :)
[09:38] <pitti> G0SUB: I'm here now
[09:38] <G0SUB> pitti: great
[10:00] <hikenboot> hello all--question for you all...I am removing perhaps 50 packages from the live cd using apt-get remove `cat file.txt`...one or several of these packages are a causing x-window-system-core xbase-clients ubuntu-base ubuntu-live and ubuntu-desktop to be removed
[10:00] <hikenboot> my question is how can i see the tree of dependencies so i can figure out which package is causing this
[10:01] <pitti> hikenboot: apt-cache rdepends might be helpful
[10:02] <pitti> hikenboot: or http://people.ubuntu.com/~cjwatson/germinate-output/edgy/rdepends/
[10:02] <hikenboot> thanks...it does help a lot 
[10:03] <hikenboot> why would ubuntu live depend on xh language pack? I thought the default was english?
[10:11] <_ion> Wow, apport is really nice.
[10:11] <pitti> _ion: \o/ :)
[10:12] <zyga> pitti: apport can kill your machine after 'collecting' a program that died of memory consumption
[10:12] <_ion> A thought: perhaps the UI should allow the user to read 'strings' output of the core dump, if she wishes to.
[10:12] <pitti> zyga: I have a bug open about that
[10:12] <pitti> zyga: repeated crashes, apport catches itself
[10:12] <zyga> oh!
[10:12] <zyga> recursive crash
[10:13] <zyga> I once wrote a crash handler that pretty much got me fired :)
[10:13] <pitti> yeah, I have to think about that case
[10:13] <zyga> it required a hard reboot of a really critical production server that manages tons of transactions with real money
[10:14] <zyga> (the funny thing is that it got there by accident, it was #ifdef'd)
[10:14] <zyga> it tried to send an email every time a crash happened
[10:14] <zyga> unfortunatly it looped and forked the system to death
[10:14] <_ion> Heh.
[10:14] <pitti> zyga: thanks for that hint with the firing, I'll think *really hard* :)
[10:14] <_ion> "If something can go wrong, it will."
[10:14] <zyga> _ion: heh, yeah
[10:15] <zyga> but I've got a better job now and I'm more careful
[10:36] <sivang> hmm, anybody recalls how to ident a block in emacs?
[10:36] <sivang> (the keystorke, that is)
[10:37] <Seveas> Probably C-m zd^fsdy^H^H^
[10:37] <sivang> Seveas: I recall that a bit shorter sequence :-)
[10:37] <pitti> wow, and people say that vim is complicated... (SCNR)
[10:37] <sivang> but thanks
[10:38] <johanbr> sivang: Could be Alt-Q, not 100% sure.
[10:38] <johanbr> Actually, lower-case q in that case.
[10:39] <pitti> johanbr: didn't that reformat a paragraph?
[10:39] <zyga> sivang: ctrl-x, ctrl-c, vim
[10:39] <sivang> zyga: HAH
[10:40] <zyga> sivang: if you don't know how to use that abomination of an editor why do you do it?
[10:40] <zyga> (when there are more sane things around)
[10:40] <johanbr> pitti: In a "normal" mode, yes. I'm not sure what it does in C mode. In any case, doing "M-x fill-region" should work.
[10:40] <zyga> I'm not flaming, just really curious
[10:40] <sivang> zyga: I recalled that once, but I wasn't using it for a while and so forgot.
[10:40] <sivang> zyga: I do like it.
[10:41] <sivang> johanbr: I'm using a nice python mode, and it's different, still searching
[10:41] <zyga> sivang: I see, I hope I did not offend you
[10:41] <pitti> zyga: well, I have used emacs for years, and it's really not that bad
[10:42] <zyga> pitti: did you hear of chinese slave workers?
[10:42] <johanbr> sivang: Okay. Try typing "M-x fill", then hit the tab key for completion and see what that gives you.
[10:42] <pitti> zyga: excuse me?
[10:42] <zyga> pitti: they seem to have started to like it recently ;-)
[10:43] <zyga> just flaming now, don't take me seriously
[10:43] <zyga> I had a long flame with the owner of my company about vim and emacs *AND* python and lisp
[10:43] <seb128> zyga: emacs is a nice editor!
[10:43] <pitti> seb128: emacs is a nice operating system, it just lacks a good editor
[10:43] <pitti> sorry, guys
[10:43] <zyga> hehehehe
[10:43] <zyga> :D
[10:44] <zyga> emacs *is* nice
[10:44] <_ion> As far i'm concerned, grub is better than emacs, but ruby is better than kde.
[10:44] <zyga> it's just that some people don't like how fricking huge it is
[10:44] <johanbr> emacs: "Text-editor for non-human beings". :)
[10:44] <zyga> _ion: hehe
[10:44] <pitti> _ion: chocolate is better than vanilla!!!
[10:44] <pitti> johanbr: to be fair, vim isn't for the faint-hearted either
[10:44] <zyga> johanbr: :)
[10:45] <zyga> btw, would you ack the spec to remove vim and emacs from the CD?
[10:45] <seb128> zyga: at least you can type your text when it opens without having to know any magic :p
[10:45] <zyga> pitti: but vim is nice for emacs users and gives them a hint on how to turn it off ;-)
[10:45] <zyga> seb128: but then you have to know some magic to save it or quit
[10:45] <seb128> zyga: no, emacs has a menu ;)
[10:45] <pitti> zyga: ok, I think this really doesn't belong here
[10:46] <zyga> seb128: gvim has a menu too, you can even use it like a menu
[10:46] <zyga> ok ok :)
[10:46] <zyga> I'm just having lots of fun now :)
[10:46] <seb128> zyga: I didn't say it has not ...
[10:46] <sivang> seb128++
[10:46] <welshbyte> the first thing i remember from trying emacs all those years ago is thinking "what's a buffer?"
[10:46] <zyga> oh boy I started a flame war, let's go to #ubuntu-offtopic
[10:47] <seb128> I don't intend spending time on that discussion, so no need for that :p
[10:47] <pitti> please not the 234829423th emacs vs. vim flamewar
[10:47] <pitti> the kool boys use ed :-P
[10:47] <hikenboot> any ideas? "xbase-clients" has a lot of dependencies  but i am removing none of them so i am not sure why this package is being removed any ideas?
[10:47] <_ion> Bah, i modify the files with a magnet.
[10:48] <sivang> pitti: haha
[10:49] <pitti> hi pygi 
[10:50] <pygi> hey pitti :)
[11:16] <_ion> Hi keybuk
[11:17] <Keybuk> heyhey
[11:22] <cbx33> If i needed a script to run in the background when someone logs in, where would I add it?
[11:24] <Riddell> Lure: seb128 should be a good place to start
[11:24] <cbx33> ping seb128 
[11:24] <seb128> cbx33: pong
[11:25] <cbx33> seb128, remember that gconf line I wanted added?
[11:25] <seb128> yeah
[11:25] <seb128> did you open a bug?
[11:25] <cbx33> does it need to be done before FF
[11:25] <seb128> no
[11:25] <cbx33> ok that's cool
[11:25] <Lure> seb128: I have seen g-p-m/g-s-m uses gconf entries to know if suspend/hibernate is provided by system - but whic program populates these gconf entries?
[11:25] <cbx33> I'll get that done as soon as I can
[11:25] <cbx33> I also had another quick questions for you
[11:25] <seb128> Lure: gnome-power-manager
[11:26] <cbx33> oh btw, don't worry I repackaged pessulus from your sync :D
[11:26] <seb128> cbx33: why repackaged? what is wrong with my sync?
[11:26] <cbx33> nothing
[11:26] <cbx33> I had to add a patch for the Student Control Panel Integration
[11:26] <cbx33> did you want to review it?
[11:27] <Lure> seb128: thanks - will check if it just trusts HAL or something else (we have complaints in KDE that HAL report hibernate as supported on some desktops)
[11:27] <seb128> Lure: why would hibernate be supported on a desktop?
[11:27] <seb128> wouldn't
[11:28] <Lure> seb128: it could be, but there are many report that it does not work
[11:28] <Fujitsu> But it works fine on quite a number, Lure.
[11:28] <cbx33> seb128, I can send you my diff.tar.gz if you want it?
[11:29] <Lure> seb128: from g-p-m source, I can only see that it needs both positive from hal as well as from gconf setting, but g-p-m does not look like to set gconf entry on its own
[11:29] <seb128> cbx33: not today but maybe tomorrow yeah
[11:29] <cbx33> seb128, what email address?
[11:29] <Lure> Fujitsu: that is what bothers me - should we trust HAL or should we have any workaround 
[11:30] <seb128> cbx33: seb128@ubuntu.com
[11:30] <cbx33> ok cool
[11:30] <Fujitsu> No, you should trust HAL.
[11:30] <cbx33> vuntz has been with me all the way through
[11:30] <seb128> Lure: /usr/share/gconf/schemas/gnome-power-manager.schemas
[11:30] <cbx33> he's approved all my alterations
[11:30] <seb128> good
[11:30] <Fujitsu> HAL should be corrected, not the application, because a number of things work off HAL.
[11:30] <Fujitsu> (although I'm not sure correction is necessary)
[11:30] <cbx33> seb128, seeing as you're kinda involved in this now too
[11:30] <seb128> cbx33: you can discuss that on #ubuntu-desktop with vuntz BTW, so we can participate ;)
[11:31] <cbx33> for SCP I need to run a python listening script for dbus, everytime someone logs on
[11:31] <cbx33> where do I place the link so it's gets run for every session login?
[11:32] <seb128> cbx33: add a .desktop to /etc/xdg/autostart/ by example
[11:32] <_ion> If it's a X login, perhaps /etc/xdg/autostart?
[11:32] <cbx33> thakns seb128 
[11:32] <seb128> cbx33: look to update-notifier by example for an example
[11:32] <seb128> np
[11:32] <cbx33> thanks seb128 
[11:32] <Lure> seb128: thanks - so it is on by default, therefore HAL prevails
[11:33] <seb128> Lure: which makes sense
[11:33] <seb128> Lure: the default is to trust HAL
[11:33] <Lure> seb128: yep, otherwise we should fix HAL
[11:33] <cbx33> seb128, what does the terminal field invoke?
[11:33] <seb128> not "otherwise", if HAL is wrong it should be fixed
[11:34] <seb128> cbx33: if you want to start a gnome-terminal
[11:34] <cbx33> nice _ion 
[11:34] <cbx33> i see
[11:34] <seb128> cbx33: like if you start mutt better to do it in a terminal
[11:34] <cbx33> ah right i see
[11:36] <cbx33> seb128, does this .desktop apply even if the script that is started is a non-GUI script
[11:36] <cbx33> ie just a terminal process
[11:36] <cbx33> requires no intereaction from user
[11:38] <Kamion> hikenboot: ubuntu-live's dependencies are "everything we want to shove into the live CD to fill up the remaining space"
[11:38] <Kamion> hikenboot: don't take them as statements of policy
[11:40] <zyg1> Kamion: would it not be cool to say that ubuntu-live depends on ubuntu-desktop, ubuntu-live-stuff, ubuntu-live-language-packs, ubuntu-another-group-of-packages so that we don't throw everything into one bag?
[11:40] <Kamion> zyg1: seems mostly pointless to me
[11:40] <Kamion> I'd rather get rid of ubuntu-live and just handle it with Task fields, TBH
[11:40] <zyg1> Kamion: task fields?
[11:40] <Kamion> I don't really see the value in handling that particular one as a metapackage
[11:41] <Kamion> yes, c.f. aptitude ~t patterns and tasksel
[11:41] <zyg1> ah
[11:41] <zyg1> that's the general idea :)
[11:41] <Kamion> zyg1: also, the items are separated out into blocks in the seeds, so it's perfectly manageable for us
[11:41] <zyg1> there are not so many tasks currently though
[11:41] <Kamion> it's only people who try to hack on the generated output without using the seeds who have trouble
[11:42] <Kamion> zyg1: https://launchpad.net/distros/ubuntu/+spec/ubuntu-server-tasks
[11:43] <zyg1> mmm, interesting - thank you
[11:54] <seb128> Keybuk: around?
[11:56] <Keybuk> seb128: yup, 'sup?
[11:57] <seb128> Keybuk: my system doesn't boot normally, maybe you have an idea on it
[11:57] <seb128> I get the "Booting the operating system now"
[11:57] <seb128> then "No cryptroot configured, skipping"
[11:57] <seb128> and then a text login prompt
[11:57] <Keybuk> right ...
[11:57] <seb128> is the boot suposed to be verbose with upstart?
[11:57] <Keybuk> what interesting things do you have on your syste,?
[11:57] <seb128> I just installed upstart now
[11:57] <Keybuk> no, it's not verbose by default (though I might suggest we change that)
[11:58] <seb128> knowing I have ubuntu-minimal not installed :p
[11:58] <Keybuk> why don't you have ubuntu-minimal installed?
[11:58] <seb128> I had to install the sysv-compat package by hand but it doesn't fix the boot
[11:58] <Keybuk> do you have initscripts installed?
[11:58] <seb128> because it probably got removed at some point and I didn't bother reinstalling it
[11:58] <seb128> I just figured that :p
[11:58] <seb128> ii  initscripts              2.86.ds1-14.1ubuntu7     Scripts for initializing and shutting down the system
[11:59] <Keybuk> ok
[11:59] <seb128> I don't think I've weird things started on boot
[11:59] <Keybuk> login to the text one
[11:59] <Keybuk> sudo status rcS rc2
[11:59] <seb128> "rcS (stop) waiting
[11:59] <seb128> rc2 (stop) waiting"
[11:59] <Keybuk> ok, is X/gdm running?
[11:59] <Keybuk> (ps ax
[11:59] <seb128> from my X session I started with a /etc/init.d/gdm restart
[12:00] <seb128> should I rather IRC from an another box and let the desktop to text mode?
[12:00] <Keybuk> is everything else from rc2 running?
[12:00] <Keybuk> ie. dbus, hal, etc.
[12:00] <seb128> looks not a lot of things are running, no
[12:00] <seb128> no
[12:00] <Keybuk> ok
[12:00] <Keybuk> can you do "start rc-default"
[12:01] <Keybuk> (with sudo)
[12:01] <_ion> Now the boot logger would be handy. :-)
[12:01] <Keybuk> and then immediately after "status rc1 rc2"
[12:01] <seb128> $ sudo start rc-default
[12:01] <seb128> rc-default (start) running, process 5226 active
[12:01] <seb128> $ sudo status rc1 rc2
[12:01] <seb128> rc1 (stop) waiting
[12:01] <seb128> rc2 (stop) waiting
[12:01] <Keybuk> ok
[12:01] <Keybuk> run that sudo status bit a couple of times
[12:02] <seb128> no change
[12:02] <Keybuk> "runlevel" says ?
[12:02] <seb128> 2 2
[12:02] <Keybuk> odd
[12:02] <Keybuk> sudo initctl jobs &
[12:02] <Keybuk> sudo start rc2
[12:02] <seb128> $ rc2 (start) starting, process none
[12:02] <seb128> rc2 (start) running, process 5269 active
[12:02] <seb128> rc2 (stop) stopping, process none
[12:02] <seb128> rc2 (stop) waiting
[12:02] <seb128> nothing next
[12:03] <seb128> it's waiting there
[12:03] <Keybuk> very odd
[12:03] <Keybuk> you have /etc/init.d/rc yes ?
[12:03] <seb128> yep
[12:03] <Keybuk> ok
[12:03] <seb128> 82c53693cda46f9144d94551a5442a68  /etc/init.d/rc
[12:03] <Keybuk> can you edit /etc/event.d/rc2 for me
[12:03] <Keybuk> add "console output" before the "script" line
[12:04] <Keybuk> and then "set -x" after it
[12:04] <Keybuk> ie.
[12:04] <Keybuk> console output
[12:04] <Keybuk> script
[12:04] <Keybuk>         set -x
[12:04] <Keybuk>         set $(runlevel --set 2 || true)
[12:04] <seb128> done
[12:04] <Keybuk> oh
[12:04] <Keybuk> hmm
[12:04] <Keybuk> you're in X
[12:04] <seb128> yeah
[12:04] <Keybuk> take out console output, and instead add "exec 2>/tmp/rc2.log" before the set -x line
[12:04] <Keybuk> script
[12:04] <Keybuk>         exec 2>/tmp/rc2.log
[12:04] <Keybuk>         set -x
[12:04] <Keybuk>         set $(runlevel --set 2 || true)
[12:04] <Keybuk> so you have that
[12:05] <seb128> k
[12:05] <seb128> "sudo start rc2"?
[12:05] <Keybuk> now sudo start rc2
[12:05] <Keybuk> yup
[12:05] <seb128> $ cat /tmp/rc2.log 
[12:05] <seb128> + runlevel --set 2
[12:05] <seb128> + set 2 2
[12:05] <seb128> + [ 2 != unknown ] 
[12:05] <seb128> + PREVLEVEL=2
[12:05] <seb128> + RUNLEVEL=2
[12:05] <seb128> + export PREVLEVEL RUNLEVEL
[12:05] <seb128> + exec /etc/init.d/rc 2
[12:05] <seb128> stty: standard input: Inappropriate ioctl for device
[12:05] <Keybuk> O.K.
[12:06] <Keybuk> hmm
[12:06] <Keybuk> ok
[12:07] <Keybuk> it stops immediately after it starts?
[12:07] <Keybuk> (from the jobs & thing)
[12:07] <seb128> yes
[12:07] <Keybuk> ok