[00:12] <ckyle> where do i find info on syscalls in ubuntu? mmap() and stuff? thx
[00:12] <ckyle> does it come w/ os?
[00:26] <mok0> ckyle: man mmap
[00:29] <mok0> (after installing manpages-dev)
[00:35] <NCommander> lamont, give a moment to talk about ports?
[00:42] <erast> anyone interested in porting their .deb packages to OpenSolaris/Nexenta ?
[00:42] <erast> we have bunch of SSH dev. accounts to ZFS zones on gnusolaris.org
[00:45] <NCommander> erast, Nexenta seemed kinda dead last time I looked; is there an amd64 port yet?
[00:46] <erast> yep
[00:46] <erast> i think community growing
[00:46] <NCommander> erast, I'd install it expect my trackpad doesn't work in Solaris
[00:46] <erast> we ported Hardy Heron recently and released first alpha
[00:46] <NCommander> erast, what are you using for infrastructure, dak I assume
[00:47]  * NCommander has played with Nextena and is interested
[00:47] <erast> dpkg-buildpackage
[00:47] <erast> dput
[00:47] <erast> normal stuff
[00:47] <NCommander> erast, I meant server side ;-)
[00:48] <erast> debarchiver
[00:48] <NCommander> erast, i.e., what handling the incoming and such
[00:48] <NCommander> seriously?
[00:48] <NCommander> I'm suprised it scales that well
[00:48] <erast> why not
[00:48] <erast> 95% of packages compiles as is
[00:48]  * NCommander used dak when he was hosting debian-68k testing
[00:48] <erast> i.e. apt-get source -b
[00:49] <NCommander> erast, you should be running a buildd to build all debs automatically
[00:49] <erast> i think tim (rootard) working on new autobuilder for nexenta
[00:49] <erast> its going to use ZFS and Zones
[00:49] <NCommander> erast, I won't mind helping to set that up
[00:49] <NCommander> I've run and adminned buildds before
[00:50] <erast> that'd be great
[00:50] <NCommander> Where's the dev channel?
[00:50] <erast> #nexenta
[00:51] <erast> but first, do you want to try to get SSH login and try to build couple of packages ?
[01:39] <ilovefedora> hello how can i install php 5.2 on ubuntu 6.06
[02:04] <NCommander> I think I need help
[02:08] <cody-somerville> NCommander, I can help you.
[02:09] <NCommander> cody-somerville, how?
[02:15] <mcasadevall> cody-somerville: bah, so much for the GUI
[02:17] <mcasadevall> cody-somerville: anyway, I need some SRU love
[02:17] <cody-somerville> mcasadevall, okay.
[02:17] <cody-somerville> bug #s?
[02:17] <mcasadevall> cody-somerville: one bug, 11 packages
[02:18] <mcasadevall> It's a transition
[02:18] <mcasadevall> brb
[02:18] <mcasadevall> I need to just reboot this machine
[02:23] <mcasadevall> cody-somerville: I dunno what I did
[02:23] <mcasadevall> But I seriously hosed this laptop
[02:24] <cody-somerville> :|
[02:25] <mcasadevall> cody-somerville: I'm right now deleting stuff, and then backing up
[02:25] <mcasadevall> I reformat tonight
[02:30] <cody-somerville> lol
[02:33]  * mcasadevall decides if he wants to install xubuntu/kubuntu/ubuntu/ubuntu-stdio/mythbuntu
[02:35]  * mcasadevall backs up
[02:40] <TheMuso> ogra-Q1: Did you push your casper changes to a bzr branch somewhere? At least from what Colin has given me, they are not in trunk. I'd like to merge them into trunk, and would prefer to do it from another bzr branch if available, so that its logged in the bzr log, and not just in the debian changelog.
[02:41] <cody-somerville> xubuntu, duh :P
[02:42] <TheMuso> RAOF: Pulseaudio 0.9.12 is in my PPA. Let me know if you still have those issues. If so, I'll pull latest alsa-lib git and package them up for you to test.
[02:45] <RAOF> TheMuso: I'll test it this evening, thanks.
[02:45] <TheMuso> RAOF: np
[02:46] <TheMuso> New paprefs and pavucontrol will be uploaded to my PPA as well.
[02:51] <RAOF> Oooh! Are they shiny? </ferret>
[02:51] <TheMuso> Dunno really, but I think they are needed to work properly with the newer pulseaudio.
[02:53] <RAOF> It'd probably be simple enough to whip up a lib32pulse, if you'd like me to.
[02:54] <TheMuso> RAOF: Would that solve the alsa-plugins needing ia32-libs issue?
[02:54] <RAOF> Yes.
[02:54] <TheMuso> RAOF: Added to that, pulseaudio uses cdbs.
[02:54]  * RAOF cries
[02:54] <RAOF> Ok.  Perhaps it's _not_ easy enough to whip up a lib32pulse.
[02:55] <TheMuso> The other problem with a lib32 pulse, is all the extra module packages would have to be 32-bit as well.
[02:55] <RAOF> The pulse-module-* ?
[02:55] <TheMuso> Yep.
[02:56] <RAOF> Really?  I'd've thought they'd only be interesting for the daemon.
[02:56] <RAOF> We wouldn't be getting a 32bit daemon, right?
[02:59] <RAOF> Anyway; I'll add "spend a couple of unrewarding hours hitting CDBS with a stick" at the bottom of my TODO
[03:09] <TheMuso> heh ok
[03:10] <TheMuso> RAOF: Ah of course, you are right.
[04:36] <mcasadevall> ScottK: hola
[04:39] <ScottK> NCommander: Heya.
[04:40] <NCommander> ScottK: I have a fix for kdelibs on amd64
[04:40] <NCommander> ScottK: uploading it somewhere might a trick however, my X11 installation is somewhat hosed
[04:40] <ScottK> NCommander: Can you just mail me the debdiff?
[04:41] <NCommander> ScottK: how can I do that easily: mail<EMAIL_ADDRESS><< *file* right?
[04:41] <NCommander> (well, you can just wait also until when I reboot off the liveCD)
[04:41] <ScottK> Yes.
[04:41] <ScottK> Whichever.
[04:42] <NCommander> ScottK: I tried emailing it, I'm not sure if it will work
[04:42] <NCommander> ScottK: I confirmed it on amd64, and apachelogger confirmed on i386
[04:42] <ScottK> NCommander: I greylist, so it'll be a bit before I get it.
[04:43] <ScottK> OK.
[04:43] <NCommander> ScottK: won't work then, no return path on my email
[04:45] <ScottK> NCommander: If it got to your mail server, it should be able to handle it.  Greylisting is done during the SMTP dialogue, so that shouldn't matter.
[04:46] <NCommander> ScottK: it is?
[04:47] <NCommander> ScottK: Oh, interesting, then it should work I hope
[04:47] <ScottK> Sure.
[04:47] <NCommander> Its just you can't access my SMTP server from the net
[04:47] <NCommander> I'm suprised on how affective grey listing was
[04:47] <ScottK> You deliver to your MTA, your MTA talks to my MTA.  My MTA says 450 come back later, and then later your MTA comes back and acceptes it.
[04:48] <ScottK> As long as it can access mine, it works.
[04:48] <NCommander> neat
[04:51]  * NCommander waits on his Xubuntu disc to finish burning
[04:51] <NCommander> so ... slow ....
[04:52] <NCommander> bbl
[05:36]  * calc bought a new car tonight :)
[05:42] <avb> which one? :)
[05:42] <avb> which brand
[05:42] <calc> 2009 Honda Fit (Jazz in europe)
[05:42] <avb> nice :)
[05:42]  * avb is a bmw fan
[05:42]  * calc can't justify that high a payment ;-)
[05:43] <avb> yeh, but it worth this moneys
[05:43] <calc> mine is only 475/mo for 36mo
[05:44]  * NCommander hits his head repeatively on his desk
[05:44] <avb> im highly satisfied with 2001 X5 and 94 325i
[05:44] <avb> :)
[05:44]  * calc likes the bmw/mercedes
[05:44] <calc> i've ridden in them in the past, very nicely built just a bit out of my price range at least for now
[05:45] <avb> 325i convertible is owesome
[05:45] <calc> plus i don't think i would want a toddler in one of those they would screw it up  ;-)
[05:45] <avb> i still love it
[05:45] <calc> i have a 1yr old son
[05:45] <avb> but in the city X5 is the best
[05:45] <calc> it appears the fit gets around 42mpg for me, at least on the drive back home from the dealer, it was about 40mi away
[05:46] <avb> man, dont tell me about a fuel :)
[05:46] <avb> i prefere not to think about it
[05:46] <calc> i'm pretty sure that has to be the best fuel economy for a car in the US that isn't hybrid
[05:46] <avb> it not so hurts then :)
[05:46] <calc> lol, ok
[05:47] <avb> 13mpg ....
[05:47] <calc> ouch
[05:48] <NCommander> hey persia
[05:48] <persia> NCommander: Hello.
[05:49] <NCommander> persia, ever do something stupid and kill a lot of files by accident :-)
[05:49] <calc> rm -rf ~ works ;-)
[05:49] <persia> NCommander: Like half my home directory 150 minutes ago?
[05:49] <calc> i've done that a few times i think
[05:49] <NCommander> Well, my backup didn't properly write
[05:49] <NCommander> It seems -devel having a data failure issue :-)
[05:49] <NCommander> so I just blew away my entire HDD
[05:49] <erast> NCommander: i could teach you how to use ZFS snapshots on home dirs - you gonna love it :-)
[05:49]  * avb investigated a problem with DRI with intel
[05:50] <NCommander> erast, I'm not using opensolaris on a laptop
[05:50] <avb> finaly seems i see a problem
[05:50] <NCommander> I'm just smart enough to actually backup my SSH and GPG keys to my cell phone's flash device
[05:50] <avb> Mesa 7.1 is a problem
[05:50] <NCommander> and should the phone get lost
[05:50] <NCommander> Its a five minute call to remotely wipe it
[05:51] <erast> well, ZFS like a drug... once you tried it - you will not be comfortable with anything else again
[05:51] <avb> seems first time i will do a rollback to ubuntu-1 and ubuntu+2
[05:51] <NCommander> erast, this won't have helped, I reparitioned the HDD
[05:51] <NCommander> erast, I wanted to remove the old NTFS crud left behind by Vista
[05:52] <avb> erast: one problem is that there is no zfs in linux
[05:52] <calc> and solaris is... yuck :-\
[05:52] <erast> well there is - zfs on fuse
[05:52] <NCommander> I actually like solaris
[05:52] <NCommander> erast, the performance hit is unacceptable
[05:52] <erast> solaris - sucks... nexenta - cool :-)
[05:52] <calc> of course my experience with solaris was 2.6/7 so maybe its somewhat better now, it was horrid back then
[05:53] <NCommander> At least my system decrufted now
[05:53] <avb> i feel solaris is works like a shit on x96
[05:53] <NCommander> erast, you really should work towards supporting more than just the Ubuntu LTSs
[05:53] <avb> x86
[05:53] <NCommander> Just my two cents
[05:53] <avb> and also, their coreutils sux
[05:53] <avb> completely
[05:53] <NCommander> avb, BSD and IRIX are worse
[05:53]  * calc used solaris on sun sparc hardware
[05:53] <NCommander> (well, FreeBSD does work in that respect, but NetBSD is worse)
[05:54] <calc> i just reinstalled debian onto them after getting fed up with how useless they were :)
[05:54] <avb> BSD ever works? :)
[05:54] <avb> i thought that on firewalls only
[05:54]  * NCommander finishes building his pbuilder chroots
[05:54] <calc> solaris didn't even have top installed by default
[05:54] <calc> i was surprised at how little useful utilities came with it
[05:54] <avb> and ps -ef
[05:55] <erast> NCommander: may be one day this will happen, but for now we are going after LTS only, and as i said earlier nexenta makes sense for servers - on desktop opensolaris still sucks
[05:55] <avb> i hate a time when i ought to work with solaris
[05:55] <calc> i was probably spoiled by having used Debian before Solaris
[05:55] <avb> and also from admin point of view sparc is not betten then intels
[05:55] <erast> calc: consider nexenta, its ubuntu LTS...
[05:56] <avb> maybe its cool to code for it, but in the rest it sucks
[05:56] <erast> the userland at least
[05:56] <avb> erast: are we getting speedstep, suspend to ram stuff there? :)
[05:56] <NCommander> I just want my trackpad to work
[05:56] <avb> and normal smp support
[05:56] <avb> ?
[05:56] <calc> nexenta doesn't work on Sun hardware, so why use it at all since there is already Ubuntu ;-)
[05:56] <NCommander> My battery was detected when I ran it
[05:56] <erast> we actually have it already in the latest builds
[05:56]  * calc no longer has sun hardware though
[05:57] <erast> calc: who told you that? :-)
[05:57] <avb> unfortunately how hard linux kernel sucks, its still the best in OSS world
[05:57] <erast> we running datacenter of Thumpers x4500
[05:57] <erast> on nexenta
[05:57] <NCommander> avb, having used freebsd maybe not
[05:57] <calc> erast: nexenta.org says it runs on AMD/Intel 32/64 bit
[05:57] <avb> the rest is just a joke
[05:57] <calc> erast: doesn't mention sparc at all
[05:57] <calc> erast: or i am blind :)
[05:58] <calc> "Nexenta Operating System runs on Intel/AMD 32/64bit hardware and is distributed as a single installable CD."
[05:58] <avb> NCommander: i did. this shit even cant run on all the laptops
[05:58] <erast> you said - Sun hardware
[05:58] <avb> boot sometimes just hands
[05:58] <avb> im not telling about smp again
[05:58] <erast> x4500 - is Sun hardware too, you know
[05:58] <avb> which is a complete fault
[05:58] <calc> erast: ah i mispoke, i meant real sun hardware UltraSparc ;-)
[05:58] <calc> :)
[05:58] <erast> well its a matter of resources...
[05:59]  * calc thinks Sun should just dump opensolaris and adopt a good userland like what nexenta appears to be
[05:59] <erast> I actually compiled nexenta kernel for sparc - but haven't had enough time to package and bootstrap ISO
[05:59] <avb> i wish to have a kernel clean like netbsd
[05:59] <erast> calc: +1
[05:59] <avb> but with all features of linux
[05:59] <avb> :)
[05:59] <NCommander> erast, I can help with the bootstrapping
[05:59] <avb> and with a gnu toolchain for sure
[05:59] <NCommander> But I think I should help with your buildd situation first ;-)
[06:00] <erast> NCommander: to generate ISO, we using nexenta-builder package, take a look
[06:00] <NCommander> Well, I think you need to build the packages first ;-)
[06:00] <calc> personally i think they should dump the kernel too for x86/amd64 and contribute to FLOSS properly, but that may be going a bit too far ;-)
[06:00] <erast> NCommander: yes... a lot of missing dependencies in Hardy repo..
[06:00]  * NCommander has his development toolchains reinstalled
[06:00] <NCommander> :-)
[06:01] <calc> and open up stuff like ZFS so linux can use it :)
[06:01] <NCommander> now to figure out what else I need to reinstall
[06:01] <avb> yeh
[06:01] <avb> and fuck licensing bullshit
[06:01] <persia> !ohmy
[06:01] <erast> calc: the problem with ZFS & Linux is that Linux "layers" needs to be totally redesigned
[06:01] <avb> BSD can be used in GPL
[06:02] <avb> cant
[06:02] <avb> thats a joke
[06:02] <Vger_> BSD can be used in GPL code
[06:02] <avb> persia: sorry :)
[06:02] <Vger_> GPL can't be used in BSD code
[06:02] <calc> erast: well if the licensing was open, which aiui it isn't
[06:02] <avb> Vger_: ZFS is BSD, not?
[06:02] <Vger_> I'm not sure
[06:02] <erast> huge portion of ZFS dual licensed GPL/CDDL
[06:02] <calc> erast: aiui from reading a few months ago ZFS is patented to hell and not licensed so that it could be in the kernel in any case
[06:02] <avb> ah
[06:02] <avb> ok
[06:02] <Vger_> I thought it was under Sun's open source license
[06:02] <avb> anyway
[06:02] <calc> erast: oh maybe they improved it since i read then
[06:02] <erast> GRUB zfs module is GPLed
[06:03] <avb> its realy terrible
[06:03] <Vger_> Yes
[06:03] <avb> all this licensing issues
[06:03] <calc> erast: yea the GRUB bit is ok afaik, just not the fs driver itself
[06:03] <avb> even free licenses cant be mixed
[06:03] <calc> oh well i'll just wait for ext4
[06:03] <avb> what we can talk about the rest of them
[06:03] <Vger_> Opensource has created its own restrictions that's more vile than proprietary code
[06:03] <erast> its pretty much all you need
[06:03] <Vger_> But it's our own fault.
[06:03] <calc> avb: they can just not Sun's
[06:03] <Vger_> For being dumb :(
[06:03] <Vger_> And listening to Stallman
[06:03] <calc> licensing proliferation is bad
[06:03]  * Hobbsee wonders if this is really related to ubuntu development?
[06:04] <calc> all there really needs to be is BSD/LGPL/GPL :)
[06:04]  * calc shuts up since this is way off topic
[06:04] <Vger_> This is an awesome topic!
[06:04] <Vger_> Moar!
[06:04] <NCommander> I would consider nexenta somewhat ontopic, it is an Ubuntu derivative
[06:05] <Hobbsee> NCommander: by the same logic, we should provide support for things like medibuntu in #ubuntu, and that doesn't happen either.
[06:05] <erast> NCommander: yeah, but CDDL vs. GPL vs. BSD debates - not really...
[06:05] <calc> btw if anyone needs a new computer this is a pretty good deal: http://www.buy.com/retail/product.asp?sku=209217089&adid=17653&dcaid=17653
[06:05] <Hobbsee> Vger_: more in #ubuntu-offtopic.
[06:05] <calc> someone showed me it earlier today
[06:05] <NCommander> What's the default font on Ubuntu for menu titles?
[06:06] <Vger_> Not bad
[06:06] <avb> heh
[06:06] <avb> no i see why ubuntu is so slow :)
[06:06] <avb> now
[06:06] <Vger_> Slow?
[06:06] <avb> quad core cpu, 6gb ram is not bad :)
[06:07] <pwnguin> because developers buy quad core computers and dont notice when it's slow ;)
[06:07] <Vger_> lol
[06:07] <calc> NCommander: whatever default maps to Sans (I think)
[06:07] <avb> yeh, on mine brand new core2duo 1.6 its slow
[06:07] <calc> NCommander: playing with fontconfig probably would tell you somehow
[06:07] <Vger_> I thought the developers were too busy playing games on their new quad core computers to notice Ubuntu is slow
[06:07] <avb> and cpu is always hot
[06:07] <avb> its not about ubuntu
[06:07] <NCommander> Well, I changed it, and now I don't know what it was ;-)
[06:07] <avb> its about developers
[06:07]  * Hobbsee also, wonders how this is related to ubuntu development.
[06:07] <calc> Ubuntu isn't slow on a quad core ;-)
[06:08] <avb> :) auch
[06:08] <avb> its better for me to go to offtopic
[06:08] <calc> i'm going to upload new OOo whenever i get license go ahead from Sun
[06:08] <pwnguin> well obviously, we're going to make jaunty fast by requiring really expensive hardware
[06:08] <Vger_> Stop starting things you can't finish!
[06:08] <calc> hopefully tomorrow morning before the platform meeting
[06:09] <erast> ok, i wonder how nexenta patches could be integrated with ubuntu, so we don't have to rebuild LTS each time it released?
[06:09] <calc> pwnguin: fast boots with required SSD's ;-)
[06:09] <pwnguin> you know, ive got a couple years worth of bootcharts now
[06:09] <Vger_> pwnguin, Ubuntu is going Windows Vista route?
[06:09] <avb> pwnguin: little laptops cant be fast :)
[06:09] <pwnguin> its too bad they're stored in png
[06:09] <calc> iirc my current laptop can boot Hardy in around 20s
[06:09] <pwnguin> by default?
[06:09] <Vger_> I changed the bootup to load GDM first
[06:10] <Vger_> So I can login and do things in the first 10 seconds
[06:10] <Vger_> :p
[06:10] <calc> pwnguin: yea, but i don't know if bootchart counts everything
[06:10] <calc> pwnguin: iirc it was ~ 20s on bootchart
[06:10] <NCommander> What command in ubuntu-dev-tools can grab things from a PPA easily
[06:10] <pwnguin> bootchart counts to gdm sleep by default
[06:10] <avb> and its totaly unusable for next 40 seconds more :)
[06:10] <calc> pwnguin: i have a fairly stock install though
[06:10] <Vger_> Why does Ubuntu need to load up cups and all the other crap before GDM?
[06:11] <calc> i have a c2d 1.7ghz 4gb ram laptop
[06:11] <calc> Vger_: it might not actually be doing what you think it is, or otherwise it probably has a good reason
[06:11] <Vger_> I've never been able to find a good reason for it
[06:11] <calc> Vger_: we looked at boot time stuff in several sessions at UDS in May
[06:12] <calc> i'm sure there will be a lot of them in Dec at Google UDS as well
[06:12] <avb> the best job in intrepid is a new mail storage format
[06:12] <Vger_> So much could be solved for bootup in Ubuntu
[06:12] <avb> it stop leaking
[06:12] <StevenK> Vger_: Then bring it up at UDS :-)
[06:12] <NCommander> hey StevenK
[06:12]  * StevenK waves
[06:12] <avb> that was pissing me off last 2 years
[06:12] <Vger_> Like loading non-essential stuff in the background instead of waiting for it before you actually get to login and use the WM
[06:13] <calc> Vger_: got a bootchart to show?
[06:13] <Vger_> StevenK, might be a good topic :)
[06:13] <NCommander> StevenK, KDElibs on amd64 was fixed at the cost of my home folder
[06:13] <calc> Vger_: i'm pretty sure the stuff that is loaded before GDM generally needs to be, or you are reading the chart wrong
[06:13] <StevenK> NCommander: kdelibs ate your ~?
[06:13] <RAOF> NCommander: Yay? \-:?
[06:13] <Vger_> Like what, postgresql and cups?
[06:13] <TheMuso> RAOF: I just uploaded some git fixes for alsa-lib into my PPA. Let me know if anything changes.
[06:13] <NCommander> StevenK, no, the instantly finally caught up with me
[06:13] <Vger_> Why does that need to be loaded up before gdm?
[06:13] <NCommander> I only lost a few class notes, so I'm not so screwed
[06:13] <calc> Vger_: postgresql isn't in official Ubuntu
[06:13] <StevenK> NCommander: EPARSE
[06:14] <calc> Vger_: so it probably hasn't been tweaked
[06:14] <NCommander> er, insanity
[06:14] <Vger_> Yes, but if you install it
[06:14] <Vger_> It will add to your bootup time
[06:14] <calc> Vger_: not sure about cups
[06:14] <RAOF> TheMuso: Cool.  I'll get to that in a couple of hours.
[06:14] <calc> Vger_: well there are loads of things you can install from universe that will slow down boot most likely
[06:14] <NCommander> Scott got the patch before the machine committed died
[06:14] <Vger_> calc indeed
[06:14] <Vger_> It shouldn't
[06:14] <Vger_> But it does
[06:14] <pwnguin> Vger_: its completely controllable whether it starts at boot or not.
[06:14] <calc> Vger_: i agree that this should be fixed, maybe make a point of involving MOTU to help with some of the work
[06:15] <NCommander> StevenK, know any good todos?
[06:15] <pwnguin> but id argue postgresql should start at or near boot by default
[06:15] <StevenK> NCommander: Things to do, or programs to manage a todo list?
[06:15] <Vger_> pwnguin, yes it's controllable if you know how
[06:15] <Vger_> Like I did
[06:15] <Vger_> But most won't do it and complain Ubuntu boots up too slow
[06:15] <calc> pwnguin: you could stick it towards S99 though
[06:15] <pwnguin> what palent do people install postgres but not know where the services menu is?
[06:16] <calc> pwnguin: if it starts in 20s or 60s its not too big of a deal
[06:16] <pwnguin> planet even
[06:16] <NCommander> StevenK, the former and later
[06:16] <StevenK> NCommander: Oh, both? :-)
[06:16] <calc> pwnguin: just because you can change it doesn't mean it shouldn't have logical defaults
[06:16] <Vger_> pwnguin, surprisingly many
[06:16] <StevenK> NCommander: I like Tasque for managing my todo list.
[06:16] <NCommander> StevenK, yup
[06:16] <calc> so i agree that all things that start on boot should have reasonable start up times to help keep boot time down but what those are for each package depends on what else uses them, etc
[06:17] <pwnguin> calc: when im running a server, postgresql at startup sounds lke a reasonable default
[06:17] <calc> and upstart, i think, should help a lot in this case
[06:17] <RAOF> And the gnome-do tasque plugin makes it even more awesoem!
[06:17] <calc> once everything is converted over to using upstart scripts
[06:17] <pwnguin> i imagine upstart is going to be making a jump forward in jaunty
[06:17] <Vger_> People are impatient that's for sure
[06:17] <StevenK> RAOF: I'd like gnome-do more if it didn't leak like sieve
[06:18] <avb> boot time is okay, the problem is productivity of a software
[06:18] <RAOF> StevenK: The recent gtk-sharp upload should've fixed almost all the leaking.
[06:18] <avb> terminal is loading like a second
[06:18] <RAOF> StevenK: It wasn't our fault, honest! :P
[06:18] <StevenK> RAOF: \o/
[06:18] <avb> thats ridiculus
[06:18] <StevenK> RAOF: I've not installed gnome-do on my desktop
[06:18] <calc> avb: is that a regression in 8.10?
[06:18] <avb> nautilus... i even dont want to talk about this crap
[06:18] <RAOF> StevenK: For those playing at home, gtk# used to leak a pixmap each time you loaded an icon from the theme.
[06:18] <calc> avb: for me gnome-terminal is well under 1s load on 8.04
[06:19] <avb> calc: no, its a regression since gnome 2.0 :)
[06:19] <StevenK> RAOF: The entire pixmap?
[06:19] <RAOF> Yes
[06:19] <calc> avb: maybe its a speed of computer issue? )
[06:19] <calc> :)
[06:19] <StevenK> Blink
[06:19] <avb> c2d 1.66 :)
[06:19] <StevenK> RAOF: Almost sounds SRU-worthy
[06:19] <calc> avb: i have a c2d 1.73 and its fast as i blink pretty much
[06:19] <NCommander> StevenK, are you on an SRU team?
[06:20] <StevenK> NCommander: Nope
[06:20] <calc> certainly not slow enough to be annoying to me anyway
[06:20] <NCommander> StevenK, or willing to roll roughly 12-14 packages to hardy-proposed?
[06:20] <NCommander> (I can give you debdiffs)
[06:20] <avb> unfortunately there is no better laptop then lenovo x61 in the world
[06:20] <avb> in other case i will have it
[06:20] <avb> :)
[06:20] <calc> things that annoy me are things like nautilus screwing up file timestamps on copies (setting them to current time)
[06:20] <avb> calc: try xterm :)
[06:21] <StevenK> NCommander: Eek!
[06:21] <calc> avb: loads in roughly the same time for me, gnome-terminal or xterm
[06:21] <Vger_> I prefer the Fujitsu T2010 than the X61 tablet though :P
[06:21] <Vger_> But I love my T61p
[06:21] <Vger_> Runs linux nicely
[06:21] <StevenK> calc: You know cp does that by default, right?
[06:21] <calc> StevenK: yea and cp can do something else if you tell it to, nautilus can't
[06:21] <NCommander> StevenK, is that a no?
[06:21] <avb> calc: once u have g-t opened, its pretty fast :)
[06:22] <RAOF> StevenK: Maybe; it's a tiny patch (basically telling the code generator that, yes, you get ownership of the Pixbuf returned from LoadIcon)
[06:22] <calc> and no other file manager on other OSes do that braindead stuff either
[06:22] <StevenK> NCommander: That's ... insanity
[06:22] <calc> avb: maybe that was the issue i already have it open for irc
[06:22] <avb> yeh
[06:22] <NCommander> StevenK, be happy, it was worse
[06:22] <avb> cold start is realy slow
[06:22] <NCommander> StevenK, four rebuilds, and eight patches to fix dependencies and one code change
[06:23] <calc> i think i managed to make it take 2s to load
[06:23] <StevenK> NCommander: For hardy-proposed?!
[06:23] <calc> then it was in cache when i quit it and it loaded in < 1s
[06:23] <NCommander> StevenK, we had a broken gnat package
[06:23] <NCommander> StevenK, so every Ada package is broken
[06:23] <NCommander> StevenK, the changes are minor, dependencies changes. Only two needed minor code changes to build
[06:23] <calc> the nautilus crap makes me have to manage all my files in gnome-terminal (yuck)
[06:23] <pwnguin> NCommander: so basically the risk of regression is best quantified "lol"
[06:23] <calc> but at this point its not really nautilus itself at fault aiui its the gvfs backends that are buggy now
[06:24] <NCommander> pwnguin, given the current packages are not even installable, I got to say regressions are nil
[06:24] <calc> it works properly on local filesystem now when i last tested it but still screws up on things like smb:
[06:24] <avb> calc: yeh. worm start is better. still i believe, that a lof of work should be done in pango and freetype
[06:24]  * NCommander can see StevenK shaking in his shoes
[06:24] <avb> coz im 80% sure that this is a problem
[06:24]  * StevenK isn't wearing shoes
[06:25] <NCommander> StevenK, figure of speech
[06:25] <avb> and another issue what i hate is an open dialog speed
[06:25] <avb> thats totaly unaceptable
[06:25]  * Hobbsee stomps on StevenK's bare feet then.
[06:25] <RAOF> NCommander: It's usually pronounced "Quaking in his little moonboots" :)
[06:26] <StevenK> Hobbsee: Ouch!
[06:26] <Hobbsee> avb: so, fix it?
[06:26] <NCommander> well, does anyone want to help if StevenK runs away in fear?
[06:26] <NCommander> ;-)
[06:26] <avb> Hobbsee: yeh, im going :)
[06:26] <avb> for now i just complaining for a bad life
[06:26] <avb> :)
[06:30] <avb> ok guys, was nice to talk, have a good day/night :)
[06:31] <avb> 2am, time to sleep
[06:34] <StevenK> TheMuso: So, why does libgtk2.0-dev Conflict against libgail-dev?
[06:35] <TheMuso> StevenK: The gtk+2.0 package in intrepid contains libgail's functionality.
[06:35] <StevenK> TheMuso: Ah ha.   Is there some technical reason why versioned provides don't exist, or is it just another possible feature waiting to be implemented in dpkg?
[07:12] <NCommander> StevenK, its anonying
[07:12] <NCommander> RAOF, I'm told the design of dpkg makes it difficult (I asked about that awhile ago)
[07:13] <NCommander> RAOF, but I'm honestly not sure
[07:13] <persia> RAOF: Consider the case where foo build-depends on bar >= 0.8 and baz 0.1 provides bar.  Should baz Provide bar-0.8?  what happens if something seeks bar-0.9?
[07:13] <NCommander> lamont, got some time to talk?
[07:15] <RAOF> persia: So you manually bump the version it provides, in much the same way as you'd currently bump the shlibs
[07:16] <RAOF> Specifically, the version of bar that baz provides is a piece of package metadata that is independent of the package version of baz.
[07:19] <persia> RAOF: OK.  I can accept that argument.  Now, check how dpkg handles versions and dependencies, and fix it :)
[07:20]  * RAOF is too suceptible to adding stuff to his TODO list.
[07:21] <RAOF> I was actually thinking: Hm... it's been a while since I've played C++.  Maybe I'll do that.
[07:22] <RAOF> With the one small problem that there's no way I'd get around to it!
[07:25]  * NCommander apt-get source's dpkg's source code
[07:25] <NCommander> persia, that being said, dpkg upstream been VERY difficult to work with to the point driving other contributors away
[07:26] <NCommander> (there was a massive funk on this on the d-devel mailing lists)
[07:26] <StevenK> Since when?
[07:27] <NCommander> StevenK, since at least the current maintainer took over. THere was a massive battle of egos on debian-devel
[07:27] <persia> NCommander: I refuse to believe anyone's assertion that another is difficult.  My experience has always been that human compatibility is not transitive
[07:27] <NCommander> I'm just summarizing what transpired on d-devel, which ended with an attempted hijack of dpkg
[07:28] <lamont> RAOF: given that package A and B have no relationship in version numbers (generally), having versioned provides becomes problematic if you want to describe versions in there
[07:28] <lamont> and besides, why make the build system more complicated than it needs to be, esp when you can say A | B (>=ver) ?
[07:29] <NCommander> lamont, it's more of an issue of transitional packages
[07:29] <lamont> NCommander: burning through email before heading to a meeting
[07:29] <NCommander> lamont, when xfce 4.5.80 was packaged, a versioned provides would have removed the requirement for transitional packages so Replaces would work
[07:29] <lamont> NCommander: certainly there are cases where versioned provides would be useful.
[07:29] <NCommander> (on the other hand, if there was a way to force Replaces to work even if there is no change to system state would be nice)
[07:29] <lamont> OTOH, that way lies madness. :)
[07:30] <NCommander> lamont, at some point, I'd like to talk to you on the topic of Ubuntu porting (as in porting to new architectures)
[07:30] <lamont> Replaces: doesn't do what you think it does then... .:-)
[07:30] <lamont> since it's purely a "if that package and I both provide the file, then I win
[07:30] <lamont> "
[07:30] <lamont> NCommander: ah, sure - in UK this week, which makes for some wonderful time slew
[07:31] <NCommander> Sorry, I'm thinking conflicts unless my memory is going
[07:31] <NCommander> Its 02:30 here
[07:31] <lamont> and pretty much putting in 14+ hour days between everything that's going on
[07:31] <RAOF> lamont: There would certainly be cases where versioned provides would break down, but for the fairly common case of "yes, I, libfoo really do provide a libbar interface compatible with >= 2.3" it'd be nice.
[07:31] <lamont> RAOF: yep.
[07:31] <NCommander> lamont, generally speaking, I have a desire to do a port of Ubuntu to either ppc64 or MIPS(el)
[07:31] <NCommander> RAOF, well, Breaks is a step in the right direction which at least removed the need for versioned conflicts
[07:32] <StevenK> I thought versioned Conflicts worked
[07:32] <RAOF> They do, don't they?
[07:32] <RAOF> Breaks is for a different purpose, AIUI
[07:32] <NCommander> StevenK, they do, but they are greatly depreciated by upstream
[07:33] <NCommander> (er, Debian)
[07:33] <NCommander> There is a mark in the latest policy guide not to use a versioned conflicts unless absolutely impossible to avoid, and to consider using Breaks instead
[07:33] <lamont> NCommander: steps (for your more simple case): 1) start with something older that works - say etch, 2) drop a build-essential chroot of etch on the machine, and start building toolchain bits for intrepid (or hardy, better yet), iterate until you've built everything in the chroot from the current release. 3) do it all over again starting with your results from (2).
[07:33] <NCommander> lamont, no, that part I know, I've done it before
[07:33] <lamont> NCommander: ah, cool
[07:33] <NCommander> lamont, I meant more the part on getting it on ports.u.c ;-)
[07:33] <lamont> ah...
[07:34] <NCommander> lamont, (I did a rebootstrap of amd64 out of total boredom from scratch; no debian)
[07:34]  * NCommander thinks he did four rebuilds
[07:34] <NCommander> before the result was installable
[07:35] <RAOF> That wasn't boredom though, was it?  That was build-the-world-with-PIE?
[07:35] <NCommander> RAOF, yeah well, when I got stuck, I spent five hours on a train doing that
[07:35] <NCommander> RAOF, so I had a general idea what to do if I could work out the toolchain issues
[07:35] <NCommander> I don't mind running dak or something, but if it was possible to get a port to be "blessed" with at least being hosted by canonical
[07:36] <lamont> that part is simple-ish: 1) work out with folks, and ship not less than 3 machines to the data center (4 preferred)  of course, you'll need to make sure that people believe in things enough to provide rack space and such for said machines.  2) work with the buildd guy (that'd be infinity) to point him at an archive for him to do the DC bootstrap from
[07:36] <NCommander> lamont, ouch, for ppc64, I guess I could send canonical four PS3s ;-)
[07:36] <StevenK> And rack them how?
[07:37] <RAOF> Under the TVs, surely.
[07:37] <NCommander> StevenK, someone made a rack for PS3 since they were doing cell work on them
[07:37] <StevenK> RAOF: And how many TVs have you racked? :-D
[07:37] <NCommander> StevenK, they made a mount so it could be placed in a U3 rack I think
[07:37] <RAOF> StevenK: 1!
[07:37] <lamont> 3U each? ouch
[07:37] <StevenK> RAOF: !?
[07:37] <lamont> OTOH, that beats 9+U
[07:38] <StevenK> lamont: What in the DC is 9+U?
[07:38] <NCommander> lamont, it was awhile ago
[07:38] <lamont> StevenK: besides the ciscos?
[07:38] <NCommander> lamont, anyway, I dont have $PS3_PRICE*4
[07:38] <StevenK> lamont: Yup
[07:38] <lamont> dunno - the tour hasn't happened yet
[07:38] <NCommander> lamont, I really really want armel, to the point having started that port before getting fed up with my slow as hell ARM box, and I'm told that one is getting done soon-ish
[07:40] <pitti> Good morning
[07:40] <StevenK> pitti!
[07:40] <pitti> NCommander: heh, ok
[07:41] <NCommander> pitti, we're working to fix the Ada packages on Hardy
[07:42] <StevenK> NCommander picked on me.
[07:44] <NCommander> StevenK, it could be worse
[07:49] <slangasek> StevenK: versioned conflicts work on an individual level.  When you get an archive full of them, your dist-upgrades look like "remove the world" if using apt-get, and "duh, I think you told me not to do anything" if using aptitude
[07:49] <StevenK> Haha
[07:52] <lamont> moof
[07:53] <lamont> NCommander: so.. you were saying?
[07:54] <lamont> hrm... actually time for me to head officewards - back online in about 15-20 min
[07:54] <NCommander> lamont, well, you explained it that Ubuntu must always host the buildd machines (I thought hppa for some reason was done outside at first)
[07:54] <lamont> it was
[07:54] <lamont> and hosted on people.ubuntu.com/~lamont/hppa/$mumble
[07:55] <NCommander> lamont, ah. I see. I figure at point I'll do the port, and then run a donation drive for the Canonical DC :-)
[07:56] <lamont> NCommander: yeah - it's best to get a port together and get a community behind it first, and then pursue getting it into the datacenter and such - a much easier path
[07:57] <NCommander> lamont, well, I plan to do an armel port if I don't see something before intrepid+1 opens, mostly because I want to do a netbook remix port for internet tablets
[07:57] <lamont> the other path is harder, and results in people asking why anyone should care about a port that maybe 6 machines in the world are using...
[07:57] <lamont> OTOH, 3 of those machines are buildds. :-)
[07:57] <NCommander> lamont, or the 20 m68k Debian buildd cluster
[07:57] <NCommander> (be warned, I will probably try and port Ubuntu to m68k ....)
[07:57] <lamont> s/20/70 or so/ last I heard
[07:57] <StevenK> Noooooooooooooooo
[07:58] <lamont> StevenK: he's welcome to try porting it.
[07:58] <StevenK> Damn doorstep architecture
[07:58] <NCommander> StevenK, yes, I do Ada and m68k
[07:58] <lamont> when it breaks, we'll laugh at him when he files bugs
[07:58] <lamont> anyway.  afk for 20 min or so
[07:58] <StevenK> Haha
[07:58] <NCommander> StevenK, I fix everyones FTBFS, in retrospect, its not that big of a quirk
[08:02] <wgrant> pitti: Isn't there a more feasible solution for keeping virtualbox unbroken in hardy? Say, adding a rebuild of the modules to the ABI bump process? Not that hard...
[08:04] <pitti> wgrant: that would require the kernel team to "adopt" the package
[08:05] <wgrant> pitti: For very restricted values of "adopt".
[08:06] <wgrant> Alternatively, there could be a more sane SRU process for kernel module rebuilds, and the appropriate maintainers could be notified of ABI bumps before the world breaks.
[08:06] <NCommander> wgrant, you do know virtualbox has a setup script to do extactly that?
[08:06] <NCommander> (/etc/init.d/vboxdrv setup)
[08:07] <wgrant> NCommander: We have packages as well.
[08:07] <NCommander> We do?
[08:07] <NCommander> That's news
[08:07] <wgrant> Yes.
[08:07] <wgrant> virtualbox-ose-modules-*
[08:08] <wgrant> DKMS is the ideal solution, but that luxury is not had in Hardy.
[08:08] <NCommander> wgrant, DKMS just got backported
[08:08] <NCommander> wgrant, maybe as an exception it can be introduced as a new package via -updates
[08:09] <wgrant> I don't really think that rewriting a package is ideal for an SRU.
[08:11] <NCommander> wgrant, I don't know anything about DKMS, I was just suggesting
[08:18]  * lamont returns
[08:18] <lamont> dear gnome keyboard, if I suspend the laptop for 20 minutes, that should _SO_ count as a break. kthx
[08:20] <superm1> someone still needs to DKMSify the intrepid virtualbox package anyhow too
[08:21] <RAOF> Heh.  The break's not for you, it's for GNOME.  And as far as it's concerned, no time has passed!
[08:21] <lamont> meh. ntp snapped time forward - that's time passing
[09:23] <RAOF> TheMuso: Hm.  Pulse seems to die trying to load module-esound-protocol-unix.
[09:24] <RAOF> pulseaudio -vvv doesn't seem to be terribly verbose about the problem.  I wonder if it's the missing link to libauth-cookie.so that ldd can't find?
[09:31] <NCommander> lamont, have you returned?
[09:31] <pochu> dholbach: thanks for the sponsorship!
[09:31] <NCommander> dholbach, how much do you know about SRUs?
[09:31] <seb128> NCommander: oh you are hiding now?
[09:31] <NCommander> seb128, after I blew away ~, yes
[09:31] <seb128> NCommander: SRUs are described on the wiki
[09:31] <NCommander> seb128, er, I need someone to sponsor SRU uploads to -proposed
[09:31] <seb128> NCommander: oh? how did you do that?
[09:32] <seb128> NCommander: bug #nnnn?
[09:32] <NCommander> seb128, didn't check to make sure my backup was actually readable
[09:32] <NCommander> seb128, its one bug, 11 packages
[09:32] <seb128> what are the changes about?
[09:32] <NCommander> seb128, Hardy shipped with gnat-4.2 which broke most of the ada packages in Hardy
[09:33] <NCommander> Mostly because the previous maintainer hardcoded gnat-4.1 all over the place
[09:33] <lamont> NCommander: yeah, sitting in a meeting
[09:33] <NCommander> I fixed the dependencies, and added code patches to get the rest building
[09:33] <NCommander> (its relatively small changes all around)
[09:33] <seb128> NCommander: do you have a bug number describing the changes, etc?
[09:33] <NCommander> seb128, there is a spec on the wiki that was approved by a member of motu-sru, I did the work with his approval, but he hasn't been on in awhile, and I'd like to at least get these into proposed
[09:34] <NCommander> seb128, https://wiki.ubuntu.com/HardyGnatTransition
[09:34] <seb128> NCommander: did you read https://wiki.ubuntu.com/StableReleaseUpdates ?
[09:35] <NCommander> seb128, yes, all packages have proper X.1 versioning strings
[09:35] <seb128> NCommander: need a bug explaining the changes, etc before uploading, I'm fine doing sponsoring if you have the bug open, the debdiff attached, etc
[09:35] <NCommander> seb128, hold on
[09:35] <NCommander> seb128, I was told by SRU however for binary rebuilds on packages that don't have an ubuntu version string to use Xbuild0.X
[09:35] <seb128> NCommander: right, "build" means it'll be overwritten by syncs automatically
[09:36] <NCommander> seb128, yeah, its two binaries rebuilds, and nine minor patchs
[09:36] <NCommander> seb128, https://bugs.edge.launchpad.net/ubuntu/+bug/268260
[09:36] <NCommander> gnat-gps is a rather odd issue
[09:36] <NCommander> It's got a major policy violation in it as of right now (in hardy), it doesn't follow the python policy at all
[09:37] <NCommander> I can fix it, but its a very invasive change since I need to do some heavy patching to the build system to fix it
[09:38] <seb128> NCommander: alright, let's word it differently, when you have a task for a package update and a debdiff closing this task ready to upload attached to the bug I'll review and sponsor it
[09:38] <NCommander> seb128, so you want me to attach all 11 debdiffs to these bugs?
[09:38]  * NCommander has already rerolled the source packages w/ proper versioning strings so its not that difficult
[09:38] <seb128> NCommander: SRU uploads require paper work, proper tagging, testing, etc so yes, read the wiki page if you didn't
[09:39] <seb128> NCommander: we need to be able to review updates and track which ones have been tested, etc
[09:39] <NCommander> seb128, I've done SRUs before, but never did them inmass, I was under the impression if its a single issue affecting multiple packages a single bug will do
[09:39] <NCommander> Let me fix that now then
[09:40] <NCommander> seb128, do I need to discuss tag creation on the lists?
[09:40] <seb128> NCommander: each package needs to be tested though
[09:40] <seb128> NCommander: what tag? no, you are free to use tags as you want
[09:41] <NCommander> Ok
[09:41] <NCommander> Launchpad doesn't have a link-bugs feature, does it
[09:43] <NCommander> seb128, it should be noted in advance some of these packages depend on each other, I'll try to note the order of what depends on what
[09:46] <NCommander> seb128, https://bugs.edge.launchpad.net/ubuntu/+source/asis/+bug/268458
[09:59] <ogra> \sh, bah, you stole my idea blogging the duerer drawing :)
[10:14] <NCommander> seb128, https://bugs.edge.launchpad.net/ubuntu/+source/libaws/+bug/268260 - this is quickly becoming the bug from hell
[10:14] <seb128> NCommander: that's alright, but since I've already lot to do and those are universe I'm pondering letting the sponsoring to MOTUs ;-)
[10:18] <stefanlsd> seb128: whats your feelings on getting the 2.5.1 pidgin into intrepid. couple of people have been using my PPA and reported no problems.  Or will we rather wait for debian?
[10:19] <seb128> stefanlsd: no feeling I'm overworked and didn't have time to look at it yet, still working on the GNOME 2.23.n updates
[10:20] <stefanlsd> seb128: oki.  tell them to not work you so hard  :)
[10:21] <\sh> ogra:  ;)
[10:28] <asac> Riddell: http://paste.ubuntu.com/45232/
[10:28] <asac> any idea?
[10:29] <pitti> tseliot: any chance you could do a proper release of x-kit (or use the current version) and put the tarball on launchpad.net?
[10:30] <pitti> tseliot: e. g. look at https://edge.launchpad.net/jockey, there you have the 'trunk' series, various releases from that, and "downloads"
[10:30] <NCommander> asac, that's pretty
[10:31] <pitti> tseliot: I updated README.txt for s/guidance/xkit/ and need to put in a download URL
[10:31] <tseliot> pitti: sure
[10:32] <pitti> tseliot: if you register the 'trunk' series and make it the 'default' series, then "bzr get lp:x-kit" would start to work, too
[10:33] <pitti> (I think you still have to link the branch against the series for that, though)
[10:33] <tseliot> pitti: something like this? https://launchpad.net/xorgparser/0.3
[10:33] <pitti> oh, it's xorgparser, not x-kit?
[10:33] <pitti> I looked at https://edge.launchpad.net/x-kit
[10:34] <tseliot> pitti: no, x-kit is the whole project
[10:34]  * NCommander falls
[10:34] <NCommander> seb128, ok, bug report from hell filled out
[10:34] <tseliot> pitti: and BTW you can do bzr branch lp:xorgparser
[10:34] <pitti> tseliot: right, I tried with x-kit, since the source package is x-kit, too
[10:35] <tseliot> pitti: yes, that's the only part of X-Kit which I have released so far
[10:35] <tseliot> pitti: I know, it's a bit confusing
[10:35] <pitti> ok, nevermind
[10:36] <pitti> I put in https://launchpad.net/xorgparser/+download as download URL
[10:36] <pitti> tseliot: I fully reviewed your x-kit branch, fixed another bug (in disable() you changed the indentation of xorg.conf writing, which caused it to be written only if there previously was a device section)
[10:37] <tseliot> pitti: how do I put a tarball in that link?
[10:37] <tseliot> pitti: ah
[10:37] <pitti> tseliot: https://edge.launchpad.net/xorgparser/trunk, click on 'register a release'
[10:38] <pitti> oh, there is already one for 0.3: https://edge.launchpad.net/xorgparser/0.3
[10:38] <pitti> tseliot: on that page you shold have "add download file" or so (I can't see it since I'm not the project owner)
[10:39] <pitti> yep, that's where i see it in jockey, so it should be there for you
[10:39] <NCommander> hey TheMuso
[10:39] <pitti> tseliot: chasing the test regressions now
[10:40] <tseliot> pitti: ok, I'll do a release so that your link can actually work.
[10:40] <pitti> tseliot: many thanks
[10:40] <tseliot> pitti: good, if you need a hand with that, I'm here
[10:45] <RAOF> Yeah.ls
[10:45] <RAOF> ENOTSHELL
[10:46] <RAOF> You know, it'd be cool if irssi silently ignored shell commands :X
[10:46] <Riddell> asac: mm, no, where's the admin directory from?
[10:46] <asac> Riddell: from knetworkmanager svn
[10:47] <asac> Riddell: let me check something
[10:48] <Riddell> asac: fresh checkout and make -f Makefile.cvs works fine here
[10:48] <asac> Riddell: yeah. most likely because build-dep doesnt succeed to install
[10:48] <vovkav> hi! What is the easiest way to profile the entire linux system with large granularity? Just to see how much time is spent in kernel-libc-libxxx-apllication?
[10:48] <asac> Riddell: dpkg: error processing /var/cache/apt/archives/kdelibs4-dev_4%3a3.5.10-0ubuntu1_amd64.deb (--unpack): trying to overwrite `/usr/bin/ksvgtopng', which is also in package kdebase-runtime
[10:49] <asac> Riddell: is kdebase-runtime old and there is a missing conflict?
[10:49] <Riddell> asac: ksvgtopng should be removed from kdelibs4-dev (and has been but there's a compile error)
[10:49] <Riddell> asac: you can safely --force-overwrite
[10:49] <asac> Riddell: ok
[10:50] <asac> i removed kdebase-runtime now ... apparently didnt hurt. now i have all build-deps. lets try
[10:50] <asac> Riddell: all find. sorry for the noise ;)
[10:50] <asac> fine
[10:51] <Riddell> yay
[10:54] <asac> Riddell: now it bailed out with:
[10:54] <asac> knetworkmanager-openvpn.h:34:39: error: knetworkmanager-vpnplugin.h: No such file or directory
[10:55] <vovkav> hi! What is the easiest way to profile the entire linux system with large granularity? Just to see how much time is spent in kernel-libc-libxxx-apllication?
[10:57] <wgrant> Hmmmm. My laptopload cycle count
[10:57] <wgrant> Er.
[10:57] <wgrant> My laptop's load cycle count has just started increasing rather rapidly.
[10:57] <NCommander> wgrant, would you like to help me upload some packages :-)
[10:58] <wgrant> NCommander: I'm rather busy with uni work, sorry.
[10:58] <NCommander> wgrant, Sure, no issue. I just need to find someone who likes doing SRU work :-)
[11:00] <Riddell> asac: are you doing builddir!= sourcedir?
[11:00] <asac> Riddell: huh?
[11:00] <asac> Riddell: i used the commands you gave me
[11:00] <asac> and ran make in the same directory
[11:01] <asac> ./configure --prefix=...
[11:01] <asac> Riddell: should i do something else?
[11:02] <kwwii> asac: is there any way that Firefox could use a different skin when the gnome theme changes?
[11:03] <Riddell> no, that should be fine
[11:03] <asac> Riddell: config.status:s,@KNETWORKMANAGER_CFLAGS@,|#_!!_#|-I$(top_srcdir)/src,g
[11:03] <asac> looks ok
[11:03] <asac> Riddell: hmm
[11:04] <lool> Blah my desktop hung up again and nothing in the logs
[11:05] <asac> kwwii: what are you trying to achieve?
[11:06] <asac> kwwii: fix theme bugs in a skin?
[11:07] <cjwatson> asac: re yesterday, indeed both interfaces have been given the same metric. I attached stuff to bug 262152
[11:08] <asac> cjwatson: ok thanks. would a fixed metric be good enough to fix your use-case?
[11:09] <kwwii> asac: well, I have other themes which need a skin to look right...the idea is that when I select the theme firefox should also look ok without having to select the theme everywhere
[11:11] <asac> kwwii: yes i understand.
[11:11] <asac> kwwii: but no, changing skin on theme change doesnt work
[11:11] <asac> kwwii: can you identify which elements are not configurable in gnome theme?
[11:12] <asac> i think the right approach is to look if those can be made configurable
[11:13] <cjwatson> asac: I just tried fiddling the routing table and that doesn't seem to help
[11:14] <cjwatson> asac: I think the problem might be that (if you look at the routing table I attached) I still need to use hosts on the wireless subnet, but I would prefer to do so via a wired route when an Ethernet cable is attached; for example my nameserver is <IP_ADDRESS>
[11:14] <Riddell> asac: meh, it compiles for me whatever I do
[11:14] <asac> cjwatson: metrics worked quite well in the past for me
[11:14] <asac> cjwatson: oh. so its not a packet loss issue
[11:14] <kwwii> asac: until now the biggest problem is the url entry box and teh menu that drops down from it I think
[11:15] <cjwatson> asac: well, it is though. When I have both interfaces up, packets sent to <IP_ADDRESS> don't come back
[11:17] <cjwatson> asac: oh, sorry, ignore that last bit, I screwed up
[11:17] <asac> cjwatson: from what i see your routing table only has one default route
[11:17] <asac> so there shouldnt be any metric required
[11:17] <cjwatson> asac: hm, should I have a default route for eth1? I'd rather not - eth0 can get to every host that eth1 can
[11:18] <cjwatson> and the less I use wireless, the better wireless works for those hosts that need it
[11:18] <asac> cjwatson: right. thats correct
[11:18] <cjwatson> (I'm on the edge of the tolerances for my router)
[11:18] <asac> cjwatson: and if NM behaves that way i dont see what is wrong
[11:18] <cjwatson> right now, this ssh connection to <IP_ADDRESS> is going via wireless
[11:18] <asac> ah
[11:19] <cjwatson> oh, hmm, metrics are the other way round from what I was thinking, aren't they?
[11:19] <cjwatson> the higher the metric, the less the link will be used
[11:19] <asac> yes
[11:19] <asac> cjwatson: but that only works if there is a tie-break required
[11:20] <asac> so maybe <IP_ADDRESS>    <IP_ADDRESS>         <IP_ADDRESS> U     0      0        0 eth1
[11:20] <asac> just pulls in everything for that subnet
[11:21] <cjwatson> asac: yeah, it seems to
[11:21] <cjwatson> I bumped that metric to 10, but it still wins
[11:21] <asac> cjwatson: did you explicitly setup this subnet split in your dhcp servers?
[11:21] <cjwatson> yes
[11:23] <asac> cjwatson: what were the reasons to make wireless serve a different internal subnets?
[11:23] <asac> and why is the dns server in the wireless net?
[11:23] <cjwatson> I have a strange setup because I have a wireless router downstairs, and have never got round to running a wire upstairs so the machine that I actually want to use as a default router and DNS server (because it understands VPNs and the like) is connected to the rest of the world by wireless
[11:23] <cjwatson> it's backwards from most people's, but it's necessary until I get round to more physical layer work
[11:25] <cjwatson> the different subnets gave me control that I found I needed to make it all work; and it did work fine until n-m came along and decided it could have both interfaces up at once :)
[11:25] <asac> cjwatson: ok. just wanted to ask if the subnets split is really required
[11:25] <cjwatson> for now, yes
[11:26] <cjwatson> oh, plus I understand subnetting better than I understand Ethernet bridging; I prefer that sort of thing to be explicit :)
[11:27] <cjwatson> I suspect that, in general, with a crowded wireless network that's having trouble coping at the best of times, subnetting puts less load on it than bridging would
[11:28] <cjwatson> since the wireless network only needs to see packets definitely destined for it
[11:30] <asac> cjwatson: ok. ill show that routing table to the NM master and see what he thinks. i doubt however that this is the "use-case" he asked for to convince him to introduce an "old" mode feature
[11:30] <asac> or to add more complexity to the UI.
[11:31] <asac> cjwatson: you can certainly disable your wireless network by right clicking ;)
[11:31] <Riddell> asac: oh, I have network-manager-kde installed and it's using the knetworkmanager-vpnplugin.h from that
[11:31] <asac> but i see that this might be cumbersome
[11:31] <cjwatson> it sucks
[11:31] <cjwatson> asac: it shouldn't be looked at as an "old" mode. This is a regression
[11:32] <asac> cjwatson: i agree that his arguments arent really consistent
[11:33] <asac> cjwatson: a) he always says that NM is only useful for managing your primary network connection
[11:33] <asac> b) he says that he doesnt see the case for the 0.6.6 behaviour.
[11:33] <asac> but lets see.
[11:33] <asac> maybe this can convince him
[11:34] <asac> Riddell: ok ;)
[11:35] <asac> Riddell: so top_srcdir is wrong?
[11:36] <Riddell> yes
[11:36] <asac> Riddell: http://paste.ubuntu.com/45256/
[11:37] <asac> ?
[11:37] <Riddell> asac: yep
[11:37] <asac> Riddell: ok that fixes that
[11:37] <asac> Riddell: now i end up in http://paste.ubuntu.com/45257/
[11:37] <asac> Riddell: can you commit that fix?
[11:38] <cjwatson> asac: I want NM to manage my primary network connection. It's just that depending on the situation that might be one of two interfaces. This isn't unusual, is it?
[11:38] <cjwatson> in fact I thought that was NM's core usefulness
[11:38] <liw> isn't that the case for every laptop with both wired and wireless?
[11:38] <asac> cjwatson: right. Ill talk directly to dan about this as soon as he is online
[11:39] <asac> cjwatson: i only talked to his co-worker about this last time
[11:39] <cjwatson> thanks
[11:39] <asac> who mostly knows what dan williams wants ... but only mostly
[11:43] <asac> Riddell: so whats the right/outdated signature? the one in vpnplugin.h or in openvpn.cpp ?
[11:49] <Riddell> asac: that's the question, upstream left it between the two
[11:50] <Riddell> asac: I think QMap<QString, QString> is the new one
[11:53] <Riddell> asac: yes, according to r848503 'Again NM API changes (breaks all VPNPlugins)'
[11:55] <asac> Riddell: good. so he forgot openvpn
[11:56] <asac> lets see if i can temporarily disable it
[11:58] <tkamppeter> pitti, hi
[11:58] <Riddell> asac: try  --with-openvpn=no
[11:59] <Riddell> to ./configure
[11:59] <asac> Riddell: int OpenVPNConnectionType::mapConnectionType2String(CONNECTIONTYPE connType)
[11:59] <asac> hehe
[11:59] <asac> confusing function name
[12:16] <TheMuso> RAOF: Hrm. The module should be present in /usr/lib/pulse-0.9/modules. Got any more info, or have you attached it to the bug already?
[12:22] <TheMuso> RAOF: ah, you emailed me, thanks.
[12:33] <asac> Riddell: ok enabling/disabling wireless works
[12:34] <asac> Riddell: how knetworkmanager supposed to work? i dont see any APs in the applet drop down
[12:36] <asac> Riddell: is there a way to make knetworkmanager more verbose?
[12:36] <Riddell> asac: right click -> edit connections -> new connctions -> a list should be there
[12:36] <asac> Riddell: yeah. that exists
[12:36] <asac> Riddell: but activating such a connection doesnt do anyhting
[12:37] <asac> but i dont see any error on the console either
[12:37] <asac> (nor anything on NM side)
[12:43] <Riddell> asac: I don't think it has much in the way of debug output
[12:44] <ogra> asac, so if i run a dhcp server on my desktop machine (i.e. on ltsp servers) i see some issues ... could it be that NM starts the static interfaces from /e/n/i very late in the bootprocess ?
[12:44] <Riddell> asac: do you have anything listed in the New Connections dialogue?
[12:48] <asac> Riddell: yes. thats all working
[12:49] <asac> Riddell: what isnt working is the "ActivateConnection" dbus call. i get the callback, but i am not sure where the signal emitted there is dealt with
[12:50] <asac> Riddell: emit ActivateConnectionAsyncReply(_asyncCallId, _active_connection);
[12:50] <asac> Riddell: who is listening for that?
[12:50] <TheMuso> ogra: Did you get my message earlier about your casper changes and a bzr branch? You had a different nick, so you may not have.
[12:51] <ogra> no, i didnt
[12:54] <TheMuso> ogra: Oh ok. Was just wondering whether you had your changes somewhere in a bzr branch so I can merge them back into trunk, as Colin gave me a tarball of what he had as the latest bzr branch.
[12:54] <TheMuso> ogra: It would be nice to have them logged properly, instead of something like "merge changes back from oliver" :p
[12:55] <ogra> the casper branches i looked at were all broken
[12:55] <ogra> and nobody could tell me where the actually used branch is
[12:55] <TheMuso> ogra: Yeah, but I think its possible to push to if you have a local copy.
[12:55] <Riddell> asac: nothing (according to grep)
[12:56] <TheMuso> i could be wrong though
[12:56] <Riddell> asac: the whole of src/dbus/ files seem to be new since the current version in the archive
[12:56]  * TheMuso discovers that Colin hasn't actually pushed his casper changes to LP...
[12:57] <ogra> TheMuso, right, there is something wonky wiht the casper branch ... some error in importing from the old bazaar
[12:57] <TheMuso> yeah I know
[12:58] <ogra> and indeed i use to make my changes in a local copy via bzr pull ... but pushing that didnt work
[12:58] <ogra> i think i have the debdiff lying around somewhere, so it shouldnt be hard to generate something out of that for a time where the branch is fixed
[12:59] <TheMuso> ogra: Getting the debdiff is no problem.
[13:06] <cjwatson> TheMuso: hmm, I haven't? oh well, you have the branch, you can push it
[13:06] <ogra> cjwatson, wjere to  ?
[13:06] <ogra> *where
[13:06] <ogra> i wasnt able to push to the ones i found on LP
[13:07] <TheMuso> cjwatson: Right, I thought it was a case of tried, but failed.
[13:08] <cjwatson> ogra: I've been able to commit to the branch on LP OK
[13:08] <ogra> hmm
[13:08] <ogra> weird
[13:08] <cjwatson> the branch is screwed, though; not an LP problem as such
[13:08] <ogra> i know i tried to push to the one owned by ubuntu-core-dev
[13:08] <ogra> and that didnt work
[13:08] <cjwatson> don't fret too much about it
[13:09] <asac> Riddell: yeah. ill look into it
[13:09] <ogra> well, i dont want my changes being lost  :)
[13:09] <asac> Riddell: first step is updating the introspection files ... which also should reveal the actual api changes required
[13:09] <ogra> in case someone only uses the branch and not the source package
[13:10] <cjwatson> https://bugs.edge.launchpad.net/bzr/+bug/246880 is as far as I've got
[13:20]  * TheMuso subscribes to that bug.
[13:20] <ogra> kwwii, did you notice that the gnome-control-center shell app has a hardcoded white background ?
[13:20] <lool> cjwatson: Should the current trunk be moved on the side (or shall we move to a new branch) to continue development in bzr and keep the data for bzr's upstream to look at later?
[13:21] <ogra> kwwii, its very hard to read the golden fonts on it in the dark human theme
[13:21] <TheMuso> lool: I was thinking of the same thing, but haven't bothered because I haven't had to touch casper till now.
[13:22] <cjwatson> lool: that's an option, but I've escalated to poolie now, let's try to exhaust that first
[13:22] <lool> cjwatson: Thanks
[13:23] <cjwatson> lool: if we do get stuck I could use bzr fast-import to give us all the history at least since we switched to bzr
[13:23] <cjwatson> it'd break any existing branches of course but since the trunk is screwed there are hardly any of those
[13:33] <seb128> NCommander: new pangomm and gtkmm versions available
[13:57] <pitti> hi tkamppeter
[14:21] <MacSlow> Anybody with an intel Pro/Wireless 3945ABG wlan-nic working under interpid (2.6.27-2-generic)?
[14:22] <Riddell> mvo: update-manager bzr seems out of date with the archive
[14:22] <Riddell> MacSlow: lspci tell me I have  03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection
[14:22] <Riddell> MacSlow: works here with 2.6.27-2-generic
[14:23] <MacSlow> Riddell, *sigh*
[14:23] <Riddell> MacSlow: not using knetworkmanager are you? :)
[14:23] <MacSlow> Riddell, I only have it working for about 1 minutes and then get numerous timeouts of the iwl3945 modules reported in the output of dmesg
[14:24] <MacSlow> Riddell, correct I'm not running knetworkmanager :)
[14:24] <Riddell> no timeouts in my dmesg
[14:26] <MacSlow> Riddell, there's also not much showing up in reported bugs in launchpad ... I guess I'm once again the only person being exposed to this problem
[14:26] <mvo> Riddell: oh?
[14:26] <mvo> Riddell: let me check
[14:27] <mvo> Riddell: fixed, sorry
[14:28] <Riddell> mvo: glad it's not just me who does that :)
[14:32] <mvo> Riddell: heh :)
[14:33] <Riddell> mvo: I'm adding the midding update-notifier-kde.install file then uploading
[14:33] <Riddell> missing
[14:33] <mvo> Riddell: cool, thanks. I will probably do another upload today but I need to wait on niemeyer first
[14:34] <Riddell> mvo: then I'll just commit and not upload
[14:43] <ogra> cjwatson, hibernate to /dev/ramzswap is disabled, right ?
[14:43] <ogra> (the compcache device)
[14:44] <cjwatson> ogra: I don't remember doing anything explicit there
[14:44] <ogra> oh, i thought you said that back at UDS even
[14:44] <cjwatson> ogra: ... but apparently I'm just forgetful. Yes, it is disabled.
[14:44] <ogra> ok
[14:44] <cjwatson> oh, wait, looking in the wrong place
[14:45] <cjwatson> ogra: drat. No, it isn't, but will be in just a moment
[14:45] <cjwatson> (base-installer works that stuff out)
[14:45] <ogra> good :)
[14:46] <ogra> there was just a question how it affects hibernate and i couldnt remember if we actually did have it disabled
[14:46] <cr3> cjwatson: your fix to dpkg enabled the automated testing to kick in again, thanks!
[14:47] <jdstrand> cjwatson: hi! fyi, ufw and netboot d-i should be in good shape now
[14:48] <jdstrand> cjwatson: I had a thought about integrating ufw into the installer. something along the lines of redhat's 'Enable firewall' with some rudimentary ports stuff. Is this something that you would be open to for intrepid+1?
[14:50] <cjwatson> cr3: I didn't touch dpkg; you can thank jdstrand for his ufw fix
[14:50] <cr3> jdstrand: ^^^ thanks :)
[14:51] <jdstrand> cr3: heh, well, you can also blame me for the breakage... but your welcome! :)
[14:53] <cr3> jdstrand: I don't blame breakage, these things happen during development :)
[14:59] <siretart> does the ubuntu live cd autoload the kernel module dm_mod?
[15:03] <emgent> happy network manager!
[15:03] <emgent> Program received signal SIGSEGV, Segmentation fault.
[15:03] <emgent> [Switching to Thread 0xb6f81730 (LWP 6857)]
[15:03] <emgent> 0xb7f17545 in ?? () from /usr/lib/libnm-util.so.0
[15:04] <stefanlsd> emgent: :)
[15:04] <emgent> heya stefanlsd :)
[15:05] <emgent> i have to go out now, see you later people
[15:10] <lool> siretart: Last time I checked it didn't do so for me
[15:11] <jdstrand> hi emgent!
[15:11] <lool> siretart: I wanted to mount my lvm over md, I'm not sure how I solved it in the end; something like installing mdadm and lvm2 (the later probably installed), then udevadm trigger, then vgscan or something like that
[15:24] <cjwatson> ogra: base-installer and ubiquity fixed so that /dev/ramzswap won't be selected for hibernation (at least after the next ubiquity upload)
[15:26] <ogra> cjwatson, gracias :)
[15:27] <siretart> lool: k, thanks
[15:31] <tkamppeter> pitti, hi
[15:31] <pitti> hey tkamppeter
[15:33] <tkamppeter> pitti, bzr pull --remember bzr+ssh://bzr.debian.org/pkg-cups/cups/debian-trunk/ does not accept my password
[15:34] <cjwatson> tkamppeter: is your Launchpad user name the same as your local user name?
[15:34] <cjwatson> tkamppeter: if not, you want this in ~/.ssh/config:
[15:34] <cjwatson> Host bazaar.launchpad.net
[15:34] <cjwatson>         User till-kamppeter
[15:34] <tkamppeter> pitti, Launchpad account or alioth (Debian) account?
[15:34] <pitti> cjwatson: it's bzr.debian.org
[15:35] <cjwatson> ... I'll shut up then - although the same principle applies
[15:35] <tkamppeter> I tried also bzr pull --remember<EMAIL_ADDRESS>[15:35] <tkamppeter> but I got
[15:35] <pitti> tkamppeter: if you didn't set your alioth name in .ssh/config, try<EMAIL_ADDRESS>[15:35] <cjwatson> I'm not sure that bzr.debian.org runs a smart server. Try sftp:// rather than bzr+ssh://.
[15:35] <pitti> cjwatson: I use<EMAIL_ADDRESS>WFM
[15:36] <lool> tkamppeter: Try to ssh<EMAIL_ADDRESS>[15:36] <tkamppeter> pitti, this is what I tried. I got asked for the password, entered it, and got
[15:36] <tkamppeter> Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
[15:36] <pitti> tkamppeter: right, but that's just a warning, I get it, too
[15:36] <pitti> bzr.d.o just has bzr 1.3
[15:36] <tkamppeter> Then I got asked for the password again, entered it and got
[15:37] <tkamppeter> bzr: ERROR: Not a branch<EMAIL_ADDRESS>[15:37] <pitti> which doesn't help to make it faster :(, but for political reasons I didn't put the debian bzr trunks onto LP (just a mirror)
[15:37] <lool> tkamppeter: I use /bzr
[15:37] <jcristau> tkamppeter: bzr.d.o/bzr/pkg-cups/...?
[15:37] <lool> tkamppeter: Right you need a /bzr
[15:37] <lool> bzr branch bzr+ssh://bzr.debian.org/bzr/pkg-cups/cups/debian-trunk
[15:37] <jcristau> tkamppeter: /pkg-cups doesn't exist
[15:37] <lool> Worked for me
[15:37] <lool> Branched 543 revision(s).
[15:37] <pitti> ah, indeed
[15:38] <lool> tkamppeter: You might to run a ssh agent to avoid typing your passwords over and over again (or better use ssh keys)
[15:39] <broonie> Well, you need the keys for the agent anyway.
[15:40] <lool> uh right, I meant to present things the other way around
[15:40] <lool> Anyway, use an agent, use keys, if possible use passwords on your keys :)
[15:42] <tkamppeter> lool, I have upoaded my key to Alioth now.
[15:42] <asac> StevenK: so NM how do you know that its nm-applet that kills your X?
[15:42] <lool> tkamppeter: dumped hourly or so, might take some time to be up-to-date
[15:46] <StevenK> asac: Because I click the applet and then X dies.
[15:46] <tkamppeter> pitti, now I succeeded. I have broken it by a "bzr upgrade", but now I have deleted everything and I am starting over.
[15:46] <pitti> tkamppeter: broken? upgrade doesn't work, due to its history of being a svn import, but it just fails, doesn't break
[15:46] <pitti> tkamppeter: but good
[15:47] <tkamppeter> pitti, can you make a new announcement, with correct paths and telling the users about the warnings?
[15:47] <pitti> yes
[15:53] <tkamppeter> pitti, I have uploaded the last change (patch from ion_ for bug 263049) to the bzr now. I had already uploaded it to SVN, but it seems that you had already converted the SVN before.
[15:54] <pitti> tkamppeter: oh, thanks
[15:55] <ion_> Converted?
[15:55] <tkamppeter> pitti, another question: I have always built CUPS by running svn-buildpackage from within the SVN repo directory. Is there an equivalent for bzr?
[15:55] <ion_> bzr-buildpackage :-)
[15:55] <pitti> tkamppeter: what ion_ said, but I have never used either so far
[15:55] <pitti> tkamppeter: I just use debuild
[15:56] <tkamppeter> pitti, does debuild also join the debian directory from the repo with the original source or do you do that manually?
[15:56] <pitti> tkamppeter: no, I just unpack the orig.tar.gz into the source tree, just as with normal source packages
[15:56] <pitti> debclean works :)
[15:57] <pitti> but I should really try bzr-buildpackage some day
[15:57] <ion_> By default, git-buildpackage refuses to build a source package if the tree contains uncommitted changes, which quite nicely prevents accidental uploads of local changes. :-)
[15:57] <tkamppeter> pitti, I am installing it now.
[15:57] <ion_> I assume bzr-buildpackage does that, too.
[15:58] <ion_> git-buildpackage has pristine-tar integration, which is teh awesome.
[15:58] <james_w> ion_: it doesn't, I had complaints about doing that
[15:59] <tkamppeter> ion_, I had uploaded you last patch to SVN, without knowing that the SVN got EOL hours before. Today pitti told me that he has moved to BZR and his BZR repo did not contain your patch. So it seems that pitti has moved shortly before I committed your patch.
[16:00] <pitti> tkamppeter: sorry, I am not allowed to change permissions on svn.d.o to lock down the svn repo
[16:00] <ion_> I can rebase the patch against the current bzr HEAD. If you have the bzr URL handy, please paste it. If not, i’ll look for it at launchpad myself.
[16:00] <pitti> tkamppeter: but if that happens, I can easily merge new svn changes into bzr trunk
[16:00] <siretart> pitti: perhaps a postcommit hook that always fails would do?
[16:02] <tkamppeter> pitti, ion_, the patch is already manually committed into the bzr repo. It was small and simple to commit.
[16:02] <ion_> Alright
[16:03] <asac> StevenK: clicking on applet also triggers a scan. so the "going down" might be the applet, but might also be the driver
[16:03] <asac> StevenK: is just X crashing? or the whole system?
[16:03] <tkamppeter> pitti, but the postcommit hook which siretart suggests is a good idea, as someone else could accidentally upload into the SVN black hole.
[16:03] <StevenK> asac: Ahh. X dies and comes back
[16:04] <asac> StevenK: when you log in, first thing: killall nm-applet
[16:04] <asac> StevenK: then when thats gone, start it from the console and capture stderr/stdout
[16:04] <asac> maybe we can see something
[16:04] <pitti> tkamppeter: well, it's not a black hole, we'll get commit mails
[16:04] <ion_> https://code.edge.launchpad.net/~pitti/cups/debian-trunk ?
[16:04] <asac> OR run it under a debugger ... which might catch the issue before X goes down
[16:04] <pitti> tkamppeter: in practice, the two of us are the only ones who commit nowadays
[16:05] <pitti> ion_: that's the mirror, yes
[16:05] <asac> StevenK: anyway. i cannot really see a reason why that might happen. nm-applet is quite a simple application UI wise :(
[16:05] <pitti> ion_: http://bzr.debian.org/bzr/pkg-cups/cups/debian-trunk/ is the master
[16:05] <asac> StevenK: do you use a custom theme?
[16:05] <asac> or are those the NM icons used in the main distro?
[16:09] <StevenK> asac: I think it's the normal icon
[16:09] <tkamppeter> pitti, ion_, I am currently building with "bzr-buildpackage --merge". fakeroot is used automatically, but to automatically get the source code from ../tarballs "--merge" needs to be supplied.
[16:09] <StevenK> asac: It could be the scan that's doing something odd.
[16:10] <tkamppeter> The result lands in ../build-area
[16:10] <StevenK> asac: Since iwlist scan returns nothing since the driver is horked
[16:10] <asac> StevenK: if the driver is as flaky as i think it is it could cause problems.
[16:10] <asac> but getting no results shouldnt be a big issue alone for nm-applet
[16:13] <ogra> StevenK, did you try to manually compile madwifi ?
[16:13] <ogra> for me on -generic on the Q1 it doesnt crash X with ath5K but doesnt connect either
[16:14] <tkamppeter> pitti, it does not build into the build-area, but into ..
[16:15] <tkamppeter> pitti, but it builds and installs fine.
[16:17] <tkamppeter> pitti, another question: You have added CUPS to the UFW: /etc/ufw/applications.d/cups
[16:17] <pitti> tkamppeter: jdstrand did, but yes, it's there (just for ubuntu)
[16:18] <tkamppeter> For CUPS only port 631 seems to be opened. Will it still be possible for CUPS and its backends to access ports 443, 631, 515, 139, and 9100?
[16:18] <tkamppeter> Will cups-lpd still be able to listen on port 515?
[16:18] <pitti> jdstrand: ^
[16:20] <tkamppeter> pitti, will you soon put cups 1.3.8-10 into Debian and Ubuntu? Or is there still something planned to be done?
[16:21] <pitti> tkamppeter: I was mainly waiting for ion_'s patch to land, which you just did
[16:27] <ogra> evand, lool proposed i should show you https://launchpad.net/usb-imagewriter .... its essentially a dd gui frontend and might make a good company for usb-creator (there are screenshots, though its functional it needs some improvement)
[16:27] <jdstrand> tkamppeter: all /etc/ufw/applications.d/cups does is add an application profile that users can use when adding rules to their rulesets. eg 'ufw allow Cups'. Nothing is done automatically and the firewall is not enabled by default
[16:28] <jdstrand> tkamppeter: that said, it sounds like adding additional profiles might be a good idea.
[16:28] <evand> ogra: neat
[16:29] <evand> noted
[16:29] <jdstrand> tkamppeter: the stance that is taken is not to add an appliation profile for every conceivable port that could be used, but only for the very most common
[16:30] <jdstrand> tkamppeter: eg, one might argue that cups-lpd doesn't need its own profile, because it is for compatibility and the admin likely knows she needs to open port 515
[16:30] <liw> evand, do you have a url handy for your usb image creator, if one wants to try it out? (I am going to re-install a machine in the relatively near future)
[16:30] <jdstrand> (and can do so (as always) with 'ufw allow printer'
[16:31] <jdstrand> (or 515/tcp, ...)
[16:31] <evand> liw: 0.1.2 is in universe, bzr at lp:~ubuntu-installer/usb-creator/trunk
[16:32] <liw> evand, oh, cool, thanks
[16:32] <evand> you will undoubtedly run into issues with device ordering and grub.  That will be fixed once I have UUID support in grub-installer.
[16:33] <jdstrand> tkamppeter: if you'd like to add additional profiles to /etc/ufw/applications.d, feel free to do so-- and I'd be happy to review/help in any way I can
[16:33] <evand> (the USB key will appear as the first disk during installation, making it the default target for grub as well as causing ordering issues once removed)
[16:35] <jdstrand> tkamppeter: if the profile that is in place is not appropriate for the default installation, please file a bug and assign it to me
[17:04] <dendrobates> pitti: any chance of promoting  smartpm and update-motd?  I really want to test landscape-client in the installer.
[17:06] <ion_> % apt-cache search landscape server
[17:06] <ion_> %
[17:07] <ion_> Is that going to change?
[17:09] <Adri2000> eh, I asked myself the same question when I noticed this package -- btw, I don't think the canonical ad in motd is a good idea
[17:11] <ion_> If not, i’ll stay a happy puppet user. :-)
[17:11] <dendrobates> Adri2000: we are working on softening that.
[17:11] <Adri2000> good
[17:12] <Adri2000> dendrobates: can landscape-client be used with something other than landscape.canonical.com?
[17:12] <dendrobates> Adri2000: yes you can write your own landscape-sysinfo modules.
[17:13] <dendrobates> Adri2000: the package is changing so it only installs the needed portions for that and not the entire client, as well
[17:14] <Adri2000> but can I write my own landscape.canonical.com from scratch, and use it to manage my ubuntu machines with landscape-client installed?
[17:14] <dendrobates> Adri2000: sure the client is gpl, you can do what ever you want.
[17:16] <Adri2000> ok
[17:21] <dendrobates> Riddell: any chance of promoting  smartpm and update-motd?
[17:22] <dendrobates> Riddell: for a kubuntu user.  :)
[17:39] <pitti> dendrobates: eww, we need smart in main?
[17:40] <davmor2> pitti: current cd builds are failing because of it :)
[17:40] <dendrobates> pitti: landscape-client requires it.
[17:40] <pitti> davmor2: that's a bug in the seeds then
[17:41] <davmor2> pitti: The following packages have unmet dependencies:
[17:41] <davmor2>                     Depends: update-motd but it is not installable
[17:41] <davmor2>   landscape-client: Depends: smartpm-core (>= 1.0) but it is not installable
[17:42] <dendrobates> pitti: the server daily iso's are building fine.
[17:43] <dendrobates> pitti: but the installer silent fails when you select landscape client.
[17:43] <pitti> uh, I even have landscape-client installed
[17:43] <pitti> why's that, are we going to ship the full package on the CDs?
[17:44] <dendrobates> yes, but we will only install the part needed to run landscape-sysinfo.  mathiaz is breaking up the package now.
[17:44] <pitti> I thought we'd ship only a stub, and customers would then activate Canonical's repo to get the real thing?
[17:44] <dendrobates> pitti: this is on server, desktop can do it's own thing.
[17:44] <Treenaks> pitti: is it known that lang-supp-writing-en is broken? or is that just my system misbehaving?
[17:45] <pitti> Treenaks: --verbose ?
[17:45] <Treenaks> pitti: great idea :)
[17:45] <Treenaks> uhr
[17:45] <superm1> is landscape-client going to be useful on most desktop systems?
[17:45] <pitti> superm1: no
[17:46] <superm1> pitti, then how did it make it into dependencies to be on desktop CDs?
[17:46] <Treenaks> pitti: ah, hunspell vs myspell
[17:46] <dendrobates> pitti: it won't ask any questions and will not be configured and the daemon will not run, unless you select it in d-i.
[17:46] <Treenaks> pitti: my bad, sorry
[17:47] <pitti> dendrobates: right, but it takes some extra 2 MB CD space, and isn't useful for 99% of desktop users
[17:47] <cjwatson> dendrobates: have you escalated the issue of landscape using smartpm when the rest of Ubuntu doesn't? It will cause problems
[17:47] <cjwatson> real upgrade problems, that we're going to have to work around in complex ways
[17:47] <dendrobates> pitti: it is worth noting that desktop users that upgrade will get it.
[17:47] <pitti> that's my other concern why I don't think that having smart in main is a good idea ATM
[17:47] <pitti> especially not after FF
[17:47] <pitti> dendrobates: right
[17:47] <cjwatson> (I don't know of anything specific, but I can guarantee you that a new dependency resolver will have its own set of issues)
[17:48] <pitti> I assumed that we'd always just keep the stub, and keep the real client in a caonical repo
[17:48] <dendrobates> cjwatson pitti: since it is in the server seed,are you removing it form the desktop?
[17:48] <pitti> dendrobates: did slangasek approve the real landscape-client upload yesterday? (FF exception)
[17:49] <mathiaz> pitti: yes
[17:49] <niemeyer> Hello there!
[17:49] <cjwatson> dendrobates: I'm not sure we will be able to do that effectively
[17:49] <pitti> dendrobates: I'm not sure; if we don't have the stub any more, then most probably yes
[17:49] <dendrobates> slangasek: gave us a FFE and kees and jdstrand did a code review.
[17:49] <pitti> but that won't help for upgrades
[17:49] <smarter> could someone please take a look at bug #267705?
[17:49] <cjwatson> dendrobates: we can perhaps do that for update-manager upgrades, but not for apt upgrades
[17:50] <niemeyer> Can I help the ongoing discussion anyhow?
[17:50] <cjwatson> (not without massive overkill such as conflicts)
[17:50] <cjwatson> niemeyer: I am very concerned about Landscape using smartpm when it's not something that's part of the Ubuntu upgrade testing process
[17:50] <pitti> niemeyer: why did we suddenly provide the real landscape client in the ubuntu repo?
[17:50] <cjwatson> pitti: we always intended to
[17:50] <pitti> (and smart in main, too)
[17:51] <cjwatson> niemeyer: without it being something we test regularly, the probability approaches 1 that we're going to break it at some point
[17:51] <pitti> cjwatson: hmkay, wasn't aware of that (since it seems fairly useless without a support contract)
[17:51] <niemeyer> pitti: I'm not sure I understand your question.. was it supposed to always be an empty package?
[17:51] <dendrobates> pitti: and the stub was in main.
[17:52] <cjwatson> niemeyer: certainly smart has been on our radar for a while, but at this point Landscape seems to be forcing the issue
[17:52] <niemeyer> cjwatson: Smart should comply to the package relations defined
[17:52] <cjwatson> niemeyer: so should apt, but theory and practice often differ
[17:52] <niemeyer> cjwatson: How is it forcing the issue now?
[17:52] <cjwatson> it just doesn't work that way
[17:52] <niemeyer> cjwatson: It's not like we suddenly started using Smart in Landscape
[17:52] <cjwatson> I am not alleging a particular bug in smart; I'm merely speaking from experience of having to work around problems in all kinds of tools
[17:53] <niemeyer> cjwatson: We've been using it for 3 years now
[17:53] <cjwatson> niemeyer: because now we have been asked to include the client in the distro
[17:53] <cjwatson> niemeyer: which means that we have to support smartpm in main
[17:53] <niemeyer> cjwatson: That's not a decision we've done now
[17:53] <pitti> niemeyer: forcing> we are suddenly confronted with MIRs for smart and other things for packages which are already uploaded, and all that past FF without discussing how to support a second package manager in intrepid
[17:53] <cjwatson> niemeyer: Ubuntu is now also promoting Landscape to some extent, which hopefully translates into more users
[17:53] <niemeyer> cjwatson: The inclusion of landscape-client was discussed back in Dapper
[17:54] <cjwatson> niemeyer: I was in those discussions, and don't recall smartpm being mentioned
[17:54] <niemeyer> cjwatson: Smart is a dependency of Landscape since day 1
[17:54] <cjwatson> niemeyer: I'm also very concerned that this partitions the set of Ubuntu users into two package management camps, and we're going to have to support them both
[17:54] <cjwatson> regardless of whether this is a current decision or not, it is a current problem
[17:55] <niemeyer> cjwatson: I'm not trying to make people use Smart
[17:55] <pitti> niemeyer: I guess we have never been really aware of that, since so far it was completely separate from Ubuntu, and our testing efforts, as well as bug tracking
[17:55] <cjwatson> but everyone who uses Landscape for upgrades will use Smart, no?
[17:55] <niemeyer> cjwatson: We are just trying to offer good server-side package management
[17:55] <cjwatson> in order to support that usefully in Ubuntu, we need to be testing Smart
[17:55] <niemeyer> cjwatson: and Smart enabled us to do it quickly, and well
[17:55] <cjwatson> we are not doing so right now, and it doubles our upgrade testing work
[17:56] <cjwatson> I appreciate and respect your reasons. Nevertheless, it has created a problem for us
[17:56] <niemeyer> cjwatson: Smart uses the repositories from APT itself
[17:56] <cjwatson> yes, I know.
[17:56] <niemeyer> cjwatson: We'll be happy to try to solve your problems in any way we can
[17:56] <cjwatson> it is nevertheless a completely separate implementation. We have worked around bugs in APT before; I'm not saying Smart is bad software, but experience of software engineering strongly indicates that at some point we will have to work around bugs in Smart
[17:56] <niemeyer> cjwatson: But let's step back
[17:57] <niemeyer> cjwatson: Landscape is in development for 3 years, and it uses Smart
[17:57] <cjwatson> Landscape has not, in any real sense, been in Ubuntu for three years.
[17:57] <cjwatson> (which you know as well as I)
[17:57] <niemeyer> cjwatson: Okay
[17:57] <niemeyer> cjwatson: So what do you suggest we do?
[17:58] <cjwatson> the number of existing Landscape users is tiny compared to the number of Ubuntu users
[17:58] <cjwatson> we have a *lot* of experience with upgrade problems, and they are complex and tend to be unanticipated with the best of goodwill
[17:58] <niemeyer> cjwatson: So do I :-)
[17:58] <cjwatson> What would it take to make Landscape use apt?
[17:58] <niemeyer> cjwatson: But that doesn't change things
[17:58] <cjwatson> while it is still the standard package manager in Ubuntu
[17:59] <niemeyer> cjwatson: This is impossible in the short term
[17:59] <niemeyer> cjwatson: For Landscape to do what it does we use a good amount of the logic in Smart
[17:59] <cjwatson> in that case, either (1) we need to restructure the Landscape packages in Ubuntu so that we don't have to include smart in main or (2) we need to find a way to have enough resources to test Smart upgrades as part of our routine QA
[17:59] <pitti> so, I don't see a good and quick solution to that, short of reintroducing the stub for intrepid, and discussing how to integrate smart in our testing efforts and the package tools in jaunty
[18:00] <cjwatson> for (2), remember that much of our routine QA for upgrades comes from thousands of people testing Intrepid and reporting bugs
[18:00] <cjwatson> we can't just magic up that sort of effort
[18:00] <niemeyer> pitti: Sure, we can discuss that possibility
[18:00] <cjwatson> what's the stub in question?
[18:01] <cjwatson> also, does landscape-sysinfo require smartpm?
[18:01] <radix> cjwatson: landscape-sysinfo does not
[18:01] <pitti> cjwatson: stub> I meant the empty package we've been carrying until Monday
[18:01] <radix> not now, anyway. we are considering further features that will, but probably not before the beta freeze
[18:02] <cjwatson> I don't think that will be acceptable; this is a major headline feature and it's important to Canonical
[18:02] <pitti> hmm
[18:03] <pitti> niemeyer: so the actual plan is to just ship sysinfo, and the current, complete, package is just an interim state?
[18:03] <cjwatson> pitti: the requirement is to ship the Landscape client
[18:03] <pitti> hm
[18:04] <cjwatson> I don't see any way to satisfy the constraints here without magicking up vast amounts of upgrade testing efforts of all kinds of Ubuntu (at least server) combinations
[18:06] <jdstrand> cjwatson: side-stepping smartpm in main for a moment, just having smartpm installed doesn't change update-manager or apt-get IIUC. though both installed simultaneously is both confusing and problematic in its on right
[18:07] <jdstrand> cjwatson: so won't it still be the 'small number' of landscape users that are affected by these upgrades?
[18:07] <jdstrand> cjwatson: further, this 'small number' have been using smart for sometime...
[18:07] <cjwatson> that's correct, but since we now have parts of the distro that refer to landscape, I think it's incumbent on us to ensure that that works
[18:07] <cjwatson> I don't think we can reasonably assume that the number of landscape users will remain static
[18:08] <jdstrand> I heartily agree (and mentioned some of this in emails)
[18:08] <radix> in fact we hope that it doesn't :-)
[18:08] <jdstrand> sure, I was just trying to think about the problem differently
[18:08] <cjwatson> what can the landscape team do to ensure widespread testing of server upgrades?
[18:08] <tkamppeter> pitti, I asked you yesterday whether you could document the DBUS API quickly so that we can make a patch for s-c-p to trigger Jockey for driver download as this would enable especially network printers to make use of driver download. You told that you will answer later. Have you any answer now?
[18:09] <cjwatson> I assume you have some degree of automatic testing, although it can't possibly cover all combinations
[18:09] <pitti> tkamppeter: oh, sorry; erm, "yes" :-)
[18:09] <niemeyer> cjwatson: The Landscape team itself can't do widespread testing of server upgrades, of course
[18:10] <cjwatson> niemeyer: who does?
[18:10] <niemeyer> cjwatson: But we can certainly discuss what's the proper way of doing testing of upgrades with Landscape, within a Canonical context
[18:10] <cjwatson> within an Ubuntu context too
[18:10] <cjwatson> if there are problems, they will reflect on Ubuntu
[18:10] <niemeyer> cjwatson: I would like to isolate the things we're discussing at ocne
[18:10] <niemeyer> once
[18:10] <niemeyer> cjwatson: We have several things mixed
[18:11] <niemeyer> cjwatson: Are all the concerns coming from the fact that Smart is going to main?
[18:12] <cjwatson> well, part of the concern arises from the fact that this is landing late, two weeks after feature freeze
[18:12] <pitti> niemeyer: well, that, and shipping an ubuntu package which doesn't use our standard packaging tools, without prior discussion, or without us being prepared to do appropriate testing with it
[18:12] <niemeyer> cjwatson: So that's *yet* another issue
[18:13] <cjwatson> that is not necessarily your problem, but it contributes to the Ubuntu team being uneasy
[18:13] <pitti> niemeyer: well, sorry, that was wrong
[18:13] <pitti> niemeyer: "discussion with the distro team"; it has certainly been discussed at length in general
[18:13] <dendrobates> cjwatson: it is landing late, because we wnated to do a thorough security review.
[18:13] <cjwatson> dendrobates: yes. Nevertheless, that means it's late
[18:14] <cjwatson> late things that are easy aren't necessarily a problem, but this is a late thing that's hard
[18:14] <niemeyer> cjwatson: I feel very bad about it.. I personally thought the package had been integrated for a while, and I feel bad for not following more closely, but that's a separate issue I would like to discuss in another moment so that we can get back to the aforementioned concerns
[18:14] <jwendell> hi, pitti. Any reason for not having consolekit 0.3 in intrepid?
[18:14] <cjwatson> and I agree that the security review being already done alleviates some other problems
[18:14] <cjwatson> niemeyer: that which package had already been integrated - landscape or smart?
[18:15] <slangasek> hum, yes, this is significantly more complicated than what I understood I was granting a FFe for; we hadn't discussed that any new dependencies were being pulled in that would need MIRs
[18:15] <pitti> jwendell: there isn't a particular reason reported for it, and we are past FF
[18:15] <dendrobates> cjwatson: there was pressure to shove it in that I resisted.  It is entirely my fault that it is landing when it is.
[18:15] <cjwatson> dendrobates: understood. I'm not trying to apportion blame
[18:15] <jwendell> pitti, it's needed by the new gdm (2.24)
[18:15] <niemeyer> cjwatson: Both.. Landscape is in development for three years, as I've been unfortunately been saying repeatedly.  Many of the people involved into the discussions know about that, so I didn't think that was going to be brought up so late (now).
[18:15] <cjwatson> but niemeyer asked for other concerns and that's definitely one of them
[18:16] <pitti> jwendell: hm, maybe, but we won't use that in intrepid
[18:16] <cjwatson> I find it surprising that smartpm wasn't mentioned as a distro concern before now, but I can't find any records of it
[18:16] <jwendell> pitti, yeah, I know... I'm trying to get is usable in intrepid to make an alternative package
[18:17] <pitti> jwendell: nothing wrong with preparing a PPA package, or requesting a FFE if the changes aren't too intrusive and backwards-compatible
[18:18] <pitti> jwendell: the primary reason is "we don't update to new upstream versions unless someone cares and asks"
[18:18] <jwendell> pitti, ok, thanks
[18:18] <pitti> jwendell: (after FF)
[18:18] <pitti> jwendell: BTW, both seb128 and MacSlow have packages for the new gdm, so don't start from scratch
[18:18] <jwendell> seb128, ??
[18:18] <jwendell> really?
[18:19] <mdz> dendrobates: already here
[18:19] <seb128> jwendell: the packaging is on launchpad in the ubuntu-desktop bzr
[18:19] <cjwatson> we did have a spec a couple of years ago for smartpm (https://blueprints.launchpad.net/ubuntu/+spec/smartpm), but it was never very high priority and hasn't happened
[18:19] <seb128> jwendell: I didn't upload binaries to a ppa though because it's too broken to be pushed to users
[18:19] <tkamppeter> pitti, thanks, tell me when you have the doc ready.
[18:19] <cjwatson> (for use of it in Ubuntu, I mean)
[18:20] <seb128> jwendell: what do you want the new gdm for exactly? it just does less than the previous one
[18:20] <pitti> tkamppeter: where do you think should that be? there is a README.txt, but it's mainly for jockey developers
[18:20] <seb128> jwendell: it's buggy, it has no graphical theme, no configuration gui, etc, etc, etc
[18:20] <pitti> tkamppeter: but for the time being it could stay there, I figure
[18:21] <dendrobates> mdz: I thought that it was widely known that landscape used smart.  I understand the concerns and share them, but I am surprised at the resistance at this time.
[18:21] <tkamppeter> pitti, or you add an interface doc file (or section in README.txt) for the interfaces to work together with other programs.
[18:21] <niemeyer> cjwatson: So what do you think we should do to understand how to best address the concerns?
[18:22] <pitti> tkamppeter: I'll do a section in README.txt for now; at some point I'll write manpages and move it there then
[18:22] <cjwatson> niemeyer: explain to me what your upgrade testing involved
[18:22] <cjwatson> involves
[18:22] <niemeyer> cjwatson: Upgrade testing of what, when?
[18:22] <tkamppeter> Riddell, I have a question to PDF printing output of KDE and Qt.
[18:22] <cjwatson> niemeyer: Ubuntu, using Landscape
[18:22] <cjwatson> niemeyer: you have a server upgrade feature, yes?
[18:23] <tkamppeter> pitti, thanks in advance
[18:23] <niemeyer> cjwatson: Can you please define "server upgrade" in more details?
[18:23] <mdz> dendrobates: this is the first time that the client is being fully released in Ubuntu, nothing about it has been common knowledge until now
[18:24] <cjwatson> niemeyer: upgrading an Ubuntu system from one release to another, or applying security updates
[18:24] <niemeyer> cjwatson: The first thing isn't supported by Landscape at all at this point
[18:24] <niemeyer> cjwatson: As it's not supported by APT, in fact
[18:24] <cjwatson> that is entirely false
[18:24] <cjwatson> change sources.list, apt-get dist-upgrade
[18:25] <cjwatson> we recommend update-manager in its stead, but that method is still entirely possible and used by a significant fraction of Ubuntu users
[18:25] <niemeyer> cjwatson: I thought the only supported way of doing release upgrades was via update-manager
[18:25] <cjwatson> that doesn't mean it isn't supported by APT
[18:25] <cjwatson> it just means it's not the method we recommend
[18:25] <niemeyer> cjwatson: We're talking about policy, not tools
[18:25] <pitti> niemeyer: it's debian's official method, and due to our heritage, a lot of Ubuntu users do it that way, too
[18:25] <cjwatson> in practice we often do accept bug reports from apt-get dist-upgrade and deal with them where it makes sense to do so
[18:25] <slangasek> policies don't stop users from using the tools
[18:26] <cjwatson> because they often indicate package bugs that should be fixed
[18:26] <cjwatson> so our policy is a little more broad than the outward presentation of it might indicate
[18:26] <niemeyer> Nothing stops users from upgrading the distribution in any way they want, but not all paths will be tested
[18:26] <niemeyer> THis is what I mean
[18:26] <cjwatson> apt-get dist-upgrade is widely tested, in reality
[18:26] <niemeyer> You guys were bringing up tested paths
[18:26] <niemeyer> So I'm trying to stay within a given context
[18:27] <cjwatson> niemeyer: is it *possible*, tool-wise, to perform an upgrade from one Ubuntu release to another using Landscape?
[18:27] <niemeyer> cjwatson: So that's the reality, Smart can do distribution upgrade if the user does it manually
[18:27] <cjwatson> right, Smart can, but do you present it in Landscape?
[18:27] <niemeyer> cjwatson: No, there's no way to do it via Landscape only
[18:27] <cjwatson> OK, that simplifies things somewhat
[18:28] <niemeyer> cjwatson: The user would have to change the repositories
[18:28] <jdstrand> hmm, would a user know to use smart in this instance, or would the user go to update-manager or apt-get?
[18:28] <niemeyer> cjwatson: This doesn't change things much, of course.. the user can still do the distribution upgrade if he really wants to
[18:28] <cjwatson> sure, but I care about the new paths that we're presenting to users
[18:28] <niemeyer> cjwatson: But we don't advertise that as such, and we won't
[18:29] <cjwatson> could we separate the Smart libraries needed by Landscape from the binary that users can use standalone?
[18:29] <cjwatson> and ship only the libraries
[18:29] <cjwatson> I would be happier if we were only shipping the parts Landscape strictly needed
[18:30] <kees> hm, where is the main/universe mismatch output?  I've been wandering germinate output but haven't found it yet.
[18:31] <cjwatson> kees: http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt
[18:31] <niemeyer> cjwatson: Landscape needs Smart installed.. we can name it landscape-smart if that's the case
[18:31] <cjwatson> niemeyer: Which parts of Smart does Landscape need? Does it need /usr/bin/smart?
[18:31] <kees> cjwatson: ah! thanks, I wasn't looking in the top-level. gah
[18:32] <niemeyer> cjwatson: Yes, for running "smart update"
[18:32] <niemeyer> cjwatson: We can do it in different ways of course
[18:32] <cjwatson> niemeyer: Could it use the library interface to that instead, please?
[18:32] <cjwatson> niemeyer: Then it would be trivial to support Smart *only* for use by Landscape, since the command-line client wouldn't be provided
[18:33] <niemeyer> cjwatson: We certainly can hide in any way wanted
[18:33] <jneves> asac: I hope this is not off-topic here: NM 0.7 (hardy, from the PPA) doesn't seem to accept/save my PPP options (and the umts modem doesn't work with them enabled)
[18:34] <cjwatson> niemeyer: how does Smart deal with dpkg conffile resolution?
[18:34] <cjwatson> (I'm thinking now of problems likely to affect server users)
[18:34] <cjwatson> (on security updates)
[18:34] <jdstrand> I know that smart can be run alongside other package managers, but am concerned that if release upgrades aren't supported, and people use apt or upgrade-manager to upgrade to another release, and then start using smart again, what the consequences might be (and also the possibly untested package combinations)
[18:34] <niemeyer> cjwatson: We can have "landscape-smart" as well, for instance
[18:34] <cjwatson> I'm not sure landscape-smart would help. That would introduce extra complexity later
[18:35] <cjwatson> and it would introduce dual maintenance, which is something we generally abhor
[18:35] <niemeyer> cjwatson: I meant just the executable name
[18:35] <cjwatson> oh, I don't think that would really help
[18:35] <niemeyer> cjwatson: Leaving inside landscape-client
[18:35] <niemeyer> Living even
[18:36] <cjwatson> smart is not a name Ubuntu users are familiar with, and neither is landscape-smart; they're identical from that point of view
[18:36] <cjwatson> surely it would be very little harder just to use the library interface?
[18:36] <radix> what about /usr/share/landscape/landscape-smart?
[18:36] <cjwatson> I thought Landscape was written in Python
[18:36] <radix> cjwatson: we use the library interface in the client, but we need something to run in cron
[18:36] <dendrobates> cjwatson: we could, of course, easily split the package and only install the python lib.
[18:36] <niemeyer> cjwatson: We use the smart command line commonly to debug issues
[18:36] <slangasek> jdstrand: what's the possible issue that you see there?  I would hope that smart is treating the existing /var/lib/dpkg, /var/lib/apt metadata as authoritative
[18:36] <cjwatson> oh. In that case /usr/share/landscape/landscape-smart would be fine
[18:36] <niemeyer> cjwatson: I wouldn't like to ask users to execute python and run code to debug things when necessary
[18:37] <niemeyer> cjwatson: Cool
[18:37] <cjwatson> it just reduces the risk of us having to deal with users having found smart and done untested upgrades with it
[18:37] <cjwatson> note that untested is a much stronger statement than unsupported, so I don't consider users finding apt-get to be a problem in the same way
[18:37] <tkamppeter> jdstrand, thanks for the clarification on ufw profiles.
[18:37] <pitti> tkamppeter: http://bazaar.launchpad.net/~jockey-hackers/jockey/trunk/revision/378
[18:37] <jdstrand> slangasek: I am not entirely sure there is an issue, not having used smart myself. but IIUC, Recommends are treated differently in smart, so we'd likely have many different package combinations that may or may not be tested
[18:38]  * pitti -> gotta run now, cu tomorrow
[18:38] <niemeyer> pitti: Heh
[18:38] <niemeyer> pitti: You sounded so interested in that topic.
[18:38] <dendrobates> jdstrand: imo, smart is going to have to install recommends.
[18:38] <dendrobates> jdstrand: it will have to be fixed.
[18:38] <jdstrand> dendrobates: does it currently? I wasn't aware of the change
[18:39] <slangasek> jdstrand: well, unless smart plans to autoremove Recommends, I don't see much room for horrible failure scenarios when one specifically /does/ use apt for the upgrade :)
[18:39]  * jdstrand nods
[18:39] <dendrobates> jdstrand: no
[18:39] <niemeyer> jdstrand: Ok, about the things you've brought up
[18:39] <niemeyer> jdstrand: Indeed Recommends are not handled by Smart right now
[18:40] <niemeyer> slangasek: Smart doesn't consider anything in /var/lib/apt
[18:40] <ahasenack> https://bugs.launchpad.net/smart/+bug/268143 is about the Recommends handling
[18:40] <cjwatson> niemeyer: how does Smart deal with dpkg conffile resolution?
[18:41] <niemeyer> cjwatson: It doesn't do anything special about this
[18:41] <niemeyer> cjwatson: It just runs dpkg
[18:42] <cjwatson> niemeyer: does it ensure that the user has a terminal (emulation) so that they can respond to dpkg conffile prompts?
[18:42] <niemeyer> cjwatson: For Smart, it doesn't
[18:42] <norsetto> jdstrand: thx for fixing bug 268084, works a charm now
[18:42] <niemeyer> cjwatson: For Landscape, it runs Smart with options to run dpkg non-interactively right now
[18:43] <cjwatson> niemeyer: that's going to be a real problem in practice
[18:43] <slangasek> niemeyer: so smart has to re-download all the packages files?
[18:43] <niemeyer> cjwatson: In practice, it hasn't been a problem so far
[18:43] <niemeyer> cjwatson: But it's certainly our desire to make things better over time
[18:43] <cjwatson> niemeyer: your test cases are inadequate, then, I'm afraid
[18:43] <jdstrand> norsetto: np :)
[18:43] <cjwatson> niemeyer: this means that any change to a dpkg-handled conffile in an Ubuntu update will be ignored by people upgrading using Landscape
[18:43] <niemeyer> cjwatson: I'm saying "in practice"
[18:44] <cjwatson> well, no, that's not true
[18:44] <cjwatson> niemeyer: this means that any change to a dpkg-handled conffile in an Ubuntu update will be ignored by people upgrading using Landscape, if they have already changed that conffile themselves
[18:44] <cjwatson> niemeyer: it is a problem in practice for Ubuntu.
[18:44] <cjwatson> niemeyer: the effect of this will be that, at some point in the future, we will get obscure bug reports that turn out to be because a configuration file didn't get updated, and the user was provided no guidance about this
[18:44] <niemeyer> cjwatson: Yes, it will not work well in some cases indeed
[18:45] <niemeyer> cjwatson: This is a bug we have to fix on Landscape
[18:45] <cjwatson> Is there a bug filed about this? Can it be release-critical for Intrepid/
[18:45] <cjwatson> ?
[18:45] <james_w> norsetto, I saw in that report that apport also fails in that situation, did you report that as well?
[18:45] <niemeyer> cjwatson: No, it can't be release critical for Intrepid
[18:45] <cjwatson> Why not?
[18:46] <norsetto> james_w: IIRC apport didn't report since it was over the number of max allowed bugs (or crashes, or something like that)
[18:46] <niemeyer> cjwatson: First, because we have a development schedule too.  We have to verify what it will take to implement support for this, and come up with a plan.
[18:46] <cjwatson> all our existing package management tools handle conffiles, and in many cases this has been something we've taken care to add to them
[18:47] <jneves> asac: edited what I needed through gconf-editor (I looked at the source for the keys) - the interface isn't working
[18:47] <niemeyer> cjwatson: Then, I consider this as a bug in Landscape, not in Ubuntu.
[18:47] <cjwatson> niemeyer: you're asking us how you can best address the concerns; this is one of the problems that is of concern
[18:48] <cjwatson> Landscape is a package in Ubuntu now, and thus I think it makes sense to talk about certain bugs in it being RC for intrepid
[18:48] <james_w> norsetto, the terminal log in your bug shows apport falling over try to get /proc/<pid>/cmdline which obviously fails for the same reason as ufw
[18:48] <niemeyer> cjwatson: Of course.  This is a concern of myself too.  I have discussed this problem with dendrobates in the past.
[18:49] <cjwatson> niemeyer: Does Landscape offer the ability to install and remove individual packages?
[18:49] <niemeyer> cjwatson: If you want to mark it as RC for Intrepid and follow on with it, I can't prevent it.
[18:49] <niemeyer> cjwatson: I'm not in a position to offer you a fix for this in time or Intrepid.
[18:49] <niemeyer> s/or/for/
[18:50] <niemeyer> cjwatson: Yes, it offers it.
[18:50] <norsetto> james_w: well, what happened in that case is that dpkg failed a certain number of packages in the trigger_awaited state, and I do remember having seen a message saying that it was not going to be reported because it was above a certain threshold, but, really, I only glanced at it
[18:50] <cjwatson> niemeyer: does it record which packages were automatically installed and which were manually installed, in a way which will be compatible with 'apt-get autoremove'? (Note that you can manipulate apt's state here using apt-mark.)
[18:51] <niemeyer> cjwatson: No, it doesn't.  That feature was added after Landscape was born and we didn't catch up.
[18:51] <cjwatson> I think that will need to be added. (Note that I'm not mentioning everything that comes to mind, only the things I think make sense in this context and that I expect to cause problems in practice.)
[18:52] <niemeyer> cjwatson: Ok, one more thing to fix.
[18:53] <cjwatson> I'm going to have to continue this at another time, sorry - I'd love to try to get this sorted out now but I'm expected elsewhere
[18:53] <cjwatson> thanks for answering our questions thus far
[18:53] <niemeyer> cjwatson: Cool, just let me know when would be a good time and I'll be happy to follow up.
[18:54] <niemeyer> cjwatson: No problem.
[18:54]  * niemeyer looks for lunch
[19:00] <norsetto> james_w: I guess your case is covered by bug 215380 ?
[19:00] <james_w> norsetto, I just found that, I think it might be
[19:06] <nxvl> popey: i LOVE your bug reports
[19:06] <nxvl> popey: the screencast is a lovely and helpfull idea
[21:01] <kees> ack, wtf?  why does policykit show me as the registrant?  https://edge.launchpad.net/policykit
[21:02] <kees> james_w: I've made you the registrant.  I think I was marked that way since I was the first to report a bug against it upstream.
[21:11] <mathiaz> dendrobates: is lp:~dendrobates/landscape-client/intrepid-packaging
[21:11] <mathiaz> dendrobates: the most update-to-date ?
[21:13] <popey> :) thanks nxvl
[21:30] <dendrobates> mathiaz: yes.
[22:27] <mdke> can a package have itself as a build-dep?
[22:27] <seb128> mdke: no
[22:28] <slangasek> why not?
[22:28] <slangasek> it's not a /good/ thing, but it's not impossible
[22:28] <seb128> slangasek: doesn't really make sense and you require boostraping?
[22:28] <mdke> heh, and I thought it was a stupid question
[22:28] <seb128> bootstraping
[22:28] <slangasek> seb128: there are compilers that have themselves as build-deps, unfortunately
[22:29] <mdke> this would be a lot less complicated
[22:29] <slangasek> because they can't do a ground-up bootstrap in the source package
[22:29] <seb128> slangasek: right, that was a short reply for "usually not a good idea"
[22:29] <slangasek> ok :)
[22:29] <slangasek> mdke: which answer makes it less complicated?  If a "no" is less complicated, just go ahead and pretend it's "no" :)
[22:30] <seb128> mdke: you should give details on what you want to do
[22:30] <slangasek> in practice, bootstrapping new packages that self-depend is awkward because of the need for packages to build in the DC
[22:30] <NCommander> slangasek, one of the worst offers is GNAT, since its the only free ada compiler
[22:30] <NCommander> sladen, offenders
[22:32] <mdke> seb128: I'm playing around with making a txt version of the ubuntu serverguide
[22:32] <mdke> seb128: and so far, using lynx -dump, I get to this - http://launchpadlibrarian.net/17522613/serverguide.txt - which has loads of ugly footnotes at the bottom
[22:32] <bryce> where are acpi events logged?
[22:33] <mdke> seb128: I figured that if I use an installed version of the server guide to generate the txt, the links in the footnotes won't look quite so appalling
[22:34] <mdke> (because at least they will point at files which the user has installed)
[22:34] <cjwatson> mdke: either convince it to use relative links, or just postprocess the output
[22:34] <mdke> obviously I could just run sed over the links
[22:34] <mdke> right
[22:35] <cjwatson> a self-build-dep that needs to be kept up to date every time is going to be completely infeasible
[22:35] <cjwatson> that's not even a self-build-dep on the previous version - you have to get the current one installed before you can complete the build
[22:35] <cjwatson> you could use fakechroot or something, but honestly postprocessing is going to be a *lot* easier
[22:36] <mdke> fair enough
[22:36] <mdke> thanks :)
[22:54] <Riddell> dendrobates: why do you need smartpm and update-motd?  generally these things need a MIR
[22:55] <Riddell> tkamppeter: what's your PDF and Qt question?
[22:58] <dendrobates> Riddell: never mind there is an on going discussion.