[00:13] <Roey> bryce:  heya Bryce, Jonathan Riddell referred me to you.  I had a question about this set of modules for the Linux kernel and X for accelerating 2d and GL for KVM and Xen guests (it's called "VMGL"); I was wondering if and when it will get incorporated into the next version of Ubuntu.  Its home page is here: http://www.cs.toronto.edu/~andreslc/xen-gl/
[00:13] <Roey> Riddell:  thanks
[00:15] <bryce> Roey: I hadn't heard of this prior to now.  Is there a bug id# open about the current status of it?
[00:16] <bryce> Roey: if it isn't already in debian, then the first task would be to get it packaged
[00:16] <Roey> ok
[00:16] <Roey> it's just a project page so far, as far as I know--they had a paper about this for some conference back in '07
[00:16] <Roey> and they have tarballs and rpms
[00:16] <Roey> (just not an ubuntu module, yet)
[00:17] <bryce> I see it is at version 0.1, which sounds pretty immature
[00:17] <Roey> bryce, and I haven't checked yet about any submission as a bug id
[00:17] <Roey> ok
[00:17] <bryce> Roey: have you tested it?  does it do what it claims?  Or is it still early on in development?
[00:17] <Roey> bryce:  right, right, it's rather embryonic
[00:17] <Roey> bryce:  I just found out about it.
[00:17] <bryce> gotcha
[00:17] <Roey> bryce:  in #ubuntu+1,
[00:17] <Roey> there's this one guy who -has- tried it and says it works for him
[00:18] <bryce> ok, so step #0 is verify it does work on ubuntu and does something useful.  ;-)  #1 after that would be packaging it, and upload to universe
[00:18] <Roey> his nick is h3sp4wn; he should be here momentarily (if he's at his computer)
[00:18] <Roey> ok
[00:18] <Roey> bryce:  ok
[00:19] <Roey> bryce:  which archs must it be compiled for in order to submit to universe?
[00:19] <bryce> once it's had time in universe to get tested, continue development, and is felt to be well polished and useful, then main inclusion can be considered (which requires some code review, security analysis, etc.)
[00:19] <Roey> right right
[00:19] <Roey> but you gave me what I was looking for, which is a roadmap
[00:19] <Roey> thanks
[00:19] <bryce> in the packaging you'll specify which arch it works in.  so as long as it works for one arch, that should be ok
[00:19] <Roey> ok
[00:20] <bryce> i.e., there's an arch field in debian/control
[00:20] <Roey> ah, got it
[00:20] <bryce> if it works on i386, that would be a good start
[00:20] <Roey> hrm, that'd require me to compile a different kernel in that case
[00:21] <Roey> (using a quad-core intel core here)
[00:21] <Roey> q6600
[00:23] <bryce> Roey: I suspect amd64 would be fine too, although you'd probably get better testing coverage if there's an i386 package.  Maybe that could come later after it's in universe though.
[00:23] <Roey> do you mean i386 and not i686
[00:23] <Roey> ?
[00:26] <crimsun> ia32 (32-bit) vice amd64 (64-bit)
[00:51] <rhineheart_m> when will be the hardy be released?
[00:52] <TheMuso> rhineheart_m: http://wiki/ubuntu.com/HardyReleaseSchedule
[00:58] <rhineheart_m> TheMuso, are you sure with the link you've provided. It seems that it is redirected to www.wiki.com
[00:58] <slangasek> that was meant to be http://wiki.ubuntu.com/HardyReleaseSchedule
[01:00] <rhineheart_m> april 24?
[01:01] <slangasek> yes
[01:02] <rhineheart_m> what is Intrepid Ibex? Is it a LTS also?
[01:02] <slangasek> it's the next release after hardy; there are no plans for it to be an LTS, no
[01:02] <rhineheart_m> just like the gutsy gibbon?
[01:03] <slangasek> I expect it's going to be a release with an 18-month support cycle if that's what you mean, yes
[01:03] <rhineheart_m> slangasek, what's the difference for heron from gutsy? Is it also a good version for server?
[01:04] <slangasek> rhineheart_m: I think you might find that #ubuntu is better suited to answering these questions for you; this channel is for development of Ubuntu
[01:05] <rhineheart_m> oaky.. thanks.. no plans yet to include webmin again to repo as it has been updated by the author already?
[01:05] <slangasek> LTS is more likely to be deployed on servers than regular Ubuntu releases due to the longer support cycle, but I couldn't tell you how much more likely
[01:05] <slangasek> webmin isn't going to be included in hardy, no
[01:06] <rhineheart_m> any projected available web based GUI for hardy?
[01:09] <TheMuso> slangasek: thanks. Slip of the cold finger.
[01:10] <slangasek> rhineheart_m: ebox is included in universe for hardy.
[01:11] <rhineheart_m> slangasek, how I wish a better web based GUI will be included that could handle multiple sites configuration... just like ISPConfig
[01:54] <Riddell> siretart: the problems I was having playing DVDs were because I havn't set the region
[02:31] <sigger_> I wrote up a little feature proposal on the wiki and created a Launchpad proposal for it.  What is the next step?
[02:32] <bryce> url?
[02:32] <sladen> sigger_: get it ready for the next UDS
[02:32] <bryce> next step is usually for me to review/approve it
[02:32] <bryce> er whoops!
[02:32] <bryce> sorry thought this was #inkscape.  nevermind me
[02:32] <bryce> sigger_: next step is to get it approved by mdz.  ;-)
[02:32] <sigger_> hehe, np bryce
[02:33] <sigger_> sladen: well, I unfortunately am not in a position to actually code it.
[02:33] <Caesar> Has anything changed lately with the alternate installer that would make uuid-runtime no longer be installed by default?
[02:34] <Caesar> I'm not sure what to look at to try and figure it out myself
[02:34] <sigger_> sladen: If I leave it be, will is it in queue for someone to look at it, or do I need to take a further action to propose it?
[02:35] <sigger_> s/will/
[02:36] <sladen> Caesar: do you mean "I have tried to install using the alternate and found a possible bug with by-UUID not working on $this machine"?
[02:36] <sladen> Caesar: things won't have intentionally changed to break something that previously worked
[02:38] <srbaker> folks
[02:38] <srbaker> i just installed hardy beta on a laptop that wouldn't install previous versions without screwing around.
[02:38] <srbaker> where am i supposed to report my successes?
[02:41] <_MMA_> srbaker: #ubuntu-testing can help.
[02:42] <srbaker> okay
[02:42] <srbaker> thx
[03:08] <slangasek> keescook: can I blame you for strace failing to sensibly detach anymore on ^C?
[03:11] <slangasek> ... and tricking me into breaking my own gnome-session when I was looking at bug #58171
[03:11] <ubotu> Launchpad bug 58171 in gnome-session "Connection to ICE-unix/.. socket times out so programs take minutes to start" [Medium,Confirmed] https://launchpad.net/bugs/58171
[03:18] <Erickj92> is the the appropriate channel to ask for help while programming under GNOME?
[03:19] <jcastro> Erickj92: nope, try #gnome on gimpnet
[03:20] <Erickj92> jcastro, what is the exact address?
[03:20] <Erickj92> for gimpnet?
[03:20] <jcastro> irc.gimp.org
[03:21] <Erickj92> ok, thank you
[04:44] <calc> does anyone know why totem won't play m2t files anymore?
[04:45] <pwnguin> does anyone know what an m2t file _is_?
[04:47] <calc> mpeg-ts
[04:47] <calc> mpeg transport stream
[04:47] <calc> ie what a dv/hdv camera spits out from dvgrab
[04:47] <pwnguin> Bdoh
[04:47] <calc> it used to work from what i recall, but gives me an error now
[04:47] <calc> even with the fluendo mpeg-ts plugin installed
[04:48] <RAOF> That was what I was going to ask next :)
[04:48] <calc> i'm doing a full update to see if anything helps
[04:48] <pwnguin> does vlc/mplayer handle the file?
[04:48] <calc> haven't tried yet, just tried after haven't used it in a few months
[04:49] <calc> ** Message: Error: Failed to connect stream: Invalid argument
[04:49] <calc> error isn't very useful, will try mplayer
[04:49] <calc> and note it doesn't tell me i need to install a different package to play it which totem normally does(?) if it can't play the file
[04:50] <pwnguin> you can up the debug level
[04:50] <calc> pwnguin: what argument do i use?
[04:51] <pwnguin> i forget. but the manpage knows
[04:51] <calc> i wonder if it doesn't want to play because its too high res for my screen
[04:52] <pwnguin> oh
[04:52] <pwnguin> that reminds me to file a bug
[04:52] <calc> mplayer isn't playing it either
[04:52] <calc> but it says no suitable res found
[04:52] <calc> its 1920x1080 video on a 1280x800 laptop :\
[04:52] <pwnguin> totem will make its window larger than the screen if it plays a song that has lyrics embedded in it
[04:54] <calc> is there a way to make mplayer shrink its video output to say 1/4 original size?
[04:54] <pwnguin> im sure mencoder can do it ;)
[04:54] <calc> ah scale
[04:56] <calc> hmm well i'll mess with it later seems it doesn't like my laptop much
[04:56]  * calc bbl :\
[05:12]  * lamont grumbles at doko for uploading an nmap with half a fix, and no bug in any bug-tracking system
[05:45] <keescook> slangasek: haha, no, I can't claim that one.  blame the crappy PTRACE interface in linux.  ;)
[06:01] <slangasek> keescook: has it somehow gotten crappier recently?
[06:03] <lamont> hrm.. given a bug in the debian bts, is there a trivial way to import that to launchpad?
[06:04] <Caesar> sladen: no, I mean previously the uuid-runtime package was installed by default with the alternate installer, and it appears to no longer be
[06:04]  * lamont points slangasek at the other window. :-)
[06:04] <tjaalton> Ng: it seems to work, but I haven't used it much yet
[06:07] <slangasek> lamont: the...one I replied to?
[06:07] <lamont>  /query here, and I didn't get your answer... prairie-net for the win
[06:07] <slangasek> lamont: ... right before you disconnected? :)
[06:07] <bd_> https://bugs.launchpad.net/ubuntu/+source/git-core/+bug/196846 Would it be possible to have someone with main uploader privileges look at this bug? It's an RC (high) bug for hardy, and a trivial patch is available. It would be a shame for gitk and git-gui to be broken in hardy's release, and the deadline's coming up...
[06:07] <ubotu> Launchpad bug 196846 in git-core "gitk requires wish8.5 but depends on tk8.4" [High,Confirmed]
[06:07] <lamont> did not.  my ISP did
[06:09]  * lamont plans to upload nmap_4.53-3 and request a sync for 211666
[06:22] <slangasek> Caesar: do you have an opinion on bug #90681? :)
[06:22] <ubotu> Launchpad bug 90681 in dhcp3 "resolv.conf overwritten using VPN/PPP etc..." [Medium,Confirmed] https://launchpad.net/bugs/90681
[06:24] <Caesar> slangasek: looking
[06:25] <Caesar> slangasek: while we're at it, what about #203723 ?
[06:30] <Caesar> slangasek: the problem with DHCP, is there's about three different ways that /etc/resolv.conf can be managed
[06:30] <Caesar> So just dicking with /sbin/dhclient-script addresses one vector for /etc/resolv.conf getting messed with, but not all of them
[06:31] <Caesar> and I hate the way NetworkManager (ab)uses dhclient
[06:31] <Caesar> But this is the first I'd heard of this issue (makes perfect sense though). Why hasn't it been forwarded up to Debian?
[06:59] <slangasek> Caesar: because there's not enough warm bodies to have someone watching the dhcp3 package in Ubuntu, I imagine
[06:59] <slangasek> Caesar: is resolvconf a good solution for this, generally?  It seemed to be making headway in Debian, and now it isn't
[07:01] <slangasek> Caesar: 203723> looks straightforward to fix, so it must really not be
[07:18] <pitti> Good morning
[07:23]  * slangasek waves
[07:54] <laga> slangasek: can you please merge r1287 from http://bazaar.launchpad.net/%7Emythbuntu/debian-cd/mythbuntu-debiancd/?
[08:12] <siretart> good morning!
[08:17] <dholbach> good morning
[08:24] <pitti> mjg59: hm, for bug 162654, maybe it's best to revert the network unloading for now?
[08:24] <ubotu> Launchpad bug 162654 in pm-utils "networkmanager (0.6.5-0ubuntu16.7.10.0) needs to be restarted manually after suspend using pm-utils, while functioning correctly using acpi" [Undecided,In progress] https://launchpad.net/bugs/162654
[08:26] <Silicium> heyho
[08:26] <Silicium> there are some intoduction for creating debootstrap scripts
[08:26] <Silicium> i only want wo install some packages (around 10) over debootstrap
[09:14] <warp10> Good morning
[09:15] <pitti> hi warp10
[09:15] <warp10> hey pitti!
[09:17]  * pitti looks at mvo, wondering what the libpri1.2 transitional package is all about
[09:17] <pitti> mvo: that's just a library, isn't it? why do we need a transitional library package?
[09:22] <mvo> pitti: some strangness in the asterisk package
[09:23] <pitti> mvo: but, but... any details? this looks crackful
[09:25] <mvo> pitti: I need to recreate the situation again, if you don't like I can look for a different fix. libpri1.0 claims a conflict on 1.2
[09:26] <pitti> mvo: oh, I don't want you to do pointless work, I'm just trying to understand the ratinoale for this oddity
[09:26] <pitti> oh, a conflict?
[09:26] <pitti>  Conflicts: libpri1.2 (<< 1.4.0-3)
[09:26] <pitti>  Replaces: libpri1.2 (<< 1.4.0-3)
[09:27] <pitti> mvo: weird that a transitional package changes that in any way
[09:27] <pitti> mvo: well, apt is your mystery :)
[09:27] <mvo> yeah, then the package gets removed in hardy and
[09:27] <mvo> that confuses it. the alternative is to remove the conflict
[09:28] <mvo> I guess that is cleaner especially because there isn't really a conflict AFAICS
[09:29] <pitti> mvo: unless they conflict on the soname symlink? /usr/lib/libpri.so.1
[09:29] <mvo> meh, yeah
[09:29] <mvo> I knew there was a reason
[09:29] <pitti> mvo: the package name is wrong then, it should just be libpri1
[09:30] <pitti> which Conflicts/Replaces/Provides libpri1.2 perhaps?
[09:30] <pitti> if it didn't change ABI
[09:30] <pitti> and if it did, then the SONAME is still wrong
[09:30] <pitti> mvo: so, please don't get me wrong, not trying to cause trouble, but it doesn't feel like this would even be a working hack...
[09:31] <pitti> since we have no guarantee that the transitional package is installed first
[09:31] <pitti> oh, wait, that's what the conflicts is doing, nevermind
[09:31] <mvo> the transitional package does work, I tested it in a dapper chroot, makes both aptitude and apt happy.
[09:32] <cjwatson> Caesar: uuid-runtime seems to be optional (both according to the changelog, and according to Debian priorities); I made casper depend on it, but I wonder if we need to install it by default
[09:32] <cjwatson> of course it's arguably inconvenient to deal with UUIDs without it ...
[09:33] <pitti> mvo: ah, ok; well, *shrug*, I'll accept it, but the broken SONAME will likely cause more trouble in the future
[09:34] <mvo> pitti: right, I don't think there is a debian bugreport about this yet, I will create one
[09:34] <pitti> mvo: that'll do, thank you! (please make it serious, it's a gross violation of library policy)
[09:45] <mjg59> pitti: I'm looking at it
[09:46] <pitti> mjg59: good morning! thanks
[09:46] <pitti> mjg59: btw, which TZ are you in ATM?
[09:46] <mjg59> London
[09:47] <pitti> aah; I was afraid it was Boston and you're up that long :)
[09:50] <pitti> Riddell: *chuckle* removal of adept from Debian: "ROM, broken beyond repair" -- that's certainly a different adept then?
[09:52] <pitti> doko: gcc-4.0 was recently removed from Debian; no rdepends in hardy AFAICS; I assume I can remove it from Hardy as well?
[09:53] <doko> pitti: no, we still build gcc-3.4 on hppa
[09:53] <pitti> doko: and that needs gcc-4.0?
[09:53] <doko> libgcc2 is built from gcc-4.0
[09:53] <pitti> oh, I should reenable ports in checkrdepends
[09:54] <doko> hppa is too much broken for this
[09:55] <pitti> ok, then I leave it for now *shrug*
[10:01] <\sh> damn....what do I need to do to enable pulseaudio again? seems like it's not started anymore since one or two last updates
[10:02] <\sh> starting manually fixed it ;)
[10:04] <pitti> \sh: system -> settings -> audio -> software mixing?
[10:05] <\sh> pitti, when I would find it, hopefully ;)
[10:06] <\sh> I have system -> preferences -> default soundcard (which is set to PA) and system -> preferences -> sound (all needed output/input stuff is set to PA too).
[10:06] <\sh> but session manager doesn't start PA automatically anymore
[10:07] <pitti> \sh: do you have system -> settings -> audio -> "Klaenge" -> "Mix sounds with esd"? that triggers pulse
[10:07] <\sh> ah...there
[10:07] <\sh> that was disabled
[10:08] <\sh> so you need to enable "ESD" to start pulse automatically?
[10:08] <pitti> geser, doko: hm, atlas3 was removed from debian with "RoQA; NVIU; RC-buggy; obsolete g77 package", but we still have a lot of rdepends; is our transition not complete yet? is that something to be concerned with?
[10:09] <doko> pitti: no, we need to keep the g77 based packages, IMO
[10:10] <pitti> ok
[10:18] <Riddell> pitti: hrm, where do you see that?
[10:18] <pitti> Riddell: in process-removals
[10:27] <pitti> asac: can you please have a look at the firefoxish bits of "binary-only demotions" on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt and tell me what I should demote, and what should be seeded?
[10:28] <asac> pitti: looking
[10:29] <seb128> pitti: bug #211569 is something you might want to look at
[10:29] <ubotu> Launchpad bug 211569 in xsane "xsane won't start unless run as root (Epson Perfection 1240)" [Medium,Confirmed] https://launchpad.net/bugs/211569
[10:29] <pitti> seb128: libglib2.0-data certianly needs to become a Depends: of something?
[10:29] <asac> pitti:  i don't understand taht page
[10:29] <asac> what does "Binary only demotions to universe
[10:29] <seb128> pitti: why?
[10:29] <asac> " mean?
[10:29] <pitti> asac: those are the binary packages which are not dependencies of any main package
[10:29] <asac> firefox-themes-ubuntu -> universe
[10:29] <seb128> pitti: it has only translations and we stip those
[10:29] <pitti> asac: they either need to be seeded to stay in main, or become a dependency of a main package, or dropped to universe
[10:29] <seb128> pitti: s/stip/strip rather ;-)
[10:30] <pitti> seb128: ah, ok; so I can demote it then?
[10:30] <seb128> pitti: yes
[10:30] <pitti> seb128: thanks
[10:30] <asac> pitti: everything that is firefox-3.0* is main
[10:30] <seb128> pitti: hum, wait
[10:30] <seb128> pitti: ok, that's alright
[10:30] <asac> same for everything just firefox* .... firefox-granparadiso and firefox-trunk bits are transitional packages (they could stay in universe, but are from the same source as the firefox-3.0 bits)
[10:30] <seb128> pitti: I was just checking that it doesn't contain the copyright, etc for the other binaries too
[10:31] <cjwatson> could somebody with a thinkpad fingerprint reader look at bug 208668, please?
[10:31] <ubotu> Launchpad bug 208668 in thinkfinger "sshd core dumps while trying to connect with a password" [Undecided,Incomplete] https://launchpad.net/bugs/208668
[10:31] <pitti> asac: cdbs shouldn't do that if there is no depends:, thanks for checking
[10:31] <seb128> pitti: that was for me I think ;-)
[10:31] <pitti> right, sorry
[10:31] <seb128> you are welcome ;-)
[10:31] <asac> pitti: huh?
[10:31] <pitti> asac: so they need to get seeded then?
[10:32] <asac> seeding like on CD?
[10:32] <pitti> cjwatson: I only have a Dell fp reader, but it also uses thinkfinger; I can try it a bit later
[10:32] <Silicium> cjwatson: iam
[10:32] <pitti> asac: just to supported, I guess
[10:32] <Silicium> cjwatson: i have the T32
[10:33] <Silicium> T43
[10:33] <asac> pitti: ah. right. i can do that. can we keep parts in universe?
[10:33] <pitti> asac: so those are transitional packages for universe and thus should go to universe? firefox-granparadiso firefox-granparadiso-dom-inspector firefox-granparadiso-gnome-support firefox-trunk firefox-trunk-dom-inspector firefox-trunk-gnome-support firefox-trunk-venkman
[10:33] <asac> i'd like to keep -dom-inspector and -venkman in "unsupported"
[10:34] <seb128> cjwatson: just curious but do you know if there is an known issue about scp upload speed being on crack? it tends to go to 100% really quickly when I scp to rookery for example and display a speed which is much faster than my dsl line and then stay stucked for a while which is likely the real upload still running
[10:34] <pitti> asac: yes, we can have only some in main
[10:34] <asac> pitti: yes right.
[10:34] <pitti> asac: hm, that basically means that all of the listed ones can go to universe?
[10:34] <asac> pitti: ok, we can basically push everything to universe
[10:35] <asac> that is in that list
[10:35] <asac> yes
[10:35] <pitti> cool, thanks
[10:35] <asac> the ones that are not transitional are venkman and -dom-inspector
[10:35] <asac> and they are not supported
[10:35] <asac> pitti: so nothing to do from my side?
[10:35] <pitti> asac: no, I just wanted to ask you which we want to support
[10:35] <asac> ok thanks
[10:36] <seb128> pitti: btw did you read the xsane bug number I gave you in the same time you asked about the glib data demotion?
[10:37] <pitti> seb128: yes, I'll look at it
[10:37] <seb128> pitti: ok, cool
[10:37] <asac> vim is not supported?
[10:37] <asac> hmm
[10:39] <ogra_cmpc> pitti, could jockey not display a descriptive message if linux-image and l-r-m are out of sync (running a test of which versionns are available before it even fires up the package installer which will then fail with error)
[10:39] <asac> pitti: i see that libmozjs-dev libxul-dev xulrunner are bin only promotions to main ... can we hold that back?
[10:40] <asac> pitti: we have to kick moblin folks to migrate mobile-basic-flash to xul 1.9
[10:40] <cjwatson> seb128: not afaik
[10:40] <cjwatson> seb128: or rather if it is it was too confused to be actionable
[10:41] <seb128> cjwatson: ok, what informations would be useful in case I would like to open a bug about the issue?
[10:42] <seb128> cjwatson: that's only a detail and I'll try to see when it does it, etc
[10:42] <asac> pitti: ill talk to bob
[10:43] <pitti> asac: no, those are source/binary promotion, and I don't want to promote xulrunner
[10:43] <asac> pitti: ok. good. just don't promote the xulrunner binary ;)
[10:43] <cjwatson> seb128: scp -vvv output, ideally with some indication of anywhere it hangs for a long period
[10:44] <seb128> ok
[10:44] <seb128> the estimation seems to be wrong for small files, I need try again to make sure
[10:45] <pitti> seb128: I triaged that bug
[10:45] <mjg59> pitti: Re: 162654 - I'm somewhat confused about what the problem is here. Is it just that we're not bringing interfaces back up on resume?
[10:45] <asac> bug 162654
[10:45] <ubotu> Launchpad bug 162654 in pm-utils "networkmanager (0.6.5-0ubuntu16.7.10.0) needs to be restarted manually after suspend using pm-utils, while functioning correctly using acpi" [Undecided,In progress] https://launchpad.net/bugs/162654
[10:45] <seb128> pitti: cool
[10:45] <pitti> mjg59: yes; rmmod'ing them tears down the ifaces, and thus you need a /etc/init.d/networking restart to ifup all of them again
[10:45] <mjg59> pitti: If so, I think we probably just want the logic from acpi-support
[10:46] <pitti> asac: promote xulrunner binary> over my dead, cold body :) (lib duplication)
[10:46]  * asac hugs pitti 
[10:46] <mjg59> pitti: Since the init script has various side effects (like refusing to deconfigure interfaces if you have network mounts)
[10:46] <mjg59> pitti: Oh, wait. Actually, the restart call looks ok. Ish.
[10:47] <pitti> ogra_cmpc: I'm not sure I understand; can you please file a bug with the details?
[10:47] <pitti> mjg59: makes me a little nervous, but if we rmood modules, then it's at least better than doing nothing, yes
[10:47] <pitti> mjg59: another question is whether we need to rmmod all of them in the first place?
[10:48] <mjg59> pitti: I'd rather go with what we have in acpi-support, since it pays attention to which interfaces are currently up
[10:48] <mjg59> pitti: No, we don't need to rmmod all of them. But it's easier than trying to work out which ones we /can/ rmmod.
[10:48] <pitti> we only got reports about ipw3945, which isn't an issue any more (iwl3945), and for e1000
[10:48] <mjg59> I suspect there are more
[10:50] <pitti> tjaalton, bryce: we need to keep xserver-xorg-driver-all in main for dapper upgrades, right?
[10:51] <tjaalton> pitti: not only that, but there's no way of knowing what driver the user needs
[10:51] <tjaalton> oh
[10:51] <tjaalton> -driver-all
[10:51] <pitti> tjaalton: *driver* vs. *video*
[10:51] <Ng> mjg59: after hitting the networking restart thing in the last few days I'm wondering if it might be better to expose the driver bugs than mess with peoples' networking setups by ripping out all the modules. i don't know how far it spreads beyond my e1000 though
[10:51] <tjaalton> pitti: yes, that's for upgrades I think, mvo added it :)
[10:51] <pitti> tjaalton: so I'll seed it for hardy as a transitional package
[10:51] <mjg59> Ng: It's what we did in previous releases
[10:55] <Ng> mjg59: indeed and that was why I thought it would be ok to suggest it
[10:55] <pitti> seb128: gvfs-bin > universe, supported, or desktop?
[10:56] <Ng> aha, so acpi-support does ifdown/ifup the interfaces as well as just ripping out the modules
[10:57] <seb128> pitti: what do you think? supported or desktop I would say, those can be handy but are not really things desktop users will run
[10:58] <ogra_cmpc> pitti, Bug #211733
[10:58] <ubotu> Launchpad bug 211733 in jockey "jockey should know about restricted drivers being out of sync during linux rebuilds" [Wishlist,New] https://launchpad.net/bugs/211733
[10:59] <pitti> mvo: oh, thanks for fixing aptitude/cwidget
[11:00] <pitti> seb128: My gut feeling is supported
[11:00] <pitti> ogra_cmpc: thanks
[11:01] <pitti> cjwatson: hm; which seed would you recommend to add "xserver-xorg-driver-all" transitional package to?
[11:01] <seb128> pitti: agreed
[11:03] <pitti> seb128: hm, and libbonobo2-bin?
[11:03] <pitti> not really needed any more AFAICS?
[11:04] <seb128> pitti: it's still used, but those tools are not really required, you can demote to universe
[11:05] <pitti> ArneGoetje, Riddell: do we need scim-bridge-client-qt4 for anything, or shall I demote it to universe?
[11:08] <pitti> cjwatson: also, I don't see a proper place to seed 'vim'; what would you recommend?
[11:08] <pitti> cjwatson: (it sounds like it should be in some platform supported-*, too)
[11:09] <mvo> pitti: cheers
[11:10] <mvo> pitti: drivers vs video - it should be enough to have -drivers-all in the archive, we shouldn't need it in the seeds
[11:10] <pitti> mvo: but for upgrades from dapper it should be in main?
[11:10] <pitti> mvo: or can we always count on having universe enabled on dapper upgrades?
[11:10] <mvo> pitti: oh, yes!
[11:11] <mvo> pitti: in main please (sorry, I misread the earlier bits then)
[11:11] <pitti> right, what I thought; thanks
[11:30] <pecisk> Can someone explain why https://bugs.launchpad.net/ubuntu/+source/gnome-system-tools/+bug/185854 bug has "Declined  for Hardy  by Pedro Villavicencio" text attached to it and what does it mean?
[11:30] <ubotu> Launchpad bug 185854 in gnome-system-tools "Setting static IP in Network Settings doesn't produce correct data" [High,Confirmed]
[11:31] <mrben> hello - quick question
[11:31] <mrben> ok - in a package listing in ubuntu, what does the number before the colon mean?
[11:31] <mrben> eg Package: ardour (1:2.0.5-1ubuntu1) [universe]
[11:31] <mrben> http://packages.ubuntu.com/gutsy/ardour
[11:32] <laga> mrben: i think that's called "epoch". try #ubuntu-motu for packaging related questions
[11:32] <mrben> ok - thanks laga
[11:33] <james_w> mrben: yeah, it's an epoch, sometimes they are needed for some reason, usually someones mistake with version numbers
[11:33] <mrben> ahh
[11:33] <pecisk> anyone? :(
[11:34] <james_w> pecisk: it means that someone proposed it for Hardy, meaning that it would be put in a pool of bugs that would be considered as being high importance to fix before Hardy is released
[11:34] <mrben> thanks for the info
[11:34] <james_w> the fact that it was declined means that it wasn't considered important enough for this status.
[11:34] <pecisk> well
[11:34] <pecisk> that person have made wrong decision then
[11:35] <pecisk> because it is actually a blocker
[11:35] <laga> pecisk: i believe we're seeing similar issues in mythbuntu, but i have yet to confirm that.
[11:36] <james_w> pecisk: well a blocker normally goes a different route, but proposing for hardy would be a good start.
[11:36] <mantiena-baltix> doko: maybe you know if I should set BUILD_JARS_NATIVE=n in OOo2.4 Gutsy backport ?
[11:36] <mantiena-baltix> doko: in gutsy's (OOo 2.3) debian/rules file BUILD_JARS_NATIVE was set to 'n', while in OOo 2.4 from Hardy it's set to 'y'
[11:36] <mantiena-baltix> infinity: hi
[11:37] <doko> mantiena-baltix: does it fail to build while building the native jars?
[11:38] <amitk> ogra_cmpc: does the zsync update work for you? http://pastebin.ubuntu.com/6459/
[11:39] <ogra_cmpc> amitk, riched uses it extensively and i know highvoltage has used it
[11:39] <pecisk> james_w: simply I expierenced this bug on newest live cds, on up-to-date laptops, workstations. It is annoying and Hardy definitely can't be shipped with it.
[11:40] <james_w> pecisk: I'm sure it exists, whether hardy can be shipped with the bug is more subjective.
[11:40] <ogra_cmpc> amitk, s/-i/-o/
[11:40] <james_w> pecisk: I'm pretty sure a patch to fix it would be accepted.
[11:41] <james_w> pecisk: you would need to work out why set_auto on the interface doesn't make oobs write out the "auto" line.
[11:41] <ogra_cmpc> amitk, or even omit the option and mv hardy-classmate-20080326.img hardy-classmate-20080401.img ... before you start
[11:41] <ogra_cmpc> -i means definately "input file", you want to output to it :)
[11:42] <pecisk> james_w: subjective? with manual IP address configuring don't working from gui? :) ok, sure, I will check it
[11:44] <thom> pitti: thanks for the puppet sync dude :)
[11:44] <pitti> thom: you're welcome
[11:45] <james_w> pecisk: on_iface_toggled in src/network/callbacks.c is probably a good place to start looking.
[11:45] <pecisk> thanks :)
[11:47] <laga> pecisk: it'd be great if you got a patch :)
[11:47] <pecisk> I will try
[11:47] <pecisk> I do it only second time :)
[11:54] <james_w> Is anyone able to answer my question at the end of https://bugs.edge.launchpad.net/ubuntu/+source/python-central/+bug/205470?
[11:54] <ubotu> Launchpad bug 205470 in python-central "python-central crash on upgrade (was: python2.4-minimal could not be uninstalled)" [High,New]
[11:54] <james_w> "if you are removing a package is there a window in which the files are removed (in particular /var/lib/dpkg/package.list), but the package is still listed in /var/lib/dpkg/status?"
[11:55] <james_w> and by listed I mean listed there with a Version: and Depends:? Not in "purge ok not-installed" state.
[11:56] <amitk> ogra_cmpc: I tried all sorts of cmdline options starting from the one you recommend: http://pastebin.ubuntu.com/6460/
[11:58] <ogra_cmpc> hum
[11:58] <ogra_cmpc> i'll test, one secd
[12:05] <ogra_cmpc> amitk, http://paste.ubuntu.com/6461/
[12:05] <ogra_cmpc> works fine here
[12:06] <ogra_cmpc> (command cop/pasted fromm your pastebin)
[12:06] <ogra_cmpc> 63min ETA
[12:08] <ogra_cmpc> amitk, hardy-classmate-20080326.img is lying in $(pwd) ?
[12:08] <ogra_cmpc> seems it complains about the output file missing
[12:09] <Riddell> pitti: scim-bridge-client-qt4 is used by kubuntu-kde4-desktop, but I suppose it's probably also needed by qt 4 apps in main, ArneGoetje?
[12:15] <amitk> ogra_cmpc: yes, file is in cwd.
[12:17] <ogra_cmpc> thats very weird
[12:17] <Ng> asac: did we remove firefox's Ctrl-Q quit shortcut, or did they?
[12:18] <amitk> ogra_cmpc: nevermind. It will be faster for me to download the whole image  :)
[12:18] <ogra_cmpc> amitk, all i can tell is that it works fine on two different machines i tried with exactly the command you gave
[12:18] <asac> Ng: can't copy that ;) ... i still have ctrl+q
[12:19] <Ng> asac: lemmie check with a fresh profile, the one I tested it in is a few weeks old
[12:48] <Riddell> infinity, slangasek: livefs builds stuck again
[12:50] <ogra_cmpc> woah, rsync got noisy
[12:51] <ogra_cmpc> (on cdimage)
[13:05] <fta> bryce, do we have a fix for bug 198759 / bug 208224 ? it's annoying on laptops..
[13:05] <ubotu> Launchpad bug 198759 in xkeyboard-config "Right CTRL don't work" [Medium,Confirmed] https://launchpad.net/bugs/198759
[13:05] <ubotu> Launchpad bug 208224 in xorg-server "[hardy] right ctrl key does nothing (french layout) (dup-of: 198759)" [Undecided,New] https://launchpad.net/bugs/208224
[13:06] <cjwatson> fta: it seems to be a deliberate choice in the keymap, unfortunately
[13:07] <cjwatson> which has held me back from just undoing it
[13:07] <cjwatson> the right control key is deliberately mapped to a level-5 shift
[13:08] <fta> hm, but at least on a french keyboard, everyone expect the control key to act as control, not produce garbage
[13:09] <cjwatson> well, that's the thing, this keymap was produced by somebody French
[13:09] <cjwatson> so there is clearly disagreement among French users, which makes it difficult for relative outsiders to figure out what's going on ...
[13:10] <cjwatson> I think I might send mail to the keymap author and ask for clarification
[13:12] <fta> would be nice
[13:13] <cjwatson> fta: ok, I'll do that
[13:14] <fta> strange thing is that it works as expected on all my desktops, but no on laptops
[13:14] <pez2001_> can someone give me some tips on how i can have just one place in my src where i have to change the version number (im building rpms and debs too)  ...
[13:14] <pez2001_> im using kdevelop
[13:14] <cjwatson> fta: that would be odd, unless you're using a different keymap on the desktops
[13:14] <cjwatson> fta: it's not particularly hardware-specific
[13:15] <fta> i've tried both french, and french alternative on my laptop, none works as my desktops
[13:15] <seb128> fta: do you use the same keymap? the default choice changed in gutsy or hardy
[13:16] <cjwatson> it was earlier than that
[13:16] <cjwatson> check /etc/X11/xorg.conf, anyway
[13:16] <cjwatson> console-setup (1.13ubuntu7) feisty; urgency=low
[13:16] <cjwatson>   * Set default variant for French to oss (LP: #89835).
[13:18] <pitti> mvo: regarding the update-manager sitting in -proposed: is there any progress in verifying bug 172609? if I accept that, we'll stack more and more changes which never go into -updates...
[13:18] <ubotu> Launchpad bug 172609 in update-manager "mishandles prerequists-sources.list on ports architectures" [High,Fix committed] https://launchpad.net/bugs/172609
[13:23] <soren> lool: I didn't merge it. I just renamed the refacotored branch to trunk.
[13:23] <pitti> pedro_: do you happen to plan on working on SRU verifications in the next time? there is still quite a bunch of old SRUs
[13:24] <fta2> ISO_Level5_Shift (laptop)
[13:24] <slytherin> hi all, I am trying to analyze OOo build failure on powerpc but not getting much info. Is it anyway related to java?
[13:25] <fta> Control_R (desktop), same keymap.
[13:26] <pedro_> pitti: yes, let me see what i can do
[13:26] <pedro_> pitti: btw the gutsy tomboy links to GNOME reports instead
[13:27] <cjwatson> fta: interesting, but I'm not sure we need to investigate it
[13:27] <cjwatson> fta: it might for example be that on some of your systems you have selected a different keymap in GNOME that's overriding the default in xorg.conf
[13:28] <fta> hm, ok, i'll check that.
[13:28] <cjwatson> fta: in any case, this kind of investigation is the sort of thing that's needed when we aren't quite sure what's causing the bug, but in this case I can point to the line of code involved. :-)
[13:29] <pitti> soren, zul: can you please seed likewise-open anywhere or make it a dependency? ATM it wants to go back to universe; TIA!
[13:30]  * soren is (trying to be) on holiday today
[13:30] <cjwatson> pitti: xserver-xorg-driver-all should go in ship, I think, so that it's available for CD upgrades
[13:31] <cjwatson> pitti: perhaps vim should go in the dvd seed
[13:32] <cjwatson> (we don't have a platform version of that, really)
[13:32] <cjwatson> oh, we do, dvd inherits supported-common
[13:32] <cjwatson> pitti: perhaps platform.hardy/supported-development
[13:33] <cjwatson> and maybe move emacs, emacs22-el, emacs-nox from ubuntu.hardy/dvd to there as well
[13:33] <cjwatson> oh, and emacs-goodies-el
[13:34] <zul> pitti: on it
[13:35] <Ng> cjwatson: did someone reply about the thinkfinger bug? I just installed it and openssh-server, added it to pam and I can still ssh to localhost without anything dying
[13:35] <Ng> I didn't reboot, so I guess many pam services aren't using thinkfinger, but since sshd wasn't installed previously, it ought to have
[13:37] <zul> pitti: done
[13:38] <Ng> I wish the fingerprint stuff was remotely safe, but I'm going to uninstall it again ;)
[13:38] <jdong> aren't fingerprints some of the silliest things to authenticate by?
[13:39] <ogra_cmpc> yeah, easy to fake
[13:39] <jdong> next we'll be authenticating by hair and dead skin cells
[13:39] <StevenK> What would you rather, retina scan?
[13:39] <laga> StevenK: passwords.
[13:39] <soren> blood sample
[13:39] <jdong> StevenK: at least you don't leave retina prints lying around everywhere
[13:39] <jdong> :)
[13:39] <laga> soren: check_is_it_red() [boolean]
[13:40] <soren> :)
[13:40] <laga> ;)
[13:40] <jdong> lol
[13:41] <ogra_cmpc> the chaos computer club germany recently published a finger cover to pull over your indexfinger with the print of our interior minister
[13:41] <ogra_cmpc> (as gadget with their newspaper)
[13:41] <laga> .. which is amusing as hell :)
[13:41] <ogra_cmpc> yeah
[13:41] <cjwatson> Ng: I don't think anyone else replied, no; but a followup to the bug would be better :)
[13:42] <cjwatson> Ng: oh, hmm
[13:42] <cjwatson> Ng: did you edit /etc/pam.d/<anything> to actually use pam_thinkfinger?
[13:42] <cjwatson> oh, you said you did
[13:42] <cjwatson> common-auth?
[13:42] <cjwatson> IMO fingerprint authentication should be in conjunction with a password, not a replacement for it
[13:43] <Ng> cjwatson: yep, I have it set up enough that sudo will work with password or fingerswipe
[13:44] <Ng> I'll add a comment to the bug
[13:44] <Mithrandir> I think I'm going to write a pam module that will allow fingerprint auth if short enough time has passed since the system was active.
[13:44] <Mithrandir> so you can unlock the screensaver if you just left the office for 15 minutes, but not if you left it overnight.
[13:45] <cjwatson> add it as an option to pam_thinkfinger?
[13:45] <laga> so the guy who cut off my finger will have to hurry up. cool
[13:45] <cjwatson> rather than a new module
[13:47] <pwnguin> hey
[13:47] <Mithrandir> cjwatson: yeah, guess so.
[13:47] <mjg59> Would probably be preferable to add it to fprint
[13:47] <Mithrandir> laga: indeed.
[13:47] <mjg59> I don't see thinkfinger being the way forward
[13:47] <pwnguin> interesting subject
[13:48] <pwnguin> cjwatson: that bug report's for gutsy -- ubuntu doesn't ship thinkfinger in main or universe in gutsy =/
[13:49] <pwnguin> mjg59: i dont see how anyone could conclude that thinkfinger is moving forward
[13:50] <Hobbsee> pwnguin: jldugger is the likely culprit
[13:50] <pwnguin> heh
[13:50] <pwnguin> that bastard!
[13:51] <Hobbsee> bah.  curses.
[13:51] <Hobbsee> pwnguin: so, why are you packaging crack?  :)
[13:51] <pwnguin> its not crack
[13:51] <pwnguin> its just dying
[13:51] <Hobbsee> anything in ppa is crack.
[13:51] <pwnguin> fine
[13:52] <Hobbsee> :P
[13:52] <pwnguin> why is the hardy thinkfinger package also crack?
[13:52] <jdong> what is the case with apparmor and overlay filesystems?
[13:52] <jdong> is it  still a case of it doesn't work?
[13:52] <laga> aufs seems to work? unless something automagically disables apparmor on my boxes :)
[13:52] <pitti> zul: cheers
[13:53] <zul> pitti: np
[13:53] <pwnguin> Hobbsee: i guess i love crack. i do hits of nouveau and gnome-do at least weekly
[13:53] <pitti> pedro_: I know; it was a gnome microversion update
[13:54] <Fujitsu> nouveau is good crack, at least.
[13:54] <pwnguin> Hobbsee: honestly, i was going to just let it linger some more and examine fprint, but it seems Dell forced the issue a bit ;)
[13:54] <jdong> laga: I have aufs unioning /root-ro with /tmpfs, and apparmor freaks out with things like access to /root/etc/foo/bar failing
[13:54] <Hobbsee> pwnguin: ahhh :)
[13:54] <pitti> cjwatson: hm, editors in 'development'? Well, it doesn't matter too much..; thanks for your input
[13:54] <Hobbsee> pwnguin: yay, gnome-do!
[13:54] <pwnguin> Hobbsee: plus, how on earth do you authenticate via fingerprint via ssh?
[13:54] <pwnguin> its a pam problem :P
[13:54] <laga> jdong: currently, /etc/init.d/apparmor isn't started on my boxes, but i wonder if it's needed?
[13:54] <Hobbsee> pwnguin: enofingerprintreader
[13:55] <Hobbsee> pwnguin: aka "magic"
[13:55] <jdong> laga: that would be what activates apparmor, yes :D
[13:56] <laga> jdong: i definitely should do some regression testing before pushing the change that enables apparmor then..
[13:56] <jdong> laga: yeah....
[13:57] <laga> jdong: let me find an ethernet cable and i'll see if it works for me.
[13:57] <cjwatson> pwnguin: heh, granted
[13:57] <cjwatson> anyway, not openssh's problem AFAICS ;-)
[13:58] <cjwatson> pitti: seems to be the closest that's there at the moment, and after all vim does have a disproportionate number of developer users
[14:07] <pitti> cjwatson: emacs moved, vim added; I put them into a new section "Advanced editors" now
[14:08] <cjwatson> thanks
[14:08] <pitti> cjwatson: we don't have a platform/ship AFAICS?
[14:09] <slytherin> hi all, I am trying to fix OOo build on powerpc. I have found 2 things unusual. Please let me know if I am going in right direction 1. ENABLE_JAVA is set 'n' on powerpc. 2. Line number 3681170 in uncompresed .diff.gz looks like some condition is missing. But I am not sure why this doesn't cause problem on other arch.
[14:10] <mdomsch> uh, yeah, we kind of need thinkfinger, and soon...
[14:10] <mdomsch> if thinkfinger gets replaced with something better, no worries
[14:11] <pwnguin> thinkfinger mostly works in hardy
[14:11] <laga> mdomsch: why do you need thinkfinger?
[14:11] <mdomsch> laga, a goodly number of our Ubuntu-preloaded laptops have fingerprint readers
[14:11] <laga> ah..
[14:11]  * mdomsch works @Dell
[14:12] <pwnguin> mdomsch: so should it be configured as a two factor hassle?
[14:12]  * laga refrains from going on a anti-fingerprint reader campaign just because he didn't get enough sleep ;)
[14:12] <mdomsch> pwnguin, I leave that up to the engineering team
[14:12] <mdomsch> whether it's single-factor or 2-factor
[14:13] <pitti> zul: bacula-director-sqlite bacula-director-sqlite3 bacula-sd-pgsql bacula-sd-sqlite bacula-sd-sqlite3 -- which of those should stay in main (need seeding) and which are ok to move to universe?
[14:13] <mdomsch> in the end, that winds up as a user policy decision
[14:13] <pwnguin> laga: honestly, if they can recover your fingerprints, they can probably do something worse than fake your prints
[14:13] <zul> pgsql should be in main the rest should be in universe
[14:13] <zul> pitti: ^^^
[14:13] <pwnguin> mdomsch: somehow, i just dont see users clamoring for two factor ;)
[14:14] <pitti> zul: can you please seed psql? I'll move the rest; thanks!
[14:17] <zul> pitti: done
[14:17] <pitti> zul: cheers
[14:17] <laga> jdong: oh, apparmor isn't installed for my diskless clients.
[14:19] <slytherin> can anyone please comment on my observation about OOo build? Or at least provide me further pointers
[14:21] <lool> soren: Ok, thanks
[14:22] <pitti> slytherin: --verbose?
[14:23] <slytherin> pitti: I didn't understand
[14:23] <pitti> slytherin: what's wrong with the OOo build?
[14:24] <seb128> pitti: right some lines ago?
[14:24] <seb128> s/right/read
[14:24] <seb128> pitti: 15:18
[14:24] <pitti> ah, there
[14:24] <slytherin> pitti: It fails on powerpc only. And it has been failing throught hardy cycle
[14:25] <pitti> hm, disabling java on ppc might be deliberate
[14:25] <pitti> it might not work there; but I'm just guessing
[14:28] <slytherin> pitti: Please read my 2nd point too and let me know what you think
[14:28] <cjwatson> pitti: not at the moment
[14:32] <slytherin> pitti: I was not able to make much out of the build log. I will try to analyze it again tonight.
[14:33] <laga> jdong: ok, i installed apparmor and dmesg shows that i get access denied when accessing /rofs/something or /cow/foo. guess i should make sure it stays disabled.. ping me if you need something, i've gotta run now
[14:34] <slytherin> cjwatson: It was disabled long time back. Not sure if anyone tried enabling it again recently. Surprisingly Debian has packages for powerpc.
[14:34] <pedro_> pitti: is the retracer working?
[14:35] <jdong> laga: yes, that's consistent with my findings too
[14:37] <pitti> pedro_: argh, ssh broken ATM again; I'll have a look a bit later
[14:37] <pedro_> pitti: ok, thanks you
[14:37] <emgent> uhm
[14:38] <emgent> pitti: regression ?
[14:38] <cjwatson> slytherin: did you mean me?
[14:38] <pitti> emgent: yes, at the side of my ISP
[14:38] <cjwatson> slytherin: oh, I was replying to something else pitti said, nothing to do with ooo
[14:38] <\sh> pitti, do we still have sync references of packages since hoary somewhere? :)
[14:38] <slytherin> cjwatson: oh, sorry
[14:39] <\sh> pitti, especially for subversion-helper-scripts ;) it's not clear where it came from...and why we don't find any reference for it in debian
[14:40] <pitti> \sh: I don't know more than https://edge.launchpad.net/ubuntu/+source/subversion-helper-scripts either, sorry :/
[14:41] <\sh> pitti, it doesn't give us a clue about the source...but I think I found it already :)
[14:41] <\sh> http://www1.apt-get.org/search.php?query=subversion-helper-scripts&submit=Submit+Query&arch[]=i386&arch[]=all
[14:41] <pitti> ah, apt-get.org import
[14:41]  * pitti hugs dholbach
[14:43] <\sh> pitti, that reminds me, it would be good to have those references on LP...sync-source: -> this site ;)
[14:47] <Mirv> bryce: any news about the screen resolution tool, a new version? I'm mainly interested so that the i18n fixes would go in in time, but you're probably also doing other aspects before a new gnome-control-center upload?
[14:47] <seb128> Ng: around?
[14:47] <Ape> Hi
[14:47] <Ape> I'm a coder and I'd like to be part of a open source project
[14:48] <laga> jdong: apparmor is not too useful for my use case so i can live without it, luckily
[14:48] <Ape> How can I start?
[14:48] <Ng> seb128: yep
[14:49] <seb128> Ng: the issue was not the gtk one I pointed yesterday, seems to be rather a cairo on
[14:50] <Ng> seb128: aha, i saw some launchpad bug mail about something being re-classified as a cairo bug
[14:50] <laga> Ape: well, one case would be looking for a blue print in launchpad and work on something that's interesting for you (contact the people listed in the blueprint beforehand)
[14:53] <metellius> i want to code a patch for libqt-gui packages, but the whole dpkg-buildpackage process is insanely slow for actually getting some iterative code/compile/test programming going... is there actually a better way for this that people have thought of?
[14:53] <laga> metellius: i sometimes use dpkg-buildpackage -nc
[14:53] <laga> -nc means "don't clean up, start where it left off"
[14:53] <laga> maybe that can do the trick for you
[14:55] <metellius> doing a testcompile now to see if -nc makes a difference...
[14:55] <Lamego> or you could work on a normal source dir, and create the patch/package later
[14:56] <metellius> Lamego: I did think of that as an alternative too, but I was kind of hoping this was such a common problem there would be a less manual solution available
[14:57] <pitti> pedro_: indeed, I restarted it; thanks
[14:58] <pedro_> pitti: great, thanks :-)
[14:58] <cjwatson> metellius: look through debian/rules build, find what it does (which is typically just 'make'), run that
[14:58] <cjwatson> usually if you're planning to be spending enough time working on a package to need iterative code-compile-test, this is not a problem
[15:05] <Mirv> pitti: hi. bug 199255 is assigned to you. do you need help with it? it seems trivial, translation domain not set somewhere so programs tries to read messages.mo instead of correct file. identical problem preventing translations from showing is bug 204155.
[15:05] <ubotu> Launchpad bug 199255 in policykit-gnome ""Authorizations" shows untranslated, but it's translated in Launchpad" [Undecided,In progress] https://launchpad.net/bugs/199255
[15:05] <ubotu> Launchpad bug 204155 in network-manager-applet "Nm-editor translations not loaded" [Undecided,Confirmed] https://launchpad.net/bugs/204155
[15:06] <pitti> Mirv: I didn't find time to fix it yet; if you want to have a go at it, I'd appreciate :)
[15:07] <seb128> pitti: opinion on https://bugs.edge.launchpad.net/ubuntu/+source/pixman/+bug/211785?
[15:07] <ubotu> Launchpad bug 211785 in pixman "Please sponsor pixman 0.10.0-0ubuntu1" [Undecided,New]
[15:09] <seb128> pitti: I think upstream can be trusted, they do and careful work usually
[15:09] <seb128> pitti: pixman should only be directly using by cairo and xorg
[15:09] <seb128> pitti: and the new version is required to update cairo (we have 1.5.14 which is an unstable version and target 1.6 for hardy)
[15:10] <pitti> seb128: ugh, quite a lot of changes
[15:10] <ion_> Btw, couldn't Ubuntu use pdiffs for apt-get update while we're waiting for the final solution, since it's already implemented?
[15:11] <pitti> seb128: well, seems there isn't much room for saying 'no' anyway? :)
[15:13] <seb128> pitti: not really no ;-) But I'm asking to be polite ;-)
[15:13] <tjaalton> seb128: it was uploaded in debian recently
[15:13] <seb128> tjaalton: ok
[15:13] <tjaalton> so a sync should be possible soon
[15:20] <ion_> mvo: Any news about apt-sync, btw? :-)
[15:22] <tjaalton> seb128: are you syncing packages? could you sync tightvnc which is currently uninstallable because there's no vnc-common anymore
[15:22] <tjaalton> we have -21, -22 removed the dependancy
[15:29] <qense> hello developers
[15:29] <qense> I've got a question concerning  bug 186264
[15:29] <ubotu> Launchpad bug 186264 in hal "keyboard randomly goes dead; takes a logout to restore functionality." [Undecided,Incomplete] https://launchpad.net/bugs/186264
[15:30] <qense> It already has a lot of log files attached to it, but I still can't decide if HAL is the package where it should be and if it's compelte
[15:30] <qense> does anyone knows what to do?
[15:30] <seb128> tjaalton: ok
[15:34] <tjaalton> seb128: thanks
[15:34] <seb128> pitti: could you just add a ack on the pixman bug if you are ok for the update?
[15:35] <pitti> TBH I can't approve this as bugfix-only in good faith
[15:37] <seb128> pitti: I didn't say it's bug fix
[15:37] <seb128> pitti: bug cairo requires it or we are stucked with an unstable version
[15:38] <seb128> pitti: or we need to patch cairo backward to not use whatever it requires now
[15:44] <Caesar> tjaalton: just btw and fyi, the changelog in nfs-utils is still missing all of the previous Ubuntu changes
[15:45] <Caesar> (not that I'm looking forward to rebuilding with our local changes *again* if you do anything about it)
[15:46] <cjwatson> 09:32 <cjwatson> Caesar: uuid-runtime seems to be optional (both according to the changelog, and according to Debian priorities); I made casper depend on it, but I wonder if we need to install it by default
[15:46] <cjwatson> 09:32 <cjwatson> of course it's arguably inconvenient to deal with UUIDs without it ...
[15:46] <cjwatson> Caesar: don't know if you saw ^-- that this morning
[15:47] <cjwatson> Caesar: are you just using it for uuidgen?
[15:47] <tjaalton> Caesar: there weren't that many to begin with
[15:47] <Caesar> cjwatson: yes I saw
[15:47] <Caesar> cjwatson: we were using uuidgen, yes, and it just seemed to disappear
[15:49] <Caesar> cjwatson: we're just explicitly apt-installing it in our early command now
[15:50] <cjwatson> Caesar: I'm not sure what the right answer here is. On the one hand it's a regression for some; on the other, it is genuinely optional and most people won't notice
[15:50] <cjwatson> mind you, it's tiny
[15:50] <jdong> wow, gvfs-mount is quite sexy
[15:50] <cjwatson> I think I'll put it in standard as a recommendation
[15:51] <lamont> pitti: if you get bored today, could you look at 211666 (nmap) for inclusion?
[15:51] <lamont> jdstrand: I added the 'Addresses-Ubuntu-Bug: 204658' line to your patch when I accepted it... :-)
[15:54] <keescook> slangasek: nah, ptrace has always been crappy.
[15:56] <lamont> keescook: ptrace has always been lovely, providing you're the attacker. :-0
[15:57] <keescook> lamont: hehehe.  +1.
[15:57] <keescook> I've seen gdb and strace do the thing slangasek describes, though.  really sucks.  "whaaat? noo! I said quit gdb! not the attached process!"
[15:58] <keescook> from what I've been able to tell it tends to be either the application reacting poorly to an interrupted syscall, or threads gets highly upset.
[15:59] <lamont> threads + gdb == NOTLOVE
[16:08] <lamont> jdstrand: do you have more apparmor er stuff for bind9?
[16:08] <jdstrand> lamont: nope. the ApparmorProfileMigration is all worked out
[16:09] <jdstrand> lamont: just that bug you committed to -10
[16:09] <jdstrand> (thanks btw)
[16:10] <Mirv> pitti: ok, I got a fix (debdiff + package at PPA) for bug 204155 and subscribed ubuntu-main-sponsors, but the policykit-gnome (bug 199255) I couldn't resolve at least yet. If I don't update the bug, then I didn't find a fix (or have time)
[16:10] <ubotu> Launchpad bug 204155 in network-manager-applet "Nm-editor translations not loaded" [Undecided,Confirmed] https://launchpad.net/bugs/204155
[16:10] <ubotu> Launchpad bug 199255 in policykit-gnome ""Authorizations" shows untranslated, but it's translated in Launchpad" [Undecided,In progress] https://launchpad.net/bugs/199255
[16:15] <lamont> jdstrand: ok.  sorry for not noticing that before i did the upload of -9 :-(
[16:24] <jdstrand> lamont: np
[16:38] <keescook> jdstrand, lamont: with the klibc changes I uploaded last night, can you update your initramfs and verify that it fixes the "m" issues with AppArmor on i386?  I verified that the resulting personality bits are correct, but I didn't have a functional setup of slapd.
[16:39] <lamont> keescook: sure - it'll be this weekend though
[16:39] <jdstrand> keescook: actually, just test-openldap.py then reboot is enough
[16:40] <keescook> oh heh
[16:40] <jdstrand> keescook: but I can do it
[16:40] <jdstrand> keescook: it'll be a bit though
[16:40] <jdstrand> (today, just not *now*)
[16:40] <keescook> cool, thanks guys.  no rush.  :)
[16:43] <jdstrand> keescook: thanks for getting to the bottom of it! :)
[16:43] <keescook> jdstrand: it was a fun exercise.  ironically "fix executable stacks" is on my list already, it's just waaay down there.
[16:43] <jdstrand> :)
[16:55] <mok0> My kmail doesn't work under kde4 anymore :-(
[16:55] <Riddell> mok0: #kubuntu-kde4
[17:03] <lool> soren: I fought a little due to the state of the kernel, but I just got a lpia vm running
[17:04] <mok0> Is it only me, or is gfortran incredibly much slower than g77?
[17:05] <LaserJock> mok0: in compiling or the resulting binaries?
[17:05] <mok0> LaserJock: Compiling
[17:05] <lool> soren: Could you please have a look at lp:~lool/ubuntu-jeos/trunk and eventually merge it? :)
[17:05] <LaserJock> I haven't noticed it, but I haven't been timing my builds :-)
[17:06] <mok0> LaserJock: It's probably just because I'm sitting and looking at it...
[17:06] <pitti> Mirv: thanks
[17:08] <LaserJock> mok0: "A watched compiler never finishes"
[17:08] <mok0> LaserJock: :-)
[17:27] <infinity> Riddell: Hrm, mkquashfs appears to be hanging on creating kubuntu-kde4...
[17:28] <Riddell> infinity: and that's blocking everything else?
[17:28] <infinity> Riddell: Yeah, lockfile being held while kubuntu-kde4 spins.
[17:29] <Riddell> infinity: any log file to find out what's up with kubuntu-kde4?
[17:30] <infinity> Riddell: It just.. Gets stuck. :/
[17:30] <infinity> Riddell: Given that it happens on both buildds (two different arches) every day, it's got to be reproducible.
[17:31] <Riddell> infinity: but there must be a logfile to say what it's doing when it gets stuck no?
[17:31] <infinity> Riddell: It's running mksquashfs.
[17:31] <infinity> Riddell: It gets "stuck" around 70% and just spins.
[17:32] <infinity> Riddell: I can only assume some bit of data unique to kubuntu-kde4 is tripping a bug in mksquashfs.
[17:33] <infinity> Riddell: Anyhow, I've killed those two hung processes... I might disable the kubuntu-kde4 cronjob on antimony until we have time to debug the problem, if that's alright with you?
[17:33] <mvo> cjwatson: hello! because the new sudo cleans the environment I'm looking for a new test to check if the release-upgrader is running under ssh. I used to check the SSH_TTY environment, do you know about a good alternative way without checking the environment?
[17:33] <Riddell> infinity: k
[17:34] <infinity> Riddell: I can't guarantee I'll have time in the immediate future to look at it, so if you want to use livecd-rootfs to try to reproduce it locally, that might be nice.
[17:35] <infinity> Riddell: I assume, though, that kubuntu-kde4 is a community "fun" thing, not a release target?
[17:35] <Riddell> infinity: it's a release target
[17:37] <infinity> Riddell: Oh, poo. :/
[17:37] <infinity> Riddell: Well, we'll have to make time soonish to look at the bug, then.
[17:44] <pitti> zul: http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt also has some freeradius, nut, and redhat-cluster binaries which want to go to universe (see bottom of page); which of those should get seeded, and which shuold go to universe?
[17:44] <cjwatson> mvo: it's going to be pretty nasty ... look in the process tree and see if one of your ancestor processes is 'sshd: <something>'?
[17:45] <mvo> cjwatson: right, I was afraid you would answer this :) oh sudo, please give me back the old behavior
[17:46] <pitti> cjwatson: would "who | grep `tty`" be a feasible solution?
[17:46] <zul> pitti: freeradius and nut should all be seeded and im not sure about redhat-cluster though
[17:49] <zul> pitti: ill go and seed them
[17:49] <pitti> zul: thanks
[17:49] <pitti> keescook, mathiaz: do we want libpam-apparmor in main? it currently wants to go to universe, so if we do, it needs to be seeded (to supported, I guess)
[17:51] <cjwatson> pitti: who doesn't tell you that it's ssh
[17:52] <cjwatson> you get a remote host name, but if you wanted that it might be more elegant to look in ck-list-sessions or similar
[17:52] <pitti> mvo: is the actual aim of your test "remote login" or "ssh" in particular?
[17:52] <cjwatson> I was guessing that mvo actually wanted to know specifically ssh, rather than just "is it remote"
[17:52] <pitti> ah, I'm not sure
[17:52] <cjwatson> if it's specifically ssh, a supplementary question would be why? :-)
[17:53] <zul> pitti: done
[17:53] <lamont> mvo: I have noticed that sudo is prompting more often than it used to...
[17:53] <mvo> pitti: yeah, ssh because then I know what to do (offer to start a additional spare sshd)
[17:54] <cjwatson> ah
[17:54] <keescook> pitti: I have no desire for it to be in main currently.  changehat support is still rather weak overall, so I'd rather leave it out (same for the apache lib)
[17:57] <mok0> Yikes the latest kernel update hosed my graphics setup
[17:57] <keescook> mok0: in what way?
[17:57] <mok0> keescook: It came up in 640x480
[17:58] <keescook> mok0: usplash or Xorg?
[17:58] <mok0> xorg
[17:58] <mok0> Fortunately the old xorg.conf file was still there
[17:59] <keescook> mok0: hm, I don't know much about xorg res settings yet.  bryce could this be related to xrandrgui changes?
[18:00] <mok0> I also lost my GLX extension
[18:01] <mok0> ... but perhaps I just need to re-enable my restricted nVidia driver
[18:07] <seb128> re
[18:08] <seb128> pitti: so about libpixman?
[18:09] <seb128> slangasek: opinion on https://bugs.edge.launchpad.net/ubuntu/+source/pixman/+bug/211785?
[18:09] <ubotu> Launchpad bug 211785 in pixman "Please sponsor pixman 0.10.0-0ubuntu1" [Undecided,New]
[18:10] <slangasek> seb128: looks to me like it should be submitted for an FFe, but doesn't include an upstream changelog
[18:10] <seb128> slangasek: the update is not trivial but it's required for the new libcairo version (we track 1.5 at the moment and would be better to not be stucked to a non stable version)
[18:10] <slangasek> seb128: are there compelling reasons to want cairo 1.6.0 for hardy?
[18:11] <slangasek> ok, you just answered that I guess :)
[18:12] <seb128> slangasek: I think there is quite some work going upstream to fix firefox 3 issues since it uses cairo quite a lot now
[18:12] <seb128> slangasek: so I would prefer to do the libcairo 1.5.n to 1.6 updates
[18:12] <seb128> the new pixman has been uploaded to debian today
[18:13] <seb128> we can wait until monday and upload if nothing break there maybe?
[18:13] <slangasek> ok - then pixman should go through the FFe process, so please get me an upstream changelog
[18:13] <seb128> ok
[18:13] <slangasek> (and subscribe ubuntu-release)
[18:13] <seb128> fta: ^ could you do that too?
[18:13] <seb128> slangasek: well, the debdiff and diffstat and ping was sort of a FFe request, but right we will follow the rules ;-)
[18:14] <keescook> who is our ntfs guru?  :)  I'd like someone to take a look at bug 190329
[18:14] <ubotu> Launchpad bug 190329 in ntfs-3g "DAC permissions not correctly enforced" [Undecided,Confirmed] https://launchpad.net/bugs/190329
[18:15] <fta> seb128, upstream changelog is empty, it was empty in the version too
[18:15] <seb128> fta: git log between those then?
[18:16] <fta> possible, i have to pull it 1st
[18:24] <pitti> keescook: ok, demoting
[18:34] <fta> slangasek, do you want a summarized changelog or the raw one ?
[18:38] <keescook> pitti: btw, i think libapparmor1 and libapparmor-dev will fall into universe too
[18:41] <fta> seb128, done (2 logs attached to the bug and ubuntu-release subscribed)
[18:42] <seb128> fta: thanks
[18:42] <seb128> slangasek: ^
[18:44] <bryce> Mirv: yeah I've been focusing on getting the revert dialog ready to go, and there's some new stuff from upstream that I think seb128 has been working on
[18:44] <seb128> bryce: not been working on those updates yet, I've been busy with lot of other GNOME things
[18:45] <seb128> bryce: and GNOME 2.22.1 is due next week so I'll likely be busy doing those update for most of the week
[18:45] <bryce> keescook: no the xrandr gui doesn't touch the xorg.conf at all.  I've seen some other reports of GLX extension problems, and it sort of feels like a kernel issue.
[18:45] <slangasek> fta: the full upstream changelog
[18:46] <bryce> seb128: hrm, well xorg stuff has been keeping me quite busy.  I have trouble finding time to contribute into the gnome work
[18:46] <fta> slangasek, i've posted both
[18:47] <seb128> bryce: yeah, everybody is overworked
[18:48] <seb128> bryce: I would argue that this one is not a GNOME thing though but something the xorg team wants
[18:49] <seb128> bryce: anyway, new GNOME = 60 to 80 updates to do, so I guess I'll be busy but I'll try to give a hand on that after the updates
[18:49] <bryce> I'm going to be gone the last half of next week for my wedding, and will be out most of the week after that for the X conference, so I'm nearly out of time for Hardy work
[18:49] <seb128> bryce: hum, k, too bad, I guess we will have to find somebody to help or delay to 8.04.1 then
[18:51] <calc> seb128: what is the target date for 8.04.1 ?
[18:52] <seb128> calc: not sure, around 3 months after 8.04 I think
[18:52] <calc> oh ok
[19:04] <jdstrand> slangasek: hi! curious on your opinion on bug #209897
[19:04] <ubotu> Launchpad bug 209897 in ufw "FFe: ufw 0.16.2" [Undecided,New] https://launchpad.net/bugs/209897
[19:04] <jdstrand> slangasek: if it's on your todo list, don't worry about it
[19:05] <jdstrand> (talking about it with me that is)
[19:05] <cjwatson> calc: start of July
[19:05] <cjwatson> it's on HardyReleaseSchedule
[19:08] <slangasek> jdstrand: on the list, yes :)
[19:08] <jdstrand> slangasek: ok, thanks
[19:13] <calc> cjwatson: oh ok
[19:15] <shaya> upgrades from dapper to hardy might have a problem
[19:15] <shaya> emu: Dynamic MMap ran out of room
[19:15] <shaya> apt erros out on universe list
[19:15] <shaya> that was E: Dynamic MMap ran out of room (not emu, stupid xchat)
[19:29] <cjwatson> shaya: any chance that you have lots of other stuff in sources.list?
[19:29] <shaya> not that much
[19:29] <shaya> just dapper and hardy
[19:29] <shaya> added a single hardy line
[19:30] <slangasek> the typical upgrade process (using update-manager) is to replace the dapper lines with hardy.
[19:31] <shaya> yea
[19:31] <shaya> but aptitude is stupid
[19:31] <shaya> it loses all the tracking information if I do it that way
[19:31] <shaya> I guess I could do an apt-get update
[19:31] <shaya> and then run aptitude
[19:31] <laga> slangasek: did you have a chance to merge ltsp.seed from mythbuntu again?
[19:31] <slangasek> laga: yes, done; sorry, forgot to mention that here
[19:31] <laga> slangasek: no problem, thanks! :)
[19:34] <shaya> what's the default mta in hardy? exim4?
[19:34] <shaya> as thats what my upgrade is trying to install
[19:34] <ScottK> shaya: None is installed by default.  Postfix is our preferred one, but if you have a package that needs an MTA, that package my prefer exim.
[19:34] <infinity> shaya: postfix is the "preferred", but both postfix and exim4 are supported.
[19:35] <shaya> well, exim4 got chosen
[19:35] <shaya> not by me, so might be an ordering issue in some package
[19:35] <infinity> (Note that packages in main are meant to have "postfix | m-t-a" deps, so if one doesn't, that's a minor bug)
[19:35] <ScottK> shaya: If you'd rather have a different MTA, stop the upgrade, install the MTA you want, and then upgrade again.
[19:35] <shaya> ScottK: i know
[19:35] <ScottK> OK.
[19:35] <shaya> I was just saying what infinity jus said
[19:35] <shaya> might be a bug somewhere in Depends ordering
[19:35] <lamont> infinity: they quit forking packages just to add that sometime ago
[19:36] <infinity> shaya: That requirement doesn't exist for universe, though, just main.
[19:36] <ScottK> As a rule if that's the only difference we don't change it.
[19:36] <infinity> lamont: Oh, did we?  I'm out of the loop.
[19:36] <shaya> infinity: universe is commented out right now per bug I mentioned b4
[19:36] <ScottK> infinity: Yes.  Not worth maintaining the diff for.
[19:36] <lamont> infinity: well, you see, I quit :-)
[19:37] <infinity> lamont: But you keep coming back...
[19:37] <lamont> infinity: like herpes
[19:37] <infinity> lamont: But more irritating. ;)
[19:37] <lamont> infinity: anyway, the new push is to make a 'default-mta' package, and have packages Depend: default-mta | mta
[19:38] <lamont> then one package to throw the switch, and in the darkness bind them
[19:38] <infinity> lamont: Makes sense, I suppose.
[19:38] <laga> will default-mta be a virtual package?
[19:38] <infinity> laga: No, it would have to be a real package.
[19:38] <lamont> well, every time I bring it up with the exim4 maintainer in debian, it kinda starts interesting discussions
[19:38] <lamont> laga: no
[19:39] <lamont> it'll be a contentless package which Depends: on $WINNER | mail-transport-agent
[19:39] <lamont> where WINNER== exim4 or postfix, depending on whether you're debian or ubuntu
[19:39] <infinity> lamont: Well, it's a pretty big change that obviously only benefits derivatives, so I can see why one might get push-back.
[19:39] <laga> ah, was just wondering :)
[19:39] <ScottK> The benifit to Debian maintainers would be less having to see pointless Ubuntu patches on p.q.d.o.
[19:40] <lamont> infinity: it's usually of the form "why don't we just make the debian default postfix so I can quit dealling with all the whiners" type response...
[19:40] <lamont> I'm just not sure he's serious...
[19:40] <infinity> lamont: I honestly don't care what the default is anyway, I'll keep installing exim locally.
[19:40] <infinity> lamont: And I don't see why Debian would care much either, given their userbase.
[19:40] <lamont> laga: the whole 'real | virtual' thing is so that you don't get a random one if none are installed, since apt will pick $SOMETHING that provides: virtual, and you have no control over it
[19:41] <lamont> infinity: see the despair poster. :)
[19:41] <infinity> lamont: It matters mostly for Ubuntu, because our userbase is (on averge) more "end-userish" and more likely to request support, and supporting both hurts.
[19:41] <shaya> mailx: is Depends: exim4 | mail-transport-agent
[19:41] <lamont> shaya: if there isn't any other ubuntu diff for the package, then it conforms to the current debian standard.  see, for example, uh, mailx
[19:41] <lamont> :-)
[19:42] <shaya> lamnt: even if it's in "main" ?
 shaya: if there isn't any other ubuntu diff for the package ..
