[00:01] <sconklin> DoYouKnow: https://wiki.ubuntu.com/KernelMaintenance
[00:03] <DoYouKnow> ty
[00:18] <maxb_> On my Thinkpad T40p, since upgrading to intrepid, the "mute" key has turned into a "lock screen" key. I'm a bit lost as to how to debug, or which package to file a bug against
[00:52] <DoYouKnow> System->preferences->keyboard
[00:53] <DoYouKnow> did you look there?
[00:53] <DoYouKnow> check this link out:
[00:53] <DoYouKnow> http://ubuntuforums.org/showthread.php?t=633403
[00:53] <DoYouKnow> it's on changing the keymap
[00:54] <DoYouKnow> click on keyboard moel
[00:54] <DoYouKnow> *model
[00:54] <DoYouKnow> and check if the right one is selected
[01:15] <superm1> kees, awesome! thanks
[01:24] <fta> to who's behind http://patches.ubuntu.com, please extract the series/00index files, it's confusing upstream when some patches are listed there but are not applied in reality
[01:25] <lifeless> fta: what do you mean 'extract'
[01:25] <stgraber> lifeless: I guess, basically only showing patches that are applied (the ones in 00list) instead of all patches with no way to know which are actually applied
[01:25] <fta> lifeless, referring to " /by-release/extracted/ubuntu"
[01:26] <lifeless> stgraber: I can guess as well, but fta knows!
[01:26] <lifeless> fta: sorry, please be more clear. Do you want the file shown, do you want patches that aren't in it not shown? details..
[01:27] <fta> either way is fine, the current way is not :)
[01:30] <fta> lifeless, maybe it's easier to only extract the active patches and keep the indexes hidden (as upstream is not always aware of what quilt and dpatch are)
[01:53] <ScottK> fta: Do you have experience with upstreams that browse p.u.c directly?  IME usually it's a link to a specific patch in a bug report so they know which to look at.
[01:54] <fta> ScottK, yes, mozilla, they are currently reviewing our patches for xul and firefox
[01:55] <ScottK> I see.  In that case I can see how it could be a bit confusing.
[01:55] <fta> ScottK, we have a long list of patches, it's easier that way, compared to using the branch on code.lp
[01:57] <ScottK> I wonder if there's some bzr-whatever_they_use_now (Hg I think?) plugin where they could pull the branch in and review it in their own VCS?
[02:03] <fta> it's hg, they have hgweb, a clone of gitweb, and several web tools to dig into the code
[02:04] <fta> but for a quick patch review, p.u.c is nice
[02:10] <piju_> hello, how can i make a suggestion in packages ?
[02:13] <hyperair> piju_: what dyou mean?
[02:16] <piju_> hyperair, wants to suggest to put newer version of package
[02:19] <piju_> hyperair, i think squid 2.7 is better than squid 2.6, but squid 3 is different version from 2.* that is why there is two version of squid in debian/ubuntu packages
[02:22]  * hyperair has no idea
[02:22] <hyperair> well file a bug on launchpad.net
[02:23] <hyperair> speaking of which.... squid 2.7 is in ubuntu
[02:23] <hyperair> piju_: ^
[02:23] <hyperair> so what's your point exactly?
[02:24] <piju_> hyperair, ok thanks
[02:24]  * hyperair is confused
[02:24] <piju_> my points is, ubuntu user can use the benefits of squid 2.7
[02:24] <piju_> thats all
[02:25] <piju_> im not ruining ubuntu
[02:25] <hyperair> well
[02:25] <hyperair> squid 2.7 is in ubuntu
[02:25] <hyperair> so
[02:25] <piju_> if u feel like im such a jerk. its ok. just forget it
[02:25] <hyperair> i don't understand
[02:25] <hyperair> seriously
[02:25] <hyperair> nono there's some miscommunication or something. =.=
[02:26] <piju_> pool/main/s/squid/squid_2.6.18-1ubuntu3_i386.deb
[02:26] <piju_> still 2.6
[02:26] <hyperair> that's in older versions of ubuntu
[02:26] <hyperair> ubuntu intrepid has squid 2.7
[02:26] <hyperair> dyou mean you want squid 2.6 backported?
[02:26] <piju_> really ?
[02:26] <hyperair> yep
[02:26] <piju_> intrepid has squid 2.7 ?
[02:26] <hyperair> yep
[02:27] <hyperair> ubuntu hardy has squid 2.6, intrepid has squid 2.7
[02:27] <piju_> ok. nevermind. coz im using hardy now.
[02:27] <hyperair> ah
[02:28] <piju_> hyperair, thanks. maybe squid 2.7 can be backported in hardy
[02:29] <hyperair> yeah you can file a backport request in launchpad.net =)
[02:29] <piju_> ok. thanks
[02:49] <woody86> any body have problems updating their packages after upgrading to 9.04? I try to do a partial upgrade, but then it says "Can not upgrade. An upgrade from 'jaunty' to 'intrepid' is not supported with this tool"
[02:49] <woody86> and that's using update manager
[02:51] <wgrant> woody86: If you don't know how to fix that or why it happenns, you shouldn't be using Jaunty.
[02:52] <woody86> wgrant- well thanks for such an informative response. I'm in the MOTU mentor program right now, and my Mentor wanted me to install 9.04 so he could teach me stuff using 9.04, but he's not online right now to ask
[03:15] <ScottK> woody86: Who is your mentor?
[06:42] <dholbach> good morning
[06:56] <dholbach> the kill switch for wifi on my IBM X40 does not work any more (intrepid), does anybody else have the same problem? what can I do to debug it? loading the ipw2100 does "work", but the wireless LED is still not blinking
[07:07] <soren> dholbach: Your X40 has a wifi kill switch?
[07:07] <dholbach> soren: well the FN-F5 thing
[07:07] <soren> dholbach: Oh, that.
[07:07] <dholbach> right now it just toggles bluetooth on and off
[07:07] <dholbach> but no wifi workie workie
[07:07] <soren> :(
[07:11] <slangasek> dholbach: the wireless in the IBM X40 is ipw2100?
[07:12] <dholbach> slangasek: yep
[07:12] <dholbach> I'm just talking to amitk on #ubuntu-kernel - let's see what he can find :)
[07:13] <slangasek> dholbach: do you have a /sys/class/net/$dev/device/rfkill directory?  I think each driver has to be converted to that individually and I don't have any idea if ipw2100 has; the acpi-support stuff should still support the old interfaces as well, but that's probably untested in intrepid
[07:14] <dholbach>   /sys/devices/platform/thinkpad_acpi/rfkill
[07:14] <dholbach>   /sys/devices/platform/thinkpad_acpi/rfkill/rfkill0
[07:14] <dholbach>   /sys/class/rfkill
[07:14] <dholbach>   /sys/class/rfkill/rfkill0
[07:14] <dholbach>   /sys/module/rfkill
[07:17] <dholbach> slangasek: http://paste.ubuntu.com/70342/ - it worked like 2 days ago with intrepid, but does not work now
[07:17] <slangasek> hum
[07:17] <slangasek> so no under /sys/class/net/$dev/device/rfkill ?
[07:17] <slangasek> s/under //
[07:18] <dholbach> what I pasted above is the output of   find /sys/ -name "*kill*"
[07:18] <slangasek> ok
[07:18] <slangasek> hopefully you still have /sys/class/net/$dev/device/power/state ?
[07:20] <dholbach> daniel@lovegood:/sys/class/net$ ls
[07:20] <dholbach> eth0  lo  pan0
[07:20] <dholbach> daniel@lovegood:/sys/class/net$
[07:20] <dholbach> no, doesn't look like it
[07:20] <slangasek> is one of those your wireless?
[07:20] <slangasek> (i.e., is your wireless device named 'eth0' for some reason?)
[07:20] <dholbach> no, I'm connected via cable (eth0) right now
[07:20] <dholbach> pan0 should be some bluetooth thing I never managed to use :)
[07:21] <slangasek> mmm, you should still have the device listed there if the kernel detects it.
[07:24] <UpChuck_Norris> Just to be sure it's not the obvious solution, is your wireless card disabled (keyboard shortcut, power switch, etc.)?
[07:25] <wgrant> That sort of problem often spontaneously occurs due to the wireless card deciding to disable itself in the BIOS
[07:25] <dholbach> wgrant: alright, I'll reboot and see what the BIOS says - back in a bit
[07:25] <wgrant> I've no idea how it happens.
[07:25] <wgrant> But I'
[07:26] <wgrant> But I've seen it on a couple of different machines now.
[07:26] <dholbach> alright
[07:26] <slangasek> UpChuck_Norris: I guess you're joining us mid-conversation; dholbach's specific complaint was that the keyboard shortcut doesn't work.
[07:28] <xTr3m3> hi
[07:30] <wgrant> slangasek: Some wifi kill switches (the one on my father's HP laptop, in particular) actually drop the device off the bus.
[07:30] <slangasek> then how is un-kill supposed to work?
[07:30] <xTr3m3> ubuntu 8.10 = really great work!
[07:30] <xTr3m3> always a pleasure ubuntu to see continue to grow in every respect
[07:31] <wgrant> slangasek: It's implemented in hardware.
[07:31] <slangasek> xTr3m3: thanks, we're glad you like it
[07:31] <xTr3m3> =)
[07:31] <slangasek> wgrant: tsk
[07:31]  * wgrant likes happy users.
[07:32] <liw> I have one of those hardware kill switches, it seems
[07:32] <xTr3m3> i like it ,open source is the best for future
[07:32] <liw> except only for bluetooth, not wifi
[07:32] <wgrant> It's not quite as infuriating as Dell brightness keys, I don't think.
[07:32] <wgrant> We;ve got libsmbios to control brightness in software, but AFAICT you can't stop the BIOS from controlling the brightness.
[07:33] <wgrant> So when you unplug the AC, the BIOS drops the backlight immediately, then g-p-m puts it back up and down again in a gradient.
[07:33] <wgrant> It looks stupid, and there's no way to fix it.
[07:33] <liw> (bluetooth on usb, wifi on pci, that's probably why)
[07:35] <wgrant> The lack of dholbach after almost 10 minutes isn't promising...
[07:36] <StevenK> pitti: I didn't, since I'm bad. :-(
[07:44] <dholbach> amitk, wgrant, slangasek: seems like I'm an unhappy person today: http://people.ubuntu.com/~dholbach/img_2498.jpg
[07:45] <dholbach> (so not necessarily an Ubuntu problem)
[07:46] <mvo> dholbach: alter! *unauthorized*
[07:46] <pitti> Good morning
[07:47] <dholbach> mvo: it's built-in wireless
[07:47] <amitk> dholbach: Unauthorized?!
[07:47] <dholbach> mvo: no boot - no wireless - no laptop - no happy
[07:47] <amitk> dholbach: http://www.thinkwiki.org/wiki/Problem_with_unauthorized_MiniPCI_network_card
[07:47] <pitti> mvo: ah, ok; it was a feature, so don't flip it back and forth; I just wasn't sure whether something was weird
[07:47] <pitti> ScottK: insane-backends> coming...
[07:48] <tkamppeter> pitti, hi
[07:48] <dholbach> amitk: I can't boot the machine at all now :)
[07:48] <wgrant> dholbach: Well done!
[07:48] <wgrant> dholbach: Remove the MiniPCI card and see if it works?
[07:48] <tkamppeter> pitti, I have found a fix for bug 290395 and would like to make an SRU
[07:49] <tkamppeter> Only problem is that it is not a tiny patch but one has to replace the pdftoraster filter by another one
[07:49] <pitti> tkamppeter: uh, that sounds regression prone
[07:49] <tkamppeter> See my last comment in the bug report
[07:50] <pitti> tkamppeter: can you please sub ubuntu-sru? I'll have a look later then
[07:50] <amitk> dholbach: did you update the bios recently
[07:50] <dholbach> amitk: no, never
[07:51] <dholbach> I'm too boring for things like that
[07:51] <tkamppeter> pitti, I can perhaps also do it somehow that I add a renamed version of the filter to SpliX and also some .types and .convs files so that only SpliX uses the new filter-
[07:51] <pitti> tkamppeter: that's a good idea
[07:51] <pitti> tkamppeter: then this new filter could be shipped in the splix package itself?
[07:54] <tkamppeter> pitti, yes. This will then only be done for the INTrepid SRU package of SpliX. This will not be introduced in Jaunty. In Jaunty pdftoraster will be replaced straight-away so that it gets full 6 months to get tested.
[07:54] <pitti> tkamppeter: sounds like a good plan
[07:56] <tkamppeter> pitti, the filter will be renamed to pdftosplixraster and by conversion rule it produces data of format splix-raster. The SpliX PPDs will then get patched to accept splix-raster as input.
[07:57] <tkamppeter> And this will be made exclusively for Intrepid, not for Jaunty.
[08:05] <tkamppeter> pitti, see my last comment on bug #290395
[08:06] <tkamppeter> pitti, does this work? Can I make a new Intrepid package for SpliX for the SRU without needing to upload it into Jaunty?
[08:07] <pitti> tkamppeter: if the corresponding filter change is one in jaunty (in cups, I assume?), that's fine, yes
[08:08] <tkamppeter> pitti, so I should do the Jaunty changes at first?
[08:09] <tkamppeter> pitti, this means that I remove pdftoraster and its .tconvs rule from CUPS, add the new filter and the .convs rule to Ghostscript.
[08:09] <pitti> tkamppeter: it should be done by the time it goes into -updates; you can do the SRU first, if you are currently working on it
[08:10] <tkamppeter> pitti, the cups/ghostscript change also affects Debian, as CUPS is synced.
[08:10] <pitti> tkamppeter: I guess that's intended?
[08:12] <tkamppeter> pitti, yes. Debian should also get equipped with the better pdftoraster filter. We only have to do it in a way so that the time where Debian is incomplete (filter taken from CUPS but not yet added to ghostscript) as short as possible.
[08:12] <pitti> tkamppeter: why does it need to move anyway?
[08:13] <tkamppeter> pitti, but you can probably also upload Ghostscript into Debian, simply applying the debdiff of my next Ubuntu Ghostscript to it.
[08:14] <stefanlsd> Anyone use jigdo on Ubuntu that needs an updated Ubuntu mirror list, or is it ok as is?
[08:14] <tkamppeter> pitti, it has to move as I have placed my pdftoraster filter in the upstream repository of Ghostscript, as pstoraster is already there. The Poppler-based pdftoraster is in the Ubuntu/Debian package of CUPS and upstream neither in CUPS nor in Ghostscript.
[08:32] <pitti> tkamppeter: no, I can't upload gs into debian
[08:33] <pitti> tkamppeter: but you should file a debian bug with the changes and ask the maintainer to upload to experimental, so that we can do the cups change in experimental, too
[08:33] <pitti> tkamppeter: until that happens, we have to fork cups
[08:34] <pitti> tkamppeter: or put a copy of the new pstoraster into cups
[08:35] <tkamppeter> pitti, there will probably not be an interruption, if someone happns to have the new CUPS package with pdftoraster removed but not the new Ghostscript with pdftoraster added, CUPS will automatically take a PostScript path using pstoraster. So if Debian's ghostscript maintainer does not follow quickly, most users will not see any problem.
[08:35] <pitti> tkamppeter: that shuold be done with a versioned dependency on ghostscript
[08:36] <dholbach> slangasek, wgrant, amitk, mvo: it was a hardware problem, I took out the minipci card, dusted it off, put it back in again and the machine is happy again :)
[08:37] <tkamppeter> pitti, so as the removal of pdftoraster from CUPS does not cause any breakage and as CUPS trunk is currently only in experimental, I think I will commit the removal to BZR now and the Ghostscript change will probably follow soon, as the gs maintainer can simply take my changes from the Ubuntu gs package.
[08:38] <pitti> tkamppeter: ok, if that works (I think I did try to remove pdftoraster, and that broke with a "filter not found" error)
[08:38] <tkamppeter> pitti, as soon as the pdftoraster-equipped gs package appears in Debian, the CUPS package of Debian will get a versioned gs dependency.
[08:39] <tkamppeter> pitti, you cannot simply take away a filter under a running CUPS daemon. You must also take away pdftoraster.convs and restart CUPS.
[08:40] <pitti> ah, I didn't remove the .convs
[08:41] <wgrant> dholbach: How strange...
[08:42] <dholbach> wgrant: my X40 is 4+ years old, so it was just the off-dusting and re-plugging :)
[08:44] <hyperair> dholbach: you have an ibm x40?
[08:44] <dholbach> hyperair: yes
[08:44] <hyperair> dholbach: how's suspend on it?
[08:45] <dholbach> hyperair: it works :)
[08:45] <hyperair> resume with backlight?
[08:45]  * wgrant likes having a 3 year old laptop - pretty much all of the hardware works fine in Ubuntu.
[08:45] <hyperair> how very strange. must be one of those models which works
[08:46] <hyperair> wgrant: mine's 3 months old and everything works =D
[08:46] <siretart> Mithrand1r: (or anyone involved in pkg-config): I've brought up the pkg-config issue on the ffmpeg-devel mailing list, you can read about it here: http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/76897
[08:46] <siretart> anyone else, that is.
[08:49] <dholbach> slangasek, wgrant, amitk, mvo: thanks for your help!
[09:06] <tkamppeter> pitti, I have built the new cups 1.3.9-4 and tested it. It actually works without pdftoraster by going the pstoraster way. I have pushed it into the Debian BZR now.
[09:07] <pitti> tkamppeter: can you please refer to the ghostscript debian bug in the changelog, so that it's easy to find?
[09:08] <tkamppeter> pitti, the Ghostscript Debian bug I will post as soon I have the new Ghostscript package. Then I can directly provide the patch.
[09:08] <pitti> tkamppeter: ok, great
[09:14]  * pitti fixes ubuntu-dev-tools buildd to work with pockets
[09:23] <viviersf> can someone tell me, why when i use an ubuntu alternate cd to make changes to isolinux default config, and rebuild the iso, i get a invalid cdrom error ?
[09:27] <viviersf> Mithrand1r, you still in charge of this ?
[09:28] <Mithrand1r> viviersf: no, and I haven't been in a long time.
[09:28] <Mithrand1r> viviersf: unsure why you should get that error, though.
[09:30] <viviersf> Mithrand1r, :(
[09:30] <slangasek> dholbach: n/p, glad to hear you have it working again!
[09:30] <viviersf> Mithrand1r, who does the alternate cd installer stuff these days ?
[10:01] <cjwatson> wgrant: we already un-deadlocked jaunty PPAs earlier yesterday; cprov said they're enabled now
[10:02] <wgrant> cjwatson: Yep, they're enabled. I spoke to him a few hours ago.
[10:03] <wgrant> Thanks.
[10:03] <cjwatson> viviersf: exactly what command did you use to rebuild the CD?
[10:49] <kirkland> mvo: hiya
[10:50] <kirkland> mvo: I looked at your revision 410
[10:52] <mvo> kirkland: excellent, thanks!
[10:53] <mvo> kirkland: how do you feel about it?
[10:53] <mvo> kirkland: oh, I see the mail now
[10:53] <sebner> pitti: mighty pitti! what's now with audacious? :P
[10:53] <kirkland> mvo: very similar to what I was going for in an early revision of the shell script, so i like the concept
[10:54] <kirkland> mvo: see what you think, about apt-check always writing the human-readable output (and translated) to /var/run/updates-available
[10:54] <pitti> sebner: this morning I noticed that ports buildds were clogged; I bumped the build score of all SRUs, and many have caught up now; can move as soon as hppa built it
[10:54] <sebner> pitti: ah I see, thx! sry for the trouble
[10:59] <DigitalSpirit> j
[11:04] <viviersf> cjwatson, mkisosfs ?
[11:05] <viviersf> cjwatson, hold, mkisofs -J -R -l -V "Ubuntu" -b isolinux/isolinux.bin -no-emul-boot -boot-load-
[11:05] <viviersf> size 4 -boot-info-table -z -iso-level 4 -c isolinux/isolinux.cat -o
[11:05] <viviersf> ./autoinstall.iso newiso/
[11:05] <viviersf> cjwatson, i got that from a canonical whitepaper
[11:11] <cjwatson> viviersf: I am interested to know which, since it's slightly at variance with the options we use for our own images
[11:12] <cjwatson> viviersf: try: mkisofs -r -V 'Ubuntu 8.04 i386' -o autoinstall.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table newiso
[11:12] <cjwatson> viviersf: if you can give me the URL of the white paper I may be able to get it corrected
[11:28] <viviersf> cjwatson, robin barley-wagner mailed it to us
[11:28] <cjwatson> viviersf: thanks
[11:28] <cjwatson> viviersf: can you confirm that the options I give make it work?
[11:29] <viviersf> cjwatson, im gonna try it quick, gimme a sec
[11:29] <cjwatson> viviersf: also, at what point does it fail? is it a BIOS-type message, or is it a blue screen with an error message from the installer?
[11:30] <viviersf> cjwatson, its a big red message from the installer
[11:31] <cjwatson> viviersf: oh. In that case you probably just forgot to copy over the .disk directory
[11:31] <viviersf> oh!
[11:31] <viviersf> *dumbass*
[11:31] <viviersf> lol
[11:32] <viviersf> cjwatson, ill try with that dir quick
[11:33] <jordi> slangasek: it isn't on a 64-bit capable system running a 32 bit install (with a 64 bit kernel?)
[11:35] <jordi> slangasek: honestly, I don't know much about this stuff, my personal desktop is a very modern Athon 800, which wasn't too capable of anything last time I checked ;)
[11:41] <viviersf> cjwatson, thanks allot :) it works
[11:42] <viviersf> cjwatson, using a kickstart file, i get a busybox "uknown option : -l"
[11:42] <viviersf> is that a known problem ?
[11:42] <cjwatson> viviersf: yes, bug 293586 :-(
[11:43] <viviersf> cjwatson, and how do i bypass that ? :(
[11:44] <cjwatson> 8.04 ...
[11:44] <cjwatson> or preseeding
[11:44] <cjwatson> sorry about this, entirely my fault
[11:45] <viviersf> cjwatson, lol, i need to deploy 8.10 with kickstarts, can i create a new disc with a different busybox-udeb somehow ?
[11:45] <viviersf> cjwatson, or can i use a 8.04 cd to install a 8.10 desktop ?
[11:46] <cjwatson> viviersf: I have no easy solution to offer you right now
[11:46] <viviersf> cjwatson, ok
[11:46] <cjwatson> viviersf: https://launchpad.net/~kamion/+archive contains a fixed busybox
[11:46] <cjwatson> viviersf: but you'd need to rebuild debian-installer against that
[11:47] <viviersf> ugh
[11:47] <viviersf> cjwatson, if i use network mirror for 8.10, would a 8.04 cd be able to install it ?
[11:48] <ogra> eeek, Riddell can you reject my latest xf86-input-evtouch upload ? i accidentially set the distro to interpid-updates instead of intrepid-proposed
[11:48] <ogra> i'll re-upload with the proper target
[11:49] <cjwatson> viviersf: no
[11:49] <pitti> ogra: done
[11:50] <Hobbsee> ogra: thrown out.
[11:50] <Hobbsee> pitti: beat you :)  *throws a gummy bear to you*
[11:50] <cjwatson> viviersf: you could use http://people.ubuntu.com/~cjwatson/tmp/intrepid-busybox-fix/netboot/ if netboot is OK for you
[11:50] <pitti> ok, Hobbsee beat me by 0.5 seconds
[11:50] <ogra> gracias !
[11:50] <Hobbsee> pitti: \o/  Even with aussie lag!
[11:50] <cjwatson> viviersf: there's a mini.iso there too
[11:50] <cjwatson> viviersf: only i386 at the moment though
[11:50] <pitti> Hobbsee: in this case it was my IRC reading lag :)
[11:50] <Hobbsee> heh :)
[11:50] <viviersf> cjwatson, i want i386 and as long as i installs im happy ;) thx
[11:53] <directhex> hurrah. mono 2.0-1: no universe build-deps
[11:56] <mvo> kirkland: thanks for your mail, I just replied :)
[11:57]  * mvo goes to get some food
[12:14] <pitti> ogra: was there any progress wrt. the dhcp3 next-server option patch upstream?
[12:14] <ogra> pitti, no, and there wont be ever (the discussion predates our patch btw)
[12:16] <ogra> upstream simply disagrees with our view, jammcq (ltsp) has discussed it several times with them and mdz and i decided to add it on a package level instead so that our users arent affected, i would stil like to keep it until upstream finally releases a v4.x
[12:17] <pitti> ogra: ok, fine
[12:17] <pitti> oh, it's fixed in 4.x?
[12:17] <ogra> no idea, but if there is a 4.x users wont be shoked if features changed
[12:17] <tkamppeter> pitti, I have made a new Ubuntu package of gs, filed a bug against Debian gs to take the new pdftoraster (Debian bug 505282), and added the bug number to the CUPS changelog. This changelog I have pushed to bzr now. Now you should be able to upload the CUPS package to both Debian and Ubuntu.
[12:18] <ogra> the thing is that they removed the feature in a minor update where nobody would expect it to vanish
[12:18] <tkamppeter> pitti, tell me when you have uploaded the new cups package so that I can upload ghostscript to Ubuntu.
[12:18] <pitti> tkamppeter: cool, thanks; building now
[12:19] <ogra> pitti, there is no "fix" for disagreement ;) the change is less of a surprise in a new version though
[12:19] <pitti> ogra: ah, ok; (disclaimer: I never understood what this patch is all about, just monkey-porting)
[12:19] <ogra> we'll go with whatever will be in v4.x but should keep the patch during the 3.x cycle
[12:21] <pitti> argh apt
[12:21] <ogra> its about userfriendlyness, next-server used to default to the dhcp server itself if unset (so tftp gets automatically requested from the same machine on netboot), at some point upstream decided to force it to 0.0.0.0 if unset which breaks all existing setups
[12:21]  * pitti wonders whether he'll ever remember auto-remove (option) vs. autoremove (command)
[12:22]  * mvo wonder if he should add a alias option for autoremove for pitti
[12:23] <pitti> mvo: just teach me harder :)
[12:23] <ogra> pittiremove ?
[12:23] <ogra> especially helpful before vacations :)
[12:24]  * mvo add --teach-pitti-harder
[12:24]  * mvo add --teach-pitti-harder-with-a-big-whip
[12:24] <pitti> mvo: rrrrrr
[12:25] <mvo> lol
[12:27] <kirkland> mvo: hiya!
[12:29] <kirkland> mvo: if you'd prefer, the updates-available shell script could actually be python
[12:29] <kirkland> mvo: update-motd doesn't care...  it just executes the scripts/links in those dirs
[12:29] <mvo> kirkland: either way is fine with me
[12:30] <kirkland> mvo: the same goes for notify-reboot-required ...  in python, the translation of that string might be easier (more consistent with the rest of the code)
[12:30]  * mvo nods
[12:30] <kirkland> mvo: i'm grabbing some lunch, will catch up in a bit ;-)
[12:31] <mvo> kirkland: ok, cool
[12:31] <mvo> kirkland: I think we are 99% there now :)
[12:31] <mvo> kirkland: a upload today for it should be feasible
[13:48] <pitti> tkamppeter: cups uploaded to debian and jaunty
[14:07] <Ng> mvo: does update-manager emit the power management inhibiting things while it's working?
[14:08] <mvo> Ng: yes
[14:08] <Ng> mvo: so that would disable suspend and hibernate, but presumably not reboot/shutdown?
[14:08] <mvo> Ng: yes, I would like to add reboot/shutdown to this too, I haven't figured out yet how to do this
[14:09] <tkamppeter> pitti, thanks, I will upload gs now. I have already test-built it and with it installed the correct filter chain is used and bug 290395 actually fixed.
[14:09] <Ng> mvo: fair enough. I just fixed an install where the user had shutdown instead of locking the screen, by mistake ;)
[14:09] <mvo> Ng: in the office?
[14:09] <Ng> mvo: yup
[14:09] <mvo> Ng: I make it a priority
[14:10] <Ng> mvo: while I was thinking about that, I also wondered if it would make sense to refuse to upgrade, or at least display scary discouragements, if the user is just on battery
[14:10]  * mvo scratches his head
[14:10] <mvo> that would make sense
[14:11] <Ng> I think scary discouragements would be the better option than just refusing to do it
[14:12]  * ScottK would find refusing really annoying.
[14:13] <tkamppeter> pitti, gs is uploaded now.
[14:14] <Ng> ScottK: yeah, I think i would too, but I would appreciate being reminded that I'm risking my sanity :)
[14:15] <ScottK> I think a warning is fine.  I can imagine thinking "Yes, but I have hours of batter left and I just have to walk across the room to plug in.  I just don't feel like it right now."
[14:15] <ScottK> batter/battery
[14:20] <hyperair> could someone take a look at pm-utils debian/patches folder? it seems that the 99 patch comes before the 85 patch in debian/patches/series
[14:20] <hyperair> how very strange
[14:20] <hyperair> ah nevermind. as long as it builds =.=
[14:35] <tdomhan> if you want to request a new feature for ubuntu, do you file a blueprint, or should you file a wishlist bug?
[14:36] <directhex> what kind of feature?
[14:36] <cjwatson> users should not file blueprints
[14:37] <cjwatson> blueprints are software design documents and should generally be written by developers
[14:37] <tdomhan> kk, was just curious what the process is
[14:38] <cjwatson> generally speaking a wishlist bug is perfectly reasonable if it's a relatively small and contained feature (though you may have to argue with bug triagers who are confused about the validity of the concept of wishlist bugs), while more complex and vague ideas should go on brainstorm.ubuntu.com
[14:38] <emgent> evening
[14:38] <tdomhan> ok thx
[14:39] <tkamppeter> pitti, I have another idea about the garbage printing in bug 292690
[14:41] <tkamppeter> The splix package has a patch against crashing when it gets fed with data with a wrong paper size: debian/patches/no-crash-on-bad-papersize.patch
[14:41] <tkamppeter> pitti, the patch applies to a part where a lot of page margin calculations are done.
[14:43] <tkamppeter> pitti, in src/document.cpp, from line 114 on there is some calcualtion for clipping done. Probably something is mis-calculated there.
[14:44] <tkamppeter> pitti, for example from line 131 on the clipping is applied to the page height, but there is no such thing for the width.
[14:45] <tkamppeter> pitti, as you have the printer you could perhaps find out what needs to be corrected.
[14:46] <Shoopuf> Destruction of erratic volume sliders is on my Christmas wish list.
[14:54] <pitti> tkamppeter: I can try without the patch, for a start
[14:56] <tkamppeter> pitti, OK
[15:53] <mvo> james_w: is there anything like a "pre-build-command" hook in bzr-buildpackage? I would like to run ./autogen.sh automatically when doing the package build
[15:53] <tkamppeter> pitti, SRU for bug 290395 uploaded
[15:54] <james_w> hey mvo, check out file:///usr/share/doc/bzr-builddeb/user_manual/hooks.html
[15:56] <mvo> james_w: exactly what I want, thanks!
[15:56]  * mvo waves good-by to his arch-build targets
[15:58] <pitti> mvo: !
[15:58]  * mvo hugs james_w
[15:58] <mvo> rrrrrrrrrrrrrrrrrr
[15:58] <pitti> mvo: bzr-builddeb FTW?
[15:58] <mvo> good stuff!
[15:58] <mvo> ftw!
[15:59] <mvo> how about a policy "bzr-buildpackage" must build it and the whole discussion of "how packages in bzr should be hanleded" is moot?
[16:00] <mvo> bzr commit -m 'debian/rules: byebye arch-build"
[16:01] <tkamppeter> pitti, I have uploaded a splix for bug 290395 into -proposed, can you approve it?
[16:02] <directhex> hm. did someone come up with a plan to allow package selection in the installer, whilst i wasn't looking? or are my dodgy sources talking their usual crap?
[16:04] <cjwatson> directhex: no
[16:04] <directhex> cjwatson, crap being talked, then? doesn't surprise me
[16:06] <cjwatson> directhex: well, in order to answer that, I'd need to know what was actually said - this is sort of a subtle area
[16:06] <cjwatson> there have been some suggestions, but nothing that immediately translates into something implementable, and nothing that's been a high enough priority to get me to sit down and work it out
[16:06] <directhex> cjwatson, it's from the anti-mono crowd, so you can guess their plan
[16:07] <directhex> i think the phrasology was "keep that microsoft/novell trap out of my hardware" button
[16:07] <directhex> i think they're confused by the disable-restricted-plz option when booting the install disc these days
[16:10] <pitti> mvo: do you have a minute for bug 296819? the previous SRU was a bit incomplete and missed a product ID on the balcklist
[16:12] <pitti> tkamppeter: BTW, I usually add the verification-needed tag and instructions when accepting a package, so you don't need to do that
[16:14] <mvo> pitti: looking
[16:15] <mvo> pitti: hm, i945? *urgh*
[16:16] <cjwatson> directhex: sounds like it
[16:16] <pitti> mvo: itz bad?
[16:26] <mvo> pitti: yes, i945 is very common and pretty recent, blacklisting that will affect a lot of system
[16:26] <mvo> pitti: I talk to #ubuntu-x about this first I think
[16:27] <pitti> mvo: ok, thanks; seems to be a deeper issue then
[16:28] <mvo> pitti: thanks, I work on it, but I have a bad feeling about it, there are not many cards (from intel) if we blacklist i945 entirely
[16:28] <pitti> mvo: yeah, absolutely; let's not for now
[16:28] <pitti> mvo: all i945 have the same product ID?
[16:29] <mvo> pitti: not sure, for some cards (IIRC 830) there is only one, for others there are multiple ones, I need to find out more about it
[16:29] <mvo> pitti: dosn't your dell have a i945?
[16:29] <mvo> or was thas a 965 already?
[16:29] <pitti> 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
[16:30] <pitti> mvo: it's a 945, but product ID 27a2
[16:30] <pitti> hm, wait
[16:30] <pitti> I *also* have a 27a6
[16:30] <pitti> that's the one I pasted above
[16:30] <pitti> the 27a2 is
[16:30] <pitti> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
[16:31] <mvo> pitti: hm, could you try compiz on it? does it hang on login for you too?
[16:31] <pitti> mvo: I have run compiz for months without problems
[16:32] <mvo> pitti: thanks, do you mind if I put that into the report?
[16:33] <pitti> mvo: already done
[16:33] <mvo> heh .) thanks
[16:45]  * cjwatson considers converting usplash to unifont
[16:45] <Keybuk>     -> copying [./libs]
[16:45] <Keybuk> cp: cannot stat `./libs': No such file or directory
[16:46] <Keybuk> my pbuilder-fu is not strong - what does that mean?
[16:50] <jpds> Keybuk: I usually see that when one doesn't do "pbuilder build" on the *.dsc file.
[16:50] <Keybuk> hmm, I gave it the changes file
[16:52] <Keybuk> silly thing
[16:53] <Keybuk> sbuild is so much easier
[16:53] <Keybuk> but not the "done thing"
[17:01] <Keybuk> geser: around?
[17:05] <persia> Why isn't sbuild the "done thing"?  Lots of us use sbuild.
[17:07] <geser> Keybuk: yes
[17:11] <Keybuk> geser: I was looking at your lockfile-progs
[17:11] <Keybuk> and something caught my eye
[17:11] <Keybuk> lockfile-progs (0.1.11ubuntu2) intrepid; urgency=low
[17:11] <Keybuk>   * Merge with Debian unstable (0.1.11-0.1)(LP: #242086).
[17:11] <Keybuk> why that version?
[17:11] <Keybuk> shouldn't it be 0.1.11-0.1ubuntu1 ?
[17:12] <persia> 0.1.11-0.1ubuntu1 < 0.1.11ubuntu1
[17:12] <Keybuk> or is there a missing debian/changelog entry for an 0.1.11ubuntu1 (based off 0.1.11 assumedly?)
[17:12] <Keybuk> persia: there's no 0.1.11ubuntu1 mentioned in debian/changelog
[17:12] <persia> This is the fundamental issue with not always using -0.0ubuntu1 when ubuntuising native packages.
[17:12]  * persia refrains from further comment
[17:13] <Keybuk> ah, Soyuz says there _was_ an 0.1.11ubuntu1
[17:13] <Keybuk> geser: when merging, it's always best to preserve the merged changelog
[17:15] <geser> Keybuk: if I remember correctly the old Ubuntu changes got merged in Debian but due to the versioning we needed that fakesync/fakemerge
[17:15] <geser> the other change was needed to get it build
[17:16] <Keybuk> even then, I always try and preserve the ubuntu changelog
[17:31] <liw> https://bugs.launchpad.net/ubuntu/+source/system-cleaner/+bug/285614 -- is there something I can do interpret those stack traces? it's a SEGV inside the Python interpreter, and I don't see any reason why my code would cause that to happen
[17:49] <Keybuk> \sh: you really don't need to mention the policy maintainer change in debian/changelog
[19:23] <RainCT> Symlinking the changelog is correct (and automatically done) in Ubuntu, right?
[19:24] <RainCT> (I'm about to file a bug against lintian asking for the debian-changelog-file-is-a-symlink not to be shown for Ubuntu packages, but want to be sure first :))
[19:43] <ScottK> RainCT: Only for CDBS packages it is done (IIRC).
[19:53] <infinity> RainCT: It's only correct if the package has a dependency on the package that ships the correct changelog.
[19:53] <infinity> RainCT: And I could have sworn that lintian's check as smart enough to grasp that (note: when checking an entire .changes, not when checking a single deb)
[19:54] <RainCT> infinity: ah, I get such complains when checking .deb's
[19:55] <infinity> RainCT: There's no way it can know if one .deb is correct when it's not self-contained.
[19:55] <infinity> RainCT: It *IS* a bug for a .deb to not ship a changelog.  But if something else from the same source ships the changelog, and the changelog-less deb depends on it, that's fine (hence you need to be checking the upload as a whole).
[19:56] <infinity> RainCT: If I'm wrong, and lintian still gets it wrong when checking the entire upload, then that's a valid lintian bug. :)
[19:57] <infinity> RainCT: (In both Ubuntu and Debian... The policy I'm referring to above is Debian policy, not Ubuntu-specific)
[19:58] <RainCT> infinity: alright, thanks for the info! :)
[20:16] <cody-somerville> slangasek, can you take a look at https://bugs.edge.launchpad.net/ubuntu/+source/grub/+bug/291256 ?
[21:59] <alkisg> Hi, I'm trying to fix hotkey-setup for my laptop (acer-aspire-5900.hk). But there are some keys that I don't know where I should map them. E.g. there is an "e" key which is supposed to start Acer "Empowering Technology". Should I map this to HP_KEY?
[22:03] <alkisg> Other keys which I don't know where to map are: TV, Acer Arcade, Shortcut help, eSettings, ePower management, touchpad toggle,  euro, dollar sign. Any ideas?
[22:04] <slangasek> cody-somerville: I've merged your branch into my local branch, but haven't pushed it yet; I was thinking about changing the variable name to indomU instead of in_domU, which I think is more consistent with the existing convention, what do you think?
[22:05] <slangasek> jordi: sure, that would be on a 64-bit capable system running a 32-bit install with a 64-bit kernel.  The question is, what software is out there that uses alsa, that you would go to the trouble of running in 64-bit mode?
[22:05] <alkisg> sladen, any hints? ^^^^
[22:07] <sladen> alkisg: I think there's a POWER key we were mapping the various "open power-saving control panel" function to
[22:08] <sladen> alkisg: Acer Arcade, probably needs mapping to just one of the PROG1/PROG2 functions
[22:08] <alkisg> sladen, KEY_POWER it is then. :) The other ones? Is there any documentation in the key-constants?
[22:08] <sladen> alkisg: touchpad should be easy to spot from the other files
[22:09] <alkisg> (and I think I'll map TV to KEY_MEDIA)
[22:09] <sladen> alkisg: hopefully there's enough comments in the other manufacturer files
[22:10] <alkisg> sladen, should I include in acer-aspire-5900.hk a call to loadkeys with a "-" parameter (=read from input) to make the euro key actually send a euro character?
[22:10] <sladen> alkisg: dollah and euro aren't fixable for the moment
[22:11] <alkisg> sladen, thank you very much. I'll upload the file to the bug report and make a wiki page on how other can do the same thing for their laptops.
[22:12] <alkisg> *others
[22:13] <sladen> alkisg: the trouble is that hotkey-setup remaps things in terms of actions (volume up, load media player, ...) and not inserting raw textual sequences (ponder over how handle  alt-shift-euro
[22:15] <sladen> cloest thing would be "load Character Map" but if the kernel doesn't currently have a map for that;  then we're stuck
[22:16] <sladen> alkisg: null-mapping the might be a good second best
[22:17] <alkisg> sladen, I don't really like null-mapping because it makes the key useless, but I believe you're right, so I'll null it.
[22:18] <sladen> alkisg: looking at the acer-aspire-1600.hk  file,  I recorded the infomration in there, but left it commented out, so rather than null mapping, it's doing whatever it was doing before
[22:19] <alkisg> sladen, right, better this way. I'll look at the other files too.
[22:23] <maxb> I have a peculiar hotkey problem too. On my ThinkPad T40p, the "mute" key has become a "lock screen" key with the upgrade to intrepid
[22:23] <maxb> Any hints on how to debug, or what package to report a bug against and how to make it useful?
[22:28] <sladen> maxb: coo, that's a new one.
[22:28] <maxb_> Oh, it gets weirder :-)
[22:28] <sladen> maxb: can you do some 'acpi_listen'
[22:28] <maxb_> In the early stages of X session startup, it's working properly!
[22:28] <xTr3m3> hello ,i have a question about ubuntu 8.10... is 7zip included in ubuntu 8.10?
[22:29] <sladen> maxb: actually this rings a bell, but from 2 years ago
[22:30] <maxb_> Oh, acpi_listen is a lot easier than socat - UNIX-CONNECT:/var/run/acpi.socket :-)
[22:30] <sladen> xTr3m3: yes.
[22:30] <xTr3m3> =) ok thx...
[22:31] <maxb_> sladen: the acpi event is the one listed in /etc/acpi/events/thinkpad-mute
[22:32] <sladen> xTr3m3: if you come across a similar question again, the first thing to do could be to experiment;  and if not, try  Applications->Add/Remove  and see if you can find it searching in there
[22:32] <sladen> maxb_: have a look in System->Preferences->Keyboard
[22:33] <alkisg> sladen, in the hotkey-setup folder, there are also an "english" and a "greek" file. Do you happen to know if these get loaded, and when? (before or after the laptop hkeys?)
[22:33] <alkisg> sladen, and some keys that are "information only", like e.g. the wireless button, I shouldn't map them to e.g. KEY_WLAN, right? (like you did in aspire 1600...)
[22:34] <maxb_> sladen: "Keyboard" or "Keyboard Shortcuts"? Anyway, I've already disabled the "Lock screen" keybinding in "Keyboard Shortcuts" trying to debug this, but the behaviour is unchanged
[22:35] <xTr3m3> okay sladen ,thx for information
[22:35] <sladen> alkisg: yes;  in theory they can be listened for, then depending on whether a particular laptop does the change itself, the change can be displayed, or changed, then displayed
[22:36] <sladen> alkisg: greek file?
[22:36] <sladen> maxb_: try killing -9 gnome-power-manager tempoaryily
[22:36] <alkisg> sladen, yes, I'm greek and I have both greek + english files there... ??
[22:37] <alkisg> (and the brightness bug didn't occur when I switched the keyboard to greek!)
[22:38] <sladen> alkisg: where is 'there' (pathname?)
[22:38] <maxb_> sladen: Better... now "mute" does "volume up"
[22:38] <alkisg> intrepid - /usr/share/hotkey-setup
[22:39] <sladen> alkisg: and '/usr/share/hotkey-setup' contains greek characters?
[22:39] <alkisg> !pastebot
[22:40] <sladen> try /query
[22:40] <alkisg> sladen, http://pastebin.ubuntu.com/70714/
[22:42]  * lamont looks around for an sqlite-hacker
[22:43] <jdstrand_> kees: did you happen to see cody-somerville's dput changes?
[22:43] <jdstrand> mdeslaur: ^
[22:44] <jdstrand> kees: it allows you to do something like:
[22:45] <jdstrand> dput security:intrepid ./..._source.changes
[22:45] <jdstrand> kees: with only one entry in ~/.dput.cf
[22:45] <jdstrand> kees: it's *awesome*
[22:45] <jdstrand> go cody-somerville! :)
[22:50] <maxb_> What component is it that actually shows the volume OSD?
[22:53] <sladen> alkisg: I don't know where your 'english' and 'greek' files are coming from.  they are are _not_ a standard part of 'hotkey-setup'.  The difference in your pastebin in the Nulling out of the HELP, PROG1 and PROG2 keys
[22:55] <alkisg> sladen, default intrepid setup. I just selected "greek" when isolinux in the live cd prompted for a language
[22:55] <sladen> maxb_: on a thinkpad, mute always mutes.  It's emulated, by sending a volume up (unmute) then a mute (force mute) IIRC
[22:55] <alkisg> sladen, anyway, no big deal there. Thanks again.
[22:55] <maxb_> yeah, I have come across this in /etc/acpi/always-mute.sh
[22:55] <sladen> maxb_: mute is not a toggle on a thinkpad, so investigate it carefully if you think it's not doing as it should do
[22:55] <maxb_> well, with g-p-m killed, it seems that only the "volume up" bit is taking effect
[22:56] <sladen> maxb_: correct, but in normal operation, g-p-m _would_ be running, and right at the moment, the hardware keys still do as expected (other than for toggling mute)
[22:58] <sladen> maxb_: I thought your original issue was to do with lock and mute;  does the locking no longer occur?
[22:58] <maxb_> with g-p-m killed, locking does not occur
[22:59] <sladen> maxb_: sooo, we've narrowed it down that g-p-m is the one mis-interpreting the key-press
[23:00] <maxb_> the quirky thing is that muting then still isn't occurring which is different from what happens during the first few seconds of X login
[23:00] <cody-somerville> jdstrand, :D
[23:10] <maxb_> hrm
[23:11] <maxb_> So, on poking around in the g-p-m source, it's starting to look like X is confusing the ACPI event into an XF86XK_Screensaver keypress
[23:13] <sladen> maxb_: are there any other mappings that don't match
[23:14] <maxb_> What should I check? That last was a conjecture based on what g-p-m is logging ("Key 160 mapped to HAL key lock") and the fact that X is reading the acpi socket
[23:15] <maxb_> Interestingly, g-p-m *is* recognizing the key as "mute" - but the OSD doesn't show, and it *also* gets this "Key 160", which it takes to mean lock