[12:15] <Riddell> Mithrandir: how do we go about asking for permission to upload a new upstream version these days?
[12:15] <Riddell> (into main)
[12:19] <Hobbsee> :)
[06:05] <superm1> could someone point out at what point during the livecd bootup, the ubuiqity .desktop file is copied to the live cd user's desktop?  I was making a custom disk and wanted to copy something else too
[08:05] <dholbach> good morning
[08:06] <_ion> Hi dholbach
[08:06] <dholbach> hi _ion
[08:06] <ajmitch> hey dholbach 
[08:07] <dholbach> hey ajmitch
[08:18] <dholbach> should the NEW queue be accessible from  http://launchpad.net/ubuntu/+builds ?
[08:31] <pitti> Good morning
[08:32] <dholbach> :-)))
[09:56] <cjwatson> dholbach: try /ubuntu/feisty/+queue
[10:12] <dholbach> cjwatson: found it in the meantime - thanks again
[10:19] <Mithrandir> Riddell: uvf exceptions> ask me, either by email or IRC (until we have the new process working)
[10:45] <Nafallo> where we supposed to upload a new wtf (bsdgames) if we stumble upon an unknown acronym? :-)
[10:53] <cjwatson> Nafallo: the Debian maintainer always mails the upstream author first
[10:53] <cjwatson> see the address in the package; it's easy to find
[10:53] <Nafallo> okidoki :-)
[10:54] <ailean> is anything happening to get rid of the ugly fade outs when asked for admin password, or the ugly terminal transparency?
[10:56] <Nafallo> sent :-)
[11:14] <Treenaks> argh.. my screensaver is misbehaving again
[11:14] <Lathiat> ailean: having real compositing on the desktop would go along way to sorting that sortof stuff out
[11:15] <Lathiat> and im not talking about cubes or burning windows, or burning cubes ;)
[11:15] <ailean> Lathiat, lol, i know what you mean :)
[11:15] <Treenaks> did the gdm socket move _again_?
[11:15] <Mithrandir> Treenaks: yes.
[11:16] <Treenaks> *sigh*
[11:16] <seb128> Treenaks: I've used a Breaks on packages using the socket and updated them
[11:16] <Treenaks> seb128: I think I don't log out often enough :)
[11:16] <seb128> Treenaks: that doesn't make real sense, the gdm socket will not change until you restart it and if you restart gdm you restart gnome-screensaver
[11:16] <seb128> Treenaks: if you don't restart the app no reason for the socket to change
[11:17] <Treenaks> seb128: sometimes Gnome apps just die while I'm upgrading..
[11:17] <Treenaks> seb128: mostly the panel.. but maybe gnome-screensaver too
[11:17] <seb128> basically you restart gnome-screensaver during your session then?
[11:17] <seb128> that's a feisty upgrade problem though
[11:18] <Treenaks> yeah.. I know.. I shouldn't complain :)
[11:18] <seb128> I made the apps looks to /tmp/.gdm_socket first and then /var/run/gdm_socket
[11:18] <seb128> so it would work fine with app restarting if you upgraded from edgy
[11:18] <seb128> I just didn't add a case for the /var/run/.gdm_socket which has been used for a week only
[11:18] <Treenaks> I have /var/run/.gdm_socket
[11:18] <Treenaks> ah!
[11:18] <seb128> what I just wrote :p
[11:19] <Treenaks> seb128: ok.. I need to logout/login (and probably reboot too; new l-r-m)
[11:51] <Riddell> mvo: I completed my first successful upgrade from edgy to feisty with kubuntu upgrade manager, everything works great
[11:51] <doko> pitti, seb128, Mithrandir: although it's no archive day, please process the new sip4-qt3 binaries
[11:51] <pitti> doko: will do in a minute
[11:51] <seb128> doko: looking at it
[11:52] <Riddell> doko: what's changed in that?
[11:52] <seb128> ok, pitti was faster ;)
[11:53] <doko> Riddell: -dbg packages, you may want to check them ...
[11:53] <Riddell> pitti: I added a cleaner patch to kdelibs for the dist-upgrade SRU
[11:54] <pitti> yay
[11:55] <pitti> doko: while I'm at it, I can as well do the python-gnome* stuff, too
[11:56] <mvo_> Riddell: rock!
[11:57] <doko> pitti: please do
[11:57] <Riddell> mvo_: you can ignore the e-mail I sent you about an error, fixed by changing the working directory
[12:06] <Riddell> pitti: what's the current hwdb plan?
[12:06] <pitti> Riddell: wrt what?
[12:07] <Riddell> pitti: removing menu entry and replacing with something?
[12:07] <pitti> Riddell: ah, it doesn't have a menu entry any more; instead, we now have a postinstall notification
[12:07] <pitti> Riddell: see the spec
[12:07] <pitti> Riddell: does adept-notifier support these notifications as well?
[12:08] <Riddell> pitti: no
[12:09] <pitti> Riddell: so we should either teach it to, or add a KDE .desktop file to hwdb-client-kde?
[12:10] <Riddell> pitti: did you remove the KDE .desktop file?
[12:10] <pitti> Riddell: I didn't remove any file, I just changed back and forth the 'NoDisplay' value
[12:10] <pitti> Riddell: i. e. the net effect is zero compared to edgy
[12:11] <pitti> 'k, binary NEW is empty again
[12:12] <Riddell> pitti: I think adding popups to adept-notifier is sufficiently difficult it needs to be spec'ed, I'd rather keep a menu item for feisty and have popups in feisty+1
[12:13] <pitti> right
[12:19] <Riddell> pitti: oh, what's the use case for the Report a problem menu entry?
[12:22] <ogra> Riddell, thats LPI
[12:22] <ogra> malone iirc
[12:23] <Riddell> Linux Professional Institute?
[12:23] <cjwatson> launchpad-integration
[12:24] <pitti> Riddell: it collects some info about the package and running process and files a launchpad bug
[12:24] <pitti> Riddell: i. e. like source/+filebug with additional apport data love
[12:25] <Riddell> pitti: it's in the k-menu, how does it know what process you care about?
[12:25] <pitti> Riddell: you mean in a particular applications' menu, or the general KDE panel?
[12:26] <Riddell> pitti: in the general KDE applications menu
[12:26] <Riddell> on the panel
[12:26] <pitti> Riddell: ah, right; this will file a general distro bug
[12:26] <pitti> we weren't so sure about that one
[12:26] <Riddell> where does it appear in Gnome?
[12:26] <pitti> whether it would ask for a package or not (spec doesn't say so ATM), or whether to display it at all
[12:27] <pitti> Riddell: similar place, 'System -> Report a bug'
[12:29] <Riddell> pitti: ah, system menu makes more sense than top level apps menu, mind if I change s/Core/System/ in the KDE .desktop file?
[12:30] <pitti> Riddell: of course not; can you commit it to the official bzr branch?
[12:30] <pitti> Riddell: sftp://bazaar.launchpad.net/~ubuntu-core-dev/apport/ubuntu
[12:30] <Riddell> yes
[12:35] <doko> Mithrandir: please requeue psycopg for all archs
[12:35] <Mithrandir> doko: please file a bug about it.
[12:36] <doko> Mithrandir: bug reports for requeues?
[12:37] <doko> Mithrandir: and assign/subscribe who?
[12:37] <Mithrandir> doko: sorry, I read "remove", not requeue.
[12:37] <doko> :)
[12:38] <Mithrandir> doko: given-back
[12:44] <Keybuk> http://rafb.net/p/PEW7W882.html
[12:45] <Hobbsee> tepsipakki: which source package did my upload change?  do you remember off hand?
[12:46] <StevenK> I need to confirm if having the evms.conf file in the initramfs ignore hd? fixed the problem.
[12:47] <tepsipakki> Hobbsee: the xserver dying thingy?
[12:47] <Hobbsee> tepsipakki: yep
[12:47] <tepsipakki> Hobbsee: I think it was this https://lists.ubuntu.com/archives/feisty-changes/2007-February/005133.html
[12:48] <Hobbsee> bug #60288
[12:48] <Ubugtu> Malone bug 60288 in xorg-server "xorg segfaults in FontFileCompleteXLFD" [Medium,In progress]  https://launchpad.net/bugs/60288
[12:49] <tepsipakki> it applies to 1.2 as well, and I have included it
[12:49] <Hobbsee> tepsipakki: 1.2?  that's the version you published?
[12:49] <tepsipakki> yes
[12:50] <Hobbsee> tepsipakki: when did that get published?
[12:50] <tepsipakki> oh, it's not yet in feisty
[12:50] <Hobbsee> right
[12:51] <tepsipakki> do you have ati?
[12:52] <Hobbsee> nope - intel 965 card.
[12:52] <tepsipakki> ok.. maybe it'll be better with 1.2
[12:52] <tepsipakki> +mesa
[12:52] <Keybuk> doko: ping
[12:53] <Hobbsee> will see if it's reproducable - this is the first hardlock i've had since that patch was put in.
[12:53] <tepsipakki> err, mesa 6.5.2
[12:53] <Hobbsee> tepsipakki: yes, hopefully.
[12:53] <doko> Keybuk: pong
[12:54] <Hobbsee> tepsipakki: current ETA is...?
[12:54] <Keybuk> doko: trying to track down whether that is a gcc bug or not
[12:54] <Keybuk> don't suppose you know of any upstream pointers (heh) on it?
[12:55] <doko> which one?
[12:55] <Keybuk> http://rafb.net/p/PEW7W882.html
[12:55] <Keybuk> I think I should be able to pass a char ** to a function that expects a const char * const *
[12:55] <Keybuk> since that is only adding const to the type
[12:57] <doko> hmm, no, make it a const char **a = 0 ?
[12:57] <Keybuk> that would defeat the object
[12:57] <Keybuk> the intent is to declare that function in such a way that it says it does not modify the array, nor the strings the array points to
[12:57] <Keybuk> (just as you'd declare one with const char * and pass in char * to indicate it doesn't modify the string)
[12:58] <Keybuk> I think gcc is misinterpreting the C standard which says that const <array>s and <array>s aren't equivalent
[12:58] <Keybuk> but I'm only dealing with pointers there
[12:58] <Keybuk> a pointer and a const pointer should be equivalent
[12:59] <tepsipakki> Hobbsee: I'm now merging xorg, and if I can get it ready today all of the remaining bits can go in, provided that they are reviewed first
[12:59] <Hobbsee> tepsipakki: yay :)
[01:00] <tepsipakki> xorg-server can't go in before xorg since it might not work without editing xorg.conf
[01:00] <tepsipakki> manually
[01:00] <tepsipakki> mesa and xft could go now, I guess
[01:00] <tepsipakki> but back to #ubuntu-x :)
[01:01] <doko> Keybuk: hmm, I'm sure the current behaviour is intended; I'll try to track down a pointer, IIRC there was at least on discussion on gcc-help
[01:02] <Keybuk> doko: the only reference I can find is for passing char ** into a function that accepts const char *[] , which is very definitely invalid :p
[01:02] <doko> Keybuk: what does gcc-snapshot say?
[01:02] <Keybuk> but it should be, afaik, possible to pass a char ** into a function that accepts const char * const *, since that's just adding a couple of levels of const
[01:06] <cjwatson> Keybuk: I'm pretty sure I recall the C standard forbidding that
[01:06] <cjwatson> I'll try to dig up the reference
[01:08] <carlos> dholbach: hi, around?
[01:08] <cjwatson> Keybuk: C99 6.3.2.3 says "For any qualifier q, a pointer to a non-q-qualified type may be converted to a pointer to
[01:08] <cjwatson> the q-qualified version of the type; the values stored in the original and converted pointers
[01:08] <cjwatson> shall compare equal.
[01:08] <cjwatson> "
[01:08] <cjwatson> Keybuk: which allows char ** to be converted to const char **
[01:09] <Keybuk> right
[01:09] <Keybuk> it also allows char ** to be converted to char * const *
[01:09] <cjwatson> but I'm pretty sure you aren't allowed both levels
[01:09] <cjwatson> ah
[01:09] <cjwatson> ok, it allows char ** to be converted to char * const *
[01:09] <cjwatson> but not to const char **
[01:09] <cjwatson> it only talks about one level of indirection
[01:10] <cjwatson> in fact this is a C FAQ
[01:10] <Keybuk> I couldn't find it in the FAQ
[01:10] <cjwatson> one sec
[01:10] <cjwatson> Keybuk: http://c-faq.com/ansi/constmismatch.html
[01:11] <cjwatson> gcc is correct
[01:11] <Keybuk>  6.2.5.25 says Any type so far mentioned is an unqualified type.  Each unqualified type has several qualified versions of its type, corresponding to the combinations of one, two, or all three of the const, volatile and restrict qualifiers.  The qualified or qualified version of a type are distinct types that belong to the same type category and have the same representation and alignment requirements.  A derived type is not qualified by the qual
[01:11] <Keybuk> ifiers (if any) of the type from which it is derived.
[01:12] <Keybuk> so char ** is an unqualified pointer to pointer to char
[01:12] <cjwatson> the FAQ explains why it is disallowed
[01:13] <Keybuk> and char * const * would be qualified
[01:13] <cjwatson> yes, and you can convert an unqualified pointer to pointer to char into a const-qualified pointer to pointer to char, but not into a pointer to const-qualified pointer to char
[01:13] <Keybuk> right
[01:13] <Keybuk> const char ** is a pointer to const-qualified pointer to char
[01:14] <cjwatson> it's easier to understand given an example such as that in the FAQ, IMO
[01:14] <Keybuk> right, but the standard only forbids that
[01:14] <Keybuk> I don't see how the standard forbids const-qualified pointer to const-qualified pointer to char
[01:15] <cjwatson> "(C++ has more complicated rules for assigning const-qualified pointers which let you make more kinds of assignments without incurring warnings, but still protect against inadvertent attempts to modify const values. C++ would still not allow assigning a char ** to a const char **, but it would let you get away with assigning a char ** to a const char * const *.)"
[01:15] <cjwatson> I think your complaint is with the C standard, not with gcc
[01:16] <Keybuk> yeah
[01:16] <Keybuk> I think it's one of those situations where you have to read the standard in a "what does it say? AND WHAT DOESN'T IT SAY?" kind of way
[01:17] <Keybuk>  6.3.2.3 does say they're equivalent, but doesn't say the equivalents recurses 
[01:17] <Keybuk> so that implies that they don't recurse, I guess
[01:17] <Keybuk> so you can only add const at the top-most level
[01:17] <cjwatson> it's talking about convertibility, not equivalence
[01:17] <Keybuk> err, yes
[01:17] <cjwatson> and 6.3.2.3 is a complete specification of what you're allowed to convert
[01:17] <cjwatson> so indeed, if it doesn't say it recurses, it doesn't :)
[01:19] <Keybuk> (why the rationale is at the front of the book, I have no idea <g>)
[01:20] <Treenaks> Keybuk: otherwise, people would stop reading it too soon ;)
[01:22] <Keybuk> nope, typically not mentioned there
[01:22] <Keybuk> cjwatson: thanks for the reference :p
[01:24] <Keybuk> (not for the first time, I wonder why the standard permits "const void *" :p
[01:24] <Keybuk> it should fail with "nonsense type")
[01:28] <Keybuk> gnome-screensaver has failed locked again
[01:29] <pitti> Keybuk: nooo, then he can't fix it
[01:35] <seb128> Keybuk: the gdm socket changed, you might need to restart gdm if you restart gnome-screensaver
[01:35] <Treenaks> seb128: I just symlinked it to the right place :)
[01:35] <Treenaks> seb128: works too
[01:36] <Treenaks> (as an emergency solution)
[01:47] <ogra> seb128, since its /var/run which gets wiped on reboot, why not adding a symlink to the postinst ?
[01:47] <seb128> ogra: symlink to what?
[01:47] <ogra> its not beautiful, but would solve it
[01:47] <seb128> solve what?
[01:47] <ogra> .gdm_socket to gdm_socket
 I made the apps looks to /tmp/.gdm_socket first and then /var/run/gdm_socket
