[12:42] <unggnu> hi all
[12:43] <unggnu> Today was a new acpi-support version release for Gutsy but the sonybright.sh issue https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/136380 hasn't been fixed. Is something wrong with the patch?
[12:43] <ubotu> Launchpad bug 136380 in acpi-support "[Gutsy]  sonybright.sh doesn't use the correct value range" [Undecided,New]
[12:45] <mjg59> No, it was simply uploaded for other issues
[12:46] <unggnu> I am afraid that this bug make it into final. Ok, it is no debian package patch but at least it should be clear what is wrong.
[12:50] <unggnu> Is there any how to what is the best way to post patches?
[01:00] <unggnu> If I post a bug in Launchpad it tries to find similar bugs which is great but it often shown duplicates. Isn't it better to show the main bug an not the duplicate? It should use the duplicate to find a similar one but then only show the main bug imho.
[01:06] <pochu> unggnu: sounds like a good suggestion, could you file a bug at https://bugs.launchpad.net/malone/+filebug ?
[01:06] <unggnu> pochu: For Launchpad?
[01:07] <pochu> yeah, the dups thing
[01:07] <unggnu> Ok, thanks.
[01:16] <unggnu> pochu: There was already a bug report for this issue. https://bugs.launchpad.net/malone/+bug/130526
[01:16] <ubotu> Launchpad bug 130526 in malone "Improve list of duplicates when reporting a bug (order by number of dupes, mark dupes)" [Undecided,New]
[01:16] <unggnu> ciao
[01:23] <pygi> ls
[02:20] <ion_> https://launchpad.net/apt-mark-sync in case anyone is interested.
[02:21] <pygi> ion_, what is debfoster? :P
[02:21] <pygi> and people are sleeping :D
[02:21] <ion_> pygi: apt-cache show debfoster
[02:22] <pygi> ion_, at this time of day? xD
[02:22] <pygi> right
[02:22] <pygi> good night =)
[02:23] <ion_> Night
[02:24] <saispo> anyone have an idea why with my macbook and the latest madwifi drivers under feisty i see my AP but when i enter the key, no dhcp response...
[02:24] <saispo> ?
[03:11] <jdong> 21:13 -!- geser [i=mb@2002:5361:2a04:0:0:0:0:1]  has joined #ubuntu-devel
[03:11] <jdong> cool is that IPv6?
[03:11] <geser> yes, ipv6-over-ipv4
[03:12] <jdong> cool
[03:12] <geser> it really is :)
[03:13] <ion_> Speaking of IPv6, i hacked IPv6 reverses to all machines in my LAN. They advertise their addresses using Avahi, and the DNS box queries the addresses and updates the DNS records on demand.
[03:14] <ion_> Thus, this box is seen by the outside world as luotain.lan.heh.fi
[04:29] <stuart_> hi everyone, does this udev rule look correct? ACTION=="add", BUS=="usb", SYSFS{model}=="MHT2020AT*", RUN+="/usr/local/bin/fht_backup", SYMLINK+="usb_backup_disk"
[04:59] <josh_whitney> hi, someone on my localnet got this ip address banned from #ubuntu.  how do I resolve it?
[05:00] <Hobbsee> go to #ubuntu-ops
[07:05] <pitti> Good morning!
[07:06] <pygi> morning pitti
[07:08] <StevenK> Morning pitti!
[07:08] <StevenK> pitti: How was your holiday?
[07:09] <pitti> hey StevenK, hi pygi
[07:09] <pitti> StevenK: we truly enjoyed it, Paris is great
[07:10] <StevenK> pitti: Now that you're back at work, can you do a bunch of NBS stuff? :-)
[07:11] <StevenK> pitti: I *think* -10 of the kernel can be NBS'd out, along with a whole bunch of everything else - my suggestion is kill everything that is zero sized and then regenerate the list.
[07:12] <pitti> StevenK: right, I'll do that
[07:14] <StevenK> pitti: NBS'ing out everything zero-sized will also make another five or six also hit zero-size after the list is regenerated.
[07:18] <pitti> hey thekorn
[07:19] <thekorn> hey pitti
[07:19] <thekorn> how was your vacation?
[07:19] <pitti> thekorn: thanks for the apport porting to the new p-lp-bugs; however, the retracers now throw some exceptions, can I bother you with some questions today?
[07:19] <pitti> thekorn: we loved it, Paris is great
[07:20] <thekorn> pitti: yes, sure
[07:25] <pitti> StevenK: slaughtery committed
[07:26] <StevenK> pitti: Yay! You need to wait for the publisher to run/finish before re-generating?
[07:28] <pitti> StevenK: yep
[07:31] <superm1> pitti, do you know how mvo builds the big .tar.gz that contains all the .desktop and and icons files that go into app-install-data?  It appears his update script for it grabs them from a big .tar.gz sitting in his people.ubuntu.com directory
[07:31] <pitti> superm1: unfortunately I don't know this; this is a special upload magic method
[07:32] <superm1> okay i'll just shoot him a mail then, thx :)
[07:39] <ScottK> StevenK: Maybe while he's in a slaughtering mood, he'll process some removal bugs ...
[07:42] <StevenK> ScottK: Heh, maybe.
[07:46] <LaserJock> pitti (aka The Grim Reaper) ;-)
[07:50] <pitti> ScottK: if you need something urgently, I can do it now; otherwise, Friday is my archive day
[07:50] <ScottK> pitti: No, no rush.  Friday will be fine.
[07:50] <ScottK> Just having fun with the slaughtering motif.
[07:51] <ScottK> Good night all.  I'm off to sleep.
[07:51] <pitti> g'night Scott
[07:52] <superm1> night ScottK
[08:08] <StevenK> I guess that means the new PAM works.
[08:08] <pitti> StevenK: so far it does fine :)
[08:13] <kagou> good morning
[08:15] <dholbach> good morning
[08:18] <pygi> morning dholbach
[08:19] <dholbach> hey pygi
[08:28] <Mithrandir> dholbach: why did you make bluez-utils build-dep on gstreamer-tools rather than libgstreamer-plugins-base0.10-dev?
[08:29] <Mithrandir> (and libgstreamer0.10-dev)
[08:29] <dholbach> Mithrandir: gstreamer-tools is required for dh_gstscancodecs
[08:29] <Mithrandir> ah, ok
[08:29] <dholbach> Mithrandir: I guess I forgot to add the other build-dep
[08:29] <dholbach> and didn't run the build in pbuilder, so I did not notice that the build-dep was missing
[08:44] <StevenK> pitti: You should be able to regenerate the NBS list now, right?
[08:45] <pitti> StevenK: right, doing now
[08:52] <StevenK> Hum.
[08:52] <StevenK> Maintainer: Peter Zhu<EMAIL_ADDRESS>Ubuntu MOTU Developers <ubuntu-mo
[08:52] <StevenK><EMAIL_ADDRESS>[08:52] <StevenK> I don't even think that's legal.
[08:56] <pitti> StevenK: http://people.ubuntu.com/~ubuntu-archive/NBS/ is updated
[08:56] <StevenK> pitti: Yay, thank you.
[08:56] <pitti> StevenK: maintainer> right, there should only be one; but I guess few programs actually rely on that
[08:57] <pitti> StevenK: I kill the two without remaining rdeps
[08:57] <StevenK> pitti: Way cool.
[08:57] <doko> pitti: maybe you can double-check the fstack-protector/nostdlib thing, planned to upload 4.1 with this one as well
[08:58] <pitti> doko: yep, I can, once it's built and in the archive
[08:58] <MacSlow> Greetings everybody!
[08:58] <StevenK> infinity: Ping, libnss-db some more.
[09:16] <Mithrandir> pitti: are you fixing the ftbfs in libcgi?
[09:16] <pitti> Mithrandir: I got a lot of FTBFS from the maintainer: rebuilds, I probably won't fix them all
[09:16] <Mithrandir> ok
[09:16] <pitti> Mithrandir: if this one is particularly important, I can look into it, of course
[09:16] <Mithrandir> nah, I'm just looking at my lp-buildd-admins mbox
[09:17] <pitti> but since most of these packages haven't been touched for ages, I won't waste much time on them in general
[09:18] <Mithrandir> hm, I wonder if there's a good mechanism I can add to packages maintained in revision control to tell people to submit patches properly rather than just uploading new versions of them.
[09:18] <Mithrandir> (apart from X-VCS)
[09:19] <StevenK> X-Commit-Do-Not-Upload: True ? :-P
[09:20] <Fujitsu> We need the bit of NoMoreSourcePackages where Soyuz rejects non-VCSed uploads for VCSed source packages.
[09:20] <Mithrandir> Fujitsu: something like that, yes.
[09:20] <Mithrandir> I'm wondering if I can get it done in the package, though
[09:40] <DktrKranz> dholbach, do you have time to review a segfault fix for bluez-libs in bug 126068 ?
[09:40] <ubotu> Launchpad bug 126068 in bluez-libs "Pybluez segfaults if bluez not running" [Undecided,Confirmed]  https://launchpad.net/bugs/126068
[09:41] <pitti> thekorn: ah, p-lp-bugs 0.2.10 might actually resolve one of the crashes
[09:43] <thekorn> pitti: ah, ok, do you have any tracebacks or error messages I can check?
[09:43] <pitti> thekorn: I'll look into it in a bit, once the updated deb is in the archive, I'll restart the retracers and watch the logs
[09:44] <thekorn> ok, ping me if you need some help with py-lp-bugs
[09:47] <calc> pitti: hi
[09:48] <pitti> hey calc
[09:48] <pitti> calc: why not?
[09:48] <calc> my wife can't sleep and she won't shut up
[09:48] <calc> so i am working instead of sleeping :\
[09:49] <calc> i need another bed for situations like this ;)
[09:49] <ion_> ...So your wife decided youll not sleep tonight?
[09:49] <calc> pitti: oh did you get my message about suitesparse?
[09:49] <calc> ion_: more or less, not her fault she has insomnia, we are taking her to the doctor tomorrow to have it checked
[09:50] <pitti> calc: I did; I didn't check for an MIR yet, though
[09:50] <calc> pitti: it was in main until Sept 5
[09:50] <doko> calc: why upload rc1, if rc2 is released?
[09:50] <calc> pitti: i can do a MIR if needed
[09:50] <calc> doko: why upload at all when 2.3.0 will be out ~ thursday...
[09:51] <calc> doko: i had rc1 done already and tested i didn't have rc2 tested
[09:51] <calc> and yes 2.3.0 should be out around wed/thu this week aiui
[09:52] <doko> ahh, ok. please don't upload the -l10n package immediately, but loosen the deps instead, and include the updated translations from launchpad
[09:55] <doko> calc: hmm, debian changelog not in the changes file
[09:59] <calc> either part the including the entries or kicking me when i don't use -v, either would suffice ;)
[10:06] <pitti> calc: it does print out a warning about it already
[10:07] <AlinuxOS> hello pitti, nice to re-see you ;)
[10:07] <pitti> bonjour AlinuxOS!
[10:08] <AlinuxOS> pitti, one fast question, is there daily lang-packages for gutsy ?
[10:09] <pitti> AlinuxOS: it was disabled for a while due to some bad circumstances, but I just uploaded fresh ones and re-enabled the cronjobs
[10:10] <AlinuxOS> asac, good morning, how is going https://bugs.launchpad.net/ubuntu/+source/mozilla-firefox-locale-all/+bug/88677 fixing?Sorry for refreshing you via IRC :)
[10:10] <ubotu> Launchpad bug 88677 in mozilla-firefox-locale-all "Georgian Language support." [Undecided,Confirmed]
[10:11] <AlinuxOS> pitti, ah, so it's usable now right ?
[10:11] <pitti> AlinuxOS: they are not built yet, but will be soon
[10:11] <AlinuxOS> pitti, ah ok ;)
[10:11] <AlinuxOS> nice too hear. thank you.
[10:12] <calc> pitti: oh, hmm i missed that somehow, i'll look to see if i can find the warning
[10:12] <AlinuxOS> pitti, I suppose this is a rep right?  deb http://ppa.dogfood.launchpad.net/ubuntu-langpack/ubuntu gutsy main
[10:12] <pitti> AlinuxOS: nope, gutsy updates are uploaded straight into gutsy proper
[10:13] <calc> pitti: i don't see the warning though i may be blind
[10:13] <calc> pitti: at least not in my build log
[10:13] <AlinuxOS> pitti, I was talking about daily langpack updates.
[10:13] <pitti> AlinuxOS: so was I
[10:14] <AlinuxOS> pitti, ;) ok thanks
[10:15] <pitti> WARNING generated by debuild:
[10:15] <pitti> Ubuntu merge policy: when merging Ubuntu packages with Debian, -v must be used
[10:15] <pitti> calc: ^
[10:15] <pitti> calc: I get this (from debuild)
[10:18] <\sh> uh...what happened to the mouse under gnome?
[10:19] <calc> pitti: cool i wonder why mine doesn't say that
[10:20] <calc> pitti: i built with debuild -sa -S -us -uc
[10:20] <calc> pitti: would that cause the problem of not seeing the message maybe?
[10:20] <pitti> calc: no, that shuold work
[10:21] <pitti> calc: however, it's only shown if $DEBEMAIL =~ /ubuntu/
[10:21] <calc> pitti: hmm does that show up in the debuild *.build log?
[10:21] <dholbach> DktrKranz: ok
[10:21] <calc> pitti: oh doh
[10:21] <calc> i should set my DEBEMAIL var then so it reminds me
[10:21] <calc> i build in a chroot and don't have that set at all
[10:21] <dholbach> DktrKranz: I'll triage the sponsoring queue in a bit
[10:22] <DktrKranz> dholbach: thanks
[10:27] <angel25_> i installed ubuntu server 7.04 on Intel Core 1.83 with 2 GB RAM (1 stick) and everyting working good , when i increase my memory to 4 GB the system got stuck and move very slowly, on the start i get an error under : loading hardware drivers - e1000: eth0: e1000_request irq unable to allocate msi interrupt error -22 someone please can help me ?
[10:31] <DktrKranz> pitti: hi martin, welcome back! have you some time have a look at plr SRUs proposals in bug 130059 ?
[10:31] <ubotu> Launchpad bug 130059 in plr "[SRU]  R_HOME environmental variable not set" [Undecided,Confirmed]  https://launchpad.net/bugs/130059
[10:33] <calc> pitti: hmm i still don't get the warning even with it set, eg
[10:33] <calc> dpkg-genchanges: including full source code in upload
[10:33] <calc> ver: 1:2.3.0~rc1-1ubuntu1 since<EMAIL_ADDRESS>[10:33] <calc> dpkg-buildpackage (debuild emulation): source only upload (original source is included)
[10:33] <calc> very odd :-\
[10:33] <calc> debuild is out to get me, heh
[10:34] <soren> calc: Does your DEBEMAIL have "ubuntu" in it somewhere?
[10:34] <calc> soren: notice debuild output says debemail =<EMAIL_ADDRESS>[10:35] <pitti> calc: erk, there's still some debugging output there, I should remove that
[10:35] <calc> heh
[10:35] <pitti> calc: debuild itself generates the warning, btw
[10:35] <soren> calc: Oh, right :)
[10:35] <pitti> calc: and the changelog entry has to =~ /merge.*Debian/i
[10:36] <pitti> calc: I know, it's a weird heuristics, that's why it doesn't live in dpkg itself
[10:36] <calc> oh gr i used different wording in my changelog
[10:36] <calc>   * Resynchronise with Debian. Remaining changes
[10:36] <pitti> calc: ah
[10:36] <calc> so it doesn't like my changelog entry i guess
[10:36] <pitti> calc: I'll change the regex for that
[10:36] <pitti> calc: along with removing that debugging stuff
[10:36] <calc> thanks
[10:39] <pitti> DktrKranz: reviewed, I updated the bug
[10:41] <DktrKranz> pitti: thanks.
[10:53] <mdz> jdstrand: yes.  the control actually works properly at the moment, but the brightness indicator on-screen is borked
[11:07] <mhb> hi pitti
[11:07] <soren> \o/
[11:07] <pitti> hey mhb
[11:09] <mhb> pitti: zasf had some bug fixes for r-m, before you upload them, I would like to have a look if those bugs don't appear in KDE frontend, too
[11:10] <mhb> by "upload" I meant merge with the main branch, not uploading itself
[11:10] <pitti> mhb: alright, thanks for the notice
[11:16] <asac> siretart: ping
[11:18] <Lure> pitti: have 5 minutes to discuss libgphoto2?
[11:18] <pitti> Lure: doing some other things, but just ask
[11:19] <Lure> pitti: I did merge to try libgphoto2 2.4.0 (new upstream release), but have found one issue with  debian/libgphoto2-2.postinst
[11:19] <pitti> Lure: did you get UVFE for that?
[11:19] <Lure> pitti: it looks like one condition (version check) is in reverse and I am concerned if it is ok at all in current package
[11:20] <Lure> pitti: not yet, as I would like to have wider testing through ppa and then ask you what do you feel about it
[11:20] <pitti> Lure: looking
[11:20] <Lure> pitti: good thing that api stays (just new functions added)
[11:20] <StevenK> Hrm. Who's archive day is it today?
[11:20] <Lure> pitti:
[11:20] <Lure> if which udevinfo >/dev/null && udevinfo -V | awk '{if ($3 >= 98) e
[11:20] <Lure> xit 1}'; then
[11:20] <Lure> This exit 1 seems to be wrong, based on what is executed afterwards
[11:21] <pitti> Lure: I think it's correct
[11:21] <Lure> pitti: on current gutsy, "else" part print usage of print-camera-list into udev rule file
[11:21] <pitti> Lure: the problem is that udev-rules-0.98 has a weird semantics
[11:22] <Lure> pitti: but exit 1, makes condition false
[11:22] <pitti> Lure: oh, I guess they removed the pre-0.98 syntax in 2.4?
[11:22] <Lure> pitti: looks like, but I still think condition is wrong in current package
[11:22] <Lure> pitti: I can fix 2.4 properly (remove 0.98 case)
[11:22] <pitti> Lure: for a new gutsy merge the entire if should just be removed, and replaced with a single p-c-l call
[11:23] <Lure> pitti: exactly
[11:23] <pitti> Lure: this was mainly introduced to keep the feisty package backportable to edgy
[11:23] <Lure> pitti: ok, that was the reason
[11:24] <geser> morning
[11:24] <pitti> hey geser
[11:24] <Lure> pitti: will complete the merge then and will upload to my PPA and ask for review/UVF later (when confirmed with some users it still works fine with most apps)
[11:25] <pitti> Lure: great, thanks; I did the last merge IIRC, so I'd be interested in reviewing it
[11:26] <Lure> pitti: that is why I waited for you to come back from vacation to check it at all makes sense to ask for UVF ;-)
[11:27] <geser> does somebody know why the gnuradio source is in universe but all the binaries in multiverse?
[11:28] <pitti> geser: probably just an oversight when NEWing it
[11:29] <pitti> geser: hm, do you see a reason why it should be in multiverse?
[11:30] <StevenK> pitti: libmissioncontrol{0,-dev} is ready to NBS out at your leisure.
[11:30] <pitti> geser: I moved it to universe for now (debian/copyright is GPL and it's in Debian main)
[11:31] <geser> pitti: thanks, I don't know a reason why it should be in multiverse.
[11:31] <pitti> StevenK: done, thanks!
[11:41] <StevenK> pitti: Thanks!
[11:55] <geser> pitti: do you also handle UVFe for packages in main?
[11:56] <pitti> geser: yes, I can do that
[11:56] <geser> I've started to look on boost (bug #134684)
[11:56] <ubotu> Launchpad bug 134684 in boost "Upgrade to Version 1.34.1" [Wishlist,New]  https://launchpad.net/bugs/134684
[11:56] <geser> the linked list of fixed problems looks interesting
[11:57] <geser> I've uploaded a merged boost to my PPA and started to check if packages build-depending on it still build
[11:57] <geser> I didn't get far as my PPA is nearly full
[11:58] <geser> I checked the 3 packages from main depending on boost and some from universe
[11:59] <geser> 57 packages from universe are still to be checked :(
[12:00] <pitti> geser: hm, which applications would actually benefit from that?
[12:01] <geser> in main kdepim, kdeedu and libwibble build-depend on it
[12:01] <pitti> geser: I mean benefit from the bug fixes to fix visible bugs
[12:02] <geser> I don't know if there are any filed bugs
[12:08] <geser> pitti: so no upgrade of boost for gutsy? and the bug asking for it can be closed?
[12:08] <pitti> geser: currently looking
[12:08] <pitti> geser: it's only a microversion upgrade
[12:09] <pitti> geser: however, I'd like to see the upstream changelog, and a quick review of the diff
[12:09] <geser> yes, a bugfix release from 1.34.0 to 1.34.1
[12:09] <pitti> geser: browsing the diff should give an idea about API breakage and whether things look bugfix-ish, or like major new features
[12:09] <geser> the problem is that the packages names contain the version and all depending packages need rebuilding
[12:10] <geser> pitti: ok, will prepare the diff
[12:10] <pitti> geser: merci
[12:17] <dholbach> iwj: is bug 134358 ok to upload?
[12:17] <ubotu> Launchpad bug 134358 in hexter "Please merge hexter (0.6.1-2) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/134358
[12:21] <pitti> geser: can you confirm that bug 131591 is fixed? it's for me
[12:21] <ubotu> Launchpad bug 131591 in poppler "pdftops from poppler-utils 0.5.9-0ubuntu1 produces broken postscript" [High,In progress]  https://launchpad.net/bugs/131591
[12:25] <geser> pitti: yes, it's fixed
[12:26] <pitti> geser: thanks, closed
[12:27] <dholbach> iwj: also... does the patch in bug 131858 make sense? shall I assign it to you or do you think there's somebody else who can review it?
[12:27] <ubotu> Launchpad bug 131858 in grub "Update-grub does not add savedefault anymore" [Undecided,New]  https://launchpad.net/bugs/131858
[12:27] <geser> pitti: re boost: there is no changelog, only the ticket list which got fixed in 1.34.1 (which is also linked from the homepage): http://svn.boost.org/trac/boost/query?status=closed&milestone=Boost+1.34.1
[12:27] <pitti> geser: ok, so we need to take a look at the diff
[12:28] <geser> pitti: a diffstat and a diff between 1.34.0 and 1.34.1 is at http://members.ping.de/~mb/boost/
[12:30] <pitti> geser: filterdiff -x "*.html" boost.diff |grep -v ^diff is much better to read :-) reviewing now
[12:34] <pitti> geser: why was the python2.5-dev b-dep changed to python2.4-dev? that looks wrong
[12:38] <geser> pitti: it's a change made by Debian
[12:38] <pitti> geser: bug updated
[12:38] <geser> I diff the old Ubuntu packages with the new one
[12:39] <geser> pitti: all the python-*-dev build-depends look a little bit duplicate for me
[12:40] <pitti> geser: right, python-dev already pulls in 2.5-dev, but 2.4-dev seems to be wrong, unless we reintroduce the elementtree dep with sth. like "Depends: python2.5 | python-elementtree"
[12:45] <geser> looking at the Debian bug it was done as python2.4 is still default in Debian, so it should be safe to change it back
[12:46] <geser> pitti: build logs for boost, kdepim, kdeedu and libwibble at https://launchpad.net/~geser/+archive/+builds?build_text=&build_state=all
[12:47] <pitti> geser: ah, cool; if everything builds, I'm fine with it
[12:47] <geser> the miro FTBFS dies at linking with boost as it tries the old lib name
[12:50] <siretart> asac: pong
[12:50] <asac> siretart: hi ... about wpasupplicant .)
[12:51] <asac> siretart: some operations take ages some times ... e.g. terminate
[12:51] <asac> siretart: any idea what wpasupplicant might be doing?
[12:53] <siretart> huh? I never noticed that
[12:53] <siretart> asac: is it perhaps in state 'D' while hanging?
[12:53] <siretart> that would indicate it was waiting for a system call to finish
[12:55] <asac> siretart: how can i see that state?
[12:55] <asac> siretart: my guts feeling suggests that its some system call ... however i am not sure how to best track that
[12:56] <asac> siretart: you can easily see that when you use the latest opennet branch ... i increased timeout for some operations in nm ... but still sometimes it just fails.
[12:56] <asac> siretart: would be really great if you could help a bit ;)
[12:57] <asac> siretart: if you don't want to compile nm ... just wait a few hours, I will upload that branch now anyways.
[12:57] <siretart> asac: you can see the process state with tools like 'top' or 'ps'
[12:58] <asac> ah ... let me see
[12:58] <siretart> asac: other 'normal' states are 'S' for sleeping, or 'R' for running. 'D' is 'I'm hanging during some system call'
[12:58] <siretart> asac: is there a bug number for this issue?
[12:58] <siretart> I'm happy to take a look at it, but first I need to be able to reproduce that
[12:58] <asac> siretart: no ... i asked you because i am not sure if that is a known issue ;)
[12:59] <asac> siretart: sure ... should be rather simple
[12:59] <asac> siretart: i will ping you once new nm is rolled
[12:59] <asac> siretart: you can see it now in nm as well ... there are often "couldn't connect to supplicant errors" when you switch networks for instance
[12:59] <siretart> if it is indeed a system call which blocks it, there isn't much we can do on the supplicant side. it's a(nother) driver problem then
[12:59] <mjg59> asac: ipw3945 loves me again
[12:59] <mjg59> Thanks!
[01:00] <asac> mjg59: yeah ;) ... i am happy that it appears to have cured most :)
[01:00] <asac> mjg59: thanks for the feedback
[01:00] <siretart> :)
[01:01] <asac> siretart: the intersting thing is that i see the same timeout issues even though i am using a different driver
[01:01] <mvo> asac: network-manager is fine for me now after updating to the latest version. when the interface is manually managed it does not longer thinks its not configured, but correctly keeps its hands away
[01:02] <asac> mvo: strange ;)
[01:02] <asac> mvo: there wasn't really a change related to something like that ;)
[01:02] <asac> but happy that it works now :)
[01:03] <mvo> asac: I only infrequently upgrade my notebook, its quite possilbe that the change is already ~4 weeks old :)
[01:07] <asac> ah ok
[01:07] <asac> let me know when it reappears
[01:08] <asac> mvo: its pretty important that users are not offlin if they use /e/n/i ;)
[01:08] <mvo> sure
[01:08] <mvo> I keep a eye open
[01:16] <pitti> mvo: do you already know about the ImportError crash on livecd start from update-app-install?
[01:19] <mvo> pitti: is this still a issue with 0.4.8-0ubuntu2 ? this version was meant to fix it
[01:21] <pitti> mvo: I just tested the current i386 live
[01:21] <mvo> pitti: could you please check the version of gnome-app-install on it? I sync a new image now, but it will take a bit until I have it
[01:21] <pitti> mvo: which package is that?
[01:22] <pitti> 0.4.8-0ubuntu1
[01:22] <mvo> ok
[01:22] <mvo> -ubuntu2 should fix it
[01:22] <pitti> mvo: ah, ok, so I'll check tomorrow's; thanks!
[01:22] <mvo> cheers
[01:23] <mvo> -ubuntu2 was uploaded a couple of days ago, before the weekend - I wonder why its not there yet
[01:23] <cjwatson> today's live CD build broke, which was my fault
[01:23] <cjwatson> should be fixed shortly
[01:23] <cjwatson> mvo: see above :)
[01:23] <cjwatson> I'll poke through a new live CD build now
[01:24] <mvo> :)
[01:24] <mvo> ok
[01:24] <mvo> np
[01:25] <carlos> cjwatson, mdz: hi, around?
[01:25] <mdz> carlos: on the phone. what's up?
[01:26] <carlos> cjwatson, mdz: I wonder whether we could add a policy to force a package rebuild when we move it from universe to main if it has translations
[01:26] <carlos> otherwise, the application cannot be translated in Launchpad neither appears in language packs
[01:26] <cjwatson> it would be rather inconvenient to force it
[01:26] <carlos> until a new version is rebuilt
[01:27] <mdz> carlos: I think that rather we should ensure (when we do a global rebuild test) that no cases like this exist, and force rebuilds where necessary at that time
[01:27] <cjwatson> is there a huge problem with just waiting until it's uploaded again in the normal course of development?
[01:27] <cjwatson> (or reporting on it, as mdz suggests)
[01:27] <mdz> at string freeze, say, we could do any needed rebuilds then
[01:27] <carlos> cjwatson: well, the only problem is that users asks us to fix it, and we redirect them again to package maintainers
[01:27] <cjwatson> carlos: the workflow for packages being moved from universe to main is not geared to let us easily do this sort of thing immediately
[01:27] <carlos> other than that... nothing
[01:28] <carlos> ok
[01:28] <cjwatson> if we had the facility for central binary-only rebuilds, it would be trivial, but as it is it requires a source upload
[01:29] <cjwatson> carlos: is it possible for you to produce a list of packages in main for which you do not have translation tarballs?
[01:29] <carlos> cjwatson: we have a spec to produce such report, although is not yet implemented
[01:30] <cjwatson> that would seem like the most straightforward answer
[01:32] <carlos> anyway, that would include also packages that cannot be translated as false positives (still need to think on a way to remove them from the report)
[01:32] <pitti> Mithrandir: to get a workaround for bug #131976, I'd like to create a casper hook which disables the AppArmor profile for cups on the live cd; would I ship that in the cupsys package, or in casper proper?
[01:32] <ubotu> Launchpad bug 131976 in cupsys "fails to start: cannot apply additional memory protection after relocation" [High,Triaged]  https://launchpad.net/bugs/131976
[01:33] <Mithrandir> pitti: traditionally, I've shipped all those hacks in casper itself.
[01:33] <pitti> Mithrandir: right, by the looks of it it has all sorts of package specific hacks, but I wanted to get a second opinion
[01:33] <dholbach> BenC: do you think I should assign review bugs for the kernel team to canonical-kernel-team instead of ubuntu-kernel-team?
[01:37] <cjwatson> pitti: if you want a third opinion, I agree with Mithrandir - ship it in casper
[01:37] <pitti> cjwatson: thanks; I'll do that
[01:39] <cjwatson> pitti: I see cryptsetup is on the approved-for-main list now. Should we promote that and all the d-i bits for it too? I know we're past feature freeze ...
[01:41] <pitti> cjwatson: promotion is fine for me if it works properly now
[01:41] <pitti> cjwatson: I'd rather apply the FF to the package itself
[01:41] <pitti> cjwatson: the d-i bits might fall under FF once they get installed by default, I figure?
[01:41] <cjwatson> they won't be used by default, merely provided as options
[01:42] <pitti> cjwatson: is that the module which allows you to create LUKS encrypted partitions in partman?
[01:42] <cjwatson> right
[01:42] <pitti> default> right, that's why I'm not too concerned about it
[01:42] <pitti> in the unlikely case that it breaks the default install, the breakage should be at a level we immediately notice on install tests
[01:43] <cjwatson> indeed so, and we won't be including it in ubiquity anyway
[01:43] <cjwatson> ok, I have to go to buy milk now but will look at that when I get back
[01:43] <pitti> (which is a pity... :-) )
[01:43] <cjwatson> the ubiquity code would *definitely* fall under feature freeze. :-)
[02:00] <stdin> doko: you about?
[02:00] <doko> stdin: ?
[02:01] <stdin> doko: Lure mentioned you were working on kde-systemsettings, it seems it now need python2.5-dev to work now
[02:02] <doko> did I mention to work on this?
[02:02] <Lure> doko: recent cleanup of python-qt that you did
[02:03] <ion_> benc: Btw, have you had the chance to apply the patch to nvidia_supported in l-r-m? The newest l-r-m package still contains no modaliases for nvidia_new.
[02:03] <stdin> doko: well, yeah, seems kde-systemsettings tries to access /usr/lib/libpython2.5.so
[02:03] <doko> Lure, stdin: bug number?
[02:04] <doko> shouldn't it do that?
[02:04] <geser> doko: your vectormath package looks odd, libvectormath1 seems to be missing (the -dev package depends on it) and the -dev package includes only headers. Is this intended?
[02:04] <Lure> doko: it is provided by python2.5-dev and not regular package
[02:05] <doko> geser: yes, working on that ...
[02:05] <stdin> here we go https://bugs.launchpad.net/ubuntu/+source/kde-systemsettings/+bug/138189
[02:05] <ubotu> Launchpad bug 138189 in kde-systemsettings "[gutsy]  libpython2.5.so is missing" [Undecided,New]
[02:05] <doko> geser, do you have ubuntu running on the ps3?
[02:05] <Jucato> thanks stdin :)
[02:06] <ion_> benc: Btw2, in case you ever need a small program that indicates whether given hardware (by modaliases or a module name) is connected to the system, <https://launchpad.net/hardware-connected>. It should be useful when making the nvidia stuff automatically make symlinks to different versions of the nvidia drivers based on connected hardware.
[02:08] <geser> doko: I don't even own a ps3
[02:31] <hunger> siretart: Are you serious with cryptsetup breaking whith /usr being in a separate encrypted filesystem not being a serious problem?
[02:55] <geser> pitti: can you please give-back libglade-java on sparc and libgnome-java on ia64. Thanks.
[02:56] <pitti> geser: done
[02:56] <pitti> hunger: do you think it is? what's the use case?
[02:56] <pitti> hunger: after all, wouldn't it make much more sense, if you have a separate /usr, to have it be the only partition which is *not* encrypted?
[02:58] <hunger> pitti: It has to be: /usr has to be encrypted, otherwise somebody can sneak SW onto your system.
[02:58] <hunger> pitti: at least if you are considering encryption as a protection against manipulation of your system.
[02:58] <pitti> hunger: but in that case, leaving / unencrypted won't help you
[02:58] <hunger> pitti: Nope, you need to encrypt everything
[02:59] <pitti> right
[02:59] <siretart> hunger: iwj did the change, please discuss that with him
[02:59] <pitti> but that was said to work?
[02:59] <siretart> hunger: he was asking for comments for that change, and nobody was able to give reasonable arguments. I think you might be able to convince him.
[03:00] <hunger> siretart: OK, The changelog entry was sailing under your name:-)
[03:02] <Hobbsee> pitti!
[03:02] <Hobbsee> hehe :)
[03:02] <pitti> Hobbsee: how are you, oh my mistress of Kubuntu?
[03:02] <Hobbsee> pitti: could be better.  i *seriously* dislike the physics subject i'm doing now.
[03:04] <soren> Hobbsee: Are they claiming your LPSoD doesn't work and/or exist?
[03:05] <cjwatson> hunger: in general, encryption is not the piece of cryptography that I'd look to to provide integrity
[03:05] <Hobbsee> soren: havent tried, actually
[03:05] <hunger> cjwatson: What else to use?
[03:06] <cjwatson> hunger: hashes on a separate secured medium?
[03:06] <hunger> cjwatson: Without encryption anybody that can get access to your HDD can change stuff on it.
[03:06] <cjwatson> please read some introductory texts on security
[03:06] <soren> hunger: Depends. Are you most worried about people messing with your data or about now knowing if they've done so?
[03:06] <cjwatson> encryption's primary purpose is confidentiality
[03:07] <cjwatson> you can sometimes get integrity out of it but there are much better ways
[03:07] <hunger> soren: Basically I am doing full disk encryption. With cryptsetup (which is what I have to use) that amounts to encrypting all the partitions I have.
[03:07] <cjwatson> since practically all of /usr is shipped in Ubuntu packages, I expect I could probably replace your separate encrypted /usr with an entirely new blob and you might well not notice
[03:08] <cjwatson> since /var tells me what packages are installed and that's not encrypted unless you encrypt all of /, and if you do that and keep /usr on the same partition as / then you don't have a problem here
[03:08] <hunger> cjwatson: /var is a seperate partition here and of course encrypted.
[03:09] <cjwatson> the problem is only if you encrypt /usr and keep it separate from /
[03:09] <cjwatson> don't do that, then
[03:09] <hunger> cjwatson: And replacing /usr with a new blob will not work without a key:-)
[03:10] <hunger> cjwatson: Seperate / and /usr is traditionally done (even though it is not much use anymore), so having that break when both are encrypted seems very strange to me.
[03:10] <cjwatson> it's necessary for the time being
[03:11] <cjwatson> would you rather we provided encryption as long as you don't have a separate /usr, or no encryption at all?
[03:11] <cjwatson> have you read the reason why that restriction is there for the time being?
[03:12] <hunger> cjwatson: maintainability.
[03:12] <cjwatson> false
[03:12] <cjwatson> I conclude therefore that you have not
[03:12] <hunger> cjwatson: Why not move those two libs to /lib?
[03:12] <hunger> cjwatson: I read the changelog entry. Not that much info in it:-)
[03:13] <cjwatson> it would be possible to move them, yes
[03:13] <cjwatson> it simply has not been done yet, and somebody needs to work out what to do with the initramfs
[03:13] <cjwatson> it is not necessary to overreact to the restriction, given that cryptsetup was only moved into main literally this morning
[03:17] <bigon> dholbach: are you there?
[03:42] <alex-weej> if we're in UVF now does this mean we're not getting GTK 2.12 / GNOME 2.20?
[03:42] <ogra> gnome has a general freeze exception
[03:42] <alex-weej> ogra: right
[03:42] <ogra> so dont worry ;)
[03:42] <alex-weej> there are several tooltip fixes in GTK trunk that i'm really starting to long for :P
[03:52] <dholbach> bigon: yes
[03:53] <bigon> dholbach: I've posted a comment about bug #138027
[03:53] <ubotu> Launchpad bug 138027 in empathy "Please merge empathy (0.12) from debian (main)" [Undecided,In progress]  https://launchpad.net/bugs/138027
[03:53] <dholbach> bigon: good, I'll check my mails in a bit
[04:16] <asac> siretart: with network-manager 0.6.5-0ubuntu11 installed, try to switch networks and you will eventually see huge delays for some wpasupplicant operations when looking at tail -f syslog
[04:17] <dholbach> bigon: it can't use python-distutils.mk for that reason, but the python packaging items I mentioned are ok to use
[04:21] <bigon> dholbach: I don't see how it can be done since DEB_PYTHON_SYSTEM is only use in python-distutils.mk
[04:24] <stgraber> asac: did you change something about wpa_supplicant in the latest NM upload ? looks like it now correctly disconnects here (I just tried suspending/resuming my laptop and it reconnected correctly instead of waiting for 10s)
[04:25] <asac> stgraber: he? well i uploaded my opennet branch
[04:25] <asac> stgraber: it tries a bunch of things to properly shutdown nm ... its DISABLE_NETWORK + AP_SCAN 0 + TERMINATE now iirc
[04:25] <asac> s/shutdown nm/shutdown wpasupp)
[04:26] <stgraber> asac: ok, maybe I just was lucky. I'll use it as usual and see if I have any unwanted behaviour
[04:26] <asac> stgraber: so you say that suspend/resume is fixed?
[04:26] <stgraber> looks like yes
[04:26] <asac> stgraber: i have a bunch of bugs about that I would be happy to close ;)
[04:26] <stgraber> let me try 4-5 more time then :)
[04:26] <asac> thanks :)
[04:27] <bddebian> Heya
[04:32] <dholbach> bigon: I'm not sure it is
[04:33] <ScottK> There's always a traditional debian/rules with calls to dh_pysupport or dh_pycentral.
[04:36] <bigon> dholbach: http://www.pastebin.be/5235
[04:37] <stgraber> asac: argh, I had two kernel freeze (I'll check what happens later), but NM worked almost correctly (it just took 3s to disconnect once, otherwise it was already disconnected)
[04:37] <dholbach> doko: is DEB_PYTHON_SYSTEM only for python-distutils.mk?
[04:38] <doko> dholbach: yes, I think so, part of cdbs
[04:38] <dholbach> doko: so the variable isn't used anywhere else?
[04:43] <doko> dholbach: not 100% sure, but I don't think so
[04:43] <asac> stgraber: thanks
[04:44] <dholbach> thanks doko
[04:44] <dholbach> pitti: you can upload bughelper, if you like
[04:44] <dholbach> bigon: in that case, that's ok :)
[04:44] <Hobbsee> asac: got any thoughts on https://bugs.launchpad.net/ubuntu/+source/mozilla-thunderbird/+bug/133171 ?
[04:44] <pitti> dholbach: bughelper?
[04:44] <ubotu> Launchpad bug 133171 in mozilla-thunderbird "moztraybiff (tray icon enabler extension) doesn't work in gutsy version of thunderbird 2" [Undecided,New]
[04:44] <pitti> dholbach: I just did a p-lp-bugs upload
[04:44] <bigon> dholbach: great :)
[04:44] <dholbach> pitti: sorry, I meant that
[04:45] <asac> Hobbsee: yes ... thanks
[04:46] <doko> pitti: please could sync ecj (fixing current build failures seen on my rebuild tests)
[04:46] <dholbach> pitti: I think I was quicker with my upload than you with yours :-/
[04:47] <slavik> who is responsible for maintaing the drivers in the restricted driver manager?
[04:47] <pitti> dholbach: as long as you got all three commits, that's fine :)
[04:47] <asac> Hobbsee: now "triaged" :)
[04:47] <dholbach> pitti: 3 commits?
[04:47] <pitti> slavik: me for the UI part, the actual drivers -> kernel team
[04:47] <pitti> dholbach: if you have r48, all is well
[04:48] <slavik> where can I get in contact with the kernel team?
[04:48] <slavik> or should I file a bug on launchpad?
[04:48] <pitti> dholbach: but my push worked, so you didn't push your 'release' changes before uploading...
[04:48] <pitti> slavik: #ubuntu-kernel should do
[04:48] <slavik> the nvidia driver is horribly outdated on feisty, but I dunno if it's worth submitting a bug atm.
[04:48] <slavik> haven't checked gutsy yet
[04:48] <pitti> slavik: no, it's not; we will only fix gutsy
[04:48] <StevenK> slavik: Did you try nvidia-glx-new?
[04:48] <pitti> slavik: (it's not worth it, that is)
[04:49] <pitti> slavik: but what StevenK says
[04:49] <StevenK> There is in fact, three Nvidia drivers in Feisty
[04:49] <superm1> is restricted manager making choices as to when to use nvidia-glx-new or nvidia-glx now too then?
[04:49] <pitti> superm1: no, those lists are shipped in l-r-m
[04:49] <slavik> StevenK: nvidia-glx-new is also outdated IMO (but I haven't tried) after the restricted manager's driver failed, I installed the one from nvidia's site, the 100.xx series
[04:49] <Hobbsee> asac: :)
[04:50] <superm1> but in theory nvidia-glx-new will work on all the hardware that is supported by nvidia-glx too though
[04:51] <StevenK> slavik: I can't think of any reason to use 100.x instead of -new on Feisty.
[04:51] <paran> superm1: that is not true.
[04:51] <pitti> superm1: s/all/most/
[04:51] <pitti> dholbach: I got an accept mail
[04:51] <slavik> StevenK: does -new support 8800 series?
[04:52] <superm1> paran, pitti didn't realize that there was hardware support dropped in the newer releases. (other than the break off between regular release / legacy )
[04:52] <pitti> dholbach: erk, I mean a reject mail
[04:53] <StevenK> slavik: So it would seem.
[04:53] <pitti> dholbach: erk, I mangle a new changelog and reupload then
[04:54] <paran> superm1: nvidia maintains two "legacy drivers" 1.0-71xx, 1.0-96xx and one current "100.14.11"
[04:54] <dholbach> pitti: ok, thanks
[04:54] <superm1> paran, ugh that really makes for a bad taste in my mouth.
[04:54] <slavik> -new in feisty is 97xx
[04:54] <pitti> doko: synced
[04:54] <cjwatson> mvo: did you notice that your gnome-app-install 0.4.8-0ubuntu2 upload was rejected?
[04:55] <slavik> also, would it be worth it writing a GUI bind zone configurator?
[04:55] <cjwatson> mvo: I think your .dsc had a different md5sum for the .orig.tar.gz
[04:55] <mvo> cjwatson: oh, thanks
[04:56] <StevenK> mvo: Does that also fix the sexy-python -> python-sexy issue?
[04:56] <paran> superm1: yeah, it sucks. off course they all have different ranges off supported cards.
[04:56] <doko> pitti: thanks
[04:56] <mvo> StevenK: yes
[04:56] <superm1> paran, ah ha: http://www.nvidia.com/object/IO_32667.html
[04:56] <StevenK> mvo: Great!
[04:56] <superm1> that explains it all
[04:57] <paran> superm1: anyway, all the three are in gutsy. packages nvidia-legacy, nvidia-glx and nvidia-new
[04:58] <StevenK> nvidia-glx-legacy and nvidia-glx-new
[04:58] <paran> oops :)
[04:58] <superm1> paran, i'm hunting for a good way to query which one should be installed during ubiquity-frontend-mythbuntu yet.
[04:58] <superm1> so i might just end up parsing the file shipped with l-r-m
[05:02] <superm1> so what happens when they introduce another legacy series? :)  nvidia-glx-new-new?
[05:02] <Hobbsee> wow, we can certainly tell that pitti is back
[05:03] <StevenK> I think -new is a hold-over from Debian
[05:03] <StevenK> Didn't Khensu have a Plan[tm]  or something?
[05:03] <pitti> StevenK: no, it was a gross hack to avoid breakign edgy->feisty upgrades
[05:03] <StevenK> Ah ha
[05:04] <StevenK> Well, I feel suitably dirty now.
[05:04] <pitti> I'm still in favor of merging them all into just one package and select at runtime by modaliases
[05:04] <pitti> but packaging-wise, that's very complicated
[05:04] <superm1> especially since they all need to ship libGL?
[05:04] <pitti> still, the current 'splitting' approach cannot be continued endlessly
[05:05] <pitti> it forces us to install obsolete versions, duplicates maintenance, and cannot be supported
[05:05] <pitti> hi mathiaz
[05:05] <pitti> mathiaz: are you aware of the current AA profile breakage? I think it's due to kernel/userspace desync
[05:05] <superm1> well this splitting approach will eventually turn into a nvidia-glx-71xx nvidia-glx-96xx, gnvidia-glx-100xx and so on so forth if its continued i'd anticipate
[05:05] <StevenK> Personally, I'm with pitti on this one.
[05:06] <mathiaz> pitti: yes. that's correct.
[05:06] <StevenK> pitti: Agreed, just thinking about it, it's a big mess to sort out, but I think it's a big win.
[05:07] <mathiaz> pitti: The new kernel module has been uploaded on friday.
[05:07] <pitti> mathiaz: so it'll be updated soon? it blocks some bug fixes from me
[05:07] <mathiaz> pitti: now what needs to be done is to update the userspace in main.
[05:07] <mathiaz> pitti: I already have everything in my brz branch, but I need a bit more testing
[05:08] <mathiaz> pitti: and then it needs to be reviewed by a core-dev ( keescook )
[05:08] <pitti> mathiaz: ah, cool; you rock
[05:09] <StevenK> pitti: So the new package ought to be nvidia-glx, or nvidia-glx-all or nvidia-glx-unified?
[05:09] <dholbach> bigon: one more thing: maybe we should change the branch to the one LP in debian/control?
[05:09] <pitti> StevenK: -glx preferably, with C/R/P:'ing the others
[05:10] <dholbach> bigon: unless we can sync completely?
[05:10] <StevenK> pitti: *nods*
[05:10] <StevenK> pitti: I seriously doubt it would fly for Gutsy
[05:11] <ion_> pitti: https://launchpad.net/hardware-connected should help with the scripting part of making a package choose the correct nvidia driver version at runtime.
[05:13] <superm1> ion_, still, but how do you get around the versions of all the other libraries that are shipped in those packages?
[05:13] <superm1> adjust lots of symlinks on the fly?
[05:14] <bigon> dholbach: done
[05:14] <ion_> superm1: Yeah, thats what update-alternatives(8) is for.
[05:14] <dholbach> bigon: rock
[05:14] <bigon> dholbach: there still not merged ubuntu changes so we can sync
[05:15] <dholbach> bigon: we can't sync at the moment, because of the different conflicts/replaces, no?
[05:15] <superm1> currently no support under update-alternatives for all of the libGL family though, so that would need to be added as well, but does sound sensible
[05:15] <bigon> dholbach: yes but there are also haze tp profile that are not yet in debian packages
[05:16] <dholbach> bigon: right, yeah
[05:19] <superm1> paran, pitti the nvidia-supported script in restricted-manager only generates listings for 'nvidia' and 'nvidia_legacy', so it would appear that restricted-manager isn't even offering support as of yet for the nvidia-glx-new stuff
[05:20] <pitti> superm1: /usr/share/linux-restricted-modules/2.6.22-11-generic/modules.alias.override/nvidia
[05:20] <pitti> superm1: that's shipped by l-r-m itself, as I said above
[05:20] <ion_> superm1: Bug #134245
[05:20] <ubotu> Launchpad bug 134245 in linux-restricted-modules-2.6.22 "[gutsy]  restricted driver namager claims 2 nvidia drivers in use" [Undecided,In progress]  https://launchpad.net/bugs/134245
[05:22] <superm1> ah okay and that file is looking identical to what was generated by nvidia_supported in the restricted manager source package.
[05:27] <bigon> dholbach: what will you doing with bug #132928 ?
[05:27] <ubotu> Launchpad bug 132928 in devscripts "debcommit: add options to specify changelog path" [Unknown,Fix committed]  https://launchpad.net/bugs/132928
[05:30] <dholbach> bigon: http://launchpadlibrarian.net/8856581/devscripts_2.10.7ubuntu2.diff3 is in debian svn then?
[05:30] <geser> bigon: have you talked with StevenK about it as he cares about devscripts for now?
[05:31] <bigon> geser: no I dont
[05:31] <bigon> dholbach: is checking
[05:31] <mvo> cjwatson: how card will it be to add the feisty-backports/debian-install release-upgrader udebs on the alternative CD to support pre-requists on the CD?
[05:33] <cjwatson> mvo: trivial, stick them in a new section in the ship seed
[05:33] <cjwatson> or maybe the installer seed
[05:33] <mvo> cjwatson: nice! thanks, I will check that out today
[05:33] <cjwatson> probably ship
[05:34] <cjwatson> mvo: yeah, should be ship as otherwise dependency expansion will do bad things to the installer seed's output
[05:34] <cjwatson> mvo: oh, hang on. feisty-backports.
[05:34] <dholbach> bigon: the empathy patch looks good otherwise
[05:34] <cjwatson> ok, that's actually sort of annoying
[05:35] <cjwatson> mvo: it'll probably have to be a debian-cd patch
[05:35] <dholbach> bigon: going to upload in a bit, might take a bit for the new binaries to go through binary new though
[05:35] <bigon> dholbach: ok
[05:35] <dholbach> bigon: let me know if you confirmed that the devscripts upload is ok
[05:35] <dholbach> bigon: for command line changes, I'd be happier if they were made upstream first
[05:35] <mvo> cjwatson: ok, thanks
[05:36] <cjwatson> mvo: do they need to be in the CD's Packages files?
[05:36] <cjwatson> in fact, do you need separate Packages files for them?
[05:36] <cjwatson> as in /dists/feisty-backports/...
[05:37] <bigon> dholbach: the cmd line option has been change in debian svn too (i'm sure) what I'm not sure is that the patch is _exactly_ the same
[05:37] <dholbach> bigon: if you could check, I'd appreciate that and upload ASAP
[05:39] <mvo> cjwatson: some form of packages file for them would be good as the release-upgrader searches for them within the apt cache and also checks the signatures via the regular apt mechanisms. but this could be worked around for the CD if required (its very handy for the network bits)
[05:40] <dholbach> bigon: I just want to know if it's ok that your change is going to be assumed as 'is in debian already', when somebody does a merge
[05:40] <cjwatson> mvo: the phrase "argh" comes to mind, but I'll see what I can do. could you file a bug on bugs.launchpad.net/ubuntu-cdimage so that I don't forget?
[05:41] <mvo> cjwatson: yes, I will dig into it a bit and file a bug
[06:02] <pitti> BenC: do you happen to know if the Intel 4965 WiFi chipset works under Linux?
[06:03] <BenC> pitti: using it right now :)
[06:03] <pitti> BenC: oh, cool :) thanks
[06:03] <BenC> supported by the iwl4965 driver in gutsy's lum package
[06:03] <pitti> BenC: (just looking for a new laptop)
[06:04] <bigon> dholbach: I've made a patch with changes directly taken from the debian svn (for bug #132928)
[06:04] <ubotu> Launchpad bug 132928 in devscripts "debcommit: add options to specify changelog path" [Unknown,Fix committed]  https://launchpad.net/bugs/132928
[06:04] <dholbach> BenC: do you think I should assign review bugs for the kernel team to canonical-kernel-team instead of ubuntu-kernel-team?
[06:04] <dholbach> bigon: you rock
[06:05] <BenC> pitti: might I suggest the dell xps m1330
[06:05] <pitti> BenC: I'm currently looking at the Latitude D430
[06:05] <pitti> BenC: I want a 12" one
[06:05] <BenC> dholbach: mainly we did that for private bugs, but I don't see why we couldn't use it to highlite bugs
[06:05] <bddebian> *cough*
[06:06] <BenC> pitti: the 1330 is a 13", but it's really light (sub 2lbs)
[06:06] <dholbach> BenC: thanks a lot - it's not that many bugs coming that way anyway
[06:08] <bddebian> Doesn't lsmod show relationships?
[06:08] <pitti> BenC: how long does the battery last?
[06:08] <Hobbsee> bddebian: hmm
[06:08] <BenC> pitti: I have the low-end battery, and it's 2:10
[06:09] <BenC> pitti: they have three battery options for it, I would guess max is probably 5-6 hours
[06:09] <pitti> BenC: ah, nice; I have a list of candidates, and I throw away everything < 5 hours
[06:09] <dholbach> bigon: uploaded
[06:09] <BenC> pitti: it has webcam and finger-print reader options too, and you can also get 3g card for it
[06:09] <bigon> dholbach: thx
[06:10] <dholbach> bigon: thank YOU
[06:10] <BenC> internal 3g, not like a cardbus card
[06:10] <dobey> hola dholbach
[06:10] <dholbach> heya dobey
[06:10] <dobey> how's it goin?
[06:11] <dholbach> dobey: good good - how are you?
[06:11] <dobey> doing alright
[06:12] <dobey> pondering on how to architect this rss parsing code a bit
[06:12] <dobey> and what to get for lunch
[06:17] <dobey> and i'm starving, so thinking about code is hard right now :P
[06:17] <dobey> bbiab, later
[06:18] <dholbach> hehe, enjoy your meal :)
[06:20] <edulix> hi
[06:20] <edulix> networkmanager - is there any of its developers over here?
[06:22] <doko> Riddell-awa: I left some bug reports open as exercise for the kubuntu team (build failures with 4.3 in core kde packages) ;-)
[06:23] <Hobbsee> doko: so i noticed.
[06:23] <Hobbsee> doko: and the trick to fixing them is?  (disclaimer:  hvae only seen titles fo the bug reports so far)
[06:24] <bddebian> Oh crap Riddell..  Hmm, what package was that again...
[06:24] <doko> Hobbsee: I assume these should be already fixed in kde4 (Riddell told me that this is test-built against newer g++ versions), so maybe look in the upstream archives?
[06:25] <Hobbsee> ah right, so there is no quick-fix, per se
[06:26] <doko> Hobbsee: maybe for the kde packages (missing includes), but afaik you have your own repo, and there are still other packages to fix ..
[06:27] <Hobbsee> doko: true.  i was more asking in the general case, rather than for each kde app specifically
[06:27] <doko> Hobbsee: different bugs in different packages,
[06:28] <Hobbsee> doko: true, i was wondering if the fix was the same in all cases.
[06:28] <doko> and I hate to figure out what to patch in qt, what does generated, and so on ...
[06:28] <Hobbsee> right
[07:02] <pitti> doko: wow, taking over the archive again? :-)
[07:03] <Hobbsee> it seems to be a race of who can take over gutsy-changes - doko or pitti
[07:03] <doko> Hobbsee: doing just maintainer change uploads is unfair ;-P
[07:04] <Hobbsee> hehe
[07:16] <geser> pitti: have you time to upload boost? bug #134684
[07:16] <ubotu> Launchpad bug 134684 in boost "Upgrade to Version 1.34.1" [Wishlist,In progress]  https://launchpad.net/bugs/134684
[07:20] <doko> pitti: did I ask for ecj -2, not -5?
[07:20] <doko> the sync
[07:26] <pitti> doko: I just synced whatever was in sid
[07:27] <pitti> doko: if it's wrong, please file a sync bug or ask Mithrandir/seb128, I need to leave for Taekwondo now
[07:29] <doko> Mithrandir: please sync ecj 3.3.0+0728-5 (bug 138542)
[07:29] <ubotu> Launchpad bug 138542 in ecj "sync request" [Undecided,New]  https://launchpad.net/bugs/138542
[08:33] <geser> keescook: Hi, do you see any reason why bug #91426 should be kept marked as private/security issue?
[08:33] <ubotu> Bug 91426 on http://launchpad.net/bugs/91426 is private
[08:34] <keescook> geser: no idea.  weird.
[08:35] <geser> ok, then I'll make it private
[08:36] <geser> s/private/public/
[08:45] <xhaker> bdmurray, what about that ubuntu-qa membership?
[08:48] <bdmurray> xhaker: I'm looking at it now. Thanks for the reminder.
[08:50] <asisak> (BTW I was also convinced we are at -bugs based on the latest twenty minutes :))
[08:51] <keescook> mjg59: around?  I was curious about bug #37234.  You mention that using SHMConfig is a security risk.  Is it larger than just local users being able to tweak the touch pad?  (i.e. does it allow them to reach into other memory areas?)
[08:51] <pygi> doko, ping
[08:51] <ubotu> Launchpad bug 37234 in xserver-xorg-input-synaptics "synaptics should allow runtime configuration (eg. Option SHMConfig on)" [Wishlist,Confirmed]  https://launchpad.net/bugs/37234
[08:51] <pygi> Your final survey is in there. Not the one we need from your mentor.
[08:51] <pygi> It is now past due and we will need to enter it. If you have not already
[08:51] <pygi> done so please contact your mentor and let him know that we have still not
[08:51] <pygi> received your final evaluation and it will have to be entered in.
[08:51] <pygi> Thanks,
[08:51] <pygi> Tiffany G
[08:51] <pygi> ergh, sorry :D
[08:51] <pygi> :-/
[08:51] <pygi> apologies
[08:57] <bdmurray> xhaker: could you join ubuntu-bugs?
[08:58] <xhaker> bdmurray, ubuntu-bugs seems to be "invite" only
[09:00] <bdmurray> The irc channel #ubuntu-bugs ?
[09:29] <keescook> bryce: do you know where I can find the source for the synaptics driver?  Is it in xorg-server?
[09:31] <keescook> ah, duh: xserver-xorg-input-synaptics
[09:31] <ogra> :)
[09:31] <keescook> heh.  clearly I need more coffee.  :)
[09:38] <pygi> siretart, poke
[09:41] <tormod> keescook: can I bug you with some ubuntu-main-sponsor'ing? I have some debdiffs lost/stuck in the queue, some should really be in before Gutsy release...
[09:44] <keescook> tormod: sure, which bugs?
[09:44] <tormod> bug #127273
[09:44] <ubotu> Launchpad bug 127273 in laptop-mode-tools "laptop-mode init script links not created" [Undecided,Confirmed]  https://launchpad.net/bugs/127273
[09:46] <tormod> bug #114793, bug #131858, bug #83690 (ok, the last one is not so critical)
[09:46] <ubotu> Launchpad bug 114793 in linux-wlan-ng "linux-wlan-ng fails compilation" [Medium,Triaged]  https://launchpad.net/bugs/114793
[09:46] <ubotu> Launchpad bug 131858 in grub "Update-grub does not add savedefault anymore" [Undecided,New]  https://launchpad.net/bugs/131858
[09:46] <ubotu> Launchpad bug 83690 in grub "update-grub hardcodes to 'Ubuntu'" [Undecided,Confirmed]  https://launchpad.net/bugs/83690
[09:47] <tormod> keescook: the three first are no-brainers, they just need a little push :)
[09:47] <keescook> tormod: okay, I'll go look through them (just need to finish up a few other things first)
[09:47] <tormod> keescook: thanks a lot!
[09:48] <keescook> tormod: np :)
[10:20] <keescook> tormod: I'd like to let mjg59 handle 127273 -- I'm not sure what is "correct" for the acpi script removal.  he'd know better.
[10:22] <keescook> tormod: 114793 will need a UVFe, but that should happen without too much issue, I think.
[10:25] <tormod> keescook: can you give mjg a ping about 127273? he seems to have forgotten about it.
[10:25] <keescook> tormod: I think we already have now (he's online in this channel)  :)
[10:27] <tormod> keescook: 114793, UVF would be much better than patching the outdated Ubuntu version. The problem is that few developers have the card themselves so few know the package: trust Debian and me :)
[10:28] <keescook> tormod: yeah, I trust you for 114793 -- that's why I think the UVFe will go fine.  I just can't help with it personally -- I'm not on the UVFe team.  :)
[10:29] <keescook> the two grub updates look fine to me.
[10:31] <tormod> keescook: any suggestion for who to ask about 114793? It's been in the u-m-s queue since June...
[10:32] <keescook> tormod: for that, I think you'll need to subscribe ubuntu-release and explain the situation (https://wiki.ubuntu.com/FreezeExceptionProcess)
[10:32] <keescook> once they've ACK it, then a core-dev can upload it.
[10:50] <keescook> tormod: grub fixes uploaded though.  I really like the title fix.  :)
[10:50] <tormod> keescook: thanks!
[10:51] <keescook> np
[10:52] <tormod> keescook: just added UVF rationale to 114793. damn bureaucracy :)
[10:52] <keescook> hehe, yeah.
[10:52] <keescook> okay... late lunch time!  back in a bit...
[10:53] <tormod> keescook: enjoy your meal :)
[10:54] <siretart> pygi: huh?
[10:54] <pygi> siretart, just wanted to say I've committed cdrkit support in Gnomebaker
[10:58] <siretart> pygi: cool!
[10:59] <pygi> siretart, ofcourse that's only in svn (not released)
[10:59] <pygi> but it works pretty nicely
[10:59] <pygi> siretart, it has a user preferences part where you can choose what to use if you have both cdrtools and cdrkit installed
[11:00] <siretart> ah. I see
[11:00] <siretart> well, I assume its mostly a matter to call the right tool. the commandline interface should be the same, ain't it?
[11:01] <pygi> siretart, a tiny difference in addressing the devices if I'm not mistaken
[11:06] <siretart> aha?
[11:08] <pygi> bus,target,lun not working any more or something like that since 1.1.5 I think
[11:17] <siretart> oh. thats... interesting
[11:21] <pygi> siretart, I do remember tsmetana of fedora was telling me something about that
[11:26] <mdke> can anyone help with this build error: http://paste.ubuntu-nl.org/37052/ ?
[11:29] <stdin> mdke: is there a configure script?
[11:30] <mdke> stdin: I don't really know anything about how the package works, lemme see
[11:31] <mdke> there is a configure.in
[11:31] <stdin> I think that'll be for autoconf to make the configure script
[11:35] <mdke> stdin: yes
[11:38] <mdke> any idea on the error?
[11:39] <thom> mdke: ***Error***: You must have automake >= 1.9 installed
[11:39] <thom> do as it says :)
[11:39] <mdke> thom: hmm. guess the build-deps are wrong
[11:40] <thom> guess so
[11:40] <mdke> or maybe that doesn't count as a build dep
[11:40] <mdke> I'll try, thanks
[11:41] <thom> well, it's a dependency for it to build, so it definitely is
[11:41] <mdke> thom: I think perhaps that is more building the source package, rather than the binary
[11:41] <mdke> anyway, seems to have worked :)
[11:47] <tormod> keescook: just saw that 114793 was assigned to canonical-kernel-team today, it's been assigned around in circles forever... Also very reassuring since their home page says "Do not use this team, use ubuntu-kernel-team instead."