[00:09] <NCommander> pitti, ping?
[00:17] <StevenK> NCommander: If pitti isn't sleeping, I'd be suprised.
[00:17] <NCommander> ah, right
[00:29]  * Hobbsee wonders what the current 'central time' is.
[00:30] <stgraber> CET is 1:30am
[00:31] <stgraber> (in EST :))
[00:31] <superm1> Hobbsee, CST is 18:31
[00:32] <stgraber> hmm, what I just said doesn't make any sense ...
[00:32] <StevenK> % TZ=US/Central date
[00:32] <StevenK> Thu Jan 22 18:32:19 CST 2009
[00:33] <slangasek> $ TZ=CEST date
[00:33] <slangasek> Fri Jan 23 00:32:51 UTC 2009
[00:34] <stgraber> slangasek: isn't CEST Central Europe Summer Time ? making it non-existent at this time of the year ?
[00:35] <slangasek> maybe :)
[00:35] <slangasek> that might explain why it shows an hour earlier than if I type 'CET'
[00:35] <stgraber> probably explains why the TZ in your date's output is UTC and not CEST as it should have been if the timezone existed
[00:35] <slangasek> well, that's simply because /usr/share/zoneinfo/CEST doesn't exist. :)
[00:36] <StevenK> Yeah, date has a "feature" if the timezone doesn't exist, then it must be UTC
[00:39] <Hobbsee> hrm, OK, thanks.
[00:40] <Hobbsee> 2am meeting. damn.
[00:40] <StevenK> OpenWeek isn't so friendly for the Australian timezones this time around
[00:41] <Hobbsee> nah, release team meetings
[00:41] <Hobbsee> and what do you mean *this* time around?  They're not friendly *any* time around.
[00:41] <StevenK> I was trying to remember ...
[00:41]  * StevenK mumbles something about caffeine
[00:41] <Hobbsee> they always start at 1600 utc or so.
[00:42] <Hobbsee> heh, caffeine.  If only that would work in this house... ;)
[01:16] <refdoc> Hi, I am one of the developers of a programme which is as a package in Ubuntu  The package you have is ancient. It is very frustrating for us as we get constantly bug reports for ancient stuff from ubuntu users,. The maintainer listed does not respond to our emails. What is the mechanism to get him/her removed and replaced by someone from us?
[01:17] <cjwatson> we generally maintain packages as a group in Ubuntu rather than having individual maintainers. You may be seeing the Debian maintainer listed.
[01:18] <asomething> refdoc: what is the package? do we inherit it from debian?
[01:18] <refdoc> So what shall we do?
[01:18] <cjwatson> is there an Ubuntu bug filed about this?
[01:18] <refdoc> Gnomesword, libswrod diatheke
[01:18] <refdoc> yes
[01:18] <refdoc> multiple
[01:18] <refdoc> I think you inherit from debian
[01:19] <cjwatson> as we do with the vast majority of our packages, yes
[01:19] <calc> refdoc: has a bug in debian been filed yet?
[01:19] <refdoc> one of our guys maintains for years now his own repository
[01:19] <refdoc> not sure
[01:19] <refdoc> never looked yet
[01:19] <calc> refdoc: ok
[01:19] <refdoc> but people say even there they complain
[01:19] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463207
[01:19] <cjwatson> Debian is frozen for release at the moment, of course
[01:20] <refdoc> Is it now always frozen? :-)
[01:20] <cjwatson> no. :-P (Note that many people in this channel work on Debian too.)
[01:20] <calc> refdoc: no it was not frozen when that bug was filed
[01:20] <refdoc> Sorry that was an attempt at a joke
[01:20] <refdoc> so, what shall we do
[01:21] <cjwatson> it would probably be fine for us to update, but it needs an enthusiastic Ubuntu developer to step up and do it. mail<EMAIL_ADDRESS>which is a good place for that kind of thing
[01:21] <refdoc> one of us maingtains his own packages for years
[01:21] <refdoc> they are good and work immediately fine on clean installs
[01:21] <refdoc> ok I will email there
[01:21] <refdoc> thanks
[01:21] <cjwatson> no offence to your developer but we do always like to make sure of things ourselves :-)
[01:22] <cjwatson> sometimes people who work on the distribution have a better idea of what needs to be got right in certain areas, so it's always worth having a distro expert look it over
[01:22] <refdoc> Aye, no problem, but your packages are now two years out of date in this particular case
[01:22] <calc> refdoc: if you don't get any hits from there after a week or so you can email me<EMAIL_ADDRESS>and i'll try to take a look at it (i'm pretty busy most of the time though)
[01:22] <cjwatson> not saying that's why the package is still at an old version - that's almost certainly because Daniel Glassey ran out of time
[01:23] <refdoc> great calc!
[01:23] <cjwatson> I can maybe ask around in debian-uk and find out if he's still active
[01:23] <calc> i'm sure my father in law would like to run that program and an up to date version would be good ;-)
[01:23] <calc> i'm supposed to be finishing up his system as soon as i get some spare time
[01:24] <refdoc> we are moving to 3.0 release, the version you have is 2.1 or 2.2
[01:24] <refdoc> ok thanks a lot to everyone!
[01:26] <slangasek> cjwatson: ISTR he was presumed MIA except that he appeared in person at DebConf 7...
[01:27] <calc> he came to debconf but doesn't actually update his packages, weird :-\
[01:35] <arpu> hello i have the problem with ubuntu 8.10 and intel  945GM
[01:35] <arpu> GL_RENDERER   = Software Rasterizer
[01:35] <arpu> GL_VERSION    = 2.1 Mesa 7.2
[01:35] <arpu> GL_VENDOR     = Mesa Project
[01:36] <arpu> i found a lot of posts and bug reports for ubuntu but nobody knows a solution
[01:38] <arpu> the only solution is to wait for  jaunty but i can not update my stable installation
[01:39] <arpu> mybe some knows anything on this problem
[01:40] <arpu> one of the bug reports https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/252094
[01:41] <cjwatson> slangasek: so, apparently Debian has *finally* fixed the grub/xfs problems, and there's a decent chance that we can switch it on again in grub-installer at long last
[01:42] <cjwatson> slangasek: how hard would a merge be? :-)
[01:42] <slangasek> oh, really?
[01:42] <slangasek> a merge of which package?
[01:42] <cjwatson> grub
[01:42] <slangasek> grub?
[01:43] <cjwatson> turned out that (a) the kernel was fixed upstream in around .19/.20 to arrange that xfs_freeze -f doesn't return until I/O is complete (b) grub was doing xfs_freeze -f; write to filesystem; xfs_freeze -u which was completely broken, and xfs_freeze -f; xfs_freeze -u; write to filesystem actually works now that the kernel has been fixed
[01:43] <cjwatson> or at least so I gather from a while reading Debian #239111
[01:43] <slangasek> very hard, the repo is bollocked right now because of a bzr-svn bug :(
[01:43] <calc> i just noticed that in intrepid there is a im status icon on the right side, why is it there when the same thing is in the tray?
[01:43] <cjwatson> heh, what a title
[01:43]  * jelmer wakes up
[01:43]  * calc hadn't done a full reinstall in a while
[01:43] <cjwatson> slangasek: yeah, I didn't expect it to be a straightforward bzr merge
[01:43] <cjwatson> maybe we can just backport that patch, not sure
[01:44] <calc> is the other im icon not visible enough or something?
[01:44] <cjwatson> it was only in xfs_freeze.patch, really
[01:44] <slangasek> cjwatson: well it was meant to be, that's why I put it in bzr! :)
[01:44] <cjwatson> yeah, but I knew about the bzr-svn problems
[01:44] <slangasek> jelmer: any progress on that bug which I will refer to with hand-waving because I don't have the number in front of me?
[01:45] <slangasek> hrm, it's not in my subscribed bugs list
[01:45] <jelmer> slangasek: maybe; I did fix one bug (for which I had a test case) related to pushing of unrelated merged trees, but there's another issue still remaining
[01:45] <slangasek> maybe it got fixed and I wasn't watching
[01:46] <jelmer> slangasek, If you created the combined branch by merging the debian directory into the grub directory, it does not work yet - if you did it the other way around (keeping the tree root from the debian packaging directory), it should work.
[01:47] <slangasek> ok, then it's going to not work
[01:47] <jelmer> the bug # is 295416, btw
[01:47] <cjwatson> slangasek: (and fjp just confirmed that grub/xfs now works on a system where he could previously reproduce the bug, if you're watching #debian-boot)
[01:48] <slangasek> jelmer: ah, new bug number that I hadn't seen before :)
[01:48] <slangasek> er, except I'm subscribed so apparently I have
[01:49] <slangasek> cjwatson: a one-time manual cherry pick, then?
[01:50] <asomething> calc: there are some threads about that on the desktop list, no urls handy though
[01:51] <cjwatson> slangasek: yeah, I think so
[01:51] <asomething> calc: i believe that the idea is to make the fusa conrol global status for im ect eventually
[01:52] <cjwatson> sounds doom-laden otherwise
[02:10] <calc> asomething: doesn
[02:10] <calc> asomething: doesn't sound particularly useful since the IM app is already in the tray
[02:10] <arpu> re hi i think i found the problem  Virtual 2560 1888 without them all works fine
[02:10] <calc> asomething: perhaps more gnome crack? :)
[02:11] <calc> asomething: and the im app (pidgin or telepathy) is already essentially global setting anyway
[02:12]  * calc has 5 or 6 im protocols running in pidgin and only has one status setting for them
[02:19] <asomething> calc: I think it's an Ubuntu patch http://www.markshuttleworth.com/archives/233
[02:22] <calc> asomething: yes, but ubuntu gnome crack ;-)
[02:23] <asomething> calc: don't you mean innovation? ;-)
[02:24] <calc> asomething: useless innovation, unless something hasn't been hooked up properly and is just buggy
[02:25] <calc> i have within 3in of the corner a second IM status icon
[02:25] <calc> that actually does what it is supposed to... control the IM program
[02:25] <calc> the screenshot you posted apparently has no running IM client, or something else weird
[02:25] <calc> its not in the tray
[02:26] <calc> tedg: ping
[02:33]  * calc thinks he will just delete it
[02:33] <calc> yea that works better :)
[02:38] <slangasek> better than what?
[02:41] <calc> slangasek: better than a lot of wasted corner screen real estate
[02:41]  * calc now has the calendar there which he uses much more often than a duplicated IM status widget
[02:42] <slangasek> oh?  I still have plenty of real estate to spare on my toolbar, so. :)
[02:44] <calc> i never use fusa and don't need a duplicate im applet so it was completely useless
[02:46]  * calc wishes someone would fix the clock applet to have radar map support, then i could throw out gweather
[03:44] <TheMuso> dtchen: I'd be interested in your thoughts re bug 235007, since a quirk already exists for this in upstream alsa, and users are reporting 3stack as a better option...
[04:41] <NCommander> hey cjwatson
[05:10] <bluesmoke> hey RAOF
[05:10] <RAOF> Howbidie.
[05:10] <bluesmoke> RAOF: you ever get compiz++ working?
[05:10] <bluesmoke> the snap port is fixed now
[05:11] <RAOF> For values of "working" equal to "able to move windows without decoration", yes.
[05:12] <bluesmoke> well that's creepy to see, snap only stops the window from moving, not the decoration
[05:13] <bluesmoke> onestone must not have noticed (he fixed it) because he uses kde-window-decorator which does reparenting
[05:13] <RAOF> Nifty.
[05:13] <bluesmoke> RAOF: Just build libcompizconfig and compizconfig-python so you can use the ccp plugin and ccsm
[05:13] <RAOF> Both from compiz++ branch, I take it.
[05:13] <bluesmoke> I have a feeling you're missing a plugin dependency there or something
[05:13] <bluesmoke> right
[05:13] <RAOF> Probably.
[05:13] <bluesmoke> and make sure you set PYTHONPATH to point to the compiz++ version when you run ccsm
[05:14] <RAOF> Or just install it systemwide!
[05:14] <bluesmoke> I'm about to, it's usable now
[05:15] <RAOF> I might get myself a working GL stack and give it another whirl then.
[05:15]  * RAOF wishes nvidia was as fast as nouveau.
[05:15] <bluesmoke> RAOF: If you use kde-window-decorator you just need good RenderAccel and Composite :)
[05:16] <RAOF> Well, I've got me _that_.
[05:16] <bluesmoke> Although I dunno if even the minimize plugin works without opengl
[05:16] <bluesmoke> but move, resize, and snap should work :)
[05:17] <bluesmoke> Actually with Composite you can use gtk-window-decorator, kwd is only needed if you don't want to use Composite
[05:17] <bluesmoke> onestone is apparently working on a plugin to handle viewport changes that will work without composite and then other plugins (wall, cube) can plug into it to provide composited and opengl effects to switching
[05:19] <RAOF> Wouldn't that require you to not unmap the windows on viewport change?  How does that fly with lack of composite?
[05:20] <bluesmoke> eh? they just go offscreen like they do now
[05:21] <bluesmoke> viewports were not designed with composited desktops in mind
[05:22] <RAOF> Hm.  There appears to be a compiz++ branch of only libcompizconfig.
[05:24] <bluesmoke> RAOF: oh, right, you just have to build the python bindings against that one
[05:24] <bluesmoke> the ABI changed, not the API
[05:26] <RAOF> Hm.  How much do I care about protobufs?
[05:28] <bluesmoke> I haven't done any benchmarks but if compiz++ gains support for it that should solve most of our startup time problems
[05:28] <bluesmoke> not much, I guess
[05:28] <bluesmoke> I built it because it was cool though :)
[05:29] <RAOF> Hurrah for name mangling!  That configure.ac check is a thing of beauty. :l
[05:37] <dholbach> good morning
[05:38] <TheMuso> Hey dholbach .
[05:38] <TheMuso> dholbach: Re sound volume profiles, its not possible afaik.
[05:39] <dholbach> hi TheMuso
[05:39] <dholbach> TheMuso: that's fine, alsactl will do what I want to do :)
[05:39] <TheMuso> dholbach: I thought as much, but I don't know of a GUI equivalent.
[05:40] <dholbach> ah OK
[05:40] <dholbach> thanks TheMuso
[05:40] <TheMuso> np
[05:44] <RAOF> bluesmoke: So, that kind of works.  Still no decoration, though ;)
[05:45] <bluesmoke> RAOF: You've got the plugin loaded and you're running the right gtk-window-decorator?
[05:45] <bluesmoke> RAOF: Perhaps try kde-window-decorator
[05:48] <RAOF> Oh, yeah.  There we go.
[05:48] <RAOF> bluesmoke: Hm.  Doesn't actually seem that composite's working.
[05:49]  * bluesmoke blames your driver
[05:49] <bluesmoke> apparently intel, fglrx, ati, and nvidia work fine
[05:52] <RAOF> This has been tested with Composite !OpenGL?
[05:56] <bluesmoke> RAOF: I think I screwed up and loaded that combo once, yes :P
[05:56] <RAOF> kde4-window-decorator works, but there 'aint no composite.
[05:57] <bluesmoke> ok, i see what you mean
[05:57] <bluesmoke> Apparently Composite doesn't have an XRender internal system, dunno how I missed that
[05:58] <bluesmoke> RAOF: Hey, you need a fun project? :)
[05:58]  * RAOF is fairly sure his definition of "fun" does not accomodate adding an XRender backend to compiz.
[05:58] <RAOF> But I'll put it on the list, right after "Learn Portugese" :P
[06:04] <bluesmoke> RAOF: Looks pretty straightforward, really
[06:04] <bluesmoke> If you know XRender, anyway
[06:04] <bluesmoke> The composite plugin handles basically everything, you just have to hook into it and draw stuff
[06:18] <calc> bug 320351 (new gnome crack of the day)
[06:20]  * calc should start a blog so he can have a gnome crack of the day meme on it ;-)
[06:20]  * calc digs in svn to see if there is a reason why they did this
[06:21]  * ScottK thought reduced options were a Gnome feature?
[06:22] <calc> lol
[06:22] <calc> because all cities are small enough the weather is the same everywhere :)
[06:23] <calc> i found the commit i think
[06:23] <calc> rev 518 of libgweather
[06:23] <calc> Don't worry about sub-city locations; people generally aren't going to know which of the locations is closest to them, and the weather reports from all of them should be basically the same anyway.
[06:23] <calc> bahaha, yea this is true of a city that is 4000 sq km
[06:32] <bryce> calc, ick
[06:41] <calc> generally cities only have one weather station if any at all unless they are very large cities, in which case the weather is likely not to be the same
[06:42] <calc> houston is somewhere in the range of 4000 sq km and has 6 stations (maybe more?) and now they don't even tell you which one it is much less let you choose which one to use
[06:43] <mininat> hi ! i've been reading the "contribute" pages of Ubuntu's web site and i was wondering if there is any task managment platform for ubuntero ?
[06:43] <calc> some of the stations listed as 'houston' aren't really houston but are in the houston metro area so get grouped that way
[06:43] <calc> strictly speaking houston city limits aren't that big but the stations listed for houston are in the huge area
[06:49] <mininat> any task repatition platform for a devoted want-to-contribute ? :)
[06:50] <bryce> mininat: welcome!  could you explain what you're looking for specifically?
[06:51] <mininat> i've checked the contributes pages on the main site, developemnt team
[06:51] <mininat> i checked the first stage, called "ubuntero"
[06:51] <mininat> but seems there is no task list or any specific project
[06:51] <mininat> and i'm looking for one to start contributing
[06:52] <mininat> see what i can do etc etc
[06:52] <bryce> ah, most tasks are in launchpad.net
[06:52] <bryce> mininat: what sorts of tasks in particular are you looking for?
[06:53] <bryce> bbiab
[06:54] <mininat> i like hacking my computer, i mean, read docs, looking solutions, scripts things
[06:54] <mininat> and as i want to go more deep in programming stuff
[06:54] <mininat> contributing to my system community should be a cool starting point
[06:56] <mininat> https://launchpad.net/ubuntu/+mentoring
[06:56] <mininat> that would be a good wau to start according to you ?
[07:22] <Karnaugh> [0123 09h27.42] real_name = Colin Alston
[07:23] <Karnaugh> sorry about that
[08:36] <pitti> StevenK, NCommander: sorry, was away doing some login time measurements, took a while
[08:36] <pitti> !ping | NCommander
[08:36] <pitti> erm
[08:37] <pitti> I meant to say "Please do not send contentless pings, just ask" :)
[09:17] <pitti> primes2h: hi
[09:17] <primes2h> pitti: Hello.
[09:17] <pitti> primes2h: thanks for working on this
[09:17] <pitti> primes2h: some comments:
[09:17] <primes2h> pitti: I have the new correct debdiff
[09:18] <primes2h> Did you get?
[09:18] <pitti> - package should drop the old *.icon files, since they are autogenerated now; the Makefile.am's clean rule should do that
[09:18] <pitti> - changelog should just say "renamed *.icon to *.icon.in and marked description as translatable" or so, instead of putting that long redundant list of new files
[09:20] <primes2h> In fact I made .icon.in from scratch.
[09:20] <primes2h> there were no .icon file before.
[09:21] <primes2h> you mean this? CLEANFILES = $(icons_in_DATA)
[09:21] <pitti> primes2h: well, there certainly must have been a place before where the C strings came from?
[09:21] <pitti> are they in the .svg files?
[09:22] <primes2h> .icon file are created during build and then are cleaned
[09:22] <pitti> primes2h: it seems wrong to maintain a separate set of files, since that would duplicate the original strings
[09:22] <pitti> hm, I don't know how emblem translations work
[09:22] <pitti> gnome-icon-theme doesn't ship *.icon files either
[09:23] <primes2h> Exactly.
[09:23] <primes2h> I got that example.
[09:23] <primes2h> as example
[09:23] <primes2h> strings are taken from icon.in files that I created.
[09:24] <primes2h> I mean, it uses icon.in to create .icon files...
[09:25] <primes2h> strings are probably taken from them,
[09:25] <primes2h> and finally .icon file are removed.
[09:26] <primes2h> This is how gnome-icon-theme (and human-icon-theme) works (I'm quite sure)
[09:26] <pitti> primes2h: so where did the English strings for the emblems came from before?
[09:26] <primes2h> from the name of the icon.. emblems-important.svg etc...
[09:27] <primes2h> In fact the name was not in Capital letter.
[09:27] <_max> dono if this is a bug or not, if i boot 8.10 x86 livecd, i can make changes to /etc/network/interfaces, add /etc/resolv.conf etc, and they are "kept" after actual installation.
[09:27] <_max> however my /etc/apt/apt.conf was discarded.
[09:27] <primes2h> have a look at Edit -> Backgrounds and emblems -> emblems
[09:28] <primes2h> I guess this... but it's the more probable explanation...
[09:30] <primes2h> I learnt this looking at gnome-icon-them
[09:30] <pitti> primes2h: "Edit" where?
[09:34] <pitti> primes2h: so whether it's from the file name or a field in the .svg file, I think the pot should be created from that one instead of a separately maintained .icon.in file
[09:35] <pitti> otherwise you'd always have to make the same change in two different places
[09:36] <tkamppeter> pitti, I have answered your question to bug 308817
[09:37] <primes2h> pitti: Edit in nautilus
[09:37] <primes2h> pitti: hold on, I'm on the phone.
[09:39] <pitti> tkamppeter: thanks
[09:40] <tkamppeter> pitti, then I think you can pass through the 3 -proposed packages, cups, ghostscript, and foomatic-filters
[09:53] <epicgoo> those .a files in the dev packages use .so files. right?
[09:53] <epicgoo> you link blah.a to your program and program uses blah.a
[09:53] <epicgoo> blah.so
[09:56] <slangasek> epicgoo: no, .a files and .so files are two different things; and this is not really the channel for learning how the linker works
[09:56] <seb128> pitti: did you try to talk to dobey? he's on #ubuntu-desktop and he's the upstream icon naming specification maintainer and working on gnome-icon-theme, he likely knows about those things
[09:57] <epicgoo> I know...
[09:57] <epicgoo> they are different so?
[09:57] <epicgoo> I am talking about the dev packages in ubuntu
[09:58] <epicgoo> if you link a blah.a lib to your program (from libblah-dev), will the program use blah.so?
[09:59] <epicgoo> or those .a files are just static libs
[09:59] <slangasek> a .a file is a static lib, yes.
[09:59] <slangasek> with the exception of libc.a, which is a linker script for arcane reasons
[09:59] <epicgoo> but your program may or may not need the .so file
[10:02] <slangasek> Not sure what you're meaning to ask.  If your program is statically linked against a library, it doesn't need a shared copy of that library.
[10:05] <epicgoo> http://en.wikipedia.org/wiki/Library_(computing)#Naming
[10:05] <epicgoo> linux =/= windows
[10:15] <primes2h> pitti: icon.in files it's the way gnome-icon-theme works...
[10:16] <primes2h> pitti: and I think is the best way because it's more flexible...
[10:17] <primes2h> You can choose the best text to explain the icon purpose.
[10:18] <primes2h> It's not necessarily the same as icon-name
[10:19] <primes2h> e.g emblem-CVS-controlled.svg you can choose "CVS controlled"
[10:19] <primes2h> and you can use capital letter
[10:19] <primes2h> that it's missing in icon-name.
[10:22] <primes2h> that is
[10:25] <primes2h> pitti: In fact if you look at gnome-icon-theme changelog you see that this kind of patch was made on 2004 to add emblem translation...
[10:32] <primes2h> pitti: By the way I found out another emblem untranslated (emblem-desktop) in 48x48/emblems/ 16x16/emblems/ and 24x24/emblems/
[10:32] <primes2h> I need to add it in the patch.
[10:38] <primes2h> pitti: You need icon.in files because POTFILES needs to know where to pick up strings for po files...
[10:38] <pitti> primes2h: right, but those could be autogenerated from the actual source, like the file names or svg header?
[10:39] <primes2h> No, that's the problem!
[10:40] <primes2h> because now what you see on emblem name in the GUI is a sort of fallback because it's not set up for translation
[10:41] <primes2h> Or better, I don't know but I think it's more complicated...
[10:41] <primes2h> POTFILES doesn't work this way.
[10:42] <primes2h> have a look on POTFILES.in
[10:42] <primes2h> in
[10:48] <pitti> primes2h: re (sorry, we have the plumber here)
[10:49] <primes2h> pitti: no problem :-)
[10:49] <pitti> primes2h: what I meant is: autogenerate .icon.in from the original source, then use the inltool magic to create the .pot, and throw away the .icon.in/.icon again
[10:52] <primes2h> Ah, ok. It probably can be done adding code I think, but it could be a problem if, for some reason, you need to change strings name, in that case you should change .svg name
[10:52] <primes2h> and it's worse
[10:53] <primes2h> .icon.in files are present in gnome-icon-theme source
[10:53] <primes2h> one for each svg
[10:55] <primes2h> and moreover you should change linkname on each file where svg files are mentioned.
[10:55] <pitti> primes2h: that's exactly what I was heading to; if you change the .svg's name, you have to remember changing the .icon.in
[10:56] <pitti> .icon.in is derived information, it shouldn't be something that has to explicitly be maintained?
[11:01] <primes2h> Following gnome-icon-theme changelog, you have to manage .icon.in manually (adding, removing, changing) and the correspondent Makefile.am
[11:01] <pitti> hmm
[11:02] <primes2h> They are needed to mantain separated code from translation things...
[11:02] <primes2h> To keep all clearer...
[11:03] <pitti> primes2h: but if the .icon.in file is the definitive place for the strings, then they would need to be shipped in the gnome-icon-theme package?
[11:03] <primes2h> In fact they are.
[11:04] <primes2h> :-)
[11:04] <primes2h> Have a look at the source...
[11:04] <pitti> ah, I see
[11:05] <pitti> and of course again with statically replicated translations
[11:05] <pitti> those spread faster than we can squash them *sigh*
[11:07] <primes2h> :-)
[11:14] <mib_p8yxoe6r> hi
[11:14] <primes2h> pitti: In fact they are not replicated, because some strings in .icon.in are different from the svg-name (e.g. emblem-important.svg -> Important (with capital letter in .icon.in), and emblem-cvs-added.svg -> CVS added (in .icon.in))
[11:15] <pitti> primes2h: ok, I see now
[11:15] <pitti> primes2h: so, that looks fine then
[11:16] <pitti> primes2h: mind to attach the current debdiff to the bug and subscribe me? I'll review/sponsor it
[11:17] <primes2h> Ok, I just need to add emblem-desktop in 48x48(24x24,16x16)/emblems that I forgot to set up
[11:17] <primes2h> Thank you! and what about changelog?
[11:18] <primes2h> Do you think it's too long with all icon.in files?
[11:19] <primes2h> In my opinion it's needed to keep trace of changing...
[11:20] <primes2h> pitti: What do you think?
[11:21] <pitti> primes2h: you could just say "Added *.icon.in: Explanation..."
[11:21] <primes2h> pitti: ok! Other changes?
[11:23] <pitti> primes2h: should be alright; I'll give it another review once it's attached to the bug
[11:23] <pitti> primes2h: thanks for bearing with me and explaining everything
[11:23] <primes2h> That's nice, thank you very much for all.
[11:24] <primes2h> pitti: Just one last thing...
[11:26] <primes2h> This patch expose also another bug already present in human-icon-theme, that kwwii told you yesterday...
[11:26] <primes2h> pitti: bug #319991
[11:27] <primes2h> pitti: just to remaind you... :-)
[11:29] <pitti> primes2h: let me ask Ken
[11:30] <pitti> primes2h: ah, I guess I know
[11:30] <pitti> it should be named stock-mail, not stock_mail
[11:33] <primes2h> pitti: ask Ken, I am puzzled because the icon doesn't exist and I don't know where it looks for the name...
[11:34] <primes2h> pitti: I go away for lunch, see you later...
[12:13] <mib_730riq17> hi
[12:17] <mib_730riq17> how to use autoconf and automake to change the configuration file of an existing project?
[12:19] <mib_730riq17> Please give alink so that I can read and know the use of autoconf and automake
[12:20] <cjwatson> the autoconf-doc and automake packages include extensive info documentation for those tools; 'info autoconf', 'info automake'
[12:20] <mib_730riq17> cjwatson: thanx
[12:21] <cjwatson> the autoconf documentation is also in /usr/share/doc/autoconf-doc/autoconf.html if you prefer that
[12:21] <cjwatson> the automake documentation is only installed as info, but is available online as HTML in http://www.gnu.org/software/automake/manual/automake.html
[12:22] <mib_730riq17> cjwatson: do the change in configure.in file needs automake( it needs autoconf)..
[12:22] <mib_730riq17> cjwatson: thanx for the valuable links
[12:23] <cjwatson> mib_730riq17: that depends on the project. Some do, some don't
[12:23] <cjwatson> mib_730riq17: you should generally use autoreconf rather than running the individual tools
[12:25] <mib_730riq17> cjwatson: autoreconf thats a new tool I heard now???Is it installed along with autoconf?
[12:26] <mib_730riq17> cjwatson: I will try both the ways so that I learn all of the processes , thanx for all the info...
[12:26] <cjwatson> mib_730riq17: autoreconf is in the autoconf package, and has been around for a long time
[12:27] <cjwatson> it's documented in the autoconf documentation
[12:27] <mib_730riq17> cjwatson: OK
[12:28] <mib_730riq17> cjwatson: what are the general precaution should I take to edit the configure.in file of an existing project so that it does not damage the app or the process of installation of app...
[12:31] <cjwatson> I would personally recommend keeping files in revision control so that you can easily check the diffs produced (e.g. bzr diff) and test extensively
[12:31] <cjwatson> if you're using different versions of the autotools from those used to generate the previous files you have in hand, then the diff may be very large, and you may need to make changes simply to get it to work at all
[12:32] <cjwatson> with poorly-written configure.in files it can be quite a difficult exercise to modify them at all, I'm afraid
[12:32] <cjwatson> and you typically end up learning rather more about the autotools than you expected :-)
[12:32] <cjwatson> the fact that it's called configure.in at all (rather than the modern name, configure.ac) is not a good sign to begin with
[12:39] <mib_730riq17> cjwatson: actually I have the task to update the configure.in so I have to take all the pain
[12:40] <mib_730riq17> cjwatson: anyways if you are new to something its always adventurous to learn...
[12:42] <mib_730riq17> cjwatson: what are difs , revision control and all those stuffs ??? do u have a link to the tutorial explaining all those stuffs..
[12:42] <cjwatson> mib_730riq17: you can google for "revision control" as a first step and read e.g. the Wikipedia article on the subject
[12:43] <cjwatson> mib_730riq17: the 'bzr' tool I referred to is http://bazaar-vcs.org/ and there are several general tutorials on that site
[12:48] <mib_730riq17> cjwatson: it seems that bzr has a bug that it does not support proxy with authentication so i think i have limited use of bzr :(
[12:50] <cjwatson> mib_730riq17: #bzr may be able to help you check whether this is something you can work around
[12:50] <cjwatson> there were some old bugs about this but I thought they had been fixed
[12:52] <mib_730riq17> cjwatson: i tried #bzr but they confirmed that this bug has no way around and this is not going to be fixed in coming future.This was pretty rude I hope that I can help them but I dont have enough knowledge to do so :(
[12:52] <cjwatson> I don't think it's rude for developers to be honest about their roadmap!
[12:55] <mib_730riq17> cjwatson: after being into 1 or 2 developing projects i agree with u...
[12:56] <mib_730riq17> cjwatson: can I get help from here if i am stuck during revision or i have to go to some other channel?
[12:56] <cjwatson> this is really not the best channel; I would recommend you look elsewhere
[13:03] <mib_730riq17> cjwatson: like...do u have any ideas?
[13:04] <cjwatson> mib_730riq17: no, it depends on the problem you are having; please be creative :-)
[13:10] <mib_730riq17> cjwatson: OK thanx for ur valuable time...:) bye
[14:07] <kirkland> mvo: hi there, are you around?
[14:19]  * pitti squashes his first pet bug
[14:19] <ScottK> \o/
[14:20] <jdstrand> cjwatson: fyi-- I really liked HardyReleaseNotes/ChangeSummary/8.04.2. I hadn't seen that for previous point releases and think it is a great idea.
[14:20] <pitti> slangasek: ^ that's a CD space present for you (bug 123025)
[14:21] <cjwatson> jdstrand: glad you liked it, it was a lot of work :)
[14:21] <soren> pitti: How much space does that buy us?
[14:22] <pitti> soren: once all the GNOME packages are rebuilt, in the order of 100 MB uncompressed and 10 MB compressed
[14:22] <soren> Whee!
[14:22] <pitti> well, that is, 10 MB on desktops (which has the pregenerated /var/lib/gconf/defaults/)
[14:23] <pitti> on the alternates, where that tree is generated at runtime, I guess more like 5 MB
[14:23] <pitti> but still not to be sneezed at
[14:23] <soren> Certainly not.
[14:28] <dholbach> hey soren: are you well again?
[14:29] <soren> dholbach: Getting better.
[14:29]  * dholbach hugs soren
[14:29] <dholbach> AWESOME!
[14:29] <soren> dholbach: I just got fed up with lying in my bed.
[14:29] <dholbach> I can imagine
[14:29] <dholbach> after lying there, getting fed and everything, having read 35 books and stuff it must get tiring ;-)
[14:31] <soren> :)
[14:31] <pitti> apachelogger: argh, my cdbs upload got rejected, because 0.4.52ubuntu11 is already in the archive; you didn't commit to bzr
[14:33] <apachelogger> pitti: I commited, I just didn't push
[14:33] <PecisDarbs> hi people, when GNOME 2.26 will be merged into Jaunty?
[14:33] <PecisDarbs> in what date?
[14:33] <pitti> apachelogger: I'll fix it up, since I already pushed my stuff
[14:33]  * PecisDarbs plans translation stuff
[14:34] <apachelogger> pitti: ok, thanks ... and sorry for the inconvenience :)
[14:35] <pitti> apachelogger: ok, applied your changes and pushed
[14:53] <lool> tjaalton: Hmm you don't rm_conffile() /etc/network/if-up.d/mountnfs.orig?
[14:54] <lool> oh sorry already covered in the bug's comments
[14:55] <tjaalton> yes, it should be fine. worked here
[14:57] <lool> seb128: I don't understand what "[BLACKLISTED] libv4l_0.5.3-1" means in Bug 319975?
[14:57] <seb128> lool: it means the sync didn't work because for some reason libv4l is on the not-to-sync list
[14:58] <seb128> I just did some quick syncs because mvo asked one but I want to finish other things so I will not investigate that now though
[14:58] <lool> # ... due to orig.tar.gz mismatch:
[14:59] <lool> That would be surprizing as I thikn I sponsored all the Debian uploads and requested all syncs
[14:59] <bigon> seb128: hi, what does [BLACKLISTED] libv4l_0.5.3-1 means?
[14:59] <lool> bigon: See above
[14:59] <cjwatson> bigon: scroll up
[14:59] <lool> Beside it's a new upstream
[14:59] <seb128> bigon: hey, read the channel?
[14:59] <pitti> lool: could ahve been a temporary measure; should just disappear from the blacklist then
[15:00] <pitti> lool: we need to do those to unbreak sync-source -a, i. e. "sync everythign unmodified from Debian"
[15:00] <seb128> bigon: also do you have a bugzilla.gnome.org account?
[15:00] <lool> seb128: Mind dropping it from BL and syncing?
[15:00] <seb128> lool: will do later, I closed my shell on this box now and I'm in middle of something else
[15:00]  * bigon should read his backlog indeed
[15:00] <lool> seb128: Ok; I'm reopening the bug then
[15:00] <bigon> seb128: yes<EMAIL_ADDRESS>[15:00] <seb128> lool: ok
[15:01] <seb128> bigon: when you reopen a gnome bug on launchpad which has an upstream task could you also reopen or comment on the upstream bug?
[15:01] <seb128> bigon: ie the gnome-session crasher you reopened
[15:06] <bigon> seb128: done
[15:06] <seb128> bigon: thanks
[15:06]  * mvo hugs seb
[15:06]  * mvo hugs seb128
[15:06]  * seb128 hugs mvo ;-)
[15:45] <dholbach> can somebody please massage the u-d-a list?
[15:48] <cjwatson> dear conference organisers, ubuntu-devel-announce does not want to submit a paper
[15:49] <cjwatson> dholbach: approved your post
[15:49] <dholbach> cjwatson: thanks muchly
[15:52] <tjaalton> could someone kick yellow, it's been building qt4 since the 20th
[15:52] <tjaalton> qt4-x11
[15:56] <apw> pitti, about?
[15:56] <pitti> apw: hi
[15:57] <apw> pitti, did you get a chance to look at that apport branch i requested merge?
[15:57] <pitti> apw: currently catching up with SRUs, then I'll review your apport branch
[15:57] <apw> pitti, thanks
[15:57] <pitti> apw: not yet, sorry; but next thing on my list
[15:57] <apw> no, thats perfectly reasonable ... just sliding past it on my 'watch this lot list'
[15:58] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek - last day going to kick off in #ubuntu-classroom now!
[15:58]  * pitti hugs dholbach
[15:59]  * dholbach hugs pitti back
[15:59] <pitti> seb128: argh, there must be something wrong; all four retracers didn't crash in the last three days!
[16:01] <seb128> pitti: where is the fun there? ;-)
[16:01] <pitti> boooooring
[16:01] <seb128> indeed!
[16:34] <pitti> seb128: question for you in bug 207072
[16:41] <seb128> pitti: replied
[16:42] <seb128> pitti: basically the change means "only do mounting when accessing the share, not when listing those"
[16:42] <seb128> pitti: otherwise it would try to mount all bookmarks when opening the gnome-panel places menu for example
[16:43] <pitti> seb128: ugh, why did it do that before?
[16:43] <seb128> pitti: and when you have bookmarks which don't reply the software hangs on timeout
[16:43] <seb128> pitti: not sure what advantage it has but that was not an issue since there was no call doing ios
[16:44] <seb128> pitti: that's also why the nautilus change on bug #251809 is required btw
[16:47] <primes2h> pitti: I attached the debdiff and subscribed you.
[16:47] <seb128> pitti: http://bugzilla.gnome.org/show_bug.cgi?id=524485#c32
[16:48] <pitti> seb128: ah, and the nautilus change is to handle ENOTMOUNTED?
[16:50] <seb128> pitti: not exactly, nautilus already handle ENOTMOUNTED since ssh, etc were never automounted, the code was buggy apparently and that fix the bug
[17:09]  * apw wonders if there is something up with the amd64 buildds they seem very behind the curve
[17:10] <pitti> apw: just busy, as it seems
[17:10] <apw> yellow seems to have been doing the same job for three days?  is that likely?
[17:11] <apw> https://launchpad.net/+builds/yellow
[17:21] <ia> hello. could you tell me, please, how can i detect, which "server's version" contained in xorg package? i ask about it, because after last update (i use jaunty 3 alpha), when xserver starts, it shows me error message with text "module abi major version (4) doesn't match the server's version (5)"
[17:24] <slangasek> pitti: ooh yay, I like cd space presents. :)
[17:25] <pitti> slangasek: I uploaded nautilus and gnome-terminal, which are the two packages with the biggest saving (ls -lSr /usr/share/gconf/schemas/)
[17:25] <pitti> slangasek: the rest will trickle through with the normal gnome updates
[17:43] <lool> cjwatson: As debootstrap and random guru I'd rather have you decide what to do for PATH based on Chet's comments :)
[17:43]  * lool doesn't feel like he has any weight to claim that the kernel or bash or debootstrap should set it
[18:03] <pitti> Keybuk: could you put your udevadm howto into README.Debian or so?
[18:03] <calc> how is kde 4 coming along? i may be switching back to it soon, the gnomies are scaring me :-\
[18:05]  * calc filed a bug report and the response was essentially, we like to make big broad sweeping changes that break stuff, but we have this pie in the sky idea that would fix the breakage we caused if we ever get around to implementing it
[18:05] <pecisk> calc: what is so scary about gnomies? :)
[18:06] <calc> pecisk: see above ^
[18:06] <calc> pecisk: they have done it with gdm, gnome-session, pulseaudio, and now gweather :-\
[18:06] <calc> probably other stuff as well
[18:06] <pecisk> calc: exactly what? :)
[18:07] <calc> eg try logging out of your session with stuff open, it just kills them now instead of warning you to save (gnome-session)
[18:07] <pecisk> new stuff which breaks old stuff?
[18:07] <calc> pulseaudio completely replaces the audio system in 2.26 and if you have intel hda realtek it doesn't work right
[18:07] <pecisk> you mean consistency
[18:07] <pecisk> well
[18:07] <calc> gdm was so buggy (aiui) we didn't ship the new version for the past few releases?
[18:08] <LaserJock> calc: I'm with you man, I made the jump a couple weeks ago. In a few days KDE 4.2 will be out, you should try it
[18:08] <calc> and now with gweather they are dropping the ability to select the station you want to see reports from, the grouping of stations per city is buggy and some cities are so big the weather is different from one side to other anyway
[18:08] <pecisk> I have my share of arguments why it is bad to do so, however, I haven't seen much impact, expect logging out/quiting dialog, which was kinda stupid to do without huge warning in release
[18:08] <calc> LaserJock: heh ok
[18:09] <pecisk> calc: have bug report/reference about that? :)
[18:10] <calc> pecisk: the gweather one is gnome bug 568813
[18:10] <tjaalton> well, you can always look out ot the window?-)
[18:10] <pecisk> :)
[18:10] <calc> tjaalton: sure, so why not just throw all of gnome away you can do stuff with pen and paper too
[18:10] <tjaalton> calc: heh
[18:10] <pecisk> joke aside, removing features without warning and insight is truely GNOME developers problem now
[18:10] <pecisk> tjaalton: he is partly right
[18:11] <calc> i reference both Houston and London in that bug report that they are both buggy with respect to station data, but he just wants to break it
[18:11] <tjaalton> surely it's a bug
[18:11] <pecisk> PA is thrown in just because it is "Next Best Thing", nevermind regressions in SOUND, which is mererly a basic of OS
[18:11] <Keybuk> pitti: seems an odd place for it
[18:11] <LaserJock> Gnome has gotten really good about calling bugs "features"
[18:11] <pecisk> :)
[18:12] <Keybuk> pitti: ubuntu-policy would be better, no?
[18:12] <Keybuk> or a developer's reference
[18:12] <LaserJock> the volume control stuff, gnome-session, gweather, ...
[18:12] <pecisk> NetworkManager :)
[18:13] <calc> perhaps i should just switch with 8.10 and hope by 10.04 gnome is sane again
[18:13] <calc> i can do my testing etc inside vmware :)
[18:14] <LaserJock> calc: man, I don't know. I thought the same thing the time the released without a menu editor
[18:14] <pecisk> Problem is that steering of development is done by people who are very protective about stuff they like
[18:14] <pecisk> and they want that everyone accepts it
[18:14] <pecisk> and if someone objects, he is unpolite, jerk and doesn't understand how cool this stuff will be after year or two. maybe.
[18:14] <calc> LaserJock: luckily gnome finally has one of those :)
[18:15] <LaserJock> calc: for now
[18:15] <pecisk> LaserJock: GNOME has menu editor for quite a long time
[18:15] <calc> pecisk: yea the developers don't seem to get that crap should stay in a branch until it is ready
[18:15] <calc> pecisk: iirc it took several years before it did
[18:15] <pecisk> I think problem is that they don't have any way to test it than force it upon users
[18:15] <pecisk> and that is bad
[18:16] <LaserJock> pecisk: right, but they pulled a similar to the gnome-session thing that long ago
[18:16] <calc> pecisk: even when they know it is definitely broken they still force it on users, eg gnome-session and pulseaudio
[18:16] <calc> gnome-session doesn't manage sessions anymore for example
[18:16] <pecisk> calc: gnome-session sure was problem, but it was solved. Pulseaudio, however, isn't still acepted even as external module for GNOME
[18:17] <calc> pecisk: solved when in 2.25?
[18:17] <calc> pecisk: it doesn't work in 2.24
[18:17] <calc> pecisk: pulseaudio is being forced into main gnome for 2.25/2.26
[18:17] <pecisk> calc: what exactly doesn't work in gnome-session? :)
[18:17] <calc> pecisk: when you log out it doesn't warn you to save anymore
[18:18] <LaserJock> it doesn't actually do any session management
[18:18] <calc> pecisk: maybe other stuff too
[18:18] <pecisk> calc: it won't, so far reading GNOME devs list
[18:18] <pecisk> calc: ahhh
[18:18] <cjwatson> lool: ok :-/ I'll think about it on Monday, have to go now
[18:18] <calc> pecisk: did someone revert the gnome-volume-* stuff then?
[18:18] <pecisk> calc: well, actually they work on improvements, but they will be in distro like Ubuntu first
[18:19] <pecisk> calc: no one, but no one also have accepted it as only one
[18:19] <LaserJock> it's rediculous what they did with gnome-session
[18:19] <LaserJock> gnome-session-save is even left with a man page
[18:19] <LaserJock> yet it does absolutley nothing
[18:19] <LaserJock> they had the GUI for session saving
[18:19] <LaserJock> but it wasn't hooked up to anything
[18:20] <LaserJock> why on earth would you do that?
[18:20] <pecisk> more or less, all these problems indicates one particular issue with open source - when getting big as GNOME, Ubuntu, KDE, you have to make specs
[18:20] <pecisk> what should do that button
[18:20] <pecisk> what should do another button
[18:20] <pecisk> etc.
[18:20] <LaserJock> seems to me to  be rather release management
[18:20] <calc> they even have specs in gnome afaict but they don't care that they break stuff
[18:20] <pecisk> without specs, GNOME keeps crunching on "oh so shiny features" while deserting "just works" field
[18:21] <pecisk> LaserJock: release management follows specs - usually :)
[18:21] <LaserJock> pecisk: right, but you can spec all you want, if the features don't arrive in time you don't just ship broken stuff and say "oh well, maybe next time"
[18:21] <pecisk> calc: they don't have specs on how you should log out from session
[18:22] <tjaalton> what.. there's no 'gnome-session-save --kill --silent' anymore??
[18:22] <LaserJock> tjaalton: no
[18:22] <tjaalton> uh
[18:22] <pecisk> LaserJock: but this is exactly what I am talking about ;) If new code doesn't provide warning dialog about unsaved docs, forget about inclusion
[18:22] <tjaalton> so much for the lock-timeout then
[18:22] <pecisk> tjaalton: it is gone the way of Todo
[18:22] <tjaalton> guess I'll have to forward-port it then
[18:22] <pecisk> tjaalton: due of gnome-session rewrite, which didn't landed all features it's promised
[18:23] <LaserJock> pecisk: right, but the problem was that they knew that and released it anyway
[18:23] <tjaalton> maybe I'll ruin my evening by reading some ml archives then..
[18:23] <pecisk> :D
[18:23] <pecisk> reading GNOME ml is neverending thrill these days - which features will get thrown out
[18:24] <pecisk> some guy did remake for Vino dialog - for what?! Instead of adding SIMPLE CHECKBOX, he thrown Advanced tab just because it is "not worth it".
[18:24] <LaserJock> I mean, it's even worse than xorg getting rid of Ctrl-Alt-Backspace ;-)
[18:25] <pecisk> He didn't even evaluated which features maybe is worth to get into new version!
[18:25] <pecisk> I mean - what a development is this?
[18:26] <pecisk> Also infameous NetworkManager 'Auto eth0' profile, which people tried to change, and everytime it falls back to DHCP
[18:30] <directhex> pecisk, oh yes, that sucks hard
[18:31] <directhex> gave up using NM on a home server. unusable due to the auto eth0
[18:37] <pecisk> anyway, it is getting out of handing and seriously hurting any chances for free desktop enviroments to be accepted as usable from common people. Even more, it can drive lot of them away without intent to never look back.
[18:51] <tjaalton> could a buildd admin kick yellow (amd64)? it's been stuck for a couple of days now.. https://edge.launchpad.net/ubuntu/+source/qt4-x11/4.4.3-0ubuntu1.2/+build/842557
[18:52] <tjaalton> a better link https://edge.launchpad.net/+builds/yellow
[19:31] <NCommander> Keybuk, you around?
[19:33] <Keybuk> NCommander: yup
[19:35] <NCommander> Keybuk, I'm curious about the issues with upstart on ARM, specifically, what/s missing in in our kernel to make it work sanely
[19:35] <Keybuk> pselect() and ppoll() just as the bug says
[19:35] <Keybuk> and you mean udev, not upstart ;)
[19:35] <NCommander> What bug?
[19:35] <NCommander> (sorry, I was just informed of this via a meeting this morning, I haven't seen any bug)
[19:35] <Keybuk> bug #319729
[19:36] <tjaalton> Keybuk: could you have a look at yellow (the buildd). I'd really need to get mesa  et al built on amd64 to avoid bugs like bug 320525
[19:36]  * ogra wasnt aware either that Keybuk logged a bug
[19:36] <Keybuk> I always file bugs ;)
[19:36] <ogra> NCommander, i would have told you ;)
[19:36] <NCommander> ogra, oh, I know :-)
[19:39] <ogra> Keybuk, didnt you say upstart makes extensive use of pselect as well ?
[19:39] <Keybuk> some versions do, yes
[19:39]  * ogra thought he remembered something like that
[19:39] <ogra> ah
[19:39] <Keybuk> I suspect there's a few programs that use it
[19:39] <ogra> likely
[19:39] <Keybuk> since the entire point of the syscall is it solves a difficult race condition
[19:39] <ogra> though i didnt see any issues yet
[19:39] <NCommander> Ah
[19:39] <Keybuk> you probably have seen issues
[19:40] <NCommander> yeah
[19:40] <Keybuk> and just not realised it
[19:40] <ogra> *but* that might be because 80% of the arm kernels i use dont even have modules
[19:40] <NCommander> At least they have syscall ids reserved
[19:40] <Keybuk> it could show up simply as zombie processes staying around and a parent not reaping them
[19:40] <ogra> so devices dont change usually
[19:40] <NCommander> Oh, I had that
[19:40] <Keybuk> it could show up as a module not loading or a removable device not being activated
[19:40] <Keybuk> it could show up as a dns timing out instead of resolving for no apparent reason
[19:41] <ogra> i might have seen the latter
[19:41] <ogra> unlikely i saw the first
[19:41] <ogra> usually my removable device carries the rootfs ... so its there before udev ...
[19:42]  * NCommander is currently trying to find where in the kernel ppoll/pselect are actually defined so I can see the implementation
[19:42] <ogra> unistd.h or so
[19:42] <NCommander> ogra, oh, no, the actual function :-)
[19:42] <ogra> in arm they are just a comment
[19:43] <ogra> right :)
[19:43] <NCommander> ogra, right, but I want to see the x86 implementation so I know what it will take to implement
[19:44] <ogra> yep, understood
[19:44]  * NCommander suspects its a large blob of ASM
[19:49] <NCommander> Keybuk, ok, this is kinda weird. I found the function, its a blob of C thats dependent on HAVE_SET_RESTORE_SIGMASK existing, but only x86, ia64, and sparc64 seem to have it, which means this bug also effects powerpc, and pa-risc
[19:50] <Keybuk> arch/powerpc/include/asm/thread_info.h:#define HAVE_SET_RESTORE_SIGMASK 1
[19:50] <Keybuk> powerpc has it
[19:50] <Keybuk> and who cares about pa-risc?!
[19:50] <ogra> IBM !!
[19:51] <NCommander> Keybuk, hrm, it must not exist in 2.6.26, since that was the source tree I was grepping :-)
[19:54] <Keybuk> I mean we don't support pa-risc
[19:54] <Keybuk> but we're going to support arm, and it's missing some rather handy syscalls that fix bugs!
[19:54] <NCommander> I get the point :-)
[19:54]  * NCommander is seeing whats goingt o be needed to implement it
[19:58] <tjaalton> ogra: no, HP !! :)
[19:59] <ogra> tjaalton, HP owns it ... for IBM its competition ;)
[19:59] <tjaalton> ogra: ah, good point :)
[19:59] <NCommander> so set_restore_sigmask is a single C function ...
[20:00] <NCommander> This seems too simple ...
[20:06] <NCommander> Keybuk, do you have some test code I could use to test ppoll/pselect's implementation?
[20:07] <Keybuk> I'm not sure what you mean?
[20:08] <slytherin> hi, is any of the kernel deveopers planning to update kernel on powerpc to bring it in sync with i386?
[20:09] <ScottK> NCommander: ^^
[20:09] <NCommander> slytherin, yes we are, TheMuso working on a mechanism to allow us to stay easily in sync w/ the main kernel
[20:09] <slytherin> NCommander: cool
[20:11] <slytherin> by the way, does anyone know why I have suddenly got non-working mouse and keyboard at GDM. I am running latest jaunty.
[20:14] <tjaalton> LaserJock: btw, looking at the current gnome-session code.. and g-s-s is still there
[20:14] <seb128> tjaalton: you want to work on GNOME? ;-)
[20:15] <tjaalton> seb128: hehe :)
[20:15] <tjaalton> seb128: I was just worried that the new g-s would have removed g-s-s --kill --silent
[20:15] <LaserJock> tjaalton: it is there, it just doesn't work
[20:15] <tjaalton> it's really useful on classrooms
[20:15] <tjaalton> LaserJock: ah, now that's interesting :)
[20:16] <seb128> nothing got killed, that's just need code and things are still not there or working correctly yet
[20:16] <LaserJock> tjaalton: they rewrote the core fo gnome-session so all the outside bits are there but they don't work
[20:16] <tjaalton> seb128: I'm checking the upstream bugs now to see if it's reported or being worked on
[20:17] <seb128> not sure about this one but the session storing is being worked
[20:17] <tjaalton> that's good
[20:17] <seb128> the GNOME trolls on this channel are not really useful though
[20:18] <tjaalton> I also had a quick look at the gvfs webdav bugs, and seems like it's not maintained at all :/
[20:18] <tjaalton> not that I've had much time to test it, but it's going to be used extensively here..
[20:19] <tjaalton> seb128: who is the upstream gvfs guy to contact?
[20:20] <seb128> tjaalton: there is not one guy, depends of the code you want to change
[20:20] <seb128> tjaalton: ah, webdav
[20:20] <tjaalton> yes, gvfsd-dav
[20:20] <seb128> tjaalton: that's gicmo on IRC
[20:20] <tjaalton> there are 10+ bugs upstream that have no replies
[20:21] <tjaalton> ok thanks
[20:21] <seb128> that's not a lot
[20:21] <LaserJock> tjaalton: yeah, common problem :(
[20:21] <tjaalton> well, they are showstoppers
[20:21] <tjaalton> it's not usable atm
[20:21] <LaserJock> seb128: do you know if anybody is maintaining g-s-t upstream? I looked at svn but it seemed pretty dead
[20:21] <seb128> that's not really true, depends of the use you want to do rather
[20:22] <seb128> LaserJock: no, nobody upstream nor in ubuntu, it's being deprecated
[20:22] <seb128> LaserJock: we just need an user admin tools and can stop using it on the default installation
[20:22] <LaserJock> seb128: in favor of?
[20:22] <tjaalton> anyway, I'll poke him and ask
[20:22] <tjaalton> g-s-t = gnome-search-tool?
[20:22] <calc> tjaalton: gnome-system-tools (iirc)
[20:23] <seb128> tjaalton: he's busy with university recently and knows about some issues, should be better in some weeks if I understood him correctly
[20:23] <LaserJock> seb128: so "we" is Ubuntu or ?
[20:23] <tjaalton> calc: ah ok, so many components :)
[20:23] <seb128> LaserJock: no, we being osx on this channel ;-)
[20:23] <calc> LaserJock: of course deprecation in gnome doesn't mean there is a replacement.. they just throw stuff out for fun ;-)
[20:23] <tjaalton> seb128: thanks, shouldn't be a problem
[20:23] <seb128> calc: it's not deprecated in GNOME
[20:23] <LaserJock> calc: that's what I was worried about
[20:24] <jelmer> slangasek, hi
[20:24] <seb128> could people stop trolling there
[20:24] <seb128> I'll reply when people have constructive comments, I'm not interested in trolls
[20:24] <LaserJock> I haven't seen any trolls
[20:24] <calc> seb128: ok is gnome-session going to be fixed for 2.26? :)
[20:24] <seb128> not reply to those trolls
[20:24]  * calc gets users filing bugs against OOo because of that
[20:25] <tjaalton> calc: according to the upstream bug, lucas rocha is working on it
[20:25] <calc> s/troll/disillusioned user/
[20:25] <seb128> same difference
[20:25] <LaserJock> s/disillusioned/frustrated/
[20:25] <seb128> it seems you guys don't understand how opensource is working
[20:26] <LaserJock> don't give me that
[20:26] <seb128> g-s-t is no deprecated there is just nobody interested to work on it
[20:26]  * calc thinks Gnome thinks it is Apple and can just foist stuff on users... but Gnome doesn't have a reality distortion field like Jobs has for Apple
[20:26] <seb128> other distros have their own set of tools
[20:26] <seb128> and ubuntu maintainers are too busy
[20:26] <seb128> and perl is not the best thing to write desktop softwares
[20:26] <LaserJock> seb128: so Gnome, as a whole, doesn't feel like g-s-t is important to maintain?
[20:27]  * calc is tryin to reach 0 new bugs for OOo
[20:27] <seb128> there is no GNOME as a whole having ressources to thrown on code
[20:27] <calc> LaserJock: from what i can see in g-s-t most of it is duplication at this point, but the idea in general seems sound as long as it is not in perl
[20:27] <seb128> GNOME is not a company
[20:27] <seb128> it's just a project of volunteers writing code
[20:28] <seb128> if somebody stops working on a software what do you suggest doing?
[20:28] <LaserJock> finding people to take it over
[20:28] <LaserJock> putting out a call for volunteers
[20:28] <calc> LaserJock: like you? :)
[20:28] <seb128> you are welcome to try
[20:28] <LaserJock> calc: we'll yeah
[20:28] <LaserJock> I've been seriously trying to figure out what to do with user management
[20:28] <seb128> it's easy, just make a call to find people to fix all the bugs and write new code
[20:28]  * calc would have volunteered to take over libgweather but it seems upstream is alive and happy with what they are doing
[20:29] <seb128> calc: I think you are overeacting to minor changes on this one
[20:29] <calc> seb128: there is no way to tell which station it is using anymore and what it calls 'Houston' is a 4000 sq km area
[20:29] <LaserJock> I was thinking that g-s-t was just going through a lull
[20:29] <seb128> you flamed upstream before waiting for any comment from their part or before knowing if they were interested to reconsider the changes
[20:30] <calc> seb128: wheather is definitely different from one side to the other, often
[20:30] <LaserJock> if they plan to deprecate it then that's a whole different story
[20:30] <seb128> LaserJock: they don't but same difference
[20:30] <seb128> LaserJock: redhat as *-admin, mandrake has mandraketools, suse has yast
[20:30] <calc> seb128: that combined with all of what gnome upstream has been doing in general and i think will be getting rid of gnome entirely from my system by 9.04 at minimum
[20:31] <seb128> LaserJock: ie, nobody is paying people to work on g-s-t, so if nobody show up to write on ugly perl code it's not going to change a lot
[20:31] <LaserJock> seb128: so Gnome gives up on providing useful system administration tools?
[20:31] <calc> they have broken gnome-session, gdm, audio, and who knows what else with the claim they will eventually get around to fixing it
[20:31] <calc> but release it as 'stable' completely broken
[20:31] <seb128> LaserJock: dunno what you consider GNOME to be but you seem to have no sense of reality
[20:31] <calc> so seeing them go on to break gweather was the last straw for me, i'm dumping gnome for my systems
[20:32] <LaserJock> seb128: that's rather rude and uncalled for
[20:32] <LaserJock> seb128: please stop making personal attacks on people for raising concerns
[20:32]  * calc thinks he will switch to something that people don't enjoy breaking like flubox or something
[20:32] <seb128> LaserJock: GNOME is an agregation of project maintained by volunteers, GNOME decide on what component they ship but they don't have nn people they can order to write new softwares
[20:32] <calc> seb128: they could however change commit rules to not cause regressions
[20:32] <LaserJock> seb128: no, but you know darn well there's organization there and people can make efforts toward getting things going
[20:33] <seb128> LaserJock: that's not GNOME though but those organizations
[20:33] <LaserJock> seb128: the gnome community
[20:33] <seb128> calc: they could but one of the issue is that things are perceived to not move enough there
[20:33] <seb128> LaserJock: what the community wants do not give you magically people writting code though
[20:34] <LaserJock> seb128: of course not, I didn't say that
[20:34] <seb128> calc: they have broken gnome-session and that's about it
[20:34] <calc> LaserJock: i think that the issue you are seeing wrt g-s-t isn't really something that can be solved, if no one wants to work on it then no one does
[20:34] <LaserJock> but if Gnome, as a community, says "we dont't really care about system administration tools", that's a bit frustrating
[20:34] <seb128> and that's the fedora guys pushing too hard for changes
[20:34] <calc> seb128: so they are backing out the changes for gnome-volume?
[20:34] <seb128> LaserJock: they do care, they is just nobody wanting to code on those
[20:35] <calc> seb128: because it now uses pulseaudio and pulseaudio is known broken on many audio systems
[20:35] <calc> seb128: the new gnome-volume requires pulseaudio aiui and from looking at it
[20:35] <seb128> calc: it's being used since hardy, wake up, that's not GNOME breaking anything now
[20:35] <calc> seb128: but now you can't change your volume anymore if you don't use pulse on Gnome
[20:35] <seb128> that's being discussed on the upstream lists though
[20:35] <calc> seb128: yes and it is looking like they are going to force pulseaudio in broken as it is
[20:35] <seb128> calc: the volume applet should still be working it's using gstreamer
[20:36] <seb128> there is one issue there
[20:36] <seb128> which is that fedora is doing most of the GNOME work
[20:36] <seb128> so there is nobody having weight to counterbalancer their decisions
[20:36] <calc> which is why gnome org/foundation(?) needs to adopt a no regressions policy
[20:37] <LaserJock> I find it frustrating that you're saying that Gnome isn't a company but it's hard to do things becase of companies/distros
[20:37] <calc> so things like this can't get just forced into gnome
[20:37] <seb128> LaserJock: GNOME has no real power, softwares maintainers can basically do what they want
[20:37] <slangasek> jelmer: hello
[20:37] <calc> seb128: gnome board could throw out a developer that is misbehaving like debian has done on occasion
[20:38] <seb128> right and stale GNOME for good
[20:38] <jelmer> slangasek, What were the URLs for those grub branches?
[20:38] <seb128> let's thrown out the only people doing things
[20:38] <calc> seb128: stale gnome > than broken gnome
[20:38] <jelmer> slangasek, I should've put them in the bug report, and can't find them anymore.
[20:38] <seb128> calc: I don't agree, they are rewritten a lot right now and that will benefit GNOME 3 which we should get for the next lts
[20:38] <calc> ok
[20:38] <LaserJock> in the mean time people leave because of regressions
[20:39] <seb128> either you push for new changes and break things on the way for a while
[20:39] <slangasek> jelmer: lp:~ubuntu-core-dev/grub/ubuntu, svn://svn.debian.org/svn/pkg-grub/grub/trunk
[20:39] <seb128> or maintain several codebase and slow work because you have to work on several versions
[20:39] <jelmer> slangasek, thanks
[20:39] <slangasek> jelmer: thank you :)
[20:39] <calc> seb128: broken things (broken on purpose) should never make it into a stable release
[20:39] <seb128> nothing is broken on purpose
[20:40] <seb128> that's just life, the guy who started the gnome-session rewrital got a new job and moved between countries during the cycle
[20:40] <calc> seb128: well then described as rewriting and pushing it out before its done, however you want to say it
[20:40] <LaserJock> seb128: gnome-session without any session managment isn't broken on purpose?
[20:40] <seb128> no
[20:40] <seb128> on purpose, that's just trolling
[20:40] <calc> seb128: they should have reverted the change before release in the gnome-session case then
[20:40] <seb128> other code depends of the new dbus api that's not so trivial
[20:41] <LaserJock> ok, but they left all the UI and exposed stuff that doesn't work
[20:41] <LaserJock> that's broken and that's on purpose
[20:41] <seb128> the guy started on the rewrital, was on track mid cycle and then vanished because he was changing job, country, etc
[20:41] <LaserJock> they knew what stuff didn't work and choose to keep it anway
[20:42] <seb128> LaserJock: I'm near of being really unpleasant with you now
[20:42] <seb128> "on purpose"
[20:42] <LaserJock> seb128: likewise
[20:42] <seb128> yeah, they decided "let's screw users"
[20:42] <LaserJock> I wouldn't go that far
[20:42] <seb128> 'let's start on something and break it just to laugh to users'
[20:42] <seb128> that's what on purpose mean
[20:42]  * calc thinks this proves the case of rewrites shouldn't be done on trunk
[20:42] <LaserJock> I didn't say they did it with malicious intent
[20:42] <LaserJock> but I think they did do it knowingly
[20:42] <seb128> that's what on purpose means
[20:42] <LaserJock> no
[20:42] <seb128> no, they didn't
[20:43] <seb128> they were on track mid cycle
[20:43] <LaserJock> yes they did!
[20:43] <seb128> the guys said he would fix it
[20:43] <seb128> and he didn't
[20:43] <calc> ok s/on purpose/knowingly/
[20:43] <seb128> no
[20:43] <LaserJock> right
[20:43] <LaserJock> which is why you don't release it when somebody goes AWOL
[20:43] <calc> they should definitely have known it was broken before the release and just released with it as is
[20:43] <LaserJock> we do that all the time in Ubuntu
[20:43] <seb128> they got screwed by somebody who didn't deliver
[20:43] <seb128> no we don't
[20:43] <LaserJock> I don't know why it'd be so hard for an organization like GNOME to figure out
[20:43] <seb128> we could have downgraded gnome-session
[20:43] <seb128> and we knew about the issue
[20:44] <calc> LaserJock: in Ubuntu if we have known broken things we revert them generally with a XreallyY syntax for packaging
[20:44] <seb128> that's the other side of fixed schedule
[20:44] <LaserJock> sure
[20:44] <LaserJock> but gnome left things exposed
[20:44] <seb128> we knew it one month before intrepid
[20:44] <seb128> but nobody stepped to do the job
[20:44] <LaserJock> just kinda dropped it out there where it was
[20:44] <seb128> we did the same
[20:45] <seb128> again GNOME has no paid people they can use at will
[20:45] <LaserJock> sure
[20:45] <LaserJock> but it shows that perhaps people are caring about what's going on enough or some other institutional/community issue
[20:45] <seb128> what you do when you know you need somebody working for a week to fix the situation but have only overworked volunteers?
[20:45] <seb128> either you delay schedule or just ship what you have
[20:45] <LaserJock> it's called community managment
[20:46] <seb128> you can't order community
[20:46] <LaserJock> well, you can  quickly try to patch things up the best you can
[20:46] <seb128> there was call for volunteer to fix those issues
[20:46] <seb128> nobody stepped there
[20:46] <seb128> who is you?
[20:46] <LaserJock> i.e. take out gnome-session-save and the "Remember current running applications"
[20:46] <tedg> seb128: I think the real problem is that no one defined a date where it has to be fixed to get in.  One of the things I've liked about the Evolution-dbus situation is that if it doesn't do XYZ by date A it doesn't get in this release.  No one did that for gnome-session, which I think, was a failure of the release team.
[20:46] <LaserJock> tedg: exactly my point
[20:46] <m1k3> What gives with Ubuntu using OLD ffmpeg? from ffmpeg website, "It is a key component in many multimedia projects and has new features added constantly. New, official "releases" are few and far between. In short, if you want to work with FFmpeg, you are advised to go along with SVN development rather than relying on formal releases."
[20:46] <seb128> tedg: right, they didn't want to do a gdm situation again
[20:47] <seb128> that's really fedora's fault
[20:47] <calc> seb128: perhaps this is something we should look into to help out gnome then? not something to help out Ubuntu specifically, but to help them get their release engineering going properly, since we heavily depend on upstream Gnome being in a usable state
[20:47] <tedg> There's generally an assumption that existing modules will continue to get in, even with complete rewrites.  I don't think that should be allowed.
[20:47] <seb128> calc: they know about the issue now, that's new issues for them, they didn't really have such issues until recently
[20:48] <seb128> they didn't accept the new gdm for several cycles because it was not ready
[20:48] <tedg> calc: I think the processes is being adjusted, but yes, we need to clone seb :)
[20:48] <calc> seb128: yet people were still trying to defacto force PA into 2.26... so it seems they still need help
[20:48] <seb128> but that created tension with the fedora guys who are doing the work and are major contributors
[20:48] <seb128> calc: again fedora's decision
[20:48] <seb128> and there is nobody to balancer their influence there
[20:49] <calc> seb128: which is why i suggest we see if we can help influence them somehow
[20:49] <seb128> opensource is sort of a who-do-work-has-something-to-say
[20:49] <seb128> we can by starting doing work
[20:49] <slangasek> seb128: well, there was also the gvfs debacle where GNOME stopped being a useful SMB browser just in time for an LTS :(
[20:49] <seb128> slangasek: again fedora did the changes and we picked the wrong cycle for a lts and where stucked between sucking choices
[20:50] <calc> seb128: but as gnome is a real organization (i think?) it can decide what to let those who are doing do
[20:50] <calc> seb128: it can't tell them what to do, but it can decide what to accept
[20:50] <seb128> right, they didn't accept the new gdm when it was not ready
[20:50] <slangasek> seb128: I would argue that if there's /any/ "stable" cycle in which GNOME is landing that large of a regression, there's a problem with the release management per se
[20:50] <seb128> the new gnome-session was judged as mostly working
[20:50] <calc> seb128: but they accepted the gvfs issue slangasek brought up and gnome-session
[20:50] <seb128> nobody raised the issue about session storing during the unstable cycle
[20:51] <LaserJock> seb128: I think I read about it before, but I could be wrong
[20:51] <seb128> the gvfs smb issues was raised after they rolled the stable version
[20:51] <calc> seb128: i can't even run jaunty right now because it is too buggy, i'm sure there are plenty of people in that boat
[20:51] <seb128> slangasek: the issue is that GNOME has no manpower they control
[20:51] <slangasek> seb128: but GNOME should have control over what goes into a release
[20:51] <LaserJock> but I don't see how they could have accepted gnome-session when almost all the user-visable features are missing
[20:51] <seb128> slangasek: so either they reject changes until they are ready which tend to discourage people or try to go forward and do what they are doing
[20:52] <slangasek> discouraging people who are otherwise going to wind up breaking the stable release for users is not a loss
[20:52] <seb128> slangasek: they do, they just have the feeling that GNOME is not moving fast enough compared to other desktop, users expectations, etc and that they should go forward rather than stepping to stop changes because of issues
[20:52] <tedg> What I hope that we can do in the future is do thing like what we're doing for gdm/gpm for this release.  Do parallel releases of version.
[20:52] <calc> slangasek: and after a while the developers will understand what they need to do to get into the release and just go along with it
[20:53] <calc> seb128: the other desktop.. KDE? is broken as well as I understand it
[20:53] <slangasek> seb128: who is "they" and who is it they're worried about trying to move as fast as?
[20:53] <tedg> I think that provides a little both worlds.  Allows for easily available experimentation while still allowing for stable releases.
[20:53] <seb128> LaserJock: the fedora guys didn't perceive session storing as an important thing since it never worked correctly
[20:53] <calc> seb128: so trying to be like KDE 4.x releases isn't particularly helpful
[20:53] <slangasek> seb128: heh
[20:53] <seb128> and we didn't either
[20:53] <calc> however dropping session storing also got rid of the save before logout bit
[20:53] <broonie> seb128: The other alternative is to flag things more clearly to users (possibly using something like tedg mentions with alternative versions available).
[20:53] <LaserJock> seb128: then why is it in the UI?
[20:53] <seb128> and nobody raised that as an issue until late
[20:54] <seb128> LaserJock: I already explained you that the guy doing the work changed job and country no?
[20:54] <slangasek> well, session saving /used/ to work just fine for me, and has progressively degraded over the last three releases
[20:54] <LaserJock> I don't understand why there's a UI for something in a stable release for something that doesn't work and nobody cares about
[20:54] <calc> on the other end of this argument is Sun OOo which takes forever to get anything in, so it is a balancing act
[20:54] <seb128> because the guy stopped his work mid cycle
[20:54] <seb128> and nobody else picked up then
[20:54] <LaserJock> can it really be that hard to remove the button and remove gnome-session-save?
[20:54] <slangasek> I probably would've noticed it sooner myself if I didn't already find restarting my sessions to be a hassle
[20:55] <seb128> LaserJock: send a patch?
[20:55] <tedg> slangasek: The problem is that it didn't work for a bunch of use cases, and didn't recover properly.  For instance if you saved the session on a autostart app.
[20:55] <seb128> LaserJock: nobody is working on this code
[20:55] <LaserJock> seb128: ok, but that's not exactly a great excuse for releasing broken features
[20:55] <seb128> lot of applications don't store their workspace or position or open work either
[20:55] <LaserJock> sure
[20:56] <seb128> LaserJock: nobody said that's an excuse, it's just how it happened, the same reason it happened for ubuntu
[20:56] <LaserJock> but when you have a gtk button that's connected to an empty callback ..
[20:56] <slangasek> tedg: I agree, it was broken before.  But now it's more broken.
[20:56] <tedg> The problem is that the fix isn't good either.  Inventing a new API isn't the solution to poor implementations of the old one.
[20:56] <seb128> LaserJock: there is a fixed scheduled, known issue but nobody stepping up, either you delay or ship what you have
[20:56] <LaserJock> and an "executable" that doesn't work
[20:57] <seb128> that's similar to what ubuntu do
[20:57] <seb128> we don't have the manpower to fix all the upstream code
[20:57] <tedg> While we can argue about the past, I'm more concerned about the future.  seb128, is gnome-session looking better for Jaunty?
[20:57] <seb128> and we have a fixed schedule
[20:57] <LaserJock> sure
[20:57] <seb128> so we do the best we can
[20:57] <LaserJock> but we rely on upstreams to have some sense of QA
[20:57] <seb128> tedg: session storing will be fixed for jaunty
[20:58] <tedg> \o/
[20:58] <seb128> LaserJock: and if they don't we can be screwed, same for GNOME
[20:58] <slangasek> but, er, GNOME /is/ the upstream? :)
[20:58] <seb128> GNOME doesn't have paid people
[20:58] <LaserJock> seb128: but I'm interested in how that institutionally happens and what could be done to fix it
[20:59] <seb128> they just do a desktop with softwares volunteers are writting
[20:59] <slangasek> seb128: no, but that's no excuse for not structuring themselves in a way that their QA is proportional to their development targets
[20:59] <slangasek> if that means they have to scale back their development, so be it
[20:59] <seb128> slangasek: you could say the same about ubuntu
[20:59] <seb128> we did ship with those bugs too
[20:59] <LaserJock> and we are constantly adjusting QA and development procedures in the wake of EPIC FAILs
[20:59] <slangasek> but we didn't drive the development of the half-delivered features
[20:59] <seb128> we just ship way too much code for the ressources we have
[21:00] <seb128> slangasek: they didn't either, they don't control the people doing the changes, they are not paid by GNOME
[21:00] <LaserJock> you act as if the only way to "control" anything is to pay people to do it
[21:00] <LaserJock> which seems rather odd
[21:00] <seb128> no, but when you don't have ressources you can use you are limited in choices
[21:01] <seb128> either you are conservative and wait to see before doing a change
[21:01] <calc> LaserJock: if they are paid they tend to disappear less frequently ;-)
[21:01] <LaserJock> calc: sure, but you compensate
[21:01] <seb128> or you decide to go with whatever somebody is doing and get screwed if they stop on the way
[21:01] <LaserJock> FLOSS projects have been dealing with flakes for years :-)
[21:01] <calc> but i think a better solution to this would be to just not allow major rewrite type changes to happen on trunk to begin with
[21:01] <calc> its equivalent to us using ppa's
[21:01] <seb128> that's the flip side of fixed schedule with limited ressources
[21:02] <seb128> there is not a zillion of way
[21:02] <seb128> either you
[21:02] <seb128> - delay the version
[21:02] <seb128> - allow extra ressources
[21:02] <seb128> - ship what you have
[21:02] <seb128> there is no way around those
[21:02] <calc> i could try to shove OOo 3.1 into jaunty but i think it will likely not make it in time so do it via ppa for people to play with
[21:02] <seb128> delay the version is what debian does
[21:02] <seb128> allow extra ressources required having some to allow
[21:02] <seb128> and ship what you have is what happens there
[21:02] <LaserJock> seb128: I think that's a little simplistic
[21:02] <seb128> what are the other choices?
[21:03] <LaserJock> you can have release management teams and QA structures
[21:03] <LaserJock> best-practices
[21:03] <calc> and debian does have testing/unstable so it doesn't do the equivalent of direct commits to trunk
[21:03] <seb128> calc: we could stay on not current GNOME, the issue is that GNOME fix a lot more issues than we could do with the ubuntu ressources we have
[21:03] <slangasek> seb128: sorry, but I don't think either of those options you propose constitute very good release management; the better answer is "sort out a rollback path in advance and identify a milestone at which x, y, z features need to be implemented before you commit to it"
[21:04] <seb128> slangasek: I agree with you and that's what GNOME usually do
[21:04] <seb128> the gvfs smb issue was not raised before stable
[21:04] <calc> seb128: true, and even then that wouldn't help that much since eg the gnome-session issue was broken for several upstream releases, looks like it might be fixed in 2.25
[21:04] <seb128> which might shows they (and we as a distributor too) don't do enough pro-active testing
[21:04] <seb128> they delayed the new gdm
[21:04] <slangasek> seb128: hmm, was that a failure on our side?  I thought we had reports about gvfs smb borkage at least a month before the release
[21:05] <seb128> slangasek: a month before our release rather?
[21:05] <seb128> slangasek: we have our beta around their stable
[21:05] <seb128> and have our stable around their .1
[21:05] <slangasek> seb128: yes - and our beta is only 3 weeks before release, neh, so a month before release is before their stable? :)
[21:05] <slangasek> anyway
[21:06] <seb128> slangasek: well, it took me a while to get that would be a real issue for many users
[21:06] <seb128> and nobody else ringed any bell early either
[21:06] <slangasek> fwiw, the last two release cycles have taught me that I need to be proactive about upgrading to the devel release of Ubuntu early, and reporting all the bugs I trip over
[21:06] <slangasek> seb128: right, that's fair
[21:06] <seb128> what I was saying to the upstream guys recently
[21:06] <seb128> their recent screwing taught me to not upgrade automatically everything now
[21:06] <LaserJock> slangasek: except when there's nobody on the other end listening :(
[21:06] <slangasek> seb128: did upstream have any sort of post mortem after the gvfs smb thing, to try to understand what they could do better to prevent that in the future?
[21:07] <seb128> if that was this cycle I would not do the gnome-session upgrade
[21:07] <slangasek> LaserJock: I report them to LP, so seb128 is always listening to me ;)
[21:07] <LaserJock> slangasek: sure, but that's not always fair to seb128 :-)
[21:08] <seb128> slangasek: I don't think they really did
[21:08] <seb128> but the issue is clear
[21:08] <seb128> they didn't see the issue coming before their stable
[21:08] <slangasek> yes - the question is, how to make sure they have a perspective that lets them see the issue
[21:09] <seb128> they have all the discussion on public lists anybody can raise objection
[21:09] <LaserJock> do you think like having a bit more publicized pre-releases would help?
[21:09] <tedg> slangasek: Convince Fedora that users like being able to upgrade their systems? ;)
[21:09] <seb128> Josselin is raising concerns about the sound changes for 2.26 at the moment for example
[21:09] <slangasek> seb128: I don't think it's reasonable to expect users of GNOME to have to track a discussion mailing list
[21:09] <seb128> we did raise concern about the new gdm which didn't get accepted upstream
[21:09] <LaserJock> like for KDE the Kubuntu clan backport all of KDE betas and rcs so peple can try them out
[21:09] <seb128> slangasek: well, if somebody perceive an issue it should be raised by some way
[21:09] <slangasek> for major changes, they ought to actively seek feedback from a wider base
[21:09] <LaserJock> would that help Gnome out to find those issues earlier?
[21:10] <seb128> LaserJock: GNOME roll new version often enough and those are in major unstable distros
[21:10] <seb128> they didn't screw that much and are learning from it too
[21:10] <slangasek> LaserJock: I'm not sure there's a market for pre-release backports of GNOME, and I'm pretty sure there isn't the manpower
[21:10] <LaserJock> seb128: but I've never seen like a "Get 2.25.x for Intrepid today!"
[21:11] <seb128> they had issues on gvfs (specific to smb that linux hackers usually don't rely on and didn't notice)
[21:11] <LaserJock> slangasek: is that just because more is going on with the KDE 4 cycle
[21:11] <LaserJock> ?
[21:11] <seb128> and on gnome-session (they didn't perceive session storing being such an issue since most of hackers don't use it)
[21:11] <LaserJock> I don't use it either
[21:11] <slangasek> LaserJock: speaking frankly, at least for myself I think the unstable GNOME changes are the biggest reason *not* to upgrade to devel releases...
[21:11] <seb128> there is sort of disconnection between hackers and users expectations there
[21:12] <slangasek> seb128: I cannot fathom why hackers would be less likely to use session saving
[21:12] <seb128> otherwise they didn't really screw up anything else
[21:12] <seb128> slangasek: not less likely, that's just that nobody in the upstream community screamed
[21:12] <slangasek> LaserJock: i.e., if you're willing to run the GNOME stuff that's in development, might as well run it on the Ubuntu devel series
[21:12] <LaserJock> seb128: so do you know if anybody is going to write a user and group admin tool for Ubuntu then if upstream seems to not care?
[21:13] <seb128> the fedora guys considered that it never worked correctly since it was not storing workspace, position, open work etc informations for most softwares anyway
[21:13] <LaserJock> slangasek: ahhh, I see what you mean
[21:13] <seb128> LaserJock: they still ship g-s-t which works
[21:13] <LaserJock> seb128: well, except I want to modify it
[21:13] <ScottK> slangasek: In Kubuntu we do get quite a number of people who are willing to run pre-release KDE versions on the current Ubuntu release.
[21:13] <seb128> LaserJock: there is just nobody actively fixing issues there because nobody seems interested, how do you solve that without having money to spend ?
[21:13] <slangasek> anyway, where was I... oh yes, filing a critical bug on NM
[21:13] <slangasek> ;)
[21:14] <ScottK> I think it's a useful risk mitigation for people who aren't up to dealing with infrastructure breakage.
[21:14] <LaserJock> seb128: dude, we do it all the time
[21:14] <seb128> LaserJock: you are welcome to modify it and take over maintainship upstream if you want
[21:14] <LaserJock> that's how MOTU works, making slaves out of volunteers ;-)
[21:14] <slangasek> seb128: "vision"
[21:14] <LaserJock> seb128: well, that's sort of what I'm looking at
[21:14] <seb128> slangasek: vision doesn't make things magically happen
[21:14] <slangasek> (if you build... the vision..., they will come)
[21:15] <LaserJock> I myself, am unlikely to be able to just up and write a new tool
[21:15] <seb128> there is nothing fancy in an user management tool
[21:15] <pecisk> seb128: but they show directions :)
[21:15] <slangasek> seb128: what it does is encourage the people who are most likely to be enthusiastic about helping solve the problem feel welcome
[21:15] <LaserJock> however, the current tools aren't so great to hack on because of being perl/C
[21:15] <slangasek> that's not a sentence, but maybe you get the idea
[21:15] <seb128> right
[21:15] <LaserJock> what I'm wondering is if it's better to start a new pygtk tool for Ubuntu
[21:15] <pecisk> guys, why are you doing this on friday night? :)
[21:15] <LaserJock> or try to restart upstream
[21:15] <LaserJock> or ...
[21:16] <seb128> the g-s-t situation is a bit special since almost no distro use it
[21:16] <seb128> so it's only upstream debian and ubuntu basically
[21:16] <LaserJock> seb128: right, I guess I knew that but didn't know it :-)
[21:16] <seb128> and ubuntu is using the redhat tools for different things now
[21:16] <seb128> and gnome-panel clock applet can set time now
[21:16] <seb128> and network-manager replactes network-admin,  etc
[21:17] <LaserJock> slangasek: right, I'd like to help upstream some, but if they're not even enthusiastic about their software I'm not really either :/
[21:17] <seb128> you should help the fedora guys to work on the new user admin tool
[21:17] <LaserJock> seb128: they've got one?
[21:17] <seb128> they have some plans and mpt contributed to the discussion
[21:17] <pecisk> seb128: I think if NM wouldn't be so full of small quirks no one would even notise disappearance of g-s-t network-admin
[21:18] <seb128> pecisk: nm 0.7 is supposed to do eveything network-admin does now
[21:18] <slangasek> oh, I don't use g-s-t network-admin
[21:18] <slangasek> I use NM exclusively
[21:18] <seb128> me too
[21:18] <slangasek> because it's best-of-breed for wireless managemen
[21:18] <slangasek> t
[21:18] <pecisk> seb128: problem is that it doesn't. NM guys even claim that they don't plan to do ppp any time soon.
[21:18] <LaserJock> it took a while, but for me it's great
[21:18] <slangasek> unfortunately, that's not saying much, and it's always getting in my way in other ways
[21:19] <seb128> pecisk: network-admin has many limitation too
[21:19] <seb128> configuring wireless using it is the suck
[21:19] <slangasek> yes
[21:19] <seb128> do you know of anybody who managed to configure a dsl connection?
[21:19] <pecisk> seb128: sure, and I generally happy about switch
[21:19] <slangasek> pecisk: fwiw, it's not friday night for all of us. :)
[21:20] <seb128> network-admin is a buggy piece of code written in perl and having many limitation
[21:20] <LaserJock> seb128: do you happen to know the name of red hat's user admin tool?
[21:20] <seb128> network-manager is doing a much better job
[21:20] <mvo> LaserJock: have you considered just replacing the perl backend with a python one for the user-admin tool? i haven't looked into it in a while but it was one of the ideas floating around
[21:21] <slangasek> mvo: one word: liboobs
[21:21] <pecisk> seb128: where is link about redhat rewriting user admin? :) would like to take a look
[21:21] <LaserJock> mvo: I have no idea
[21:21] <seb128> LaserJock: no, maybe ask mpt he participated to the discussions about the new tool
[21:21]  * calc bbl, dropping off my son
[21:21] <seb128> pecisk: that was discussed in some desktop team meeting previous cycle and somewhere on their wiki
[21:22] <LaserJock> mvo: it's just that Edubuntu wants to get user administration better, but not a lot of experienced programmers
[21:22] <pecisk> nice
[21:22] <LaserJock> and so I've been trying to look around to see what the best course of action would be
[21:23] <slangasek> LaserJock: I think you'll find that the UI / model are the hard part, not the programming
[21:23] <mvo> slangasek: right
[21:24] <seb128> anyway GNOME did screw up some things recently
[21:24] <LaserJock> slangasek: perhaps, but if all people know is pythong it's hard to get them wanting to hack on perl/C
[21:24] <seb128> they learnt from it and we did too
[21:24] <LaserJock> yikes, bad typo I did there :-)
[21:24] <pecisk> seb128: I really hope so :) I love GNOME as desktop env. and don't wanna leave
[21:24] <seb128> I don't think it's fair to troll that much on them breaking things
[21:24] <seb128> they only really screwed gvfs-smb and gnome-session
[21:25] <seb128> and that's because nobody raised enough concern early
[21:25] <LaserJock> seb128: well, the point wasn't to troll, but rather to discuss/figure out what's going on
[21:25] <pecisk> seb128: that indicates that isn't tested properly. We need some written, automated tests
[21:26] <LaserJock> of course frustration was also in there, so sorry for some of that
[21:26] <seb128> pecisk: that and that it's not always easy to know what users expect
[21:26] <mvo> well, liboops provides the gobject mapping to the dbus backend. the dbus backend could be written in python instead of perl. now its the question if the gobject model for the user is a) good b) worth the effort
[21:26] <seb128> they knew about session storing being broken
[21:26]  * mvo has no answer to this question
[21:26] <seb128> but they though nobody was really relying on it since it never worked correctly
[21:26] <mvo> but whatever is done, a dbus/polkit based model very similar to g-s-t is probably the right ansewr
[21:27] <LaserJock> mvo: what if we want the UI to change a fair amount?
[21:27] <pecisk> seb128: of course, but users more or less expect desktop to work and be consistent
[21:27] <mvo> its kind of sad, g-s-t was really ahead of its time in a sense
[21:27] <seb128> pecisk: the intrepid desktop works and is consistent
[21:27] <pecisk> seb128: if there is a feature, it should work
[21:28] <pecisk> seb128: comparing to what? :) Hardy has different way to log out and switch off computer. PA completely changed way of doing things :)
[21:28] <mvo> LaserJock: well, the ui could talk to the same dbus service. when using python the liboops layer is not really needed
[21:28] <seb128> pecisk: depends of the feature, when you rewrite code you might decide to delay some things
[21:28] <walters> mvo: there is some gobject user management code in gdm that i happen to be looking at right now actually, but it's not really designed around management
[21:28] <pecisk> seb128: yes, but then distro or GNOME has to be sure it is mentioned and there is clear path to have to workaround problem
[21:28] <walters> s/user management/user modeling/ i guess
[21:28] <mvo> walters: interessting
[21:28] <pecisk> otherwise it creates confusion
[21:28] <pecisk> and lot of anger
[21:28] <seb128> walters: it's all you fault, you guys are going to fast in rewrites ;-)
[21:29] <pecisk> in both sides - users and developers
[21:29] <mvo> LaserJock: but then, if you write a new UI and a new backend you can as well skip the compatiblity with liboops I guess
[21:29] <walters> seb128: heh, well FWIW i'm personally kind of unhappy at the number of incompatible breaks
[21:30] <walters> though X SM *is* broken by design, it sucks to not have offered any replacement
[21:30] <pecisk> seb128: for example, there is vino caplet interface rewrite going on. Good developer added support for PnP autoconfiguration of firewall, but also removed Advanced tab and icons. I personally thought that vino finally got right gui, but seemingly developer thought otherwise.
[21:30] <seb128> walters: me too, I talked a bit to vuntz about it, I think GNOME should be careful about accepting rewrites too quickly the user perception about GNOME is not good for some cycles, too many things which used to work which are not in new versions
[21:31] <pochu> pecisk: what icons?
[21:31] <walters> seb128: yeah
[21:31] <mvo> LaserJock: g-s-t is using glade (well, .ui files) so a lot of the gui stuff can be done without code
[21:32] <LaserJock> mvo: well, messing with the UI without hooking it up to code doesn't work too well
[21:33] <seb128> walters: right, it's broken but some things were working, ie some software were closing correctly with the session before and now users are loosing work because it stopped doing that
[21:33] <maxb> Hmm, with that mesa build still pending, for amd64, would now be a _really_ bad time to try an upgrade?
[21:33] <mvo> LaserJock: depends on the changes :) but sure, if you want new functionality, then certainly not
[21:33] <walters> seb128: that is a more serious concern, yeah
[21:34] <pecisk> pochu: http://www.bani.com.br/lang/en/2009/01/new-vino-dialognova-tela-do-vino/
[21:34] <slangasek> asac: bug #320652 for you :)
[21:35] <walters> seb128: i think lucasr was looking at the session bug, hopefully we'll at least get some bare bones XSM support
[21:35] <seb128> walters: right
[21:36] <walters> i have a much better design for session stuff, hoping to get a chance to it at some point
[21:36] <pochu> pecisk: ah, the icons in the UI
[21:36] <pochu> pecisk: well, I wouldn't call that a regression, but YMMV
[21:36] <pochu> pecisk: although I think an advanced tab is nice to have
[21:36] <pochu> I'll talk to Jonh about it
[21:37] <seb128> that's another issue sometimes
[21:37] <pecisk> pochu: those icons didn't hurt anyone :) well, I personally like that sections of configuration has kind of visual indication. Helps on screens with huge resolutions and when you are farer from desktop than you would like.
[21:37] <seb128> there is nobody really looking at the design but maintainers do what they want
[21:37] <seb128> some take good choices, some are not
[21:37] <pecisk> pochu: and this dialog was actually one of few where it was done right imho
[21:38] <pochu> pecisk: yeah, I agree they're nice, but I wouldn't call that a regression ;)
[21:38] <tjaalton> maxb: yes, it would.. if you have intel
[21:38] <Amaranth> Although and "Advanced" button/tab/section probably means you've done something wrong in your application
[21:38] <Amaranth> s/and/an/
[21:38] <Amaranth> So that's not a big loss in the UI
[21:39] <pochu> Amaranth: not really, you can change the listening port there for example
[21:39] <pochu> or deactivate the wallpaper, or a few more things
[21:39] <Amaranth> pochu: I think avahi should make that unneeded
[21:40] <pochu> Amaranth: sorry for my ignorance :) but isn't avahi for local connections?
[21:40] <Amaranth> Sure but that's what vino is targeting
[21:40] <maxb> tjaalton: I don't really understand much about what mesa is, but I thought it wasn't solely intel-related? Am I save with an nvidia card?
[21:40] <pochu> not really
[21:40] <walters> mvo: http://svn.gnome.org/svn/gdm/trunk/gui/simple-greeter/gdm-user-manager.h btw, if it's useful
[21:41] <Amaranth> That's why the port and whether to draw the desktop background are 'advanced' and/or 'not needed' options
[21:41] <tjaalton> maxb: yes, nvidia diverts that stuff anyway
[21:41] <pochu> or not only
[21:41] <Amaranth> pochu: The UI makes it very clear vino is meant for LAN use
[21:41] <Amaranth> The UI and the defaults, rather
[21:41] <tjaalton> maxb: mesa provides the OSS libGL & DRI drivers
[21:41] <tjaalton> among other things
[21:43] <Amaranth> pochu: Although the UPnP autoconfiguration in the new one makes it clear the developer is conflicted on what the real use of the app is
[21:43] <pochu> Amaranth: does it? I have to admit I've never used vino if not with localhost, but I didn't think it was for local networks only
[21:43] <mvo> walters: thanks, I have a look (<- LaserJock might be interessting for you as well)
[21:43] <pecisk> pochu: well, there is no rules to say what is regression or not, so I can't objectively discuss about that ;)
[21:43] <pochu> pecisk: sure, that's why I said YMMV :)
[21:44] <walters> mvo: at this moment preparing a patch to make it into a public library since we need it for gnome-shell
[21:44] <pochu> pecisk: did you report a bug in bugzilla yet?
[21:45] <Amaranth> pochu: but vino is configured by default to work best on LANs, otherwise it wouldn't draw the desktop
[21:47] <pecisk> pochu: I thought that inform developer first is enough :)
[21:48] <pecisk> pochu: I left comment in that blog post
[21:48] <slangasek> Amaranth: "is meant for" -- um, I don't think it's reasonable to expect people who want /non/-local VNC to have to install a different implementation, or dig around in vino's guts
[21:48] <Amaranth> slangasek: You just have to know the port and have a fast connection or open up gconf-editor
[21:49] <slangasek> "know the port"?
[21:49] <Amaranth> hopefully the UI at least mentions the port number somewhere
[21:50] <Amaranth> and it doesn't
[21:50] <slangasek> heh
[21:50] <Amaranth> also: "Talk to the router and try to open the door there"
[21:50] <Amaranth> wtf
[21:51] <slangasek> clearly a typo, should be s/router/BBS/
[21:52] <Skiessi> is x known to not work correctly after the latest upgrade?
[21:52] <Skiessi> or wait I'll recheck if there's any updates
[21:53] <maxb> Skiessi: If your video hardware is intel and your architecture is amd64, yes, it's broken due to buildd lag
[21:53]  * Amaranth remembers to not restart X
[21:53]  * Amaranth stops working on compiz stuff that can freeze X
[21:53] <Skiessi> video hardware is intel but I think I'm using the 32-bit version
[21:54] <maxb> Skiessi: dpkg --print-architecture
[21:54] <Skiessi> okay. booting
[21:55] <Skiessi> i386
[21:55] <maxb> I guess you  have a different problem then
[21:55] <Skiessi> I'll take a pic :p
[21:56] <directhex> where would i file a bug against the start.ubuntu.com google page?
[21:56] <Laney> https://bugs.launchpad.net/ubuntu-website
[22:01] <directhex> aha, already open as lp 305905
[22:04] <pochu> Amaranth: well, it shows the port in the advanced tab in 2.24, that was pecisk was complaining about
[22:04] <pochu> Amaranth: and it uses the default VNC port, so there's not much you need to know unless you change it
[22:04] <Amaranth> In that case it's fine to not have it in the UI
[22:05] <Amaranth> and not drawing the wallpaper is usually not something you need to do
[22:05] <pochu> well, what's wrong with an Advanced tab?
[22:06] <pochu> I think it does no harm and otherwise you need to go to gconf
[22:06] <Amaranth> pochu: "Advanced" means "I failed to find a place for these and failed to make you not have to care about them"
[22:06] <slangasek> and somehow sending people to gconf is better?
[22:06] <Amaranth> like the background thing, it should do that on the fly if it detects your connection is bad
[22:07] <pochu> Amaranth: I disagree. Advanced means "I want to further customise it"
[22:07] <pochu> Amaranth: so, should we move NM's VPN to a config file or gconf, for example?
[22:08] <pochu> because if you plug your cable and it doesn't work, then it shouldn't be in the UI
[22:08] <pochu> (at least that's what I understand from your reasoning)
[22:09] <Amaranth> VPN is a large thing to setup and has it's own configuration section
[22:09] <Amaranth> and there is no way to automatically set it up
[22:10] <pochu> I don't think an Advanced tab means there's no better place for it
[22:10] <pochu> it's just an advanced tab, something you likely don't want to change, but if you do, there you have
[22:10] <Amaranth> It may not have to mean that but it almost always does
[22:11]  * LaserJock looks around for a UserKit project
[22:11] <Amaranth> Advanced turns into a dumping ground for all the things random people think they should be able to tweak and things where you couldn't decide what a default should be
[22:12] <Amaranth> 100 lines of code and an option or 1000 lines of code and it just does the right thing, I'd go for the latter
[22:14] <slangasek> you're assuming the latter is one of your choices
[22:14] <slangasek> if there's no one to write the right 1000 lines of code, it isn't
[22:14] <Amaranth> I'm saying if I'm writing the app, that's how I'd go
[22:15] <pochu> having a good default doesn't mean you should hide the setting from the UI
[22:15] <pecisk> Amaranth: but not in this scenario, I was there when previously that dialog was designed, and Advanced was generally accepted
[22:15] <Amaranth> Or if one option was used by 90% of my users I'd ditch the option
[22:15] <slangasek> sorry, but I think that's naive, you don't always anticipate all the "right" answers when writing a program :)
[22:15] <Amaranth> one choice for an option, rather
[22:15] <slangasek> Amaranth: er, you'd screw over 10% of the users?
[22:16] <slangasek> you think it's acceptable for 10% of the users to have to dig around in gconf?
[22:16] <Amaranth> I wouldn't even put it in gconf unless it was a tiny bit of code to maintain
[22:17] <lamont> so... the printer config settings widgit thingy.... it seriously won't let you share printers on the network without announcing them?  sigh
[22:17]  * lamont hugs vi
[22:17] <pecisk> Amaranth: first, you really have any veryifable metrics about that 90% versus 10%, have you?
[22:17] <Amaranth> That's problem 2, we have no idea what our users are doing with our apps
[22:17] <pecisk> exactly
[22:17] <Amaranth> Microsoft does, why can't we?
[22:17] <pecisk> so you can't claim "90% don't need this feature"
[22:17] <pecisk> Amaranth: Microsoft doesn't
[22:18] <ScottK> Microsoft's number is 80%
[22:18] <slangasek> lamont: hmm?  announce how?
[22:18] <pecisk> Amaranth: Microsoft makes study and real ui design according to "how they think it should work"
[22:18] <Amaranth> pecisk: The default in their apps is to report usage statistics
[22:18] <Amaranth> How many times do you use the menu for Cut/Copy/Paste? How many times do you use the keyboard? They know these things
[22:18] <ScottK> pecisk: And then you get the Vista logout/shutdown diaglogue monster as a result.
[22:20] <Amaranth> Also, any easy way to figure out how to do settings: Look at what compiz does, do the opposite
[22:20] <pecisk> Amaranth: ok, I think we went wrong path here
[22:20] <pecisk> what I wanted to say
[22:20] <Amaranth> s/any/an/
[22:20] <lamont> slangasek: broadcast or multicast, dunno
[22:20] <pecisk> is if there a feature, and if someone, at least two people need it, and we can have it without ruining simplicity
[22:21] <pecisk> well
[22:21] <pecisk> it would be nice to have it
[22:21] <lamont> whatever the "look at me I HAZ PRINTAR!" IPP method is
[22:21] <pecisk> and plan to have it
[22:21] <slangasek> lamont: well if it's broadcast or multicast, it's not IPP :)
[22:21] <lamont> whateveh
[22:21] <slangasek> lamont: if it's broadcast or multicast, I guess it's ultimately avahi's doing?
[22:21] <maxb> The nice folks on #launchpad have unwedged yellow. However the build on crested looks to be stuck - judging by the previous buildlog it will be killed in another couple of hours by the "150 minutes with no activity" criterion. Is it worth asking someone to terminate it earlier, in view of the previously mentioned mesa/intel/amd64 breakage?
[22:21] <lamont> system -> administration -> printing -> settings -> lines 2 and 3 on an intrepid box
[22:22] <Amaranth> pecisk: That way leads to GNOME 1.x
[22:22] <Amaranth> pecisk: We've learned from those mistakes
[22:22] <lamont> maxb: let me go look at it for giggles
[22:22] <slangasek> lamont: also, server -> settings -> publish shared printers connected to this system doesn't control what you want? or is that jaunty only?
[22:22] <lamont> slangasek: I want allow printing from internet, but not publish printers
[22:22] <maxb> lamont: http://launchpadlibrarian.net/21472199/buildlog_ubuntu-hardy-amd64.ardour_1%3A2.7.1-2~hardy1_FAILEDTOBUILD.txt.gz  <-- the previous buildlog, which wedged in the same place
[22:22] <lamont> _I_ know what they are, you see...
[22:23] <pecisk> Amaranth: really? I think GNOME 1.x didn't have much features and they didn't worked well
[22:23] <Amaranth> pecisk: You can look at GNOME 1.x and say "well obviously that's too complex" but it was death by a thousand cuts
[22:23] <pecisk> Amaranth: what is too complex? For me is too complex to put vino into encryption mode using gconf
[22:23] <Amaranth> pecisk: You ever see the configuration in GNOME 1.x? The panel had 2 or 3 "unbreak me" options you could toggle
[22:23] <slangasek> lamont: hrm, I guess maybe I configured my acl in /etc/cups/cupsd.conf by hand, doh
[22:24] <pecisk> Amaranth: yes, I used it for two years :)
[22:24] <lamont> strace -p 17061
[22:24] <lamont> Process 17061 attached - interrupt to quit
[22:24] <lamont> msgrcv(272531459,
[22:24] <lamont> maxb: ^^
[22:24] <lamont> stupid ipc
[22:24] <lamont> slangasek: like I said: vim deserves hugging
[22:24] <pecisk> Amaranth: but where is connection with what I said and GNOME 1.x?
[22:24] <Amaranth> pecisk: If two people want the option and it's not much code to provide put it in
[22:25] <Amaranth> pecisk: That leads to configuration like GNOME 1.x
[22:25] <lamont> slangasek: I mean, announcing them to the world is definitely toeing the free-beer line
[22:25] <Amaranth> pecisk: You have to ignore some users wishes for the betterment of the rest of the users, the only argument should be where the cutoff point is
[22:27] <slangasek> lamont: the GUI says 'publishing', I think that refers only to whether they're browseable - so not really an announcement per se...
[22:28] <pecisk> Amaranth: so you have to cut it already universally accepted Advanced tab from Vino dialog just to prove that there should be cutoff?
[22:28] <lamont> slangasek: well, I know that when I turned that option, it added BrowseAddress @LOCAL, and my laptop magically found all the printers on the amchine...
[22:28] <lamont> just sayin'
[22:28] <pecisk> I agree that introducing of new advanced features
[22:29] <pecisk> that it should be clearly a line when it shouldn't be in the front of the user
[22:29] <pecisk> it/there/s
[22:29] <pecisk> but
[22:29] <pecisk> old Vino dialog was job of some three or four bug reports
[22:29] <pecisk> with requests to having these Advanced features in gui
[22:30] <pecisk> including port, encryption and disabling wallpaper
[22:30] <Amaranth> three or four?
[22:30] <pecisk> yes
[22:30] <pecisk> as far as I remember
[22:30] <Amaranth> I'd be looking for more like 100
[22:30] <pecisk> Amaranth: three or four with LOT of comments ;)
[22:30] <Amaranth> pecisk: Encryption should probably go in the UI somewhere
[22:31] <Amaranth> port and wallpaper, no
[22:31] <slangasek> lamont: hmm, looks like without setting that option, my printers aren't exposed over avahi, interesting
[22:31] <Amaranth> port is the default and you really shouldn't have to change it, disabling wallpaper should be an automatic thing
[22:33] <pecisk> Amaranth: I agree about port and wallpaper
[22:33] <pecisk> see
[22:33] <pecisk> it is not that hard :)
[22:33] <pecisk> anyway
[22:33] <lamont> maxb: thinking here is that it's scons
[22:34] <pecisk> for positive side, it was great to have such blog post about new dialog
[22:34] <lamont> maxb: hardy kernel on the machine, inside whatever chroot that is
[22:34] <pecisk> so anyone could comment about it on early stage
[22:37] <Amaranth> pecisk: Do you use compiz?
[22:38] <pecisk> Amaranth: very very rarerly. It is nice, but somehow it still have lot of artifacts
[22:38] <Amaranth> pecisk: Ok then, have you ever looked at the settings for compiz?
[22:39] <pecisk> Amaranth: Desktop Effects or Compiz itself?
[22:39] <Amaranth> I never want to see that happen to any project ever again
[22:39] <Amaranth> compiz itself
[22:39] <pecisk> ahhh
[22:39] <pecisk> that infamous monster configuration gui? :)
[22:39] <Amaranth> The excuse for compiz was it's a research project so we have to allow all these options to see what works best
[22:39] <Amaranth> The problem is we can't get rid of them now :/
[22:41] <Amaranth> I tried to write a plugin that would ensure certain plugins were loaded and disable a lot of the options but couldn't make it work
[22:41] <Amaranth> Originally the plugin was called 'metacity', right now it's called 'sanity' :P
[22:42] <pecisk> :D
[22:42] <pecisk> I understand your struggle
[22:45] <Amaranth> I suppose we could just strip the XML for those options in Ubuntu, then ccsm wouldn't show them
[22:45] <pecisk> Amaranth: what I really would like to see is some kind of spec for GNOME, to keep in check main features so they don't get lost, or if they are gone, there is documented workaround or solution. It would lower a confusion between users a lot.
[22:45] <pecisk> yeah
[22:50]  * maxb raises eyebrow at release-upgrader removing openssl-blacklist
[22:52] <pecisk> anyway, was nice to discuss all this with you devs. Cheer up and keep on doing great work. And forgive us users and testers that we whine too much sometimes :)
[22:52] <pecisk> see ya
[23:02] <maxb> Hmm. Jockey just proudly announced that I'm using no proprietary drivers... but I'm using nvidia-glx :-/
[23:05] <LaserJock> wow, nvidia must have gone open source! ;-)
[23:09] <Amaranth> LaserJock: Sweet, now I can comment out the crashXServer() function
[23:09] <Amaranth> and the corruptKernelMemory() one too!
[23:13] <directhex> pitti, poke
[23:14] <directhex> asac, poke also
[23:16] <LaserJock> it's pretty late on a Friday for them
[23:17] <directhex> true
[23:17] <directhex> but i've found the bug which relates to a problem so infuriating i was seriously considering drastic measures like using vista, or worse, kubuntu
[23:26] <slangasek> directhex: ?
[23:32] <directhex> slangasek, lp 286119 has been driving me round the bend for MONTHS
[23:33] <directhex> perhaps longer
[23:33] <directhex> i might've been unfairly blaming nspluginwrapper all this time
[23:36] <slangasek> directhex: hrm, odd; never seen that bug here
[23:37] <directhex> slangasek, do you have an intersection of amd64, winbind, and lots of tabs?
[23:37] <directhex> and possibly not being connected to a domain is relevant too
[23:37] <slangasek> directhex: er, oh, misleading description - I certainly /am/ familiar with that bug once I see which bug it is
[23:37] <directhex> it was in some old sarge bugs
[23:40] <slangasek> directhex: well, s/winbind/nss_wins/ - I never use nss_wins, it's Broken By Design
[23:41] <slangasek> fix is supposed to be in intrepid-proposed now, anyawy?
[23:42] <directhex> slangasek, no amd64 binaries that i can see. possibly buildd delay or mirror delay
[23:42] <slangasek> right, amd64 seems to be lagged for SRUs
[23:43] <maxb> yellow had a stuck build for 3 days, didn't help matters.
[23:53] <pochu> directhex: that looks familiar
[23:53] <pochu> isn't it the same as bug #214192?
[23:54] <directhex> pochu, description sounds identical
[23:55]  * pochu duplicates it