[01:47] <Treenaks> seb128: a symlink from the real socket location to the expected socket location
[01:47] <seb128>  so it would work fine with app restarting if you upgraded from edgy
[01:47] <seb128>  I just didn't add a case for the /var/run/.gdm_socket which has been used for a week only
[01:48] <ogra> Keybuks problem, which might show up for more pwople
[01:48] <seb128> it only happens for people who run feisty daily
[01:48] <ogra> right
[01:48] <seb128> and who restarted apps without restarting gdm
[01:48] <ogra> but for these you could solve it with a symlink
[01:48] <seb128> people running feisty can restart gdm once
[01:48] <seb128> feel free to do it
[01:48] <ogra> well, indeed
[01:48] <seb128> I think that's a waste of effort now
[01:49] <seb128> most of people probably already updated
[01:49] <ogra> hopefully
[01:51] <seb128> bah
[01:51] <seb128> tepsipakki: pitti removed libpthread-stubs
[01:51] <seb128> from the archive
[01:51] <seb128> libxcb can wait for a long time on it :p
[01:51] <ogra> bad pitti
[01:51] <ogra> :)
[01:52] <seb128> yeah, blocking xorg 7.2 :p
[01:52] <Mithrandir> uh, why on earth did he do that?
[01:52] <seb128> looking at why libxcb Build-Depends on it
[01:52] <Mithrandir> I approved it like a week ago.
[01:52] <seb128> "'(pitti) only produces empty binaries, synced from Debian/experimental, useless'"
[01:53] <seb128> indeed the .deb are empty
[01:53] <seb128> the ones from Debian experimental
[01:54] <Mithrandir> yes, which is why it's -stubs.
[01:54] <seb128> ah, the -dev has a .pc
[01:54] <seb128> ok, let's sync it again
[01:54] <Mithrandir> hm, can we just do that?
[01:54] <seb128> can we sync a version which has already been available and removed?
[01:54] <Keybuk> seb128: wouldn't it also affect people who installed Herd 4 and upgrade ?
[01:55] <seb128> Keybuk: it does
[01:55] <Keybuk> (this was an upgrade from Herd 4 gnome-screensaver to today's)
[01:55] <Keybuk> right
[01:55] <pitti> hm, I didn't find anything in those debs, and I wasn't sure where they came from
[01:55] <Keybuk> so it's more serious than "just affects people running daily"
[01:55] <Keybuk> so needs to be fixed
[01:55] <seb128> Keybuk: if you restart gnome-screensaver without restarting gdm
[01:55] <Keybuk> does gnome-screensaver's postinst restart gnome-screensaver?
[01:55] <seb128> Keybuk: well, the socket doesn't change if you don't restart the app
[01:55] <Keybuk> so why didn't it unlock?
[01:55] <seb128> I don't think so
[01:55] <Mithrandir> seb128: can you please just upload a 2build1?  I'd rather be cautious than risk breaking something fun in soyuz.
[01:55] <Keybuk> I had Herd 4 installed
[01:55] <Keybuk> I upgraded today
[01:55] <seb128> it would unlock people dist-upgrading while they are away
[01:55] <Keybuk> gnome-screensaver locked during the upgrade
[01:56] <Keybuk> and then wouldn't unlock, and just stuck at "Checking..." eating 100% CPU
[01:56] <seb128> Keybuk: maybe gnome-screensaver crashed or something?
[01:56] <seb128> there is no reason for the socket to change if the program doesn't restart
[01:56] <seb128> Mithrandir: will do
[01:56] <Mithrandir> seb128: cheers.
[01:57] <seb128> pitti: no problem, I'll upload a build1 one, you can review it and libxcb for main if you want to make up for it :p (new libx11 requires them)
[01:58] <pitti> seb128: I still don't understand the point of empty debs?
[01:58] <pitti> seb128: yes, will review :)
[01:59] <ogra> Keybuk, did dbus restart during the upgrade ? 
[01:59] <seb128> pitti: the package is bugged
[01:59] <seb128> I'll fix it
[01:59] <Keybuk> gdm was restarted (if that makes any difference)
[01:59] <Mithrandir> pitti: they're used on non-pthread arches of which we don't have any, but where syncing from debian > avoiding an empty package.
[02:00] <pitti> Mithrandir: ah, I see
[02:00] <seb128> ah, ok
[02:00] <seb128> non bugged then ;)
[02:00] <pitti> sorry for having screwed this up
[02:00] <seb128> Keybuk: weird, then everything should look for /var/run/gdm_socket and that should work
[02:00] <Keybuk> ogra: no, no dbus update
[02:01] <Keybuk> seb128: it didn't
[02:01] <Keybuk> I'd suggest testing this in vmware?
[02:01] <seb128> Keybuk: what socket do you have in use?
[02:01] <Keybuk> seb128: how do I tell?
[02:01] <seb128> ls /var/run -a | grep gdm
[02:01] <Keybuk> there's a /var/run/.gdm_socket
[02:02] <seb128> if you restarted gdm that should be /var/run/gdm_socket
[02:02] <seb128> what version of gdm is installed?
[02:02] <Keybuk> gdm was upgraded from 2.17.7-0ubuntu1 to 2.17.7-0ubuntu2
[02:02] <Keybuk> it was restarted by postinst with the usual "log out all sessions to take effect" message
[02:02] <Keybuk> (which I haven't done yet)
[02:02] <seb128> ah ok
[02:03] <seb128> so it was not restarted
[02:03] <Keybuk> gnome-screensaver was upgraded from 2.17.7-0ubuntu2 to 2.17.7-0ubuntu3
[02:03] <seb128> and for how long is gnome-screensaver running?
[02:03] <Keybuk> seb128: I can't tell
[02:03] <Keybuk> oh wait, yes I can, I have the VT where I killed it from
[02:03] <Keybuk> and ran ps first
[02:03] <Keybuk> Feb 19
[02:03] <seb128> ok, it's most likely than gnome-screensaver got restart for whatever reason
[02:04] <Keybuk> so I was running 2.17.7-0ubuntu2
[02:04] <Keybuk> doesn't look like it was started
[02:04] <seb128> which is using /var/run/.gdm_socket
[02:04] <seb128> I'll try later to install and herd4 and upgrade
[02:04] <Keybuk> are you sure it's not just that the gnome-screensaver-dialog process (which gets started when you try to unlock) wasn't looking in a different place?
[02:05] <pitti> Mithrandir: how do you feel about http://www.php.net/releases/5_2_1.php for feisty?
[02:06] <seb128> Keybuk: hum, might be yes
[02:07] <ogra> right, gnome-screensaver-dialog isnt running all the time ...
[02:07] <Mithrandir> pitti: apart from it being PHP so I have to hate it? :-)  I'll review the changelog at least.
[02:07] <ogra> it gets started on demand .... and the socket is hardcoded there
[02:08] <pitti> Mithrandir: I feel with you, but it's chained to our testicles^W^W^W^W^Wwe support it
[02:09] <pitti> Mithrandir: I have to cherrypick security patches anyway, so not updating to 5.2.1 wouldn't be much more work either; but people even ask me to put new microreleases into dapper (d'oh)
[02:09] <Mithrandir> pitti: the changelog looks sane to me at least.  Mostly small changes; I'd be a bit worried about the PDO_MySQL prepared statement API bit.
[02:09] <pitti> Mithrandir: right; OTOH there are probably much worse changes in 5.1.6(edgy) -> 5.2
[02:10] <Mithrandir> pitti: well, we have 5.2.0 already.
[02:10] <Mithrandir> (in feisty)
[02:10] <Mithrandir> pitti: I say just go for it.
[02:11] <pitti> ok
[02:11] <pitti> Mithrandir: you mean demoting php to universe, right? :-P
[02:11] <Mithrandir> pitti: that too, yes. :-)
[02:11] <Mithrandir> I'm sad we can't, but we can't.
[02:15] <StevenK> Mithrandir: Why not?
[02:17] <pitti> StevenK: sad, but true, server folks need it
[02:18] <StevenK> Pity.
[02:18] <StevenK> I give you -lusplash and the right headers, so why can't you find usplash_open!
[02:20] <jdong> StevenK: be nicer to it.
[02:21] <jdong> have you ever done anything in return for usplash?
[02:21] <jdong> tell it a entertaining story.
[02:21] <jdong> dance for it?
[02:21] <StevenK> I don't dance for anybody. :-P
[02:21] <jdong> that explains a lot...
[02:21] <jdong> ;-)
[02:22] <StevenK> Actually, it gets better. I drop -L/usr/local/lib, and now it tells me it can't find -lusplash
[02:24] <seb128> Mithrandir: did you accept libpthread-stubs previously? i.e: can I accept it without review? ;)
[02:24] <Mithrandir> seb128: yes.
[02:24] <seb128> good
[02:24] <seb128> doing that now
[02:26] <seb128> pitti: do you want wiki MIR pages for libpthread-stubs and libxcb?
[02:26] <pitti> seb128: don't bother about MIR for an empty package :)
[02:26] <pitti> seb128: I'll do the source/binary review of libxcb, ok? that'll do for MIR for my part
[02:26] <seb128> pitti: ok, thank you
[02:27] <seb128> pitti: libxcb has been already source accepted (it was coming from Debian and looked fine)
[02:28] <pitti> 'k
[02:28] <seb128> binaries will be available when libpthread-stubs is available so it can build
[03:07] <Riddell> dholbach: is the ubuntu logout dialogue a custom one?  and who made it?
[03:16] <Lathiat> pitti: ping?
[03:16] <Lathiat> pitti: i think https://launchpad.net/ubuntu/+source/avahi/+bug/83468 needs a serious look at
[03:16] <Ubugtu> Malone bug 83468 in avahi "Avahi behaves badly where there is a unicast .local-domain." [Undecided,Unconfirmed]  
[03:16] <Lathiat> pitti: i had problems where that was popping up once a second at an airport
[03:16] <Lathiat> pitti: *10 seconds
[03:16] <pitti> Lathiat: once per second? that is, you got a new dhcp lease so often?
[03:16] <Lathiat> im not sure if its dhcp lease related
[03:17] <Lathiat> i didnt think to check at the time
[03:17] <pitti> Lathiat: it's called as a dhclient plugin
[03:17] <Lathiat> ah so that would make sense
[03:17] <Lathiat> can you differentiate between renewing and a new lease?
[03:17] <pitti> Lathiat: not sure
[03:18] <Lathiat> if its an exit hook i think you can
[03:18] <Lathiat> wheres the files?
[03:18] <Lathiat> doesnt appear to be in the exit-hooks.d/ ?
[03:19] <pitti> Lathiat: /etc/network/if-up.d/avahi-daemon
[03:19] <Lathiat> ah
[03:21] <Lathiat> wouldnt have thought those files wouldbe recalled for a lease update
[03:22] <Lathiat> wee
[03:22] <Lathiat> i think i found an avahi bug
[03:22] <pitti> neither had I...
[03:22] <Lathiat> Feb 20 23:22:29 lathiat-desktop avahi-daemon[5117] : Host name conflict, retrying with <lathiat-desktop-12157>
[03:23] <Lathiat> i guess it's been doing that since i turned the machine on ;)
[03:26] <Lathiat> so i've set my dhcp timer to 10 seconds on my gateway
[03:26] <Treenaks> "oops"
[03:26] <Lathiat> heh i know why the above was happening 
[03:27] <Lathiat> theres a bug atm if the reverse dns pointer already exists
[03:27] <Lathiat> it just continues to conflict
[03:27] <Lathiat> because the reverse dns PTR never changes on host name change
[03:27] <Lathiat> it can never find a non conflicting set
[03:27] <Treenaks> *cycle* *cycle*
[03:27] <Lathiat> i had a conflicting host entry on my fileserver to test that bug from a few weeks back and forgot about it ;)
[03:28] <Lathiat> Feb 20 23:27:50 lathiat-desktop dhclient: bound to 203.15.141.2 -- renewal in 6 seconds.
[03:28] <Lathiat> woo ;)
[03:28] <Lathiat> pitti: hrm, that doesnt seem to be the cause
[03:28] <Lathiat> unless your ip changes everytime you got a new lease i guess
[03:28] <Lathiat> i guess that coudl cause it
[03:29] <pitti> Lathiat: I wonder whether the notification actually does something good...
[03:29] <Lathiat> pitti: either way perhaps some sort of rate limiting is in order and an easy way to disable the message
[03:29] <Lathiat> the notification is possibly superfluos
[03:29] <Lathiat> i guess its usefull to know
[03:29] <Lathiat> not sure if its worth a popup
[03:30] <Lathiat> could cause some confusion tho
[03:32] <Treenaks> Lathiat: wow, that DHCP server will get _hammered_
[03:33] <Lathiat> Treenaks: i just did that now as a test to see if that was the issue
[03:34] <cjwatson> minutes
[03:38] <Lathiat> cjwatson: heh
[03:38] <dholbach> carlos: pong
[03:38] <dholbach> Riddell: lmanul hacked on it
[03:41] <zorglu_> q. is there a 'network person/team' for ubuntu ? i mean who decide stuff about network like "no firewall by default" or "netif lo without multicast", this kind of stuff ?
[03:43] <Lathiat> pitti: i've added some comments to the bug please review when your back, cheers
[03:46] <zorglu_> where should i look to get an answer to this ? (if here is not the most suitable one)
[03:56] <carlos> dholbach: just wanted to know the status of gnome-power-management and totem in full screen mode
[03:56] <seb128> carlos: what do you mean?
[03:56] <carlos> seb128: let me look the bug #
[03:57] <dholbach> carlos: from that description I dunno either
[03:57] <infinity> The age-old "don't blank my screen while media players are fullscreen" thing that has no standard solution?
[03:57] <carlos> https://bugs.beta.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/30969
[03:57] <Ubugtu> Malone bug 30969 in gnome-power-manager "monitor goes to standby when playing a movie in totem fullscreen" [Medium,Confirmed]  
[03:57] <carlos> infinity: yeah, that one
[03:58] <dholbach> carlos: ogra takes care of g-p-m
[03:58] <seb128> nothing to do with g-p-m probably
[03:58] <carlos> oh, I saw comments from you and thought you were caring of that bug
[03:59] <infinity> You need to get totem, g-p-m, g-s-s, mplayer, blah blah blah to all talk to each other in a sane way.
[03:59] <carlos> seb128: any suggestion about how to help debugging it?
[03:59] <infinity> daniels and I once specced this using root window hints, but while it got coded on someone's laptop hard drive, it never really went anywhere.
[03:59] <seb128> carlos: nop
[04:00] <carlos> infinity: well, I guess GNOME modules should work by default
[04:00] <infinity> Neat theory. :)
[04:00] <carlos> I mean, totem is integrated with GNOME
[04:01] <seb128> totem does send a dbus signel to inhibit the screensaver
[04:01] <seb128> signal
[04:01] <carlos> and I know it's using DBUS to disable setting the screen off (or it's supposed to)
[04:01] <carlos> seb128: yeah
[04:01] <seb128> not sure of what trigger the screen power saving though
[04:02] <carlos> seb128: maybe a bad x.org configuration?
[04:02] <seb128> no idea
[04:02] <seb128> I've no clue about xdpm
[04:02] <carlos> I just killed gnome-power-manager and it still happens
[04:02] <seb128> dpms I mean
[04:02] <carlos> so I guess it's not directly related with it
[04:02] <seb128> not a surprise
[04:03] <infinity> Could still be.
[04:03] <infinity> DPMS timeouts are handled by the Xserver, no?  g-p-m just adjusts the delay according to user prefs.
[04:03] <infinity> So, if you kill it, the setting just never changes.
[04:04] <bddebian> Heya
[04:08] <carlos> infinity: I see
[04:21] <iwj> I think I might make a wrapper script called `vcs' which looks to see what metadata your cwd has and runs the right one ...
[04:26] <Mithrandir> it'd still break when you have stuff which is stored in multiple RCS-es.
[04:26] <Mithrandir> or am I the only person insane enough to do that? :-)
[04:26] <kylem> ... why?
[04:27] <cjwatson> I've done it in the past
[04:27] <Riddell> pitti: doing the adept apport stuff, it seems to need a delay of a second or so after the crash before running apport else apport doesn't process the files, did you have anything similar on the update-notifier side?
[04:28] <Mithrandir> kylem: useful way of doing CVS + SVN before I wrote my CVS-to-SVN committer.
[04:28] <cjwatson> kylem: nCipher had a CVS repository of handy stuff for your ~/.vim. I had my own SVN repository for ~, including .vim. I solved this by having ~/.vim/CVS and ~/.vim/.svn and cross-committing where necessary.
[04:28] <Mithrandir> kylem: and the reason I wanted both SVN and CVS is CVS exists on so many more systems.
[04:28] <cjwatson> iwj: it's only for commit, but debcommit is very useful for that
[04:28] <cjwatson> (in devscripts)
[04:29] <kylem> cjwatson, yow.
[04:31] <cjwatson> It's lucky I didn't. I couldn't have had two overlapping CVS checkouts like that nearly so easily.
[04:36] <iwj> cjwatson: Right, but then `vcs' would say "err, this is too confusing for me" and bail out.  So you'd have to say what you actually wanted in that case.  No great loss I think :-).
[04:37] <iwj> Wow, that sounds quite useful.
[04:37] <iwj> Thanks.
[04:38] <iwj> It's almost certainly cleverer than the shoddy thing I have for doing the same job.
[05:16] <Keybuk> cjwatson: isn't that the standard way of doing it? :p
[05:18] <iwj> Aargh, I hate python.  I've just spent 10 mins debugging something where I wrote    '\n'.split(output)
[05:22] <pitti> Riddell: well, apport needs some time to write out the report
[05:22] <pitti> Riddell: but we don't have any explicit delays
[05:23] <Riddell> pitti: ok, putting a sleep 1 before running apport fixes it fine
[05:23] <pitti> Riddell: however, it'll take a while between 'inotify reports action in /var/crash' and 'call apport-checkreports
[05:23] <pitti> Riddell: I think u-n checks every 10 seconds or so
[05:25] <iwj> Yay!  It's using the right version finally.
[05:25] <iwj> dsc1t-mawktest       FAIL status: 1, stderr: /root/adt-downtmp/mawktest: 24: mawk: no...
[05:25] <iwj> Not only can report test passes, but it failures too.
[05:30] <tkamppeter> pitti, ping
[05:31] <pitti> hi tkamppeter 
[05:32] <jdong> pitti: thanks for quick resolution of the hal mtab bug :)
[05:33] <pitti> jdong: you're welcome :)
[05:33] <jdong> now, pitti how do you feel about the unmount notify popups? :)
[05:34] <pitti> jdong: I'm not sure TBH
[05:34] <jdong> would you agree that it should always display that it's safe to remove the media?
[05:34] <pitti> I think the computer shuold only warn about unsafe things, not things that are safe
[05:34] <jdong> well, important things that are safe should be confirmed.
[05:35] <tkamppeter> pitti, it seems that the upload server is somehow hanging. The HPLIP which you have uploaded today in the morning did not arrive yet.
[05:35] <jdong> especially since in a slightly different context it could be unsafe...
[05:35] <kwwii> dholbach: so, did I mess something up somehow without knowing?
[05:35] <jdong> i.e. icon changes/disappears before data is flushed anyway
[05:35] <jdong> if that wasn't the case, I'd agree with you.
[05:35] <mvo_> iwj: from reading bug #84906 it looks like we need a SRU for the dapper vim package? 
[05:35] <Ubugtu> Malone bug 84906 in vim "vim-tiny postinst fails" [Medium,Confirmed]  https://launchpad.net/bugs/84906
[05:36] <dholbach> kwwii: seems the .desktop file is missing
[05:36] <dholbach> kwwii: HumanCircle has one, Human does not
[05:36] <dholbach> kwwii: or it's not installed
[05:36] <jdong> and pitti , while unmounting an iPod with near no dirty data, it still takes a bit of time for the disk to spin up....
[05:36] <Goliath23> hi
[05:36] <dholbach> kwwii: i can take a look too
[05:36] <pitti> jdong: hmmkay
[05:36] <dholbach> kwwii: ok, might have been my fault I'll check later
[05:37] <Goliath23> how do I get a hand on the ubuntu source repository? https://code.launchpad.net/ doesnt help much.. I need the file usplash-testcard-theme.c
[05:37] <Goliath23> its supposed to be an example for a minimal bootsplash theme
[05:38] <Goliath23> do I have to have an account to be able to read the repository?
[05:39] <jdong> no, you need bzr
[05:39] <kwwii> dholbach: I found it...it was removed from the makefile
[05:39] <kwwii> dholbach: I'll add that to the makefile, and update some picks soon
[05:40] <Goliath23> jdong: is there a webfrontend like websvn.kde.org?
[05:40] <jdong> Goliath23: not yet...
[05:40] <jdong> sorry :)
[05:41] <Goliath23> kk, i'll install bazaar. could you point me to an url, where I can find usplash-testcard-theme.c
[05:41] <Goliath23> ?
[05:41] <Riddell> Goliath23: you can also just do apt-get source usplash
[05:41] <Goliath23> oh okay. thanks
[05:46] <Keybuk> ooh... the spanish grand prix is the weekend immediately after UDS ...
[05:46] <Keybuk> just up the coast ...
[05:47] <Keybuk> (pretty boring track though)
[05:47] <Goliath23> Riddell: usplash seems to be version .4 while usplash-theme-ubuntu seems to be 0.6, also the makefiles differ much. which one should I use to create a simple custon usplash?
[05:47] <pochu> Keybuk: spanish grand prix?
[05:47] <pochu> Keybuk: formula 1? :)
[05:47] <iwj> mvo_: No, I don't think so.  That is, we can fix it up later rather than doing an SRU and that seems preferable.
[05:47] <Keybuk> pochu: yes
[05:47] <doko> seb128, pitti: please could you look again for -dbg packages in NEW
[05:48] <Riddell> Goliath23: usplash-theme-ubuntu
[05:48] <iwj> fix it up later> As in, just retain the workaround I uploaded today.
[05:48] <iwj> (Speaking of which I discover I failed to save debian/control before uploading :-/)
[05:49] <Goliath23> Riddell: do I have to recreate all the different images in all sizes or can I just modify the c-file so some are missing?
[05:50] <mvo_> iwj: ok, so its enough to have the feisty version fixed?
[05:50] <pitti> tkamppeter: which version was that?
[05:51] <iwj> mvo_: Yes, if we retain the fix until the next LTS.
[05:51] <iwj> The `fix' is just to create those directories and eventually to merge from Debian.
[05:52] <mvo_> iwj: ok, cool. and you will do the upload for vim? or should I do that?
[05:52] <iwj> As in that ought to make the symptoms go away and the real bug is fixed there.
[05:52] <iwj> I already have, see ^
[05:52] <mvo_> cool, thanks!
[05:53] <seb128> doko: looking now if nobody else did
[05:56] <Riddell> pitti: http://kubuntu.org/~jriddell/tmp/apport.png
[05:57] <pitti> Riddell: sexy! :)
[05:57] <pitti> Riddell: do you check for both user and system crashes?
[05:57] <Riddell> pitti: yes, it runs it with kdesu if there has been a system crash
[05:58] <pitti> cool
[06:06] <Keybuk> yay for not using the phrase "terminated unexpectedly"
[06:13] <seb128> doko: binary NEW mostly cleaned
[06:14] <seb128> pitti: libpthread-stubs binaries available for review
[06:14] <pitti> seb128: ah, will have a look
[06:14] <seb128> thank you
[06:17] <pitti> seb128: look fine, I put them into main
[06:17] <seb128> pitti: thank you
[06:17] <pitti> seb128: I'll NEW the python goo as well while I'm at it
[06:18] <seb128> pitti: ok, I did most of binary NEW a few min ago so there should not be much left
[06:19] <pitti> seb128: did you already new ps3pf-utils? there's a single ppc build in the queue
[06:19] <seb128> no
[06:19] <pitti> ok, I'll wait then
[06:19] <seb128> just the python dbg uploads from doko
[06:19] <pitti> these are done again
[06:20] <pitti> ah, php finished building, so back to that ;)
[06:29] <tkamppeter> pitti, there was a short network failure, so again, package is hplip_1.7.1-1ubuntu2
[06:30] <pitti> tkamppeter: ah, you built the changes with -sa, i. e. with an orig.tar.gz
[06:32] <doko> seb128, pitti: there always new dbg uploads ;)
[06:32] <seb128> doko: looking
[06:32] <doko> seb128: no, just joking
[06:32] <seb128> doko: ah :p
[06:33] <doko> seb128: the last one was vte/python-vte
[06:37] <Keybuk> http://tango.freedesktop.org/Window_Experiments
[06:37] <Keybuk> ^ that's rather nice
[06:39] <_ion> Quite nice indeed, as long as the document title, the program name and the menu bar take no more than two lines.
[06:40] <_ion> "Large, click-able/drag-able document icon that can be dragged to the trash to delete, dragged to the desktop and other locations to save, etc." Doesn't MacOSX do that (although with a small icon)?
[06:40] <Keybuk> Risc OS used to do that
[06:41] <Ng> why do you need to waste a whole line that tells you it's a text editor? I can see that, there's text in it :(
[06:41] <Keybuk> there wasn't an open or save dialog, you dragged the icon somewhere
[06:41] <Keybuk> Ng: I guess "Text Editor" vs. "IDE" vs. anything else
[06:42] <Keybuk> we had that argument a while back when we wanted to call "Firefox" just "Web Browser" ;)
[06:42] <Ng> I'm turning off more and more window borders as time passes, I'd just rather have the useful space
[06:43] <_ion> ng: I only have a title bar, the other borders are zero pixels thick.
[06:43] <Ng> that's the way to do it, but I appreciate that I'm an atypical use case ;)
[06:43] <Treenaks> macos does have that option that in the title bar
[06:44] <_ion> With soft shadows, windows are perfectly distinguishable from each other without borders.
[06:45] <Riddell> pitti: do python programmes need anything special for apport to pick up crashes?
[06:46] <pitti> Riddell: no, it just works
[06:46] <tkamppeter> pitti, thanks.
[06:46] <pitti> Riddell: just try adding a 'raise Exception' in /usr/bin/bzr or so
[06:48] <Riddell> pitti: that works, but it doesn't work if I do raise exception on just a local file
[06:48] <tkamppeter> pitti, it seems that in a short time CUPS 1.2.9 will come out, fixing bug 85339 and bug 57050, so we should perhpas put this up with UVF exception request, instead of 1.2.8.
[06:48] <Ubugtu> Malone bug 85339 in cupsys "CUPS test page does not look very good at A0" [Low,Needs info]  https://launchpad.net/bugs/85339
[06:48] <Ubugtu> Malone bug 57050 in cupsys "Brother HL-1430 USB printer will only print once" [Low,Confirmed]  https://launchpad.net/bugs/57050
[06:48] <slomo> Mithrandir: could you please take a look at #85454? :) the compiler bugfixes are something i would prefer to have asap ;)
[06:48] <pitti> Riddell: right, it's not supposed to; we only catch exceptions for packaged software
[06:49] <Riddell> pitti: clever
[07:26] <mdz> BenC: I received a request from a community member on bug 78634 for more information; is that what's needed or are they confused?
[07:26] <Ubugtu> Malone bug 78634 in linux-source-2.6.20 "usbdev4.1_ep00: PM: suspend 0->1, parent usb4 already 2" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78634
[07:27] <BenC> mdz: Checking...
[07:28] <BenC> mdz: Nope, it just needs to be fixed...I'll set the status
[07:28] <BenC> mdz: Most likely it's a driver, and the new code is just doing sanity checks that weren't there before
[07:29] <seb128> cjwatson, Mithrandir: do you know what happened to the libpthread-stubs binaries? pitti accepted them one hour ago and they are no to the archive
[07:30] <pitti> seb128: they are in drescher's archive
[07:30] <seb128> pitti: where?
[07:30] <pitti> seb128: drescher:~/ubuntu/pool/main/libp/libpthread-stubs
[07:30] <pitti> libpthread-stubs0 | 0.1-1build1 |        feisty | amd64, i386, ia64, powerpc, sparc
[07:30] <seb128> ah ok
[07:31] <pitti> seb128: so it's just the mirroring that lags
[07:31] <seb128> ok, good
[07:56] <_ion> Thanks a lot for the information!
[08:35] <victory747> I'm having a really strange problem with disappearing text in gnome terminal in feisty.  Has anyone seen anything like this?
[08:36] <Treenaks> victory747: no disappearing text here
[08:36] <Treenaks> but they do blink white every now and then
[08:36] <Treenaks> or flash once actually
[08:36] <Treenaks> but only during upgrades
[08:36] <victory747> well, i have whole lines that disappear, and then re-appear when highlighted or sometimes when the mouse is over them
[08:37] <jdong> victory747: I've seen xchat do that :)
[08:37] <victory747> almost like it's a refresh problem
[08:37] <jdong> victory747: using a 3D compositing WM or anything?
[08:37] <victory747> no, nothing strange
[08:37] <victory747> it's pretty much a stock feisty install from about a week ago (with upgrades)
[08:37] <jdong> hmm
[08:38] <jdong> I can't confirm that :(
[08:38] <victory747> I AM using my home directory from my edgy install, so there may be some strange stuff left over.
[08:38] <victory747> let me try a new user profile and see if i see anything
[08:39] <victory747> hmm, switch user doesn'twork
[08:40] <victory747> i remember now that when i woke up from suspend it would not log back in, so i killed the screensaver process
[08:41] <victory747> maybe that's why.  anyway, the gnome terminal thing has been doing that since i installed.
[08:44] <pochu> heno: ping?
[08:44] <heno> pochu: hi
[08:44] <pochu> heno: hi :)
[08:45] <pochu> heno: I'm building listen, but it has a warning:
[08:45] <pochu> Gtk-Message: Failed to load module "gail": libgail.so: cannot open shared object file: No such file or directory
[08:45] <pochu> Gtk-Message: Failed to load module "atk-bridge": libatk-bridge.so: cannot open shared object file: No such file or directory
[08:45] <pochu> heno: those are accesibility libraries, I think
[08:45] <pochu> heno: should I build against them?
[08:45] <pochu> since they are just warning, I can ignore them :)
[08:46] <heno> pochu: have you installed the relevant -dev packages and sources?
[08:46] <pochu> heno: no, I haven't. Should I add them to the build-deps?
[08:46] <heno> pochu: I'm not the best person to ask though; I don't build these things :)
[08:47] <pochu> :)
[08:47] <pochu> ok, ty anyway ;)
[08:48] <heno> pochu: some people in #ubuntu-accessibility will know, such as TheMuso and chrisj
[08:48] <pochu> heno: there :)
[09:54] <jdong> urgh since a dist-upgrade today X suddenly became very sluggish?
[10:18] <Mithrandir> slomo: approved
[10:20] <slomo> Mithrandir: thanks, uploaded :)
[10:44] <givr1> Mithrandir, or any archive manager around : can you reject ntfs-config from NEW, i have a new version in REVU waiting for an ack. Thanks
[10:54] <macd> would a dapper to edgy upgrade remove scsi emulation from a pata dvdr?