[00:10] <sladen> dylan-m: good, might be best put in the bug tracker.  Perhaps phrase it that dylan-m is ignoring the passed parameter
[00:10] <sladen> dylan-m: good question, ...
[00:23] <dylan-m> sladen: Yeah, I think I will. It was fine before, but my change adds a race condition or something.
[00:23] <dylan-m> (Assuming any of our users are like me and enjoy torturing their window managers)
[00:26] <sladen> dylan-m: I get several unity crashes per day, so that's probably as a result of torturing (what I call "normal use" :-)
[00:32] <Keybuk> kees: hey
[00:33] <Keybuk> kees: I don't think it does? I think it just leaves it in mtab
[00:33] <kees> Keybuk: bug 736512. I'm scratching my head on this
[00:33] <kees> Keybuk: basically, something is putting /var/lib/ureadahead/debugfs in mtab and not removing it.
[00:33] <kees> it doesn't really seem to be either ureadahead or mountall.
[00:36] <Keybuk> yes
[00:36] <Keybuk> mountall
[00:36] <Keybuk> mountall has a function which iterates the mounted filesystems at the point / is remounted rw and puts them all in mtab ;)
[00:36] <Keybuk> that debugfs mount point is mounted at that time
[00:36] <Keybuk> so mountall sticks it in mtab
[00:36] <Keybuk> and since ureadahead is just calling mount() itself, it never removes it from mtab
[00:37] <Keybuk> now is probably a good time to have that "/etc/mtab should burn in fire" conversation
[00:37] <sladen> Keybuk: stupid question, but why is it not just a symlink to  /proc/self/mounts  ?
[00:38] <Keybuk> sladen: because /p/s/m doesn't carry any non-kernel recognised options
[00:38] <Keybuk> such as those used by a whole raft of userspace mounts (nfs, smb, fuse, etc.)
[00:38] <Keybuk> and the companion unmount tools of those generally *need* them
[00:38] <slangasek> I thought they've gotten rid of all the non-kernel options for smb now (well, cifs really)
[00:39] <Keybuk> slangasek: if they have: one down, a couple of billion to go
[00:39] <Keybuk> now /proc/self/mountinfo does carry those
[00:39] <slangasek> yep
[00:39] <Keybuk> so if you're in a patchy mood ... ;-)
[00:39] <Keybuk> Fedora have some hideous /dev/.run/mount crap I think too
[00:39] <Keybuk> I'm not sure what that's about
[00:47] <psusi> Keybuk, hey, question... you're still listed as the maintainer for usplash... it's dead right?  what should be done about the upstream project on lp?
[00:48] <Keybuk> whatever anyone wants
[00:48] <psusi> Keybuk, you're not maintaining it anymore though right, so at the very least, it shouldn't be telling people you do right? ;)
[00:48] <Keybuk> it doesn't tell people I do
[00:48] <Keybuk> it tells people I did in a previous life
[00:49] <psusi> that's not neccesarily known to people looking at the page ;)
[00:49] <psusi> let me rephrase that... it says a dead man is the maintainer ;)
[00:49] <Keybuk> there's hundreds of pages on LP like that
[00:49] <Keybuk> cf. ureadahead too
[00:49] <psusi> well, I'm fixing to batch close all bugs against it in ubuntu, was thinking of doing the same for the upstream
[00:50] <psusi> well yea, but ureadahead isn't dead...
[00:50] <Keybuk> usplash isn't dead, as long as somebody remembers it ...
[00:50] <psusi> just not found a replacement maintainer yet... probably should change that to ubuntu-dev or something
[00:50] <psusi> well, I had it dropped from the archive because it can't be installed anymore, and debian is doing the same...
[00:52] <psusi> I need to start looking over the plymouth sources again too... want to integrate uswsusp with it...
[02:12] <psusi> can you get upstart to log the stderr of a daemon somewhere?
[02:34] <hallyn> psusi: 'console output' in the .conf file should do that
[02:37] <psusi> hallyn, that lets it go to the console... I want it logged
[02:48] <broder> psusi: no, that's not currently possible without a shell redirects or something
[02:49] <broder> it's been discussed, and Keybuk indicated that he didn't think it was particularly difficult, and that it should be possible to do more or less in isolation of other upstart development without having to worry much about conflicting changes or anything
[02:53] <hallyn> psusi: ah  (i guess i misread 'somewhere')
[02:58] <hyperair> on /media/origroot type none (rw,bind,commit=0,commit=0,commit=0,commit=600,commit=600,commit=0,commit=600,commit=0,commit=0,commit=0,commit=0,commit=600,commit=600,commit=0,commit=0,commit=0,commit=0,commit=600,commit=600,commit=0,commit=600,commit=0,commit=600,commit=0,commit=0,commit=0,commit=0,commit=600,commit=600,commit=0,commit=0,commit=0,commit=0,commit=0,commit=0,commit=600,commit=600,commit=0)
[02:58] <hyperair> hmmmm
[02:58] <hyperair> something seems wrong about this
[02:59] <broder> hyperair: pm-utils remounts filesystems when you go on and off of AC power, and /etc/mtap is dumb
[03:00] <hyperair> yeah i know about the remounting bit
[03:00] <hyperair> but the mtab bit is kinda funny =p
[03:00] <hyperair> sounds like a bug somewhere
[03:01] <broder> i'd argue that the bug is that /etc/mtab isn't just a symlink to /proc/mounts :)
[03:08] <psusi> I frequently have a hanging entry in /etc/mtab for /var/lib/ureadahead/debugfs... it is unmounted during boot but the entry is still there so it shows up in df bug gets the root's details
[03:36] <broder> psusi: oh, is that what that is? kees was asking about why debugfs was mounted earlier
[07:01] <didrocks> good morning
[07:19] <cjwatson> hallyn: normally it should be 'debian/rules build && fakeroot debian/rules binary' (by definition, build doesn't require (fake)root).  What's the complaint from binary?
[07:36] <pitti> Good morning
[07:37] <ion> that
[08:07] <geser> good morning
[08:28] <abhinav-> pitti,Good monring.  Its working now. but I am not very familiar with unit testing in python.
[08:29] <abhinav-> pitti, you suggested to update test_parse_argv_apport_bug
[08:29] <pitti> abhinav-: if you do "test/run local", it should already complain
[08:30] <pitti> abhinav-: it has two test cases which check CLI arg parsing for teh full (apport-cli) and simplified (apport-bug/ubuntu-bug) case
[08:30] <pitti> abhinav-: and since you added a new option, this will be missing
[08:31] <pitti> so you mainly need to add them to the expected option dict
[08:31] <abhinav-> oh ok. got it :)
[08:32] <pitti> abhinav-: btw, you can run "python apport/ui.py -v", that's faster than running all tests
[09:42] <tkamppeter> pitti, I have committed a fix in CUPS for bug 405116
[09:42] <tkamppeter> pitti, can you upload the CUPS package to Debian and Ubuntu? Thanks.
[09:43] <pitti> tkamppeter: can do
[09:45] <tkamppeter> pitti, thanks.
[10:01] <pitti> tkamppeter: done
[10:04] <tkamppeter> pitti, thanks.
[10:05] <dholbach> TheMuso, thanks for the flowers
[10:09] <apw> @pilot in
[10:12] <fta2> pitti, hi. i have another problem with apport... on a server (maverick), one of my services segfaults, i have a crash file with a core, yet apport rejects it as an unsupported "assertion failure".. it's clearly not an assertion
[10:12] <pitti> fta2: it's a SIGABRT
[10:13] <pitti> fta2: these come from abort(), which are commonly assertion failures
[10:14] <fta2> pitti, i wrote the code, there's no abort() anywhere
[10:14] <pitti> fta2: which signal did it crash with?
[10:14] <pitti> fta2: if you want to report it anyway, you could edit the .crash file and remove the UnreportableReason: field
[10:14] <pitti> fta2: but I'm fairly sure it has Signal: 6
[10:15] <fta2> pitti, well no, i don't want to report it, i just want to use apport to resolve everything for me. I have the -dbg installed
[10:16] <pitti> fta2: you can still use apport-retrace etc.
[10:16] <fta2> apport-retrace? hmm
[10:16] <fta2> where is it?
[10:16] <pitti> fta2: and the .crash file should have complete data after you run it through the UI once (i. e. you see above error message)
[10:16] <pitti> fta2: it's in a separate package
[10:17] <pitti> fta2: apport-retrace -sv /var/crash/foo.crash -> trace to stdout; -gv will throw you into a gdb session
[10:17] <pitti> fta2: (if you run that as root, it will install extra -dbg/-dbgsym)
[10:18] <pitti> it's got a fairly complete manpage
[10:18] <fta2> trying..
[10:18] <fta2> hm, it dies horribly
[10:19] <fta2> KeyError: 'Stacktrace'
[10:19] <fta2> obviously, there's no such entry in the crash file
[10:20] <pitti> what's the full trace?
[10:21] <pitti> fta2: (I suspect it failed to generate one, so it can't print it)
[10:22] <fta2> pitti, http://paste.ubuntu.com/581532/
[10:23] <pitti> fta2: right, what I suspected; can you please try -g?
[10:23] <pitti> (instead of -s)
[10:25] <pitti> fta2: (I'll fix all these deprecation warnings, thanks for pointing out)
[10:26] <fta2> pitti, ok, it's indeed a sig 6, but deep inside libc
[10:27] <fta2> pitti, can i ask apport to resolve those anyway? it's not to report to lp, it's for me as upstream
[10:28] <pitti> fta2: you mean make apport-retrace -s work?
[10:29] <pitti> (which is equivalent to adding the Stacktrace: to the .crash file)
[10:32] <fta2> pitti, i mean I'd like to have the Stacktrace/ThreadStacktrace/.. in the crash file even it is unreportable because it's an abort()
[10:32] <pitti> fta2: right; yes, that should be possible
[10:33] <fta2> would be great
[10:33] <pitti> added to my todo list
[11:33] <soren> cdbs: In the most recent runit merge, you moved the debconf magic to the bottom of postinst. I can't work out why, and it seems to be causing problems.
[11:49] <abhinav-> pitti, I have made changes in the testsuite but cant really run it. It says: ' /etc/apport/crashdb.conf is damaged: No default database'
[11:49] <abhinav-> perhaps because of maverick
[11:50] <abhinav-> pitti: but I made the same changes in a branch of apport 1.4, and ran the tests, they were all ok
[11:52] <pitti> abhinav-: nice!
[11:52] <pitti> abhinav-: I can fix up the rest of this in the merge, so don't worry about thsi
[11:53] <abhinav-> pitti, ok thanks. I will push the branch :)
[11:53] <pitti> abhinav-: thanks a lot for your work! that's a nice feature indeed
[11:53] <abhinav-> pitti, Thank you :). apport is really an interesting project
[13:21] <cdbs> soren: you mean #DEBHELPER# or debconf?
[13:27] <hallyn> cjwatson: it turned out iwas compiling maverick's grub2 in lucid.  lucid's compiled fine.  sorry for the noise
[13:33] <cjwatson> hallyn: ok
[13:34] <cjwatson> hallyn: perhaps missing build-dependencies then
[13:41] <hallyn> cjwatson: maybe - it was complaining about some arch i'd never heard of before
[13:43] <cjwatson> I think I'd need to have seen the exact error message ...
[13:44] <hallyn> cjwatson: in any case i'll just need to try and cherrypick onto the lucid version, np.  thanks
[13:54] <soren> cdbs: debconf
[13:54] <soren> cdbs: You moved the confmodule inclusion to the bottom.
[13:55] <cdbs> wait, did I?
[13:55] <cdbs> Long time since I did it
[13:55]  * cdbs looks into the package
[13:55] <soren> cdbs: Cool, thanks.
[13:56] <soren> cdbs: The problem is that including debconf/confmodule re-executes that postinst script.
[13:56] <soren> cdbs: ...and the second time it executes, "start runsvcdir" fails, because it's already running.
[13:57] <cdbs> wait, this change was made in Debian
[13:57] <cdbs> but not included in the Changelog message
[13:57] <soren> Oh, really?
[13:58] <soren> Ah, yes.
[13:58]  * cdbs confirms
[13:58] <cdbs> soren: and, that isn't an ubuntu-specific change
[13:59] <cdbs> soren: patches.ubuntu.com confirms that
[13:59] <soren> Oh, I see the problem now.
[13:59] <soren> They don't use upstart, so they don't have this problem.
[14:00] <soren> "they" being Debian.
[14:00] <cdbs> yes, I also get it
[14:00] <cdbs> start fails, but why is runsvdir running then?
[14:00] <soren> Because its started the first time the script runs.
[14:00] <soren> Like I said, including confmodule re-execute the postinst.
[14:01] <cdbs> soren: is there a bug # already?
[14:01] <soren> two :)
[14:01]  * soren waits for lp
[14:02] <cdbs> soren: bug #708579
[14:02] <cdbs> I'll assign that to myself and look into the issue
[14:02] <soren> cdbs: Cool, thanks!
[14:02] <cdbs> soren: No, thank you for reporting the issue! :)
[14:03] <cdbs> Mark enters the fray! ^^
[14:03] <pitti> kees, jdstrand: new kernel releases to -updates and -security: karmic (linux linux-backports-modules-2.6.31 linux-ec2 linux-meta linux-meta-ec2 linux-ports-meta) and lucid (linux linux-backports-modules-2.6.32 linux-meta linux-ports-meta)
[14:46] <hggdh> cjwatson, ISO installs are failing -- partman fails, and there is this error:  error while loading shared libraries: libext2fs.so.2 no such file or directory.
[14:47] <hggdh> cjwatson, and good morning, and sorry to bother
[14:47] <cjwatson> hggdh: thanks, no problem, I'll look
[14:47] <cjwatson> hggdh: which images?
[14:48] <hggdh> cjwatson, we are opening a bug, but you can grab the d-i syslog at (for example) http://204.236.234.12/view/ISO-server-Natty/job/natty-server-amd64_openssh-server/100/artifact/100/test-results/
[14:48] <hggdh> cjwatson, amd64/i386 for the server and, I guess the alternates
[14:49] <hggdh> cjwatson, http://204.236.234.12/view/ISO-server-Natty/ gives you an idea
[14:49] <cjwatson> no more detail needed, thanks
[14:49] <cjwatson> looks like a regression caused by multiarch support
[14:51] <abhinav-> pitti, Thanks for accepting the patch and mentioning my name in NEWS :-). The patch had flaws,  I should have written better code looking at the rest of the code in the file :-)
[14:52] <pitti> abhinav-: don't worry, it wasn't hard to clean up
[14:52] <abhinav-> :)
[14:52] <pitti> abhinav-: I have a few other things to do in trunk still, but I should be able to do a new release/upload by tomorrow
[14:53] <abhinav-> pitti: that would be awesome :)
[14:53] <Laney> Can someone take a quick look at the build failure here — nothing at all relating to libffi.h changed in ghc with this upload. http://launchpadlibrarian.net/66569327/buildlog_ubuntu-natty-i386.ghc6_6.12.3-1ubuntu6_FAILEDTOBUILD.txt.gz
[14:58] <cdbs> soren: ah, fixed. Thanks again. Had someone notified me of it earlier I would have fixed it then and there
[14:59] <apw> @pilot out
[15:03] <soren> cdbs: Awesome, thanks.
[15:04] <hggdh> cjwatson, for reference, this is bug 736908
[15:06] <cjwatson> it's an e2fsprogs regression.  I'll look into it
[15:08] <pitti> fta: I just tried bash -c 'kill -ABRT $$'
[15:08] <pitti> fta: on current natty, and I do get a Stacktrace in the .crash file (even though apport complained about missing assert message); so I guess that was fixed since lucid
[15:09] <pitti> fta: I added an automatic check for this to apport's test suite
[15:22] <abhinav-> pitti, what do you think about bug 340970 ? I think it will require replacing ui_info_message with ui_question_yesno and calling update-manager if the user says yes ?
[15:24] <pitti> abhinav-: I wouldn't like to hardcode update-manager into apport (that would only work on ubuntu)
[15:25] <abhinav-> right, that would be a problem
[15:25] <pitti> abhinav-: so to do that, the apport/packaging.py API would need a new method run_package_update(), which the Ubuntu branch could then implement
[15:26] <pitti> and a way to tell "is upgrading available"
[15:26] <pitti> ui.py would check the latter, and run run_package_update() or so
[15:26] <pitti> other distros could plug in packagekit or yast or whatever
[15:28] <abhinav-> pitti, so define an abstract method in packaging.py ? and where will be the ubuntu specific code go ?
[15:29] <pitti> abhinav-: into the ubuntu branch, in backends/packaging-apt-dpkg.py
[15:30] <abhinav-> pitti, oh ok. got it.
[15:30] <pitti> abhinav-: sorry, it's a bit indirect and abstract, but I really want to avoid any Ubuntu specifics in trunk
[15:31] <pitti> abhinav-: this could also use python-aptdaemon.gtk3widgets instead of update-manager, not sure what's better
[15:31] <pitti> or it could try both
[15:31] <abhinav-> pitti, I understand, it would lead to more portable code :)
[15:33] <abhinav-> pitti, I dont know about aptdaemon.gtk3widgets, I will try it. Also, perhaps I will now create a branch from lp:apport ? last time I messed it up :-D
[15:33] <pitti> abhinav-: yes, working from trunk is appreciated
[15:33] <abhinav-> thanks for helping :)
[15:45] <mvo> pitti: update-manager uses the aptdaemon stuff internally (fwiw)
[15:45] <seb128> slangasek, you broke the retracers!
[15:46] <seb128> slangasek, hey btw ;-)
[15:46] <seb128> today's libstdc++6 update leads to that error
[15:46] <seb128> # apt-get update
[15:46] <seb128> apt-get: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by apt-get)
[15:46] <seb128> apt-get: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by /tmp/tmpd0eoqh/usr/lib/libapt-pkg.so.4.10)
[15:46] <pitti> (what a nice way to say "hello" :) )
[15:46] <pitti> seb128: I guess it's a problem of running this in fakechroot under lucid?
[15:46] <bjf> pitti, just any fyi, i sent email about new hardy pkgs
[15:47] <pitti> seb128: we can try getting the natty dchroot upgraded to today's packages, and let the retracer run there
[15:47] <seb128> pitti, could be, I just hate fakechroot I think ;-)
[15:47] <pitti> bjf: yeah, I saw; will do ASAP
[15:47] <pitti> seb128: so do I :)
[15:48] <seb128> pitti, wdym by "getting the natty dchroot upgraded to today's packages, and let the retracer run there"?
[15:48] <bjf> pitti, also :-) have you had a chance to look at the kernel sru workflow wiki page? any thoughts?
[15:48] <pitti> seb128: right now the lucid/maverick/natty retracer runs in osageorange's lucid dchroot
[15:48] <seb128> pitti, if we run the update and get the new libstd apt-get is broken, it will fail in the apt-get update call
[15:48] <pitti> bjf: not yet, sorry :/ still knee-deep in other stuff
[15:48] <pitti> seb128: I mean the dchroot, not the fakechroot
[15:49] <bjf> pitti, that's what i figured, thanks
[15:49] <YokoZar> pitti: slangasek: a fun side-effect of wine1.3 being in the archive now is that I need to add about 50 packages to ia32-libs unless I can make em multiarch ready ;)
[15:59] <cjwatson> pitti: any further thoughts on bug 732860?  I'm just preparing a snapshot upload to Debian now, which will be syncable
[16:00] <pitti> cjwatson: no strong opinion; seems fairly safe to me; so if you consider it appropriate, plesae go ahead
[16:01] <cjwatson> OK - yeah, I do
[16:12] <slangasek> seb128: interesting; does this retracer problem affect all archs or just i386?
[16:12] <seb128> slangasek, both i386 and amd64 but seems due to the fact that the retracers are fakechroots running in a lucid environment
[16:13] <seb128> slangasek, it works fine in a natty chroot, I switched to that for now (but that breaks the lucid retracers as a side effect)
[16:13] <seb128> slangasek, I think it's rather another fakechroot issue than a bug in the update
[16:14] <slangasek> seb128: lucid's libc should have already known about the multiarch paths, but I guess maybe they were at the /end/ of the library search path
[16:15] <slangasek> YokoZar: well, I'm not going to speak in favor of adding anything to ia32-libs, but we're still laying foundations here - it's still much too early for me to suggest flipping multiarch on for end users as a means of installing wine
[16:17] <YokoZar> slangasek: Will we be able to move anything out of ia32-libs and into proper multiarch in natty?
[16:26] <slangasek> YokoZar: ia32-libs is not allowed to express a dependency on any 32-bit multiarch packages, so the most likely scenario is still that ia32-libs carries the whole stack that it does now for natty release
[16:27] <slangasek> only once we've shaken multiarch down and are ready to turn it on for desktop users do we get to start pulling things out of ia32-libs
[16:27] <cjwatson> slangasek: can you look into bug 736908?
[16:28] <slangasek> cjwatson: ah shoot, yes
[16:28] <fta> pitti, re. /wrt apport, my production servers are running lucid or maverick, obviously not natty.
[16:28] <slangasek> I swear I checked all the udebs before uploading this
[16:28] <slangasek> apparently I missed one
[16:28] <cjwatson> ta
[16:31] <fta> pitti, also, just installing & enabling apport on a maverick server doesn't do much, apport-* all fail to add anything useful to the crash files.. until you install gdb (and something coming with dpkg-dev, not sure what)
[16:31] <fta> pitti, .. and i usually don't have the dev tools in my serv-farms
[16:32] <pitti> fta: ah, that was actually deliberate, as the server folks complained about having gdb by default, bug 354172
[16:32] <pitti> fta: hm, dpkg-dev? that shouldn't be
[16:33] <fta> pitti, well, not dpkg-dev itself, one of its deps
[16:33] <pitti> fta: ah, binutils perhaps
[16:34] <pitti> although I don't immediately see anything in binutils which it would need
[16:34] <fta> pitti, i had to install dpkg-dev on a pre-prod box to satisfy apt-get source (the unpack part), and it dragged a bunch of stuff with it, which made apport work
[16:50] <Laney> slangasek, doko: Sorry to ping directly, but can one of you look at the ftbfs of ghc6/i386? gcc fails to find libffi.h — it doesn't appear to be on the default search path.
[16:52] <slangasek> Laney: yes, libffi needs fixing for multiarch, known issue on my list - didn't realize it was blocking anything, I'll fix that now
[16:52] <Laney> great, thanks
[16:54] <slangasek> Laney: this failure is i386-only, right?
[16:55] <Laney> yeah
[17:03] <OdyX> tkamppeter: Grrr… Why did you upload the foomatic-db to Ubuntu ? It could easily have gone trough Debian + sync this time…
[17:09] <slangasek> Laney: libffi 3.0.9-3ubuntu1 uploaded
[17:10] <Laney> slangasek: thanks! will give ghc6 back when it hits :-)
[17:13] <pitti> bjf: hm, seems the lrm upload includes every changelog made ever -- http://launchpadlibrarian.net/66520064/linux-restricted-modules-2.6.24_2.6.24.18-29.8_source.changes
[17:13] <pitti> bjf: this will cause a lot of bug noise
[17:13] <bjf> pitti, my bad
[17:13] <bjf> pitti, i'll fix that
[17:13] <pitti> ok, thanks
[17:14] <bjf> pitti, i must have dropped the -v of the command line and didn't notice the changelog
[17:14]  * pitti will do linux in the meantime
[17:14] <pitti> that always takes longest anyway
[17:20] <pitti> bjf: linux, l-u-m, and l-b-m done; waiting for a fixed l-r-m, and linux-meta is missing
[17:20] <bjf> pitti, won't the linux-meta in -proposed suffice ?
[17:20] <pitti> bjf: ah, it's already -29, right
[17:20] <pitti> sorry
[17:21] <bjf> pitti, np, always good to double check
[17:21] <pitti> bjf: the hppa build has a proper ubuntu build record now (https://launchpad.net/ubuntu/+source/linux-backports-modules-2.6.24/2.6.24-29.38/+buildjob/2327416)
[17:21] <pitti> bjf: but of course without any hppa buildds that'll need to wait a bit
[17:22]  * pitti checks https://launchpad.net/builders/kohnen
[17:22] <pitti> trying to revive
[17:22] <pitti> hm, it's back on, but on manual
[17:22] <pitti> lamont: ^ kohnen (hppa) is on manual, is that deliberate?
[17:23] <lamont> only slightly
[17:24] <lamont> it's back to auto now
[17:24] <pitti> ah, cheers
[17:24] <pitti> bjf: linux hardy hppa building now
[17:54] <slangasek> cjwatson: e2fsprogs fix inbound; any other multiarch breakage you're running into?
[17:56] <cjwatson> slangasek: that's all I've heard of so far ...
[17:56] <slangasek> ok
[17:56] <cjwatson> do you have a list of libraries converted up to now?  I could go and double-check
[17:57] <slangasek> cjwatson: the list of packages on https://launchpad.net/~vorlon/+archive/multiarch/+packages that are superseded by newer versions, basically :)
[17:58] <cjwatson> that's as good as any other list
[17:58] <cjwatson> ok
[18:02] <cjwatson> slangasek: everything else there seems fine
[18:02] <slangasek> ok, good to hear
[18:27] <M0hamed> hello is this where I ask questions about how wubi installer works
[18:27] <cjwatson> M0hamed: I suppose it's as good as anywhere else
[18:28] <M0hamed> ok I was wondering how I could incorporate wubi-like functionality into other distributions
[18:28] <M0hamed> debian based
[18:29] <cjwatson> it would be a pretty giant amount of work
[18:29] <cjwatson> wubi includes integration into the installer, and there are lots of pieces that aren't in Debian yet
[18:29] <cjwatson> I'm not even sure I can enumerate them all and I wrote several of them
[18:31] <M0hamed> but the veru first version of lupin was a side project thatuses the debian installer with no change in the actuall ubuntu source
[18:31] <cjwatson> I know, but it did stuff like running sed over installer code at run-time
[18:31] <cjwatson> it wasn't maintainable like that, so we integrated it into the installer instead
[18:32] <M0hamed> so it wouldnt be a good GSoc project
[18:32] <cjwatson> you're not the first to ask, but I suspect that it would be pretty challenging as GSoC projects go, yes ...
[18:33] <M0hamed> cjwatson: can you tell me where to look for more info and how to build it from source
[18:33] <cjwatson> I think at the very least you would need to limit the scope - for example, including "port ubiquity to Debian" in the scope would reduce its chances of success by a fair bit
[18:33] <cjwatson> https://wiki.ubuntu.com/Installer/Development is about the best I can do for the Ubuntu installere
[18:33] <cjwatson> *installer
[18:34] <M0hamed> cjwatson: why not just use the debian installer
[18:34] <cjwatson> that would be one option for a Debian port
[18:34] <M0hamed> cjwatson: why ubiquity
[18:34] <cjwatson> it would still require a good deal of work
[18:36] <M0hamed> cjwatson: anyway that rules out that project because I am not that experienced in linux development and thought it was a good starting point
[18:36] <cjwatson> you'd need to do a full analysis of wubi's preseeding and figure out which installer facilities need to be ported to Debian; separately, you would need to figure out how to integrate the post-install bits, so integrating lupin with live-initramfs, porting the grub2 pieces over, etc.
[18:36] <cjwatson> and of course the Windows UI side of things
[18:37] <M0hamed> the windows ui is the easiest
[18:37] <M0hamed> cjwatson: its what I am experienced in the problem is on the linux side
[18:37] <cjwatson> oh, and the patches to fuse and ntfs-3g to put it in the initramfs, which we submitted to Debian some time back and the relevant maintainers refused to include them
[18:38] <cjwatson> (at least that's my memory ...)
[18:38] <M0hamed> cjwatson: so would that be the case for any other debian based distribution
[18:39] <M0hamed> or is it just debian itself lacking certain features
[18:39] <cjwatson> hm, the fuse patch was rejected, ntfs-3g initramfs never got submitted, but the ntfs-3g udeb patch was marked wontfix with no explanation and that would be absolutely necessary
[18:39] <cjwatson> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481335)
[18:39] <cjwatson> anything descended from Debian and not descended from Ubuntu is likely to have the same obstacles
[18:43] <M0hamed> cjwatson: you were graet thank you
[18:43] <M0hamed> cjwatson: although I will think twice before atempting such a feat
[18:44] <M0hamed> cjwatson: but you really helped
[18:51] <cjwatson> you're welcome
[18:59] <hasenj> what's the preferred way to develop natty? dual boot? or a virtual machine?
[19:01] <RoAkSoAx> hasenj: most of us work on the development version
[19:01] <hasenj> so it's the only installed version basically ..?
[19:01] <hasenj> I mean, you don't dual boot with 10.10 or anything like that?
[19:01] <RoAkSoAx> hasenj: I don't
[19:02] <RoAkSoAx> hasenj: i usually keep older kernels in case something goes wrong with graphics or stuff like that
[19:03] <cjwatson> in the very early part of the cycle I usually use a chroot.  from alpha 1 onwards or so I just upgrade and run it natively.
[19:03] <cjwatson> (but I know how to rescue myself if it breaks ...)
[19:04] <Chipzz> cjwatson: have you asked the maintainer about the ntfs3f udeb bug?
[19:04] <Chipzz> cjwatson: it appears he is on #debian-devel, I just asked him about it
[19:04] <hasenj> ah, chroot, interesting
[19:06] <cjwatson> Chipzz: somebody asked on the other bug he marked wontfix at the same time, and he did not respond
[19:06] <cjwatson> so I didn't hold out any particular hope
[19:38] <kirkland> how do i make the unity sidebar thing go away?
[19:38] <kirkland> it's getting "stuck"
[19:38] <kirkland> and rendering on top of my more important windows
[19:42] <Martiini> elou ..
[19:42] <Martiini> anyone here who belongs to devel team?
[19:42] <Martiini> I have a question about ubuntu kernel .. kernel seems to configured not as well as some other distros
[19:42] <Martiini> I have installed .. fedora, opensuse, ubuntu ..  and .. opensuse seem have best kernel+modules .. most laptops work out-of-box with acpi modules .. etc etc
[19:44] <achiang> Martiini: there is an #ubuntu-kernel channel that might be more appropriate; additionally, you may have better luck if you try to make your question more specific
[21:06] <Gatorade> hi
[21:06] <Gatorade> hi
[21:41] <mrc3_> sladen, i revisited gst-plugins-base, and i see now when it goes awry: with "include /usr/share/cdbs/1/rules/autoreconf.mk" in debian/rules
[22:03] <sladen> mrc3_: autocrap.  joy.  mmm