[01:18] <doko__> broken eglibc on powerpc :-(
[01:19] <ArneGoetje> cjwatson: new packages uploaded, thanks for the heads up.
[01:20] <cjwatson> ArneGoetje: great, thank you
[02:06] <kirkland> slangasek: hiya, around?
[02:06] <slangasek> kirkland: hi
[02:06] <kirkland> slangasek: hi there, i just uploaded eucalyptus_1.6.2~bzr1120-0ubuntu2_source.changes
[02:06] <kirkland> slangasek: when does the next ISO build trigger?
[02:07] <slangasek> kirkland: in 8h
[02:07] <kirkland> slangasek: okay, could i schedule a server build in about 4 hours?
[02:08] <kirkland> slangasek: ttx asked that i make sure a new ISO is built with my changes before his morning
[02:08] <slangasek> kirkland: schedule one, or have me schedule one?
[02:08] <kirkland> slangasek: i don't think i can
[02:08] <kirkland> slangasek: i suppose i'm asking you to do so, on my behalf :-)
[02:08] <slangasek> ok
[02:08] <kirkland> slangasek: is that something you can do for me?
[02:08] <slangasek> yeah, I can make sure that happens
[02:08] <kirkland> slangasek: thanks
[03:07] <crimsun> TheMuso: PA patches of doom pushed upstream
[03:09] <crimsun> hyperair: FWIW, 1.0.22.1 (which contains my powerdown work) is slated to be merged into linux-backports-modules-2.6.31, so you'll be able to get it linux-backports-modules-alsa-$(uname -r), too
[03:09] <crimsun> bah, missing preposition
[03:21] <crimsun> ScottK: what was the surrounding context for slicer FTBFS that you mentioned a couple days ago?
[03:22] <crimsun> some invalid const char * conversion, I think?
[03:22] <ScottK> crimsun: Nothing major, just I saw you'd uploaded a new vtk and started checking what might be buildable.  Yes.
[03:22] <crimsun> drat, -ECHANNEL
[03:22] <ScottK> I retried it on i386 after your last vtk upload and it failed again.
[03:22] <crimsun> ok, I look
[03:47] <TheMuso> crimsun: Just saw that thanks, will do that myself in the future.
[03:58] <TheMuso> /c/c
[04:03] <hyperair> crimsun: i see. but i use a custom kernel so i guess i won't be seeing it for some time
[04:03] <persia> hyperair: Well, you could pull the -sru source and recustomise :)
[04:03] <hyperair> heh
[04:04] <hyperair> it's actually a kernel from git
[04:04] <hyperair> the zen kernel
[04:04] <hyperair> got a bunch of cool stuff like phc, tuxonice, and bfs =)
[04:05] <crimsun> you could just use alsa-source from Lucid and m-a
[04:05] <hyperair> modules-assistant?
[04:06] <crimsun> in any case, it isn't enabled for your codec (I don't think, let me check)
[04:06] <hyperair> ah
[04:06] <hyperair> say, we still use m-a? i thought everything was dkms nowadays.
[04:07] <crimsun> if we is Debian pkg-alsa, yes
[04:07] <hyperair> O_o
[04:07] <crimsun> no one has committed the dkms bits yet
[04:07] <hyperair> i see
[04:09] <crimsun> hyperair: is your ssid 0x1744384e? (see lspci -nv|grep -A1 0403)
[04:09] <crimsun> sorry, 0x17aa384e
[04:10] <hyperair> 00:1b.0 0403: 8086:284b (rev 03) Subsystem: 17aa:384e
[04:10] <hyperair> what's this ssid?
[04:10] <Claviceps> you will probably get a Unknown device error
[04:10] <Claviceps> rev02
[04:10] <hyperair> huh?
[04:11] <Claviceps> you are trying to point and get PCI bus information arent you?
[04:13] <crimsun> hyperair: http://pastebin.com/d179ba213
[04:13] <crimsun> hyperair: you'll need to apply that on top of 1.0.22.1
[04:13] <crimsun> I'm turning on the powersavings for Realtek codecs quirk by quirk
[04:14] <Claviceps> try executing pciconf -l
[04:14] <Claviceps> or dmesg
[04:14] <Claviceps> to get the kernal message
[04:15] <hyperair> Claviceps: er
[04:15] <crimsun> hyperair: ssid is given in the "Subsystem" section
[04:15] <hyperair> ah
[04:15] <Claviceps> ohhh HELL nooo
[04:15] <hyperair> Claviceps: no i don't get any unknown device error or anything.
[04:15] <Claviceps> wikipedia.en
[04:16] <Claviceps> did you check the libpci ?
[04:16] <Claviceps> make sure all devices are listed therwe
[04:16] <crimsun> Claviceps: what are you on about?
[04:17] <Claviceps> I dont EVEN LIKE COMPUTERS
[04:17] <Claviceps> but fishing is a dying industry
[04:18] <Claviceps> you have an answer to that NIGGA
[04:19] <Claviceps> check all the pcids
[04:19] <Claviceps> pciids
[04:21] <hyperair> looks like we've an annoying new bot
[05:23] <joshua___> Any way to convince sulogin to not ever ask for a password
[05:23] <persia> joshua___: That sort of question is better asked on #ubuntu (and the answer is available by running `man sulogin` )
[05:24] <joshua___> I read the man page. Why do you think I'm in devel?
[05:25] <persia> Well, it's in the fourth paragraph :)
[05:26] <joshua___> Look guys after trying sudo for one year I gave it up.
[05:47] <superm1> glatzor, ping re the gtk python-aptdaemon stuff.  is there no way to make a blocking run() call anymore?
[05:48] <superm1> or if there is, I think i'm just missing the proper way to do it
[05:48] <lifeless> how should debug autosyncs not happening?
[05:48] <lifeless> s/should/should one/
[05:49] <persia> lifeless: You've confirmed that something was present in Debian testing (main) at the time of the autosync, that it's not NEW, and that there's no Ubuntu package with that name that might block it?
[05:50] <Claviceps> I HAVE BEEN FIGHTING THIS BULLSHIT MY ENTIRE LIFE
[05:50] <Claviceps> with worse odds than me vs ali in a boxing ring
[05:50] <glatzor> superm1, hello. you are right. currently the wait statement in the aptdaemon.client.AptClient isn't supported
[05:51] <glatzor> superm1, if you are writing a GTK application I would encourage connecting to the signal
[05:51] <glatzor> superm1, to the finished signal of the transaction
[05:51] <lifeless> persia: well, I'm not sure where to find the autosync run time
[05:51] <superm1> glatzor, unfortunately i'm getting weird behaviors when I connect to that signal versus running the function directly from the application
[05:51] <lifeless> persia: I have a package (testresources) that is out of date in Ubuntu, current in testing
[05:52] <glatzor> superm1, see http://bazaar.launchpad.net/%7Eglatzor/update-manager/ubuntu-glatzor/annotate/head%3A/UpdateManager/backend/InstallBackendAptdaemon.py
[05:52] <superm1> glatzor, i'm doing some stuff with a policykit check that i'm suspecting isn't working when invoked that way
[05:52] <glatzor> superm1, could you point me to your code?
[05:53] <StevenK> lifeless: The autosyncer is run manually. I can kick one off now, if you wish
[05:53] <lifeless> StevenK: sure
[05:53] <superm1> glatzor, sure give me a sec to push up my latest iterations of trying to sort it out
[05:53] <maco> StevenK: "auto... run manually" *blink*
[05:53] <persia> lifeless: I usually scan through https://launchpad.net/ubuntu/lucid/+queue?queue_state=2 to find a batch of packages with Debian revisions uploaded near the same time (in this case about 2 hours ago).
[05:54] <glatzor> superm1, you should not have to care about policykit on the client side (except e.g. that you want to disable buttons)
[05:54] <StevenK> maco: It's auto in the way that it will automatically pull in everything that doesn't have Ubuntu changes.
[05:56] <superm1> glatzor, so if you take a look at lp:~mythbuntu/mythbuntu/mythbuntu-control-centre and the file ./mythbuntu-control-centre, summaryApply is what invoke's the commit.  if you have a set of changes that require more beyond that commit, summaryApply is called again as the handler to run those other changes.  it works when called with no commit changes, but fails when it's invoked through the signal handler
[05:56] <Hobbsee> Claviceps: please put your offtopic discussions to somewhere like #defocus, not here
[05:57] <Claviceps> okay..
[05:58] <Claviceps> i GUESS you DIDNT get the POINT??
[05:59] <lifeless> Claviceps: you are being disruptive, are talking about things not relevant for this channel. Please stop - as Hobbsee says #defocus would be a better channel.
[05:59] <Claviceps> alright..
[05:59] <Claviceps> yes you are right. this is off topic..
 what's this ssid? <-- for reference, the ssid is the " Subsystem: 17aa:384e" part of that output