[19:42] <infinity> shaya: Evidently, I was living in the past, and we no longer change packages in main for just that.
[19:43] <shaya> doesn't make much of a consistent policy...
[19:43] <lamont> infinity: I believe it was $lamont that did that in the past, the rest of the distro team went 'meh'
[19:43] <infinity> lamont: I used to always do it too, as I'd assumed it was established policy.
[19:43] <lamont> shaya: hence the work in progress to make it so we can change one package and win
[19:43] <infinity> lamont: And it's painful to explain to users why they got a random MTA (even if we do support both of them)
[19:44] <infinity> lamont: The big problem is that most of the wiki docs and such refer to postfix, and completely ignore that exim is also in main.
[19:44] <infinity> lamont: So, a user with exim installed, while clearly having the superior MTA, is at a loss for "easymode" support.
[19:44] <lamont> and pushing exim to universe wouldn't fix that either
[19:44] <lamont> infinity: your bias is showing... pull your pants back up/
[19:45] <infinity> lamont: Pushing exim to universe would make elmo and I very grumpy.
[19:45] <infinity> lamont: Bias?  What bias?
[19:45] <lamont> and wouldn't change anything
[19:45] <lamont> heh
[19:45] <infinity> lamont: I imagine my bias is similar to yours, in that I've contributed so much code and time to exim, I can't use anything else.
[19:45] <lamont> exim vs postfix - depending on your criteria, both are better.
[19:46] <lamont> Oh, I can use exim, I just don't like to
[19:46] <infinity> We call all agree that both are infinitely better than writing sendmail.cf by hand.
[19:47] <shaya> lamont: if one doesn't want to patch the packages
[19:47] <shaya> why not just patch apt/aptitude/update-manager with the right logic?
[19:47] <infinity> Eww.
[19:47] <infinity> No.
[19:47] <shaya> :)
[19:48] <infinity> We don't want to FORCE postfix on anyone, nor have any "magic" in the background.
[19:48] <infinity> We just want to have a default that makes it easier to exlain things to new users who don't know what an MTA is at all, and don't care.
[19:48] <shaya> I didn't say force
[19:48] <slangasek> I prefer my magic front and center, yes
[19:48] <shaya> I said if no choice, choose it for them
[19:49] <lamont> infinity: so having postfix provide: exim4 would be bad, eh? :-)
[19:49] <laga> (if the user doesn't know what an MTA is, and if they don't care, should they be using an MTA?)
[19:49] <infinity> But, y'know, for those who know, the easy solution is "apt-get install postfix mailx", and you're done. :P
[19:49] <lamont> and the mail-server task includes postfix, to force things in the right direction
[19:49] <infinity> laga: I'd argue "no", but I'm also regarded as an elitist jerk.
[19:49] <slangasek> by "regarded", he means "there's a UN resolution that declares him to be..."
[19:50] <infinity> Ouch.
[19:50]  * calc thinks he determined what was wrong with OOo icons patch, finally :)
[19:50] <laga> heh :)
[19:51]  * calc isn't sure how it ever worked
[19:51] <slangasek> infinity: don't worry, I'm pretty sure this is the same UN resolution that declares MJ Ray has an inalienable right to whinge on mailing lists
[19:52] <infinity> slangasek: "whinge"?  Have you been hanging out with too many brits again?
[19:53] <Daviey> oi!
[19:53] <slangasek> infinity: mayhaps
[19:53] <infinity> slangasek: perbe!
[19:54] <lamont> nagios-plugins prompts-a-plenty FTFL
[19:55] <lamont> infinity: he's trying to be cjwatson
[19:55]  * lamont ducks
[19:55] <slangasek> I just find "whining" an inexact description. :)
[19:55]  * lamont wonders if he wants the dapper/modified, or hardy version of cupsd.conf
[19:56] <infinity> Keep both, and alternate them based on moon phase.
[19:56]  * shaya sighs
[19:56] <lamont> well, the funny part is that this machine is the one that has the broken USB printer plugged into it
[19:56] <infinity> If it's broken, I hardly see the issue.
[19:57] <lamont> well, the jetdirect-printers that are also configured _do_ work
[19:57] <slangasek> infinity: did you see Riddell's comment from this morning about livefs being stuck again?
[19:57] <infinity> Yeah, only an ex-HP emplpoyee has JD printers at home.
[19:57] <lamont> and my primary source of pain/joy uses a machine that's configured to print through cups on the machine I'm upgrading
[19:57] <slangasek> oh, indeed, and you had a conversation about it right in front of me
[19:57] <infinity> (I was going to go JD on my parents' printer, but the added cost for the JD card just isn't worth it)
[19:58] <infinity> slangasek: Yes, yes we did.
[19:58]  * lamont tries to remember if the colorlaserjet 2550n was bought from the HP referb, or from OfficeDepot closeout-rack
[19:58] <infinity> slangasek: mksquashfs is hanging around ~70% on kubuntu-kde4 (and only on kubuntu-kde4) on both arches.
[19:58]  * ScottK has a Jet Direct box.
[19:58] <slangasek> infinity: right
[19:58] <infinity> slangasek: Someone investigating that locally would be lovely, since it's clearly a distro bug, not my bug. :)
[19:59] <lamont> infinity: I ran into mksquashfs hanging on my machine somewhere around 1-1.5 GB into an image
[19:59] <slangasek> infinity: right... :)
[19:59] <lamont> so upgrading to hardy probably won't fix it...
[19:59] <lamont> kthx
[19:59] <infinity> lamont: livefs uses hardy anyway...
[19:59] <lamont> right
[20:00] <lamont> I'm trying to remember if it was broken on gutsy for me, or if it broke after I upgraded
[20:00] <infinity> slangasek: Anyhow, seems to be par for the course for us to headless-chicken last minute squashfs bug fixes before releases anyway, so I'm sure we'll manage.
[20:00] <slangasek> heh
[20:00] <lamont> in the end, my backup DVD image became an encrypted tar -j instead of an encrypted squashfs iso
[20:00] <infinity> slangasek: And by "we", I mean "you".
[20:01] <slangasek> yes, I'll managed, and you shall be managed
[20:01] <slangasek> <-- release manager
[20:01] <slangasek> I bet that would've sounded more ominous if I hadn't typoed
[20:01] <infinity> It would also have carried more weight if I was on the distro team. :)
[20:02] <slangasek> this too!
[20:02] <lamont> dear nagios-plugins.  no love.
[20:02]  * lamont looks around for his scissors
[20:02] <laga> i'm trying to understand seeds (again) and the interaction with tasksel. if the seed for the live disk contains recommends like "* (network-manager-gnome)", are these installed by default?
[20:06]  * lamont wanders off 
[20:10] <Riddell> laga: yes (the brackets mean its a recommends rather than a suggests, so it can be removed)
[20:11] <lamont> Apr  4 11:33:17 printers cupsd: Unable to open log file "/var/log/cups/error_log" - Permission denied
[20:11] <lamont> win
[20:11] <LaserJock> although tasksel isn't used by the live cd is it?
[20:11] <slangasek> Riddell: s/suggests/depends/
[20:12] <laga> LaserJock: true. :) trying to understand the interaction between seeds and the live disk ;)
[20:15] <Riddell> laga: as slangasek says
[20:16] <Riddell> LaserJock: live cds a bulid from kubuntu-live^ etc, which is a task
[20:31] <calc> mu
[20:31] <calc> er M}Y
[20:31] <calc> sorry my 7mo old son decided he wants to use Ubuntu
[20:59] <jdstrand> keescook: \o/ slapd still running without 'm' on i386 reboot ( bug #202161 )
[20:59] <ubotu> Launchpad bug 202161 in klibc "apparmor broken after reboot on i386" [Medium,Fix released] https://launchpad.net/bugs/202161
[21:07] <keescook> jdstrand: \o/
[21:09]  * jdstrand hugs keescook 
[21:10] <jdstrand> of course now, we have to update cupsys and slapd
[21:10] <keescook> heh
[21:10] <keescook> this exercise of klibc vs ld makes me feel well-prepared to take on the "eliminate executable stack" task now.  :)
[21:11] <jdstrand> yea
[21:28] <pawalls> join #puppet
[21:28]  * pawalls fails...
[22:05] <calc> heh comcast man trying to convert me to their service
[22:06] <calc> i'm like "i don't really want packet filtered internet, but your new 50Mbps service in 2010 sounds great", heh
[22:06] <calc> they offer 2-3x faster internet than i currently can get from my telco but they don't packet filter (afaict anyway)
[22:06] <calc> at least not yet
[22:10] <slangasek> but I'm thinking they aren't going to put that in a contract for you. :)
[22:11] <calc> well at 50Mbps even packet filtered might not be too bad
[22:11] <calc> i'd rather have 3Mbps unfiltered (that i currently have) than comcast's 6Mbps filtered though
[22:12] <calc> for 17x faster internet access i might trade unfiltered traffic :-\
[22:12] <calc> of course the rumor is that the 50Mbps connection will cost $150/mo (ouch)
[22:13] <Caesar> Is there a way to see all bugs submitted in Launchpad, not just the open ones?
[22:13] <Caesar> (for a given submitter)
[22:15] <calc> whats the new style printf specifier for unsigned long (on amd64)?
[22:15] <calc> that would be a unsigned 64bit specifier, right?
[22:15] <calc> oh doh that isn't my bug, i left a extra , laying around :\
[22:16] <calc> the numbers i am printing is small enough that the right specifier isn't a big deal it just was warning about them being wrong
[22:17] <calc> a %lu
[22:19] <cjwatson> laga: Launchpad arranges for anything in a task (either depends or recommends, or (in)direct dependencies from either of those) to have a Task: whatever header, and livecd-rootfs tells apt to install everything that says Task: whatever
[22:19] <cjwatson> so it all works out
[22:20] <cjwatson> Caesar: launchpad.net/~person/+reportedbugs, advanced search, check all the statuses
[22:21] <cjwatson> Caesar: modulo bug 148901, which may interfere a bit, but not a lot to be done about that except encourage the LP guys to fix it
[22:21] <ubotu> Launchpad bug 148901 in malone "less bugs listed when sorting" [High,Confirmed] https://launchpad.net/bugs/148901
[22:22] <cjwatson> oh, heck, that's irritating me. "fewer"!
[22:23] <laga> cjwatson: how does launchpad know which tasks are there (and which packages are related to a task?)
[22:24] <Caesar> cjwatson: thanks
[22:25] <cjwatson> laga: Task-* headers in the seeds
[22:25] <cjwatson> laga: "which packages" is easy, it uses germinate to expand the correspondingseeds
[22:25] <cjwatson> s/gseeds/g seeds/
[22:26] <calc> it seems gedit is only registered to open files of type text/plain :\
[22:26]  * calc wonders if this is considered a bug or a feature
[22:27] <cjwatson> laga: it has a hardcoded list of which seed branches to look at
[22:28] <laga> cjwatson: well, i've got the germinate and the tasksel package and they're all already set up for the mythbuntu branches, so i guess i'm good to go
[22:28] <cjwatson> laga: mythbuntu, sadly, is not in Launchpad's hardcoded list
[22:28] <cjwatson> laga: you can work around that by having livecd-rootfs install a metapackage rather than a task, though
[22:28] <cjwatson> Launchpad only really matters for the Task headers
[22:29] <cjwatson> i.e. omit the "^"
[22:29] <elmo> oh hai, why is I getting sane prompts on resume?
[22:32] <laga> cjwatson: i'm not interested in livecd-rootfs.. we have our own build scripts for the live disks where we indeed use a meta package :) i basically need to add a) a few packages to be shipped on our alternate disks which is built on cdimage.u.c (i guess that's easy) b) add some new tasks so users can choose what kind of setup (eg a set of packages) they want.
[22:32] <cjwatson> laga: ok, well in that case you don't need to worry about Launchpad
[22:33] <cjwatson> germinate, tasksel, and presumably mythbuntu-meta is all you need
[22:33] <cjwatson> laga: I'm afraid that we are out of space on cdimage
[22:33] <laga> cjwatson: i guess i can make a new seed file, add Task-Key: my-new-task and then run ubuntu-seeds.pl in tasksel?
[22:33] <laga> cjwatson: our image is already built there, do you need to drop it?
[22:33] <cjwatson> oh, is it?
[22:34] <cjwatson> so it is, I thought you were requesting a new build
[22:34] <cjwatson> please look at the *-server seeds in ubuntu.hardy for examples
[22:34] <laga> no. :)
[22:35] <laga> cjwatson: do they contain everything needed to generate new tasks?
[22:35] <laga> or does additional magic need to happen?
[22:35] <cjwatson> you also need to fiddle with the STRUCTURE file
[22:35] <cjwatson> I suggest that you create the seeds and then let me review them
[22:35] <cjwatson> I would like to review them before a tasksel upload happens in any case
[22:36] <cjwatson> right now I'm too tired to give good general advice, but specific advice is a lot easier :)
[22:36] <laga> that's ok, i'm too tired to ask good questions anyways :)
[22:36] <laga> cjwatson: i'll take you up on your offer to review them :)
[22:37] <cjwatson> basically putting the right set of Task-* at the top is sufficient, but tasksel will need to be rebuilt and likely mythbuntu-meta too
[22:37] <cjwatson> you also need to get the structure right so that cdimage will include them on CDs
[22:37] <cjwatson> which basically means (for alternate CDs) having them be inherited by ship
[22:38] <cjwatson> and you'll probably need to adjust any tasksel preseeding you have in cdimage to allow the user to choose
[22:43] <laga> cjwatson: i'll try to get back to you tomorrow, thanks for the input
[23:25] <calc> Riddell: ping
[23:26] <Riddell> hi calc
[23:27] <calc> do we use human or crystal (or something else) on kubuntu?
[23:27] <calc> i'm fixing the icon theme issue on openoffice and wanted to make sure i set it up right
[23:28] <Riddell> calc: crystal
[23:28] <calc> ok :)
[23:28] <calc> i'm hoping to have the fallback patch working properly by later tonight for inclusion in the upload early next week
[23:31] <calc> even with ccache it takes ~ 90m to do a build :\
[23:31]  * calc wishes OOo could safely multithreaded compile
[23:45] <tjaalton> calc: did you check --enable-ogltrans? the configure script doesn't seem to know about it, though the upstream one does
[23:46] <calc> tjaalton: enable-opengl seems to do it
[23:46] <calc> tjaalton: does installing openoffice.org-ogltrans not fix the issue?
[23:47] <tjaalton> calc: oops, I didn't notice it exists.. let me check
[23:47] <calc> /usr/lib/openoffice/program/OGLTrans.uno.so
[23:47] <calc> /usr/lib/openoffice/share/config/soffice.cfg/simpress/transitions-ogl.xml
[23:47] <calc> looks like it should be working
[23:48] <tjaalton> ooh yeah ;)
[23:50] <tjaalton> calc: yeah, works perfectly, thanks :)
[23:51] <calc> great :)
[23:52] <calc> wow selecting human-murrine crashes firefox
[23:54] <Fujitsu> human-murrine is choosable again now? Yay!
[23:55] <tjaalton> calc: switching compiz->metacity does the same
[23:55] <calc> fun