[00:21] <phil_ps> I submitted a patch for glife a few days ago on launchpad
[00:21] <phil_ps> contacted the maintainer...
[00:21] <phil_ps> no response from either...
[00:22] <phil_ps> (I know glife is not a top priority program, but it was my first patch)
[00:23] <nhandler> phil_ps: What does the patch do?
[00:23] <phil_ps> nhandler: makes it compile again.  (ports from glade0 to glade2)
[00:23] <phil_ps> nhandler: its been a year since the package worked
[00:24] <nhandler> phil_ps: You will want to file a Freeze Exception request for it (https://wiki.ubuntu.com/FreezeExceptionProcess). Once the request gets approved, subscribe ubuntu-universe-sponsors to the bug to get it uploaded
[00:24] <phil_ps> nhandler: it was the first thing on the "harvest" list
[00:24] <phil_ps> nhandler: thanks
[00:24] <nhandler> phil_ps: You're welcome
[00:26] <phil_ps> nhandler: oh, I see, the new ubuntu is coming out so there is a freeze.  I've heard of that
[00:30] <maco> haha that's a good thing for a patch to do...
[00:32] <phil_ps>  its gnome2-0 supported in ubuntu 9.04? where would I find out without installing it
[00:32] <phil_ps> (on a windows machine...)
[00:32] <phil_ps> (linux laptop is on loan...)
[00:35] <maco> packages.ubuntu.com
[00:36] <phil_ps> thanks marco
[00:38] <phil_ps> hmm, I guess I should get the beta and try to get it to compile there. (I am such a newbie...)
[00:39] <maco> phil_ps: alpha, actually
[00:41] <phil_ps> the thing I love about working on open source software so far is interacting with people regarding computers.  I am in grad school but still, it's considered cheating when you discuss problems....
[00:42] <phil_ps> marco: thanks
[00:42] <ia> wooow... new gdm theme in jaunty incredibly amazing :-)
[00:43] <maco> phil_ps: my school says we can discuss, just write our answers independently (undergrad here)
[00:43] <maco> phil_ps: and there's no r
[00:46] <phil_ps> marco: yeah they say that here too.  but I dunno, this is just so much more fun
[00:47] <maco> phil_ps: you know, i only get highlighted if you spell my nick right
[00:48] <LaserJock> hehe, maco has a new nickname :p
[00:48] <jdong_> maco: polo!
[00:49] <maco> *snort*
[00:49] <phil_ps> maco: sorry
[00:50] <phil_ps> haha
[00:51] <maco> isok im too busy laughing at jdong_ now
[00:51] <maco> actually...i think i have a picture of marco polo's house...
[00:52]  * LaserJock wonders if it has a pool
[00:52] <maco> LaserJock: its in venice. just walk out the front door.
[00:53] <maco> i took the photo from a gondola
[00:53] <maco> oh....i guess that explains why it's a swimming game
[00:54] <ajmitch> water polo is :)
[00:55] <maco> ajmitch: marco polo is too...
[00:55] <ajmitch> how odd
[00:55] <maco> huh?
[00:55] <ajmitch> nevermind
[00:57] <LaserJock> yay, LP is back
[00:57] <phil_ps> I hate that java doesn't have function pointers/delegates
[00:57] <phil_ps> (probably wrong channel...)
[00:58] <phil_ps> I'll goto ubuntu-offtopic
[00:58] <jdong_> phil_ps: you can do the same with anonymous interface wrappers
[00:58] <jdong_> well interface wrappers in general but Java now lets you declare them anonymously on the spot.
[00:58] <jdong_> it is IMO utterly verbose and ugly but it does the same thing
[00:59] <phil_ps> but the standard java components all use inheritance to achieve the effect. so annoying.
[00:59] <directhex> phil_ps, don;t use java if you don;t like it
[00:59] <phil_ps> have to for work
[00:59] <phil_ps> directhex: the company loves it, so I have to learn it real quick for this project
[01:00] <phil_ps> jdong_: i will look into that
[01:01] <jdong_> phil_ps: but yes it's based off the same inheritance idea, just syntactic shorthand so you can do it on the spot.
[01:01] <ArneGoetje> tjaalton,slangasek: until X.org has been changed that it would use fontconfig directly, we still need to deal with defoma. However, Keith Packard has mentioned that we works on that on the X side.
[01:01] <jdong_> I absolutely agree with you there should be a more smooth way of doing it but Java isn't known for being non-verbose.
[01:02] <maco> jdong_: which is more verbose, java or cobol?
[01:02] <jdong_> maco: lol OF THE PRACTICAL LANGUAGES
[01:02] <slangasek> ArneGoetje: what's left on the X side that doesn't just use Xft?
[01:02] <snuffmeister> hey
[01:02] <jdong_> maco: (select (list (languages (filter (practical) ))))))
[01:03] <snuffmeister> dunno if this is the right channel but i-m trying to install jaunty
[01:03] <snuffmeister> and the install from the livecd doens't work
[01:03] <maco> ubuntu+1 may be what you're looking for
[01:03] <snuffmeister> crashes, won't even start
[01:03] <maco> but that could be useful info...
[01:03] <maco> crashes when?
[01:03] <snuffmeister> ooh
[01:03] <snuffmeister> that's right
[01:04] <snuffmeister> thanks
[01:04] <ScottK> nhandler: patches to make stuff work don't need freeze exceptions.
[01:04] <directhex> jdong_, how about some JNI? that's nice & sensible syntactically
[01:04] <maco> snuffmeister: wait, when does it crash?
[01:04] <snuffmeister> it doesn't start
[01:04] <maco> does the lve cd not start or is it just the installer that's not working for you?
[01:04] <snuffmeister> installer
[01:04] <maco> did you try it from the command line to see if there are any error?
[01:04] <snuffmeister> i tried installing directly from boot but it started the whole live cd, and the installer doesn't start
[01:05] <snuffmeister> maco: no
[01:05] <snuffmeister> how do i do that?
[01:05] <jdong_> directhex: the last time I tried that I remembered the time I had to bridge a Ruby lib to Python using C as the middleman.
[01:05] <maco> try that. open gnome-terminal and run ubiquity in there
[01:05] <ArneGoetje> slangasek: I don't know. I'm not familiar with X.
[01:05] <jdong_> that was a bazillion times easier.
[01:06] <snuffmeister> is ubiquity the command?
[01:06] <snuffmeister> didn't do anything, i'm waiting for the crash signal
[01:08] <maco> yes, ubiquity's the installer command. run it in a terminal and pastebin whatever errors it throws
[01:08] <nhandler> scottk: He was porting from glade0 to glade2. I would not consider that a basic bug fix
[01:08] <ScottK> nhandler: I'd call porting from non-working to working a bug fix.
[01:08] <snuffmeister> maco: didn't do anything, no errors no nothing
[01:09] <snuffmeister> not even the crash signal
[01:09] <ScottK> The downside risk is nil.
[01:09] <maco> didnt launch either?
[01:09] <snuffmeister> nope
[01:09] <snuffmeister> lemme check the processes
[01:09] <snuffmeister> nothing there
[01:10] <nhandler> scottk: Depending on how you look at things, you could consider any change a bug fix
[01:10] <maco> snuffmeister: did you check the cd?
[01:10] <snuffmeister> for md5?
[01:11] <snuffmeister> not really, but it's the third or fourth time i've tried it, cd and dvd over time
[01:11] <ScottK> nhandler: This is true, but release management is mostly about risk management and if they thing is dead to start with, there's really not much to worry about.
[01:11] <snuffmeister> and never worked, only by updating
[01:11] <snuffmeister> i'm on the live cd, can i do that now?
[01:13] <maco> snuffmeister: reboot and when you start up itll offer to checkthe cd's integrity
[01:13] <slangasek> ArneGoetje: well, the only fonts that X itself /needs/ to have are fixed, serif, and sans (though I think the other two have other names in X); it doesn't need defoma for that; and any apps that use Xft bypass X's view of the fonts in favor of fontconfig
[01:13] <slangasek> snuffmeister: what version (date) of the CD are you using?
[01:13] <snuffmeister> ok, i'll do that
[01:13] <snuffmeister> daily build
[01:13] <snuffmeister> of yesterday
[01:13] <snuffmeister> or 2 days ago
[01:13] <slangasek> 2 days ago was broken
[01:14] <snuffmeister> =x
[01:14] <snuffmeister> mm
[01:14] <snuffmeister> mm
[01:14] <maco> well there's an answer
[01:14] <snuffmeister> lol
[01:14] <snuffmeister> ok
[01:14] <slangasek> if you need a reliable CD for installing the development release, you should generally use the most recent alpha
[01:14] <snuffmeister> alpha4 i guess
[01:15] <ArneGoetje> slangasek: legacy X apps don't.
[01:15] <slangasek> yes - unless you want to wait until alpha 5 is out tomorrow
[01:15] <slangasek> ArneGoetje: correct
[01:16] <slangasek> ArneGoetje: but I don't know any legacy X apps that need access to all the various fonts that are exposed via defoma
[01:16] <slangasek> ArneGoetje: i.e., legacy X apps already have access to everything under /usr/share/fonts/X11, which is not managed by defoma
[01:17] <snuffmeister> slangasek: crap, and i just formatted everything now =p
[01:17] <snuffmeister> what time, btw?
[01:18] <slangasek> snuffmeister: likely some time in the afternoon, US time
[01:19] <snuffmeister> hmm.. nighttime in europe
[01:19] <slangasek> yes
[01:20] <slangasek> LaserJock: FFe acked
[01:21] <LaserJock> slangasek: thank you kindly
[01:21] <LaserJock> slangasek: are you going to respin the Edubutu CD then?
[01:21] <slangasek> LaserJock: if it's still appropriate at the time the packages become available, yes
[01:21] <ArneGoetje> slangasek: I personally know that fontforge needs the XLFD to access fonts. Other apps (which are not core X) I don't know at the moment.
[01:21] <slangasek> if we happen to be left with an uninstallable moodle on the edubuntu alpha5 ISO, that's not the end of the world either
[01:22] <LaserJock> slangasek: certainly not
[01:22] <LaserJock> slangasek: I was just wondering when I should give the CD a test
[01:23] <ArneGoetje> slangasek: and in the past (that might have been fixed already) there were problems toth .ttc fonts in oo.o if they weren't registered through defoma.
[01:24] <ArneGoetje> s/toth/with/
[01:24] <slangasek> LaserJock: ah, I was planning to check the testing status in deciding whether to reroll edubuntu for moodle :)
[01:28] <LaserJock> slangasek: well, I can test it tommorow morning if we want to wait for a reroll
[01:29] <slangasek> that would be fine
[01:29] <LaserJock> k
[01:30] <ArneGoetje> slangasek: I suggest that for karmac we disable the dh_installdefoma call in all font packages and put them into a ppa. Then we can test if there are still problems left.
[01:30] <LaserJock> does the arch matter much for that one? I'm not really aware of anything that should be different between the amd64 and i386 CDs
[01:35] <slangasek> ArneGoetje: alternatively, we could prod Debian to see what their plans are and what bugs they hit, since there was discussion recently on debian-qa :)  http://lists.debian.org/debian-qa/2009/02/msg00074.html
[01:40] <nhandler> scottk: If that is the case, I would like to clarify what the wiki page says about Bug Fix uploads. So it would be clear that a new upstream releases/patches that fix broken packages that don't affect any other packages are ok to upload without a FFe
[01:41] <ScottK> nhandler: Basically the question is bugfix or features.  It doesn't really matter much if it's upstream features or locally induced ones.
[01:41] <ArneGoetje> slangasek: well, they want to fix it in squeeze... means within the coming 2 years or so... ;) If we want to be faster, then we should take the initiative for testing, I think.
[01:41] <slangasek> ArneGoetje: well, I don't think pabs was talking about waiting two years before removing it, though. :)
[01:42] <ScottK> So if a package is broken and you unbreak it, that's a bugfix.  An upstream release may also have feature changes and still need an FFe (we might prefer a patch to the new version).
[01:44] <ArneGoetje> slangasek: true, but it might take a bit longer until all problems are found and fixed. So, the overall time until everything works like expected may take multiple Ubuntu releases.
[01:45] <nhandler> scottk: But I think the definition of a bug fix is unclear. For instance, if my application doesn't currently have support for 'foo', someone might file a bug saying 'myApp does not work with foo'. So would a patch that fixes this count as a bug fix? Or would it be a new feature?
[01:46] <ScottK> New functionality is a feature.
[01:46] <ScottK> Just because someone scribbled in a bug tracker they want a feature, doesn't make it any less so.
[01:47] <LaserJock> like generally you wouldn't do wishlist bugs
[01:47]  * ogra remembers his first post FF gcompris upload ... i updated to a new upstream with a 37MB patch to aviod the paperwork ... we had no release manager back then
[01:47] <ogra> so watch out for such people :)
[01:48] <phil_ps> nhandler: launchpad is back up. I am trying to file the bug
[01:48] <phil_ps> nhandler: it asks if the existing bug is the one I want to file...
[01:48] <phil_ps> nhandler: not sure what to do
[01:49] <LaserJock> ogra: tsk tsk
[01:50] <LaserJock> that reminds me, I should go look at gcompris
[01:50] <ogra> LaserJock, yeah, that was hoary ... i as still learning my way around
[01:50] <ogra> or breezy
[01:50] <ogra> cant remember
[01:50] <ogra> today a RM would block it
[01:54] <slangasek> superm1: were you wanting a mythbuntu alpha5 reroll for bug #334547?
[01:55] <nhandler> scottk: I just think the line between new feature and bug fix is a little fuzzy and should be explained better on the wiki
[01:55] <ScottK> nhandler: OK.  Propose some text then.
[01:56] <nhandler> scottk: I will. I'm just trying to get a better idea for what you and the other -release members consider bug fixes
[01:57] <ScottK> OK.
[02:03] <slangasek> superm1: btw, is someone taking care of updating firmware-addon-dell to smbios-utils?
[02:06] <slangasek> superm1: seems to currently use getSystemId and dellBiosUpdate, both of which are provided as compat symlinks
[02:21] <superm1> slangasek, i was just talking to mebrown about that today.  will address it after alpha
[02:21] <slangasek> ok
[02:21] <calc> what format and where is the help that yelp shows?
[02:21] <superm1> slangasek, yeah we'll need a reroll for bug 334547
[02:21] <superm1> as long as *ubuntu4 has published by now
[02:21] <slangasek> calc: xml, /usr/share/gnome/help/foo?
[02:21] <calc> i have a bug report that complains that the OOo dev documentation doesn't show up in yelp, and i think it shouldn't but i don't know exactly how yelp works
[02:22] <calc> slangasek: ok
[02:25] <slangasek> calc: well, that's where the documentation is that's /displayed/; I don't know about how it's /registered/ with yelp
[02:26] <slangasek> superm1: ok, scheduled to trigger on the buildd as soon as mythtv -0ubuntu4 is published on amd64
[02:27] <LaserJock> calc: generally you'll want an .omf file and use scrollkeeper/rarian to register it
[02:27] <superm1> slangasek, great thanks
[02:27] <LaserJock> calc: the .omf files are placed in /usr/share/omf/<foo>
[02:29] <LaserJock> calc: is that documentation you would get at via the OO.o help menu or from yelp itself?
[02:49] <calc> LaserJock: neither he wanted documentation for developer stuff in ooo-dev-doc to be in yelp
[02:51] <LaserJock> calc: that's sort of tricky
[02:51] <LaserJock> you can get it into yelp's database but it's not exactly easy to get at from yelp
[02:52] <LaserJock> the menu you see when you open up yelp is hard-coded
[02:52] <LaserJock> unless it's a man/info page you gotta do a search for it, and yelp's search function is ... special
[03:08] <calc> LaserJock: ok i just closed it invalid after explaining that the OOo dev docs are not Gnome dev docs and are not formatted in the special manner that it requires
[03:09] <LaserJock> calc: are those docs available online somewhere?
[03:11] <calc> LaserJock: not certain, its in openoffice.org-dev-doc though
[03:19] <ScottK> If there's an archive admin with a free moment, I'd appreciate it if you'd toss http://paste.ubuntu.com:80/123115/ at syncbugbot for some backports (target is all intredpid, source is all jaunty).
[04:19] <LaserJock> heh, I get a kick out of the happycoders-emacs long description "This is a daily cvs snapshot". The Intrepid version is 2004.08.14
[04:21] <stgraber> :)
[04:21] <ScottK> Didn't say which day.
[04:22] <lws> Is this the channel for Jaunty questions?
[04:23] <stgraber> nope, that'd be #ubuntu+1
[04:23] <lws> oops
[04:35] <slangasek> superm1: new mythbuntu posted
[05:11] <superm1> slangasek,  bug 334341 is affecting several types of builds.  ive seen it on xubuntu and mythbuntu, looks like there are reports on normal ubuntu as well. affecting situations that you have existing partitions that get deleted i think.
[05:12] <slangasek> superm1: yes, that looks like errata material to me
[05:12] <superm1> slangasek, alrighty
[05:41] <dholbach> good morning
[06:55] <ebroder> Any backporters around who could look at bug #334538?
[06:55] <ebroder> I'm mostly wondering if there's anything else I should do to the patch
[07:10] <pitti> Good morning
[07:13] <StevenK> Morning pitti
[07:14]  * pitti hugs StevenK
[07:26]  * StevenK finally finishes processing removals
[07:32] <StevenK> bryce: Argh! I processed syncs like an hour ago!
[07:34] <pitti> StevenK: not for main, I hope? :-)
[07:34] <bryce> StevenK: no hurry
[07:34] <StevenK> Uhhhh
[07:34] <StevenK> I *think* they were all universe
[07:35] <bryce> these syncs are all for main - they're the silly little video drivers no one uses
[07:35] <StevenK> I saw, I just removed the silly little input drivers no one uses
[07:42] <tjaalton> StevenK: excellent, thanks :)
[07:43] <savvas> Riddell: I've just tested the patch for bug 190907 on kubuntu jaunty and it works as expected for Greek :)
[07:45] <bryce> tjaalton: sync req's filed - https://wiki.ubuntu.com/X/PackageNotes
[07:46] <tjaalton> bryce: cool
[07:46] <bryce> http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html updated
[08:03] <nikolam> Hi, can I use fridge calendar when calendar has moved to google calneda? Can I import ical calendar like before?
[08:06] <dholbach> nikolam: https://wiki.ubuntu.com/Fridge/Calendar
[08:06] <dholbach> there's even an ICAL link at the bottom of http://fridge.ubuntu.com/calendar
[08:07] <nikolam> dholbach, that is ical link?
[08:07] <dholbach> no
[08:07] <nikolam> liek I can import it inside Sunbird like before?
[08:07] <dholbach> it's linked from there
[08:07] <dholbach> linked from both pages
[08:08] <nikolam> So we don`t have ability to add ical link to applications, like sunbird etc, we need to go to google to see meetings?
[08:09] <dholbach> ?
[08:09] <dholbach> no... search for ical on the two links I gave you
[08:11] <nikolam> Ah http://www.google.com/calendar/ical/j5q85mmi6ujvjtii5s1n3li5io%40group.calendar.google.com/public/basic.ics
[08:11] <nikolam> I found it.
[08:11] <nikolam> It is working now :)
[08:14] <juanje> hi guys, may I make you a packaging question?
[08:14] <juanje> it's about the packages version
[08:15] <dholbach> sure
[08:15] <RAOF> juanje: #ubuntu-motu is likely to be a better place, but you can probably ask here.
[08:15] <juanje> if we (in guadalinex) make a version of one package from Ubuntu, how should be the version?
[08:15] <juanje> dholbach: thanks
[08:15] <dholbach> juanje: you could do it like we do... just add "guada1" :-)
[08:16] <juanje> that's waht we usually do, but seems too long
[08:16] <juanje> so something like 0.2-4ubuntu2guada1 could be ok?
[08:16] <dholbach> it's your distro, you can sure do it :-)
[08:17] <juanje> it's just to be sure, the upgrade of the version from the upstream (you) make sense
[08:18] <dholbach> if you decide to import 0.2-4ubuntu3 in the next release (and drop your changes because they're in Ubuntu or don't make sense anymore) the upgrade will just work
[08:18] <juanje> ok, we were doing like that but it's the kind of things we were not sure if was the better way
[08:18] <juanje> dholbach:  perfect
[08:19] <juanje> dholbach: thanks ;-)
[08:19] <dholbach> sure :)
[08:21] <juanje> RAOF: sorry for asking those things here, it was just because it is more derivative policy than packaging itself. But I'll join at #ubuntu-motu channel in case we have more technical questions :-)
[08:23] <RAOF> juanje: #ubuntu-motu is generally a better place for simple-ish packaging information; this is generally better for highly complex packaging, policy interactions, and such.  That said, now that I've seen the whole question, it's entirely appropriate here :)
[08:24] <juanje> RAOF: :-)
[08:25] <pitti> StevenK: just to make sure, did you also add arts to the sync blacklist?
[08:27] <StevenK> pitti: Indeed
[08:28] <StevenK> pitti: Along with everything else that I thought Debian wouldn't remove
[08:28] <pitti> StevenK: splendid, thanks
[08:30]  * dholbach hugs juanje and rcmorano
[08:30]  * dholbach hugs RAOF too
[08:30] <dholbach> hey seb128!
[08:30]  * dholbach hugs seb128 too
[08:30] <seb128> hello dholbach
[08:30]  * seb128 hugs dholbach
[08:31]  * RAOF hugs dholbach 
[08:31]  * juanje hugs dholbach
[08:31] <dholbach> :-D
[08:32] <juanje> hahaha.... how much love in this channel :-P
[08:32] <juanje> I like it
[08:32] <juanje> :-)
[09:18] <asac> pitti: so as expected a single proper shutdown should fix your "addons installed" issue
[09:18] <asac> i managed to reproduce after langpack update by using killall firefox-3.2 to shutdown
[09:18] <pitti> asac: yes, I expect that, too; I just wondered if I should keep it that way for debugging, or this is basically a "wontfix" issue
[09:23] <asac> pitti: not sure. looking at code it seems they disabled it on startup to avoid excessive IO
[09:24] <pitti> asac: ah, you mean the extension files are updated on shutdown?
[09:24] <asac> personally i would think that it should be disabled until all extensions are properly setup/registered
[09:24] <asac> pitti: yes. the extensions manifest is the problem here (extensions.cache) ... it has a mTime field for each addon
[09:24] <asac> that is flushed on shutdown only atm ... but i think thats a bug
[09:25] <asac> but its a bit hard to determine, when all extensions are properly updated during startup
[09:27] <pitti> asac: okay; sounds a bit like "wontfix" then
[09:28] <asac> i will look a bit more and bug upstream about it. seems that the code to flush on startup is actually there, but not reached. strange
[09:34] <cjwatson> ScottK: backports done; I assumed that you meant kde4-style-bespin rather than plasma-widget-xbar, since the former is the source package name
[10:08] <pitti> $ git reset  fdi/information/10freedesktop/10-modem.fdi
[10:08] <pitti> fdi/information/10freedesktop/10-modem.fdi: locally modified
[10:08] <pitti> argh, yes, that's exactly what I want to reset, you *censored*
[10:09] <ion_> IIRC, git checkout -- fdi/information/10freedesktop/10-modem.fdi
[10:09] <pitti> "git reset --hard" seems to have worked
[10:09] <pitti> but last time I did that, I couldn't push any more
[10:09] <pitti> well, let's see :)
[10:09] <cjwatson> yes, stupid program. you have to use one command to revert all changes in your tree and a different one to revert individual files.
[10:09] <pitti> ion_: thanks, will do that next time
[10:10] <pitti> I think next time I'll just do git diff | patch -Rp1 or so..
[10:10] <cjwatson> git checkout is the right thing to use here but is not exactly obvious
[10:11] <pitti> cjwatson: well, I first tried git revert, but its help says "If you want to throw away all uncommitted changes in your working directory, you should
[10:11] <pitti>        see git-reset(1)"
[10:11] <pitti> ah, "particularly the --hard option."
[10:13] <bryce> glad I'm not the only one that finds resetting git trees a bit confusing
[10:27] <cjwatson> kirkland: I would really appreciate a look at bug 327348 at some point; I keep wasting time due to it
[10:27] <apw> bryce, pitti, its just a perception thing
[10:27] <apw> resetting a tree to a particular point in history makes perfect sense
[10:28] <apw> if you perceive each point to be a snapshot of the world in time
[10:28] <apw> i want to reset the world to as it was 'then'
[10:28] <pitti> I just wanted to say "discard my uncommitted modifications"
[10:28] <pitti> I think "git reset --hard" does that
[10:28] <cjwatson> it's not just a perception thing; it's a bad UI design
[10:28] <apw> so you wanted to reset to the HEAD of the tree
[10:28] <apw> cjwatson, i don't think that is fair at all
[10:29] <apw> how do you do it in bzr
[10:29] <cjwatson> I do; I see people running into this frequently
[10:29] <cjwatson> 'bzr revert <file>'
[10:29] <apw> git checkout <file>
[10:29] <cjwatson> "I want to revert my changes. I know, I'll use bzr revert"
[10:29] <apw> would be the equivalent there
[10:29] <cjwatson> git revert even acknowledges that people might look there for this feature
[10:29] <cjwatson> in its manual pages
[10:29] <apw> i want the version of this file in head, i know i'll ccheck that one out
[10:29] <apw> its a perception thing in a lot of ways
[10:29] <cjwatson> actually it's git checkout -- <file>
[10:30] <cjwatson> AFAICT?
[10:30] <apw> well the -- thing is not necessary
[10:30] <cjwatson> I have seen git checkout fail when the -- is omitted
[10:30] <apw> unless the filename might clash with a vranch name
[10:30] <apw> branch name
[10:30] <cjwatson> this is a classic case of "user must adapt to fit tool"
[10:31] <cjwatson> I think it's entirely fair to criticise that
[10:31] <apw> its a classic case of if you are in the bzr mind set then the commands are not intuitive
[10:31] <cjwatson> it's not just bzr
[10:31] <apw> i find bzr revert reverting just one file just mad
[10:31] <apw> but that is cause i am in the git mind set
[10:31] <cjwatson> most other revision control systems have similar semantics
[10:31] <cjwatson> apw: huh?
[10:31] <cjwatson> apw: 'bzr revert <file>' -> revert one file. 'bzr revert' -> revert whole trtee.
[10:31] <cjwatson> tree.
[10:32] <apw> what does bz revert -r -4 do ?
[10:32] <cjwatson> revert whole tree to four revisions from end of branch
[10:32] <apw> right where as it _should_ (in my head) undo just -4
[10:32] <cjwatson> (working tree, not equivalent of the index)
[10:33] <apw> the only point i am making is the interfaces are different
[10:33] <apw> that doesn't make one or the other any righter
[10:33] <cjwatson> the point I am making is that it makes sense to optimise for common operations
[10:33] <apw> just the one you learn first is less wrong
[10:33] <apw> ok and which are the common ops that are not optimised ehre
[10:33] <cjwatson> "oh, shit, that change was completely wrong, let me throw it away rather than commit it" is a common operation
[10:33] <apw> git checkout -f
[10:33] <apw> would be undo everything
[10:33] <pitti> I'd also think that "commit all my changes" is more common than "commit nothing"...
[10:33] <cjwatson> I give up :)
[10:33] <bryce> I dunno, I learned git first and found it confusing before I ever heard of bzr.  I was skeptical of bzr, but now I know it... I still find git syntax confusing.
[10:34] <cjwatson> git just fails to realise that brain-compatibility with other systems is important
[10:34] <apw> bryce, but what did you use before
[10:34] <apw> or was git really your first ?
[10:34] <bryce> apw, rcs, cvs, clearcase, svn
[10:34]  * pitti still painfully remembers arch
[10:34] <apw> cjwatson, i personally seem to be able to use both now (git and bzr) and mostly get by
[10:34] <apw> bryce, so you git wasn't your first
[10:34] <apw> cvs really was
[10:35] <bryce> yep
[10:35] <cjwatson> just like thousands of other developers
[10:35] <apw> so that confusion is to be expected, and bzr to be less confusing as its closer
[10:35] <cjwatson> you can't just discount the "migrating from cvs" case
[10:35] <apw> yep.  but we adapt, we learn
[10:35] <bryce> apw, if you argue that git makes sense for people who have never used a vcs, I will laugh ;-)
[10:35] <cjwatson> tools adapt to me
[10:35] <apw> i am not trying to
[10:35] <apw> i am trying to argue, that its a matter of subbing in the right commands for the concepts
[10:36] <apw> like when you program in perl you use $()(%)(%()$ and in C you use something else
[10:36] <apw> you have to tranlate from 'if constuct' to a command line
[10:36] <apw> and you do thast for every tool you use
[10:36] <cjwatson> you see, I don't want to learn a VCS
[10:36] <cjwatson> I use a VCS to get my work done
[10:36] <james_w> I think the confusing thing is that "reset" works for the whole tree case
[10:36] <apw> i don't want to learn a proigramming language
[10:36] <Mithrandir> cjwatson: the same argument can be made for editors and programming languages.
[10:37] <cjwatson> therefore, in a VCS, working like other VCSes is a desirable attribute
[10:37] <Mithrandir> you generally don't want to learn tools.
[10:37] <cjwatson> Mithrandir: I don't agree for programming languages, because their expressiveness is much more important
[10:37] <apw> git and bzr are almost indistiguisable at the semantic level
[10:37] <cjwatson> Mithrandir: for editors I entirely agree which is why I learnt one ten years ago and never change
[10:37] <apw> just the commands differ in construction
[10:37] <apw> same as programming in two languages
[10:37] <james_w> because it is "revert" in most other systems, that's where people go first, and it does something different, but tells them about reset, which does whole trees. Then you try and do a single file and get a really confusing error message.
[10:37] <apw> find the commands that work and you are set
[10:38] <james_w> if "revert" pointed to "checkout" then that may be improved
[10:38] <apw> james_w, probabally it should point to checkout really
[10:38] <cjwatson> programming in two languages is completely different; languages are well-known to have widely different expressive properties (at least if you're considering them at a level above Turing machines)
[10:38] <apw> james_w, ack
[10:38] <Mithrandir> cjwatson: I guess I'm weird in that I use different tools for different things, then. :-)  (I use both vi and emacs)
[10:38] <james_w> and if the error messages where better then it would be easier to learn. Generally they give you no clue as to what you did wrong.
[10:38] <apw> cjwatson, well on that i dissagree.  i use the same bit of my brain to convert between git and bzr
[10:39] <apw> james_w, yeah can't argue that some of the errors are unhelpful
[10:39] <cjwatson> apw: look, I'm not trying to argue that any one system is perfect; you can look at my list of bugs filed on bzr if you like ...
[10:39] <apw> anyhow, don't get the impression i think git is any better or worse
[10:39] <cjwatson> apw: but I'm getting really tired of people saying that git UI bugs aren't bugs
[10:39] <apw> i am trying to argue they are the same, but suttly different
[10:40] <cjwatson> in that respect I prefer the bzr attitude which is, IME, "oh, it didn't do what you expected. hmm. how can we improve that?"
[10:40] <apw> well you are stating that any ui difference from a cvs is a bug
[10:40] <cjwatson> no, absolutely not!
[10:40] <cjwatson> where did I say that?
[10:40] <cjwatson> I'm saying that some level of similarity is desirable
[10:40] <apw> thats the same thing just more subtle :)
[10:40] <cjwatson> I don't want to have to type bzr -nq up to find out what the changes in my tree are
[10:41] <cjwatson> but I do want to not have to remember a completely different lexicon of verbs for absolutely everything
[10:41] <cjwatson> I don't think that's unreasonable
[10:41] <cjwatson> if git people actually acknowledged UI bugs I would be a lot happier with it
[10:42] <cjwatson> but everyone gets all defensive
[10:42] <apw> the problem is that most of the issues come from the commands in both being the same name
[10:42] <RAOF> "Where there's no compelling reason to be different, being different from is a bug" would be a reasonable rephrasing of this sentiment, I think.  Is that clearer?
[10:42] <cjwatson> RAOF: yes
[10:42] <apw> its not possible to 'fix' that without being incompatible with older releases
[10:42] <apw> and that is the compelling reason at this stage, revert is different and making it the same would break the userbase
[10:42] <cjwatson> apw: actually, fixing the error messages would help too
[10:43] <apw> that is why they get defensive
[10:43] <james_w> apw: I think that being more forgiving when these common issues are hit would go a long way to alleviating the problem, and wouldn't break compatibility
[10:43] <cjwatson> in this particular case, if you use the wrong one, the error messages are incomprehensible
[10:43] <apw> and as far as can see thing do improve with every release
[10:43] <apw> cirtainly i get more human readble stuff with every version
[10:43] <cjwatson> apw: so you mentioned that git checkout does different things depending on whether you give it something that looks like a branch or something that looks like a file
[10:43] <cjwatson> apw: why can't git revert do that?
[10:44] <james_w> it is improving, but the developers are unwilling to fix some things
[10:44] <apw> if you want to point out the ones you hate and find hard to grok to me message wise
[10:44] <apw> then i'll try and get them fixed
[10:44] <cjwatson> its argument is a commit id
[10:44] <cjwatson> it could easily say "oh, that's a filename, you meant git checkout -- <file>, I'll do that"
[10:44] <apw> cjwatson, i suspect it could, and that might well be a reasonable thing
[10:44] <apw> though
[10:44] <apw> as revert here means "undo what was done in commit N"
[10:45] <apw> then git revert HEAD -- debian/changelog
[10:45] <cjwatson> "git revert <filename>" is not ambiguous
[10:45] <apw> _should_ mean undo the changes to devian/changelog in head
[10:45] <apw> which is not the same as make the working tree match HEAD
[10:45] <apw> ie not what it means in bzr
[10:46] <cjwatson> I'm not after an identical interface
[10:46] <apw> right, but to add the semantic you want would be to add
[10:46] <cjwatson> I want an interface that DTRT when it is unambiguous and gives me helpful output when it isn't
[10:46] <apw> a semantic that makes no sence in the meaning of the command
[10:46] <apw> that is a little unepexected
[10:46] <cjwatson> (by and large I already have such an interface so I am undermotivated to fix git, but ...)
[10:46] <apw> and would prevent that command ever undoing part of an old commit
[10:47]  * apw goes paint his bikeshed a different colour
[10:47] <cjwatson> "git revert HEAD -- debian/changelog" != "git revert debian/changelog"?
[10:47] <cjwatson> surely
[10:47] <cjwatson> if you've explicitly specified a commit id there then you're clearly in a different mindset
[10:48] <apw> most commands work on HEAD if nothing is specified
[10:48] <cjwatson> TBH I suspect the only way to get to B from A is to have a completely different command-line frontend
[10:48] <apw> so it would mean the same
[10:48] <cjwatson> which seems a bit of a waste of effort
[10:48] <cjwatson> cogito died
[10:49] <apw> yeah it did
[10:49] <apw> i am lucky i just learn the mappiing and carry on
[10:49] <cjwatson> apw: BTW, the reason I'm not diligently filing bugs about everything I find unintuitive is that Linus has explicitly said that he deliberately made it different to break hardcoded expectations
[10:49] <broonie> You do need a different front end - see the git archives, this has been discussed ad infinitum.
[10:49] <cjwatson> apw: which basically says "sod off, not interested in your bugs"
[10:50] <apw> cjwatson, it is entirly true that git being linus' baby is not good for git nor its users
[10:50] <apw> tooo big a personality
[10:51] <broonie> cjwatson: That's not so much the case any more - apart from anything else Linus isn't the maintainer any more.
[10:51] <apw> yeah junio is better for sure
[10:51] <apw> anyhow ... sorry to waste so much time on that bikeshed.  they differ, sorry
[10:51] <broonie> Most of the stuff that doesn't get changed is difficult to change.
[10:52] <apw> we should get some more help in the mans for sure
[10:52] <cjwatson> broonie: sure, but now it's all deeply hardcoded and as apw says a pain to change for compatibility reasons
[10:52] <cjwatson> so I might as well just use a system I like instead
[10:52] <cjwatson> but I hate sitting still for bugs
[10:52] <broonie> The stuff that "is difficult to change", yes. Though much of the stuff that people don't like is in error handling so there's plent of room for doing better.
[10:57] <maco> between apw and Keybuk, i'm getting really excited about the fact that my new job requires using git!
[10:58] <apw> heheh you'll either love or hate it
[11:00] <broonie> It's gorgeous for working on the kernel (or other projects that use it well).
[11:01] <maco> i dont even want to find out how long bzr would take to do a merge on the kernel source
[11:02] <Keybuk> maco: that's one of those "heat death of the universe" type events
[11:02] <maco> hmm?
[11:03] <Ng> maco: "longer than the rest of time"
[11:03] <maco> ah
[11:03] <maco> gotcha
[11:04] <BUGabundo> pitti: ping
[11:04]  * Ng shrugs, bzr not being suited to heavy kernel work is largely irrelevant if you start with the basic premise that git and bzr and others are not equivalent, and that one size demonstrably can't fit all :)
[11:04] <pitti> !ping | BUGabundo
[11:04] <pitti> meh, can someone please fix ubottu to say something sane about contentless pings?
[11:04] <pitti> BUGabundo: hi
[11:05] <BUGabundo> pitti: is this known '? http://paste.ubuntu.com/123251/
[11:05] <BUGabundo> looking at LP, I see too many, not sure it's a dupe
[11:05] <maco> Ng: they're just not making learning to use it sound very pleasant. my grand total experience with it included dtchen sitting next to me telling me which commands let me generate a changeset
[11:06] <BUGabundo> maco: ahh?
[11:06] <maco> BUGabundo: git
[11:06] <Ng> maco: I've uesd git about twice ever. I'm not a hardcore developer, it just doesn't make sense for me to use it, and none of the projects I interact with use it, so *shrug*
[11:07] <maco> BUGabundo: im sure you've seen Keybuk's git rants, and apw just had one of his own
[11:07] <pitti> BUGabundo: no, please file a bug against apport and assign it to me
[11:08] <BUGabundo> doing so now
[11:08] <apw> maco, i wasn't ranting.  i was just trying to say they are differnt stop comparing them
[11:08] <apw> i am not trying to change either, i just use them both and accept their esentricities
[11:08] <BUGabundo> pitti: bug 334823
[11:09] <BUGabundo> assigned
[11:09] <BUGabundo> bye
[11:11] <Keybuk> apw: I use them most and hate their eccentricities ;)
[11:11] <Keybuk> use them both, I mean
[11:11] <apw> tollerance comes with age :)
[11:18] <StevenK> Oooh, apw had a git rant?
[11:18] <StevenK> Sorry I missed it ....
[11:18] <apw> heh, na, maybe
[11:20] <apw> Keybuk, is there a bzr equivalent of gitk ??
[11:20] <cjwatson> yes, 'bzr vis' in the bzr-gtk package
[11:20] <apw> cool
[11:21] <cjwatson> though bug 283832 is a tad annoying after installing bzr-gtk
[11:22] <james_w> apw: qbzr's qlog is apparently superior to "bzr vis"
[11:23] <james_w> but bzr gannotate is miles better than anything I have seen
[11:23] <apw> nng
[11:23] <james_w> the "back" button is genius
[11:25] <StevenK> cjwatson: Oh, that reminds me. You told me at the sprint that you've bent vi to your will in terms of coding Python. Do you have a sec to dig through your config for the magic?
[11:26] <apw> cjwatson, oooo is that modes to do the spacing right?  please, pretty please?
[11:26] <cjwatson> I think it's just:
[11:26] <cjwatson> augroup myauto
[11:26] <cjwatson>     au FileType python  setlocal tabstop=8 softtabstop=4 shiftwidth=4 expandtab
[11:26] <cjwatson> augroup END
[11:27] <StevenK> apw: I think you used up all of your brownie points with the git discussion :-P
[11:27] <cjwatson> though I also set these globally, which might be relevant: set autoindent; let python_highlight_all = 1; filetype indent on; filetype plugin on; syntax on
[11:27] <Ng> bah, bzr vis just seems to explode for me
[11:27] <apw> StevenK, quite probabally
[11:27]  * Ng blames PPA versions of bzr
[11:27] <pitti> apw: I also find this very helpful:
[11:28] <pitti> autocmd FileType python :set smartindent cinwords=if,elif,else,for,while,try,except,finally,def,class
[11:28] <StevenK> Ng: I find blaming lifeless to be very helpful, since then he turns up and argues.
[11:28] <pitti> apw: then you type something like "def foo:", press enter, and automatically get indentation
[11:28] <Ng> StevenK: haha
[11:28] <cjwatson> StevenK: http://www.chiark.greenend.org.uk/~cjwatson/tmp/vimrc is my whole .vimrc in case that's useful
[11:28] <apw> pitti, yeah not so keen on things doing that for me, but the spacing thing being sane :)
[11:29] <StevenK> Ah, excellent.
[11:29] <cjwatson> there is a little bit of ancient cruft there ;)
[11:29] <apw> thanks cjwatson that seems to be the incantation
[11:29]  * StevenK tries to stop his eyes bleeding, since .vimrc syntax hurts
[11:29] <cjwatson> yeah, it's painful
[11:29] <cjwatson> I'm by no means a master
[11:29] <pitti> while we are on the subject of tweaking vim, does anyone know how to stop vim from putting "*" in front of lines automatically? this drives me mad in multi-line debian/changelog entries
[11:29]  * pitti 's .vimrc is 317 lines...
[11:30]  * evand equally on gq
[11:30] <apw> pitti, whats the symptom, add a * foo and when it wraps it add * again?
[11:30] <StevenK> pitti: Heh, mine is 10
[11:30] <cjwatson> pitti: that'll be something to do with 'comments' I'd have thought
[11:30] <apw> i don't get that by default
[11:30] <pitti> apw: right
[11:30] <pitti> it tries to DTRT for C comments
[11:30] <apw> i don't think i get that
[11:30] <pitti> /* foo
[11:30] <pitti>  *... continue
[11:30] <cjwatson> you could 'au FileType debchangelog setlocal comments='
[11:31] <cjwatson> although that probably isn't quite what you want
[11:31] <pitti> I have
[11:31] <pitti> autocmd FileType debchangelog :set nofoldenable
[11:31] <pitti> right, I'll try that
[11:31] <cjwatson> how about 'au FileType debchangelog setlocal comments=bf:*'
[11:31]  * apw hands cjwatson a black-belt in vim foo
[11:31] <cjwatson> BTW I don't see this and don't customise debchangelog at all; maybe you have some global configuration here?
[11:32] <pitti> cjwatson: may thanks, that's it
[11:32] <StevenK> apw: I think Colin made his own ... using vi
[11:32] <cjwatson> comments=bf:<leader> is in my muscle memory because it's how you get bullet-point lists to work sanely
[11:33] <pitti> cjwatson: I don't think I ever touched it (http://people.ubuntu.com/~pitti/scripts/vimrc)
[11:33]  * apw adds that to his catalogue of vi magic
[11:33] <pitti> maybe it's smartindent
[11:33] <cjwatson> pitti: ah, I think 'filetype plugin on' arranges for debchangelog to fix this itself
[11:33] <StevenK> OW, pitti has *fuctions* in his .vimrc
[11:34] <cjwatson> have a look in /usr/share/vim/vimcurrent/ftplugin/
[11:34] <pitti> yeah, most of it is LaTeX stuff
[11:34] <cjwatson> using ftplugin saves a lot of reinvention IME
[11:34] <pitti> cjwatson: right, debchangelog.vim has setlocal comments=f:* there
[11:35] <pitti> at some point I need to clean up my .vimrc cruft, indeed
[12:11] <s0u][ight> weird
[12:14] <s0u][ight> cjwatson, what were the 2 apps you recommended me to build live cd's? livecd-rootfs and...
[12:14] <cjwatson> I explicitly didn't recommend them to you :-)
[12:14] <cjwatson> I said that they were what we used; they're designed for automation rather than for people to use to build their own
[12:15]  * directhex explicitly recommends not eating yellow snow
[12:15] <cjwatson> s0u][ight: which updated images was it you were looking for?
[12:16] <s0u][ight> cjwatson, i wasn't looking for some updated iso, i was recommending you guys to build frequently new ones
[12:16] <s0u][ight> because after some time you get amazing downloads like 200 MB right after installation
[12:16] <cjwatson> s0u][ight: which release?
[12:17] <cjwatson> I am happy to do occasional one-offs
[12:17] <directhex> any release where an OOo update exists, at a guess
[12:17] <s0u][ight> yes
[12:18] <cjwatson> we don't have disk space on the machines in question to do it all the time
[12:18] <cjwatson> and it would tend to interfere with other things - but I can do it occasionally when nothing else is going on
[12:19] <cjwatson> I've kicked off hardy and intrepid live CD builds now
[12:19] <s0u][ight> cjwatson, it is not a personal request, just something that would be another + for ubuntu
[12:20] <s0u][ight> btw cjwatson i'm curious about the way ubuntu live cd's are made (from scratch)
[12:21] <cjwatson> s0u][ight: that turns into a personal request in the end *shrug*
[12:21] <s0u][ight> cjwatson, last time i installed a new distribution from a live cd was like ... a year ago or something :D
[12:22] <s0u][ight> but i'm helping people around in #ubuntu-tr and often people go like, just installed ubuntu and already this much of updates
[12:22] <cjwatson> s0u][ight: so, first, remember that we build images for several different architectures, so it clearly can't all be done on one machine; that's why we split the automation into two pieces
[12:23] <cjwatson> s0u][ight: livecd-rootfs builds the appropriate live filesystem for a single architecture, and http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ (and the other bits listed in configs/devel in there) deals with building the ISO out of that
[12:23] <cjwatson> s0u][ight: it's not delivered in a nicely packaged form AT ALL, and most people don't need this extra sophistication; they just want a quick build for their current architecture
[12:24] <cjwatson> so generally speaking I discourage people from using it because I don't particularly want to end up putting in the effort to turn it into a nicely-packaged thing
[12:24] <cjwatson> the customisation workflow is much easier for most people
[12:25] <s0u][ight> i still have to learn so much more ...
[12:25] <cjwatson> but it isn't appropriate for running daily builds every day for years; and once you have the infrastructure set up to do *that* then you might as well use it ...
[12:25] <s0u][ight> daily would be too often but like with each about 100 MB of updates
[12:26] <cjwatson> stop focusing on the "daily" bit
[12:26] <cjwatson> pretend I said "regular" if you like
[12:27] <s0u][ight> let them just get the updates themselves :D
[12:28] <cjwatson> they're going to have to update eventually anyway. most people are not going to want to reinstall their system every couple of months from a CD, and it would be less efficient to do so anyway
[12:28] <cjwatson> our package archive infrastructure is much more efficient and distributed than our CD image infrastructure, and we'd rather people used the former in general
[12:29] <s0u][ight> ok :-)
[12:29] <cjwatson> having CD images every six months at release means that those can be burned to physical media, sent out to people, etc., which is much better than them thinking that they have to download 700MB in order to do an installation
[12:29] <cjwatson> it's important to think beyond the initial update, I think
[12:30] <s0u][ight> cjwatson, i get the point :)
[12:30] <s0u][ight> thanks for all the effort to convince me :D
[12:31] <cjwatson> new images will show up in a bit at http://cdimage.ubuntu.com/hardy/daily-live/ and http://cdimage.ubuntu.com/intrepid/daily-live/ ... that is, if they don't fail
[12:31] <s0u][ight> cjwatson, i would like to convince you using firefox with wine, runs much smoother :D
[12:31] <s0u][ight> i'm off now laters
[12:31] <cjwatson> *blink* how about "no"
[12:34] <directhex> metacity and nautilus suck, can we use explorer in wine while we're at it?
[13:05] <mdz> Keybuk: are you still having some mysterious I/O related issue on Jaunty, and if so, what's the bug number?
[13:05] <mdz> (you mentioned some I/O performance issue at the sprint IIRC)
[13:44] <lamont> pitti: 334410 sure doesn't look like a postfix bug to me...
[13:54] <kirkland> cjwatson: looking at bug #327348
[13:55] <kirkland> cjwatson: are you seeing this in kvm-84 as well?
[13:57] <kirkland> cjwatson: there's some changes in 1:84+dfsg-0ubuntu3 that could affect this
[14:03] <IntuitiveNipple> kirkland: Is there a reason VDE isn't enabled in kvm?
[14:07] <smb_tp> bug 318978
[14:07] <kirkland> IntuitiveNipple: good question ...  i don't know why that's no longer enabled
[14:08] <kirkland> IntuitiveNipple: i'll check upstream
[14:08] <smb_tp> -WRONGCHAN
[14:08] <IntuitiveNipple> It is auto... but we don't build-depends on it
[14:08] <kirkland> IntuitiveNipple: i still an an email in my inbox from you, i'm sorry, i've been swamped
[14:08] <mvo> doko: is "XS-Python-Version: current" still ok to use?
[14:09] <IntuitiveNipple> kirkland: That's the one :) bug # 253230
[14:09] <kirkland> IntuitiveNipple: aha :-)
[14:09] <IntuitiveNipple> bug #253230
[14:09] <IntuitiveNipple> (helps to avoid spaces :)
[14:09] <kirkland> IntuitiveNipple: okay, let me dive into it right now
[14:09] <cjwatson> kirkland: I encountered it today with kvm 1:84+dfsg-0ubuntu3
[14:09] <kirkland> cjwatson: :-/  okay, how are you launching the vm?
[14:09] <doko> mvo: what for?
[14:09] <cjwatson> kirkland: just kvm from the command line, only options are -m -hda -cdrom
[14:10] <kirkland> cjwatson: okay, and just to be clear, it won't accept keyboard input?
[14:10] <kirkland> cjwatson: because that's how i run, and the screen will go all goofy sometimes (that i'm still working on)
[14:10] <cjwatson> kirkland: it accepts it, but it's as if a modifier key is stuck
[14:10] <mvo> doko: update-manager, I'm merging your ppa changes into the bzr tree
[14:10] <cjwatson> kirkland: either ctrl or alt
[14:11] <cjwatson> kirkland: so I can change ttys, but not actually type into them, and I occasionally see indications that it's seeing metacharacters rather than the characters I meant to type
[14:11] <kirkland> cjwatson: this only happens when running the installer?
[14:11] <Keybuk> cjwatson: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=3d3a0a709a38805259fe07240c3ca47a120dd5d6
[14:11] <cjwatson> it could be something to do with the order I press and/or release ctrl and alt when getting kvm to release focus?
[14:12] <cjwatson> kirkland: IME yes, but that means very little since I almost exclusively use kvm for installer testing ...
[14:12] <doko> mvo: IMO you should set it to all, then the symlinks are created for both 2.5 and 2.6. for private modules, current/all doesn't make a difference
[14:12] <cjwatson> Keybuk: thanks!
[14:12] <kirkland> cjwatson: okay, i'm pulling today's iso and i'll try to test
[14:12] <Keybuk> mdz: http://bugzilla.kernel.org/show_bug.cgi?id=12309
[14:13] <cjwatson> kirkland: I don't *think* that the guest is doing anything particularly special here; it's not changing the keyboard layout at the relevant time or anything
[14:17] <kirkland> IntuitiveNipple: okay, i think that build depends is correct, i'm building/testing now
[14:17] <IntuitiveNipple> kirkland: Yeah, it builds fine (for me) in pbuilders. I've been adding it manually up to now
[14:26] <AnAnt> quadrispro: Hello, I wanted to ask you about gpm
[14:27] <AnAnt> quadrispro: regarding "Add -D_GNU_SOURCE to CFLAGS, fixes FTBFS." in gpm, I am compiling gpm 1.20.6 without -D_GNU_SOURCE in intrepid & jaunty, and it does work
[14:36] <pitti_live> bryce: FYI, just trying current amd64 desktop on my wife's computer (rv630); as expected, I don't get DRI and composite; video playback fullscreen (1920x1600) is not really usable (way too slow)
[14:36] <pitti_live> bryce: is xv related to DRI nowadays? do you know whether the next ati driver will support better xv?
[14:37] <seb128> I can't play videos on my ati r6xx desktop either
[14:38] <seb128> I can't play videos on my ati r6xx desktop either, way too slow
[14:38] <seb128> pitti_live: btw bug #326029 is your camera issue
[14:39] <kirkland> IntuitiveNipple: good fix ;-)
[14:39] <pitti_live> seb128: ah, I wanted to ask you about the "master" bug for that issue a few hours ago (but you were offline)
[14:39] <kirkland> IntuitiveNipple: i'll upload as soon as the alpha freeze is over
[14:39] <pitti_live> seb128: I reassigned a gnome-moutn bug to gvfs, will dup that then
[14:39]  * pitti_live goes back to his workstation
[14:39] <IntuitiveNipple> kirkland: many thanks... that'll make some people happy... I've just moved away from VDE to using tap and routing
[14:40] <seb128> pitti_live: the gnome session bug you have with theming is gnome bug #567958 which is a 2.26 blocker
[14:40] <kirkland> IntuitiveNipple: yeah, i try to use as many different networking options as possible for testing
[14:40] <kirkland> IntuitiveNipple: and i noticed vde broke at some point, but hadn't had time to circle back
[14:41] <kirkland> IntuitiveNipple: if you have any other golden kvm fixes, i'm all ears :-)
[14:41] <IntuitiveNipple> kirkland: yeah, I know how it is.
[14:41] <pitti> seb128: thanks
[14:41] <seb128> pitti: you're welcome
[14:41] <IntuitiveNipple> kirkland: Not right now, it's behaving really well.
[14:41] <IntuitiveNipple> kirkland: But I hack on it occassionally so I'll be sure and let you know :)
[14:42] <kirkland> IntuitiveNipple: please do.  sorry for the initial delay in response
[14:42] <pitti> seb128: so should bug 274889 be linked to that gnome bug?
[14:43] <IntuitiveNipple> kirkland: that's okay
[14:43] <seb128> pitti: no, that's different issues, yours is about the icons being used which was already a bug in intrepid
[14:43] <seb128> pitti: the jaunty issue is just that xsettings are not applied, ie no theming
[14:44] <seb128> pitti: yours will make it buggy when using other icon themes, the jaunty issue once fixed will make it correct with the default theme
[14:47] <pitti> seb128: okay, understood; so we need to fix bug 277309 (which is the master for 274889 AFAICS) ourselves?
[14:47] <seb128> pitti: right since that's distro change
[14:47] <seb128> pitti: the dialog is not the upstream one but the opensuse one
[14:51] <pitti> seb128: is that on your radar, or shall I find someone else?
[15:01] <pitti> bryce: for bug 304871, do you think it's possible to switch to XAA on a per-model/chip basis?
[15:10] <ccm> can somebody please have a look on https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/216292
[15:10] <kirkland> cjwatson: has the keyboard drop issue happened for you in the graphical installer?
[15:10] <ccm> the guy rants and confirms his own bug
[15:11] <cjwatson> kirkland: I can't say for sure
[15:11] <kirkland> cjwatson: okay, i'll test it both ways
[15:12] <cjwatson> ccm: what's wrong with his report? It may not be how it works right now but it seems a completely reasonable request.
[15:12] <cjwatson> ccm: he deserves an answer from a developer of the software; I recommend forwarding the bug rather than looking for reasons to close it
[15:12] <cjwatson> ccm: I'm not at all surprised that the bug reporter is upset
[15:13] <cjwatson> I have added a bug comment to that effect
[15:15] <ccm> cjwatson: actually all command line options on aptitude are not for interactive mode
[15:15] <cjwatson> ccm: ... and a further comment noting that the Debian developer, a.k.a. the upstream author, has accepted the bug
[15:15] <cjwatson> ccm: when developers accept bugs, bug triagers should leave them alone
[15:15] <cjwatson> ccm: they aren't right now, but the bug reporter is absolutely right that this is an error
[15:16] <ccm> cjwatson: than i have a different definition of an error when this is documented and intended behaviour
[15:16] <ccm> cjwatson: so you count user experience first?
[15:17] <cjwatson> ccm: firstly, I count the upstream author having accepted the bug as evidence that people should stop looking for reasons to close it
[15:17] <cjwatson> ccm: secondly, something being documented behaviour is *not* in general a reason to close it
[15:18] <cjwatson> ccm: the bug is a request for the behaviour to be changed, and "it's documented that way" is a completely irrelevant objection
[15:18] <ogra> cjwatson, the localechooser workaround isnt in the archive yet, right ?
[15:18] <cjwatson> ogra: correct, due to milestone freeze
[15:18] <ccm> cjwatson: okay
[15:18] <ogra> right, davidm just asked me if we could get it in as a post A5 exception to publish a working A5 slug image
[15:18] <ogra> since 30h installs are not really feasable
[15:19] <cjwatson> ogra: there is no need for an exception; it's not a feature
[15:19] <Keybuk> cjwatson: found a random console-setup bug ;)
[15:19] <ogra> (that would mean a post freeze upload of d-i aith immediate ublishing of the resulting slug image i think
[15:19] <Keybuk> debootstrap hangs on it when installing into a chroot ...
[15:19] <ogra> )
[15:20] <Keybuk> ... if you have scroll lock on for the actual physical console of that machine
[15:20] <ogra> *with immediate publishing
[15:21] <ccm> cjwatson: actually i did not get the accepted message fromthe debian right away - need to look there more carefully, thanks again
[15:24] <ogra> cjwatson, point is that i need to find a way to get that fix into an A5 image for the slug ... i'm not really sure how we can do that
[15:24] <ogra> without breaking the rules
[15:32] <IntuitiveNipple> Is this a version comparison problem? "xserver-xorg-input-elographics: Depends: xserver-xorg-core (>= 2:1.4.99.905) but it is not going to be installed"
[15:32] <IntuitiveNipple> xserver-xorg-core: Installed: 2:1.5.99.902-0ubuntu7
[15:33] <cjwatson> Keybuk: blink. interesting
[15:33] <cjwatson> ogra: how about we just build a modified image and stick it on people.ubuntu.com?
[15:33] <Keybuk> cjwatson: the postinst tries to call setupcon
[15:33] <Keybuk> which echos > /dev/console
[15:33] <ogra> davidm, ^^^^
[15:33] <ogra> would that suffice ?
[15:33] <Keybuk> which will block on scrolling
[15:34] <cjwatson> IntuitiveNipple: might not be for quite the reason it says, try 'sudo apt-get install xserver-xorg-input-elographics xserver-xorg-core'
[15:34] <IntuitiveNipple> cjwatson: thanks; will-do
[15:34] <davidm> ogra, if there is an image and we point at it from the A5 page I'm happy
[15:34] <ogra> hmm
[15:34] <IntuitiveNipple> cjwatson: Interesting: "xserver-xorg-core: Conflicts: xserver-xorg-input-2.1"
[15:35] <cjwatson> Keybuk: that's actually very odd, because setupcon isn't supposed to do that in the modes in which it's run by the postinst
[15:35] <cjwatson> Keybuk: we run setupcon --save-only; setupcon --force -k
[15:35] <ogra> i wonder if we can do that
[15:35] <cjwatson> ogra: yes
[15:35] <ogra> ok :)
[15:35]  * ogra loves clear short staements :)
[15:35] <ogra> *statements
[15:36] <cjwatson> Keybuk: the echo to /dev/console is (effectively) if [ "$keyboard_only" != yes ] && [ "$save_only" != yes ], so one of those should fail for each of those two commands
[15:36] <tjaalton> IntuitiveNipple: it probably isn't built (FTBFS) against the new xserver
[15:36] <liw> when should the installer automatically create a separate /boot? can it detect if the bios is going to have problems with the kernel not being in the first 8 gigs?
[15:36] <tjaalton> *ABI
[15:37] <cjwatson> liw: I've never worked out how to detect that
[15:37] <IntuitiveNipple> tjaalton: ahhh... I'll go look :) thanks.
[15:37] <Keybuk> cjwatson: it was quite clearly hanging on an echo ;)
[15:37] <cjwatson> liw: I've always been reluctant to do it all the time, because creating more partitions tends to cause further problems :-/
[15:38] <IntuitiveNipple> tjaalton: Yeah.. FTBFS all the way :)
[15:38] <liw> cjwatson, that's fair enough, I guess; stupid hardware with idiotic limitations...
[15:39] <cjwatson> Keybuk: oh, I'm not saying you're wrong, I just can't see why off the top of my head ...
[15:40] <bluesmoke_> wow, there is hardware that can only boot a kernel from the first 8GB on the drive?
[15:40] <tjaalton> IntuitiveNipple: trivial to fix though
[15:41] <IntuitiveNipple> tjaalton: I was just about to research it - newer upstream source package maybe?
[15:41] <tjaalton> IntuitiveNipple: no, it's not fixed upstream yet
[15:41] <IntuitiveNipple> tjaalton: OK, just patch ours for now, then?
[15:42] <tjaalton> IntuitiveNipple: ye
[15:42] <tjaalton> s
[15:43] <cjwatson> bluesmoke_: there are lots of such limitations; see the Large-Disk-HOWTO
[15:44] <tjaalton> IntuitiveNipple: actually, it _is_ fixed upstream
[15:45] <IntuitiveNipple> tjaalton: yippee! saves me some brain-strain :)
[15:46] <IntuitiveNipple> tjaalton: "xf86-input-elographics-1.2.3" branch?
[15:46] <moquist> slangasek: 'apt-get install postgresql-server moodle' doesn't work. Installing postgresql-server completely and then installing moodle works. (same for mysql) I'm thinking that if I add a preinst to moodle to make sure that at least one of postgresql or mysql is ready to go, then I can display a debconf note and bail before most of a doomed moodle installation happens.
[15:46] <tjaalton> IntuitiveNipple: tag, but yes
[15:47] <IntuitiveNipple> I'll give it a try
[15:47] <moquist> slangasek: But if mysql is ready to go and the user specifies postgresql, then this still needs to be caught in postinst. So I'd like to put these check_mysql() and check_pgsql() functions in a library that both preinst and postinst source.
[15:47] <apw> cjwatson, the installer kernel, that kernel is built from the same source as the kernel on the image right?
[15:47] <moquist> slangasek: do you have any objections or advice about my idea?
[15:47] <cjwatson> apw: it is the same kernel, bit-for-bit
[15:48] <apw> if there had been an abi buimp, could it have been missed?
[15:48] <cjwatson> apw: the vmlinuz, anyway
[15:48] <cjwatson> apw: which release?
[15:48] <apw> hardy
[15:48]  * pitti "meh"s at launchpad which broke p-lp-bugs again
[15:48] <pitti> and thus apport retracers
[15:48] <cjwatson> I only recently uploaded a d-i for 2.6.24-24 and I don't think that's been approved yet, but I'm not sure this is your problem ...
[15:48] <cjwatson> apw: what's the symptom here?
[15:48] <james_w> pitti: you assesed launchpadlib for that task I believe?
[15:49] <pitti> james_w: thekorn even created a branch for that
[15:49] <pitti> but it doesn't work on ronne, supposedly due to weird firewall configuration
[15:49]  * pitti asks about that RT again
[15:50] <apw> cjwatson, not 100% sure if there is an issue or not yet, a claim of missmatch but not sure ... the incoming information is currently not 100% clear yet
[15:54] <thekorn> pitti, where is it broken, can you give me a traceback or something?
[15:55] <cjwatson> apw: this sort of thing is sometimes due to people trying to use current images against outdated mirrors; I can probably help with more detail
[15:55] <pitti> thekorn: http://paste.ubuntu.com/123389/
[15:56] <thekorn> pitti, bug 327620
[15:57] <thekorn> don't ask me why I did not merge the fix into trunk
[15:57] <pitti> thekorn: splendid, thanks
[15:58] <LaserJock> slangasek: I see Edubuntu is rerolled, testing now
[15:59] <Adri2000> Keybuk: seen my query? ;)
[16:01] <NCommander> does anyone know where on cdimage lpia hardy images are?
[16:01] <NCommander> (if they even exist)
[16:05] <LaserJock> mvo: I've noticed that with the addon CD nautilus is started up as well as well as the little addon installer dialog box
[16:05] <LaserJock> mvo: I don't think nautilus used to show up, do you know if there's a way around that?
[16:06] <mvo> LaserJock: I don't know, I guess seb128 can help us with that
[16:08] <LaserJock> mvo: and did you get a chance to get a float flag for g-a-i?
[16:08] <mvo> LaserJock: I did some work on it, but its not finished :/ its relatively small, so it may land for user interface freeze (if I get it done and approval for it)
[16:09] <calc> pitti: there will be more gvfs point releases before jaunty is released right?
[16:09] <LaserJock> mvo: is there anything I can do to help that along?
[16:10] <allquixotic> bryce: Are we planning to pull xserver-xorg-video-intel 2.6.2? It's http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=93ae6c7f8cadb60d479e626ddd2a67d7cb2cc4c0
[16:14] <pitti> calc: yes, very likely
[16:15] <pitti> calc: if not we can cherrypick that patch, but gvfs is in GNOME's release cycle, so it'll get point releases
[16:15] <LaserJock> if a package has recommends but the recommends aren't in the archive does apt just ignore them and install anyway?
[16:15] <doko> calc: when do you plan your next OOo upload?
[16:15] <mvo> LaserJock: yes
[16:16] <LaserJock> mvo: thanks
[16:16] <LaserJock> I kept wondering why the Edubuntu CD was pulling in Universe and Main packages
[16:16] <LaserJock> but when I turned everything but the CD off in sources.list it installed just fine too
[16:18] <mvo> LaserJock: let me have a look at the floating patch thing again now
[16:18] <LaserJock> mvo: that'd be wonderful, without it it kinda kills my spec :-)
[16:19] <calc> doko: sometime after today :) why is there a specific thing you would like to see?
[16:19] <LaserJock> no pressure though ;-)
[16:19] <calc> doko: aiui we are in alpha 5 freeze still
[16:20] <doko> calc: please do the next upload using python2.6 directly if we didn't do the change before your upload.
[16:21] <doko> calc: or better: build python-uno for 2.5 and 2.6
[16:24] <calc> doko: ok
[16:24] <kirkland> Keybuk: around?
[16:25] <Keybuk> yup, what's up?
[16:25] <kirkland> Keybuk: http://people.ubuntu.com/~kirkland/Screenshot.png
[16:25] <kirkland> Keybuk: booting degraded raid has regressed in jaunty
[16:25] <kirkland> Keybuk: this is the first time i've tested it this cycle
[16:25] <calc> doko: i have a few other changes queued up for the next upload as well, so i probably will do one sometime next week
[16:25] <Keybuk> kirkland: it says your /dev/sda1 is already in /dev/md0
[16:25] <kirkland> Keybuk: i'm wondering if there's something obvious you'd know about that'd cause this
[16:26] <Keybuk> in fact, the very fact you're getting a kobject-related message from the kernel suggests there's an md bug here
[16:26] <Keybuk> an in-kernel md bug
[16:26] <kirkland> Keybuk: yuck, okay
[16:26] <calc> doko: oh is python2.4 being dropped now that we have both 2.5/2.6 in main?
[16:26] <kirkland> Keybuk: i'll file against the kernel
[16:27] <doko> calc: does OOo still use 2.4?
[16:27] <kirkland> Keybuk: the root/disk user/group message ... that's just a red herring?
[16:27] <Keybuk> kirkland: there is no /etc/passwd or /etc/group in the initramfs
[16:27] <Keybuk> so you can just ignore that
[16:27] <Keybuk> it's the kobject message below that which is the issue
[16:27] <calc> doko: no, just wondering since we have 3 pythons now :)
[16:27] <kirkland> Keybuk: okay, i was just making sure that wasn't something that changed between intrepid/jaunty
[16:27] <Keybuk> and it's simply a bug to even get anything like that
[16:27] <Keybuk> kirkland: I don't think so
[16:28] <Keybuk> unless mdadm changed ;)
[16:28] <kirkland> Keybuk: okay, thanks for the analysis ;-)
[16:38] <Keybuk> Adri2000: yes
[16:38] <Adri2000> \o/
[16:38] <Adri2000> and? :)
[16:38] <Keybuk> and it's on my todo list
[16:39] <Keybuk> probably today
[16:39] <Adri2000> excellent, just ping me then
[16:39] <Keybuk> in fact, let me go and get a cup of coffee and I'll do it now
[16:39] <Keybuk> since you're here, and gcc is actually building this time ;)
[16:40] <Adri2000> ok :)
[16:48] <Keybuk> Adri2000: ok, I now have coffe
[16:49] <Adri2000> :)
[16:49] <Keybuk> the last revision I have from you is 135
[16:49] <Keybuk> addcomment.py: explicitely import cgi.escape and mention the name of the p
[16:49] <Keybuk> arameter quote when calling escape()
[16:49] <Keybuk> is that the latest?
[16:50] <Adri2000> yep
[16:51] <Keybuk> ok, let me do the update on casey
[16:53]  * RainCT hugs Keybuk :)
[16:53] <Keybuk> Adri2000: ok, pushed
[16:53] <Keybuk> how do we test this?
[16:54] <RainCT> error :P
[16:55] <Adri2000> indeed
[16:55] <Keybuk> ?
[16:55] <RainCT> Keybuk: http://merges.ubuntu.com/universe.html
[16:56] <Adri2000> Keybuk: mv htaccess .htaccess?
[16:56] <Keybuk> Adri2000: no htaccess permitted on casey
[16:56] <Keybuk> ah
[16:57] <slangasek> moquist: how would putting anything in the preinst help?  If it wasn't working in the postinst, wouldn't it be more of a problem in the preinst?
[16:57] <Keybuk> try https://merges.ubuntu.com/universe.html
[16:57] <Adri2000> hmm, htaccess is allowed on https but not http?
[16:57] <moquist> slangasek: The idea was to catch the problem and bail earlier.
[16:58] <slangasek> hmm
[16:58] <Keybuk> no, the config change only got applied to https apparently
[16:58] <moquist> slangasek: but I think multiple binary packages with pre-depends can simply solve the problem.
[16:58] <slangasek> I don't think you should be using pre-depends
[16:58]  * moquist was afraid of that :)
[16:59] <Adri2000> Keybuk: what config change?
[16:59] <Keybuk> Adri2000: adding mod_python
[16:59] <Adri2000> mod_python is enabled on both http and https
[16:59] <Adri2000> according to the ServerSignature
[16:59] <Keybuk> Adri2000: the handler is only enabled on http
[17:00] <moquist> slangasek: the problem is that even 'apt-get install mysql-server moodle' fails b/c mysql-server isn't completely installed before moodle's postinst runs. See things go bad on line 6 of http://rafb.net/p/kZmMbM22.html (pgsql & mysql have the same problem - the paste is pg)
[17:01] <moquist> Based on my quick reading of what pre-depends do, it seems like what we need, but if there's a better way I'm all for it.
[17:01] <slangasek> pre-depends would mean you *always* have to have the server installed locally
[17:01] <RainCT> Keybuk: Uhm.. The .htaccess isn't in the LP branch?
[17:02] <Keybuk> RainCT: I removed it
[17:02] <moquist> ah, yes. Well, the package now assumes that anyhow. Maybe that's bad, but I suggest that we should have a moodle-nodb package that gives the admin max flexibility and minimal config automation.
[17:02] <seb128> slangasek: hey, any idea when the freeze will lift?
[17:03] <Keybuk> Adri2000, RainCT: seems to be working on https now
[17:03] <moquist> Regular users who install the 'moodle' package can end up with a worknig system, while power admins can install moodle-nodb and do whatever they like.
[17:03] <slangasek> seb128: US afternoon today, I expect
[17:03] <Adri2000> adding comments on https works
[17:04] <slangasek> moquist: if the local db server is a requirement, which I think is horribly wrong from a packaging perspective, then the db server package should be a *depends*, not a recommends
[17:04] <maco> slangasek: it's afternoon in part of the US already. has been for 4 minutes :P
[17:04] <slangasek> and certainly not a pre-depends
[17:04] <seb128> slangasek: ok, thanks
[17:04] <slangasek> maco: that coast doesn't count
[17:04] <moquist> slangasek: right, I would remove it from recommends.
[17:05] <geser> Adri2000: would it be possible to add a link to the debian changelog (on the debian version) on MoM?
[17:05] <moquist> slangasek: does having the db server in depends do anything different than simply installing both packages simultaneously?
[17:05] <ogra> hmm, cjwatson will oem-setup-debconf work over a ssh connection ? i'm pondering to do a prebuilt image for nslu2
[17:05] <Adri2000> geser: I have a patch for adding a link to the PTS (like in DaD), but not merged (yet)
[17:06] <Adri2000> oh, it is merged
[17:06] <ogra> i see it starts by default on the tty
[17:06] <slangasek> moquist: it enforces the order in which the packages are configured; I'd recommend reading the Ubuntu policy manual
[17:06] <Adri2000> geser: do you want a direct link to the changelog as well?
[17:06] <moquist> slangasek: Fair enough. Thanks.
[17:07] <Adri2000> Keybuk: so, need a sysadmin to put the same server config from https to http?
[17:07] <RainCT> Keybuk: I was working on a redesign for MoM some months ago. If I finish it, will you(/somewho) commit to get it merged in a reasonable amount of time?  (if that'll be lying around for months like the comments I may as well leave it for this summer)
[17:07] <geser> Adri2000: would be nice (if it's not to much work) so one can check if a merge is usefull (e.g. now). I can go through the PTS to the changelog but a direct link would be one click less (and one page load less)
[17:08] <Keybuk> RainCT: sure
[17:09] <Keybuk> RainCT: the comments stuff wasn't lying around, it needed some extensive security review and discussions between different people ;)
[17:09] <Keybuk> changing around the html is just a push <g>
[17:09] <Keybuk> Adri2000: yes
[17:09] <Keybuk> Adri2000: we also need your existing DaD comments file?
[17:10] <Adri2000> yes, I already set it read-only on DaD a few minutes ago
[17:10] <Adri2000> http://dad.dunnewind.net/comments
[17:10] <RainCT> Keybuk: Great, I'll have a go at it within the next weeks then.
[17:10] <cjwatson> ogra: hmm, theoretically, though it does prefer to have a framebuffer
[17:10] <Keybuk> Adri2000: are comments cleared at any point?
[17:10] <cjwatson> ogra: you'll probably run into some glitches, but I'd be happy to fix them
[17:10] <Adri2000> Keybuk: yes, when the merge disappear from the list
[17:11] <Keybuk> Adri2000: cool
[17:11] <cjwatson> ogra: oem-config-debconf does also rather prefer to have a UTF-8 locale generated though ...
[17:11] <ogra> yeah, sounds a bit saner to do it that way with a basic bootstrapped jffs2 system than having an 8h d-i install
[17:11] <Keybuk> ok, your comments now in place
[17:11] <ogra> meh, now my qemu kernel oopsed right at the end of oem-setup
[17:11] <Adri2000> Keybuk: there are a few lines of spam in the file you can remove
[17:12] <cjwatson> YM oem-config?
[17:12] <Adri2000> geser: maybe file a bug so we don't forget it. also we'd need to find a place where to put the link, maybe RainCT can do that with the new design
[17:12] <ogra> err
[17:12] <ogra> and after qemu my X died ... fun
[17:13] <Adri2000> Keybuk: also grab http://adrishost.net/~adri2000/ubuntu/MoM/result/merges/ubuntu.png and http://adrishost.net/~adri2000/ubuntu/MoM/result/merges/debian.png
[17:14] <Keybuk> where do they need to go?
[17:14] <Adri2000> https://merges.ubuntu.com/{ubuntu,debian}.png
[17:14] <Adri2000> they're used in the Bug column
[17:16] <RainCT> Keybuk: It's not just HTML, though, I also added a template engine -tinpy, available at SF under MIT License.. just a single file-, that shouldn't be a problem or?
[17:16]  * ogra cries, so my 30h slug install was just done with its last locale ... grmbl
[17:17] <Keybuk> RainCT: is the dependency in main?
[17:17] <Adri2000> Keybuk: have you pinged a sysadmin yet? I pinged Chex as he is the one who enabled mod_python
[17:17] <RainCT> Keybuk: no, I added it as a file in utils/
[17:17] <Keybuk> Adri2000: yes
[17:18] <Keybuk> but no response
[17:18] <Keybuk> RainCT: that should be ok
[17:20]  * RainCT tries to figure out why he created two branches :P
[17:35] <superm1> pitti, could you take a look at https://code.edge.launchpad.net/~superm1/jockey/only-broadcom-sta/+merge/1391 ? I submitted it some time back and wanted to make sure it wasn't overlooked for jaunty
[17:36] <mvo> LaserJock: please have a look at lp:~mvo/gnome-app-install/always-on-top - the remiaing problem is that its currently slower at startup, I look into that now
[17:37] <Adri2000> Keybuk: "The requested URL /ubuntu.png was not found on this server."
[17:38] <pitti> superm1: oh, I think I either overlooked or didn't get the mail for it
[17:42] <Keybuk> Adri2000: needs a server reload
[17:43] <Adri2000> ah yes, just saw your commit, you put them in .img/
[17:44] <RainCT> mvo: arr.. I don't know what you're talking about, but that always-on-top sounds evil *g*
[17:46] <LaserJock> RainCT: not too evil
[17:46] <LaserJock> RainCT: it means I get to override the sorting in Add/Remove
[17:47] <RainCT> LaserJock: Ah, I don't understand your last sentence but it sounds way less scaring ;P
[17:50] <LaserJock> RainCT: normally Add/Remove sorts alphabetically
[17:50] <LaserJock> RainCT: for Edubuntu we wanted a way to make certain menu items "float" to the top of the list
[17:51] <RainCT> LaserJock: Oh, I see. So nothing to do with what I first thought; this actually sounds cool :)
[17:52] <LaserJock> RainCT: of course! :p
[17:57] <Adri2000> Keybuk: looks like it's been workarounded :p
[17:59] <pitti> superm1: done; sorry that this slipped
[17:59] <superm1> pitti, no problem.  i suspected it was an oversight
[18:01] <Keybuk> Adri2000: cool
[18:01] <Keybuk> anything else you need?
[18:03] <Adri2000> nope, I'll update DaD to show a message saying to go to MoM. also, I'll send an announcement mail to ubuntu-devel, except if you want to do it? anything I should mention apart from comments merged into MoM and DaD shut down?
[18:07] <RainCT> Adri2000: new interface coming somewhen soon (before they complain :P)
[18:10] <Adri2000> RainCT: eheh, ok :)
[18:11] <Keybuk> Adri2000: you can do that :)
[18:12] <didrocks> jelmer: about evolution-mapi: do you have some time to take into account james_w concerns on REVU?
[18:14] <jelmer> didrocks, those should already be fixed IIRC
[18:15] <jelmer> ah, looks like the package just didn't come through
[18:15] <pitti> superm1: will you be at the LF summit, btw?
[18:16] <didrocks> jelmer: yep, the new upload is not in REVU
[18:18] <jelmer> didrocks, I'll see if I can upload a new one in a few minutes
[18:18] <didrocks> jelmer: no pb, even if it's later. I subscribed :)
[18:19] <ogra> hmm, isnt oem-config supposed to uninstall itself after it has been run successfully ?
[18:19] <ogra> it seems to work just fine and properly sets up the first user, but i still have the package and binaries
[18:23] <cjwatson> ogra: no
[18:24] <cjwatson> that's been a wishlist for a while, but is a little problematic in case you actually wanted to rerun it for some reason
[18:24] <ogra> yeah, understood
[18:24] <ogra> the gui version does that though, no ?
[18:24] <cjwatson> no, it does not
[18:24] <ogra> ah, k i thught i read it in a wiki doc
[18:24] <cjwatson> glad to hear that it worked
[18:24] <ogra> *thought
[18:24] <ogra> well, on the tty
[18:25] <cjwatson> well, you know what wikis can be like :)
[18:25] <ogra> havent tried it via ssh yet
[18:25] <cjwatson> ah
[18:25] <ogra> i'm not a fan of setting up qemu networking on the host side :)
[18:26] <ogra> so i need to do some fiddling first
[18:33] <kirkland> superm1: ping, re: dkms
[18:34] <superm1> pitti, probably not.  we're rather low on travel budgets, so need a good business case if I was going to go
[18:34] <superm1> kirkland, pong
[18:37] <kirkland> superm1: i'm no dkms expert, but it looks like there's something wrong with the kvm-source --configure bits
[18:37] <kirkland> superm1: https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/334177
[18:39] <kirkland> superm1: does that package need some better smarts about upgrades in the postinst?
[18:42] <superm1> kirkland, i'd need to see the log for sure (that log on the bug is invalid)
[18:42] <superm1> kirkland, but yes you do need to have some smarts in the upgrades to make sure that all previous versions are knocked out
[18:42] <kirkland> superm1: what log do you need?
[18:42] <superm1> look at the fglrx or nvidia postinst's for examples
[18:42] <kirkland> superm1: http://pastebin.ubuntu.com/123471/
[18:42] <superm1> the dist upgrade log, apt term log, and dpkg.log
[18:43] <kirkland> superm1: the current postinst is very basic
[18:43] <superm1> kirkland, definitely not enough
[18:44] <kirkland> superm1: which is the correct nvidia source package?
[18:50] <kirkland> superm1: nvidia-glx-180, eg?
[18:52] <moquist> if my package has multiple binaries with different .config scripts, should I have multiple .templates files or just one?
[18:53] <kirkland> moquist: better question for #ubuntu-motu
[18:53] <moquist> kirkland: OK. Thanks.
[18:59] <mathiaz> robbiew: should I unassign myself from bug 289470?
[19:00] <robbiew> mathiaz: yeah
[19:00] <robbiew> mathiaz: I'll grab it for my team, thnx
[19:15] <superm1> kirkland, yeah that should be fine. tseliot did a pretty good job keeping it clean and covering for errors
[19:16] <superm1> kirkland, look at the prerm and postrm too
[19:16] <cjwatson> Keybuk: davmor2 confirmed that that udev fix works
[19:19] <Keybuk> cjwatson: good to know
[19:22] <slytherin> anything wrong with hal again? I am having trouble playing DVD on latest jaunty.
[19:22] <slytherin> s/hal/dev
[19:33] <kirkland> superm1: thanks, i'm digging through it now
[19:34] <slytherin> Keybuk: Can you help me here? I remember you solved my last problem with udev
[19:43] <fta> is there a way to add new stuff in ia32lib in hardy? it's really messy for some upstream, like android and chromium. See bug 277772, http://groups.google.com/group/chromium-dev/browse_thread/thread/d3f6b7f4eadb43a3 and http://code.google.com/p/chromium/wiki/LinuxBuild64Bit
[19:46] <sea-gull> ﻿ Hi, All! Will ubuntu participate in Google Summer of Code?
[20:09] <slytherin> any archive admins around? it seems libgmyth0 got eaten somehow on ports repository.
[20:14] <kirkland> superm1: looks like i was really just missing "dkms remove -m $PKG -v $PKGVER --all -q > /dev/null"
[20:15] <superm1> kirkland, yeah that's the important part
[20:15] <kirkland> superm1: so nvidia's looks like: http://pastebin.ubuntu.com/123507/
[20:15] <kirkland> superm1: i don't think the if [ "$STATUS" = "True" ] && [ -d $SOURCES ]; then ....
[20:16] <kirkland> bit applies to me
[20:16] <kirkland> superm1: that some custom maintainer work for nvidia, right?
[20:16] <superm1> kirkland, i think that was from some errors in earlier packages to make sure it's cleaned up right
[20:16] <savvas> Riddell: made patch for bug 102773 - it fixes the problem with unicode server names in combobox_server - any comments welcome :)
[20:16] <superm1> kirkland, you'll want to check with tseliot though.  he wrote that part in
[20:18] <kirkland> tseliot: ping?
[20:19] <kirkland> superm1: agreed, looks like custom cleanup
[20:22] <maco> kirkland: did you get the mini iso to install at all?
[20:23] <kirkland> maco: oh, thanks for the reminder!
[20:23] <kirkland> maco: i'm back home now, and can try again
[20:24] <kirkland> maco: i was onsite the first of this week and connectivity/equipement was non-ideal
[20:27] <slytherin> can any of the core dev please give back elisa-plugins-* packages?
[20:31] <wgrant> Is there a way I can get the old update-notifier behaviour?
[20:31] <savvas> slytherin: aren't they in jaunty?
[20:31] <cjwatson> slytherin: could I have the exact source package list?
[20:32] <tseliot> kirkland: yes?
[20:32] <kirkland> tseliot: hi there, i'm trying to fix the kvm dkms module installation
[20:32] <kirkland> tseliot: superm1 pointed me your way
[20:32] <kirkland> tseliot: i was looking at nvidia's install
[20:32] <slytherin> cjwatson: sure, elisa-plugins-good, elisa-plugins-bad, elisa-plugins-ugly
[20:32] <tseliot> kirkland: ok, what's the problem?
[20:32] <cjwatson> slytherin: all architectures?
[20:33] <kirkland> tseliot: i think i was just missing: dkms remove -m $PKG -v $PKGVER --all -q
[20:33] <slytherin> cjwatson: they are arch:all packages
[20:33] <cjwatson> oh, it's arch all
[20:33] <cjwatson> ok
[20:33] <kirkland> tseliot: the error reported is https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/334177
[20:33]  * tseliot has a look
[20:34] <cjwatson> slytherin: done
[20:34] <slytherin> cjwatson: thanks
[20:34]  * savvas notes that give back means remove :p
[20:35] <kirkland> maco: mini.iso installing....
[20:36] <davmor2> maco: worked here unless we are talking about a non-standard install
[20:36] <kirkland> davmor2: encrypted-home + Kubuntu
[20:37] <kirkland> davmor2: starting from mini.iso
[20:37] <kirkland> maco: that's the problem ^^^ right?
[20:37] <davmor2> kirkland: Ah only did a standard not e-h
[20:38] <slytherin> cjwatson: should I report a bug for missing libgmyth0 for ports architectures?
[20:40] <maco> kirkland: yes
[20:40] <maco> davmor2: kde tried to write its config files before the ~ was mounted writable. then it tried to read teh config files it failed to write. then it got upset and refused to load.
[20:41] <davmor2> maco: is it only on netboot or does it happen from cd too?
[20:42] <maco> i used mini iso. the original bug reporter used netboot. that's all i know.
[20:42] <maco> the laptop i installed on doesnt have a well-working cd drive, so i can only use mini iso on it
[20:42] <davmor2> maco: same thing really :)
[20:43] <davmor2> no probs :)
[20:45] <kirkland> tseliot: i'm getting an error, though
[20:46] <tseliot> kirkland: I can't access the log in the bug report but it looks like the source code is being put in the same directory twice or so. I need to have a look at the source code to see what's happening
[20:46] <kirkland> tseliot: http://pastebin.ubuntu.com/123523/
[20:46] <kirkland> tseliot: want me to pastebin the postinst script?
[20:46] <slangasek> LaserJock: is there an impending test of Edubuntu amd64?
[20:46] <tseliot> kirkland: yes, please
[20:49] <kirkland> tseliot: http://pastebin.ubuntu.com/123524/
[20:49] <kirkland> tseliot: that's what i'm working with now
[20:49] <kirkland> tseliot: this is what it looked like before: http://pastebin.ubuntu.com/123471/
[20:51] <LaserJock> slangasek: no, I don't have a 64-bit VM unfortunately
[20:52] <tseliot> kirkland: what's the name of the package?
[20:52] <tseliot> kvm-source?
[20:52] <tseliot>  yes, right
[20:52] <slangasek> LaserJock: ok; is there someone else who usually helps with the amd64 tests?
[20:52]  * tseliot gets the source
[20:53] <slangasek> LaserJock: or should I only release the i386 ISO for this alpha?
[20:53] <davmor2> slangasek: I can run that in a minute :)
[20:53] <slangasek> davmor2: ok
[20:53] <LaserJock> slangasek: do I have to have a test to get it released?
[20:53] <slangasek> yes
[20:53] <slytherin> can any of the archive/lp admin please copy libgmyth0 for all port architectures in the ports repository?
[20:54] <LaserJock> slangasek: bugger, ok I can do a test in around 15 min
[20:54] <kirkland> tseliot: kvm
[20:54] <kirkland> tseliot: kvm-source is the binary
[20:54] <slangasek> LaserJock: well, davmor2 just offered
[20:54] <LaserJock> oh, then that'd be great
[20:55] <davmor2> slangasek: Won't be for a minute though running tests already so after these I can :)
[20:55] <slangasek> ok. :)
[20:55] <LaserJock> slangasek: it seems a little weird to have to do that much testing before releasing an alpha for Edubuntu
[20:56] <LaserJock> slangasek: it's pretty much just a pool/
[20:56] <davmor2> LaserJock: still needs to work though dude :)
[20:57] <LaserJock> well, "work" is a bit relative
[20:58] <LaserJock> I can't think of much of anything that'd happen with it that I'd say "don't install this"
[20:58] <LaserJock> which I think is sort of the point of the alphas
[20:58] <slangasek> LaserJock: if the tasks weren't actually installable off the CD
[20:58] <slangasek> then there'd be no point in keeping the ISO around
[20:59] <tseliot> kirkland: ok, I'll try to install it so as to see what's wrong. I'll do it tomorrow though as it's 21:28 here and I'm a bit tired. I'll let you know how it goes
[20:59] <kirkland> tseliot: thanks, i'll keep hacking on it
[20:59] <kirkland> tseliot: i think i'm close
[20:59] <LaserJock> slangasek: what do you mean by "tasks"?
[20:59] <tseliot> kirkland: ok
[21:00] <slytherin> Keybuk: please drop me an offline message whenever you see this. Need your help in debugging an issue which I believe is udev/hal related.
[21:00] <kirkland> tseliot: subscribe to https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/334177
[21:00] <kirkland> tseliot: i'll note in there if i fix it
[21:00] <slangasek> LaserJock: tasksel tasks; is that not what edubuntu installs currently?
[21:00] <LaserJock> no
[21:00] <LaserJock> not that I now of
[21:00] <tseliot> kirkland: ok, done.
[21:00] <slangasek> ok - "metapackages", then?
[21:01] <LaserJock> well, I wouldn't consider those as critical to the .iso
[21:01] <LaserJock> it's a big point of it and we need to know if they are broken for sure
[21:01] <LaserJock> but it shouldn't stop people from trying out the software that's on the CD
[21:01] <kirkland> tseliot: cheers, thanks.
[21:02] <tseliot> np
[21:02] <slangasek> LaserJock: they can do that straight from the archive if that's all they're doing
[21:02] <LaserJock> slangasek: they can do the metapackages as well
[21:03] <LaserJock> the only thing to test that you can't do from the archive is self-consistency
[21:04] <LaserJock> and that's not often going to change depending on arch
[21:04] <slangasek> LaserJock: these are the standards that we apply to all ISOs that we release with alphas.  I'm not going to consume disk on the CD server and point our users at ISOs that haven't even been minimally tested before the alpha release.
[21:04] <kirkland> maco: i'm on tasksel now, just grab Kubuntu-desktop?
[21:04] <LaserJock> slangasek: fair enough, you're the boss :-)
[21:26] <kirkland> slangasek: has the archive thawed yet?
[21:26] <maco> kirkland: yeah
[21:28] <slangasek> kirkland: it's thawing; what do you have?
[21:29] <kirkland> slangasek: nothing urgent, kvm, ecryptfs-utils
[21:29] <slangasek> those should be fine to upload
[21:29] <kirkland> slangasek: cool, thanks.
[21:29] <slangasek> seb128: GNOME stuff too, if you want
[21:30] <seb128> slangasek: ok thanks!
[21:41] <davmor2> LaserJock: still no usplash on edubuntu
[21:42] <kirkland> maco: hmm, kubuntu install looks fine to me
[21:42] <kirkland> maco: the mini.iso install completed
[21:42] <kirkland> maco: rebooted, logged into kubuntu
[21:42] <kirkland> maco: my encrypted home is mounted
[21:42] <kirkland> maco: checked the underlying files...  encrypted contents, encrypted filenames ...
[21:42] <kirkland> maco: i don't see the problem here ...
[21:44] <maco> kirkland: ><
[21:44] <maco> anything change since last week?
[21:44] <kirkland> maco: hrm
[21:45] <kirkland> maco: not really in ecryptfs-utils
[21:45] <kirkland> maco: i can't speak for the installer, though
[21:45] <kirkland> maco: this should have started working just before FF
[21:45] <kirkland> wow, i haven't seen kubuntu in a while
[21:45] <davmor2> kirkland: installer has
[21:45] <kirkland> cool :-)
[21:45] <kirkland> davmor2: ah
[21:46] <kirkland> maco: any chance you can try to reproduce the problem on your end?
[21:46] <kirkland> maco: i'll note my experience in the bug report
[21:46] <maco> yeah ill try again
[21:46] <kirkland> maco: cheers, thanks.
[21:46] <davmor2> kirkland: maco: I'll run a test tomorrow morning and let you know too
[21:46] <maco> ok
[21:46] <kirkland> davmor2: cool, thanks.
[22:10] <slangasek> ScottK, ryanakca, Riddell: are there kubuntu alpha release notes for this round?
[22:11] <ScottK> slangasek: How close are you to needing them?
[22:11] <slangasek> ScottK: hmm, 1.5h
[22:11] <ScottK> We'll have something.
[22:11] <slangasek> ok
[22:18] <LaserJock> wow, this new screen-profile thing is rockin'
[22:28] <slangasek> ScottK: will https://wiki.kubuntu.org/JauntyJackalope/Alpha5/Kubuntu be the correct link?
[22:29] <ScottK> Yes.
[22:43] <LaserJock> davmor2: thanks for doing the Edubuntu amd64 test
[22:44] <davmor2> LaserJock: np's
[22:50] <savvas> TheMuso: any luck with powerpc and jaunty build environment?
[22:50] <savvas> or any progress, heh
[22:50] <TheMuso> savvas: Oh yes, I've got it set up, I just need to test build
[22:51] <savvas> TheMuso: do you want me to look up the logs for the patch?
[22:52] <TheMuso> savvas: no I should have a copy locally here
[22:52] <savvas> great :)
[22:52] <savvas> ScottK: we needed a powerpc test build for bmpx if I remember correctly, right?
[22:53] <ScottK> That needs fixed too.
[22:53] <ScottK> It failed on the buildd's but I don't know what to do to fix it.
[22:53] <savvas> with the patch I provided?
[22:53] <savvas> I mean, the patch I found :P
[22:54] <ScottK> OK.  I lost sync.  Then yes, we need a PPC test build.
[22:54] <savvas> ok :)