[06:00] <maco> hyperair: oh. crimsun said that already. i should read further before answering questions i think werent answered. oops
[06:00]  * maco shuts it
[06:03] <glatzor> superm1, does it segfault? do you have got a traceback?
[06:04] <superm1> glatzor, unfortunately it just hangs and won't respond to ctrl-c anymore in the terminal
[06:04] <superm1> traceback would be nice, i'd have a bug to directly file :)
[06:07] <superm1> but it does get as far as using the dbus activation to open up mcc-backend
[06:07] <glatzor> superm1, line 299 does not work this way. If commit_packages is called async it will not return the transaction instance
[06:08] <superm1> glatzor, ah yeah, that's the next thing i was going to try to sort out (but that used to work when things were called synchronously)
[06:08] <glatzor> superm1, you can still make sync dbus calls
[06:09] <glatzor> superm1, just skip the reply_handler and error_handler
[06:10] <glatzor> superm1, sorry. I just see that this is not documented in the module.
[06:10] <glatzor> superm1, if you using async dbus calls adds to much complexity to your application you can use sync calls
[06:11] <superm1> glatzor, yeah i certainly wasn't aware of that. if i skip using reply_handler and error_handler (i'm guessing it's just providing None as an argument), how do I handle errors that are raised in those scenarios?
[06:11] <glatzor> superm1, the method call will just raise an exception
[06:12] <superm1> works for me
[06:12] <glatzor> superm1, you can catch it using a try|except pair
[06:12] <superm1> glatzor, that's much more ideal for my usage anyway. thanks, i'll run with that and see if I can get things back in working order then
[06:23] <dholbach> good morning
[06:34] <StevenK> lifeless: All done.
[06:36] <lifeless> StevenK: did it pick up testresources?
[06:37] <StevenK> lifeless: Sure did, it'll build in a few hours.
[06:37] <lifeless> cool, thanks.
[06:37] <lifeless> [and I just uploaded a new release to debian :P]
[06:38] <StevenK> So we're going to have the same discussion tomorrow? :-)
[07:04] <hyperair> maco: :-)
[07:20] <pitti> Good morning
[07:24] <siretart> hi pitti
[07:24] <alkisg> Would anyone care to sponsor a MIR for libsdl1.2debian-pulseaudio? It would be the first step in solving LP #203158 (the second one being, changing the seeds)
[07:24] <pitti> hey siretart, gesundes Neues!
[07:25] <siretart> pitti: danke! dir ebenfalls! ;-)
[07:25] <siretart> pitti: is there anything left to do with the yasm MIR? you set the status to fix committed before christmas, but it is still in universe
[07:26] <pitti> siretart: oh, it's on component-mismatches now
[07:26] <pitti> siretart: promoted
[07:26] <siretart> yes, I've uploaded a ffmpeg (main) that build depends on it
[07:26] <siretart> thanks! :-)
[07:27] <siretart> this means I can start the symbol versioning transition now :-)
[07:28] <siretart> although I feel a bit uncomfortable that upstream hasn't applied my patch yet, and I first need to fix my car today...
[07:50] <DktrKranz> mvo: thanks for merging the fixes! I have some minor ones too, I'll prepare a branch for them later.
[07:50] <twb> I'm using pbuilder the roll some private packages for Hardy, but I'd like to be able to use debhelper >= 7~ from hardy-updates.
[07:51] <twb> How do I tell pbuilder to include hardy-updates ?
[07:52]  * twb tries --othermirror
[07:52] <DktrKranz> mvo: I also saw Debian version overwrote Lucid one, main difference is it no longer passes --always-ask-pass to gksu, I asked to blacklist it, in order to avoid such inconvenieces in the future.
[08:04] <mvo> DktrKranz: thanks, let me know when the branch is ready
[08:04] <mvo> DktrKranz: maybe we can make the --ask-pass a runtime detection, it would be nice to have the same source in debian and ubuntu
[08:05] <mvo> DktrKranz: or I need to nag kov to take the patch for it :)
[08:06] <DktrKranz> mvo: oh, nice idea. I'll try to address that too
[08:07] <mvo> many thanks
[09:11] <lool> geser, dholbach: Thanks for the pbuilder mere
[09:11] <lool> merge
[09:11] <dholbach> heya lool - I just reviewed and uploaded it :)
[09:12] <lool> Well thanks for reviewing and uploading it  :-)
[09:12] <dholbach> :)
[09:12]  * dholbach hugs lool
[09:12]  * lool hugs dholbach 
[09:13]  * mneptok takes photos for his later "personal use"
[09:14] <maco> mneptok: you know there's a video of like 20people+dholbach hugging on youtube, right?
[09:15] <mneptok> maco: dependning on its vintage, i may well be one of those 20
[09:15] <mneptok> maco: and i haven't showered since.
[09:15] <maco> mneptok: the surprise group hug a few udses ago
[09:15] <maco> ah that explains the smell at uds dallas
[09:15] <mneptok> Prague, i think
[09:18]  * mneptok tootles off to bed.
[09:18] <mneptok> early confcall. bleh.
[11:13] <ScottK> pitti: Would you please rescore kdeadmin on amd64.  It's the last package I need to declare KDE 4.2.4 done in karmic-backports and we're holding an announcement for it.  At the rate the queue is going, it may be days before it gets a try ....
[11:15] <pitti> ScottK: done
[11:24] <ScottK> pitti: Thanks.
[12:27] <asac> cjwatson: what would be the best way to check for what packages (in main) have not yet been rebuild in lucid?
[12:28] <seb128> asac, compare karmic and lucid versions?
[12:28] <seb128> should be a few python-apt line
[12:28] <seb128> lines
[12:29] <asac> yeah. could have been we already have something for that ;)
[12:29] <seb128> could be, I don't know though
[12:31] <cjwatson> asac: lp:~cjwatson/+junk/suite-diff
[12:36] <asac> cool ... checking
[12:44] <CAiRO> hi
[12:44] <CAiRO> i'm just trying to compile a package from source and it fails with the error "tail: cannot open `debian/changelog' for reading: No such file or directory"
[12:44] <CAiRO> i can see there's only a changelog.in file
[12:44] <CAiRO> the real changelog file probably has to be generated from the changelog.in file, but how do i generate it?
[12:45] <cjwatson> changelog is traditionally written by hand, not generated. if you have a changelog.in then your package is Weird and we would need to see a concrete example rather than guessing
[12:47] <CAiRO> cjwatson: the package is sawfish http://sourceforge.net/projects/sawmill/files/sawfish/1.6.0/sawfish-1.6.0.tar.bz2/download
[12:49] <cjwatson> CAiRO: wait a sec, you're relying on debian/* files in the upstream source?
[12:50] <CAiRO> cjwatson: yes, i am
[12:50] <CAiRO> cjwatson: worked fine so far with the other 2 libs
[12:51] <cjwatson> CAiRO: I wouldn't bother. Pretend it didn't have any debian/* files and compile it in the usual upstreamish way
[12:54] <CAiRO> cjwatson: well, then i'd rather make up the changelog file myself
[12:54] <CAiRO> its always better to have a deb package with dependencies etc.
[12:55] <cjwatson> CAiRO: it's clearly intended for daily builds or some such, it's not a proper changelog
[12:55] <cjwatson> CAiRO: you could attempt to merge the .diff.gz from the Ubuntu archive
[12:59] <CAiRO> cjwatson: well, it says the package is the latest stable version.. and there is some debian unstable package for it
[12:59] <CAiRO> anyway, i managed to copy and extend the changelog file from the original sawfish 1.3.1 ubuntu package
[12:59] <CAiRO> so now its working
[13:01] <CAiRO> great thing, this update fixes all my problems with sawfish, yeah :)
[13:02] <CAiRO> the coolest thing is that you can bind mouse buttons to things like "move window interactively".. its the same as in metacity with alt + middle mouse button.. except that i can use my mouse button 8
[13:02] <CAiRO> without any keys..
[13:02] <CAiRO> same goes for resize etc./
[13:26] <zul> doko: ping
[13:53] <zul> james_w: it looks like samba failed the bzr import can you have a look?
[13:53] <james_w> yep
[13:59] <happyaron> anybody can help on coverting docbook to pdf?
[14:36] <ttx> cjwatson: please have a look at https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/503339
[14:36] <ttx> cjwatson: it's due to a failure to fetch the CLC preseed file at install time
[14:37] <ttx> wget.gnu: error while loading shared libraries: libssl.so.0.9.8: cannot open shared object file: No such file or directory
[14:37] <cjwatson> ttx: ok, will investigate once I've finished upgrading to lucid
[14:37] <ttx> cjwatson: I guess adding libcrypto0.9.8-udeb to eucalyptus-udeb "Depends" would not provide the right file...
[14:37] <ttx> cjwatson: sure :)
[14:38] <cjwatson> eucalyptus-udeb is the wrong place to fix this
[14:38] <cjwatson> it does not have a direct dependency on libssl itself
[14:38] <ttx> I'll assign the bug to you then, feel free to look at it when you have some time.
[14:40] <dholbach> did anybody else have spontaneous reboots on lucid?
[14:40] <ttx> dholbach: I had spontaneous reboots on karmic.
[14:40] <dholbach> it might be just my hardware that's unhappy, but I'm wondering
[14:40] <pitti> not so far
[14:41] <dholbach> http://paste.ubuntu.com/351799/ is the last things that happened afaics
[14:42] <dholbach> but it doesn't really say much, does it?
[14:47] <joaopinto> dholbach, is that mountall-shell expected to be running at that time ?
[14:47] <dholbach> joaopinto: I have no idea
[14:48] <dholbach> I certainly didn't run it myself :)
[14:48] <ev> bryce_, Riddell: are you aware of any plans to implement BulletProofX for KDE, or plans to refactor the existing code so it's not so tied to GDM?  I'm investigating support for it in oem-config and only-ubiquity mode on the live CD.
[14:49] <Riddell> ev: in theory that got implemented ages ago but I havn't tested it recently and I don't know if it still works
[14:50] <ev> I just tried creating a broken xorg.conf on the kubuntu live CD (in the initramfs) and I ended up at a shell.
[14:51] <ev> so I'd wager not ;)
[14:51] <Riddell> guess not then
[14:51] <joaopinto> dholbach, looking from mountall-shell.conf, mountall-shell was expected to be started only if manual recovery was required
[14:52] <dholbach> joaopinto: I ran it in the boot before because I a filesystem was dirty after a previous "spontaneous reboot"
[14:52] <joaopinto> ah ok, so is not a cause, it's a result :P
[14:54] <dholbach> joaopinto: I rebooted after the recovery boot
[15:07] <sbalneav> mvo: Thanks for #501559
[15:07] <mvo> sbalneav: no problem :)
[15:10] <jetsaredim> what is the easiest way to update a deb to adjust the makefile options?  obviously not for merging into ubuntu, but for my own personal use
[15:11] <cjwatson> get the source package, edit debian/rules which typically calls make somewhere
[15:22] <dholbach> GAR, it rebooted again :-/
[15:22] <dholbach> http://paste.ubuntu.com/351822/ this time
[15:22] <dholbach> can somebody enlighten me about mountall-shell?
[15:39] <pitti> dholbach: probably only Keybuk
[15:39] <dholbach> pitti: I see
[15:39] <dholbach> it's a bit unpleasant if the machine just restarts like that :/
[15:40] <joaopinto> dholbach, assuming mountall-shell is the cause, tere is a reboot call on the post-stop script
[15:41] <joaopinto> don't trust me, but I c
[15:41] <dholbach> joaopinto: hum... what does that mean?
[15:41] <joaopinto> I guess you could mv /etc/init.d/mountall-shell.conf /etc/init.d/mountall-shell.conf.disable
[15:42] <joaopinto> but make sure your filesystems are clean first :P
[15:44] <joaopinto> well, better wait for KeyBuck, I am just wondering
[15:46] <cwillu_at_work> dholbach, I believe the intent is to handle the rebooting after an automatic fsck, what's the context?
[15:47] <pitti> aaah
[15:47] <pitti> dholbach: perhaps there's a long-running fsck in the background, and once that finishes, it reboots?
[15:47] <pitti> perhaps for a /media partition or so (which the booting doesn't wait on)
[15:47] <cwillu_at_work> pitti, hmm, that's sound like a possibility
[15:48] <cwillu_at_work> /etc/init/mountall-reboot fires on stopped mountall EXIT_STATUS=4
[15:48] <cwillu_at_work> (tell me to shut up if I'm not being at all relevant :p)
[15:48] <joaopinto> isn't the mainteance shell supposed to be interactive ?
[15:48] <dholbach> there's no fsck running right now
[15:48] <pitti> seems that everyone contributes a piece to a puzzle, so just keep going :)
[15:49] <dholbach> and there's only sda1, so that'd surprise me :)
[15:49] <cwillu_at_work> dholbach, can you repeat yourself for me?  what are you seeing?
[15:49] <pitti> joaopinto: yes, but if X.org and getty are running, it probably doesn't even have a console to work on?
[15:49] <pitti> dholbach: ok, so that's not it
[15:49] <joaopinto> dholbach, is mountall-shell running ?
[15:49] <dholbach> cwillu_at_work: my machine was restarting a couple of times without me doing anything
[15:49] <pitti> brb
[15:49] <dholbach> http://paste.ubuntu.com/351822/ is the last part of the syslog before restarting
[15:50] <joaopinto> I mean, after a clean reboot
[15:50] <dholbach> http://paste.ubuntu.com/351799/ is what happened before
[15:50] <dholbach> joaopinto: let me restart again and check
[15:50] <cwillu_at_work> mountall-shell -> start on (stopped mountall EXIT_STATUS=[!4] or stopped mountall EXIT_SIGNAL=?*)
[15:51] <cwillu_at_work> the post-stop script would fire the reboot
[15:51] <joaopinto> the mountall-shell should be running only if there was a failed mount
[15:51] <joaopinto> cwillu_at_work, that is were I was looking at :)
[15:52] <dholbach> joaopinto: not running right now after the reboot
[15:52] <dholbach> let's see when the machine is going to restart itself again :)
[15:52] <joaopinto> dholbach, is mountall running ?
[15:53] <dholbach> joaopinto: nope
[15:53] <cwillu_at_work> dholbach, pastebin initctl list
[15:53] <joaopinto> ok, so I don't see how the recovery shell could be triggered at this time
[15:54] <dholbach> http://paste.ubuntu.com/351836/
[15:54] <cwillu_at_work> joaopinto, wait for the paste :p
[15:54] <cwillu_at_work> mountall-shell start/running, process 1505
[15:54] <joaopinto> that looks bad :P
[15:55] <cwillu_at_work> dholbach, does it immediately reboot if you "stop mountall-shell"?
[15:55] <dholbach> but "ps afxvw" does not show mountall-shell
[15:56] <cwillu_at_work> dholbach, you wouldn't, it's upstart running a shell
[15:56] <cwillu_at_work> dholbach, look for sh's
[15:56] <dholbach> ahhh
[15:56] <dholbach> /bin/sh -e /dev/fd/8
[15:56] <cwillu_at_work> specificially process 1505 15051505:p
[15:56] <cwillu_at_work> bah, too many 1505's
[15:57] <dholbach> yes it does immediately restart
[15:58] <cwillu_at_work> I think I want you to do something with initctl log-priority, but I don't know what :p
[15:58] <dholbach> hm
[15:58] <dholbach> that sucks :/
[15:59] <cwillu_at_work> dholbach, add "initctl log-priority debug || true" in /etc/init/mountall.conf's script
[15:59] <ion> dholbach: mountall-shell is started in the first place because mountall fails for some reason. Please change /etc/init/mountall.conf to exec mountall --debug --daemon $force_fsck $fsck_fix >/dev/mountall.log 2>&1
[16:04] <dholbach> ion: http://paste.ubuntu.com/351841/
[16:07] <ion> dholbach: Dunno then... It seems /dev/mapper/cryptswap1 never appears, but that shouldn’t be related to this problem.
[16:08] <dholbach> thanks a lot for helping out, ion
[16:09] <joaopinto> even if there is a mountall failure there is another issue with mountall-shell which should be running on a VT
[16:11] <ion> Ah, now that i took a better look at mountall-shell.conf, mountall failure doesn’t seem probable after all.
[16:12] <ion> dholbach: Try adding ‘exec >/dev/mountall-shell.log 2>&1; set -x’ in front of the script part in mountall-shell.conf
[16:15] <dholbach> ion: where? the line before "script"?
[16:15] <ion> dholbach: A new line just after ‘script’
[16:15] <dholbach> ah ok
[16:15] <joaopinto> I am not familiar with upstart, but isn't mountall-shell being started on exit status 0 ?
[16:15] <ion> Sorry for being ambiguous
[16:16] <dholbach> ion: after "end script"?
[16:17] <ion> dholbach: Might as well add ‘echo "EXIT_STATUS: $EXIT_STATUS, EXIT_SIGNAL: $EXIT_SIGNAL"’ after the exec and set -x. I mean, add these as new lines between the ‘script’ line and the ‘    case "$EXIT_STATUS" in’ lines.
[16:18] <dholbach> ion: I don't have that case EXIT_STATUS line
[16:18] <cwillu_at_work> dholbach, it starts in the cases where mountall-reboot doesn't
[16:18] <ion> dholbach: In mountall-shell.conf?
[16:18] <cwillu_at_work> but my understanding is incomplete because I don't see why one of those isn't always true
[16:19] <dholbach> ion: yes
[16:19] <ion> dholbach: Please pastebin your mountall-shell.conf. Which version of the mountall package do you have?
[16:20] <dholbach> 2.3
[16:21] <dholbach> http://paste.ubuntu.com/351846/
[16:21] <ion> That’s mountall.conf :-)
[16:22] <dholbach> urgh
[16:22] <dholbach> excusez-moi
[16:26] <ion> dholbach: Oh, i just realized redirecting stdout and stderr might contaminate the analysis, since sulogin might behave differently in that case.
[16:29] <ion> dholbach: This should run sulogin with the original file descriptors, but if you’re already taking a log, let’s take a look at it first. http://pastebin.com/f11f6a2e5
[16:31] <dholbach> http://paste.ubuntu.com/351853/ is what I got now
[16:31] <ion> How about /dev/mountall-shell.log?
[16:32] <dholbach> http://paste.ubuntu.com/351854/
[16:33] <ion> Huh. it seems mountall died with SIGABRT but didn’t print an error message.
[16:33] <cwillu_at_work> update_mount: /sys/kernel/debug: /sys/kernel/debug none debugfs optionmountall:mountall.c:1296: Not reached assertion failed in mountedall
[16:34] <ion> cwillu: Good catch!
[16:34] <cwillu_at_work> ion, it's the longest line in the log :p
[16:35] <ion> Yeah, i just looked at the very end blindly to the rest, not realizing the flushing of stdout and stderr or something like that might cause that.
[16:39] <ion> dholbach: Ok, i think i see the problem in mountall.c
[16:40] <dholbach> ion: is there anything I can do for now?
[16:41] <cwillu_at_work> dholbach, just disable the shell script will work, or comment out the umount -a ; exec reboot -f lines
[16:43] <dholbach> thanks ion and cwillu_at_work
[16:43] <dholbach> ion: will you talk to Keybuk about that problem or propose a fix for it or something?
[16:43] <dholbach> ion: I don't know what to do about it nos
[16:43] <dholbach> now
[16:43] <ion> dholbach: Yeah, i will.
[16:43] <dholbach> thanks a bunch ion
[16:44] <ion> np
[16:51] <cjwatson> superm1,pitti,ev: please note for future commits that casper is in lp:ubuntu/casper now rather than lp:caspper
[16:51] <cjwatson> lp:casper that is
[16:51] <pitti> ah, thanks; me updates his branch
[16:52]  * ev does the same
[17:12] <superm1> cjwatson, what is lp:casper then?
[17:12] <cjwatson> superm1: it has in big letters on it "use lp:ubuntu/casper instead" so I assume it's just hard to delete or something
[17:13] <cjwatson> we can always try to keep them in sync somehow I suppose, but we definitely want to get to the invariant where lp:ubuntu/<package> works for all packages in Ubuntu so please try to avoid writing to lp:casper
[17:16] <robbiew> james_w: should we have kerneloops enabled by default during Alpha/Beta releases?
[17:17] <pitti> IMHO we should enable apport and kernelopps for alpha-2
[17:17] <pitti> (and perhaps we can get a kernel fix to unbreak signal crashes as well again)
[17:18] <james_w> robbiew: aha! we discussed that this morning
[17:18] <robbiew> :)
[17:18] <james_w> I'll renable when apport is, unless the kernel team want something different?
[17:18]  * robbiew had an oops when messing with his bluetooth headset sound settings ;)
[17:18] <robbiew> james_w: I'll check with pgraner
[17:18] <james_w> thanks
[17:19] <pitti> seb128: I'd like to enable apport now, so that we can get at least python and kernel crashes (won't work yet for sigsegv due to kernel bug); ok for you?
[17:19] <seb128> pitti, it's early to my taste but if you think it's useful...
[17:20] <robbiew> james_w: actually...their weekly meeting is going on now
[17:20] <robbiew> so I'll try to ask there ;)
[17:20] <superm1> cjwatson, i thought there was a way to mark a branch as pointing to something at lp:<PROJECT> ?  Is it maybe the project driver at launchpad.net/casper needs to set the development focus to the right branch?
[17:20] <cjwatson> superm1: I don't think project and distribution branches get to meet
[17:20] <cjwatson> unfortunately
[17:20] <pitti> seb128: you don't want it for alpha2?
[17:20] <superm1> oh shame :(
[17:20] <robbiew> james_w: got a response..."(11:20:16 AM) pgraner: robbiew: yep, should go off for rc"
[17:21] <seb128> pitti, I'm not sure, starting early means adding thousand of crash bugs that we will never look at
[17:21] <seb128> because that will be too many of those, new versions coming, etc
[17:21] <pitti> that's fine
[17:21] <seb128> well it adds to the "not able to work on our bug lists anymore"
[17:22] <pitti> we should only look at the ones with many dupes anyway (at least initially)
[17:22] <james_w> cjwatson: we can point lp:ubuntu/casper at lp:casper, it will just cause some fun when we branch for manic
[17:22] <pitti> seb128: ok, so when do you think is a better time? beta-1?
[17:22] <seb128> if only we had a good way to get notified about those...
[17:22] <ion> dholbach: https://code.edge.launchpad.net/~ion/ubuntu/lucid/mountall/lucid should contain a fix. I’ll mention it to Keybuk when he’s around.
[17:22] <seb128> pitti, hum, alpha3?
[17:22] <pitti> seb128: ^ I'm working on that
[17:22] <james_w> robbiew: I'm now sure what that means?
[17:22] <pitti> seb128: bug 487900
[17:23] <seb128> pitti, well I'm not opposed to enable it now if some people find those useful
[17:23] <seb128> or have time to look at those bugs
[17:23] <seb128> if we start only to look at bugs in one month because we are too busy with work items, etc now
[17:23] <cjwatson> james_w: ok, if that's possible, please do. the branches are currently identical
[17:23] <seb128> they will be outdated by then and only noise
[17:23] <robbiew> james_w: should be enabled for Alphas and Betas...then off for the Release Candidate
[17:23] <robbiew> sorry :/
[17:24] <james_w> robbiew: ok, makes sense
[17:24] <robbiew> james_w: does it make sense to note this as part of our process for when we open the next release
[17:24] <seb128> pitti, could you subscribe the package maintainer also to those or something which would made people watching the package to be notified by email?
[17:25] <james_w> I'll fix that mega-bug before I enable it, I'd rather not taunt the baying hordes once again
[17:25] <james_w> robbiew: if they would like it on as soon as the release opens then yes, it would make sense there
[17:25] <pitti> seb128: that's a good idea
[17:25] <pitti> I'd certainly appreciate this for my packages
[17:26] <robbiew> james_w: agreed...could you let slangasek know to add this to the process?
[17:26] <dholbach> ion: awesome! :)
[17:26] <pitti> seb128: OTOH, the bug already calls for tagging it "bugpattern-needed"
[17:26] <james_w> robbiew: I think it's just a wiki page
[17:26] <seb128> pitti, maybe do it only if the maintainer is in bugcontrol though
[17:26] <pitti> seb128: we could just set up filter rules to look for those, too
[17:26] <robbiew> james_w: heh...isn't it always
[17:26] <pitti> seb128: but as I said, even if I enable apport now, it's only for python and kernel oopses
[17:26] <robbiew> james_w: well then could you add it to the wiki page?
[17:28] <seb128> pitti, do it then
[17:29] <seb128> we need to find a better way to deal with bugs anyway
[17:29] <seb128> it's going to add some extra noise but very noisy or very very noisy...
[17:29] <seb128> we don't read all bugs in any case
[17:29] <pitti> right
[17:29] <james_w> robbiew: done: https://wiki.ubuntu.com/NewReleaseCycleProcess?action=diff&rev2=48&rev1=47
[17:29] <pitti> but we can get them collected and duplicated
[17:29] <pitti> seb128: I don't get bug mail for crashes, do you?
[17:29] <robbiew> james_w: thank you kind sir!
[17:30] <seb128> pitti, not until somebody makes those public
[17:30] <pitti> right
[17:30] <seb128> but as asac is saying for cycle bugs should not go to bug tracker
[17:31] <seb128> they should go to crash collector and only selected ones should be moved to bugs
[17:31] <seb128> but that's out of the scope of this discussion
[17:31] <seb128> launchpad is turning to a noise tracker
[17:31] <asac> ++
[17:31] <seb128> and we are building a new bug tracking system on it
[17:31] <seb128> ie trying to build lists of useful bugs
[17:32] <asac> maybe we could file crash bugs against a launchpad project != ubuntu and then regularly sort them by duplicates and add ubuntu tasks for those that are important?
[17:32] <seb128> well the noise issue is not specific to crashes nowadays
[17:33] <Riddell> who broke fontconfig in the builddds?
[17:33] <seb128> we just need a way to build custom bug lists from things we pick up in the noise
[17:33] <asac> what other automated filing happens now?
[17:33] <asac> or just saying there are too many bugs filed?
[17:33] <seb128> too many bad quality bugs
[17:33] <seb128> or non useful user rants
[17:34] <asac> yeah. thats true
[17:34] <asac> Riddell: fontconfig wasnt uploaded for 10 weeks
[17:34] <asac> even longer ;)
[17:34] <Riddell> right enough but "/var/lib/dpkg/info/fontconfig.postinst: 13: defoma-subst: not found" something broke it
[17:35] <seb128> defoma got uploaded
[17:35] <seb128> it's a sync from Debian though
[17:35] <james_w> we probably want to sync fontconfig too
[17:35] <asac> so fontconfig needs a merge?
[17:36] <asac> sync would be fun ;)
[17:36] <Riddell> ArneGoetje: about?
[17:38] <Riddell> actually it was TheMuso who asked for the sync
[17:39] <pitti> seb128: oh, Debian has fontconfig 2.8 now as well
[17:40] <seb128> rock on
[17:40] <asac> as well?
[17:40] <pitti> I put 2.8 into the ubuntu-desktop PPA a while ago
[17:42] <asac> ok so you can just upload that?
[17:43] <pitti> well, we have patches, it needs a merge
[17:43] <pitti> that was just a quick update to test whether it impacts boot speed
[17:44] <pitti> ArneGoetje: do you have some time to merge fontconfig and review what our remaining delta is?
[17:44] <asac> ok thoguth you already did that
[17:52] <asac> the merge will take a bit
[17:55] <asac> http://pastebin.com/f1cae287f
[17:55] <asac> i think just that might work
[17:56] <asac> at lesat it says its about:
[17:56] <asac>  emergency band-aid fix to avoid messing setup on install/remove when
[17:56] <asac> +    defoma is not installed, Closes: #559136, #560252, #559348
[18:01] <asac> someone wants to test before i upload?
[18:02] <asac> seb128: Riddell: pitti: http://pastebin.com/f30d6922   thats from upstream NMU http://pastebin.com/f1cae287f
[18:02] <asac> i have no system to test that atm. but since its broken and i wont have time to do full merge, i will just upload
[18:03] <Riddell> asac: rock
[18:03] <asac> uploaded. lets hope ;)
[18:28] <kees> python-unit pulls in X now?  odd.
[18:45] <DktrKranz> jdstrand: when you have time, mind looking at bug 485973? It seems a regression in php5.
[18:46] <jdstrand> DktrKranz: ok
[18:47] <DktrKranz> thanks
[18:53] <pitti> asac: thanks!
[18:57] <pitti> ev: sorry for the casper mess, seems I was wrong yesterday
[18:57] <pitti> ev: derivatives have an existing gdm custom.conf for setting the default session
[18:57] <pitti> ev: I'll sort it out, just FYI
[18:57] <seb128> pitti, new gdm tarball has that in the news
[18:58] <seb128> "- make --with-custom-conf work"
[18:58] <seb128> pitti, ^ not sure if that has anything to do with what you discuss there though
[18:58] <pitti> seb128: actually not, this is about enabling autologin in casper
[18:58] <seb128> I just mention it because I was reading the news of things which are to update some minutes ago
[18:58] <pitti> but good to know
[18:58] <seb128> ok
[19:08] <DktrKranz> mvo: my gdebi merge proposal is ready for review. wrt detecting presence of --always-ask-pass, it's not so easy to detect it at runtime because it's undocumented. The only workaround I can think about is checking with lsb_release, or so.
[19:27] <simple> selam
[19:27] <simple> ilk once sansimizi turkce olarak deniyelim
[19:28] <simple> sonra engilisceye vururuz kendimizi
[19:28] <simple> ubiye ntfs formatlý bi hdd takýyorum ama gormuyor
[19:28] <simple> mount etmiyor
[19:29] <highvoltage> hi simple, sorry this channel isn't for support and I doubt many people here would understand that
[19:30] <simple> saol dayi
[19:45] <Zorry> doko_: ping
[20:07] <cody-somerville> Is HAL completely deprecated in lucid yet?
[20:10] <ion> Dunno, but neither of the two desktop boxes i have have hal installed.
[20:13] <pitti> cody-somerville: it's not in the default install any more, but of course there are still tons of packages depending on it
[20:14]  * cody-somerville nods.
[20:14] <pitti> cody-somerville: it won't get removed from the archive anytime soon, if you mean that
[20:16] <cody-somerville> pitti, Do you mind if I add packages affecting Xubuntu to the Halsectomy wikipage?
[20:16] <pitti> cody-somerville: to the contrary, the more complete that page is, the better
[20:21] <mvo> DktrKranz: thanks, I have a look at the gdebi merge now
[20:23] <cody-somerville> pitti, Removing hal from the archive would be bad for Xubuntu.
[20:23] <cody-somerville> pitti, Xfce isn't as far along with the migration as gnome seems to be.
[20:24] <pitti> cody-somerville: right, nobody is proposing to remove it entirely
[20:24] <pitti> we just wanted to get rid of it from a default install
[20:24] <cody-somerville> keybuk is ;)
[20:26] <pitti> $ apt-cache rdepends libhal1|wc -l
[20:26] <pitti> 74
[20:26] <pitti> have fun..
[20:30] <charlie-tca> appears Xubuntu needs it on the desktop cd
[20:30] <charlie-tca> no
[20:31] <charlie-tca> needed it after updates when installing from the alternate cd
[20:31] <ev> pitti: ah, ouch.  Thanks for the heads up.
[20:32] <pitti> ev: uploaded already; I'll test tomorrow's daily
[20:32] <charlie-tca> What's the user name to use the desktop cd? trying to run todays version, I get a gdm login screen wanting a user name
[20:32] <pitti> charlie-tca: hm, today's works for me (but it's "ubuntu")
[20:32] <pitti> charlie-tca: yesterday's was broken
[20:33] <mvo> DktrKranz: merged, many thanks. I think the only reliable way is to use lsb-release. or we just remove this feature (or make it optional or something)
[20:33] <charlie-tca> yesterday's worked for me, today's won't
[20:33] <charlie-tca> but it is xubuntu
[20:33] <pitti> ah
[20:33] <charlie-tca> I'll try it again tomorrow, we might be a day behind on updates, then. Thanks
[20:33] <pitti> I guess the xubuntu livefs builds earlier
[20:33] <pitti> and didn't catch the casper fix yet
[20:34] <charlie-tca> I see. No problem then, as long as it is known.
[20:34] <charlie-tca> Our images are about three hours before ubuntu images, on the server
[20:35] <pitti> charlie-tca: oh, wait
[20:35] <pitti> charlie-tca: yes, I know what happened
[20:35] <pitti> charlie-tca: the casper that got uploaded an hour ago should fix it for both
[20:35] <pitti> charlie-tca: I'd appreciate if you could test tomorrow's image and verify?
[20:37] <charlie-tca> Will do that. Thanks for your time.
[20:39] <DktrKranz> mvo: I agree, I'll patch to use lsb_release now
[20:43] <mvo> many thanks DktrKranz!
[20:46] <Lure> is something wrong with i386 chroot and/or fontconfig package: I get this failure http://launchpadlibrarian.net/37455955/buildlog_ubuntu-lucid-i386.kphotoalbum_4.1.1-1ubuntu2_FAILEDTOBUILD.txt.gz
[20:51] <chrisccoulson> asac^^^
[20:51] <chrisccoulson> (not sure if you know about that) :)
[20:52] <chrisccoulson> ah
[20:52] <chrisccoulson> Lure - that issue is fixed in the latest fontconfig it seems
[20:52] <chrisccoulson> 2.6.0-1ubuntu13
[20:52] <chrisccoulson> so you will just need to try again shortly
[20:59] <Lure> chrisccoulson: thanks, will retry...
[21:24] <DktrKranz> mvo: lsb_release changes committed
[22:38] <asac> Lure: chrisccoulson: let me know if it really fixsed it. i made kind of a blind upload in the hope that this will helop ;)
[22:39] <chrisccoulson> asac - Lure's build log shows it was still using the old version i think
[22:39] <asac> kk
[22:39] <asac> lets hope
[22:45] <Lure> asac: fixed for me - retried build succeeded
[22:45] <asac> cool
[22:45] <asac> thx
[22:45] <Lure> asac: thank you
[22:45] <asac> np
[22:52] <ScottK> pitti, lamont, NCommander: Would one of you please rescore kdepim-runtime (karmic-backports).  It's lack on amd64 is breaking installs.
[22:52] <ScottK> (or any other buildd admin who happens to be reading ...
[23:42] <lamont> ScottK: on it
[23:42] <ScottK> lamont: THanks.
[23:42] <ScottK> Thanks even.
[23:42] <lamont> though fwiw, the URL for the build record is a total win... not much work to get to, but jus tsayin
[23:43] <ScottK> https://launchpad.net/ubuntu/+source/kdepim-runtime/4:4.3.4-0ubuntu1~karmic3/+build/1428284
[23:43] <ScottK> lamont: ^^
[23:43] <lamont> I see we are both equally fast :-)
[23:43] <lamont> rescored.
[23:49] <kirkland> slangasek: hi, i just manually wrote an upstart script based on an existing init script
[23:50] <kirkland> slangasek: it's in /etc/init/libvirt-bin.conf
[23:50] <kirkland> slangasek: i'd like to test it out
[23:50] <kirkland> slangasek: what else do i need to do to "register" the script, besides write it to that dir?
[23:50] <kirkland> slangasek: is there a sysctl or something?
[23:52] <kirkland> slangasek: start: Unknown job: libvirt-bin
[23:52] <kirkland> slangasek: s/sysctl/initctl/
[23:53]  * kirkland tried sudo initctl reload-configuration, to no avail
[23:56] <slangasek> kirkland: mmm, inotify is supposed to pick it up automatically
[23:56] <slangasek> kirkland: maybe it thinks your job syntax is wrong?
[23:57] <kirkland> slangasek: is there a log that would tell me that?
[23:57] <kirkland> slangasek: and can the init.d script remain there (stopped) for the time being, while I'm testing?
[23:58] <slangasek> log> probably not by default, you could bump the log priority (initctl log-priority info?), touch the job file again, and check
[23:58] <slangasek> kirkland: I can't imagine it hurts anything to have the init.d script there