[00:00] <cjwatson> liw: you don't speak fluent HTTP?
[00:00]  * ion_ is quite happy with his own server that sends the queries to the source.
[00:00] <ogra> cjwatson, he just tried but missed the tags :)
[00:00] <liw> cjwatson, _I_ do, after implementing it for Kannel, but, er, um...
[00:00] <cjwatson> well, yeah, as it happens I do too but :)
[00:01] <cjwatson> ogra: no tags in HTTP, that's HTML :)
[00:01] <ogra> well :)
[00:03] <calc> slangasek: well it does return the response as non-authoritative
[00:03] <liw> I've had to battle with enough weirdness in DNS even when things work according to spec (my brain find DNS to be illogical), I really wouldn't want to have to deal with more broken DNS implementations than I have to...
[00:03] <slangasek> the logical next step is for them to run a POP3 server on the same IP, and start remotely deleting your email for you
[00:03] <slangasek> calc: that's, er, meaningless to almost all local resolvers
[00:04] <slangasek> calc: because *every* reply that doesn't come directly from the authoritative nameserver is supposed to be tagged that way
[00:26] <mathiaz> is it normal that libtoolize --copy --force deletes config.{sub,guess} but doesn't restore them ?
[00:26] <slangasek> not traditionally, but who knows with the new libtool :)
[00:26] <mathiaz> slangasek: I'm running into this problem when trying to build openldap on intrepid
[00:26] <mathiaz> slangasek: config.{sub,guess} are copied before autogen.sh is run, and then the build fails
[00:27] <slangasek> that really sounds like a libtool bug to me, then
[00:27] <slangasek> Keybuk: ^^ ?
[00:28] <slangasek> mathiaz: did you see my reply/branch on the cn=config stuff, btw?
[00:29] <mathiaz> slangasek: yop - I've got a reply ready in my Outbox.
[00:29] <mathiaz> slangasek: I've come up with a solution to *not* bring back the perl code :)
[00:29] <mathiaz> slangasek: I've also cherrypicked some of the changes you've made in your bzr branch
[00:30] <slangasek> wow, I'm interested to see how you managed that, then. :)
[00:31] <mathiaz> slangasek: well - just a for loop - but not that I think of it, it doesn't support includes in included files... yet
[00:32] <slangasek> does it handle merging of continued lines?
[00:32] <mathiaz> slangasek: such as ?
[00:32] <slangasek> mathiaz: slapd.conf supports line continuation with \
[00:32] <mathiaz> slangasek: on includes ?
[00:32] <slangasek> mathiaz: so if you don't handle this, you won't necessarily have parsed the file correctly
[00:33] <slangasek> on any directive, sure...
[00:33] <mathiaz> slangasek: hm - then my solution won't work :/
[00:34] <mathiaz> slangasek: I'll dive into that once I've uploaded something in intrepid
[00:35] <slangasek> ok
[00:41] <cjwatson> mathiaz: try adding --install
[00:51] <mathiaz> cjwatson: thanks - works well now :)
[01:15] <slangasek> mathiaz: pushed a couple more updates to the cnconfig branch; debconf template updates, basically
[02:22] <mathiaz> slangasek: great - I've merged your change in my branch
[02:22] <mathiaz> slangasek: I've also fixed the multi-line parsing stuff for includes
[02:23] <mathiaz> slangasek: I've pushed all of it to my lp branch
[02:23] <mathiaz> slangasek: which patch should I send for review: the one against your bzr branch or the against debian svn ?
[02:58] <__keybuk> mathiaz: probably a bug?  try --install
[02:59] <__keybuk> ah yes
[02:59] <__keybuk> don't use --force without --install ;)
[02:59] <__keybuk> it won't do what you think
[03:35] <dmb> this new openjdk that is going to be in 8.10, is it fully open source?
[03:35] <dmb> because i heard openjdk still had some close elements in order for it to build
[03:44] <ScottK> If it's in Main, it's fully open source.
[03:53] <pwnguin> or its a bug
[03:56] <dmb> is there a java plugin associated with openjdk?
[03:57] <lukehasnoname_> Is another hardy point release coming in the October area?
[03:57] <lukehasnoname_> sry if I doubled that
[03:57] <persia> pwnguin: There's no such bug, although not every feature present in sun-java6 is implemented (although 97% are)
[03:57] <persia> lukehasnoname: More likely December.  October is for intrepid.
[03:58] <lukehasnoname_> figures
[03:58] <lukehasnoname_> well, bedtime for me, I'll be on in... 9 hours.
[04:05] <slangasek> persia: january, rather
[04:06] <persia> slangasek: Early January?
[04:06] <slangasek> well, we'll see :)
[04:07] <persia> Ah.  I was sorta guessing 8.04.1 + six months, and (posibly mis-) remembered that being a few weeks ago.
[04:07] <slangasek> depends on how well we think we can get the dominoes set up before everyone goes on vacation in December
[04:07] <slangasek> 8.04.1 was beginning of July
[04:08] <persia> I guess.  Last year-end seemed fairly active: I'm not sure how this year will turn out.
[04:17] <wgrant> persia: Where fairly active == two major Soyuz breakages?
[04:17] <persia> wgrant: Well, there was that, but I also remember there being a bunch of people who were working on stuff: perhaps it was just extra visible because of the Soyuz breakages.
[06:37] <pitti> Good morning
[06:38] <pitti> ion_: so you really did have a runaway process?
[06:39] <pitti> or is it a bug in deluser?
[06:41] <Hobbsee> hey pitti!
[06:41] <pitti> hey Hobbsee, how are you?
[06:41] <Hobbsee> pitti: good :)
[06:41]  * StevenK waves to pitti 
[06:41] <Hobbsee> pitti: i found the pieces of paperwork i wanted, so \o/
[06:43] <ion_> pitti: Neither. A bug in something that is supposed to remove a USER_PROCESS entry from /var/run/utmp.
[06:44] <ion_> pitti: I changed the USER_PROCESS byte in utmp to DEAD_PROCESS with a hex editor and then deluser worked fine.
[06:46] <ScottK> Good morning pitti.
[06:46] <ScottK> pitti saying good morning is really I sign I should go to bed.
[06:46] <ion_> Ditto
[06:46] <pitti> ScottK: heh, sleep well!
[06:47] <Mithrandir> hiya dudes and dudettes
[06:47]  * Hobbsee stomps on Mithrandir's feet in greeting
[06:48] <Mithrandir> evilHobbsee
[06:48] <Hobbsee> :D
[06:48] <ScottK> Mithrandir: That's redundant.
[06:48]  * Hobbsee MUHAHAHAHA
[06:48]  * Hobbsee tickles and pokes ScottK with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™
[06:48] <Mithrandir> ScottK: I work for the Redundant Department of Redundant Redundancy.
[06:49] <StevenK> Sounds like the government
[06:49] <Mithrandir> njet
[06:52] <ScottK> Fortunately ScottK has had too much Scotch to feel any of it.
[06:52] <StevenK> Let's try a pool cue, then
[06:53] <ScottK> Let's not.
[06:53] <StevenK> It could be fun
[06:55] <ScottK> I've just fixed an RC bug in Lenny, so I'd appreciate a break.
[06:56] <Hobbsee> well, you may well get the break.   it would probably be your kneecaps, though.
[06:57] <ScottK> Yeah.  Many StevenK will just sponsor the NMU upload instead.
[06:57] <ScottK> Many/Maybe
[06:57] <StevenK> Will I? :-)
[06:58]  * ScottK double checks to make sure he really uploaded to mentors.
[06:59] <ScottK> Apparently, but that doesn't mean it actually shows up there.
[07:04] <ScottK> Since mentors appears to have eaten his upload, ScottK tosses out http://kitterman.com/debian/xmms2tray_0.4-1.1.dsc in the hopes that perhaps some DD present (StevenK maybe) will pick it up.
[07:04] <ScottK> It was an easy one to fix.
[07:04]  * ScottK stumbles off to bed.
[07:21] <pitti> doko: is debian/patches/javazic-fixup.patch still required? it's not applied anywhere
[07:21] <pitti> doko: I guess it's just noise (I already elminitated the sharutils b-dep and the debian/copyright amendment), but I want to confirm with you first
[07:24] <doko> pitti: no, not needed anymore
[07:25] <pitti> doko: ok, thanks; where do these three additional javazic/tzdata_jdk/* files come from?
[07:25] <pitti> there's no documentation in the changelog, nor upstream (bug/code) references
[07:30] <doko> pitti: part of openjdk as well. openjdk/jdk/make/sun/javazic/tzdata_jdk/*
[07:31] <pitti> ah, and they are not shipped in -headless, so that they need to be copied?
[07:35] <doko> yes, I only did want to add the code only. this is data, which could change more often as well?
[07:36] <pitti> so whenever a timezone is split, the changes need to be applied there as well?
[07:38] <doko> well, it's an additional symlink, isn't it?
[07:39] <pitti> right
[08:15] <pitti> mvo: good morning
[08:15] <mvo> good morning pitti
[08:15] <pitti> mvo: some problems with your p-apt SRU, I mailed you
[08:16] <mvo> pitti: yes, I noticed. thanks. I will re-upload in some minutes
[09:20] <mvo> pitti: the python-apt stuff is reuploaded with the requested changes
[09:20] <pitti> mvo: danke sehr!
[09:38] <lifeless> assertion: config files that include non-active lines make upgrades harder.
[09:45] <pwnguin> if nouveau didn't rely on unstable kernel interfaces and was sufficiently stable versus nv, would ubuntu ship it?
[09:47] <persia> pwnguin: Most likely.  As I understand things (and I'm not a nouveau expert) libdrm is currently the main blocker.
[09:51] <tseliot> pitti: I managed to make Jockey show the 3 supported drivers instead of just one, however the result is far from perfect (and I feel that it's just a cheap workaround) : http://albertomilone.com/Screenshot-Hardware-Drivers.png
[09:52] <pitti> tseliot: in terms of code hten? the screenshot doesn't have anything surprising
[09:52] <pitti> (unless one driver is supposed to be enabled0
[09:53] <tseliot> pitti: the entries in the screenshot don't have the "(VERSION)" beside the name
[09:53] <pitti> oh, indeed
[09:53] <seb128> pitti: thanks for moving some of the GNOME srus to -updates (and thanks to pedro who did some testing rounds yesterday)
[09:54] <pitti> tseliot: I might be able to give you a hand there?
[09:54] <tseliot> pitti: let's talk in private, I have some code to show you
[10:08] <pwnguin> persia: well, im curious about why people might feel accepting money is more dangerous than shipping code
[10:09] <persia> pwnguin: I don't understand what you mean
[10:27] <Wubbbi> Hello :) I've one question. did you updated the non-free nvidia driver to the current version? "http://www.nvidia.com/object/linux_display_ia32_173.14.12.html" "Fixed a problem with missing rendering in OpenGL Workstation Overlays. " that maybe fix the bug with the kde 4.1 desktop performance?
[10:51]  * pitti summons our nvidia driver expert tseliot
[10:51] <tseliot> LOL
[10:52]  * pitti hugs tseliot
[10:52]  * tseliot hugs pitti
[11:15] <Hobbsee> hmmm.  why don't keys work anymore, on intrepid?
[11:15] <cody-somerville> Hobbsee, we decided keys were too much work to maintain so we disabled them
[11:16]  * Hobbsee beats cody-somerville
[11:16]  * cody-somerville is hurting.
[11:17] <Hobbsee> Agent admitted failure to sign using the key.
[11:18] <Hobbsee> looks like https://bugs.edge.launchpad.net/seahorse/+bug/201786
[11:25] <Hobbsee> hmmm.  maybe it isn't, as the workaround doesn't work for me
[11:29] <seb128> Hobbsee: http://bugzilla.gnome.org/show_bug.cgi?id=544554
[11:29] <seb128> Hobbsee: if the issue is the ssh agent
[11:31] <Hobbsee> seb
[11:31] <Hobbsee> seb128: i'll live in hope...
[11:32] <seb128> Hobbsee: use ssh-add meanwhile?
[11:34] <Hobbsee> seb128: that looks broken too.  i've installed the pinentry stuff, so we'll see if that fixes it
[11:34] <seb128> Hobbsee: how is that broken?
[11:36] <Hobbsee> couldn't connect to agent
[11:39] <ramvi> Can you help me with customizing a livecd? I've made this sexy /etc/gconf/schemas/local-panel-default-setup.entries and to try to load it as default panel with this command: gconftool-2 --config-source=xml:readwrite:/etc/gconf/local.xml.defaults \   --direct --load \   /etc/gconf/schemas/local-panel-default-setup.entries
[11:39] <ramvi> But the livecd starts up the same God damn standard panels every time
[11:40] <ramvi> Why? :)
[12:28] <Riddell> pitti: I think the language-pack scripts need to be changed to take /usr/share/locale/xx/entry.desktop from kde-l10n-xx instead of kde-i18n-xx, where can I find that?
[12:33] <pitti> Riddell: the files are actually copied in the langpack-o-matic tree, not taken out of the packages (they are not exported)
[12:33] <pitti> Riddell: lp:langpack-o-matic has a directory extra-files/ with all the extra KDE bits (entry.desktop, charset, flag)
[12:34] <pitti> Riddell: those need to be unpacked, the .desktop replaced, and re-tar'ed
[12:34] <pitti> Riddell: I can do that for you, if you give me the new set of .desktop files? or want to do it yourself? (should just be a moderately complex bash for loop)
[12:45]  * Riddell grumps as his internet dies for the third time today
[12:45] <Riddell> pitti: http://www.kubuntu.org/~jriddell/tmp/desktop.tar.gz
[12:46] <pitti> Riddell: just bear in mind that this won't actually become active until we get the first intrepid export from Rosetta
[12:46] <pitti> (which we all desperately wait for...)
[12:46] <pitti> Riddell: will apply, thanks
[12:47] <Koon> pitti: I was wondering what would be your take on bug 253032 -- also do you think one day it should get integrated to network-manager rather than using a separate applet ?
[12:48] <Riddell> pitti: flag.png and charset seem to have disappeared, so should be just entry.desktop now
[12:48] <pitti> ah, that's good to know; I would have kept them
[12:50] <pitti> Koon: hm; knowing nothing about AD myself, "Likewise AD settings" is not much more helpful to me, I'm afraid
[12:51] <pitti> Koon: what does that app do?
[12:51] <pitti> does it just set the AD server name/workgroup, or something like that?
[12:52] <Koon> pitti: it allows you to join or leave an Active Directory domain (accepting new logins that are authentified in AD)
[12:52] <pitti> if so, that should eventually become a n-m plugin, yes
[12:52] <Koon> "Likewise Active Directory Membership" is a little long
[12:53] <pitti> I don't think we'll find a name which is both descriptive and short
[12:53] <pitti> the entire concept is just too complex to explain in a menu entry, IMHO
[12:53] <pitti> since users shouldn't even care about concepts like AD or pam-ldap, etc.
[12:54] <Koon> pitti: we can remove "Likewise" since likewise-open is in main as the preferred way of handling AD membership
[12:54] <pitti> Koon: let's do a step back
[12:54] <pitti> Koon: do you need that AD membership to log in in the first place, or to access network services?
[12:54] <pitti> (since I suspect the former, too)
[12:55] <Koon> pitti: the idea is to let users defined on the domain log in, so the former
[12:55] <pitti> Koon: shouldn't that be exposed in the login manager rather?
[12:56] <pitti> Koon: i. e. (just purely as a "how it should look like), gdm displays a list of available domains and allows you to pick one?
[12:56] <pitti> or, if it's just one, just use it?
[12:56] <Koon> pitti: makes sense. Though in Windows joining the domain is also done as a logged-in user
[12:57] <pitti> Koon: hmm; I don't understand where PAM should get your credentials from if it isn't already connected to the AD?
[12:57] <pitti> or is the concept based on the assumption that the user db is present locally?
[12:57] <pitti> (wouldn't that make the entire idea pretty worthless?)
[12:57] <Koon> pitti: you can both use domain logins and local logins
[12:58] <pitti> I understand it as the windows pendant of pam-ldap
[12:58] <pitti> I used the latter, but not the former
[12:58] <Koon> you use a local login to set up AD membership, which plugs pam modules, nsswitch etc.
[12:58] <Koon> from then on you can log in as a domain user
[12:58] <pitti> but ICBW (my windows networking knowledge is about this ---><---- big, sorry)
[12:58] <Koon> pitti: closer integration of AD into login would be the subject of a nice spec I think
[12:58] <pitti> hm, working as two different users?
[12:59] <pitti> that sounds overly complex to me?
[12:59] <pitti> Koon: what does the app actually need to do to join a domain, do you need any authentication to even connect to the server and become able to locally log in users?
[12:59] <Koon> pitti: that's the way it works on Windows
[12:59] <broonie> pitti: AD is LDAP+Kerberos so yes, it's roughly where pam-ldap is (it can interoperate with some configuration).
[13:00] <pitti> so setting up a network with AD requires the admin to set up local logins for every user in addition to maintaining the AD?
[13:00] <Koon> pitti: when you click "join" (in the elevated-privilege Likewise applet) it prompts you for a AD domain admin user/password
[13:00] <pitti> (well, there's probably some sort of replication going on, but it still seems weird to me)
[13:01] <Koon> pitti: no, no need for local users for each domain user
[13:01] <pitti> Koon: how do users log into a machine then? certainly not through a shared account?
[13:01] <broonie> The LDAP part provides a user database.
[13:02] <Koon> pitti: likewise hooks into nsswitch to accept users from local passwd/group and remote AD-provided ones
[13:03] <Koon> exactly as an external LDAP thing
[13:03] <pitti> (I actually meant on windows, where you mentioned the two-stage login, but ok)
[13:04] <Koon> on Windows you log in with the local admin defined during install, join the domain then domain users can log in and you get two admins, a local one and a domain one.
[13:04] <Koon> both in the "local admins" group
[13:04] <pitti> Koon: ah, hang on; "prompts you for a AD domain admin user/password" -> so that's *not* the user's name/password for login, but the AD admin's password for setting up this machine to allow AD user login in the future?
[13:05] <pitti> i. e. something that is done once as a setup, not every day as normal user login?
[13:05] <Koon> pitti: yes
[13:05] <pitti> aaah
[13:05] <Koon> (sorry I'm being unclear)
[13:05] <pitti> that's where my misunderstanding came from
[13:06] <pitti> so yeah, integration into gdm doesn't make too much sense then
[13:06] <pitti> in current hardy/intrepid I'd say that it belongs into network-admin
[13:06] <Koon> pitti: better as an additional tab in network-manager
[13:06] <pitti> but that's going away
[13:06] <pitti> since n-m replaces network-admin, it should go there, yes
[13:07] <Koon> pitti: ok so we should spec closer AD integration, but for Intrepid+1
[13:07] <Koon> pitti: for Intrepid do you have any preference ? I mean, anything more descriptive than "Likewise" is OK ?
[13:08] <pitti> Koon: I'd aim for consistency here; ATM, the large majority of entries in the Admin menu have descriptions without names
[13:08] <pitti> i. e. it says "Printers" and "Hardware drivers", not system-config-printer and Jockey
[13:08] <pitti> so what about "Active Directory Setup"?
[13:09] <Koon> it's a little confusing because you aren't setting up Active Directory. You're setting up your membership to an existing AD
[13:10] <Koon> I think I prefer "Active Directory Membership" -- the two functions the applet can do is "Join" and "Leave"
[13:10] <persia> "Active Directory Membership"?
[13:10] <pitti> Koon: right, "Membership" WFM
[13:11] <pitti> Koon: thanks for the heads-up!
[13:11] <Koon> persia: as in "setting up my integration inside an AD domain"
[13:11] <Koon> pitti: many thanks for taking the time to bear with my explanations :)
[13:11] <persia> Koon: Right.  It was meant as a suggestion, but you suggested the same thing at the same time :)
[13:11] <Koon> persia: great minds alike ?
[13:16]  * pitti sighs at lightweight bzr checkouts; painfully slow...
[13:18] <Ng> hmm. is this overflow /tmp/ thing a new feature in hardy?
[13:18] <pitti> Ng: no, it's been there a little longer; feisty?
[13:18] <Hobbsee> seb128: hmmm.  running ssh-add first seems to fix the problem
[13:18] <Hobbsee> the key-based auth works after that
[13:19] <Ng> pitti: interesting. I only just came across it, someone's laptop was full, so the deleted a load of files, but the 1MB overflow /tmp/ was full too, so things still gave out-of-space errors (specifically thunderbird, which uses /tmp/ extensively)
[13:19] <pitti> Ng: ah; well, it's just meant to allow you to login in the first place to clean up
[13:20] <pitti> there should be some kind of notifictaion, right
[13:20] <Ng> pitti: unfortunately the laptop in question is some thousands of miles from me, so I didn't see whether it notified or not, but evidently the user in question didn't notice it, or understand it :/
[13:21] <Ng> perhaps it should trigger a similar reboot-required thing to kernel updates, so there is a more persisent notification?
[13:26] <pitti> it would warrant a panel icon, yes
[13:26] <pitti> it would integrate nicely with liw's system cleanup app
[13:27] <liw> yay! more files to delete!
[13:28] <mvo> I added a "clean" hook into the friendly-recovery menu too - this should be integrated with the system-cleanup too probably
[13:28] <liw> system-cleaner: because files are tasty and unlink(2) is faster than gzip(1)
[13:34] <gaspa> is there a way to get diffs beetween a generic -ubuntuX  and ubuntuX+1 revision?
[13:34] <gaspa> i mean, a place where _all_ revision were keeped, or their patches (in latter case i know the answer: no)
[13:35] <seb128> gaspa: launchpad has those diff now, so for recent version the package summary on launchpad
[13:36] <gaspa> seb128: ok, i'll see.
[13:37] <cjwatson> gaspa: also http://patches.ubuntu.com/by-release/atomic/ubuntu/
[13:38] <gaspa> cjwatson: ah, i didn't know... thanks.
[14:23] <pitti> seb128: gpm d-bus activated? that would be really weird...
[14:24] <seb128> pitti: why? it has a /usr/share/dbus-1/services/gnome-power-manager.service
[14:24] <pitti> oh, really!
[14:25] <pitti> but I thought that would be a g-p-m backend, not the applet
[14:25] <pitti> well, I'm confused
[14:28] <seb128> pitti: what do you mean?
[14:28] <seb128> pitti: gpm is what is used to know if you can suspend, hibernate, etc
[14:28] <pitti> seb128: I usually thought applets are started with autostart .desktop files, not via d-bus
[14:28] <seb128> yes, but I'm not speaking about the applet there
[14:28] <seb128> the applet is fine
[14:29] <seb128> that g-p-m itself which doesn't have the right environment
[14:30] <pitti> ah, I thought daemon and applet are the same process
[14:30]  * pitti doesn't find a separate power-applet process on his system
[14:31] <pitti> seb128: hm, so at least my session dbus does have the $XDG_SESSION_COOKIE; it might not pass it to activated services?
[14:31] <seb128> pitti: there is no applet, it uses the notification area and yes that's gpm itself which doesn't that
[14:31] <seb128> pitti: right, dbus activation doesn't pass an environment, a patch has been commited to dbus git recently to provide a way to do that
[14:32] <seb128> pitti: that's one of the reasons why we didn't active gnome-settings-daemon over dbus, otherwise the applications started using multimedia key can't connect to gnome-keyring, etc
[14:33] <seb128> *idea*
[14:33] <pitti> right, I remember
[14:33] <seb128> pitti: thanks pitti, that talk gave me an idea about the issue
[14:34] <pitti> seb128: so, would it help to have an autostart .desktop file for g-p-m?
[14:34] <seb128> gdm has an autostart directory
[14:34] <pitti> /etc/xdg/autostart/gnome-power-manager.desktop, hm, there is
[14:34] <seb128> but I put something in there to get a command line handy start on the gdm screen
[14:34] <seb128> and that didn't work
[14:34] <pitti> gdm might not look at /etc/xdg/autostart/
[14:34] <pitti> ?
[14:34] <seb128> I guess for whatever reason it doesn't manage to autostart those
[14:35] <seb128> and g-p-m get started over dbus when queried
[14:35] <seb128> pitti: no it doesn't
[14:35] <pitti> hah; that would be it then
[14:35] <seb128> it looks to /usr/share/gdm/autostart
[14:35] <pitti> well, I guess that's a feature
[14:35] <seb128> well, there is nothing in this one
[14:35] <seb128> I'm wondering if that's the issue
[14:36] <pitti> since even though it is a session, you might not want *all* the user stuff in gdm
[14:36] <seb128> maybe we should have gpm there
[14:36] <pitti> right, I think you should
[14:36] <seb128> but why the upstream tarball doesn't install an autostart there then?
[14:36] <pitti> that's also a little less brittle than relying on d-bus activation env passing
[14:36] <pitti> maybe Fedora symlinks the one from /e/xdg/autostart?
[14:37] <seb128> doesn't seem so
[14:37] <seb128> at least not in the gdm spec
[14:39]  * seb128 grrrrs at soren
[14:40] <seb128> virt-manager still doesn't work in intrepid
[14:44] <mvo> seb128: kvm is also a bit on the crashy side for me in interpid, not sure if that is kvm or the kernel though
[14:44] <seb128> mvo: well, virt-manager doesn't allow to select an iso, the "next" button in the wizard does nothing
[14:45]  * pitti currently uses only kvm directly, which seems to work fine
[14:45] <mvo> meh, different problem I guess, for me kvm (directly without virt-manager) behaves unstable (crashes in the guest etc)
[14:45] <mvo> sometimes, not always
[14:45] <seb128> pitti: the fc9 beta iso I have on the disk indeed has a gnome-power-manager.desktop in the gdm autostart directory ;-)
[14:45] <pitti> with virt-manager, it is unbearably slow (theory: not using /dev/kvm)
[14:46] <pitti> seb128: Qapla'!
[14:46]  * pitti hugs seb128
[14:46]  * seb128 hugs pitti
[14:46] <seb128> what is the rpm equivalent to dpkg -S file?
[14:46] <pitti> seb128: see, that should get filed upstream, Fedora didn't properly contribute patches back *cough*
[14:46] <seb128> ;-)
[14:58] <pitti> seb128: rpm -q something, --help usually worked for me
[14:59] <pitti> seb128: however, IMHO it's debatable whether this symlink shuold really go into gpm or gdm
[14:59] <seb128> pitti: rpm -q -f worked
[14:59] <seb128> I'm talking to upstream about it
[14:59] <pitti> argh, too many 'manager's in the session
[14:59] <pitti> nothing that does the real work :-P
[14:59] <ScottK> Rename them all 'kit' and it'll be fine.
[15:02] <Hobbsee> ScottK: *grin*
[15:04] <pitti> seb128: oh, was the -q -f successful? which package ships it in fedora?
[15:05] <seb128> pitti: gnome-power-manager
[15:05] <pitti> ok
[15:12] <pitti> Riddell: quite a few language desktop files got dropped, though
[15:12] <pitti> and 5 added
[15:12] <pitti> Riddell: committed and pushed
[15:12] <Riddell> pitti: yeah, there's not as many completed langagues in kde 4 yet, I guess you can keep the entity.desktop files from KDE 3 though
[15:13] <Riddell> entry.desktop rather
[15:27] <emgent> moin
[15:58] <LocutusOfBorg> hello!
[15:58] <LocutusOfBorg> is this a bug report channel???
[15:59] <LocutusOfBorg> I don't know if is really a bug...
[15:59] <LocutusOfBorg> I run under ubuntu intrepid ibex, but I cannot usa tty1 to 6
[15:59] <LocutusOfBorg> no problem with graphics
[16:02] <mkrufky> LocutusOfBorg: ubuntu uses a bug tracker, located at launchpad.net
[16:02] <Pici> LocutusOfBorg: Also, the Intrepid discussion channel is #ubuntu+1
[16:02] <Hobbsee> LocutusOfBorg: i don't think you should be running ibex...
[16:03] <LocutusOfBorg> Hobbsee, now I run under both 8.04 and 8.10
[16:03] <LocutusOfBorg> is only for nug huntung... :)
[16:03] <LocutusOfBorg> mkrufky, I had already submitted a bug on launchpad...
[16:03] <LocutusOfBorg> https://bugs.launchpad.net/bugs/253661
[16:04] <LocutusOfBorg> ubottu, yeah
[16:04] <Hobbsee> LocutusOfBorg: you should leran to file better bugs than that.  put a more descriptive title on it, for a start.
[16:04] <LocutusOfBorg> oh, I know
[16:04] <LocutusOfBorg> thanks...
[16:05] <LocutusOfBorg> But my english is not good, and I didn't find a better title... :P
[16:06] <LocutusOfBorg> https://bugs.launchpad.net/bugs/253661
[16:06] <Hobbsee> try "tty 1-6 does not work with a Ati Radeon 9600 pro" or something
[16:06] <Hobbsee> either way, this is not a support channel, so please continue this in #ubuntu+1
[16:07] <LocutusOfBorg> ok...
[16:09] <LocutusOfBorg> Hobbsee, title changed... :D
[16:10] <LocutusOfBorg> thanks!
[16:10] <LocutusOfBorg> have a nice day!
[16:10] <LocutusOfBorg> i'll go on the other chan
[16:31] <pitti> kirkland: I'm looking at ecryptfs to steal some knowledge about auth-client-config; how come that there is no postinst/prerm to trigger the PAM updating through a-c-c?
[16:33] <calc> doko: ping
[16:34] <pitti> kirkland: the a-c-c manpage suggests that this is necessary?
[16:34] <doko> well, ask ...
[16:34] <calc> doko: can you make me an admin on openoffice-pkgs also?
[16:35] <doko> sure
[16:35] <calc> thanks :)
[16:35] <pitti> jdstrand: "auth-client-config -L" doesn't have 'pam-login'; does that mean that I cannot use it to update the 'login' profile? or will that Just Work once I actually add a profile for login?
[16:36] <pitti> jdstrand: context: for a spec of mine I need to make libck-pam-connector to add itself to /etc/pam.d/login on installation (and cleanup on removal)
[16:36] <pitti> jdstrand: however, I'm still pretty unsure how to use a-c-c for that
[16:37] <jdstrand> pitti: hmmm, currently auth-client-config only deals with common-* (and nsswitch.conf)
[16:37] <calc> how do i delete a package that hasn't built yet from a ppa?
[16:37] <pitti> jdstrand: I tried to add it to common-auth, but that applies to gdm sessions as well then, which screws up
[16:37] <calc> i thought i needed admin access to the group, but that doesn't appear to be enough
[16:38] <pitti> jdstrand: would it be difficult to make it work for login as well? if so, I can cook my own solution in the postinst, but I'd much rather use a-c-c as common infrastructure
[16:38] <jdstrand> pitti: there isn't a technical reason why auth-client-config couldn't handle arbitrary /etc/pam.d/* files
[16:38] <jdstrand> pitti: it just currenty doesn't. I'd need to extend it
[16:38] <pitti> eek, except that /etc/pam.d/login is a conffile
[16:39] <pitti> while common-session isn't
[16:39] <pitti> urgh
[16:39] <jdstrand> pitti: you planning to do this automatically from postinst?
[16:39] <pitti> jdstrand: ok, seems I can't use a-c-c for this anyway
[16:40] <slangasek> pitti: why is it specific to login?
[16:40] <pitti> jdstrand: seems I should rather modify the default conffile accordingly and make it silent if the package isn't installed
[16:40] <pitti> slangasek: I don't want it for {g,k}dm sessions
[16:40] <pitti> since then you'll get two CK sessions for the same TTY, which confuses PolicyKit and others, and breaks
[16:41] <slangasek> pitti: the only way to make it silent right now is to use the 'missingok' module option, which is a horrible kludge that I was planning to get rid of as soon as I had the PAM framework stuff implemented
[16:41] <pitti> jdstrand: modifying other package's conffiles is a no-no, that's why I can't
[16:41] <pitti> slangasek: hm; would "the PAM framework stuff" include a scenario like mine? (just apply to VT logins)
[16:41] <jdstrand> pitti: yes I know, I was trying to ascertain if you were trying to do this via packaging, or have the user run a-c-c
[16:41] <slangasek> how does that cause two CK sessions for the same TTY, and couldn't that be addressed in either the PAM module (making the module a no-op for X sessions) or in the DM (deferring to PAM)?
[16:42] <slangasek> pitti: no, not in the least :/
[16:42] <slangasek> the framework is for managing the "common" files only
[16:42] <slangasek> the per-service files are conffiles, deliberately
[16:42] <jdstrand> pitti: based on your comments, it sounds like the former
[16:42] <pitti> slangasek: I guess that depends on which order the two CK sessions are created
[16:43] <pitti> jdstrand: just packaging, since we want to install it by default
[16:43] <jdstrand> (in which case, a-c-c is not a good fit-- unless you plan to have it own login)
[16:43] <pitti> jdstrand: no, that would be bad
[16:43] <slangasek> pitti: well, couldn't your module just check pam_get_item(PAM_TTY) and only start a session if it's a real TTY?
[16:43] <jdstrand> right
[16:43] <slangasek> (as opposed to an X display)
[16:44] <pitti> slangasek: if that's possible, sure; also, if gdm registers the CK session before PAM does, the pam-ck could just check for one
[16:44] <pitti> but if it's the other way around, it gets hairdy
[16:44] <pitti> hairy
[16:44] <pitti> slangasek: unfortunately there is no call for modifying an existing session, such as adding an X11 display
[16:45] <pitti> but it seems you both recommend to do use common-session and fix it in the PAM module itself
[16:45] <pitti> ok, I'll look into that then
[16:45] <pitti> jdstrand: so assume I use a-c-c with common-session, a-c-c still needs to be called in the postinst, right? ecryptfs-utils currently doesn't seem to do that
[16:45] <jdstrand> pitti: correct
[16:45] <slangasek> I don't think you want to just check for an existing session; I'm not sure that gdm keeps enough PAM state around until the end to let the PAM module know it didn't open it in the first place
[16:45] <slangasek> a-c-c isn't meant to be called in a maintainer script either :/
[16:46] <jdstrand> pitti, slangasek: there is documentation in the a-c-c source packge about ideas for using it in packaging, but there is no policy in place
[16:46] <jdstrand> pitti, slangasek: though I believe there are enough options to safely do it...
[16:47] <pitti> slangasek: hm, so you neither like changing the default conffile to include it, nor using a-c-c in the postinst?
[16:48] <pitti> what's the recommended way to set things up then?
[16:51] <slangasek> pitti: https://wiki.ubuntu.com/PAMConfigFrameworkSpec; you work on fixing your PAM module to handle the TTY, and I'll work on this :)
[16:52] <pitti> slangasek: ok :)
[16:53] <jdstrand> slangasek: wrt your Spec-- it doesn't handle nsswith.conf (obviously, it's a pam spec). do you have thoughts on dealing with nss too?
[16:54] <slangasek> jdstrand: only vague and incomplete thoughts; nss is much simpler by comparison, really
[16:55] <slangasek> it's "insert this block with the priority I tell you" and then "sed -e's/mymodule( \[[^]]*\])*//'
[16:55] <jdstrand> slangasek: sure-- I was just thinking of the out-of-the-box experience that is trying to be achieved
[16:55] <slangasek> "
[16:55] <slangasek> I mean simpler in terms of implementation
[16:55]  * jdstrand nods
[16:59] <jdstrand> slangasek: I guess I am getting at-- what packages will do that?
[16:59] <slangasek> jdstrand: well, a simple tool to do it can be provided by glibc itself, and then each nss package can call it in the maintainer scripts
[17:00] <seb128> cjwatson, evand: is https://bugs.launchpad.net/ubuntu/+source/grub/+bug/253323 a known issue? the user who filed it mailed me about it (not sure why) asking if he needed to do something to have the bug triaged correctly
[17:00] <jdstrand> slangasek: there will have to be policy built into that tool for ordering... won't there?
[17:01] <slangasek> jdstrand: hmm, somewhere, yes :)
[17:01] <slangasek> sorry, going into a meeting now
[17:01]  * ogra wonders about the likelyness to get sshfs into main in intrepid 
[17:01] <jdstrand> slangasek: ok, just wanted to bring it to your attention :)
[17:02] <ogra> does anyone see any big drawbacks i should know about ? (i.e. is it worth to start a MIR process)
[17:03] <cjwatson> seb128: I'm not familiar with it, I'm afraid
[17:04] <seb128> cjwatson: ok, I was wondering if grub is the right component there or if that should be assigned to some installer component
[17:05] <cjwatson> grub seems a plausible enough start
[17:05] <seb128> ok, thanks
[17:05] <cjwatson> it won't be possible to tell without digging into it
[17:07] <warren> Hmm
[17:07] <warren> https://bugzilla.mozilla.org/show_bug.cgi?id=435764  was pointed out here yesterday as an upstream fix for the flash 10 crashers.
[17:07] <warren> I patched my xulrunner in Fedora 9, but I found that crashes now happen in nspluginwrapper-1.1.0 instead of firefox.  So it seems further work is needed to fully fix this.
[17:08] <warren> Just mentioning this because you folks likely will have the same problem.
[17:08] <ogra> how does it work without nspluginwrapper ?
[17:09] <warren> ogra: i'm testing that now
[17:10] <ogra> warren, btw, note that our FF maintainer is at the FF conference atm
[17:10] <kirkland> pitti: hey, i have meet someone for lunch, i'll get back with you in a bit
[17:10] <ogra> so it might not be easy to catch him online
[17:10] <kirkland> pitti: or perhaps jdstrand has answered your questions
[17:22] <kees> TheMuso: say, your chvt change to initramfs-tools -- won't that hide the messages from the mountroot-fail hooks?  Maybe those should switch to vt1 as well?
[17:26] <warren> ogra: without nspluginwrapper it seems to no longer crash.
[17:26] <ogra> warren, hmm ,intresting
[17:26] <warren> (with the above patch to xulrunner)
[17:27] <ogra> you probably need to adapt that patch to nspluginwrapper then
[17:27] <warren> ogra: nspluginwrapper-1.1.0 has new support for the windowless plugin mode in flash 10, so there might be an additional issue in nspluginwrapper
[17:27] <warren> hm
[17:27] <warren> I have no idea how this stuff works =)
[17:28]  * ogra looks at the launchpad downstream bug
[17:28] <ogra> probaby that gives some hints
[17:29] <warren> URL?
[17:29] <ogra> warren, https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/239182/comments/19
[17:29] <ogra> hmm, you said you use that version
[17:29] <warren> yes
[17:29] <warren> prior versions of nspluginwrapper hid the firefox bug because it didn't pass the windowless stuff to firefox
[17:31] <ogra> well, in the LP bug some people seem to have it working
[17:31] <ogra> but we dont have nspluginwrapper on i386
[17:31] <ogra> (we planned to for intrepid though)
[17:42] <thibs> hi
[17:42] <thibs> I have a little question about packaging
[17:43] <persia> thibs: You may wish to ask in #ubuntu-motu
[17:43] <thibs> I'll do that!
[17:43] <thibs> thanks
[17:43] <warren> ogra: it works on maybe 50% sites
[17:43] <ogra> hmm, thats not really sufficient
[17:44] <ogra> but then i doubt upstream mozilla actually uses nspluginwrapper
[17:44] <ogra> so they might not really care
[17:47] <warren> ogra: yes, that's part of the problem
[17:47] <ogra> we do care on amd64
[17:48] <ogra> and as i dicussed with asac might move to it for i386 as well
[18:29] <mathiaz> zul: is samba 3.2 in intrepid ?
[18:30] <mathiaz> zul: I only see 3.0.30 in the archive
[18:30] <seb128> mathiaz: launchpad is your friend
[18:31] <seb128> mathiaz: https://edge.launchpad.net/ubuntu/+source/samba
[18:31] <seb128> mathiaz: https://edge.launchpad.net/ubuntu/+source/samba/2:3.2.0-4ubuntu1
[18:31] <mathiaz> seb128: oh - thanks - I was looking at packages.ubuntu.com
[18:32] <seb128> mathiaz: it's in NEW due to libwbclient0 and samba-tools, looking at accepted it now
[18:32] <alex-weej> new synaptics touchpads support detection of number of fingers when stroking the pad
[18:32] <mathiaz> seb128: ah - this is why I don't see it there.
[18:33] <alex-weej> the synaptics driver has an option for enabling scrolling/panning when making a two-fingered stroke
[18:33] <seb128> mathiaz: https://edge.launchpad.net/ubuntu/+source/samba/2:3.2.0-4ubuntu1 has the "NEW" indications
[18:33] <alex-weej> it's not on by default, instead with the right and bottom edge serving as vertical and horizontal scrolling areas, purely because of a lowest-common-denominator approach
[18:33] <seb128> mathiaz: do you know if libwbclient0 and samba-tools need to go to main?
[18:33] <alex-weej> i had opened a "bug report" for the proposal to enable it by default where possible
[18:34] <alex-weej> but timo aaltonen said "not likely to happen, besides it's a feature request so I'm tempted to close this."
[18:34] <alex-weej> *headdesk*
[18:35] <mathiaz> seb128: let me check - I'm sure slangasek will give a quick answer too
[18:36] <seb128> mathiaz: ok, binaries accepted, we can adapt the override later
[18:37] <mathiaz> seb128: ok - samba-tools is only testing stuff - libwbclient0 would definitely find its place in main
[18:37] <alex-weej> does anyone know what's going on with the seahorse gpg agent in intrepid? it doesn't seem to work...
[18:37] <alex-weej> *ssh key agent, whatever
[18:38]  * alex-weej can't push his bzr branch :<
[18:38] <poningru> just use gpg in the command line
[18:38] <poningru> oh ssh key
[18:38] <poningru> check .ssh/
[18:38] <poningru> err ~/.ssh/
[18:39] <alex-weej> poningru: check it for what?
[18:39] <alex-weej> it's fine, and when openssh-ssh fails to get the key from seahorse it asks me for my password on the CLI and it works fine
[18:39] <alex-weej> it's just i can't log in to launchpad with a password with bzr
[18:39] <alex-weej> wait, that makes no sense
[18:40] <seb128> alex-weej: ssh or gpg?
[18:40] <alex-weej> ssh
[18:40] <seb128> alex-weej: http://bugzilla.gnome.org/show_bug.cgi?id=544554
[18:40] <alex-weej> i know of at least one other person on #gnome-hackers who has the same problem
[18:40] <slangasek> seb128: libwbclient0 needs to go in main, samba-tools doesn't
[18:40] <alex-weej> seb128: thanks
[18:40] <seb128> slangasek: ok, what I though, thanks
[18:41] <seb128> alex-weej: you can "unset SSH_AUTH_SOCK" and use no agent as a workaround
[18:42] <alex-weej> seb128: great, thanks
[18:55] <poningru> can someone help me write a bug for a particular audio issue?
[18:55] <poningru> https://help.ubuntu.com/community/AspireOne
[18:55] <poningru> check under audio
[18:56] <poningru> just rebuilding it seems to fix aud9io
[20:19] <tjaalton> alex-weej: so how would you detect such devices?
[20:23] <alex-weej> tjaalton: any myriad of ways
[20:23] <alex-weej> tjaalton: if the synaptics hardware doesn't reveal itself
[20:23] <alex-weej> then you can get the model information of my notebook from HAL
[20:24] <alex-weej> tjaalton: btw your IRC nick on launchpad is different
[20:26] <alex-weej> tjaalton: i filed it against xorg for that reason. i don't expect drivers to be looking stuff up in HAL
[20:30] <tjaalton> alex-weej: so the driver should contain a database of models that support that?
[20:30] <tjaalton> er, list
[20:33] <alex-weej> tjaalton: probably HAL FDI with mechanism in Xorg to apply the policy
[20:33] <alex-weej> tjaalton: basically, i'm sick of Mac OS getting all the fun.
[20:34] <alex-weej> it "just works"
[20:35] <tjaalton> well, they don't have that much hardẃare to support..
[20:35] <alex-weej> tjaalton: and neither do we if we just start building whitelists of models for this kind of thing.
[20:45] <kees> is vte's rendering engine single-threaded, or something?  when having text pooring past my screen in one terminal, other terminals are laggy.
[20:46] <ion_> All gnome-terminals are a single process IIRC, and it might very well not be multithreaded.
[20:47] <Treenaks> gnome-terminal --disable-factory
[20:47] <Treenaks> takes a bit more memory, but speeds them up nicely for me
[20:47] <Treenaks> also, a bug in gnome-terminal doesn't kill all my terminals at once
[20:47] <tjaalton> alex-weej: btw, my nick seems to be correct on lp :)
[20:49] <alex-weej> tjaalton: odd. for some reason i only say tepsipakki before. not sure what i was looking at.
[20:49] <alex-weej> *only saw
[20:53] <ogra> tjaalton, input devices usualy have a cpability set in hal, just look for that one, synaptcs devicdes usually have input.touchpad
[20:53] <ogra> *capability
[20:55] <tjaalton> ogra: so the fdi-file could append a setting that matches that capability
[20:55] <ogra> why an fdi file ?
[20:55] <ogra> fdi files are usually needed to fix kernel bugs only
[20:55] <ogra> if the kernel doesnt set that capability, fix the kernel :)
[20:57] <ogra> the hal-input module should handle it properly, if it doesnt fix the cause and dont work around it :)
[20:58] <ogra> fdi files are a last resort :)
[20:59] <tjaalton> ogra: er, they are needed to get input-hotplug working
[21:00] <ogra> oh ? who designed that ?
[21:00]  * ogra cant imagine upstream likes that
[21:00] <tjaalton> daniels et al I guess :)
[21:00] <tjaalton> ie. upstream
[21:01] <ogra> woah
[21:02] <ogra> well, then be it ... i wont argue with daniels about input stuff :)
[21:47] <kirkland> slangasek: hi, you around?
[21:47] <slangasek> kirkland: hiya
[21:47] <kirkland> slangasek: I'd like to run an email to debian-devel by you that I'm drafting, regarding 'status' in the init scripts
[21:48] <kirkland> slangasek: mdz pointed me to you, as a good person to vet this by
[21:48] <slangasek> ok
[21:48] <kirkland> slangasek: i'll send it your way once I get it cleaned up a bit
[21:49] <kirkland> slangasek: I'm curious if you've grown any more comfortable with those patches as they stand for samba in Debian?
[21:50] <slangasek> kirkland: I don't think there's a "comfort" question now, just one of reviewing the multiple proposals and getting it committed
[21:51] <slangasek> it's been all pam/openldap for me the past week and a half, no time to squeeze in samba work :)
[21:51] <kirkland> slangasek: ogey doke ;-)
[21:52] <emgent> slangasek: when you have time can you accept rapache backport for hardy? Bug #252777
[21:54] <infinity> kirkland: Why do this:
[21:54] <slangasek> emgent: "when I have time", yes, but pitti has his archive day tomorrow, and that's probably before I have time
[21:54] <infinity> +		pidofproc -p $SMBDPID $DAEMON >/dev/null
[21:54] <infinity> +		status=$?
[21:54] <emgent> ok Thanks slangasek
[21:54] <infinity> kirkland: If you did it with "if pidofproc -p $SMBDPID $DAEMON >/dev/null; then", it would work for a "set -e" script too.
[21:55] <kirkland> infinity: b/c pidofproc doesn't do the log_success_msg() and log_failure_msg()
[21:55] <slangasek> infinity: well, we know that the smbd script isn't set -e
[21:55] <infinity> slangasek: Yeah, but I assume he has boilerplate here.
[21:55] <infinity> (And I write set -e init scripts)
[21:55] <infinity> kirkland: No, no.  "if pidofproc foo; then log_msg; else log_msg; fi"
[21:56] <slangasek> infinity: true LSB init scripts aren't allowed to be set -e \o/
[21:56] <infinity> kirkland: Has the same effect as testing if status is "0", which is the very next thing you do. :)
[21:56] <kirkland> infinity: please point me to what you're looking at specifically
[21:56] <infinity> slangasek: Seriously?  All my shell is set -e, usually.  To protect myself from bad coding, more than anything.
[21:56] <infinity> kirkland: http://patches.ubuntu.com/s/samba/samba_2:3.2.0-4ubuntu1.patch, the init script part of the patch.
[21:57] <slangasek> infinity: the LSB init script spec is full of win; it explicitly prohibits use of set -e with the /lib/lsb/init-functions
[21:57] <slangasek> (I've tried sneering at the LSB maintainers in Debian until they provided an implementation that *is* safe under -e, but it's possible this has not been a wholly successful strategy)
[21:58] <kirkland> infinity: that patch is out of date
[21:58] <kirkland> infinity: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/247087
[21:58] <infinity> kirkland: Though you would lose the return of pidofproc that way, which I suppose you want.
[21:58] <kirkland> infinity: this is the latest revision: http://launchpadlibrarian.net/16367257/samba.247087.debdiff
[21:59] <infinity> kirkland: Ahh, I see you fixed it with || status=$? ... That resolves my whine. :)
[21:59] <kirkland> infinity: ;-)  wanna sponsor that upload then?  :-P
[22:02] <infinity> slangasek: I suspect I don't actually have to tell you how I feel about that.  Meh.
[22:02] <infinity> slangasek: I mean, I can see the argument that init scripts aren't always the ideal place to use set -e, but I want the option available, should I be the sort of pedant who prefers to be strict.
[22:03] <infinity> kirkland: Yeah, I might be able to be convinced to do that.
[22:03] <infinity> kirkland: I do have a mushroom next to my name in LP, after all.
[22:04] <kirkland> infinity: ;-)  well, it's been hanging around in the sponsor queue for a couple of weeks now
[22:04] <kirkland> infinity: everytime i think of it, it seems like the archive is frozen for alpha-spinning ;-)
[22:04] <infinity> kirkland: I never check those things anymore, since I'm not technically on distro... But I'm happy to sponsor things that look "obviously correct" to me.
[22:05] <infinity> kirkland: And this (for pedants like me) is an obvious improvement. :)
[22:05] <kirkland> infinity: woohoo!
[22:05]  * infinity sets vorlon's init script to -e while he's in there and watches it asplode.
[22:05] <kirkland> infinity: i was beginning to wonder if I was the *only* person who sees value in 'status' actions in init scripts in the Ubuntu community
[22:06] <infinity> kirkland: I don't care one way or the other, but it's already THERE in samba, and your new patch is better, IMO.
[22:06] <kirkland> infinity: oh, i see your view now
[22:06] <kirkland> infinity: yes, clearly better than before
[22:06] <kirkland> infinity: which was better than nothing ;-)
[22:07] <slangasek> infinity: well, I was happily using set -e in all my init scripts before the LSB helpers came into vogue; then it became prohibitive
[22:07] <kirkland> *slangasek is easily kirkland's favorite LSB-hater
[22:07] <slangasek> heh
[22:08] <slangasek> I don't hate the LSB, just the parts of it that didn't come from Debian policy
[22:08] <slangasek> ;-)
[22:08] <Nafallo> haha
[22:08] <infinity> I always disliked the "pretty init scripts for the sake of prettiness" thing, though you'll find my name in a LOT of changelogs in Ubuntu adding such prettiness, since it was part of my job.
[22:08] <infinity> But when that prettiness comes at the cost of error checking, I'm even grumpier.
[22:09] <slangasek> my favorite LSBism is still the part where they tried to grandfather all known init scripts on all Linux distributions, and then declare the rest of the init script namespace reserved for LSB
[22:10] <infinity> Also, people who require cdbs, dbs, quilt, etc in clean targets need to die.
[22:10]  * infinity glares at slangasek.
[22:10]  * Mithrandir ruffles the angry man
[22:10] <infinity> (peloy's fault?)
[22:10] <slangasek> infinity: feel free to rebuild it as a v2.0-quilt package instead ;)
[22:11] <infinity> kirkland: Uploaded.
[22:11] <slangasek> infinity: if you're using a patch system, it needs to be used in the clean target; I'm not going to duplicate quilt logic in the debian/rules themselves
[22:12] <kirkland> infinity: many thanks
[22:12] <infinity> slangasek: I know.  I'm still a slave to the "ZOMG, simple" patch system we used in PHP, even if it wasn't perfect.
[22:13] <slangasek> yeah, I think that was the one that drove me into quilt's open arms
[22:13] <slangasek> :)
[22:13] <infinity> slangasek: And, actually, that's not entirely true.  If you use the brute-force "create a build-tree, then patch it" method, clean can just be "rm -rf build-tree".
[22:13] <slangasek> well, perhaps
[22:14] <infinity> The only real problem PHP's system had was it's lack of forgiveness for fuzziness... Which I actually came to appreciate, because it forced me to re-evaluate patches on new upstream releases and make sure they were still useful.
[22:15] <slangasek> the other problem it had was that it didn't have quilt push -f && quilt edit && quilt refresh
[22:15] <infinity> (And I got insanely good at hand-editing diffs...)
[23:34] <TheMuso> kees: No. Usplash runs on tty8, all messages echoed to the console are on tty1. When you boot without splash, you are on tty1 anyway, so unless a change to tty1 is made when usplash quits, only the initramfs prompt will be seen, and you have to switch to tty1 to see any errors you get, and then have to switch back to tty8 just to type commands.
[23:35] <kees> TheMuso: heh, okay.  so the messages echo'd by the fail hooks will still be visible?
[23:36] <TheMuso> kees: If one ends up panicking, yes, but if things boot, the need for showing them is not necessary I guess, unless you want to show them within usplash.
[23:36] <kees> nah, no need for it to show up in usplash.
[23:36] <TheMuso> As in letting the user know that an array is degraded, even if they use that command-line argument kirkland added.
[23:36] <kees> mdadm will yell at them after they're booted
[23:37] <TheMuso> kees: Yeah I thought as much.