[12:13] <manchicken> Amaranth: Realtek ones are fully FSF approved.
[12:13] <ijuz_> instead of getting this dell-ubuntu laptop i would rather get one with windows, you can only choose between cpu's that have 1 MB L2 cache, that is a joke
[12:13] <LaserJock> I think I'm most likely to go either System76 or Apple for my next purchase
[12:13] <Amaranth> manchicken: So you're talking USB dongle
[12:14] <stgraber> manchicken: so you basically have Dell and System76 and maybe some enterprise product from some other manufacturer
[12:14] <manchicken> Amaranth: Realtek has some built-in IIRC
[12:15] <Nafallo> efficientpc.co.uk
[12:15] <manchicken> stgraber: I've heard folks are having luck with Toshiba and Acer, too.
[12:15] <manchicken> And IBM
[12:15] <Amaranth> heh
[12:15] <manchicken> Sorry, lenovo
[12:15] <Amaranth> i tried to buy something from toshiba's website
[12:15] <Amaranth> really, i did
[12:15] <LaserJock> I'm on Toshiba now, and I don't really recommend it that much
[12:15] <manchicken> their site is even more confusing than Dell's
[12:15] <Amaranth> toshiba doesn't want you to use their website
[12:15] <stgraber> manchicken: I wouldn't recommend Acer due to some over-heating problem I had, Toshiba is fine (never asked for custom offer though) but tech support is fine (at least here in Switzerland)
[12:15] <Amaranth> they torture you for trying
[12:16] <Amaranth> manchicken: macbooks are full centrino platform
[12:16] <manchicken> stgraber: Overheating issues have multiple causes, I think if you were more careful about the components you could avoid that.
[12:16] <LaserJock> blah, Toshiba made me pay for shipping to get my laptop serviced under warranty
[12:16] <Amaranth> manchicken: i think they even have the 802.11n wifi
[12:16] <manchicken> Amaranth: Tonio_ had a broadcom with ATI
[12:16] <LaserJock> and my Toshiba had lots of overheating issues
[12:16] <LaserJock> and the hard drive likes to fall out
[12:17] <Amaranth> manchicken: that's a powerbook or a macbook pro
[12:17] <stgraber> manchicken: over-heating at the point of having the CPU socket to melt is really a problem, and I wasn't the only one to have that kind of problem :), I think they should have fixed that kind of stuff but I'm not going to buy one of their laptop anymore
[12:17] <LaserJock> I think I'll just get a mac-mini and carry it in my pocket
[12:18] <LaserJock> ;-)
[12:18] <justinwray> LaserJock: Minis are a bit bigger then that,
[12:18] <Amaranth> manchicken: they don't say if the wifi is 3945 or 4965 but the video is gma950
[12:18] <Amaranth> which sucks, actually
[12:18] <LaserJock> justinwray: depends on the size of your pocket ;-)
[12:18] <justinwray> But, seriously they are slick.
[12:18] <justinwray> Its not much bigger then a CD player/walkman.
[12:18] <Amaranth> i can fit my mini in some pockets :)
[12:19] <stgraber> LaserJock: Main problem with Mac is the graphic card which often is ATI (at least last time I checked)
[12:19] <stgraber> LaserJock: and the cost of course
[12:19] <LaserJock> stgraber: I don't care if it's ATI
[12:19] <Amaranth> stgraber: mini is full intel
[12:19] <justinwray> stgraber: Yeah, Mini is ATI.
[12:19] <LaserJock> and the cost is not so bad really
[12:19] <Amaranth> justinwray: G4 mini is ati
[12:19] <justinwray> Amaranth: Not for video.
[12:19] <LaserJock> especially if your a student
[12:19] <Amaranth> justinwray: you're talking about a mini from 2 years ago
[12:19] <bhale> the latest mini is intel 950
[12:19] <LaserJock> sweet
[12:19] <bhale> and core 2 duo
[12:19] <justinwray> Amaranth: No, I have one right next to me, just got it.  I swear its, ATI.
[12:19] <Amaranth> justinwray: you're wrong
[12:20] <Amaranth> justinwray: if it's intel CPU it's intel graphics
[12:20] <LaserJock> Amaranth: not on all macs though
[12:20] <Amaranth> They made a big deal out of trying to make you believe the gma950 was as fast as the radeon 9200 it replaced
[12:20] <Amaranth> LaserJock: Mac Mini and Macbook are full intel platforms
[12:20] <justinwray> Amaranth: I stand corrected, it is Intel.
[12:21] <LaserJock> Amaranth: right, but iMacs are intel CPU with ATI
[12:21] <Amaranth> LaserJock: Macbook Pro is nvidia
[12:21] <Amaranth> LaserJock: iMac is Radeon HD, worst possible thing
[12:21] <ijuz_> if the intel driver would be as good as the fglrx driver everything would be fine 8-)
[12:21] <ion_> Did i just say the words as good as the fglrx driver?
[12:21] <ion_> s/say/see/
[12:22] <Amaranth> ion_: Must have been a typo
[12:22] <manchicken> System76 had another price drop.
[12:22] <manchicken> They're actually very competitive with Dell now.
[12:23] <manchicken> I'm about to cancel my order with Dell and go with System76.
[12:23] <ijuz_> i'm just annoyed that the intel driver either keeps the screen completely dark after resume on my D830 or the background is full of garbage (the fglrx never ever failed on my other laptop and i suspend and resume it multiple time a day and i don't reboot it for weeks)
[12:24] <stgraber> well, last time I checked fglrx == kernel panic on tty change and no resume from sleep
[12:28] <stgraber> it was one of the reason why I change my laptop to full a full Intel one :)
[12:28] <LaserJock> Amaranth: I really like my iMac at work, I'd love to get one of the new one for home
[12:28] <Amaranth> manchicken: wow, the 15" is pretty good price
[12:28] <Amaranth> LaserJock: Radeon HD isn't supported in linux
[12:28] <manchicken> Yeah.
[12:28] <LaserJock> Amaranth: so?
[12:28] <Amaranth> LaserJock: Afaik you can't even get 2D on it
[12:28] <LaserJock> I used to run Edgy just fine on it
[12:28] <Amaranth> LaserJock: Who'd want to run OS X all the time? :)
[12:28] <Amaranth> LaserJock: No, the new iMac uses the new Radeon HD
[12:28] <LaserJock> Linux works great on it
[12:28] <Amaranth> it's an r600 series card
[12:28] <Amaranth> fglrx doesn't even support it
[12:28] <LaserJock> hmm, so no vesa?
[12:28] <manchicken> the 14" doesn't have bluetooth or 9-cell batteries.  Poop.
[12:28] <Amaranth> LaserJock: Don't think so
[12:28] <LaserJock> I just run vesa on everything
[12:28] <Amaranth> manchicken: bluetooth kills battery life
[12:28] <ijuz_> stgraber: well... my D810 doesn't resume anymore properly since about 2.6.20-rc1... (i tracked it halfway down, but i can neither nail it really down, now does anybody care) one of the reasons why i bought a new one, therefore i'm still using a <IP_ADDRESS>
[12:28] <Amaranth> Sucks that the only 7200rpm drive system76 has is 80GB
[12:28] <Amaranth> can get double that with dell
[12:28] <LaserJock> Amaranth: well, if it was fast enough I could run Ubuntu in qemu ;-)
[12:28] <Amaranth> LaserJock: You mean VMWare Fusion ;)
[12:28] <LaserJock> no
[12:28] <LaserJock> VMware Fusion just got released :(
[12:28] <Amaranth> But it does 3D, you could run compiz :)
[12:28] <LaserJock> so I'm back to using Q
[12:28] <LaserJock> blahhh
[12:28] <ajmitch> why would he want to do that?
[12:28] <Amaranth> Why would you stop using it when it got released?
[12:28] <LaserJock> all I'm using it for is a terminal, I don't need all that crap
[12:28] <LaserJock> Amaranth: it went from $0 to $80
[12:28] <Amaranth> ajmitch: bling is good for the soul
[12:29] <Amaranth> No so good for the scientist though, seeing how windowed 3D apps are mostly broken
[12:29] <ajmitch> only if you sold your soul
[12:29] <LaserJock> Q works ok for me
[12:29] <LaserJock> it's slow, but at least it's not going to cost me
[12:30] <LaserJock> if they had VMware server for OS X I'd love it
[12:32] <manchicken> System76 guarantees 8-10 day turnaround.
[12:32] <manchicken> Nice.
[12:32] <manchicken> Beats Dell's 3 week turnaround.
[12:32] <manchicken> (according to the guy on the phone)
[12:34] <LaserJock> yeah, I'm sure Dell has somebody out making the silicon for your computer as we speak :-)
[12:34] <manchicken> Killing and crushing the dinosaur for the oil to make the plastic, too.
[12:34] <LaserJock> heh
[12:36] <LaserJock> wow! System76 sells an Edubuntu server
[12:37] <ajmitch> makes sense, schools would like a server they can just drop in
[12:38] <LaserJock> yeah, it's just the first time I've ever seen anybody selling something with Edubuntu on it
[12:40] <ajmitch> a good sign :)
[12:40] <keescook> woo-hoo:
[12:40] <keescook> $ ./aslr text
[12:40] <keescook> ok: ASLR of text functional
[12:40] <ajmitch> hey keescook
[12:40] <keescook> hiya ajmitch
[12:40] <ajmitch> playing with some more security fun?
[12:41] <keescook> ajmitch: yeah, testing some kernel patches that SuSE extracted from RHEL that I hadn't gotten around to doing myself yet.
[12:43] <LaserJock> hmm, interesting. Looks like I might have tomorrow off
[12:43] <LaserJock> the transformer that does the power for campus blew and caught on fire today
[12:43] <ajmitch> keescook: anything else interesting apart from aslr?
[12:43] <ajmitch> LaserJock: ouch :)
[12:44] <LaserJock> so they sent everybody home, but apparently it's going to take a few days to get a new one set up
[12:44] <LaserJock> the whole university is down
[12:44] <ajmitch> that's impressive
[12:44] <keescook> ajmitch: went to DefCon last week; that's always fun.  :)
[12:44] <ajmitch> and probably very expensive
[12:44] <LaserJock> ajmitch: yeah
[12:44] <ajmitch> keescook: lucky you
[12:44] <LaserJock> keescook: oh nifty, you probably flew over me
[12:45] <keescook> LaserJock: where are you physically?
[12:45] <LaserJock> Reno
[12:45] <keescook> ah!  I bet I did.  :)
[12:45] <LaserJock> I shoulda flashed my Ubuntu logo
[12:45] <keescook> hehe
[12:46] <ajmitch> hm, old bugs to check - bug 9224
[12:46] <LaserJock> "What was that ... a bird .. a plane ... no it's ... Ubuntu"
[12:46] <ajmitch> I saw that debian has pam 0.99 in experimental now
[12:47] <dobey> doesn't apple use nis?
[12:47] <ajmitch> they mainly use ldap+kerberos now
[12:47] <dobey> ah
[12:48] <dobey> i totally need to set ldap+krb on my server
[12:48] <ijuz_> i thought apple would use nisplus >:->
[12:49] <LaserJock> and Linux would have nis-ng?  :-)
[12:49] <ijuz_> i fought years with nisplus on debian i hate it sooo much
[12:56] <keescook> ajmitch: PAM> nice! vorlon and I were going to work on it, but it looks like rleigh beat us.  :)
[12:57] <dobey> hey jono
[12:57] <jono> hey dobey
[12:58] <dobey> jono: what country are you in these days?
[12:58] <jono> dobey: back home in the UK now :)
[12:58] <jono> dobey: hows things over there?
[12:58] <dobey> good
[12:59] <LaserJock> Jonbo: kinda late for the UK isn't it?
[12:59] <Nafallo> almost midnight
[12:59] <Jonbo> yes, it's almost 12 there
[12:59] <LaserJock> oh right, I got home early, I was thinking it was 6-7pm here
[12:59] <Jonbo> but I'm guessing you weren't talking to me
[01:00] <LaserJock> Jonbo: sorry, was thinking jono
[01:00] <dobey> jono: just trying to get a nifty ubuntu job ;)
[01:00] <jono> LaserJock: is indeed, catching up with before I kip
[01:00] <jono> dobey: ;)
[01:02] <dobey> jono: of course, jimmac suggests the UI Dev. position would benefit best from me having it
[01:03] <ajmitch> keescook: yeah, I think it may be getting a bit close to UVF to stick it into gutsy though
[01:03] <ajmitch> and a little bit undertested
[01:04] <ajmitch> hardly up to me though :)
[01:04] <LaserJock> ajmitch: oh come on, everybody loves a little crack when it comes to security ;-)
[01:04] <keescook> ajmitch: yeah, we'll see if it flies
[01:13] <ijuz_> probably the hint that many people need generic.all_generic_ide=1 on recent hardware should be added to the release notes ;)
[06:17] <fabbione> morning guys
[06:17] <LaserJock> morning fabbione
[06:17] <LaserJock> fabbione: what time is it there?
[06:17] <fabbione> 6:17 am
[06:17] <ajmitch> morning fabbione
[06:45] <halcyonCorsair> is #ubuntu-devel the place for help with init-script issues?
[06:46] <halcyonCorsair> that is, I'm writing an init-script, and killproc / start-stop-daemon aren't behaving as i expect them to
[06:50] <Chipzz> halcyonCorsair: I believe #ubuntu-motu or #ubuntu-devel indeed is, but you may be better of asking in #ubuntu-motu first ;)
[06:54] <halcyonCorsair> ok
[08:12] <pitti> Good morning
[08:12] <ajmitch> morning pitti
[08:13] <thekorn> good morning pitti
[08:14] <StevenK> Morning pitti
[08:14] <doko_> good morning
[08:15] <LaserJock> hi pitti
[08:16] <ArneGoetje> pitti: Moin Moin!
[08:25] <pitti> aieee
[08:33] <StevenK> The zap-o-hug? That sounds painful.
[08:35] <StevenK> pitti: Can you give-back mlt on everything !i386?
[08:35] <pitti> StevenK: done
[08:35] <StevenK> pitti: Thanks. :-)
[08:36] <StevenK> pitti: All three zero-sized NBS list packages can be killed, too.
[08:39] <pitti> yay
[08:40] <StevenK> And if mlt actually builds, another four can be killed, too.
[08:51] <pitti> StevenK: looks good, only sparc remains
[08:52] <StevenK> pitti: Yup, and that should only take a few minutes.
[08:52] <StevenK> pitti: If it builds on sparc, are you happy to wave it through NEW?
[08:52] <pitti> StevenK: sure
[09:03] <sabdfl> asac: have further feedback for you on the ipw3945 issue
[09:03] <sabdfl> am having no trouble connecting to a WPA-PSK network in the office
[09:04] <sabdfl> but am unable to connect at home
[09:04] <sabdfl> i made a little wpa_supplicant.conf that is super-simple, just identifies the network and gives the password
[09:04] <sabdfl> that seems to run just fine with wpa_supplicant
[09:04] <sabdfl> in wpa_cli i can see that the association and key handshake etc completes just fine
[09:05] <sabdfl> so it seems the issue must be in network manager
[09:10] <jetscreamer> just for grins iptables -L -n
[09:18] <tbf> where do i find a quick tutorial for correcting ubuntu's translations?
[09:18] <tbf> gaim/pidgin's reconnect dialog says "Verbunden" instead of "Verbinden" for ages - want to fix it finally
[09:18] <pitti> doko: bug 118659 -> please upload
[09:18] <ubotu> Launchpad bug 118659 in pycurl "PyCurl 7.15.5 not working on AMD64" [Medium,Confirmed]  https://launchpad.net/bugs/118659
[09:26] <StevenK> pitti: mlt built everywhere.
[09:28] <Hobbsee> fricking uni connection.....
[09:31] <Lutin> StevenK: thanks for asking the give-back on mlt
[09:31] <StevenK> Lutin: No problem.
[09:31] <StevenK> Lutin: It should get waved through NEW soonish.
[09:31] <Lutin> StevenK: cool
[09:33] <asac> sabdfl: thats interesting ... how long does it take to associate at home vs. at work when you associate through wpa_cli?
[09:33] <Lutin> pitti: could you give-back avr-libc on i386 please ?
[09:34] <pitti> Lutin: done
[09:34] <doko> pitti: uploaded
[09:34] <StevenK> pitti: If you wave mlt through NEW, I should be able to get you to NBS four packages when I get home.
[09:37] <pitti> StevenK: done
[09:37] <sabdfl> asac: haven't tried at work, but at home its very fast
[09:37] <Hobbsee> *sigh*
[09:38] <asac> sabdfl: maybe a bit background why its so interesting: we found that wpa_supplicant took too long to connect with just network + password for ipw3945 ... unsetting essid manually before starting supplicant boosted the connect time, so we added this as a "hack" to network manager especially to make ipw3945 work
[09:38] <Hobbsee> would it be too much to ask as to why this connection is blowing up repeatedly today?
[09:38] <asac> sabdfl: so far I received more than one positive feedback about this move ... you are actually the first for whom it got worse ;)
[09:42] <Hobbsee> oh neat.  my connection seems to be systematically dropping. 4 drops in 40 mins.
[09:44] <Hobbsee> asac: i dont suppose yo'uve got ipw3945 stuff waiting to be tested on an open network currently?
[09:44] <Hobbsee> this network cant get too much eviler.
[09:45] <asac> Hobbsee: unfortunately not ... yet.
[09:45] <Hobbsee> asac: darn.
[09:46] <Hobbsee> asac: yet?
[09:48] <asac> sabdfl: is your home net a hidden network?
[09:49] <asac> Hobbsee: well ... to be honest ... not having ipw3945 chipset myself doesn't really contribute to get this started ;)
[09:49] <Hobbsee> asac: fair enough :)
[09:49] <Hobbsee> asac: (the stabbing implement wasnt for you - it was for whoever invented this uni connection)
[09:50] <asac> Hobbsee: but i hope to get ipw3945 with my new laptop from dell ;)
[09:50] <Hobbsee> asac: :)
[09:50] <Hobbsee> it's not that big an issue - this isnt nm problems today
[09:50] <Hobbsee> this is with straight dhclient
[09:51] <Hobbsee> so you're off the hook :P
[09:55] <pitti> hey seb128
[09:55] <seb128> hello pitti
[09:55] <Hobbsee> evening, seb128
[09:55] <seb128> pitti: I'll do syncs if that's ok with you, I didn't do archive work on wednesday because of the freeze
[09:55] <seb128> hey Hobbsee
[09:56] <pitti> seb128: I'd appreciate some help with archive stuff, I have an awful lot of stuff to do until my wedding
[09:56] <seb128> pitti: k, I'll give you an hand there ;)
[09:57] <ajmitch> hey seb128
[09:57] <seb128> hi ajmitch, it has been some time, how are you doing?
[09:57] <ajmitch> good, how are you?
[09:57] <seb128> good ;)
[09:57] <seb128> ajmitch: do you plan to update f-spot? ;)
[09:57] <ajmitch> of course
[09:58] <ajmitch> I have it built here & still segfaulting on exit :)
[09:58] <ajmitch> but it fixes a number of other annoyances
[09:58] <pitti> ajmitch: that should be fixed with latest gnome-sharp2, according to slomo
[09:58] <ajmitch> that's good, I'll have to grab that & test it
[09:59] <pitti> ajmitch: doesn't crash here any more, at lesat
[09:59] <pitti> least
[09:59] <pitti> ajmitch: (it's in gutsy already)
[09:59] <ajmitch> yeah, I haven't updated my desktop for a day or two :)
[10:03] <ajmitch> pitti: you're right, it seems to be fine now
[10:04] <ajmitch> so I'd better keep seb128 happy
[10:05] <seb128> ;)
[10:09] <ogra> seb128, fusa shows "edit users and groups" and "setup login screen" to any unprivileged user here
[10:10] <seb128> ogra: right, but it doesn't allow to run those, does it?
[10:10] <ogra> gksu doesnt, no
[10:11] <ogra> but i'm indeed asked for my password
[10:11] <asac> ok i started a forum thread to get the big picture about which network-manager setup is broken in tribe-4 and which works well ... lets see
[10:11] <seb128> right, look like a bug
[10:11] <Mithrandir> mvo: are you aware apt is unhappy wrt multiverse on i386?
[10:11] <Mithrandir> mvo: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/gutsy/multiverse/binary-i386/Packages.bz2  Hash Sum mismatch
[10:12] <seb128> feel free to open it on launchpad, I'm busy with other things
[10:12] <mvo> Mithrandir: checking
[10:12] <ogra> Mithrandir, ouch, is your apt up to date ? mo fixed that for the file protocol during tribe release for me
[10:12] <ogra> *mvo
[10:12] <stdin> happends here too
[10:12] <Mithrandir> ogra: it's a fresh debootstrap from about ten minutes ago, so yes, I would say it's fresh.
[10:13] <Mithrandir> and I see it across multiple machines, and saw it yesterday and fabbione and others are seeing it too.
[10:13] <ogra> yeah, sounds like ... and its not file://
[10:16] <mvo> Mithrandir: I do not see it here (currently), could you please run: "sudo apt-get update -o Debug::pkgAcquire::Auth=true -o Debug::Hashes=true" and put the result into a pastebin? preferable only with the multiverse line enabled?
[10:17] <mvo> Mithrandir: ah, its all good, have it here now too
[10:17] <Hobbsee> (here 3)
[10:17] <Mithrandir> mvo: http://rafb.net/p/x5ijbV15.html
[10:22] <tepsipakki> currently cdroms are mounted automatically noexec, but could that be changed?
[10:22] <mvo> Mithrandir: when I download the Packages.bz2 with wget and do sha256sum on it, I get SHA256:2dd2e520056c5454950f858fefbf0b2bf69dcc1fe9c2b0feb6b4e269c33792b6 (the same as you). but  the multiverse Release file disagrees with that
[10:22] <mvo> Mithrandir: is LP still using apt-ftparchive to generate the Packages files?
[10:23] <Mithrandir> I believe so
[10:25] <cjwatson> tepsipakki: they are? gnome-mount's defaults appear to be exec
[10:25] <cjwatson> for both iso9660 and udf
[10:26] <Mithrandir> mvo: if you're getting 2dd2, etc, your download is busted.
[10:26] <Mithrandir> : tfheen@drescher ..p.root/ubuntu/dists/gutsy > openssl dgst -sha256 multiverse/binary-i386/Packages.bz2
[10:26] <Mithrandir> SHA256(multiverse/binary-i386/Packages.bz2)= b01cf73944a4ed1cf5d6b2705412eed7134255df5d4a8110fc8ce538cf2449af
[10:28] <Mithrandir> (this matches what I get when I wget manually from archive.u.c
[10:28] <Mithrandir> )
[10:30] <Lutin> pitti: avr-libc give-back failed with the same error ( After installing, the following source dependencies are still unsatisfied: tetex-bin(inst 2007-10 ! <= wanted 3.0-30)|texlive-extra-utils(missing) ) but texlive-extra-utils is actually in the archive. do you have an idea what's wrong ?
[10:30] <mvo> Mithrandir: the .bz2 hash is ok, its the unpacked one that does not match, could you please give me the value that drescher has for this?
[10:30] <mvo> Mithrandir: the .bz2 matches the Release file and the downloaded file (for me)
[10:30] <fabbione> bzip borkage?
[10:31] <Mithrandir> mvo: ah, ok, you're right.
[10:31] <Mithrandir> : tfheen@drescher ..p.root/ubuntu/dists/gutsy > bzcat multiverse/binary-i386/Packages.bz2 | openssl dgst -sha256
[10:31] <Mithrandir> 2dd2e520056c5454950f858fefbf0b2bf69dcc1fe9c2b0feb6b4e269c33792b6
[10:32] <mvo> Mithrandir: that matches my downloaded hash and the hash that apt computed, but not the one from the Release file it seems. that is obscure
[10:33] <Mithrandir> ok, so this is a soyuz bug, possible an apt-ftparchive one
[10:34] <mvo> 4f412a01ce241da6f667310477a9ec79379cc32f175dec15fb8c0cbf7331d46e <- that is what the release file things
[10:34] <mvo> Mithrandir: I look into apt-ftparchive now to see if I can spot something and wait for cpov to show up
[10:35] <mvo> Mithrandir: apt got recently better (and stricter) in hashsum checking
[10:35] <Mithrandir> yes, this matches what's on drescher
[10:35] <Mithrandir> thanks for investigating
[10:36] <mvo> woah, it looks like the md5sum (for the unpacked one) in the Release file is correct, now that is strange
[10:38] <Mithrandir> I wonder why it only seems to affect multiverse.
[10:42] <tepsipakki> cjwatson: ok, this is on feisty.. haven't tried on gutsy, maybe it's sorted then
[10:45] <superm1> cjwatson, on that lirc bug that i submitted a debdiff on that you assigned to yourself from u-m-s(bug 129038), it appears that you didn't upload yet, so I added a newer debdiff that resolves an additional bug (bug 129689)
[10:45] <ubotu> Launchpad bug 129038 in lirc "lirc overwrote my lircd.conf" [Undecided,Confirmed]  https://launchpad.net/bugs/129038
[10:45] <ubotu> Launchpad bug 129689 in lirc "lirc install doesn't create working hardware.conf for dev/input devices" [Undecided,Fix committed]  https://launchpad.net/bugs/129689
[10:47] <mvo> Mithrandir: indeed, I wonder if there is some Packages file (or other file) on dresher with the hash 4f412a01ce241da6f667310477a9ec79379cc32f175dec15fb8c0cbf7331d46e and it confuses it for some reason. what version of apt-ftparchive is runing there?
[10:48] <cjwatson> superm1: ok, I haven't got to it yet
[10:48] <Mithrandir> > apt-ftparchive --version
[10:48] <Mithrandir> apt 0.6.45ubuntu14~cat for linux amd64 compiled on Oct  6 2006 17:59:47
[10:48] <cjwatson> thanks
[10:48] <Mithrandir> unsure if that's what soyuz uses, though
[10:48] <cjwatson> fairly sure it does
[10:49] <infinity> Yeah, that's the binary soyuz calls.
[10:50] <rgl> hi
[10:51] <rgl> are the packages maintained in some kind of revision control system?  where?
[10:51] <infinity> rgl: "The Packages"?
[10:51] <infinity> rgl: The short answer is "no".  The long answer is "some are, but not many, and in various places."
[10:51] <rgl> infinity, yes.  source of them.  like, the debian directory.
[10:52] <rgl> how do you guys keep up with the changes?
[10:52] <infinity> rgl: See the long answer.
[10:52] <infinity> rgl: A Debian archive is a revision control system in itself, really, it's not hard to sort out.
[10:52] <infinity> rgl: Diffing between arbitrary releases of a source package is trivial.
[10:53] <infinity> rgl: Some of us are fine with that, some prefer finer-grained control, and host their packages on code.launchpad.net, svn.debian.org, etc, etc, etc.
[10:53] <rgl> infinity, humm. but like, in FreeBSD, it so easy to track change, beause all the ports are in one place.  and we can see everything.
[10:54] <infinity> Debian's always been decentralised, this is nothing new.
[10:54] <infinity> And Ubuntu's just inherited that.
[10:55] <rgl> oh, I hoped that decentralised did not mean "hard to find"/etc.
[10:55] <infinity> It's never hard to find the source.
[10:55] <infinity> Nor is it terribly hard to track history.
[10:55] <infinity> It's just not in an RCS you're familiar with, that's all.
[10:55] <rgl> I mean, it could be easier :)
[10:55] <infinity> (ie: The RCS is "past source package releases")
[10:56] <infinity> Anyhow, this conversation's been had about 58 million times, and I don't think "Hey, you should be more like FreeBSD ports" will change anything today. :P
[10:57] <rgl> for example, I want to backport clamav to dapper (because I don't understand why the verstion there is so ansient) and it fails :|
[10:57] <infinity> How do you envision a revision control system making the backport magically work? :)
[10:57] <_StefanS_> bryce: you there?
[10:57] <rgl> infinity, hehe.  I'm not saying to change.  I just find it somewhat harder to find things.
[10:58] <rgl> infinity, it would make it easier to see why the author modified the debian files.
[10:58] <Riddell> infinity: did you give back strigi?
[10:58] <infinity> Riddell: Nope.  Will right now.
[10:58] <Riddell> infinity: kvkbd too if you could
[10:58] <Mithrandir> I did now
[10:58] <infinity> rgl: The Debian changelog should be reasonably verbose on that score, one would hope.
[10:58] <infinity> rgl: If it's not, commit messages wouldn't be any more informative.
[10:59] <tepsipakki> cjwatson: a fresh tribe4 installation mounts my cd's as noexec :)
[10:59] <rgl> infinity, how can I diff all the source packages?  is there a tool for this?
[10:59] <rgl> debdiff?
[10:59] <infinity> rgl: debdiff package_1.dsc package_2.dsc
[11:00] <infinity> Riddell: Done.
[11:00] <Riddell> thanks
[11:01] <rgl> I have to download them all, since the release of dapper to the one on gutsy?   known anything that automates that?
[11:01] <infinity> rgl: Err, I guess you'd do that if you really wanted to see what changed in each one...
[11:01] <infinity> rgl: I'd just start with diffing dapper->gutsy and seeing what jumps out, personally.
[11:01] <pitti> Lutin: hm, maybe the dependency resolver isn't clever enough to figure that out
[11:02] <hype_> do anyone know if libX11-xcb will be "included" in ubuntu? i mean gutsy +1 or somehting?
[11:02] <tepsipakki> hype_: gutsy+1 for sure
[11:02] <hype_> nice
[11:03] <hype_> is it buildable on ubuntu atm? (feisty,gustsu?)
[11:03] <tepsipakki> yes
[11:03] <hype_> is flash the only major prolem? and no need to compile it from source, its not in, feisty's repos by exemple
[11:03] <tepsipakki> flash?
[11:04] <hype_> -no
[11:04] <Lutin> pitti: btw, can you give-back darkice {amd64,ppc} please ?
[11:04] <hype_> i mean "need to compile"
[11:04] <tepsipakki> hype_: you need to enable xcb in libx11
[11:04] <tepsipakki> and rebuild it
[11:04] <hype_> okok
[11:05] <tepsipakki> hype_: but what do you mean flash being a problem?
[11:05] <pitti> Lutin: done
[11:05] <hype_> i saw this around
[11:05] <Lutin> pitti: tahnks
[11:05] <hype_> tepsipakki , did you try it?
[11:05] <tepsipakki> hype_: yes, when it was enabled in feisty
[11:06] <tepsipakki> java is the major problem atm
[11:06] <pitti> tkamppeter: hi
[11:06] <hype_> ho sorry, your right java
[11:06] <pitti> seb128: do you have objections against replacing gnome-cups-manager with system-config-printer?
[11:06] <hype_> tepsipakki , was it enebled before release or somthing?
[11:06] <seb128> pitti: no
[11:06] <infinity> rgl: Let me guess.  You're blatantly ignoring versioned build-deps, and the change to use ${binary:Version} in debian/control is breaking?
[11:06] <tepsipakki> hype_: for a while yes
[11:07] <infinity> rgl: (From a quick scan of the changelog, that looks like the obvious backport killer)
[11:07] <hype_> ok, and theu removed it because of java?
[11:07] <pitti> seb128: modulo the UI improvements that were discussed recently
[11:07] <seb128> pitti: gnome-cups-manager is not maintaining for years and has its lot of bugs, if we can use something maintained that's better
[11:07] <pitti> tkamppeter: ok, then I'm going to change the seeds now
[11:07] <tepsipakki> hype_: something like that
[11:07] <pitti> seb128: yeah, and Tim Waugh is even reading LP bugs
[11:07] <hype_> ok :)
[11:07] <seb128> pitti: ah, that's nice ;)
[11:08] <Mithrandir> mvo: no file with the same sha256sum
[11:08] <mvo> Mithrandir: I *think* this is really a soyuz bug, IIRC the release file is not generated by apt-ftparchive so I need to nag cprov about it
[11:08] <rgl> infinity, I just lifted the debian/control dependency on dpkg-dev to the version on dapper.
[11:09] <Mithrandir> mvo: I've asked cprov to prod me when he comes online
[11:09] <mvo> Mithrandir: cool, thanks
[11:10] <rgl> infinity, I mean.  I'm trying to build the gutsy version, on dapper.
[11:11] <pitti> seb128: wow, s-c-p + hal-cups-utils together is smaller than g-c-m \o/
[11:11] <seb128> ;)
[11:11] <seb128> doko: do you know about bug #131497 ?
[11:11] <ubotu> Launchpad bug 131497 in sysvinit "Please update sysvinit to version >= 2.86.ds1-38.1 asap" [Undecided,New]  https://launchpad.net/bugs/131497
[11:12] <pitti> we didn't merge that for over a year, that's going to be a bit delicate
[11:12] <seb128> pitti: read the bug please
[11:12] <infinity> rgl: Right, but the versioned build-dep was there for a reason, not "Just Cause". :)
[11:12] <pitti> seb128: erk
[11:12] <pitti> lamoooooooooooooooooont
[11:12] <cjwatson> tepsipakki: that's not hardcoded in the installer ... *shrug*
[11:13] <seb128> pitti: right, looks like lamont did the update
[11:13] <doko> seb128, pitti: hrm, so who wants to volunteer? I'll have to look at this then ...
[11:13] <rgl> infinity, I'm don't known what is that sorry.  I'm kinda new to backporting or even making debian packages.
[11:13] <doko> iff nobody else wants ...
[11:13] <tepsipakki> cjwatson: what do you mean? This is not the live-session
[11:13] <coNP> Can a core-dev please review a/o sponsor my magyarispell update package (Hungarian spell checker 0.99 -> 1.2)? It has been put to http://www.inf.bme.hu/~aron/ubuntu/magyarispell_1.2-0ubuntu1.dsc (for the time REVU is down). It has also been reviewed and advocated by persia but then we found out that it is a main package so I need a core-dev sponsor.
[11:14] <cjwatson> tepsipakki: I mean that the code in partman-target that sets up CD mounts does not use noexec
[11:14] <seb128> coNP: normal way is to subscribe ubuntu-sponsor-main
[11:14] <cjwatson> tepsipakki: and cdrom-detect even explicitly says exec
[11:14] <infinity> rgl: Build dependencies specify packages (and versions of packages) required to build the source.  The dpkg-dev in dapper is too old to cope with the changes made to debian/control in version 0.88.4-4 of clamav.
[11:15] <cjwatson> tepsipakki: ah, but the installer sets user, which implies noexec, ok
[11:15] <seb128> coNP: ubuntu-main-sponsors
[11:15] <tepsipakki> cjwatson: oh, it comes from that
[11:15] <coNP> Okay. Thanks I will.
[11:15] <cjwatson> user,noauto,exec would be ok, I think - file a bug?
[11:15] <tepsipakki> cjwatson: against cdrom-detect? yep
[11:16] <rgl> infinity, I see.  so I have to remove those changes, to make it build there.  or, maybe I can upgrade dpkg-dev?
[11:16] <cjwatson> tepsipakki: no, against partman-target
[11:16] <tepsipakki> cjwatson: hum, of course :)
[11:16] <cjwatson> rgl: the former, I wouldn't touch dpkg-dev if I were you
[11:17] <rgl> cjwatson, the thing is, I don't know what need to be changed to work on dapper *G*
[11:17] <cjwatson> rgl: ${binary:Version} -> ${Source-Version}
[11:17] <rgl> cjwatson, no ":" on dapper?
[11:18] <cjwatson> binary:Version has better semantics, but Source-Version will do for dapper
[11:18] <cjwatson> rgl: correct.
[11:18] <cjwatson> (there's a source:Version now - it's not completely unorthogonal :-), it was just reorganised)
[11:19] <rgl> cjwatson, cool thx :)
[11:19] <rgl> cjwatson, where can I read about that stuff?
[11:19] <cjwatson> rgl: deb-substvars(5) on gutsy
[11:19] <pitti> Riddell: FYI, I unseeded openoffice.org-gtk from Kubuntu again
[11:19] <cjwatson> or probably feisty come to that
[11:20] <rgl> cjwatson, is there anythign like that on dapper too?
[11:21] <cjwatson> rgl: sure (dpkg-source(1)), but of course it doesn't document variables not supported by that version of dpkg
[11:22] <rgl> BTW, why doesn't dpkg-buildpackage complains about empty stuff like ${binary:Version} ?
[11:22] <infinity> dpkg-substvars does complain.
[11:22] <infinity> "Unknown substitution variable $foo"
[11:22] <infinity> (Or similar)
[11:23] <cjwatson> (dpkg-gencontrol, not dpkg-substvars)
[11:23] <infinity> But it carries on, by design, because it's a nice and useful trick to have variables that expand to nothing.
[11:23] <infinity> Sorry, gencontrol.
[11:23] <rgl> thx guys :)
[11:24] <StevenK> infinity: Any chance of taking another look at libnss-db now the freeze has lifted?
[11:24] <cjwatson> sigh, busybox mount has no support for external mount helpers
[11:25] <rgl> is there a way to build a package, but without a subpackge?  like, in clamav there is a clamav-milter, but I don't want that build.  or, I have to nuke that altogether from the control file?
[11:25] <cjwatson> rgl: you have to nuke it from the control file, out of rules, etc.
[11:26] <StevenK> It could also be done manually, but that way lies pain.
[11:26] <rgl> why aren't there knobs on these source packages?
[11:26] <cjwatson> some source packages provide an environment variable to let you not build individual bits, but that's unusual.
[11:26] <cjwatson> there are sometimes
[11:26] <rgl> ah ok.
[11:26] <cjwatson> but the primary use for a source package is to be built on build daemons
[11:26] <cjwatson> this being primarily a binary distribution
[11:26] <Fujitsu> We're not Gentoo, so knobs aren't used much.
[11:26] <rgl> in FreeBSD port, it usual to have this kinds of stuff.  (sorry for making these comparations all the time...)
[11:27] <cjwatson> FreeBSD is a primarily source-based system, so of course the emphasis is going to be different
[11:27] <cjwatson> maintainers will often take reasonable requests for knobs
[11:27] <rgl> so the way to build packages here is to mount a build system, like pbuilder?
[11:28] <pitti> mvo: hm, about bug 125816... Tim tested it and the patch looks straightforward, and it doesn't affect runtime behaviour anyway; are you ok with me marking this as -done?
[11:28] <ubotu> Launchpad bug 125816 in redfish "linux-image postinst matches header_postinst_hook for postinst_hook incorrectly" [High,In progress]  https://launchpad.net/bugs/125816
[11:28] <cjwatson> rgl: I didn't mean that
[11:29] <cjwatson> rgl: I meant that we are much more concerned with making the binary packages that come out be suitable for wide use than with making the source packages easily tweakable
[11:29] <cjwatson> rgl: it's perfectly possible to build source packages in a regular system with dpkg-buildpackage
[11:29] <rgl> cjwatson, ah ok.
[11:30] <pitti> cjwatson: if you have the uploads for bug 130376 ready, can you please dput them?
[11:30] <ubotu> Launchpad bug 130376 in cdrkit "crash while checking MD5sums on jigdo include list" [High,In progress]  https://launchpad.net/bugs/130376
[11:30] <rgl> cjwatson, thats how I'm doing it.  though, I think it liters the system a bit.   I'm have to invest some time to mount an automated build box/chroot/vm.
[11:30] <cjwatson> grr, I hate that const char * isn't convertible to char * const
[11:30] <StevenK> pitti: Thanks!
[11:30] <cjwatson> pitti: sure, will do when I'm finished with this
[11:31] <pitti> cjwatson: but should it? those are two different semantics after all?
[11:31] <cjwatson> err, I mean const char ** -> char * const *
[11:31] <cjwatson> pitti: yeah, I know, it's just annoying :)
[11:31] <mvo> pitti: ok, let me do a regression test and then I will mark it done
[11:31] <cjwatson> (I know that it would be possible to defeat the constness without compiler warnings otherwise)
[11:32] <cjwatson> actually the problem is more that char * const * isn't convertible to const char * const *, since otherwise execv's second argument could be const char * const *
[11:32] <pitti> cjwatson: heh; yeah, sometimes I ponder something evil like "#define const /**/' or so :)
[11:33] <pitti> mvo: wow, that involves building the feisty kernel with it and comparing postinsts
[11:33] <mvo> pitti: maybe I will rethink my plan then :)
[11:34] <pitti> cjwatson: (just in case you didn't read bug mail yet, the feisty upload needs the Maintainer: dance)
[11:34] <cjwatson> pitti: can't I just DEBEMAIL=something@else for minimal change?
[11:35] <pitti> cjwatson: it's more about keeping the Maintainer: policy consistent in feisty (I guess Debian won't check that thoroughly, but *shrug*)
[11:36] <cjwatson> I don't think we should be cleaning it up in -updates for other things
[11:39] <StevenK> pitti: If the publisher is done running, libmiracle0.2.3, libmlt0.2.3, libmlt0.2.3-data and libvalerie0.2.3 can all be NBS'd at your leisure.
[11:39] <pitti> StevenK: will do
[11:39] <StevenK> pitti: Thanks
[11:40] <asac> stgraber: sabdfl: can both of you please post the output of lspci for your ipw3945 network controller ... to pastebin ?
[11:40] <asac> (lspci -v)
[11:41] <rgl> infinity, cjwatson: I was able to build clamav on dapper.  thx a lot! :)
[11:43] <stgraber> asac: http://paste.stgraber.org/2421
[11:44] <pitti> mvo: so what's the rethought plan? :)
[11:44] <stgraber> asac: btw, when you have some time to check, it seems that NM is starting dhclient on my wlan interface even when connected on LAN (which causes bad DNS record from the public WLAN my network card autoconnected to)
[11:45] <mvo> pitti: none yet, currently still digging into the hashsum issue on archive.u.c, but I will attend to it before lunch
[11:45] <cjwatson> rgl: good stuff
[11:45] <pitti> seb128: are you still interested in doing the bug 109073 SRU?
[11:45] <ubotu> Launchpad bug 109073 in gnome-games "Game Tali can't save scores" [Low,In progress]  https://launchpad.net/bugs/109073
[11:45] <pitti> mvo: ok, thank you
[11:45] <seb128> pitti: no
[11:46] <pitti> seb128: 'k, thanks
[11:46] <asac> stgraber: maybe you can add your setup et al to http://ubuntuforums.org/showthread.php?t=522054 ?
[11:46] <seb128> coNP: magyarispell, why did you update the Conflicts version? (you didn't document it in the changelog)
[11:47] <pitti> fabbione: btw, did you see the problem in bug 120177?
[11:47] <ubotu> Launchpad bug 120177 in multipath-tools "dm-multipath not autoloaded causes multipath to fail" [Undecided,In progress]  https://launchpad.net/bugs/120177
[11:47] <Amaranth> How does apt handle a Breaks?
[11:47] <coNP> seb128: not yet
[11:47] <seb128> coNP: same comment about the debian/rules changes
[11:47] <seb128> coNP: ?
[11:47] <coNP> I'll have a look.
[11:47] <seb128> coNP: "not yet" is not a reply to "why" ;)
[11:47] <asac> stgraber: can you come up with a log that shows this dhclient is started while connected on LAN issue?
[11:47] <fabbione> pitti: i thought i fixed that
[11:48] <seb128> Amaranth: it refuses to update the package if it Breaks something installed
[11:48] <Amaranth> seb128: that's bad
[11:48] <seb128> Amaranth: why?
[11:48] <coNP> seb128: sorry :). Should file a bug against my parser. It left out "why"
[11:48] <Amaranth> compiz Breaks compiz-extra :)
[11:49] <stgraber> asac: I think so, will paste it a bit later (I need the net for some mins :))
[11:50] <fabbione> pitti: nevermind.. i will look at it again
[11:50] <seb128> Amaranth: hum, I'm not sure now, mvo knows better
[11:50] <kagou> tkamppeter, ping
[11:50] <pitti> fabbione: grazie
[11:52] <Lutin> pitti: darkice give-back built on all archs, thanks. could you give-back dbi on amd64 & ppc too ?
[11:53] <pitti> Lutin: done
[11:53] <Lutin> thanks
[11:54] <mvo> seb128: what is that?
[11:55] <asac> stgraber: thanks
[11:55] <seb128> mvo: <Amaranth> How does apt handle a Breaks?
[11:55] <mvo> Amaranth: what is the issue
[11:55] <seb128> mvo: will the upgade remove compiz-extra or refuse to update compiz?
[11:55] <Amaranth> mvo: apparently if you have compiz-extra installed in feisty and try to upgrade the whole thing gets stuck
[11:55] <mvo> Amaranth: breaks are handled like conflicts in apt, it depends on the score (importance) of the package what will happen
[11:55] <Amaranth> had to go down to the dpkg level to remove compiz-extra before apt would do _anything_
[11:56] <mvo> Amaranth: I see, can you file a bug about it please? and milestone it :) and (if that is still possible) attach the output of -o Debug::pkgProblemResolver=true?
[11:56] <Amaranth> i already helped the guy manually get through it
[11:56] <infinity> The way I understand Breaks, compiz shouldn't be Breaking compiz-extra anyway, it should just be flat-out conflicting with it, no?
[11:57] <seb128> infinity: why? the ABI changed so Breaks with thing using the old one should be correct no?
[11:57] <Amaranth> infinity: well, no, the packages that have the plugins compiz-extra used to should have a Conflicts
[11:58] <Amaranth> but compiz-core breaks ABI so it's valid to have a Breaks for it there
[11:58] <stgraber> asac: http://paste.stgraber.org/2423, I got that after doing : killall -9 dhclient + suspend to ram + resume, but looking at the log it looks like it's the standard Debian networking thing that's running the dhclients
[11:58] <stgraber> asac: do you have a clean /etc/network/intefaces you can post somewhere, so I check that's not mine which is broken ?
[12:01] <asac> stgraber: what do you mean with "clean" ?
[12:01] <martoss> hi all
[12:01] <asac> stgraber: in a perfect worlkd interfaces would just be empty
[12:01] <stgraber> asac: "standard"
[12:02] <asac> well ... i think most standard is to just add one auto dhcp entry for your wired interface
[12:02] <asac> stgraber: http://pastebin.mozilla.org/182973
[12:03] <martoss> i am trying to debianize a binary package with dh_make.
[12:03] <stgraber> ok, so mine isn't broken :)
[12:03] <stgraber> question is why do those two dhclient starts on PC startup and when resuming from sleep
[12:05] <martoss> my first problem is that the configure and make install scripts are installing in default locations. Is there sth like fakeroot or so one can use in control? Just to avoid modifying all install scripts.
[12:06] <martoss> second. When i modify some lines in the "source", are the patches vs. "original source" automatically generated?
[12:06] <asac> stgraber: do you have your wireless interface as auto in interfaces as well?
[12:06] <stgraber> martoss: For questions about packaging you may better ask in #ubuntu-motu
[12:06] <stgraber> asac: I have both eth0 and eth1 as auto yes
[12:07] <martoss> ok, sry :-)
[12:07] <asac> stgraber: then thats the reason
[12:07] <stdin> martoss: there is the maint-guide package that has docs too
[12:08] <stgraber> asac: ok, removed eth1 from there, I'll need to check with a fresh livecd that it doesn't appear in the default network/interfaces
[12:08] <asac> stgraber: unfortunately it probably appears there
[12:09] <seb128> infinity: could you have a look to bug #131374?
[12:09] <ubotu> Launchpad bug 131374 in avifile "buildd try to build avifile for amd64" [Undecided,New]  https://launchpad.net/bugs/131374
[12:09] <seb128> infinity: how do we fix such bugs?
[12:09] <Mithrandir> "adjust PaS"?
[12:10] <infinity> Why is it no longer built on amd64?
[12:10] <infinity> And is the Debian source in sync with this idea? :)
[12:12] <infinity> seb128: If it builds, what's the rationale for not allowing it on amd64?
[12:13] <elmo> isn't it some 'I run win32 binaries because I CAN' crack?
[12:13] <seb128> infinity: I'm not the one who did the change, I was rather asking from a archive point of view ;)
[12:14] <Fujitsu> Um, seb128, it's fujitsu, not fujistu.
[12:14] <seb128> Fujitsu: ?
[12:14] <Fujitsu> https://launchpad.net/~fujistu/+packages
[12:14] <Fujitsu> YOu attributed some of my syncs to some random person :P
[12:15] <seb128> Fujitsu: ups, typo, sorry
[12:15] <infinity> seb128: Well, if it really shouldn't be on amd64 at all, the answer is "adjust P-a-s", but if it's just being artificially limited, the answer is "adjust the maintainer"...
[12:15] <Fujitsu> Heh, I'll hopefully remember to check that they build.
[12:16] <seb128> Fujitsu: thanks, sorry for the typo, no luck that there is somebody matching it ;)
[12:17] <geser> can an ubuntu-main-sponsor please look at bug #131304 and bug #130348?
[12:17] <ubotu> Launchpad bug 131304 in emacs-goodies-el "[Sync request]  Sync emacs-goodies-el (27.1-1) from Debian unstable (main)" [Wishlist,New]  https://launchpad.net/bugs/131304
[12:17] <ubotu> Launchpad bug 130348 in festival "[Merge]  festival 1.4.3-21ubuntu1" [Undecided,Incomplete]  https://launchpad.net/bugs/130348
[12:17] <ajmitch> seb128: thanks for syncing :)
[12:17] <seb128> ajmitch: you're welcome
[12:18] <seb128> geser: looking
[12:20] <seb128> geser: done
[12:20] <sabdfl> asac: no, it's a public network
[12:21] <sabdfl> asac: is there a way to use dhclient after wpa_supplicant, to see if i can get dhcp going after the wpa stuff is done?
[12:22] <geser> seb128: thanks
[12:23] <Lutin> seb128: buildd try to build gambas2 for sparc and ppc, but it's a i386-only package (upstream do not support other archs) . could you adjust P-a-s ?
[12:23] <seb128> infinity: how do we adjust P-a-s? ;)
[12:24] <Mithrandir> seb128: mail upstream. :-)
[12:25] <infinity> Mithrandir: That's just cruel, you know who upstream is. :P
[12:25] <Mithrandir> infinity: upstream is cuddly and huggable. :-P
[12:25] <infinity> seb128: The fundamental issue here is that if Debian is building it on amd64 and claims it works there, I won't adjust P-a-s to drop it on Ubuntu.
[12:26] <seb128> infinity: that was about what Lutin just wrote
[12:26] <Lutin> infinity: you're talking about avifile ?
[12:26] <seb128> infinity: http://packages.qa.debian.org/g/gambas2/news/20070715T141328Z.html
[12:26] <infinity> seb128: We also don't adjust P-a-s for "people are lazy and won't make it work on other arches", only for "this obviously can't work on other arches, due to arch-specific code".
[12:27] <seb128> infinity: well, in this case Debian did it
[12:27] <asac> sabdfl: if wpa_supplicant succeeds you should be able to just use dhclient IFACE
[12:27] <infinity> seb128: A Debian maintainer != Debian. :)
[12:27] <pitti> infinity: but shouldn't such cases be handled by simply adjusting the Architecture: field?
[12:27] <asac> sabdfl: public network + wpa ?
[12:27] <Lutin> seb128: feel free to reject the avifile bug - actually when setting arch to any rather than (i386 kfreebsd), it builds (don't know it works, but that's another issue)
[12:28] <sabdfl> asac: 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
[12:28] <Lutin> (on amd64)
[12:28] <seb128> Lutin: please close it if you think it's not valid
[12:28] <Lutin> seb128: ok, will do it then
[12:28] <asac> sabdfl: can you paste lspci -v
[12:28] <infinity> pitti: A constant source of contention that one. :)
[12:28] <seb128> infinity: ok, I'll let you convince the Debian maintainer he should make it work on other arches then ;)
[12:28] <asac> sabdfl: maybe there is a difference in your details
[12:29] <sabdfl> pastebin?
[12:29] <infinity> seb128: I can P-a-s out the latter case, but it leaves an icky taste in my mouth to do it because "upstream can't be bothered to fix porting bugs".
[12:29] <asac> sabdfl: yes ... use http://pastebin.mozilla.org if you don't have a link at hand
[12:29] <seb128> infinity: right, but we have already enough to do without taking over every upstream doing that :/
[12:30] <infinity> seb128: I'll note that 1.9.48 did, in fact, build on every single Debian arch..
[12:32] <infinity> seb128: It's more about "if the bugs can be fixed, they should be.. By upstream, Debian, or Ubuntu".
[12:32] <asac> infinity: for p-a-s ... is debian cvs up again? so you can commit the flashplugin changes there as well?
[12:32] <seb128> infinity: right
[12:32] <infinity> seb128: "I don't understand why chars are sometimes signed" (for example) isn't a good enough excuse for a P-a-s entry. :)
[12:32] <infinity> asac: I already did so, didn't I?
[12:32] <sabdfl> asac: http://pastebin.mozilla.org/182977
[12:32] <asac> infinity: hmmm ... looks pretty empty on webfrontend
[12:33] <infinity> asac: http://cvs.debian.org/srcdep/Packages-arch-specific?root=dak&r1=1.687&r2=1.688
[12:33] <infinity> asac: You're a month late. :)
[12:34] <asac> infinity: well i just looked at cvs.debian.org and saw only Attic ... so I assumed that its not really up ;)
[12:34] <sladen> sabdfl: if there's another dhclient/dhclient3/dhcdbd another running they'll end up eating each other packets;  so you might some  sudo killall dh<tab><tab>'ing before trying   sudo dhclient3 eth1
[12:35] <infinity> asac: Have to change project root to "dak". :)
[12:36] <asac> sabdfl: thanks ... btw, can you get a stable (wired) connection at home, so we can do some tests?
[12:36] <asac> infinity: remember that i am just a monkey ;)
[12:36] <infinity> asac: Noted. ;)
[12:39] <norsetto> Any advise on license's problems of bug 131325 (especially if upstream doesn't react)?
[12:39] <ubotu> Launchpad bug 131325 in conky "Gutsy uses old version of conky." [Undecided,In progress]  https://launchpad.net/bugs/131325
[12:47] <coNP> seb128: (about magyarispell) I investigated a bit and added explanations into the changelog (uploaded again as well).
[12:47] <Hobbsee> asac: why do you have the old enigmail version in the enigmail source too?
[12:47] <seb128> coNP: you investigated? you are not the one who did the changes? ;)
[12:48] <coNP> seb128: no, somone in our LoCo started to package it but he did not finished. But we wanted this package appear in gutsy because of the many added words, etc.
[12:49] <asac> Hobbsee: thats clutter from the time when that package built for both: mozilla-suite  + thunderbird
[12:49] <Hobbsee> asac: ah right
[12:49] <Hobbsee> asac: fine to remove, then?
[12:49] <asac> Hobbsee: ah ... you have to change version of enigmail in rules
[12:49] <asac> Hobbsee: i think so
[12:49] <asac> Hobbsee: (or rules.thunderbird)
[12:49] <asac> but that should be it
[12:49] <Hobbsee> asac: right, yeah, that's what i'm looking at now
[12:50] <norsetto> Hiya Hobbsee
[12:50] <Hobbsee> hey norsetto!
[12:50] <asac> Hobbsee: rules.thunderbird => ENIGMAIL_VERS
[12:50] <Hobbsee>         cp $(CURDIR)/debian/allmakefiles.sh.0.94.0.thunderbird $(CURDIR)/build-dir/mozilla/allmakefiles.sh
[12:50] <Hobbsee> i wonder why that old version is there too
[12:50] <Hobbsee> oh, i see
[12:51] <asac> well allmakefiles.sh is unlikely to change often
[12:51] <asac> which is why 0.94.0 might still work
[12:51] <Hobbsee> yeah.  was comign to that conclusion
[12:52] <asac> there is a bunch of old debian/configure* files as well
[12:52] <asac> Hobbsee: at best don't try to fix things ... I wanted to redo the packaging at some point
[12:52] <Hobbsee> asac: sure, OK
[12:55] <asac> Hobbsee: not that we duplicate work ... do you have seamonkey et al in debian/control ?
[12:55] <Hobbsee> asac: oh darn it, i presumably have to hardcode the value of thunderbird that we're now in too?  (as in, not <IP_ADDRESS>)
[12:56] <Hobbsee> asac: only in depends for enigmail
[12:56] <asac> Hobbsee: ok
[12:56] <asac> then its fine
[12:56] <Hobbsee> Depends: thunderbird | iceape-mailnews | seamonkey-mailnews, ${shlibs:Depends}, gnupg
[12:57] <asac> Hobbsee: no ... i think it should just work
[12:57] <asac> Hobbsee: e.g. no thunderbird version tweaking needed (i hope)
[12:57] <Mithrandir> asac: did you make any progress on the "have all mozilla packages look in a common directory for plugins" idea I talked with you about earlier?
[12:57] <Hobbsee> asac: build deps for enigmail arent satisfiable
[12:59] <Hobbsee> bah.  it all blows up anyway.  i knew i shoul dhave left this one alone
[12:59] <infinity> asac: Oh, hey, now that you work for us, can I point out that the enigmail packaging is complete CRACK? :)
[12:59] <asac> infinity: well ... read above ;)
[01:00] <asac> infinity: its in the making to clean this up
[01:00] <infinity> asac: I always tried to be polite when it was a matter of community/debian outreach, but yeah.  Dude.  What were you on? :)
[01:00] <asac> infinity: well ... the reason is that enigmail usually cannot be build outside thunderbird source tree
[01:01] <infinity> asac: Oh, I undertand the reasons for the SDK tricks and such.
[01:01] <asac> infinity: so i had to hack around all kinds of constraints ... too much ;)
[01:01] <infinity> asac: It's the rules files with the 700 hardcoded ancient versions and stuff.  Aieee! :)
[01:01] <asac> infinity: thats gone already
[01:01] <asac> infinity: I had to introduce that for different mozilla suite flavours ;)
[01:02] <asac> infinity: anyway ... i have a much better sdk now ... which i want to use soon
[01:02] <infinity> asac: I just wanted to let you know that it was responsible for a large portion of my brain bleeding through my ear when I had to deal with it, that's all. :)
[01:02] <asac> infinity: i just have to do it ;)
[01:02] <infinity> asac: Now that you do all the mozilla stuff, I couldn't care less. ;)
[01:02] <asac> infinity: be assured you are not alone :) ... it hunts me from time to time
[01:02] <asac> infinity: but usually it works if you just don't touch it ;)
[01:03] <infinity> asac: I had to touch it a few too many times. ;)
[01:03] <infinity> asac: Security releases, tbird versions out of sync with Debian, splitting the source...
[01:03] <asac> yes right ... but we all like challenges ... especially if you blame someone else ;)
[01:03] <infinity> asac: And blame you I did!
[01:03] <asac> s/you blame/you can blame/ :)
[01:04] <infinity> asac: *grin*
[01:04] <kagou> tkamppeter, have a look at #131521
[01:04] <asac> Hobbsee: ok ... if it breaks for you just remind me every other day and I will update enigmail
[01:04] <infinity> asac: Glad we actually hired someone who understands upstream, though. We've been in the dark about mozilla products since day 1, really.
[01:04] <Hobbsee> asac: building the source broke.  i left it alone, at taht point :)
[01:05] <Hobbsee> infinity: i get the impression that everyone except for mozilla themselves is in that basket :P
[01:05] <infinity> StevenK: He's busy hating soyuz, then sucking up to Mithrandir.  He's not ignoring you. :)
[01:05] <StevenK> infinity: Not much, anyway? :-)
[01:05] <asac> infinity: well understanding upstream is not what i do ... I punch my brain until their thinking fits into it :)
[01:05] <infinity> Hobbsee: It's not so much that upstream is all that weird, it's that they have such a huge number of products and contributors in a bizarre n:n relationship that it can be hell tracking changes and such.
[01:06] <thom> infinity: more so at first than latterly ;0
[01:06] <Hobbsee> true
[01:07] <infinity> And trying to sort out of changes on a firefox branch might be something you want to apply to a thunderbird branch, or a mozilla branch, or... You lose a bit of your mind each time.
[01:07] <infinity> s/sort out of/sort out if/
[01:11] <TheMuso> oo/c
[01:11] <TheMuso> ugh
[01:15] <fabbione> pitti: i have almost done with that bug.. just re-testing a lot
[01:21] <Riddell> TheMuso: this is interesting http://labs.trolltech.com/page/Projects/Accessibility/IAPoke  however I can't get it to talk to anything
[01:22] <Riddell> there's a qdasher too
[01:23] <pitti> mvo: however, I think I made it easy for you: https://bugs.launchpad.net/ubuntu/dapper/+source/cupsys/+bug/57445/comments/15
[01:23] <ubotu> Launchpad bug 57445 in cupsys "Printing not possible with line break or mis-interpreted encoding in job title" [Medium,Fix committed]
[01:24] <TheMuso> Riddell: Just a sec, I'll have a look at that page.
[01:25] <Riddell> TheMuso: I suspect it needs the qt dbus accessibility bridge thing, and probably then may need your programme altered to use it
[01:26] <TheMuso> Riddell: I am on my notebook right now, but when I get back to my desktop and large monitor, I will have a deeper look. Nice to see something for KDE like this.
[01:26] <TheMuso> I've bookmarked it in any case.
[01:29] <fabbione> pitti: #120177 back in your court.. fixed also in gutsy
[01:29] <pitti> fabbione: yay
[01:29] <fabbione> mvo: ^^ thanks for spotting that stuff
[01:29] <lamont> seb128: doko: pitti: I was not aware of 131497.  sorry
[01:29] <doko> lamont: fixed and uploaded
[01:29] <TheMuso> o/c
[01:29] <seb128> lamont: that's ok, doko fixed it ;)
[01:29] <TheMuso> ugh orca keeps dying.
[01:29] <lamont> doko: saw that
[01:29] <fabbione> pitti: btw.. i am still digging trough the 7K emails from LP in the last 2 weeks. if there is anything urgent like this one please ping me
[01:30] <doko> lamont: you owe me know a working gdb on hppa (and make that better a working gij as well) ;-)
[01:30] <pitti> fabbione: I will; I'm currently reviewing the dapper point release bugs (and do a couple of SRUs and sponsoring myself)
[01:30] <doko> s/know/now/ damn
[01:30] <pitti> that's why I bother people on IRC so much today :)
[01:30] <fabbione> pitti: ok thanks
[01:30] <fabbione> pitti: you never bother me.. really
[01:30] <lamont> doko: I'm hoping that we get offsets.h from jbailey today...
[01:31] <lamont> seems he's a bit preoccupied with moving
[01:31] <infinity> pitti: Sponsoring yourself? :P
[01:31] <doko> lamont: let me know, have some gdb changes for gutsy here locally
[01:31] <pitti> infinity: mathiaz :)
[01:31] <infinity> pitti: Surely, we have some sort of policy against that kinda of thing...
[01:31] <pitti> infinity: but wrt. my own dapper SRUs it's pretty easy to get approval for them :-P
[01:32] <lamont> doko: the current blocker (AFAIK) is the lack of an offsets.h from the kernel, which other architectures provide.
[01:32] <pitti> infinity: yeah, I don't abuse it usually
[01:32] <infinity> pitti: (I'm happy to review anything that's more than a 3-character fix that you want looked at, BTW)
[01:32] <pitti> infinity: that would be nice indeed
[01:32] <pitti> infinity: I just did bug 58935, which is really trivial and easy to verify, too
[01:32] <ubotu> Launchpad bug 58935 in hal "two hald-addon-storage  processes per pooled device" [Medium,Fix committed]  https://launchpad.net/bugs/58935
[01:33] <infinity> pitti: Given how well we've proven that your reviews of my code work, it should surely work just as well in reverse! ;)
[01:33] <pitti> infinity: and bug 57445, whose patch is more complicated (but I scrutinized it and tested it, too)
[01:33] <ubotu> Launchpad bug 57445 in cupsys "Printing not possible with line break or mis-interpreted encoding in job title" [Medium,Fix committed]  https://launchpad.net/bugs/57445
[01:33] <pitti> infinity: *cough*
[01:34] <infinity> pitti: Okay, the hald diff looks obviously correct.
[01:35] <geser> mvo: can you look at the debdiff in bug #131035 and tell if it's correct?
[01:35] <ubotu> Launchpad bug 131035 in compizconfig-python "Doesn't depend on python, ships .a and .la files" [Undecided,Confirmed]  https://launchpad.net/bugs/131035
[01:38] <infinity> pitti: "if (*value < ' '" looks odd to me.
[01:38] <pitti> infinity: why?
[01:38] <infinity> Is ' ' the first printable char in the ASCII table?
[01:38] <pitti> infinity: yes (32)
[01:38] <infinity> And, if so, why not 32? :)
[01:38] <pitti> it's meant to filter out control characters
[01:39] <infinity> Just seems stylistically odd, not broken.
[01:39] <pitti> infinity: would that change the question? :-)
[01:39] <pitti> yeah, I agree
[01:39] <infinity> Less than space, more than 127...
[01:39] <pitti> ctype.h FTW :)
[01:39] <pitti> but I didn't want to deviate from what we have upstream and in Ubuntu since edgy
[01:39] <infinity> Yeah.
[01:39] <infinity> The escaping code looks sane to me.
[01:40] <pitti> Mike contradicted himself with the "smaller than 254" limit
[01:40] <pitti> i. e. should be "smaller than or equal"
[01:40] <infinity> I assume that just print garbage for multibyte chars, but safely-escaped garbage, at least...
[01:40] <pitti> but that's just a comment error AFAICS
[01:40] <pitti> infinity: no, it makes gs fail
[01:40] <pitti> infinity: it looks like
[01:40] <pitti> %Title: a
[01:40] <infinity> Oh, hahaha.
[01:40] <pitti> b
[01:40] <pitti> instead of "%Title: a%012b
[01:40] <pitti> "
[01:41] <pitti> meh, forget my quotes
[01:41] <pitti> same with UTF-8 multibyte chars which happen to end with 10
[01:42] <infinity> Anyhow, it looks sane to me, and I put more stock in testing than eyeballing.
[01:42] <infinity> Eyeball reviews are just good for catching obvious "dude, that's backwards" stuff, IMO.
[01:43] <pitti> yeah
[01:45] <pitti> mvo: can you please have a look at my question in bug 47044? Thanks
[01:45] <ubotu> Launchpad bug 47044 in apt "apt cant work with disable proxy" [Medium,Fix committed]  https://launchpad.net/bugs/47044
[01:48] <seb128> Keybuk: could you look at bug #128257?
[01:48] <ubotu> Launchpad bug 128257 in udev "Should include 'plugdev' group in permission.rules" [Undecided,New]  https://launchpad.net/bugs/128257
[01:54] <mvo> fabbione: thanks for #120177!
[01:55] <mvo> pitti: I make it a sru-verification afternoon I think :)
[01:56] <asac> mvo: can you verify enigmail?
[01:57] <mvo> asac: what bugnumber? does it contain verification instructions?
[02:22] <asac> mvo: bug #119038
[02:22] <ubotu> Launchpad bug 119038 in enigmail "MASTER Key management / Recipient Key Selection broken (endless loop in EnigConvertToUnicode)" [Undecided,Fix committed]  https://launchpad.net/bugs/119038
[02:22] <asac> mvo: ... verification instructions are on top of summary
[02:24] <mvo> asac: thanks
[02:24] <asac> mvo: the pleasure is on my side ;)
[02:56] <fabbione> mvo: ok cool
[02:59] <sabdfl> is there a key combination under X which will bring up a task manager to let you kill a rogue process?
[02:59] <Fujitsu> sabdfl: Use Automatix :P It gives you the option to bind Ctrl+Alt+Delete for that, AFAIK
[02:59] <sabdfl> much like ctrl-alt-del does in Windows?
[03:00] <fabbione> sabdfl: not that I know off
[03:00] <Hobbsee> kde used to.
[03:00] <Hobbsee> for some reason, now it brings up the shutdown menu
[03:00] <Hobbsee> it used to bring up ksysguard.
[03:01] <fabbione> sabdfl: you can use gnome-system-monitor to get a list of tasks and end one of them.. not sure if there is a shortcut for it
[03:01] <Riddell> Hobbsee: control-escape brings up ksysguard, as it always has
[03:01] <Hobbsee> Riddell: ah right.  which i've now modified to xkill.
[03:10] <pitti> hi mathiaz
[03:10] <mathiaz> hi pitti
[03:11] <mathiaz> pitti: thks for the quagga sponsor.
[03:11] <pitti> np
[03:11] <mathiaz> pitti: I've got another one - for samba.
[03:11] <pitti> mathiaz: I was reviewing the dapper.2 bugs, and bug 84209 is still worrying me
[03:11] <ubotu> Launchpad bug 84209 in mysql-dfsg-5.0 "subselect bug in amd64 compiled version" [Undecided,Fix released]  https://launchpad.net/bugs/84209
[03:11] <pitti> mathiaz: I'll probably forego that for dapper.2 unless the guy responds soon
[03:11] <mathiaz> pitti: hum. I cannot reproduce it.
[03:12] <pitti> mathiaz: yeah, I mean 'worrying' in terms of getting a fix for dapper.2
[03:12] <mathiaz> pitti: yes. I'm not sure it's the same bug as the one he mentioned in his report.
[03:12] <mathiaz> pitti: there is another debdiff that I prepared for mysql
[03:13] <pitti> fabbione: wrt you multipath prerm script
[03:13] <pitti> fabbione: shouldn't you use lt-nl instead of lt?
[03:13] <pitti> fabbione: otherwise you'll run the special case instead of #DEBHELPER# on a fresh installation
[03:13] <mathiaz> pitti: so if you drop bug 84209, we can publish an updated mysql-dfsg for dapper
[03:13] <ubotu> Launchpad bug 84209 in mysql-dfsg-5.0 "subselect bug in amd64 compiled version" [Undecided,Fix released]  https://launchpad.net/bugs/84209
[03:13] <pitti> mathiaz: 'another'?
[03:14] <pitti> mathiaz: I just know bug 118523
[03:14] <ubotu> Launchpad bug 118523 in mysql-dfsg-5.0 "mysql server fails to start, claims /var/lib/mysql full" [Medium,In progress]  https://launchpad.net/bugs/118523
[03:14] <mathiaz> pitti: yes. this one.
[03:15] <pitti> mathiaz: right, that looked fine
[03:15] <mathiaz> pitti: the debdiff hasn't been applied because we're waiting for bug 84209.
[03:15] <ubotu> Launchpad bug 84209 in mysql-dfsg-5.0 "subselect bug in amd64 compiled version" [Undecided,Fix released]  https://launchpad.net/bugs/84209
[03:16] <mathiaz> pitti: we'll have to be publish a new mysql-dfsg for dapper.
[03:16] <cjwatson> pitti: cdrtools/edgy-proposed failed to build 'cos I screwed up the patch; any objection to a trivial reupload?
[03:16] <mathiaz> pitti: so if you decide to drop bug 84209 than we can publish a new mysql-dfsg for dapper.
[03:16] <ubotu> Launchpad bug 84209 in mysql-dfsg-5.0 "subselect bug in amd64 compiled version" [Undecided,Fix released]  https://launchpad.net/bugs/84209
[03:17] <pitti> cjwatson: please
[03:17] <cjwatson> genius here forgot to adjust the line numbers
[03:17] <pitti> mathiaz: right, let's do that then to get this going
[03:22] <pitti> mathiaz: do you have an idea how to reproduce the original failure? mvo would love you if you could add a reproducer to the bug
[03:23] <mathiaz> pitti: which bug are you talking about ?
[03:23] <pitti> mathiaz: the BLOCK_SIZE one
[03:23] <pitti> 118523
[03:24] <mathiaz> pitti: hum... I'll try to come up with something.
[03:24] <pitti> mathiaz: if it takes too long, don't worry, but if it's easy to reproduce it is good to have instructions
[03:25] <mathiaz> pitti: a bug about samba was filled yesterday - bug 131419
[03:25] <ubotu> Launchpad bug 131419 in samba "smb.conf contains valid users = %S in [global] " [High,In progress]  https://launchpad.net/bugs/131419
[03:26] <mathiaz> pitti: it's a nasty one - but impacts only new install with the last samba package.
[03:26] <mathiaz> pitti: I fixed the smb.conf file, but I wonder how I should handle the upgrade.
[03:34] <pitti> mathiaz: mysql uploaded
[03:34] <mathiaz> pitti: thks. :)
[03:35] <infinity> mathiaz: Eww, did a broken merge move that from [homes]  to [global] ?
[03:36] <mathiaz> infinity: nope. soren added some comment to clarify the homes section.
[03:36] <mathiaz> infinity: it seems that he forgot to comment out the valid users option.
[03:36] <infinity> mathiaz: Oh, [homes]  got commented, but the directive didn't.  I see.
[03:36] <mathiaz> infinity: and it's actually duplicated.
[03:37] <mathiaz> infinity: there are two entries for valid users
[03:37] <infinity> mathiaz: If this bug was only in gutsy, I don't think it's worth worry about an upgrade path, TBH.
[03:37] <mathiaz> infinity: only the second one is uncommented.
[03:37] <mathiaz> infinity: ok. It will affect users that have installed a new samba.
[03:38] <mathiaz> infinity: in the last 10 days or so.
[03:38] <infinity> mathiaz: Sure, but only people running gutsy who've installed samba in.. The last week?  When did it break?
[03:38] <infinity> Kay.
[03:38] <infinity> That's not worth the postinst cruft to fix it, IMO.
[03:39] <mathiaz> infinity: it broke on 16 Jul 2007
[03:40] <infinity> mathiaz: Well, then, if you really want to fix it, here's what I'd do:
[03:40] <infinity> Check if you're upgrading from a version >= the broken one
[03:40] <infinity> grep the config file for two occurences of "valid user"
[03:41] <infinity> If both conditions are met, blindly sed the thing into oblivion. :/
[03:41] <infinity> Oh, and make that >= the broken one, and <= the fixed one.
[03:41] <infinity> So you don't even dare run that code after this week.  Just in case it breaks someone's valid config.
[03:41] <Fujitsu> It's Gutsy, it's allowed to munge your config files.
[03:41] <infinity> Fujitsu: It's never allowed.
[03:42] <mathiaz> infinity: yeah... that seems a little bit complicated.
[03:42] <mathiaz> infinity: because you wanna grep only in the [homes]  section
[03:42] <pitti> erm, just to make sure, we are not talking about a conffile here, right?
[03:42] <infinity> mathiaz: It's not that complicated.  It all depends on how bad you think the bug is.
[03:42] <mathiaz> pitti: it's a conffile - smb.conf.
[03:42] <infinity> pitti: No, debconf-written config file.
[03:42] <pitti> ok
[03:42] <infinity> It's not a dpkg conffile.
[03:42] <mathiaz> infinity: ok.
[03:43] <infinity> adconrad@cthulhu:~$ dpkg -S /etc/samba/smb.conf
[03:43] <pitti> mathiaz: conffile -> shipped in .deb and auto-upgraded and handled by dpkg
[03:43] <infinity> dpkg: /etc/samba/smb.conf not found.
[03:43] <infinity> See?
[03:43] <pitti> mathiaz: configuration file -> created by maintainer scripts and not owned by a package
[03:43] <pitti> mathiaz: and it is a dead sin to *ever* touch a conffile in any maintainer script
[03:44] <mathiaz> pitti: hum. ok. But there is a smb.conf in the debian/ directory.
[03:44] <infinity> pitti: If it was a conffile, I wouldn't even worry about fixing it anyway, since dpkg would prompt, and the user can get stuffed it they don't care about checking the diff.
[03:44] <pitti> infinity: that's what I meant
[03:44] <infinity> (I've broken this rule before)
[03:44] <infinity> (using md5sums in preinsts, and other hideous hacks)
[03:44] <infinity> (don't do this at home, kids)
[03:45] <infinity> Pretty sure initramfs-tools has an example of such scariness.
[03:45] <mathiaz> infinity: ok. Thks.
[03:45] <pitti> I did that a lot for moving conffiles between packages
[03:45] <mathiaz> it seems that it's not worth the trouble.
[03:45] <pitti> /var/lib/dpkg/info/hal.preinst FTW
[03:45] <infinity> pitti: Is it sad that we brag about the ways we've violated policy creatively enough to get away with it?
[03:46] <StevenK> infinity: YES.
[03:46] <pitti> infinity: that script doesn't break that rule
[03:46] <pitti> infinity: it only avoids dpkg questions for unmodified conffiles, it never actually touches them :)
[03:46] <mathiaz> infinity, pitti: could you sponsor my fix for samba ?
[03:47] <infinity> pitti: I sed a conffile to unbreak the fact that another package modified it against policy. :P
[03:48] <infinity> mathiaz: I would like nothing more.
[03:50] <infinity> pitti: Aww, that code's gone now, since the mkinitramfs->initramfs-tools transition, that's right.  There go my bragging rights.
[03:50] <infinity> pitti: Basically, I put the shipped config back in place, let dpkg think everything was okay, then converted the conffile to a config file and wrote the correct value out again.
[03:50] <infinity> pitti: And died a little inside as I was writing that.
[03:52] <infinity> Then again, the pkgbinarymangler preinst is about the scariest thing ever too, maybe I'm just psychotic.
[03:52] <pitti> eww, indeed
[03:53] <infinity> if [ ! -x /usr/bin/dpkg-deb ] ; then
[03:53] <infinity> # on initial install, we have no dpkg-deb, cause we just diverted it
[03:53] <infinity> cp /usr/bin/dpkg-deb.pkgbinarymangler /usr/bin/dpkg-deb
[03:53] <infinity> fi
[03:53] <pitti> infinity: I think this beast can be pretty much dropped, though
[03:53] <infinity> pitti: What can be dropped?
[03:53] <pitti> infinity: the conffiles migration at least
[03:53] <infinity> Oh, yeah. :)
[03:53] <seb128> pitti: is "restricted-manager --check-composite" opening a dialog "nvidia hardware not available" when having an ATI card a known issue?
[03:54] <pitti> infinity: what's that "remove old diversion" about?
[03:54] <pitti> seb128: not known to me, and I didn't see a bug report about it
[03:54] <pitti> seb128: it's about a week since I checked the r-m bugs last, though
[03:54] <seb128> pitti: ok, I'm reassigning one to you we got on the appareance capplet and I can confirm it
[03:54] <infinity> pitti: Moving the diversion from pkgstriptranslations to pkgbinarymangler.
[03:54] <pitti> seb128: merci
[03:55] <pitti> infinity: ah, right; that can go now, too, I think
[03:55] <infinity> pitti: Yeah, the only bit that needs to stay is the "dpkg-deb doesn't exit, dpkg is about to die, aieeee!" voodoo.
[03:55] <infinity> pitti: But the migration code wasn't hurting anyone, so whatever.
[03:57] <norsetto> seb128: salut, have you seen my email about mentoring status?
[03:58] <seb128> hi norsetto
[03:58] <pitti> bdmurray: can I gently poke you about bug 68553?
[03:58] <ubotu> Launchpad bug 68553 in python-apt "Dapper upgrade to Edgy: Frozen dist-upgrade and failed second run (in Finnish locales" [High,Fix committed]  https://launchpad.net/bugs/68553
[03:58] <infinity> mathiaz: That offer was time-limited.  I'm about to cut out for the day (it's midnight)...
[03:59] <mathiaz> infinity: that's ok. pitti just sponsored my upload.
[03:59] <infinity> Ahh, snazzy.
[03:59] <pitti> mathiaz: not samba
[03:59] <pitti> ENOTIME, sorry
[03:59] <seb128> norsetto: I did reply to the previous mail some weeks ago than I didn't notice him doing any work, any reason you send mails again after that?
[03:59] <mathiaz> pitti: hum. correct...
[03:59] <pitti> BenC: can you please ping me once you are awake, so that we can go through the dapper.2 bug list?
[03:59] <seb128> norsetto: is there a way to note that I'm not mentoring it somewhere? ;)
[04:00] <norsetto> seb128: just checking again; so he dropeed?
[04:00] <StevenK> infinity: You can't look at libnss-db? :-)
[04:00] <infinity> mathiaz: Well, give me your diff/dsc, quick-like. :P
[04:00] <alex-weej> apport retracing just did this http://launchpadlibrarian.net/8771344/Stacktrace.txt
[04:00] <alex-weej> does it not work for gutsy yet?
[04:00] <norsetto> seb128: just tell me and I tick you off; should I keep the slot for somebody else?
[04:00] <infinity> StevenK: I'll go over it on the weekend and either upload it, fix and upload it, or bounce more annoyances at you.
[04:00] <seb128> norsetto: no news from him no, I can send you a copy of the previous mail if you want, he didn't manifest himself since
[04:00] <pitti> alex-weej: in general it does
[04:00] <pitti> alex-weej: but it sometimes fails, when no debug symbols are available and such
[04:00] <seb128> norsetto: I'm happy to mentor somebody else yes
[04:01] <StevenK> infinity: Personally, I'd prefer to upload it, I just want a second pair of eyes over it.
[04:01] <mathiaz> infinity: http://launchpadlibrarian.net/8765965/samba_3.0.25b-1ubuntu2.debdiff
[04:01] <pitti> alex-weej: those bugs are auto-tagged, I'll have a look at them every now and then
[04:01] <pitti> back in 20 minutes
[04:01] <norsetto> seb128: good! I'll take him off then, and I'll send him an email to check what happened anyway
[04:01] <alex-weej> pitti: ok, cool
[04:02] <seb128> mathiaz, infinity: you are working on samba? Do you have an opinion on 'net usershare'?
[04:02] <seb128> norsetto: thanks, do you want me to reply to your mail so you have the reply somewhere?
[04:02] <infinity> seb128: An opinion in what regard?
[04:03] <norsetto> seb128: yeah, perhaps it is better (you know Daniel ;-))
[04:03] <cjwatson> infinity,pitti: I see your /var/lib/dpkg/info/hal.preinst and raise you /var/lib/dpkg/info/openssh-client.preinst
[04:03] <seb128> infinity: https://lists.ubuntu.com/archives/ubuntu-devel/2007-January/023128.html
[04:04] <infinity> cjwatson: I assume the conffile moving, not the OH GOD, WHAT'S ALL THAT key spew? :)
[04:06] <pitti> cjwatson: dear, is this the entire Debian key ring or so? :)
[04:06] <cjwatson> infinity: it's not even so much moving it, it's convincing sarge's dpkg that yes, it's OK for this conffile to be moved between packages and no, please god don't give the user a deeply confusing prompt
[04:06] <cjwatson> pitti: /etc/ssh/moduli ...
[04:06] <cjwatson> it has a manual page and everything, moduli(5)
[04:06] <mathiaz> seb128: seems interesting.
[04:06] <pitti> ah
[04:07] <infinity> mathiaz: Verified and uploaded.
[04:07] <cjwatson> I am so glad dpkg is fixed now
[04:07] <mathiaz> infinity: thks.
[04:08] <infinity> seb128: That's pretty light on technical detail.
[04:08] <mathiaz> seb128: is the extension already integrated ?
[04:08] <infinity> seb128: But I'd be happy to look into the sanity of it.
[04:08] <mathiaz> infinity: the man page has more information.
[04:08] <mathiaz> infinity: it relies on a directory where members of a specified group can write to.
[04:09] <mathiaz> infinity: I guess that net usershare will create symlink there, or something like that.
[04:09] <infinity> mathiaz: Yeah, reading it now.
[04:10] <infinity> mathiaz: So, a config file change, and a directory in /var/lib/samba...
[04:10] <mathiaz> infinity: yop.
[04:10] <seb128> mathiaz: no, it's not inegrated. You can have a look to the nautilus-share README if you want, there is a recommend samba configuration
[04:11] <mathiaz> infinity: we just need to figure out the group thingy.
[04:11] <infinity> seb128: Should this be an "all users" thing, or just admin users?
[04:11] <infinity> seb128: Cause, sadly, we don't add users by default to a users group.
[04:11] <seb128> infinity: I'm happy to discuss it, ideally anybody
[04:12] <infinity> seb128: Our lack of a users group is a killer for this one.
[04:12] <seb128> infinity, mathiaz: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/128548
[04:12] <ubotu> Launchpad bug 128548 in samba "Enable net usershare?" [Undecided,New]
[04:12] <infinity> seb128: Because we don't want that directory world-writeable.
[04:13] <seb128> infinity: can't we use the samba group?
[04:13] <cjwatson> infinity: we have a users group, we just don't put ordinary users in it for some reason
[04:13] <mathiaz> seb128: is there a allowed to share permission ?
[04:13] <infinity> Yeah, soren's with me on this one.
[04:13] <infinity> cjwatson: Well, yes, that's what I meant.
[04:13] <infinity> cjwatson: We inherited it from base-passwd, but we don't USE it.
[04:13] <cjwatson> (also users has the wrong gid but that's a bit hard to fix now)
[04:14] <infinity> cjwatson: Wrong gid?  It's been 100 since the dawn of time.
[04:14] <cjwatson> it's a global static group, the range is 0-99
[04:14] <cjwatson> yes, the bug has existed since the dawn of time
[04:14] <infinity> cjwatson: I suspect the policy was made after the group, so who wins? :)
[04:14] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=25882
[04:14] <ubotu> Debian bug 25882 in base-passwd "base-passwd: avoid uid/gid 100" [Normal,Open]
[04:16] <infinity> Ahh, 5-digit bug reports, how I miss you.
[04:17] <mathiaz> seb128: in the user and group management, you can set user privileges, right ?
[04:17] <seb128> mathiaz: yes
[04:17] <mathiaz> seb128: could it be possible to add a new privilege there ?
[04:18] <seb128> yes
[04:18] <seb128> that's very easy
[04:18] <mathiaz> seb128: it maps to unix groups behind the scene right ?
[04:18] <seb128> correct
[04:18] <infinity> mathiaz: Ahh, yes, that might do nicely.
[04:18] <infinity> "Allow the user to manage network shares" or so.
[04:19] <infinity> And create an smbnet group or something.
[04:19] <mathiaz> infinity: yeah.
[04:19] <mathiaz> seb128: is it possible to specify default privileges for users ?
[04:19] <infinity> smbshare, whatever seems okay.
[04:19] <infinity> If you add users through that control panel, they get a default set of groups/privs, I believe.
[04:20] <seb128> mathiaz: yes, we already do that
[04:20] <infinity> If you use adduser raw, you're on your own, of course.
[04:20] <infinity> And upgrades won't get users in this group.
[04:20] <infinity> Always a problem, but nothing we can do anything about.
[04:20] <seb128> mathiaz: we have a desktop profile which list groups for a standard desktop user
[04:21] <mathiaz> seb128: does the group need to exist ?
[04:21] <infinity> It would have to.
[04:21] <seb128> mathiaz: not sure, I need to check
[04:21] <infinity> On the backend, it just uses "adduser user group", which will bail if the group doesn't exist...
[04:21] <mathiaz> infinity: yeah. of course...
[04:22] <mathiaz> hum. Which package should create the smbshare group then ?
[04:22] <infinity> (And rightfully so, since group membership is handled in /etc/groups.. Next to the group name.. :P)
[04:22] <mathiaz> is samba installed by default on the desktop ?
[04:22] <infinity> samba-common's on the desktop by default.
[04:23] <infinity> And samba-common's the right place for the group anyway.
[04:23] <mathiaz> so samba-common should create the smbshare group.
[04:23] <infinity> It's where all of samba's config magic lives.
[04:23] <mathiaz> and then we can add a privilege for the user and group applet.
[04:24] <infinity> And samba-common should also own /var/lib/samba/smbshare, root:smbshare, 1770
[04:24] <Lutin> pitti: can you give-back gok -0ubuntu2 on ppc, i386, amd64 please ?
[04:25] <infinity> cjwatson: Is it worth having this group in base-passwd, so it always exists?
[04:26] <mathiaz> infinity: how should upgrade be handled ?
[04:26] <infinity> cjwatson: I've always been fuzzy on that policy.  base-passwd inclusion is required (or encouraged) if more than one package will rely on the group, right?  Which would be the case here (samba and the GNOME stack)
[04:26] <infinity> mathiaz: Not at all.  You can't add users to groups on upgrades.  We just suffer.
[04:26] <mathiaz> infinity: I mean the samba options bits
[04:26] <mathiaz> infinity: we need to add options to smb.conf.
[04:26] <mathiaz> infinity: that would go in the postinst script ?
[04:27] <infinity> mathiaz: Same argument, really.  Besides, if it's not a fresh install, you won't be in the right groups, so who cares if samba's configured for it? :)
[04:28] <mathiaz> infinity: well. If we add a new user privilege and user enable the user privilege, it should work.
[04:28] <infinity> mathiaz: (You could use some postinst hackery to insert the appropriate lines, but you need to be careful about it, that's all)
[04:29] <infinity> mathiaz: the current postinst already shows how to mangle the config file (which it does on every new install, based on debconf values), so it's not a bad starting point.
[04:29] <mathiaz> infinity: ok. I get your point.
[04:29] <infinity> mathiaz: vorlon and I had a good cry over some of the sed expressions in that postinst when we were tweaking it. :)
[04:30] <cjwatson> infinity: base-passwd inclusion is required if something hardcodes the uid/gid in code for whatever mad reason; it's strongly discouraged otherwise
[04:30] <cjwatson> infinity: each package that uses it should just adduser --system it if it isn't there
[04:31] <infinity> cjwatson: Kay, so the gnome shares-admin thingee should adduser it as well, then, problem solved?
[04:31] <cjwatson> no reason why it needs to be done by just a single package
[04:31] <cjwatson> sounds good
[04:31] <infinity> seb128: ^^
[04:31] <cjwatson> we try to avoid too many static groups because they have to exist on every system and the id space is running a bit short for that
[04:31] <infinity> cjwatson: Yeah, fair enough.
[04:32] <cjwatson> the not-created-by-default static range somewhere up in high id space helps with that, but you've got to adduser that anyway, so just using --system should be fine
[04:32] <infinity> cjwatson: The reason I asked was because of "plugdev" which, being a recent addition to the flock, I would have assumed had no need for a static gid, so I figured it must have some other reason for being there.
[04:32] <cjwatson> plugdev got created because the installer needed it
[04:32] <seb128> infinity: looks good to me
[04:32] <infinity> Ahh.
[04:32] <cjwatson> and at the time I think we thought it needed to hardcode the id in fstab
[04:32] <seb128> infinity: so samba can be changed to use usershare and nautilus-share has to add the user when installed?
[04:33] <cjwatson> I think you can use a group name in some places in fact, but the gid is safer
[04:33] <infinity> seb128: Alright, feel free to "getent group smbshare || adduser --system smbshare" in the shares-admin postinst, then.
[04:33] <infinity> seb128: And mathiaz or I can work on making samba do something useful with that.
[04:33] <cjwatson> I'm also trying to avoid creating new global static ids until I get round to debconfifying base-passwd
[04:33] <seb128> infinity: nautilus-share is the package using it, thanks ;)
[04:34] <infinity> cjwatson: The "here's what I want to change, bring it?" prompt is being debconfified?
[04:35] <infinity> cjwatson: That might not present well...
[04:35] <infinity> cjwatson: Which I suppose might be why it's not been done yet. :)
[04:35] <cjwatson> pitti: new cdrtools/edgy-proposed uploaded to fix the build failure; please accept
[04:35] <cjwatson> infinity: precisely, it needs to be a bit more clever than that
[04:35] <cjwatson> and, being where base-passwd is in the dependency tree, it also needs some rather weird tricks to use debconf
[04:35] <cjwatson> ideally from C ...
[04:36] <infinity> Speaking of...
[04:36] <infinity> How goes the debconf->cdebconf battle on the Debian front?
[04:36] <cjwatson> they're coinstallable now (have been for a while), which makes it much less of a flag-day issue
[04:36] <cjwatson> still some more features to add to cdebconf to bring it to parity, though
[04:37] <infinity> I still look forward to the day that I can have cdebconf rule my buildd chroots.
[04:37] <infinity> Although, wait, coinstallable?  Does that mean there's some clever passthrough action where cdebconf does all the heavy lifting until its asked to do sometihng it doesn underestand?
[04:37] <infinity> Cause that would be nice...
[04:37] <infinity> Or much less useful than that? :)
[04:39] <pitti> cjwatson: thanks
[04:39] <cjwatson> no, I just mean they install into different bits of the filesystem so they don't conflict, and there's a DEBCONF_USE_CDEBCONF environment variable that makes the debconf confmodule start cdebconf instead
[04:40] <cjwatson> though you probably still need to set up something to create the cdebconf database
[04:40] <infinity> Ahh, okay, much less useful/cool, then.  Shame.
[04:40] <pitti> Lutin: done
[04:41] <Lutin> pitti: thanks
[04:41] <cjwatson> but yes, given that it ought to be possible to at least try out cdebconf in a normal system
[04:41] <cjwatson> there's nothing to say "if this package depends on debconf and not cdebconf then you REALLY need to use debconf for it"
[04:41] <cjwatson> which is sort of fundamentally hard
[04:41] <cjwatson> I think the only missing thing any package actually uses is probably capb escape, which I'm working on sporadically for ubiquity anyway
[04:47] <niemeyer> Hey everyone
[04:48] <mvo> hey niemeyer!
[04:48] <niemeyer> mvo!
[04:48] <niemeyer> mvo: How're things going in the far north? :)
[04:49] <pitti> tkamppeter: so, do you think that cups 1.3 would buy us much? quite risky IMHO, with it not being released yet and we cannot yet use too many of the new features; WDYT?
[04:49] <niemeyer> Would anyone familiar with packaging on amd64 be available for a quick question?
[04:49] <mvo> niemeyer: you mean so close to the north pole :P very nice! a bit hectic because of the tribe-4 release from yesterday, but otherise things are shaping quite nicely
[04:49] <pitti> niemeyer: packaging isn't amd64 special, but better just ask instead of asking to ask :)
[04:49] <mvo> niemeyer: ask your question, plenty of talented people around :)
[04:50] <niemeyer> Well, it's a pretty basic one, so I'm a bit ashamed of my ignorance on the topic ;-)
[04:50] <niemeyer> So..
[04:50] <infinity> Ooo, I like shameful questions.
[04:51] <niemeyer> I imagined that if we provide an i386 package, it'd be installable in an amd64 machine, but apparently apt is refusing to install it on someone else's system
[04:51] <infinity> Yeah, you can't do that.
[04:51] <cjwatson> niemeyer: It is not; multiarch is an ongoing plan that isn't done.
[04:51] <cjwatson> niemeyer: it's really easiest to just build for amd64 as well
[04:51] <infinity> There's no way to express that your i386 package depends on i386 libraries which would need to live somewhere else in the filesystem from the native amd64 libraries.
[04:51] <niemeyer> Ok.. but the actual binary should work there, right?
[04:52] <infinity> So, you just want to build your package for amd64 and provide both.
[04:52] <infinity> niemeyer: Is there any reason you want it to be an i386 binary on amd64?
[04:52] <cjwatson> niemeyer: possibly or possibly not, depending on what libraries it uses and whether i386 versions of those are installed on the system for some other reason
[04:52] <niemeyer> infinity: Right.. I remember these tricky details from past rpm times
[04:53] <niemeyer> infinity: Not really.. just brainstorming to see what'll be the best way to do it..
[04:53] <niemeyer> I guess we'll need PPAs now
[04:53] <infinity> niemeyer: The best way is to build for all your target architectures, IMO.
[04:53] <geser> pitti, tkamppeter: can something be done about but #125300 as it breaks direct PDF printing?
[04:53] <niemeyer> infinity: Yeah, true
[04:54] <niemeyer> Cool
[04:54] <infinity> s/hig/hi/
[04:55] <pitti> geser: oh, absolutely!
[04:55] <pitti> geser: no idea what happened to the conffile, but if it works well without, I'll fix it in Debian and merge it
[04:56] <bddebian> Heya
[04:56] <geser> at least it prints again
[04:56] <niemeyer> infinity, cjwatson: Thanks for the information guys..
[04:57] <pitti> geser: E [10/Aug/2007:16:57:17 +0200]  [Job 4]  pdftops-options: -cfg /etc/cups/pdftops.conf
[04:57] <pitti> E [10/Aug/2007:16:57:17 +0200]  [Job 4]  pdftops_path exited with signal 127,
[04:57] <pitti> E [10/Aug/2007:16:57:17 +0200]  [Job 4]  Empty print file!
[04:57] <pitti> geser: ^ liek that?
[04:58] <bddebian> seb128: Sorry, for bug #131326 I buried the reasons that they aren't necessary inside the Ubuntu changelog entry
[04:58] <ubotu> Launchpad bug 131326 in ivtv "[Sync Request]  ivtv 0.10.5-2" [Wishlist,Fix released]  https://launchpad.net/bugs/131326
[04:58] <fabbione> pitti: you don't use prerm on a fresh installation .. ?
[04:58] <pitti> fabbione: hm, true that
[04:58] <pitti> fabbione: my bad then
[04:58] <seb128> bddebian: I read several time the text and I didn't see any mention of "Switch all 0.8's to 0.10" in the Debian changelog
[04:59] <fabbione> pitti: even if you run it, it's ok to exit 0 since there is no daemon to stop
[04:59] <bddebian> seb128: Give me one sec
[05:01] <bddebian> seb128: ivtv (0.10.1-2) unstable; urgency=low
[05:01] <bddebian>   [ Ian Campbell ]
[05:01] <bddebian>   * Update debian/control to corectly refer to the 0.10 release.
[05:02] <pitti> fabbione: done
[05:02] <seb128> bddebian: you didn't mention that on the bug
[05:02] <fabbione> pitti: ok cool. thanks i am off :)
[05:02] <pitti> fabbione: bye, have a nice weekend
[05:02] <seb128> bddebian: there is lot of syncs request, could you try to include all the required informations when you file one?
[05:03] <geser> pitti: it prints again if I modify /usr/lib/cups/filter/pdftops line 107 to $cmdopt = "";
[05:03] <bddebian> seb128: I was not specific enough, yes, I have apologized twice now.  But I did state that it was fixed in 10.1-1/2
[05:03] <pitti> geser: yep, I'm at it
[05:03] <pitti> geser: thanks for pointing
[05:04] <seb128> bddebian: ok, sorry to mention it again, you should probably just use the requestsync tool ;)
[05:04] <bddebian> pfft :-)
[05:04] <bdmurray> pitti: is "The fix can be verified by trying a dapper upgrade from dapper->edgy with finish locales." the steps to reproduce?
[05:04] <bddebian> I think I probably should have just stayed away :-)
[05:04] <seb128> bddebian: what? it's very nice, include details like the changelog and if the package is an universe one
[05:05] <pitti> bdmurray: mvo would know better, I think
[05:06] <pitti> bdmurray: according to comment 9 that would be it
[05:06] <mvo> bdmurray: what bugnumber is that? sorry if the instructions are bad, I will improve them before you continue
[05:06] <bddebian> Hmm, would requestsync work over my ssh connection or does it require a browser?
[05:07] <seb128> bddebian: sync done, thanks for the bug ;)
[05:07] <seb128> bddebian: don't bother for this one, you can try next time
[05:07] <pitti> bddebian: requestsync sends mail
[05:07] <bddebian> Heh, NP, I'll do better, thanks
[05:07] <bddebian> pitti: That's what I thought and I don't have mail set up on that box :-(
[05:08] <pitti> bddebian: not necessary, it SMTPs directly to ubuntu.com's NX :)
[05:08] <pitti> bddebian: MX even
[05:08] <bddebian> Ohh, nice
[05:10] <pitti> geser: I get the same error message with that, though
[05:17] <geser> pitti: I get here now: PID 11635 (/usr/lib/cups/filter/pdftops) exited with no errors.
[05:17] <geser> but it still doesn't print :(
[05:18] <cjwatson> pitti: can I upload debian-installer to dapper-proposed to pick up that hw-detect SRU proposal?
[05:18] <bdmurray> mvo: it is bug 68553
[05:18] <ubotu> Launchpad bug 68553 in python-apt "Dapper upgrade to Edgy: Frozen dist-upgrade and failed second run (in Finnish locales" [High,Fix committed]  https://launchpad.net/bugs/68553
[05:19] <pitti> cjwatson: that would be good; I asked for that in the bug; if we can sensibly build CDs from that and copy it to -updates later?
[05:19] <geser> pitti: I've to run the pdf through pdf2ps and print then the ps file
[05:19] <cjwatson> pitti: oh, I missed the bug comment
[05:21] <mvo> bdmurray: I updated the instructions, they invole a upgrade, I can write a python-testcase if you do not have a dapper vm around and do not have the time to install one
[05:22] <geser> mvo: can you look at the debdiff in bug #131035 and tell if it's correct?
[05:22] <ubotu> Launchpad bug 131035 in compizconfig-python "Doesn't depend on python, ships .a and .la files" [Undecided,Confirmed]  https://launchpad.net/bugs/131035
[05:22] <mvo> geser: thanks, I'm in the middle of updating that to current git, I will incoperate it into the package
[05:23] <bdmurray> mvo: I have a dapper vm so should be set
[05:24] <geser> mvo: thanks
[05:24] <mvo> bdmurray: oh, it will still take long to verify, but it should be mostly non-interactive after you clicked on "upgrade"
[05:25] <bdmurray> mvo: and it needs verification for edgy also correct?
[05:25] <pitti> geser: I'm trying: /usr/lib/cups/filter/pdftops 1 martin 'test' 1 '' test.pdf
[05:25] <pitti> geser: and with your change it exits cleanly here, fails with current gutsy version; hmm
[05:25] <pitti> geser: I wonder why it fails when called by cups
[05:27] <mvo> bdmurray: yes
[05:27] <pitti> bdmurray: thanks; at least you can say that, after this, you fixed *all* of your assigned dapper.2 bugs :-P
[05:28] <norsetto> seb128: do you have thilo's email? I can't find it in our record.
[05:28] <seb128> norsetto: what email?
[05:28] <norsetto> seb128: his (thilo) email?
[05:28] <pitti> geser: oh, *headdesk*, my bad; bad apparmor rules
[05:29] <seb128> norsetto: email address you mean?
[05:29] <norsetto> seb128: err, yes?
[05:31] <geser> pitti: when I try your command and and save the generated postscript to a file and try to view it with evince I get GPL Ghostscript 8.60: Unrecoverable error, exit code 1 (print this file doesn't also work)
[05:31] <pitti> geser: hm, but that's a gs bug then
[05:31] <geser> ok
[05:32] <pitti> geser: does another pdf work?
[05:33] <pitti> mathiaz: REJECTING m access to /usr/lib/perl/5.8.8/auto/POSIX/POSIX.so (foomatic-rip(19010) profile /usr/sbin/cupsd
[05:33] <pitti> mathiaz: ^ this sounds like a good addition to the perl abastraction
[05:33] <Lutin> pitti: can you give-back cairodevice and foreign amd64, ppc please ?
[05:34] <pitti> Lutin: done
[05:34] <geser> pitti: I get the same error when I try it with an other PDF
[05:34] <pitti> geser: do you have -3ubuntu1?
[05:34] <geser> pitti: both times i get Error: /configurationerror in --setpagedevice-- before the gs stack
[05:34] <Lutin> thanks pitti :)
[05:35] <geser> pitti: cupsys         1.2.12-3ubuntu1
[05:35] <pitti> geser: dmesg | grep 'REJECTING.*cups' ?
[05:36] <geser> pitti: nothing in dmesg but I still run the feisty kernel as the gutsy one is missing the wifi drivers for my card
[05:36] <pitti> geser: ah, so it's not apparmor then
[05:37] <geser> running the same pdf through /usr/bin/pdf2ps produces a ps file which can be viewed with evince but not the one created with /usr/lib/cups/filter/pdftops
[05:38] <pitti> geser: oh, interesting; is the diff comprenehsible?
[05:41] <geser> pitti: I'd say no: 1 file changed, 873 insertions(+), 2180 deletions(-)
[05:41] <pitti> geser: erk
[05:41] <geser> the one generated by pdf2ps is 60k bigger
[05:41] <pitti> geser: so, we should debug how cups' pdftops wrapper calls /usr/bin/pdftops
[05:42] <pitti> and find the option that breaks it
[05:43] <patate> hi, I'm trying to build some packages... and I wonder... if there is any way to apt-get install package and make sure it won't start/restart or mess with running process
[05:43] <patate> like chroot'ing into an installed ubuntu system
[05:43] <patate> and apt-get install apache
[05:43] <patate> but I don't want it to restart or start apache and impact the apache in the host system
[05:44] <cjwatson> chroots aren't sufficiently safe to be certain of anything, but I think it should be considered a bug if it touches the host system's apache
[05:44] <cjwatson> I think apache uses a pidfile to avoid that problem
[05:45] <patate> by default, installing a package... the installed service is trying to start
[05:45] <patate> like... debootstrap is not trying to start anything
[05:45] <patate> but it do apply all post-install script correctly
[05:46] <geser> pitti: I get the same postscript file when I use /usr/bin/pdftops instead of the pdftops wrapper
[05:47] <pitti> geser: huh? how can one work and the other not then?
[05:48] <geser> ghostscript: /usr/bin/pdf2ps and poppler-utils: /usr/bin/pdftops
[05:48] <pitti> geser: ah, I see
[05:48] <pitti> geser: so it is a ghostscript bug after all
[05:48] <ion_> patate: I havent checked, but perhaps invoke-rc.d checks whether its being run in a chroot.
[05:49] <patate> ion_: but you can't invoke-rc.d something that had not been installed yet
[05:49] <patate> I want to prevent a package to start itself after installation
[05:50] <ion_> Try on a support channel.
[05:50] <geser> pitti: uses poppler ghostscript internally?
[05:50] <patate> ok
[05:50] <pitti> geser: no, it uses the xpdf code
[05:51] <geser> the pdf2ps from ghostscript produces printable postscript but not pdftops (used by cups)
[05:52] <pitti> geser: ah, so it's this way around; right, cups' wrapper calls the poppler one
[05:53] <cjwatson> patate: putting the following in /usr/sbin/policy-rc.d may help:
[05:53] <cjwatson> #! /bin/sh
[05:53] <cjwatson> exit 101
[05:53] <cjwatson> see /usr/share/doc/sysv-rc/README.policy-rc.d.gz
[05:55] <pitti> geser: indeed, confirmed here
[05:55] <cjwatson> pitti: d-i on its way into the dapper-proposed queue now; please accept when it's therer
[05:55] <cjwatson> there
[05:55] <pitti> cjwatson: will do, thank you
[05:55] <cjwatson> I *think* it should build against -proposed by itself, but if it doesn't, please fix since I'll probably be on vacation :)
[05:56] <pitti> cjwatson: I'll check the hw-detect version in the build log/manifest/whatever
[05:57] <cjwatson> thanks
[06:03] <pitti> geser: so does removing the -cfg option actually have any effect? I don't see a difference here (but I don't get that verbose error message you get, either)
[06:05] <pitti> geser: anyway, I fixed it in Debian's trunk to check for the file before supplying it; can't hurt
[06:05] <pitti> geser: can you please file a poppler bug about pdftops?
[06:06] <geser> pitti: I see that my printer gets some data submitted
[06:06] <geser> pitti: will do
[06:06] <pitti> geser: thank you
[06:10] <geser> pitti: downgrading libpoppler1 and poppler-utils to 0.5.4-6ubuntu1 (the version before the current one) produces printable postscript
[06:11] <pitti> geser: good data point
[06:24] <bryce> morning
[06:24] <pitti> hey bryce
[06:25] <Hobbsee> hi bryce
[06:27] <geser> pitti: about the -cfg option: diff the output between pdftops from poppler-utils 0.5.4 and the pdftops from 0.5.9 shows:
[06:27] <Hobbsee> heya mvo!
[06:27] <geser> +  -preload            : preload images and forms
[06:27] <geser> -  -cfg <string>       : configuration file to use in place of .xpdfrc
[06:28] <pitti> geser: ah-ha
[06:28] <pitti> geser: so that cupsys fix should at least help a bit, but if it produces wrecked postscript, it won't get very far
[06:29] <LaserJock> hi Hobbsee
[06:29] <Hobbsee> heya LaserJock
[06:30] <LaserJock> Hobbsee: what time is it there?
[06:30] <Hobbsee> LaserJock: 2.30am?
[06:30] <LaserJock> hmm
[06:31] <geser> pitti: http://paste.ubuntu-nl.org/33252/ is the diff between the postscript file created once with pdftops from 0.5.4 and once with pdftops from 0.5.9
[06:31] <pitti> geser: please add that to the poppler bug, too
[06:32] <pitti> wow, that bounding box looks broken
[06:32] <Hobbsee> LaserJock: it's not *that* late.
[06:34] <nixternal> it must be nice to be able to stay up that late and wake up early still :)
[06:38] <Hobbsee> nixternal: wake up early?  what's that?
[06:38] <nixternal> hehe
[06:38] <Hobbsee> nixternal: i dont have work tomorrow mornign, it's all good.
[06:38] <nixternal> lucky you
[06:39] <Hobbsee> i just have it tomorrow night
[06:39] <Hobbsee> hopefully they'll be someone with me.
[06:39] <geser> pitti: filed as bug #131591
[06:39] <ubotu> Launchpad bug 131591 in poppler "pdftops from poppler-utils 0.5.9-0ubuntu1 produces broken postscript" [Undecided,New]  https://launchpad.net/bugs/131591
[06:40] <pitti> geser: thank you
[06:40] <pitti> I'm off now, have a nice weekend everyone
[06:50] <highvoltage> hello jono
[06:51] <jono> hey highvoltage
[06:54] <LaserJock> hi jono
[06:56] <keescook> Hobbsee: is main unfrozen?
[06:57] <Hobbsee> keescook: i assume so.
[06:57] <keescook> Hobbsee: okay, cool, thanks.
[06:59] <LaserJock> stupid school ;-)
[07:13] <norsetto> seb128: sebastien, perhaps you may want to look at bug 131584. I think it is invalid (marked it so already).
[07:13] <ubotu> Launchpad bug 131584 in compiz "compiz.wrapper not pretty with bash" [Undecided,Invalid]  https://launchpad.net/bugs/131584
[07:15] <mvo> "not pretty" ey? :P
[07:16] <cjwatson> norsetto: 'echo "\n"' isn't POSIX; you're mistaken
[07:16] <highvoltage> not even with -e ?
[07:16] <cjwatson> http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html
[07:16] <norsetto> cjwatson: I checked the standard
[07:16] <cjwatson> highvoltage: -e is not portable
[07:16] <cjwatson> norsetto: not closely enough
[07:17] <cjwatson> "It is not possible to use echo portably across all POSIX systems unless both -n (as the first argument) and escape sequences are omitted."
[07:17] <highvoltage> cjwatson: ah
[07:17] <norsetto> yes, that; didn't I read it correctly?
[07:17] <cjwatson> Debian policy explicitly amends that for all our shells to require -n
[07:17] <cjwatson> norsetto: "\n" is an escape sequence and therefore cannot be used in portable code
[07:17] <cjwatson> policy> ... but says nothing about -e or escape sequences
[07:17] <cjwatson> either just 'echo' without arguments (possibly twice) or use printf
[07:18] <cjwatson> I've reopened the bug
[07:19] <norsetto> cjwatson: I don't understand, the policy explicitely mentions /n?
[07:19] <minghua> I remember printf should work instead of echo -n.
[07:19] <norsetto> cjwatson: sorry, I mean, the posix spec
[07:19] <cjwatson> norsetto: I am not sure how this is unclear?
[07:19] <cjwatson> Debian policy explicitly exempts -n, but escape sequences in echo are still disallowed
[07:19] <cjwatson> (phone)
[07:20] <Riddell> asac: is gnash going to be default in gutsy?
[07:21] <asac> not on the CD
[07:21] <asac> it will show up in plugin finder dialog
[07:21] <asac> next to flashplugin-nonfree
[07:21] <asac> hopefully in gutsy+1 its in a state that we can make it default without confusing users that don't know anything about gnash vs. flashplugin-nonfree
[07:25] <mvo> geser: compizconfig is merged into bzr, should I sponsor the upload
[07:26] <norsetto> cjwatson: what I mean is that echo -n is not posix, but admitted by the Debian policy ( I read is the only exception), but echo "\n" IS posix
[07:26] <geser> mvo: yes, please
[07:27] <cjwatson> norsetto: echo "\n" is not POSIX
[07:27] <norsetto> cjwatson: in any case, the problem is the fact that the users symlink /bin/sh to bash
[07:27] <cjwatson> norsetto: it is an XSI extension
[07:27] <cjwatson> norsetto: that is NOT a problem
[07:27] <cjwatson> please do not reject bugs on that basis!
[07:27] <cjwatson> that is explicitly supported
[07:28] <norsetto> cjwatson: I'm glad I checked, don't get too excited :-)
[07:28] <cjwatson> I'm not excited, but you started using capital letters ;-)
[07:29] <norsetto> cjwatson: WHO USED CAPITAL LETTER?
[07:29] <norsetto> :-)
[07:31] <pygi> mvo, what you did this time? :)
[07:32] <norsetto> hey take it easy with mvo, he still owes me two emails
[07:34] <mvo> norsetto: *cough* mailbacklog *cough*
[07:37] <seb128> norsetto: thanks, look like other people already commented
[07:37] <norsetto> seb128: did they? I didn't notice .....
[07:37] <bryce> mvo, have you heard anything about the zero-copy TFP feature in xserver 1.4 giving improvements to compiz performance?
[07:37] <mvo> norsetto: tea helps me best usually
[07:37] <Caesar> Can I get a crash course in looking up Ubuntu bugs?
[07:38] <mvo> bryce: yes - that would only be for intel, right?
[07:38] <Caesar> Like I've just found issues with vol_id in dapper
[07:38] <Caesar> How can I find out when and if that's been fixed in subsequent releases?
[07:38] <bryce> mvo, intel and one of the radeon chipsets
[07:38] <Caesar> Actually, it's probably an upstream bug...
[07:39] <bryce> mvo, r300 and intel
[07:39] <Hobbsee> mvo: try rm -rf'ing all the mail.
[07:39] <Hobbsee> seems to work here
[07:39] <Hobbsee> (on sponsorship mail, at least!)
[07:39] <seb128> norsetto: the bug has been reopened with a comment from Colin
[07:40] <norsetto> seb128: really!?
[07:41] <norsetto> seb128: just kidding, I'm still licking my wounds, colin is a tough juggler ....
[07:41] <mvo> bryce: I was not aware of r300. my understanding is that it only helps on uma cards, does the r300 support that?
[07:41] <Hobbsee> norsetto: he bites :P
[07:42] <norsetto> Hobbsee: that double nelson was a killer, let me tell you
[07:42] <Hobbsee> :P
[07:42] <Hobbsee> right, goodnight for real this time!
[07:43] <mvo> bryce: but I have a r200, so no cookies for me .)
[07:47] <Amaranth> mvo: Apparently the zero-copy tfp stuff right now is a hack using EXA
[07:47] <Amaranth> mvo: So once again we don't get it because EXA is generally broken
[07:47] <mvo> Amaranth: how does it work on a non-uma architecture?
[07:48] <Amaranth> It just means it doesn't do a copy in system RAM, apparently
[07:48] <Amaranth> Still have to copy it to the vram
[07:51] <mvo> Amaranth: aha, now it comes together
[07:51] <Amaranth> I think they can do it with true zero-copy later
[07:52] <Amaranth> But with the restriction you mentioned
[07:53] <mvo> Amaranth: so its one-less-copy for now :P
[08:03] <LaserJock> *sigh* and the love-hate relationship with gnuplot continues
[08:09] <bddebian> LaserJock: :)
[08:10] <LaserJock> Home, End, and Delete keys don't work in gnuplot (just get the funky codes)
[08:11] <LaserJock> and upstream says it's distro's fault since their internal readline has worked since before Linux existed
[08:16] <bryce> mvo, not sure about uma
[08:24] <minghua> LaserJock: Are you saying the gnuplot people claim that the internal readline should have Home, End, and Delete support?
[08:24] <LaserJock> minghua: well, yes, they say it's the distros that've screwed up
[08:25] <minghua> Nah, doesn't work in Debian either.
[08:25] <LaserJock> and can't get keycodes consistent
[08:25] <LaserJock> of course it doesn't work in Debian :-)
[08:25] <minghua> But I know with GNU readline those keys work.
[08:25] <LaserJock> it was reported in Gentoo, Debian, and Ubuntu
[08:25] <LaserJock> and OpenSuse I think too
[08:25] <LaserJock> but upstream says it's the distros
[08:26] <highvoltage> LIES!
[08:26] <minghua> LaserJock: I think the efforts should be put into getting libedit support.
[08:26] <minghua> LaserJock: I tried about a year ago, at least it compiles.
[08:26] <LaserJock> minghua: the history support was fixed though
[08:26] <LaserJock> minghua: is that the bsd readline library?
[08:27] <minghua> LaserJock: Yes.  And actually there are two, libedit and libeditline.
[08:28] <minghua> (Unfortunately, I can't remember which one is the one I tried.)
[08:28] <minghua> :-(
[08:28] <LaserJock> yes, I think it's worth the effort
[08:28] <LaserJock> readline's license is probably not going to change
[08:28] <LaserJock> and neither is gnuplot's
[08:29] <LaserJock> it's probably *they* most annoying bug I've ever really had personally
[08:29] <LaserJock> s/they/they/
[08:29] <LaserJock> bah
[08:29] <minghua> Sure they can turn on gnu readline support by default?
[08:29] <LaserJock> s/they/the/
[08:29] <LaserJock> minghua: not sure
[08:30] <LaserJock> Ubuntu was the first distro I ever had a problem
[08:44] <LaserJock> minghua: take a look at the forwarded bug in debian bug#305501
[09:05] <wasabi> So what's LPIA stand for?
[09:05] <ion_> Just a guess: low-power intel architecture.
[09:05] <wasabi> Hmm. A separate arch? Same instruction set or ?
[09:05] <ion_> I have no idea. :-)
[09:05] <ion_> Im sure someone will enlighten us.
[09:06] <Ng> infinity is the man to ask :)
[09:06] <mjg59> Yes
[09:06] <mjg59> Same instruction set but different optimisations
[09:06] <Ng> that's the one :)
[09:06] <wasabi> Interesting.
[09:06] <wasabi> optimizations at teh arch level, something that couldn't be addressed in packaging on i386?
[09:07] <wasabi> I'm just curious. ;)
[09:07] <mjg59> They'd be pessimisations for the rest of x86
[09:09] <wasabi> oh wow, I didn't know hildon made it in
[09:15] <cjwatson> wasabi: #ubuntu-mobile if you're interested
[09:33] <bdmurray>  /etc/iftab has been deprecated in Gutsy correct?
[09:34] <mjg59> Yes
[09:34] <cjwatson> bdmurray: yes, by udev rules; /etc/udev/rules.d/70-persistent-net.rules if you need to touch them
[09:34] <cjwatson> I think Scott said he still needed to do some migration logic
[09:35] <bdmurray> Right, is that documented somewhere though?
[09:36] <cjwatson> probably not
[09:40] <bdmurray> cjwatson: by the way is 130131 really a debian-installer bug?
[09:44] <ijuz> i have something odd...  gutsy from today, gnome suspends to ram without problems and resumes (well, every 5 resumes i have to switch with alt+f7 back to X), but with KDE i quickly get gfx corruptions and after about 3 resumes the gfx doesn't come back at all (the system is working, i can log into it with ssh)
[09:48] <ijuz> i thought the scripts in /etc/acpi/ are doing the suspend/resume, so i don't get what different between KDE and gnome
[09:51] <cjwatson> bdmurray: no, it's xresprobe - I've reassigned, thanks
[09:52] <bdmurray> Is xresprobe is used to determine the vga setting?
[09:54] <cjwatson> bdmurray: the vga= kernel parameter? no
[09:54] <cjwatson> we don't set that by default, ever
[09:54] <cjwatson> (except by the video mode menu in gfxboot; which isn't exactly by default but is probably more visible than it ought to be)
[09:55] <ijuz> i have seen 130131 in the same way on my gm965 laptop with 20070807.1
[09:56] <bdmurray> Okay, I'm just not clear on how it is xresprobe - where it fits into the alternate CD installer.
[09:57] <cjwatson> bddebian: alternate CD installer installs a bunch of packages including xserver-xorg which calls xresprobe in its postinst
[09:57] <bddebian> Not me, you don't love me :)
[09:57] <cjwatson> err :)
[09:57] <ijuz> afair it happened here before you can choose the resolution
[09:57] <cjwatson> bdmurray: ^--
[09:58] <cjwatson> ijuz: xserver-xorg's postinst often doesn't prompt for resolution if it thinks it can guess
[09:58] <cjwatson> ijuz: and in any case I think it tries to probe first in order to select reasonable defaults
[09:58] <ijuz> ok
[09:58] <ijuz> makes sense
[09:58] <wasabi> how far are we away from config-less X?
[09:58] <cjwatson> anyway, it's a very very long-standing xresprobe bug that sometimes it buggers up the display
[09:59] <cjwatson> as far as the alternate CD goes, wait for a while and then hit enter a few times to finish the install, as long as you didn't want to select anything other than the defaults :)
[09:59] <ijuz> xresprobe intel find here also nothing useful:
[09:59] <ijuz> id:
[09:59] <ijuz> res:
[09:59] <ijuz> freq:
[09:59] <ijuz> disptype: lcd/lvds
[10:00] <cjwatson> bryce may be able to help on the details, but I'm afraid I can't
[10:01] <mjg59> xresprobe needs updating to handle intel
[10:01] <mjg59> It only knows how to do i810
[10:02] <bdmurray> ah, that's interesting
[10:03] <mjg59> /usr/share/xresprobe/lcdsize.sh is the main one
[10:03] <ijuz> and i810 doesn't support gm965
[10:05] <calc> seb128: whats the eta for the glib 2.14.0 upload?
[10:05] <calc> seb128: i saw a claim that the init bug may be fixed in it
[10:06] <calc> seb128: i'm also trying a build without some patches that may be at fault to see if that helps also in OOo case
[10:06] <calc> seb128: some of the OOo patches that is
[10:06] <seb128> calc: I don't plan to upload 2.14.0, make check hits some errors, I was waiting for a 2.14.1
[10:07] <mjg59> Hang on, I'll fix xresprobe now
[10:07] <calc> seb128: ok no problem
[10:07] <seb128> calc: I can uploaded a patched version if you want
[10:07] <calc> seb128: when is 2.14.1 due any idea?
[10:07] <calc> seb128: oh the patch i am talking about is one they think is the cause on the OOo side
[10:08] <calc> seb128: someone claimed it worked fine for them with glib 2.14.0 though so it might be worked around on the glib side as well
[10:08] <seb128> calc: I'll try with 20
[10:08] <seb128> .2.14.0
[10:08] <seb128> and upload it openoffice starts with it
[10:08] <calc> seb128: ok, try it with -gtk -gnome removed and see if it starts
[10:08] <seb128> (there is a patch to make it build in svn)
[10:08] <seb128> right
[10:08] <norsetto> can anyone have a look at this: https://conky.svn.sourceforge.net/svnroot/conky/trunk/conky1/COPYING
[10:09] <calc> seb128: if it starts with both of those removed then it should be ok, otherwise once i get OOo built i am going to see if they patch they think is buggy is the one at fault on OOo side of things
[10:09] <norsetto> Is it acceptable as an upstream license?
[10:09] <calc> er ...the patch they think...
[10:09] <mjg59> norsetto: Yes
[10:10] <mjg59> The binary package as a whole will be GPL
[10:10] <calc> norsetto: depending on the contents of licenses (assuming they are normal licenses)
[10:10] <calc> and iirc the BSD one has to be the three clause BSD one, right guys?
[10:10] <mjg59> calc: No, 4-clause is free
[10:10] <calc> oh ok
[10:10] <mjg59> But it's 3 clause anyway
[10:11] <calc> or whatever was in that part, i have forgotten exactly what it was
[10:12] <norsetto> its the 3 clause BSD
[10:12] <calc> norsetto: ok np, it should be fine then :)
[10:12] <norsetto> cool! thx guys one hug each :-)
[10:13] <calc> "All advertising materials mentioning features or use of this..." part of 4 clause was what I was meaning is non-gpl compatible (iirc) eg openssl
[10:13] <pitwalker> Hi, all!
[10:13] <cjwatson> right, that's free but GPL-incompatible
[10:13] <calc> norsetto: but since its 3 clause it is fine
[10:14] <calc> mjg59: the 3 clause i mentioned is because that code was listed as being relicensed under GPL
[10:14] <calc> mjg59: 4 clause is ok, but not as relicensed under gpl aiui
[10:15] <mjg59> Yeah
[10:15] <calc> relicensing in this case is a misnomer its GPL code interlinked with BSD code
[10:17] <cjwatson> "distributed under the terms of" is the usual languages
[10:17] <cjwatson> language
[10:17] <calc> seb128: oh yea let me know one way or the other wrt the glib 2.14.x test if you don't mind :)
[10:17] <mjg59> ijuz: Can you try http://www.codon.org.uk/~mjg59/tmp/xresprobe_0.4.24ubuntu4_i386.deb ?
[10:17] <ijuz> sure
[10:18] <calc> mjg59: any news wrt to the amd64 vbetool?
[10:18] <ijuz> halt success
[10:18] <ijuz> half
[10:18] <ijuz> root@ijuz-laptop:~# xresprobe intel
[10:18] <ijuz> id:
[10:18] <ijuz> res: 1920x1200
[10:18] <ijuz> freq:
[10:18] <ijuz> disptype: lcd/lvds
[10:18] <mjg59> calc: Nope. I think I've worked out Kyle's problem, but yours is still a bit odd
[10:18] <mjg59> ijuz: That's all you'll get for lvds
[10:18] <calc> mjg59: ok
[10:18] <ijuz> but when i run it on the local console the screen stays black
[10:19] <calc> mjg59: if you need me to do any further tests just let me know, i'll be happy to help out in any way i can :)
[10:19] <ijuz> i still can switch to X and back, but the console stays black until i run xreprobe again from ssh... then the console works again fine
[10:19] <mjg59> ijuz: No clue there.
[10:20] <mjg59> X issue rather than xresprobe in any case, I suspect
[10:20] <ijuz> yes
[10:22] <mjg59> Anyway, uploaded
[10:23] <ijuz> it fails only about ever second time, very uncool
[10:27] <norsetto> still on that package, I see some sources are GPL 2.1 and others GPL 3; COPYING is GPL 3: I guess this is ok?
[10:27] <mjg59> Yes
[10:27] <bryce> mjg59: cool thanks, I'd been wondering about how to best add intel in there
[10:30] <norsetto>  /me thinks than better safe than sorry should actually be better sorry if it is safe .....