[01:04] <rickspencer3> robert_ancell: I'm running Karmic on my desktop from a live usb
[01:04] <rickspencer3> seems weirdly fast
[01:05] <robert_ancell> I didn't notice much of a speed improvement but I haven't changed to ext4 though
[01:06] <rickspencer3> should have exported my mailbox first :/
[07:02] <pitti> Good morning
[07:27] <robert_ancell> pitti, do you know how/why 90_relibtoolize.patch is regenerated in libwnck?
[07:27] <pitti> robert_ancell: hey
[07:27] <robert_ancell> pitti, hi#
[07:27] <pitti> robert_ancell: not in that package in particular; does it look different than other similar patches?
[07:28] <pitti> hi-sharp, nice
[07:28] <pitti> as for the "why", no
[07:28] <pitti> robert_ancell: if it's not necessary any more, just drop it
[07:29] <pitti> robert_ancell: sometimes they are regenerated for some more obscure reasons like making -Wl,--as-needed actually work, and so on
[07:29] <pitti> robert_ancell: perhaps check with Seb once he comes online?
[07:29] <robert_ancell> pitti, running autoreconf, autoconf, libtoolize doesn't seem to make a very similar patch.  Not sure what it's doing so can't drop it!
[07:29] <robert_ancell> will ask seb though
[07:30] <pitti> robert_ancell: which files does it touch ATM?
[07:30] <pitti> (lsdiff)
[07:31] <robert_ancell> libwnck-2.26.1/aclocal.m4
[07:31] <robert_ancell> libwnck-2.26.1/config.guess
[07:31] <robert_ancell> libwnck-2.26.1/config.h.in
[07:31] <robert_ancell> libwnck-2.26.1/config.sub
[07:31] <robert_ancell> libwnck-2.26.1/configure
[07:31] <robert_ancell> libwnck-2.26.1/doc/Makefile.in
[07:31] <robert_ancell> libwnck-2.26.1/gtk-doc.make
[07:31] <robert_ancell> libwnck-2.26.1/INSTALL
[07:31] <robert_ancell> libwnck-2.26.1/libwnck/Makefile.in
[07:31] <robert_ancell> libwnck-2.26.1/ltmain.sh
[07:31] <robert_ancell> libwnck-2.26.1/Makefile.in
[07:31] <robert_ancell> Changelog says "relibtoolize to avoid the amd64 rpath issue"
[07:32] <pitti> ah
[07:32] <pitti> so there's the reason
[07:32] <pitti> robert_ancell: are you on i386 or amd64?
[07:33] <robert_ancell> i386
[07:39] <pitti> robert_ancell: I can do an amd64 build for you if you need one for testing
[07:41] <robert_ancell> pitti, thanks, shouldn't need it though, will use ppa if need to build on different arch
[07:42] <pitti> ok; let me know, though, the turnaround for builing/testing rpath/ etc. might be faster
[08:28] <crevette> hello hello
[08:30] <tjaalton> should there be a script or something to migrate users from the FUSA applet in hardy to what it was replaced with?
[08:34] <pitti> tjaalton: I thought we had that, as an interactive upgrade hook?
[08:34] <pitti> (in intrepid)
[08:34] <tjaalton> pitti: how about hardy-> jaunty?
[08:34] <tjaalton> if it isn't in jaunty anymore, what about hardy -> next LTS?
[08:35] <tjaalton> hrm, lunch, bbl ->
[08:36] <pitti> tjaalton: it should still be there
[08:36] <seb128> hello there
[08:37] <didrocks> morning seb128 and pitti
[08:37] <seb128> hey didrocks pitti
[08:37] <pitti> hey seb128
[08:37] <pitti> moin didrocks
[08:37] <seb128> didrocks, how are you?
[08:37] <seb128> hey pitti
[08:38] <didrocks> seb128: fine, thanks :) I get to sleep very early compared to you, viewing the backlog ;)
[08:38] <didrocks> and you?
[08:38] <seb128> good, I didn't work late for a while now but there was just nothing to watch on TV yesterday and I had things I wanted to do ;-)
[08:39] <seb128> didrocks, would you be interested to look at getting mutter packaged for ubuntu?
[08:39] <pitti> didrocks: BTW, currently working on automatic dependency calculation for distutils-auto
[08:39] <pitti> seb128: is this the comparative of "mutt"? :-)
[08:39] <didrocks> seb128: yes. I take half of my day off. That's a thing I can have a look :-)
[08:40] <didrocks> pitti: great! "quickly release" will be able to do something useful then :)
[08:40] <seb128> didrocks, excellent
[08:40] <pitti> didrocks: after that, I'll add a script to create debian/*
[08:41] <seb128> I will have a look to gjs so we can aim at having gnome-shell in a ppa before GUADEC
[08:41] <seb128> pitti, no, it's the wm part of gnome-shell
[08:41] <didrocks> seb128: GUADEC is next week?
[08:41] <pitti> oh, yet another window manager?
[08:41] <pitti> compiz is no more?
[08:41] <didrocks> pitti: no gnome-shell doesn't work with compiz
[08:42] <pitti> (ugh)
[08:42] <didrocks> (that was a FUD in the gnome-devel ml)
[08:42] <seb128> pitti, GNOME never used compiz
[08:42] <seb128> didrocks, this weekend, ie starting on saturday
[08:43] <seb128> I'm traveling to go there on friday, there is the opening party in the evening
[08:43] <didrocks> seb128: hope you will enjoy it... should be easy in a paradisian country ;)
[08:43] <seb128> ;-)
[08:43] <seb128> thanks
[08:43] <pitti> mmm Gran Canaria
[08:43] <seb128> I'm not sure it's paradisian, it's an island and not really a fancy one I think
[08:44] <seb128> it's mainly sun and swimming pools I guess
[08:44] <didrocks> seb128: in the meantime, I'm going to Nantes for RMLL... not as attractive in every cases ^^
[08:44] <seb128> istanbul was probably nicer to see as a city
[08:44] <seb128> have fun there
[08:44] <didrocks> thanks
[08:45] <seb128> I might prefer Nantes, I'm not a big fan of too warm countries, especially when you go for work and not to stay in the swimming pool during the afternoon
[08:45] <didrocks> sure, when it's too warm, it's difficult to be effective at work
[08:46] <seb128> well they will probably have cold air inside buildings
[08:46] <seb128> ie what you need to come back with a cold
[08:46] <didrocks> exactly...
[08:46] <seb128> anyway I'm sure it will be fun and I'm looking forward going there ;-)
[08:46] <crevette> seb128, and you're an expert in getting cold
[08:46] <crevette> (hello)
[08:46] <crevette> :)
[08:46] <didrocks> hey crevette
[08:47] <pitti> we all are *sigh*
[08:47] <crevette> hey hey didrocks
[08:47] <seb128> lut huats
[08:47] <seb128> lut crevette
[08:47] <didrocks> plop huats
[08:47] <crevette> salut seb128 & pitti & huats & anyone here :)
[08:49] <pitti> bonjour crevette
[08:52] <pitti> seb128: retracers all failed (python-apt api issue), I'll fix it later
[08:53] <seb128> ok
[08:56] <seb128> pitti, not sure if you plan to do sru today but could you look at the pidgin yahoo fix for jaunty?
[08:56] <pitti> sure
[08:57] <pitti> that's urgent, I'll process it right now
[08:57] <seb128> thanks
[08:58] <seb128> the number of duplicates tell us that yahoo is quite used, so we better have to make sure it works correctly in empathy too
[08:58] <robert_ancell> didrocks, can you enable the quickly ppa from https://launchpad.net/~quickly?
[08:58] <seb128> hey robert_ancell
[08:58] <robert_ancell> seb128, hey seb
[08:59] <seb128> robert_ancell, had a good day? busy on updates? ;-)
[08:59] <robert_ancell> seb128, packaging question: was updating libwnck and not sure how to regenerate 90_relibtoolize.patch. Any ideas?
[09:00] <robert_ancell> I found http://people.dooz.org/~lool/debian/relibtoolize but it looks overly complicate
[09:00] <robert_ancell> d
[09:00] <seb128> autoreconf
[09:00] <lool> robert_ancell: It's relatively complex and out of date
[09:00] <seb128> hey lool
[09:00] <lool> robert_ancell: It did allow me to create smaller diffs than what autoreconf will do
[09:01] <robert_ancell> lool, is it needed? It seems to build ok without it
[09:01] <lool> Basically autoreconf might run more stuff than strictly necesasry and will run the latest version of tools
[09:01] <lool> e.g. it might run automake 1.10 even if you have 1.9 and upstream uses 1.9
[09:01] <lool> So it will create big diffs (MBs)
[09:01] <seb128> I tend to not bother nowadays and use autoreconf which does the job
[09:01] <lool> robert_ancell: The safest thing is autoreconf (-fi)
[09:02] <robert_ancell> ok
[09:02] <lool> I agree with seb128, most of the time that's fine
[09:02] <seb128> robert_ancell,   * 90_relibtoolize.patch: relibtoolize to avoid the amd64 rpath issue.
[09:02] <robert_ancell> yes, what does that mean...
[09:02] <lool> I know that if I only touch autoconf, I can get away with aclocal/autoconf
[09:02] <seb128> robert_ancell, I'm not really familiar with that and not sure how to check if that's still an issue in the current upstream tarball
[09:02] <lool> But that's already guessing the tools more than you want
[09:02] <pitti> we could just do an amd64 build without the patch and check if they get rpaths
[09:02] <seb128> robert_ancell, it means that the library shouldn't have a rpath on amd64 but it does due to buggy autotools versions
[09:03] <robert_ancell> hmm
[09:03] <seb128> the easier way to check if that's still an issue is what pitti said but you need an amd64 install
[09:04] <pitti> seb128: meh, the pidgin upload refers to bug 389332, which is obviously wrong
[09:04] <seb128> robert_ancell, http://wiki.debian.org/RpathIssue
[09:04] <pitti> Laney: ^
[09:04] <seb128> pitti, bug #389322
[09:04] <pitti> Laney: what is the real bug? could you do another upload with the right number?
[09:04] <pitti> ah
[09:04] <pitti> seb128: thanks
[09:05] <seb128> pitti, Laney doesn't have upload right that needs sponsoring, I can reupload with right number if you want
[09:05] <pitti> seb128: if you have it ready, would be appreaciated; otherwise I'll download/reupload
[09:05] <pitti> ugh, what a patch
[09:05] <pitti> 3000 lines??
[09:05] <tjaalton> pitti: do you have any idea what it's called?
[09:06] <pitti> tjaalton: unfortunately not; mvo knows
[09:06] <tjaalton> mvo: hey, what script does the migration from the old FUSA to the new one? it's not running on our environment and I'd like to find out why
[09:07] <robert_ancell> pitti, can you build lp:~robert-ancell/libwnck/ubuntu and see if it has an rpath issue?
[09:07] <seb128> tjaalton, /usr/share/gnome-panel/migrate-fusa-config.py
[09:07] <tjaalton> seb128: ooh, thanks
[09:07] <didrocks> robert_ancell: I will at the end of the week. We will have a first beta available then
[09:07] <tjaalton> mvo: got it already
[09:07] <mvo> tjaalton: the notice about it is in /var/lib/update-notifier/user.d/
[09:07] <pitti> robert_ancell: doing
[09:08] <mvo> tjaalton: oh, sorry - we did not do a notice for it, we just ran it :)
[09:08] <tjaalton> mvo: ok, figures.. it's disabled here
[09:08] <pitti> robert_ancell: shall I drop 90_relibtoolize.patch?
[09:08] <tjaalton> update-notifier that is
[09:08] <robert_ancell> pitti, I deleted it on my branch
[09:09] <tjaalton> but maybe there's a better way to disable the usual popups
[09:09] <mvo> tjaalton: the fusa-script was added via autorun and a gconf key
[09:09] <lool> seb128: Oh and morning BTS, sorry missed yours :)
[09:09] <pitti> robert_ancell: still here; I delete it locally for testing
[09:09] <seb128> pitti, pidgin reuploaded with right bug number
[09:10] <pitti> seb128: merci
[09:10] <robert_ancell> pitti, check you have 2.26.2, I have pushed my changes now
[09:10] <pitti> robert_ancell: ah, I had .1
[09:10] <pitti> meh, since when does bzr+ssh:// lag?
[09:11] <seb128> robert_ancell, did you read the debian wiki url I copied before?
[09:11] <robert_ancell> seb128, yes
[09:11] <seb128> robert_ancell, you might want to use a rpath call in rules rather than running autotools
[09:12] <pitti> robert_ancell: got it; started test build
[09:14] <robert_ancell> seb128, it appears to have been built with the 2.2.6 which shouldn't have the problem according to the wiki page
[09:16] <seb128> robert_ancell, indeed where 2.26.1 was built using 1.5
[09:16] <pitti> $ chrpath /usr/lib/libwnck-1.so.22.3.20
[09:16] <pitti> /usr/lib/libwnck-1.so.22.3.20: no rpath or runpath tag found.
[09:16] <seb128> $ grep VERSION= libwnck-2.26.1/ltmain.sh libwnck-2.26.2/ltmain.sh
[09:16] <seb128> libwnck-2.26.1/ltmain.sh:VERSION=1.5.26
[09:16] <seb128> libwnck-2.26.2/ltmain.sh:VERSION=2.2.6
[09:16] <pitti> robert_ancell: dropping the patch should be fine then
[09:17] <seb128> \o/
[09:17] <robert_ancell> pitti, thanks.  I guess it is safe to go with no patch
[09:17] <robert_ancell> :)
[09:17] <seb128> no relibtoolize change++
[09:17] <pitti> robert_ancell: you'll merge/pull that branch into ~u-desktop?
[09:17] <robert_ancell> pitti, yes
[09:19] <seb128> pitti, is gvfs-gdu-volume-monitor crashing all the time for you too?
[09:19] <pitti> seb128: apparently ye
[09:19] <pitti> s
[09:19] <seb128> (process:13370): libgdu-WARNING **: Couldn't call GetAll() to get properties for /: Launch helper exited with unknown return code 127
[09:20] <robert_ancell> seb128, can you update the versions tool? thanks
[09:21] <seb128> robert_ancell, done
[09:22] <pitti> seb128: I have that, too, and "invalid (NULL) pointer instance" and "Couldn't get daemon properties"
[09:22]  * seb128 investigates
[09:23] <pitti> seb128: I wonder why we don't have a d-bus .service for gdu
[09:23] <pitti> the gphoto one has one as well
[09:24] <pitti> but well, apparently it does run, otherwise it couldn't crash
[09:24] <pitti> seb128: SRUs processed, thanks
[09:24] <seb128> pitti, gvfs: /usr/share/dbus-1/services/org.gtk.Private.GduVolumeMonitor.service
[09:24] <seb128> ?
[09:24] <robert_ancell> cheers seb128, now it's a lot more red... !
[09:24] <seb128> pitti, thanks for the processing
[09:25] <seb128> robert_ancell, we need to split this page rather than having a "+" imho
[09:25] <pitti> seb128: ah, it's in gvfs; the gphoto one is in -backends
[09:25] <seb128> pitti, yeah, the gphoto one is optional where the disk one is required
[09:26] <robert_ancell> seb128, why split? What I want to do is have tags to toggle, i.e. gnome, karmic, kde, ... and autogenerate the lists
[09:26] <pitti> seb128: usually, a gvfs-mount -l spawns them all again
[09:26] <pitti> seb128: but for me that fails immediately
[09:26] <pitti> (gvfs-mount:21806): GVFS-RemoteVolumeMonitor-WARNING **: invoking IsSupported() failed for remote volume monitor with dbus name org.gtk.Private.GduVolumeMonitor: org.freedesktop.DBus.Error.Spawn.ChildSignaled: Process /usr/lib/gvfs/gvfs-gdu-volume-monitor received signal 11
[09:27] <seb128> pitti, well the gdu monitors crash on start
[09:27] <robert_ancell> So we would probably look at the page with karmic+gnome+ubuntu-desktop tags and others may use other combinations
[09:27] <pitti> hm, it crashed a lot in the previous versions as well, but now it's immediate
[09:27] <seb128> robert_ancell, I find the page less useful that what it could be, I'm not interested by many things there, some are in universe etc
[09:27] <seb128> robert_ancell, I think it would be better to have a list for this team and one for contributors, motus, etc
[09:28] <robert_ancell> seb128, do you mean the page when expanded?
[09:28] <pitti> at least it's easy to gdb, it crashes immediately
[09:28] <seb128> pitti, right, I'm rather concerned about the helper message I'm wondering was is displaying it the string is not a gvfs one
[09:28] <seb128> robert_ancell, the page expended or not
[09:28] <robert_ancell> seb128, everyone's interest is going to be different.  There's always trouble when defining where each team ends
[09:29] <seb128> robert_ancell, well the thing is that clicking on "+" mix those extra components in the middle of the standard list
[09:29] <seb128> robert_ancell, ie you can't point motus easily to the extra components
[09:30] <robert_ancell> seb128, yes, that is where I think having a tag system will work better
[09:30] <seb128> how would it work?
[09:31] <huats> hello everyone !
[09:31] <robert_ancell> huats, hi
[09:31] <huats> seb128, robert_ancell, crevette o/
[09:31] <robert_ancell> seb128, we have tags along the top of the page which act like toggle buttons
[09:31] <robert_ancell> you chose which ones are enabled and packages with that tag are shown
[09:31] <seb128> robert_ancell, hum, that would work for me yes, if you know how to do that ;-)
[09:32] <robert_ancell> can do
[09:32] <seb128> cool
[09:33] <seb128> pitti,
[09:33] <seb128> $ devkit-disks --show-info /dev/sda1
[09:33] <seb128> Cannot find device with major:minor 8:1: Launch helper exited with unknown return code 127
[09:33] <pitti> ah
[09:33] <pitti> my bug then, apparently
[09:33] <seb128> or I'm using that command wrongly?
[09:33] <pitti> no, indeed it crashes now
[09:34] <pitti> devkit-disks --dump -> same
[09:34] <pitti> the d-bus backend isn't running
[09:34] <seb128> iz kit bog
[09:34] <seb128> (devkit-disks:14751): devkit-disks-WARNING **: Couldn't enumerate devices: Launch helper exited with unknown return code 127
[09:34] <seb128> right
[09:34] <pitti> odd, it didn't change in over a week
[09:34] <seb128> devkit-daemon is running
[09:35] <pitti> right, wrong kit
[09:35] <pitti> you need /usr/lib/devicekit-disks/devkit-disks-daemon
[09:35] <seb128> that is not running
[09:35] <pitti> dk-disks doesn't even use devicekit any more
[09:35] <seb128> /usr/lib/devicekit-disks/devkit-disks-daemon: error while loading shared libraries: libgudev-1.0.so.0: cannot open shared object file: No such file or directory
[09:35] <seb128> doh
[09:35] <pitti> aaah
[09:35] <pitti> that was the udev upload yesterday
[09:36] <pitti> apparently it needs a rebuild due to changed library path
[09:36] <pitti> erm, no
[09:36] <pitti> itz Keybuk bug
[09:36] <pitti> $ dpkg -L libgudev-1.0-0
[09:36] <seb128> 	libgudev-1.0.so.0 => not found
[09:36] <pitti> -> empty
[09:36] <seb128> Scoooooootttttt
[09:36]  * pitti pokes
[09:37] <pitti> -dev is empty as well
[09:37] <seb128> Keybuk, ^
[09:37] <pitti> asac: ^ just in case your network-manager doesn't build
[09:37] <pitti> Keybuk: could you please bzr push your udev branch?
[09:37] <pitti> bzr is at 143-2
[09:39] <tjaalton> I'd like to disallow the users to restart/shutdown the machine, and I understood it should be possible by poking polkit.. But the docs are a bit sketchy on that :/
[09:39] <pitti> Keybuk: hm, there is no debian/libgudev*.install -- that might be it?
[09:39] <asac> thanks for the heads up
[09:40] <pitti> tjaalton: in karmic that's currently a bit hard; in jaunty you should be able to use polkit-gnome-authorization (it's also in the admin menu)
[09:40]  * asac remembers to not dist-upgrade just now
[09:40] <pitti> tjaalton: however, for local users it hardly makes sense -- they can just press the power button?
[09:40] <pitti> or sysrq
[09:41] <tjaalton> pitti: yes, it's just a matter of giving the gun or pulling the trigger ;)
[09:41] <Keybuk> pitti: I get a .deb in my working directory
[09:41] <seb128> Keybuk, empty deb?
[09:41] <pitti> Keybuk: right, but it's empty (jusr doc)
[09:42] <pitti> Keybuk: forgot to bzr add the libgudev*.install files?
[09:43] <Keybuk> oh maybe
[09:43] <Keybuk> would have wiped them too
[09:43] <pitti> argh devhelp broken :(
[09:43]  * Keybuk hates packaging with bzr
[09:43] <Keybuk> I'm about -> <- this far from just giving up and doing it the old fashioned away again
[09:47] <Keybuk> pitti: uploaded one that should fix that
[09:47] <pitti> Keybuk: thanks
[09:47] <seb128> Keybuk, thanks
[09:47] <seb128> hey rodrigo_
[09:47] <rodrigo_> morning
[09:48] <pitti> Keybuk: eww, aren't they installed into usr/lib, not /lib?
[09:48] <Keybuk> pitti: no idea
[09:48] <pitti> --libdir=/usr/lib \
[09:48] <pitti> $ cat debian/libgudev-1.0-0.install
[09:48] <Keybuk> that's the way Kay said to do it ;)
[09:48] <pitti> lib/libgudev*.so.* usr/lib
[09:48] <Keybuk> will see what the build does
[09:49] <pitti> right, but the .install expects them in /lib
[09:51] <Keybuk> yeah you're right
[09:52]  * Keybuk fixes the wildcard "pkgconfig" include too
[09:52] <Keybuk> and the wildcard /usr/include ;)
[09:53] <pitti> thank you
[09:53] <pitti> Keybuk: what's wrong with /usr/include?
[09:54] <Keybuk> pitti: that'd include everything in /usr/include
[09:54] <Keybuk> like other files that udev makes
[09:54] <pitti> ah, for libudev
[09:55] <pitti> Keybuk: btw, did Kay already show kayfs to you? ("devfs is back")
[09:55] <pitti> he showed me at LinuxTag, looks pretty nice
[09:55] <pitti> init=/bin/sh -> takes 0.6 seconds and has a correctly populated /dev
[09:56] <pitti> it's called "devtmpfs", IIRC
[09:56] <Keybuk> yeah :)
[09:56] <Keybuk> I'm not convinced by it though
[10:00] <Keybuk> grr
[10:00] <Keybuk> now I just modified files in the build directory and lost them when I rebuilt
[10:01]  * Keybuk wonders when bzr is going to make his life easier
[10:01] <Keybuk> right now, it just makes everything four times harder
[10:02] <seb128> Keybuk, not true it makes sponsoring easier ;-)
[10:02] <Keybuk> seb128: disagree strongly
[10:03] <Keybuk> grabbing someone's debdiff and applying it was easy
[10:03] <seb128> well I find easy to review a bzr for incremental changes than a serie of debdiff on a launchpad bug
[10:03] <seb128> well the issue is when you start having new version updates and comment and go through several iterations
[10:03] <seb128> it's not easy to diff the debdiff to see the changes
[10:04] <Keybuk> bzr's output is just a patch too
[10:04] <seb128> where it's easy to read the commits
[10:04] <Keybuk> except I have to work harder to get that patch
[10:04] <seb128> I find easier to bzr pull than to open launchpad, download a file, apply it, etc
[10:05] <Keybuk> you only know to bzr pull because they gave you the URL to pull from
[10:05] <Keybuk> how is that any different from them giving the URL of the debdiff?
[10:05] <Keybuk> except that with the debdiff approach, the URL gives you exactly what you need to review
[10:05] <Keybuk> and you don't need to go through hoops to get it
[10:05] <Keybuk> the bzr command to "show me the changes that this URL would bring to my branch" is still delightfully obtuse
[10:06] <seb128> different workflow I expect
[10:06] <Keybuk> gedit URL > bzr diff -r ancestor:. URL
[10:06] <Laney> pitti, seb128: Ugh. Typo. Sorry
[10:06] <seb128> I usually sponsor desktop packages and they are in ubuntu-desktop/component/ubuntu
[10:07] <seb128> not to mention that we usually have new versions and only the debian directory in bzr so debdiff don't really work, or you need a debian directory diff and download the tarball
[10:08] <seb128> anyway no point to discuss for hours, it works fine for sponsoring for most people on this channel but different people have different workflows
[10:09] <pitti> meh, x freeze and fsck
[10:21] <seb128> Laney, want to work on the pidgin 2.5.8 update for karmic? ;-)
[10:21] <Laney> aaaaaah pidgin
[10:21]  * Laney runs screaming
[10:22] <Laney> what's new there?
[10:22] <seb128> some bug fixed apparently, debian already did the upgrade, it should be easy enough
[10:22] <seb128> either reapply your previous merge diff on it and just do the update
[10:22] <Laney> alright I'll have a look tonight
[10:22] <seb128> thanks
[10:24] <Laney> I'm going to give up on Hardy unless you have found another distro which has done the work
[10:24] <Laney> I just requested the backport instead
[10:30] <didrocks> seb128: before going back to home and working on mutter. What do you prefer for this package dh5, dh7 or cdbs? (I know that you are a fan of cdbs ;))
[10:31] <seb128> hum no, can't find a distribution doing that backport
[10:31] <seb128> didrocks, your call but dh7 or cdbs are nicer
[10:31] <didrocks> seb128: ok, it's maybe the time to try dh7, be indulgent so ;)
[10:32] <seb128> I will have to learn it too ;-)
[10:32] <seb128> but it's a good occasion
[10:32] <didrocks> exactly :-)
[10:34] <seb128> bbl
[10:35] <Laney> dh7 is very nice to use
[10:35] <Laney> makes cdbs go away imho
[10:46] <pitti> or, at least, considerably simpler
[10:51] <pitti> didrocks: \o/
[10:51] <pitti> $ test/auto.py -v T.test_requires
[10:51] <pitti> automatic requires ... ok
[10:51] <pitti> didrocks: from that it should not be too hard to figure out the automatic package dependencies
[10:53] <didrocks> pitti: congrats ^^
[12:05] <chrisccoulson> anyone working on the control-center update?
[12:06] <pitti> didrocks: I'm about to change the spec from "./setup.py debian" to "python-distutils-mkdebian"; would that be alright for you?
[12:06] <pitti> didrocks: I want to avoid putting Debian specific stuff into the upstream distutils-extra
[12:06] <seb128> chrisccoulson, no
[12:06] <chrisccoulson> cool, i'll take that one then if that ok
[12:07] <chrisccoulson> ** if thats ok
[12:07] <seb128> good
[12:07] <chrisccoulson> thanks:)
[12:07]  * pitti hugs chrisccoulson
[12:07] <seb128> thank you for working on it ;-)
[12:07] <pitti> didrocks: https://wiki.ubuntu.com/DesktopTeam/Specs/Karmic/AutomagicPythonBuildSystem?action=diff&rev2=15&rev1=14 in particular
[12:07]  * chrisccoulson hugs pitti
[12:09] <seb128> let's get some food though it's so warm there that I'm not hungry
[12:11] <pitti> seb128: ice cream!
[12:11] <seb128> pitti, good idea for after lunch ;-)
[12:14] <chrisccoulson> is everyone enjoying hot weather? it was raining very heavily here on my drive to work this morning
[12:17] <hyperair> could someone in the desktop team advise me about the best way to go about bug #214420 ? as i understand it, usershare owner only = false'
[12:18] <hyperair> +was supposed to be a security measure
[12:18] <hyperair> i mean usershare owner only = true
[12:18] <pitti> no idea about that, I'm afraid; slangasek understands samba and might be able to help
[12:22] <hyperair> i'll wait for his input then
[12:31] <asac> lool: you remember the passphras for pkg-mozilla-maintainers ?
[12:31] <asac> (mailing list)
[12:31] <asac> lool: could you allow<EMAIL_ADDRESS>to send there and moderate the last three mails i sent ;)? thanks!!
[12:36] <didrocks> pitti: please, you can change. I will adapt my code later :)
[12:37] <pitti> didrocks: ok, thanks
[12:37] <didrocks> pitti: yeah, python-distutils-mkdebian makes sense :)
[12:37] <pitti> didrocks: I actually renamed it to python-mkdebian now
[12:38] <pitti> since it works with any setup.py generated .egg-info, not just distutils or even just distutils-auto
[12:38] <pitti> yay being generic :)
[12:38] <pitti> .egg-info is an existing standard, which I just use as input for generating the debianization
[12:38] <pitti> anyway, lunch o'clock
[12:39] <asac> enjoy
[12:39] <didrocks> pitti: great ;) looking at those egg-info stuff is on my schedule too… ;)
[12:40] <didrocks> pitti: have a good lunch!
[12:40]  * didrocks jumps on mutter packaging
[12:47] <seb128> hyperair, not sure about this usershare issue either
[12:47] <seb128> hyperair, btw if you work on nautilus-share could you have a look at switching it to gtkbuilder?
[12:47] <hyperair> seb128: okay, i'll take a look at it.
[12:47] <hyperair> patches welcome though =p
[12:48] <hyperair> seb128: when will glade be phased out?
[12:48] <seb128> thanks
[12:48] <seb128> I might have a look, I already did some patches for other applications
[12:48] <lool> asac: Are these direct messages?  Perhaps you can subscribe to the list with all addresses you use and disable delivery
[12:48] <seb128> well I expect it will still be installed by default in karmic but not in karmic+1
[12:48] <seb128> but reducing the rdepends list would be nice
[12:48] <lool> asac: I'm happy to hand you admin and/or moderator permissions; I'd like to avoid maintaining black/whitelists
[13:00] <lool> asac: nothing in queue for<EMAIL_ADDRESS>actually
[13:03] <asac> hmm
[13:03] <seb128> mvo, hey
[13:03] <asac> is that on auto reject?
[13:04] <asac> lool: oh ;) ... it was a different mailing list ;)
[13:04] <asac> the moz-extmaintainers ;)
[13:04] <lool> Don't know about that one :)
[13:04] <seb128> mvo, do you think you could update libgksu to the current debian version?
[13:05] <seb128> mvo, you know the package better than me and I'm a bit busy with GNOME3 things before desktop summit
[13:05] <mvo> seb128: sure, I was sure that someone else did the merge, but I'm probably wrong
[13:05] <seb128> mvo, there is no hurry but kov applied my gtkbuilder change so it would be nice to have in karmic ;-)
[13:05] <mvo> !
[13:06] <seb128> mvo, the most recent upload is not from you right, let me know if you are too busy I will put that on my todolist for later, I pinged you because I know you worked on this one before and know it a bit
[13:08] <mvo> seb128: no prob, I can do the merge
[13:08]  * seb128 hugs mvo
[13:08] <mvo> seb128: I ported g-a-i to gtkbuilder today, you have been inspiring
[13:08] <mvo> :)
[13:10] <seb128> mvo, \o/
[13:40] <wiwar> how to switch off  "Mirror Screens" ("System"->"Preferences"->"Screen Resolution") option with configuration files ?
[13:42] <seb128> what do you mean by configuration files there?  why not using the tool?
[13:48] <wiwar> > why not using the tool? <    Because It doesn't save it's settings. Each time I should set them again, and that settinngs doesn't affect on output
[13:50] <seb128> wiwar, could you describe what you do exactly and the issue you get?
[13:53] <wiwar> seb128, I am trying to setup triplehead configuration. Here is my config - http://pastebin.com/m9880611
[13:53] <wiwar> The issue i get - left and central monitors show identical images
[13:54] <seb128> wiwar, is your issue with the dialog that it fails to apply your changes or that those are not applied after next login?
[13:54] <wiwar> "Mirror Screens" is selected and I am unable to deselect it
[13:55] <seb128> you might want to open an upstream bug on bugzilla.gnome.org
[13:55] <wiwar> First I deselect this option, then press "apply" button, then close dialog. When I open dialog again - option is still checked
[13:56] <seb128> I doubt many people have 3 screens to test such configs so it would not be surprising if it didn't get lot of testing
[13:56] <seb128> the configuration is written as monitors.xml in .config
[14:09] <hyperair> seb128: i'm working on the glade->gtkbuilder transition now. what's the gtkbuilder version of glade_xml_new(FILE, "first_widget", GETTEXT_PACKAGE)? the reference page on library.gnome.org only says how to deal with no GETTEXT_PACKAGE
[14:10] <hyperair> hmmmm maybe strings are already translated? =\
[14:17] <seb128> hyperair, http://library.gnome.org/devel/gtk/stable/gtk-migrating-GtkBuilder.html
[14:17] <hyperair> seb128: i'm already staring at that!
[14:18] <hyperair> seb128: but it only shows the alternative for glade_xml_new(FILE,"first_widget",NULL) <-- note the NULL as opposed to GETTEXT_PACKAGE
[14:18] <hyperair> seb128: if GtkBuilder automatically translates the strings, that's a different case
[14:18] <seb128> you have a translation domain different from the software one?
[14:20] <seb128> translations should be working out of the bug as for any other string using gettext
[14:21] <hyperair> ah then it's fine
[14:28]  * hyperair attempts to compile
[14:35] <pitti> rickspencer3, didrocks: wrt. the version number and generating debian/changelog, how is the workflow? does version in setup.py get bumped on "release", or immediately after "release"? what should python-mkdebian do if that version already exists in debian/changelog?
[14:36] <rickspencer3> pitti: I would think you would increment the version, and then release
[14:36] <kenvandine> pitti, i would vote for bumping it after release
[14:36] <kenvandine> :)
[14:36] <rickspencer3> hehe
[14:36] <kenvandine> look at what gnome does
[14:36] <kenvandine> first commit after a release is bumping the version
[14:36]  * kenvandine rather likes that model
[14:36] <pitti> usually you bump immediately after and set it to "UNRELEASED", and "release" sets UNRELEASED -> karmic
[14:37] <kenvandine> pitti, that is my preference
[14:37] <kenvandine> pedro_, good morning
[14:37] <pitti> so, should python-mkdebian bail out with an error if not "UNRELEASED" and setup.py version == debian/changelog versin?
[14:37] <rickspencer3> pitti: I'm not clear on how it is different for the user ... are you suggesting that your script incrememnts the version number after a release?
[14:37] <pedro_> morning kenvandine
[14:38] <pitti> rickspencer3: no, the build system doesn't ever touch setup.py
[14:38] <pitti> hey pedro_
[14:38] <pedro_> hello pitti
[14:38] <rickspencer3> so the user has to increment it at *some point* before they release
[14:38] <pitti> rickspencer3: it's probably a moot point, since debian/changelog cannot actually get "sensible" entries unless we are using proper version control
[14:39] <rickspencer3> we could do a commit before release if that would help
[14:39] <didrocks> pitti: rickspencer3 also proposed that quickly release version_number can bump the release in setup.py if not done before
[14:39] <pitti> seb128: ah, gdu-monitor works again with current udev
[14:40] <pitti> didrocks, rickspencer3: ok, easier questions: (1) should python-mkdebian error out if you try to call it on the same version twice? (2) do you want to use the UNRELEASED schema, or just keep it at "karmic" all the time?
[14:41] <rickspencer3> pitti: I think it should error out, at least for the first iteration
[14:41] <rickspencer3> seems simpler to me
[14:41] <didrocks> pitti: python-mkdebian touches the changelog entry?
[14:41] <pitti> rickspencer3: that would imply keeping it at UNRELEASED, and then something has to call dch -r
[14:41] <pitti> didrocks: well, if no changelog exists, we dch --create, that's easy
[14:42] <rickspencer3> oh, I was thinking the script just bails and the user starts over
[14:42] <pitti> but I wonder what should happen if it already exists
[14:42] <pitti> rickspencer3: well, you might want to build several test debs until you release
[14:42] <pitti> well
[14:42] <pitti> I think I keep it very easy for now
[14:42] <didrocks> hum. I prefer UNRELEASED too. But I'm unsure for python-mkdebian question
[14:42] <pitti> don't use UNRELEASED, and just do nothing if the changelog entry already existsi
[14:42] <pitti> if we need something more elaborate, we can bolt that on later
[14:43] <pitti> that way it will never fail
[14:43] <rickspencer3> pitti: right
[14:43] <pitti> and release management is entirely up to quickly
[14:43] <didrocks> ok, we will see then what people ask for :)
[14:43] <rickspencer3> right, quickly could detect the error and do something
[14:43] <pitti> http://bazaar.launchpad.net/%7Epython-distutils-extra-hackers/python-distutils-extra/debian/changes making good progress :)
[14:43] <rickspencer3> simple is good
[14:44] <pitti> rickspencer3: in that simple model there wouldn't ever be an error
[14:44] <pitti> i. e. python-mkdebian knows nothing about the concept of a "release"
[14:44] <pitti> but of course we need to track it somewhere, e. g. you can't upload the same version twice
[14:45] <didrocks> pitti: python-mkdebian just read the changelog to detect the version according to setup.py, add dch -i if not the same and build the package?
[14:45] <rickspencer3> pitti: quickly could detect it *first* before it kicks off the script
[14:45] <pitti> let's see how that will work out
[14:45] <pitti> didrocks: right
[14:45] <didrocks> pitti: for uploading, this is really on quickly side, I think.
[14:45] <didrocks> so, quickly has to detect it as it is the link with launchpad
[14:45] <pitti> didrocks: I agree, makes things less complicated and less prone to inconsistencies
[14:46] <pitti> didrocks: well, if I were you, a "quickly release" or "quickly upload" would just bump the version after a successful upload
[14:47] <didrocks> pitti: that's possible, but how to guess that user wants going from  3.0 to 3.1, or 3.5, or even 4.0 ? (no real example included) ;)
[14:48] <pitti> didrocks: oh, do you care? I thought you'd just start with 1 and then just count upwards
[14:48] <didrocks> pitti: ok, let's do that in a first approach
[14:48] <pitti> didrocks: if you want more elaborate major/minor, you just have to ask or --version then, I guess
[14:49] <pitti> "quickly release-management" (is this simple and fun? :-) )
[14:50] <didrocks> pitti: will see that for quickly 0.2, let's just bump for the moment ;)
[14:56] <rickspencer3> didrocks: we should get quickly into a ppa by Friday it possible
[14:57] <rickspencer3> what should I prioritize between now and then? fixing the tutorial up?
[14:58] <didrocks> rickspencer3: yes, fixing the tutorial. I will finish the release command.
[14:58] <didrocks> I'm currently working on the mutter packaging. I will then work on quickly to polish those little things :)
[14:59] <didrocks> and then release 0.1~alpha in the ppa
[14:59] <pitti> didrocks.fork()
[15:00] <didrocks> pitti: ahah ;)
[15:01] <didrocks> currently, it's more didrocks.laptop.pbuilder.karmic.make_distcheck()
[15:03] <SiDi> EAGAIN, pitti
[15:03] <pitti> didrocks, rickspencer3: so, changelog looks pretty boring, but it works: http://paste.ubuntu.com/206975/
[15:03] <pitti> SiDi: hello?
[15:04] <SiDi> pitti: nevermind :p EAGAIN is an error code for when you cant get a process when fork'ing
[15:05] <pitti> SiDi: oh, I see :)
[15:05] <didrocks> pitti: this is only in the case where the user only "quickly release" if she/he "quickly release something very interesting", quickly will change it in the changelog.
[15:05] <vladzur> hi, somebody know how edit HD videos? (m2ts)
[15:05] <pitti> didrocks: oh, are you saying that you want to maintain debian/changelog yourself?
[15:05] <pitti> didrocks: by default, mkdebian will put in "new release" right now, so that it also works independently of quickly
[15:06] <pitti> didrocks: but I can add a parameter for a changelog entry if you want me
[15:06] <didrocks> pitti: it would be awesome ;)
[15:06] <pitti> didrocks: (in the next version, I want to get this working with a simple approach first)
[15:06] <pitti> I'll add optparse to it later, then
[15:07] <didrocks> perfect, let's just write it somewhere to remember later
[15:07] <pitti>         # TODO: add CLI option to specify changelog
[15:07] <pitti> ^ done
[15:08] <didrocks> :)
[15:09] <didrocks> hum, mutter seems to require a updated clutter version. The configure is ok, but it FTBFS with incompatible pointer type…
[15:10] <seb128> didrocks, should be easy to change?
[15:11] <didrocks> seb128: if I look deeper, it's more a function call error (not the god signature): guint is expected and gfloat is given
[15:12] <seb128> didrocks, do you use a tarball or git?
[15:12] <didrocks> seb128: git, they didn't roll tarball for mutter
[15:12] <seb128> oh
[15:13] <didrocks> seb128: last taggued version in the git branch is still a metacity package also
[15:14] <seb128> better to use current git
[15:14] <seb128> those are not aimed at karmic proper but to a gnome-shell ppa for now anyway
[15:15] <didrocks> seb128: yes. I just have to fix this FTBFS and see if transtyping from gfloat to guint is harmless in this case :)
[15:19] <pitti> Now running lintian...
[15:19] <pitti> W: jockey: binary-without-manpage usr/bin/jockey-gtk
[15:19] <pitti> W: jockey: binary-without-manpage usr/bin/jockey-kde
[15:19] <pitti> E: jockey: extended-description-is-empty
[15:19] <pitti> not too bad for a completely autogenerated package
[15:20] <idorock89> hi i wanted to ask about empathy
[15:21] <idorock89> will it have google video chat and msn video chat in time for karmic?
[15:23] <artir> google video chat (jingle) already works
[15:24] <didrocks> seb128: I think that's a warning transformed in a error. I infer that launching autogen.sh on a non official version which calls gnome-autogen.sh enables a --debug or --enable-debug option when configuring. Are you aware about this and how to desactivate it when running autogen.sh?
[15:25] <Zdra> idorock89: MSN video/audio is being worked, difficult to say if that will be ready for karmic, but upstream is close to get it done AFAIK
[15:25] <Zdra> idorock89: and google video is already done
[15:25] <Zdra> idorock89: since latest release of gabble
[15:26] <idorock89> Zdra: wow really didnt see a blog post about it on any planet.
[15:26] <idorock89> Zdra: so i can video chat from empathy 2.27.4 to windows user using gmail video chat ?
[15:27] <Zdra> idorock89: I think, yes
[15:27] <idorock89> Zdra: ok.really cool.
[15:28] <artir> another "cool" thing is that if u have 2.27.* and other guy has 2.26 and u try to do a videochat with him, his empathy will crash :P
[15:28] <Zdra> idorock89: you need telepathy-gabble 0.7.30 released yesterday
[15:28] <seb128> didrocks, is -Werror set?
[15:30] <didrocks> seb128: yes. I try to pass --disable-debug to autogen.sh, without success
[15:31] <seb128> didrocks, -Werror is probably defined in configure.in somewhere
[15:31] <seb128> just drop it before running autogen
[15:32] <didrocks> seb128: ok. I was thinking of a better way with options handled by autogen.sh, but well… ;) let's try to seek in configure.in
[15:34] <idorock89> artir: and did u try it with someone on windows using gmail video chat?
[15:34] <artir> nope
[15:34] <artir> just empathy to empathy
[15:39] <Ampelbein> seb128: hi. do you think bug #256041 is worth a SRU? Provided that the fix gets in karmic of course.
[15:42] <didrocks> seb128: well, that works for easy casting thing. Now, it seems there is an error with an external function: http://pastebin.com/m6bd1388a)
[15:42]  * didrocks will poke upstream ;)
[15:47] <seb128> didrocks, upstream is on on irc.gnome.org
[15:47] <seb128> Ampelbein, there is no duplicate for the bug so it doesn't seem a frequent user complain
[15:47] <seb128> Ampelbein, but otherwise could be a candidate for a sru yes
[15:48] <didrocks> seb128: yep, I'm already there. Seems that's because of an old clutter lib
[15:48] <seb128> didrocks, they use clutter 0.8 or 0.9?
[15:49] <didrocks> seb128: clutter-0.9.4 is needed
[15:49] <seb128> didrocks, it's in universe enjoy the update ;-)
[15:49] <didrocks> seb128: I was sure you were about telling that ;-)
[15:50] <seb128> hehehe
[15:51] <didrocks> seb128: upstream also told me that there is a whole bunch of changes just pulling right now. So, I'm waiting for an hour ;)
[15:52] <seb128> didrocks, you can probably do the clutter update during that time ;-)
[15:52] <didrocks> :p
[15:52] <seb128> didrocks, your work is really appreciated btw in case I don't tell it enough ;-)
[15:53] <didrocks> seb128: thanks ;-)
[16:04] <mvo> and another app ported to gtkbuilder: update-manager
[16:04] <pitti> \o/
[16:04] <pitti> I ported jockey yesterday
[16:04] <mvo> fortunately hardy python-gtk2 supports it
[16:04] <mvo> so even the release upgrader can be ported :)
[16:05] <mvo> still some more to go (gdebi, langauge-selector, software-properties, synaptic), but fortunately its pretty trivial
[16:05] <seb128> yeah, I did libgksu and nautilus-sendto yesterday
[16:06] <mvo> sweet
[16:17] <dobey> pitti: ping
[16:17] <pitti> hey dobey
[16:17] <dobey> pitti: does the .examples file in debian/ need to match the binary pkg name, or the source?
[16:18] <pitti> dobey: binary (that's true for all debhelper files)
[16:18] <dobey> pitti: ok. just wondering because the two comments in REVU from you didn't line up exactly :)
[16:20] <dobey> pitti: and what's the Vcs-Bzr: syntax? lp:project works?
[16:21] <pitti> dobey: it points to the https://code.launchpad.net/... page with the branch, if you use bzr for packaging
[16:21] <pitti> with that, other developers know if/where to commit changes
[16:21] <dobey> ok
[16:22] <dobey> i'll leave it out for now then. as there are still some changes that need to be done for that
[16:28] <asac> awe: there atm?
[16:28] <awe> asac: yea
[16:29] <asac> awe: do you think we should just track tags for connman or upload latest git?
[16:30] <asac> seems there is a lot of activity in the past 6 weeks (since last tag)
[16:30] <awe> but no new tag?
[16:30] <asac> and most likely the -gnome bits need the latest anyway
[16:30] <asac> awe: no new tag for 6 weeks yes
[16:31] <awe> sounds like we have no choice then
[16:31] <asac> and maybe 120 commits or something ;)
[16:38] <mvo> mpt: I looked at bug #377697 and it seems like update-manager should not be auto-opend if running on battery
[16:38] <mvo> mpt: does that sound right to you?
[16:39] <mpt> hmmm
[16:40] <mpt> mvo, that would mean you were never notified if you only ever work on battery (and charge it while suspended/off)
[16:40] <mvo> yes
[16:40] <mpt> so, maybe not :-)
[16:41] <didrocks> seb128: clutter upstream removed a bunch of symbols without bumping the soname (between 0.9.2 and 0.9.4). the library is still named libclutter-glx-0.9.so.0. What do you think we should do?
[16:41] <mvo> mpt: ok
[16:41] <seb128> didrocks, no rdepends -> upgrade
[16:42] <seb128> didrocks, you can ask upstream about it but they will probably say that 0.9 is unstable and has no stability guaranty
[16:43] <didrocks> ok, let's be afraid in seing the number of rdepends ;)
[16:43] <seb128> lol
[16:43] <seb128> none? ;-)
[16:44] <didrocks> exactly ;-)
[16:44] <didrocks> \o/
[16:44]  * didrocks wonders why he checks API compatibility before performing rdepends ;)
[16:45] <seb128> lol
[16:45] <seb128> because for stable updates you don't want to break api
[16:46] <didrocks> seb128: yes, for third-party apps, right? (even if there are no rdepends)
[16:46] <seb128> didrocks, indeed
[16:48] <pitti> Keybuk: bzr push in udev please
[16:49]  * pitti currently wrestles with a gtk-doc FTBFS
[16:49] <Keybuk> pitti: pushed
[16:50] <pitti> Keybuk: it seems that you somehow did some magic to the tree to actually build; here it fails on a missing version.xml
[16:50] <pitti> I start with a clean bzr, then gtkdocize --copy, then autoreconf -fvi
[16:51] <Keybuk> the magic is in debian/rules
[16:51] <pitti> Keybuk: I'll add --fail-missing to dh_install and add the missing bits, FYI
[16:51] <Keybuk> pitti: that'll fail the entire build
[16:51] <pitti> (such as the consolekit helper)
[16:51] <Keybuk> due to the way it does udebs
[16:51] <Keybuk> I think I also deliberately miss things out
[16:51] <pitti> Keybuk: I just see debian/rules tarball?
[16:52] <Keybuk> pitti: right, that makes the tarball
[16:52] <Keybuk> debian/rules package makes the source package
[16:52] <pitti> ah, and then you untar this into . ?
[16:52] <Keybuk> right
[16:52] <Keybuk> well, I unpack that source package and build from there
[16:54] <pitti> hm, unpacking the tarball leaves a huge bzr diff (probably from git pull after 143)
[16:54] <Keybuk> sure
[16:54] <Keybuk> 'tis what you'd expect
[16:55]  * pitti reverts that and hopes for the bets
[16:55] <pitti> best, too
[16:55] <Keybuk> reverts which bit?
[16:55] <pitti> well, I did "tar xzf ../udev_143.orig.tar.gz --str=1" into the bzr tree
[16:55] <Keybuk> oh
[16:55] <Keybuk> don't do that ;)
[16:55] <pitti> but that restores the files to 143 release
[16:55] <Keybuk> just bzr get the source tree
[16:56] <pitti> it doesn't use bzr-buildpackage, nor patches, so how else would I get an actually buildable source tree under bzr control?
[16:56] <Keybuk> this was so much easier when all we had to do was "apt-get source" :)
[16:56] <Keybuk> pitti: you can't
[16:56] <pitti> erm
[16:56] <Keybuk> the bzr tree is unbuildable
[16:56] <pitti> but how else do I do, test, and commit several changes?
[16:56] <pitti> hm
[16:56] <Keybuk> but you can make a source package from it
[16:56] <Keybuk> unpack the source package
[16:57] <Keybuk> and test that
[16:57] <pitti> meh, that's hilarious
[16:57] <Keybuk> I agree
[16:57] <Keybuk> bzr fail
[16:57] <pitti> revision control+autoconf fail, rather
[16:57] <pitti> they really hate each other
[16:57]  * Keybuk looks forlornly at his multi-year-open bugs against bzr that prevent a buildable udev from being checked in
[16:57] <Keybuk> it's nothing to do with autoconf
[16:57] <Keybuk> autoconf is just fine with revision control, cf. upstart
[16:58] <Keybuk> it's make vs. revision control
[16:58] <Keybuk> or more accurately, bzr's inability to apply any common sense to timestamps
[16:58] <pitti> well, why wouldn't I be able to autoreconf and build the bzr tree?
[16:58] <pitti> this should just work..
[16:58] <Keybuk> because then dpkg complains about things like the test/ subdirectory
[16:58] <Keybuk> which only exists in bzr
[16:58] <pitti> no
[16:58] <Keybuk> that's a dpkg issue ;)
[16:59] <pitti> make fails
[16:59] <Keybuk> make works here
[16:59] <pitti> it stumbles over a missing version.xml for gtk-doc
[16:59] <pitti> which apparently gets magically generated in the tarball
[16:59] <Keybuk> oh
[16:59] <Keybuk> right
[16:59] <Keybuk> that's a gtk-doc issue
[16:59] <Keybuk> which is broken
[16:59] <Keybuk> it doesn't even support out-of-tree builds properly ffs
[17:00] <pitti> but it works with the uploaded udev
[17:00] <Keybuk> right, because the tarball has the extra magic files you need
[17:00] <pitti> (which incidentally ships pre-made version.xml files)
[17:00] <Keybuk> but you can't put those files into the bzr tree, because bzr screws up timestamps
[17:00] <pitti> if I copy them from the tarball, it works
[17:00] <pitti> but why would I in the first place?
[17:00] <Keybuk> because that's the right thing to do
[17:00] <pitti> it should just build version.xml from .in at build
[17:01] <Keybuk> gtk-doc doesn't do that
[17:01] <pitti> either by make, or by autoreconf
[17:01] <Keybuk> because of the out-of-tree build
[17:01] <Keybuk> it's broken ;)
[17:01] <Keybuk> see above
[17:01] <pitti> ah, that's why you have to do make all dist?
[17:01] <Keybuk> you got it :)
[17:01] <pitti> *ugh*
[17:01] <Keybuk> tell me about it
[17:01] <pitti> Keybuk: ok, thanks for the heads-up
[17:02] <Keybuk> ideally, what I'd do would be
[17:02] <Keybuk> bzr pull from git to update to a new release
[17:02] <Keybuk> then import the tarball over the top, to add all of the missing files
[17:02] <Keybuk> then pull from that into the ubuntu tree
[17:02] <Keybuk> to pull from git head, I'd just pull directly
[17:03] <Keybuk> that should cause automake to regenerate all the files anyway, and commit them along with the merge
[17:03] <Keybuk> *but*
[17:03] <Keybuk> I can't pull from git, because bzr-git can't read the udev git repo
[17:03] <Keybuk> (to be fair, even bzr fast-import has issues on a near weekly basis)
[17:03] <Keybuk> I can't import the tarball, because bzr doesn't apply sane timestamp logic, so you end up in a rebuild death spiral
[17:03] <seb128> didrocks, \o/ new clutter ;-)
[17:03] <Keybuk> so I sit here, in my little house of fail
[17:04] <Keybuk> oh, and then I'd do dpkg-buildpackage (or bzr-buildpackage) to make the source package
[17:04] <Keybuk> but that doesn't work either, because of the things that are in git but not in the tarball
[17:04] <Keybuk> and dpkg goes nuts about them
[17:07] <Keybuk> pitti: it occurs that if it's obvious that a particular file (version.xml) doesn't exist
[17:07] <Keybuk> we could have a debian/rules snippet to do everything required to make it
[17:07] <Keybuk> and have other things depend on it
[17:07] <pitti> right
[17:07] <Keybuk> and could get rid of the clean-tree things then
[17:07] <Keybuk> which are "throw away everything I forgot to commit plz"
[17:07] <pitti> Keybuk: I'm in the middle of figuring out the magic incantatino to turn a bzr checkout into a buildable tree
[17:07] <Keybuk> pitti: it's the bits at the top of tarball
[17:07] <pitti> Keybuk: I'd like to add that as debian/rules prep or so
[17:08] <Keybuk> though you need to not use autogen.sh
[17:08] <pitti> no
[17:08] <Keybuk> gtkdocize --copy
[17:08] <pitti> autogen.sh is broken
[17:08] <Keybuk> autoreconf --install
[17:08] <pitti> right
[17:08] <Keybuk> make distclean
[17:08] <Keybuk> ./configure --enable-gtk-doc
[17:08] <Keybuk> make all dist
[17:08] <Keybuk> hmm
[17:08] <Keybuk> actually omitting the make distclean will work if not using autogen.sh
[17:08] <Keybuk> gtkdocize --copy
[17:08] <Keybuk> autoreconf --install
[17:08] <Keybuk> ./configure --enable-gtk-doc
[17:09] <Keybuk> make all dist
[17:09] <Keybuk> ;)
[17:09] <pitti> kdocize --copy
[17:09] <pitti> autoreconf -fvi
[17:09] <pitti> rm -rf autom4te.cache/
[17:09] <pitti> ./configure --enable-gtk-doc
[17:09] <pitti> make all dist
[17:09] <pitti> make distclean
[17:09] <pitti> (plus the missing "gt")
[17:09] <Keybuk> NO!
[17:09] <Keybuk> never use autoreconf -f
[17:09] <Keybuk> ever
[17:09] <Keybuk> ever
[17:09] <Keybuk> ever
[17:09] <Keybuk> BAD PITTI!
[17:09] <pitti> *shrug* it's a clean tree
[17:09]  * pitti removes the -f, I don't particularly care
[17:09] <Keybuk> make all dist distclean would work ;)
[17:10] <Keybuk> pitti: putting -f in there is a bad habit to get into
[17:10] <Keybuk> autoreconf shouldn't even *have* a -f
[17:10] <Keybuk> autoreconf -f really means "forcibly update everything auto-* related to the latest version, whether or not it'll work"
[17:12] <pitti> Keybuk: nope, that's still not it
[17:12] <pitti> warning: failed to load external entity "../version.xml"
[17:12] <pitti> ../libudev-docs.xml:10: parser error : Failure to process entity version
[17:12] <pitti> $ find -name version.xml
[17:12] <pitti> ./build-deb/extras/gudev/docs/version.xml
[17:12] <pitti> ./build-deb/libudev/docs/version.xml
[17:12] <pitti> but not in the root tree
[17:12] <Keybuk> err
[17:12] <Keybuk> why were you in build-deb to begin with?
[17:12] <pitti> distclean might wipe it?
[17:12] <Keybuk> oh, maybe
[17:12] <pitti> I wasn't
[17:12] <pitti> I did above steps in root, then buildpackage
[17:13] <Keybuk> of course, if you don't "distclean" you can't build
[17:13] <Keybuk> you'll get "source directory is configured, wah wah sky is falling"
[17:13] <pitti> but how did it ever go into the orig.tar.gz then?
[17:13] <pitti> ah, make dist
[17:14] <Keybuk> you can see how I got to the point where I just make a source package from bzr
[17:14] <Keybuk> unpack it elsewhere
[17:14] <Keybuk> and build and test that
[17:14] <Keybuk> ;)
[17:14] <pitti> Keybuk: I think I'm at the point where I'd just add a workaround for the gtk-doc breakage
[17:14] <pitti> liek copying version.xml in debian/rules
[17:16] <Keybuk> ;)
[17:17] <Keybuk> there must be a makefile rule to build it
[17:17] <Keybuk> trouble is that it always looks in $(srcdir) for it, never $(builddir)
[17:17] <Keybuk> otherwise how does it end up in build-deb/ ?
[17:20] <didrocks> seb128: hehe :-)
[17:22] <bryce> good morning everyone
[17:22] <pitti> hey bryce
[17:23] <seb128> hey bryce
[17:25] <didrocks> hello bryce
[17:26] <rickspencer3> team meeting in four minutes
[17:29] <seb128> meeting'o'clock!
[17:30] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-06-30
[17:30] <rickspencer3> asac: ArneGoetje bryce ccheney awe seb128 pitti Riddell
[17:31] <ArneGoetje> here
[17:31]  * rickspencer3 taps gavel
[17:31] <seb128> hello
[17:31] <awe> hey
[17:31] <asac> hi
[17:31] <bryce> heya
[17:31] <rickspencer3> kenvandine:
[17:32] <rickspencer3> shall we start? is this a quorum?
[17:32] <pitti><EMAIL_ADDRESS>hey... having irc issues
[17:32] <seb128> yes, pitti is around he was writing on some other channel some seconds ago
[17:32] <pitti> FYI
[17:32] <rickspencer3> heh
[17:33] <rickspencer3> ok, let's roll
[17:33]  * rickspencer3 refreshes to check for new agenda items
[17:33] <rickspencer3> outstanding items from last meeting
[17:33]  * pitti smuggles in a "GDM" topic
[17:34] <rickspencer3> paper cuts: they got 10 fixed last week, seemed to be a success, so great
[17:34] <rickspencer3> pitti: np, I'll that to the discussion section
[17:34] <kenvandine> sorry folks... technical difficulties :)
[17:35] <rickspencer3> awe: did you review the audio spec for TheMuso?
[17:35] <awe> yea... i'll send him comments before this evening's meeting
[17:35] <rickspencer3> sweet
[17:35] <rickspencer3> two announcements:
[17:36] <rickspencer3> 1. if you haven't booked travel for the sprint, please do so today
[17:36] <rickspencer3> 2. a few of us are traveling to Desktop Summit
[17:36] <rickspencer3> I'm leaving tomorrow, a few are leaving on Thursday, right?
[17:36] <seb128> rickspencer3, "today"? is there any hurry?
[17:36] <rickspencer3> like robert_ancell is leaving Thursday
[17:36]  * seb128 still not decided between sucking flight options
[17:37] <seb128> I'm travelling on friday for desktop summit
[17:37] <rickspencer3> seb128: "today" was probably unnecessarily dramatic, but it does get more expensive for some of us if we wait to long
[17:37] <seb128> I'm travelling on friday for desktop summit, landing in the afternoon
[17:37] <seb128> rickspencer3, ok
[17:37] <kenvandine> rickspencer3, yeah... mine jumped $200 over night while i thought about it..
[17:37] <kenvandine> booked now
[17:37] <rickspencer3> kenvandine: is arriving next Tuesday
[17:37] <rickspencer3> Riddell: when are you ariving?
[17:37] <kenvandine> rickspencer3, arriving monday afternoon
[17:38] <rickspencer3> kenvandine: ack, thanks
[17:38] <rickspencer3> kenvandine: partner update?
[17:39] <kenvandine> yeah
[17:39] <kenvandine> so ubuntuone packages are still being worked, dobey did a bit of a re-org to properly manage the packaging feedback he got in revu
[17:40] <kenvandine> that should be updated in revu today, hopefully we can get that reviewed quickly
[17:40] <kenvandine> dx team still hasn't communicated their iteration plans yet, but I do know fusa changes will land end of week
[17:40] <kenvandine> at least all the basic functionality needed for the new GDM
[17:40] <kenvandine> we need to decide if we want to go ahead and ship it with the new GDM
[17:40] <kenvandine> seb128, thoughts?
[17:41] <seb128> speaking about dxteam, apparently they wrote a new applet rather than adapting the gdm one?
[17:41] <pitti> why oh why?
[17:41] <kenvandine> i hadn't heard that... i knew it was a big change
[17:41] <kenvandine> using the dbus menus
[17:41] <seb128> hum, ted is not around and I guess that's a question for him rather
[17:42] <kenvandine> we can talk to him about that
[17:42] <kenvandine> they did the dbus menus work
[17:42] <kenvandine> which should be nice
[17:42] <seb128> "dbus menu"?
[17:42] <seb128> what is that?
[17:42] <kenvandine> might have required enough change to start over
[17:42] <kenvandine> so apps can export menus to other apps
[17:42] <artir> https://launchpad.net/dbusmenu
[17:42] <kenvandine> over dbus
[17:42] <rickspencer3> is there ambiguity regarding shipping new GDM?
[17:43] <seb128> how is that revelent to fuse and gdm update?
[17:43] <kenvandine> seb128, new fusa uses it
[17:43] <seb128> this dbusmenu things seems a different topic
[17:43] <pitti> I think new gdm is almost ready to go
[17:43] <seb128> well that's a technical decision from them not a justification to fork upstream imho
[17:43] <kenvandine> so it might have been enough work to just start over... i guess
[17:43] <kenvandine> not sure
[17:43] <kenvandine> yeah
[17:43] <kenvandine> rickspencer3, i don't think it is a question... it is more "are we ready next week"
[17:44] <kenvandine> or right after guadec :)
[17:44] <seb128> especially that ted was speaking about using different namespacing for the applet
[17:44] <seb128> so requiring another user configuration migration on upgrade
[17:44] <kenvandine> sigh
[17:44] <kenvandine> ok... we need to talk to him
[17:44] <seb128> yeah
[17:44] <kenvandine> he didn't mention that part to me :)
[17:44] <seb128> otherwise new gdm: help is welcome to fix upgrade issues
[17:44] <seb128> and pitti says there is a blocker gpm issue too
[17:45] <kenvandine> also, the ubuntuone karmic integration spec is approved
[17:45] <pitti> seb128: well, not really a "blocker" for uploading gdm
[17:45] <seb128> upgrade issue being that we can't restart gdm on upgrade because that would close running sessions
[17:45] <kenvandine> so we will have more MIRs coming, as the code is written
[17:45] <seb128> but the banner is broken until restart
[17:45] <pitti> seb128: I meant the weird session saving dialog
[17:45] <seb128> pitti, that's not my main concern, the concern is that gdm is not working until reboot
[17:46] <seb128> it just displays a banner error
[17:46] <rickspencer3> seb128: pitti: can we not live with gdm not working until reboot for the time being, for alpha users?
[17:46] <seb128> and clicking ok makes the same error come back
[17:46] <pitti> rickspencer3: WFM
[17:46] <seb128> rickspencer3, yeah we can
[17:46] <kenvandine> ok, i think that is all i have...
[17:46] <seb128> upload is mainly blocked on the fusa update right now
[17:46] <rickspencer3> so can we accelerate moving gdm out of the ppa and document the workaround?
[17:47] <rickspencer3> ah
[17:47] <seb128> without the patched fusa there is no way to reboot or stop your machine since we patch gnome-panel to not list those actions by default
[17:47] <pitti> seb128: I don't think we should care about that; can't we just use the upstream fusa for the time being?
[17:47] <rickspencer3> so shall kenvandine organize syncronizing those uploads, without blocking on finishing gdm?
[17:47] <pitti> oh, eww
[17:47] <seb128> we could drop that patch meanwhile too if required
[17:47] <pitti> seb128: *nod*
[17:48] <kenvandine> rickspencer3, i can do that
[17:48] <kenvandine> should we block on migration for fusa?
[17:48] <seb128> I'm not very comfortable uploading the new gdm just before traveling
[17:48] <kenvandine> or is migration not that important?
[17:48] <rickspencer3> ACTION: kenvandine to organize uploading new FUSA applet and new GDM, document workarounds
[17:48] <seb128> I can do that next week when coming back from GUADEC
[17:48] <kenvandine> seb128, lets do it right after we return
[17:48] <pitti> seb128: I'm not going, I can care about that if you wnat me to
[17:48] <pitti> like, care for the fallout
[17:48] <kenvandine> pitti, that is great :)
[17:48] <pitti> but well, next week would suffice
[17:49] <seb128> pitti, ok, let's discuss that after meeting and upload tomorrow if we will comfortable
[17:49] <kenvandine> fusa changes will land at the end of this week
[17:49] <pitti> cool
[17:49] <seb128> extra people installing the ppa version would be welcome
[17:49] <seb128> just to confirm it somewhat works for several users
[17:49] <rickspencer3> who volunteers?
[17:49] <seb128> it's in the ubuntu-desktop ppa
[17:49] <hggdh> will do
[17:49] <rickspencer3> to  try the gdm in the ppa?
[17:49] <rickspencer3> o/
[17:49] <pitti> running for several days, no probs except http://bugzilla.gnome.org/show_bug.cgi?id=585228
[17:50] <rickspencer3> not too many volunteers :)
[17:50] <seb128> ok good, I think we have everything we need there
[17:50] <pedro_> I'll help with that as well
[17:50] <rickspencer3> kenvandine: are you running new gdm?
[17:50] <kenvandine> not anymore
[17:50] <kenvandine> i had a VM with it
[17:50] <kenvandine> but it got whacked
[17:50] <Riddell> rickspencer3: I'm arriving tomorrow evening
[17:50] <artir> seb128: tried it too in virtualbox, it works
[17:50] <kenvandine> i can get it going again
[17:50] <rickspencer3> ok, three of us should suffice though
[17:50] <seb128> yeah, we will do with what we have
[17:51] <jcastro> should I do a call for testin the new GDM?
[17:51] <kenvandine> jcastro, not really great timing...
[17:51] <seb128> jcastro, I think the some people volunteering here will be enough
[17:51] <kenvandine> since we are all leaving :)
[17:51] <rickspencer3> ACTION: hggdh, rickspencer3, pedro_ to install new gdm from ubuntu-desktop ppa, report serious problems to seb128 and/or kenvandine
[17:51] <jcastro> ok
[17:51] <seb128> but thanks
[17:51] <rickspencer3> jcastro: but you could try it yourself
[17:52] <rickspencer3> kenvandine: was that the whole partner update?
[17:52] <kenvandine> rickspencer3, yup, the acceptance tests haven't changed
[17:52] <kenvandine> well, updated... no new info :)
[17:52] <rickspencer3> hmm
[17:52] <rickspencer3> ok
[17:52] <kenvandine> what did i miss?
[17:52] <rickspencer3> thanks kenvandine
[17:52] <kenvandine> ok :)
[17:52] <rickspencer3> Riddell: Kubuntu update?
[17:53] <Riddell> Kubuntu: KDE 4.3 RC 1 is in progress and will start uploading tonight
[17:53] <Riddell> Arora is now the default browser (pre-empting big discussion just started by suse on the topic)
[17:53] <Riddell> Kubuntu Tutorials Day was a big success, see logs https://wiki.kubuntu.org/KubuntuTutorialsDay
[17:53] <Riddell> New council members vote is now under way
[17:54] <Riddell> is all
[17:54] <rickspencer3> Riddell: how is the netbook version going?
[17:54]  * rickspencer3 wants to try
[17:54] <Riddell> scott created the seeds, it's waiting on the changes to the image building scripts to get merged in for images
[17:54] <rickspencer3> sweet!
[17:54] <Riddell> and also on a settings package, currently it won't actually do anything different
[17:55] <rickspencer3> oh?
[17:55] <Riddell> tonio is working on that
[17:55] <asac> Riddell: can we remove konqueror now? or do you still need it installed?
[17:55] <Riddell> asac: it's still needed, it'll still be on the CDs for this release at least
[17:55] <Riddell> baby steps
[17:56] <asac> Riddell: so you have now two browsers by default
[17:56] <asac> whats up there?
[17:56] <asac> i know that there is something difficult ongoing, but two browsers by default sounds really odd.
[17:56] <Riddell> well politics and fanboys, removing Konqueror will get us flamed by various people (we have two file managers anyway)
[17:57] <Tm_T> Konqueror is not something one can remove without flaming
[17:57] <Tm_T> nor without issues in overall
[17:57] <rickspencer3> but having two applications that do the same thing because of fan boys doesn't sound very user-centric
[17:57] <asac> how does the user experience look like? what will be used by default if you click on a http link?
[17:57] <asac> how can the user switch the default
[17:58] <seb128> why can't use who want to use it install it from universe or something?
[17:58] <Riddell> arora currently, there's a System Settings module for default apps
[17:58] <Tm_T> asac: it's all in the systemsettings, clearly labeled
[17:58] <asac> Riddell: cant that be done in a way that installs konqueror on demand?
[17:58] <asac> e.g. when user select "konqueror" as default browser, it gets automatically installed
[17:58] <asac> like codecs etc.?
[17:59] <Riddell> it could.. but this is controvertial enough without upsetting more people
[18:00] <seb128> maybe we should install empathy and pidgin by default in ubuntu ;-)
[18:00] <asac> ok... but to understand, you only have one "webbrowser" menu entry in "applications" (if something like that exists on kde) ... and userr configures what that means in system settings?
[18:00] <Riddell> asac: right
[18:00] <asac> or are there both browser in the menu?
[18:00] <seb128> (to avoid people complaining about us switching)
[18:00] <rickspencer3> ok, this sounds like a good discussion for #kubuntu-devel
[18:01] <asac> Riddell: do both at least us the same webkit lib?
[18:01] <Riddell> asac: no, that's the main problem with konqueror
[18:01] <asac> (to not duplicate seucitry=
[18:01] <Riddell> but we can't get rid of khtml, it's part of kdelibs
[18:02] <asac> ok. maybe we can review this later this cycle ;)
[18:03] <asac> moving on?
[18:03] <rickspencer3> ACTION: ALL - provide feedback and help regarding Kubuntu browsers to Riddel in #kubuntu-devel
[18:03] <rickspencer3> thanks Riddell
[18:03] <rickspencer3> bryce: quick x update?
[18:04] <bryce> sire
[18:04] <bryce> er sure
[18:04] <bryce>  * Merge Status:
[18:04] <bryce>    + Mostly waiting on upstream releases at this point.
[18:04] <bryce>    + 12 packages need merge/sync, out of 92 updates since Jaunty
[18:04] <bryce>    + 7 packages have upstream releases but not yet in Debian
[18:04] <bryce>    + -fglrx and -nvidia completed PPA testing.  Now in Ubuntu.
[18:04] <bryce>    + mesa, xorg merges completed git staging.  Now in Ubuntu
[18:04] <bryce>    + A new xserver RC is available.  Will be merged soonish.
[18:04] <bryce>    + git snapshots of -ati/KMS, & -nouveau/KMS are in PPAs
[18:04]  * rickspencer3 in awe of bryce's typing speed
[18:05] <bryce> tjaalton just did the mesa and xorg uploads a few minutes ago, so y'all will be getting those soon
[18:05] <bryce>  * X.org in Karmic is working well
[18:05] <bryce>    + 2069 total open X bugs, down 38 since last week
[18:05] <bryce>    + KMS on -intel is now on by default; relatively few bugs are being
[18:05] <bryce>      reported about it.
[18:05] <rickspencer3> great news about KMS
[18:05] <pitti> I just fixed hal to not conflict with new xorg, so please don't complain :)
[18:05] <asac> is the "lock up on screen powersave" bug fixed for i965?
[18:06] <bryce> this past week I've been arm deep in bugs, and things "feel" fairly stable.  At the moment -nvidia feels the buggiest of our drivers, but that's nothing new
[18:06] <bryce> asac, bug#?
[18:06] <bryce> asac, generally we've been keeping the launchpad bug states for -intel really well up to date lately, so the lp bug status on that is probably accurate
[18:07] <asac> bryce: mdz had the same bug i think
[18:07] <asac> so i didnt file one
[18:07] <kenvandine> i thought mdz filed it
[18:07] <asac> yes he filed
[18:07] <kenvandine> i have the same problem
[18:07] <asac> thats why i didnt ;)
[18:07] <kenvandine> me too :)
[18:07] <bryce> well, we can talk more on specific bugs off-meeting, but in general it appears this latest -intel is doing quite well
[18:08] <kenvandine> ok
[18:08] <pitti> bryce: wrt, xorg-edgers, do you want to continue keeping it at the current pace? if so, shouldn't we just upload new versions to karmic directly, to get more testing?
[18:08] <rickspencer3> that's great news
[18:08] <bryce> poor mdz ;-)
[18:08] <asac> bryce: doing quite well? it locks up my laptop if i dont type for a few minutes ;)
[18:08] <asac> just kiddig
[18:08] <seb128> bug #388357
[18:08] <seb128> I think that's this one
[18:08] <kenvandine> asac, we just have to work faster :)
[18:08] <rickspencer3> asac: that was unkind ;)
[18:08] <pitti> -intel still freezes a lot for me after suspends, and DPMS off, and dpms off seems to kill it completely, but I'll follow up with that with upstream
[18:09] <bryce> pitti, yes - in fact that's what we've been doing.  We've uploaded several things from xorg-edgers the past couple weeks
[18:09] <asac> pitti: if i suspend and close the lid quickly it freezes because its the powersave thing going on
[18:09] <asac> if i wait until its suspended -> no problem
[18:09] <rickspencer3> this seems like much better shape than even the end of Jaunty, where we had hard to reproduce freezing bugs during normal use
[18:09] <bryce> asac, ah yes; that one is reported upstream and has high priority for a fix, so I'm waiting for a patch from upstream as the next step
[18:10] <asac> ok ... /me keeps powersave disabled then
[18:10] <rickspencer3> thanks for the update bryce
[18:10] <bryce> asac, they asked for newer debugging tools, which I packaged, although doesn't appear mdz has run them, so if anyone is interested in pushing that bug forward, that's something you could work on
[18:10] <bryce> but we can talk post-meeting on bugs
[18:10] <asac> k
[18:11] <rickspencer3> also, you all should see the bug report for -intel graphics that bryce is producing ... it gives quite a good overview of the current bug situation
[18:11] <bryce> rickspencer3, should I post those reports to a public location?
[18:11] <rickspencer3> bryce: wouldn't hurt, i suppose
[18:12] <bryce> maybe I'll turn it into a web page; it's getting kind of unwieldy as it is
[18:12]  * rickspencer3 nods
[18:12] <rickspencer3> put it on a cron job, and set an auto email to Yingying
[18:12] <bryce> hehe
[18:12] <bryce> well I like to do some housecleaning before sending it out.  ;-)
[18:12] <rickspencer3> perhaps some people would be interested in seeing the tools that you use to create such reports
[18:13] <bryce> anyway, that's it for X
[18:13] <bryce> sure
[18:13] <rickspencer3> thanks bryce
[18:13] <rickspencer3> ArneGoetje: translations update?
[18:13] <ArneGoetje>  * Message sharing in Rosetta is done, translations in Jaunty and Karmic are shared now.
[18:13] <ArneGoetje>  * Imports have started for Karmic.
[18:13] <ArneGoetje>  * Contacted Kubuntu developers and asked them to review the current Kubuntu related translation templates in Rosetta. Based on their feedback, the Ubuntu Translation Coordinators team needs to approve new templates, disable obsolete ones and rename templates that have been moved.
[18:13] <ArneGoetje>  * After the first round of imports is done, and Kubuntu translations are in reasonable shape we will generate initial language-packs for Karmic (hopefully next week).
[18:14] <ArneGoetje> [done]
[18:14] <rickspencer3> ArneGoetje: in general are we ahead of the curve or behind the curve in terms of translations compared to previous releases?
[18:15] <ArneGoetje> I think behind what was planned, due to message sharing development going on. But still not too late.
[18:15] <rickspencer3> ok
[18:15] <rickspencer3> thanks for the update ArneGoetje
[18:15] <ArneGoetje> np
[18:15] <rickspencer3> pitti: GDM?
[18:16] <pitti> already covered
[18:16] <pitti> was about when to upload the new one
[18:16] <rickspencer3> ok
[18:16] <pitti> I like to see that land RSN, so that DX team/themes etc. can be developed
[18:16] <kenvandine> pitti, i just saw a snag... dbusmenu will need to get uploaded too... new package
[18:16] <kenvandine> REVU, MIR, etc
[18:16] <pitti> Riddell: any progress on bug 339313?
[18:16] <pitti> this seems to be stuck somehow
[18:17] <Riddell> pitti: well the new plasmoid is in so it's working as best as it can
[18:17] <Riddell> I can ask at GCDS when is a good time to take a new snapshot and do another update
[18:17] <pitti> Riddell: is that the "ppa package which works better" you referred to?
[18:17] <pitti> i. e. is that fixed now?
[18:17] <Riddell> yes
[18:17] <pitti> cool
[18:18] <Riddell> so it works now for far more people, but still some situations where it doesn't seem to
[18:19] <rickspencer3> moving on
[18:19] <rickspencer3> looks like the burndown chart is working, please don't forget to change the status of items when they are done
[18:19] <rickspencer3> I think I may tweak it to add a "prediction line"
[18:20] <rickspencer3> next is a discussion topic: PPAs versus archives
[18:20] <asac___> (/me back ... IRC gateway failed)
[18:20] <rickspencer3> I have two, possibly invalid, concerns:
[18:21] <rickspencer3> 1. It seems that moving some things from PPAs to universe has taken longer than predicted for some components ... making me concerned that we will find ourselves very behind if we wait too long
[18:21] <seb128> urg, wrong click
[18:22] <rickspencer3> 2. It seems that with PPAs, we are all running and testing a different desktop, which seems suboptimal from a testing POV, but also means that things may appear "done" when they are in PPAs, which may be premature
[18:22] <rickspencer3> so my question is ...
[18:22] <seb128> (what was 1?)
[18:22] <rickspencer3> (10:21:16 AM) rickspencer3: 1. It seems that moving some things from PPAs to universe has taken longer than predicted for some components ... making me concerned that we will find ourselves very behind if we wait too long
[18:22] <seb128> thanks
[18:22] <rickspencer3> so my question is ....
[18:22] <asac___> i agree that we should do most stuff directly in archive
[18:22] <rickspencer3> is there product in PPAs now that should be in archives?
[18:23] <rickspencer3> thoughts?
[18:23] <asac___> with a few exceptions: transitions that will cause unnecessary breakage on developers desktops
[18:23] <seb128> dunno if there is things in ppa to move right now
[18:23] <seb128> but I've discussed recently the xorg edger ppa with pitti and I feel it's suboptimal too
[18:23] <rickspencer3> I know about GDM, FFA 3.5, and xorg-edgers
[18:23] <seb128> I'm rather in favor of snapshoting versions directly to karmic if they are candidate to land there anyway
[18:24] <pitti> well, there's two cases
[18:24] <rickspencer3> I know that FF3.5 won't be ready for the archives until alpha 4
[18:24] <asac___> yeah. ffox 3.5 (the app) itself is in archive ... its just that i do the first transition steps in ppa to provide karmic users with a more or less smooth transition
[18:24] <pitti> stuff like the new U1 packages need to stay in PPAs until they are ready for upload and reviewed in REVU
[18:24] <rickspencer3> asac: ok, great
[18:24]  * rickspencer3 directs my last comment to all three asacs
[18:24] <bryce> erf, the whole reason for doing the ppa's was due to complaints about stuff going directly into the archive without suitable testing
[18:24] <pitti> for newer versions like X.org or ffox, I agree that direct karmic uploads would be better
[18:24]  * rickspencer3 now knows hos asac gets so much done
[18:25] <seb128> bryce, I don't think we should aim at having unstable stable
[18:25] <bryce> pitti, why is this?
[18:25] <seb128> it just slow us down
[18:25] <pitti> bryce: well, it doesn't particularly matter whether the version I revert to came from a PPA or from karmic?
[18:25] <bryce> seb128, how does it slow you down?
[18:25] <seb128> it diverts testing efforts
[18:25] <pitti> (in case it breaks)
[18:25] <seb128> you get bugs about different versions
[18:25] <seb128> you have to fix issues in 2 places when there is new changes required
[18:26] <rickspencer3> I think xorg was a special case for Karmic, in a way, as there was some sensitivity regarding intel after Jaunty
[18:26] <bryce> hmm, I really don't agree, I don't see the problems you guys are describing
[18:26] <seb128> you don't see users reporting bugs about different versions?
[18:26] <seb128> and me and pitti not running the same versions and not having the same issues?
[18:26] <bryce> it is little extra effort fixing things in both places, and it saves being endlessly pinged on IRC by people having problems with the newest stuff
[18:27] <bryce> seb128, no I'm saying it's not a huge concern to me that people are reporting bugs about different versions
[18:27] <rickspencer3> also, when x breaks, it becomes rather pressing for the user, even if they are a developer, and this impacts bryce quite abit
[18:27] <seb128> people not ready for running unstable versions should stay on jaunty
[18:27] <bryce> already I get people reporting bugs with a lot of different versions, aside from PPA
[18:27] <seb128> rickspencer3, you could say the same for glib, gtk, firefox, evolution, etc
[18:28] <seb128> linux
[18:28] <seb128> libc
[18:28] <asac___> seb128: we do that
[18:28] <asac___> we have -daily ppas
[18:28] <bryce> seb128, I disagree
[18:28] <rickspencer3> seb128: could be, I don't know ... but I know that bryce spends a huge amount of time helping people troubleshoot x
[18:28] <asac___> also we do staging for -security updates ... and now the ffox 35 transition
[18:28] <bryce> seb128, there are many people who want to run karmic to be able to test some classes of software, but who do not like it when the whole system breaks from under them
[18:28] <rickspencer3> bryce: when are you planning to move all the karmic stuff into karmic archives?
[18:29] <bryce> others like having the system break from under them... so they install edgers and work with us on bugs
[18:29] <seb128> so we should have ppa for pulseaudio too to not break sound, and for linux to not break whatever etc etc etc
[18:29] <seb128> well, so we are back to my question from the other day, is edger meant to be candidate versions for karmic or crack of the day?
[18:29] <pitti> bryce: so xorg-edgers is essentially autobuilt and not tested?
[18:30] <seb128> some people told me to test upgrades there because those are candidate for karmic
[18:30] <pitti> bryce: so perhaps a compromise would be to just upload snapshots more often then?
[18:30] <seb128> I'm fine with having crack of the days ppa for hackers
[18:30] <bryce> rickspencer3, general rule is as upstream puts out their final releases we merge into ubuntu, and just keep rolling the git snapshots
[18:31] <rickspencer3> bryce: it seems that perhaps edgers has served it's purpose for Karmic, and it's time to start focusing on the archives
[18:31] <bryce> pitti, xorg-edgers is *where* the testing is done.  but yeah, stuff is not expected to be tested before it's uploaded there
[18:32] <pitti> so we are still all encouraged to have it enabled?
[18:32] <bryce> rickspencer3, but that's exactly what's going on...  this week we uploaded -fglrx, -nvidia, xorg, and mesa.  xserver is coming soon too
[18:32] <rickspencer3> bryce: ok
[18:32] <seb128> so I'm running karmic but I'm not testing what is useful and that bothers me somewhat
[18:32] <pitti> I guess for the full fun we also need to use the daily kernel images then, to get i915 updates
[18:33] <bryce> rickspencer3, we still need xorg-edgers to make it easy for people to test upstream for bug debugging purposes, which will enable us to cherrypick fixes
[18:33] <rickspencer3> I think that X was actually handled quite well given the Jaunty issues ... and I didn't mean for this to overly focus on bryce's work
[18:33] <rickspencer3> so perhaps bryce, pitti, and seb128 can discuss a mutually satisfactory course of action ... but
[18:33] <rickspencer3> are there *other* PPAs that we should be thinking of as well?
[18:33] <pitti> I'm mainly interested in when I should stop using xorg-edgers
[18:33] <seb128> not that I know about
[18:34] <bryce> pitti, alpha-3
[18:34] <pitti> I'd like to test as early as possible what will go into karmic
[18:34] <pitti> bryce: ah, thanks
[18:34] <seb128> I'm mainly interest to know why I should be adding ppas to my sources.list to be testing karmic
[18:34] <seb128> but right that's a out of meeting discussion
[18:34] <bryce> alpha-3 is where we're going to shift focus over more to stabilization, and most all the key X bits will be in place by then
[18:34] <pitti> bryce: I hope we'll also get .31 by then
[18:35] <pitti> that should help (or break :) ) a lot
[18:35] <bryce> yeah that's the other thing... a lot of the X stuff has kernel dependencies now with KMS, that's easier and safer to deal with in a PPA
[18:36] <rickspencer3> ok
[18:36] <pitti> bryce: My fingers are itching to DKMSify i915 for git head testing :)
[18:36] <pitti> but I guess we could just as well use the kernel PPA
[18:36] <rickspencer3> I think we ran a tad past the meeting time
[18:37] <rickspencer3> are there action items to take out of the PPA/archive discussion?
[18:37] <seb128> I would say "no" looking at the discussion
[18:37] <asac___> essence for meseems to be that main testing should be done in real archive and if you ask all desktop team members to enable a PPA you probably do something wrong ;)
[18:37] <pitti> for me, it was "keep xorg-edgers until alpha-3 and disable it afterwards"
[18:38] <seb128> asac____ ++
[18:38] <seb128> I think there is something wrong if people using karmic are not testing karmic ....
[18:38] <asac___> ppas make sense for me for voluntarily staging and to prepare bits that you dont want to get tested by all ;)
[18:38] <seb128> ie what is the point to run the unstable version if your feedback is about outdated versions anyway
[18:38] <rickspencer3> but so far as I can tell, with a few exceptions that is what has been happening
[18:38] <asac___> (and for non-motus for getting things reviewed)
[18:38] <pitti> I thought that was precisely what xorg-edgers is?
[18:38] <pitti> (not recommended to all karmic users)?
[18:39] <pitti> asac___: for review it's fine, *nod* (although REVU is better)
[18:39] <pitti> like, the U1 packages
[18:40] <asac___> pitti: yes. lets phrase different: ppa is good if you want to provide packages to users while its undergooing review in revu
[18:40] <asac___> ;)
[18:41] <rickspencer3> ACTION: All: run edgers until alpha 3, and then disable
[18:41] <rickspencer3> any other business?
[18:41] <asac_> yes. anyone running jaunty or any other stable release?
[18:42] <rickspencer3> asac_: I'm running Jaunty as we speak
[18:42] <asac_> if so, please enable the https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/ppa ... i always need more testers for our security bits
[18:42]  * rickspencer3 clicks
[18:42] <asac_> only bits that would go out to end users usually go there ... so its safe
[18:42]  * awe clicks
[18:42] <pitti> jaunty? wasn't that an Ubuntu release we did a million years ago? :-)
[18:42] <asac_> if you update daily and report in case suddenly firefox brakes, let me know quickly
[18:43] <asac_> otherwise no need to confirm or anything
[18:43] <bryce> pitti, I've excised it from my brain already
[18:43] <asac_> thanks!
[18:43] <pitti> thanks all
[18:43] <bryce> thanks
[18:43] <rickspencer3> ACTION: ALL install mozilla security update, report problems to asac
[18:43] <rickspencer3> bye all!
[18:43] <rickspencer3> thanks
[18:43]  * rickspencer3 taps gavel
[18:43] <asac_> thanks
[18:43] <asac_> everybody going to desktop summit: enjoy your trip!
[18:43] <seb128> thanks
[18:44] <awe> see ya
[18:44] <pitti> have fun, guys!
[18:44] <seb128> need to reboot my laptop brb
[18:44] <ArneGoetje> thanks
[18:44] <pitti> dinner o'clock, will come back later to unbreak apport retracers
[18:46] <seb128> re
[18:47] <seb128> bryce, pitti: I've nothing against having edger ppas, the things if that we start having a gtk-edger, devicekit-edger, xorg-edger, etc everybody will have a different mix of versions and nobody test karmic proper, ie what we ship to our users
[18:48] <seb128> and sometime issues come from a specific versions combination and you don't notice you break karmic because you are running some edger version not having the issue
[18:50] <bryce> seb128, I don't think you understand how fragile X can be sometimes, and how badly it can break from just updating a driver to a git snapshot
[18:51] <bryce> and when it does break, I get people coming out of the woodwork bugging me about the problem... it gets overwhelming very quickly
[18:51] <seb128> hum, not sure how I should take that
[18:51] <seb128> you think I don't understand what sort of breakages we can have and the implications?
[18:51] <seb128> I didn't say to upload random git crack to karmic
[18:51] <bryce> from my perspective doing the extremely unstable stuff in PPAs helps, since only those who are good at reporting problems test it, and can give good feedback (and shut it off if the issues are too bad)
[18:52] <bryce> xorg-edgers == random git crack
[18:52] <seb128> well I don't get why I'm being asked to run xorg-edger until alpha3 then
[18:52] <seb128> I don't want to run git crack, I want to give feedback on karmic
[18:53] <seb128> I'm fine with ppa having crack of the day as firefox has
[18:53] <seb128> and usually we ask users to try thing there to confirm a specific bug has been fixed
[18:53] <seb128> but I don't think we should encourage all the team members to run edger
[18:55] <bryce> seb128, I'd agree
[18:56] <seb128> bryce, ok, good, I think we have the same opinion
[18:56] <seb128> I just had the impression that we were encouraged to all run edger
[18:56] <bryce> I was surprised to see rickspencer3 set it as a task for everyone; I would rather that people only run xorg-edgers if they are okay with spending the time to report bugs and deal with issues that might crop up
[18:56] <seb128> it might just be me who misunderstood though
[18:56] <rickspencer3> I can remove that for sure
[18:56] <rickspencer3> I guess it should be for people who want to
[18:56] <seb128> but pitti has been advertising it too
[18:56] <bryce> rickspencer3, thanks yes
[18:56] <rickspencer3> seb128: no the action item said All
[18:57] <rickspencer3> but it should have said "consider running" or "if you are running", etc...
[18:57] <seb128> as said before I think edger ppa should be for people interested by debugging crack of the day for the said component
[18:57] <seb128> ie I would not recommend everybody to run daily gtk snapshots there, most people don't care about doing the upstream job for gtk
[18:58] <seb128> anyway seems we are on agreement on that, only people interested run edger versions and all is fine ... time for diner ;-)
[18:59] <bryce> violent agreement again apparently ;-)
[19:00] <mclasen_> seb128: running daily gtk snapshots is entirely harmless...
[19:01] <mclasen_> compared to X
[19:04] <bryce> if some of this is coming from the emails I sent out last week to test fglrx and nvidia, both of which were being staged in xorg-edgers at the time, note that both got uploaded to karmic the next day, once we had a few positive test cases.  And the -intel I asked people to test already was in karmic.
[19:05] <bryce> the main reason I asked fglrx and nvidia users to test xorg-edgers was since a lot of them were on jaunty, and there really isn't a way to give them newer drivers aside from ppas
[19:13] <rickspencer3> seb128: kenvandine: I presume that FUSA will be broken now that I am on gdm-new?
[19:14]  * rickspencer3 logs out
[19:14] <kenvandine> yes
[19:17] <dobey> hrmm, i think i might need some help with the ubuntuone-client packaging
[19:17] <dobey> and pitti is probably gone for the day
[19:19] <kalon33> kenvandine, about new gdm, do you have an idea of when fusa will be patched to correct it's broken state ? Or will gnome-panel be unpatched to provide logout facilities until then ?
[19:20] <kenvandine> kalon33, end of the week
[19:20] <kenvandine> well the code will be ready
[19:20] <kenvandine> probably updated to karmic next week
[19:20] <kenvandine> rickspencer3, but you should be using gdm not gdm-new
[19:21] <kalon33> kenvandine, so new GDM will land at the same time in karmic or the fix will be in desktop-team PPA ?
[19:21] <kenvandine> same time
[19:21] <kenvandine> the goal is to land them both in karmic together
[19:23] <kalon33> without a transition period (for instance between the moment when the code will be ready and the next week) ?
[19:23] <kalon33> in a ppa ?
[19:25] <kenvandine> undetermined as of now
[19:26] <kalon33> kenvandine, thanks for your answers, will test new GDM now, as I can switch off manually ;)
[19:27] <kenvandine> cool
[19:27] <kenvandine> thx
[19:28] <dobey> kenvandine: are you knowledgeable enough to help me with the packaging? :)
[19:28] <kenvandine> should be
[19:28] <kenvandine> what do you need?
[19:28] <dobey> dealing with http://revu.ubuntuwire.com/p/ubuntuone-client
[19:29] <dobey> trying to figure out hwo to do the split exactly
[19:29]  * kenvandine looks
[19:30] <kalon33> kenvandine, you're welcome, I know testing is quite important, and as I have the sufficient knowledge... have a nice evening :)
[19:30] <kenvandine> dobey, so where are the package sources?
[19:30] <dobey> kenvandine: the tarball?
[19:31] <kenvandine> no, the packaging
[19:35] <dobey> kenvandine: lp:~dobey/ubuntu/karmic/ubuntuone-client/karmic
[19:35] <kenvandine> thx
[19:37] <seb128> re
[19:38] <seb128> mclasen_, yeah maybe gtk was not a good example, I was just picking a library used by quite some application, ie if gtk has a crasher commit quite some users would notice
[19:44] <dobey> kenvandine: mostly, i'm not sure where some separation should be, as most all of the code depends on gnomekeyring python bindings, whicn unfortunately pulls in most of gnome due to the way it's packaged
[19:45] <kenvandine> well for the "not depending on gnome" case that is hard... but we can surely split out the python stuff into python-ubuntuone-client
[19:45] <kenvandine> the python library that is
[19:46] <kenvandine> dobey, give me a few
[19:47] <dobey> kenvandine: right, though i'm not entirely sure what belongs there either, since ubuntuone.u1sync is just for u1sync to use (which I think should be a separate package), and the syncdaemon stuff is almost entirely just code only the syncdaemon itself should be using
[19:48] <dobey> ie, a python-ubuntuone-client doesn't really make sense to me
[19:49] <kenvandine> hang on... my box is hanging here.. it does that when writing a usb image
[19:49] <dobey> heh
[20:40] <hggdh> seb128, I will email you a sample of the evolution apport hook working (it will have real data)
[20:41] <seb128> hggdh, can't you have a simple testsuite example, ie the function called on an IP and comparing the result to a known result?
[20:42] <hggdh> seb128, yes, will do, then
[20:42] <seb128> thanks
[20:44] <seb128> walters, hey
[20:44] <seb128> walters, I'm having a look to the gobject-introspection 0.6.1 to 0.6.3 update
[20:45] <seb128> walters, there is a new libgirepository-everything-1.0.so, do you recommend splitting that as a new library?
[20:45] <seb128> I'm not sure what it's used for exactly
[20:52] <pitti> dobey: I'm back for some minutes
[20:53] <dobey> pitti: hey, kenvandine is helping me
[20:53] <pitti> ah, great
[20:53] <dobey> pitti: you might be able better answer my conffiles question though
[20:54] <dobey> pitti: does debhelper just automatically make anything in /etc a conffile now or something?
[20:54] <pitti> dobey: it has done that forever already
[20:54] <seb128> not now that has always been the case
[20:54] <pitti> usually you never need to write a debian/conffiles
[20:54] <dobey> eww
[20:54] <dobey> so it makes /etc/xdg/autostart files be conffiles?
[20:55] <seb128> yes
[20:55] <pitti> right
[20:55] <dobey> :(
[20:55] <pitti> dobey: do they need to be? can't we ship them in /usr/share?
[20:55] <seb128> cf xdg and d-d-l emails from Josselin about using usr
[20:55] <dobey> seb128: yes, that's only ONE example though
[20:55] <pitti> /usr/share/gnome/autostart/ has some stuff
[20:55] <seb128> we shipped those in etc for a reason, to let sysadmin change those easily to not start
[20:55] <dobey> but /usr/share/gnome/autostart is wrong (it's not an xdg place)
[20:56] <pitti> gnome-session-splash, libcanberra-login, and polkit-gnome-auth use it
[20:56] <pitti> but *shrug*, I don't particularly care
[20:56] <dobey> but regardless, there's lots of stuff in /etc/ which shouldn't be considered conf files
[20:56] <pitti> I usually use whatever upstream does
[20:56] <seb128> gnome-session read files in both locations
[20:56] <pitti> dobey: *nod*
[20:56] <dobey> yes, gnome-session does i'm sure
[20:57] <dobey> but i don't want to argue about the location of autostart files. i was just making an example
[20:58] <seb128> what is the issue?
[21:00] <walters> seb128: well i'm unhappy about its existence =/  but basically i'd just ship it with the main package
[21:00] <walters> seb128: it's a library of test functions that bindings can use, basically BuildRequiresTests if you know what i mean
[21:01] <seb128> I don't know about BuildRequiresTests but I'm fine shipping that in gobject-introspection
[21:01] <seb128> thanks
[21:02] <seb128> walters, btw do you follow gnome-shell too?
[21:02] <walters> seb128: yeah
[21:03] <walters> seb128: the main thing to do for that is get introspection support in gtk and pango, and then we don't need to depend on gir-repository
[21:03] <seb128> walters, apparently Clutter-0.9.gir is required to build mutter, do you know where than can be find, current gir-repository use 0.8
[21:03] <walters> seb128: clutter needs to be built with introspection for 0.9
[21:04] <walters> that's where we're tryign to get to, where the libraries themselves build introspection data
[21:04] <seb128> so the gir is in clutter proper and not gir-repository?
[21:04] <walters> yeah
[21:04] <walters> gir-repository is the old way, it's like a dependency inversion black hole
[21:04] <seb128> yeah, that makes sense, we had discussion about that at UDS
[21:05] <didrocks> FYI, I have a similar discussion with owen on #gnome-shell right now :)
[21:05] <seb128> I will join #gnome-shell I think
[21:13]  * hyperair yawns. nautilus-share porting to gtkbuilder complete =D
[21:20] <seb128> hyperair, good job!
[21:20] <hyperair> seb128: thanks =)
[21:21] <hyperair> it would have been completed faster if gtkbuilder didn't insist on creating the dummy parent window when the ui is loaded
[21:21] <hyperair> oh well
[21:21] <seb128> asac: do you plan to move libmozjs to a system path this cycle?
[21:26] <seb128_> re
[21:26] <seb128_> dsl disconnected
[21:26] <seb128_> I was saying
[21:26] <seb128_> asac: do you plan to move libmozjs to a system path this cycle?
[21:26] <seb128_> hyperair, what did you do about the weird script to do changes in the .glade?
[21:26] <seb128_>  I had a quick look yesterday and that + all the debian patche stopped me and I decided to work on nautilus-sendto rather
[21:26] <seb128_>  walters, btw do you have an opinion about gjs packaging too? ;-)
[21:26] <seb128_>  walters, would you split libgjs.so and libgjs-gi.so in proper libraries? and where should go /usr/lib/gjs-1.0/*.so if we do things this way?
[21:26] <seb128_>  lool, pitti, can you bump the gdm build score?
[21:27] <hyperair> seb128_: unhooked it from the build system.
[21:27] <pitti> seb128_, lool: doing
[21:27] <seb128_> hyperair, ok makes sense I think
[21:27] <hyperair> seb128_: it's not needed since the introductino of the system icon patch
[21:27] <hyperair> seb128_: the fix.pl was meant to mangle the pathnames of the custom icons. i tossed those away, heheh =p
[21:27] <hyperair> folder-remote looks very much better than those ugly icons it shipped with
[21:27] <seb128_> pitti, thanks, the xorg managed to break gdm and didn't notice until people start complaining so having it fixed quickly would be appreciated ;-)
[21:27] <pitti> seb128_: done, but still clogged
[21:27] <pitti> right, I saw
[21:28] <pitti> eww, doesn't help
[21:28] <pitti> https://edge.launchpad.net/builders
[21:28] <seb128_> xorg +guys
[21:28] <pitti> they are all down
[21:28] <seb128_> great
[21:28] <seb128_> why do that always happen when you need a quick build?
[21:29] <pitti> see #u-devel
[21:30] <seb128_> thanks
[21:31] <pitti> seb128_: does that affect gdm-new as well?
[21:32] <seb128_> pitti, I didn't check yet but I doubt it
[21:32] <pitti> cool
[21:33] <pitti> ok, seems my patch to unbreak apport retracers works
[21:34] <seb128_> pitti, in fact new gdm has the issue too ...
[21:34] <seb128_> pitti, basically easy to fix, just change the xserver path in gdm.conf to /usr/bin/X
[21:34] <seb128_> pitti, it's still /usr/X11R6/bin/X
[21:35] <pitti> just to know what to do when I boot my machine tomorrow morning :)
[21:42] <chrisccoulson> seb128_ - i just noticed that bug 282403 still has an open intrepid task whilst going through some of my work for my MOTU application. i think it should be closed as WONTFIX for intrepid. do you agree?
[21:42] <seb128_> chrisccoulson, seems correct
[21:42] <chrisccoulson> thanks, i'll close that one
[21:50]  * hyperair wonders where bdefreese disappeared to =\
[22:16] <pitti> seb128: ah, is that StandardXServer=/usr/X11R6/bin/X ?
[22:16] <seb128> pitti, yes
[22:16]  * pitti locally changes to /usr/bin/X
[22:17] <pitti> merci
[22:17] <seb128> de rien!
[22:17] <pitti> seb128: so, I hope the retracers will survive a bit
[22:17] <seb128> pitti, they are running now?
[22:17] <seb128> I've been too busy to look at those recently
[22:18] <seb128> or too lazy ;-)
[22:18] <pitti> seb128: the i386 survived for about 10 retracers
[22:18] <pitti> I'm currently rolling out the new versions from apport-retracer PPA
[22:18] <seb128> good start
[22:18] <pitti> then I'll restart
[22:18] <lool> seb128: I can't bump build scores I'm afraid
[22:18] <pitti> seb128: it just stoppped because the chroot changed underneath it, not because of an actual bug
[22:19] <seb128> lool, ok, I was not sure if you were buildd admin
[22:19]  * pitti sees seb128's new gdm upload and cranks up build score
[22:20] <seb128> pitti, danke
[22:20] <seb128> lool, the buildds didn't like your debian workaround, ie the xserver-xorg build-depends
[22:21] <pitti> seb128: 0ubuntu4 put down to 0 again, so that they don't build in vain
[22:21] <pitti> but now we can just twiddle thumbs until the security builds finish
[22:21] <seb128> pitti, thanks
[22:21] <pitti> I'm sure it's openoffice and linux
[22:22] <seb128> pitti, linux only according to what kees said
[22:22] <seb128> ;-)
[22:24] <pitti> seb128: guess what builds it first -- armel and lpia..
[22:24] <pitti> go mobile!
[22:25] <kalon33> ;)
[22:25] <seb128> pitti, yeah, armel is where I read the ftfbs error before
[22:29] <seb128> pitti, and the winner is, lpia!
[22:29] <kalon33> ;)
[22:29] <seb128> "X server : /usr/bin/X"
[22:29] <seb128> good, it worked
[22:29] <pitti> \o/
[22:29] <pitti> seb128: yeah, it usually is
[22:29] <pitti> lpia is blazingly fast for some reason
[22:29] <pitti> $ rm */lock
[22:29] <pitti> there, retracers should be alive again
[22:30]  * pitti knocks on wood
[22:30] <seb128> rock on
[22:30] <lool> Wow it was months if not years I touched this
[22:30] <kalon33> seb128, Sorry, I didn't checked yet, is this bug occurs with new GDM (from desktop-team PPA) ?
[22:31] <seb128> lool, well, ubuntu just got the xserver change which dropped the X11R6 compatibility thing
[22:31] <pitti> kalon33: yes, same problem
[22:31] <seb128> lool, and they didn't test if gdm was broken before uploading ...
[22:31] <pitti> kalon33: just edit /etc/gdm/gdm.conf and fix the path
[22:31] <lool> Eh
[22:31] <pitti> kalon33: StandardXServer=/usr/bin/X
[22:32] <seb128> or wait for the update
[22:32] <seb128> I updated both karmic and ppa
[22:32] <lool> I should have implemented that autoconf option, but it was old gdm and I knew it wouldn't go upstream; I guess this stayed for new gdm
[22:32] <seb128> lool, right, I used the easy way I changed the fallback case in the configure
[22:33] <kalon33> thanks both pitti and seb128 ;)
[22:33] <seb128> lool, ie it fallback to /usr/bin/X now
[22:35] <seb128> hum, bug #104957
[22:36] <lool> Oh funny I tried that today
[22:36] <pitti> feature!
[22:37] <lool> I ran passwd -d on an user and I could login on a tty but not on gdm
[22:37] <seb128> http://launchpadlibrarian.net/28548736/gdm_2.20.10-0ubuntu4.debdiff
[22:37] <lool> I saw that the PAM setup is different, I checked securetty, but didn't know how to set it up
[22:37] <seb128> the user suggests adding a nopassword group to the system for that
[22:37] <lool> Eek
[22:37] <seb128> I'm waiting for pitti or $security to comment
[22:38] <pitti> well, frankly, it should just work
[22:38] <pitti> you can log into ttys, etc.
[22:38] <pitti> passwd and user-setup should just plainly refuse to have no password
[22:38] <pitti> because that is a nightmare
[22:38] <pitti> autologin is okay
[22:38] <pitti> but open accounts, possibly on computers with ssh enabled, are a pain
[22:40] <seb128> that probably still doesn't solve the gnome-keyring issue either
[22:41] <lool> I think the tty needs to be in securetty
[22:42] <lool> And gdm is probably using an odd tty
[22:42] <lool> Perhaps redirecting stdin/stdout for instance
[22:46] <dobey> yay
[22:46] <dobey> i hope i don't have to make any more changes to the packaging for a while
[22:54] <pitti> dobey: reviewing storage-protocol ATM
[22:54] <pitti> thanks for fixing
[22:58] <pitti> dobey: uploaded
[22:58] <pitti> dobey: waiting for the -client now
[22:58] <pitti> sleep o'clock, see you tomorrow!
[22:58] <pitti> kenvandine: ^ FYI
[23:02] <kalon33> pitti, good night
[23:16] <chrisccoulson> hmmmm, "what I like least in Ubuntu"
[23:16] <chrisccoulson> not sure how to answer that :-/
[23:25] <seb128> chrisccoulson, ignore it?
[23:25] <chrisccoulson> i was just thinking that
[23:25] <chrisccoulson> thats the only thing i've got left to answer now ;)
[23:26] <seb128> not bad
[23:27] <seb128> enough work there, night everybody
[23:27] <chrisccoulson> good night