[00:00] <directhex> yes, because everyone reads the manual
[00:00] <directhex> :p
[00:02] <RAOF> directhex: Go formulate an ubuntu-devel-discuss message, then :)
[00:03] <directhex> "digg this if users suck"
[00:41] <slangasek> who here can test a powerpc-specific SRU? (bug #220890)
[00:45] <maxb> The langpacks in intrepid currently have a higher version than in jaunty, is that an issue, or a normal state of affairs at this point in the cycle?
[00:46] <cjwatson> I wouldn't get too worried, but obviously it needs to be fixed before release
[00:46] <TheMuso> slangasek: When I do powerpc related work this afternoon (i.e after work/canonical work), I'll take a peak
[00:46] <cjwatson> ArneGoetje: ^- plans for a jaunty langpack update?
[00:47] <cjwatson> we could copy the intrepid-updates ones to jaunty, in principle, but I don't want to do that because there's a Soyuz bug that means architecture-independent packages copied that way end up not showing up for armel
[00:47] <cjwatson> though that's 299448 which is fix-committed so it's possible it was fixed in the recent rollout
[00:50] <cjwatson> looks like it ought to be; I can give it a try tomorrow
[00:50] <cjwatson> but we'll need jaunty langpacks anyway so it'll just be to stop people being surprised :)
[01:41] <slangasek> seriously, what kind of boolean pervert came up with the idea of calling these things "killswitches" that turn your antenna off when they're on and on when they're off?
[01:42] <pwnguin> the same guy that named the xserver option "DontZap"
[01:42] <slangasek> nah, pretty sure that guy died of old age already
[01:42] <pwnguin> slangasek: just use the phrase "killswitch engage". its 23 percent more brutal
[01:43] <sakrasemangat> halloo..
[01:44] <slangasek> hello
[01:46] <cjwatson> my killswitch is labelled 0 for wireless-off and 1 for wireless-on
[01:46] <cjwatson> so +1 for Dell's sanity, I guess
[01:47] <slangasek> physically labelled?
[01:49] <sakrasemangat> i'm newbie from indonesia and i need the study kernel compilation process on ubuntu please guide me...
[01:57] <cjwatson> slangasek: yes
[01:57] <cjwatson> sakrasemangat: this isn't really the right channel for advising new developers; you might start by reading the kernel team's wiki, http://wiki.ubuntu.com/KernelTeam
[01:58] <cjwatson> sakrasemangat: also reading the various links from http://wiki.ubuntu.com/UbuntuDevelopment, since many of those general principles apply to the particular case of the kernel
[02:07] <sakrasemangat> cjwatson, ok thank's...
[02:07] <sakrasemangat> :)
[03:04] <junyer> hi
[03:04] <junyer> trying a third time :P
[03:04] <junyer> does anyone here work on the autofs/autofs5 packages?
[03:05] <ScottK> junyer: Just ask your question.
[03:07] <slangasek> the answer to the initial question is "no", no one from Ubuntu works on the autofs5 package, it's synced unmodified from Debian
[03:09] <slangasek> (which is not to say that this is the wrong place to ask if you're wanting to discuss development issues in the package)
[03:09] <junyer> well, autofs v4 is essentially dead as far as upstream is concerned
[03:09] <andersk> The current Intrepid/Jaunty autofs package has an Ubuntu patch that was added in bug 111612.
[03:10] <junyer> so i'm wondering if/when support (in the form of a maintained autofs package) will cease
[03:11] <slangasek> support for the autofs package will probably cease when the Debian maintainer gets rid of it, or when an Ubuntu developer notices that it's bit-rotted to the point that we should prefer the autofs5 package instead
[03:12] <ScottK> slangasek: I've got an odd problem here that I've no idea how to troubleshoot well enough to even file a useful bug.  On intrepid I've got a hard drive that when I try to write to it as a user, I'm told the disk is full, but it's not.  df -k shows more blocks existing that used, but 0 available.  I can write to the disk as root and I can delete stuff as a user, but not write new stuff.  Suggestions?
[03:12] <junyer> hmm
[03:12] <slangasek> ScottK: ext3 reserved blocks?
[03:12] <junyer> okay, so i should probably ping the debian maintainer then
[03:13] <junyer> thanks
[03:13] <slangasek> junyer: he's the one at the wheel on those packages, yes. :)
[03:13] <junyer> (although he didn't respond to my mail yet, so i might have to hunt him down on irc)
[03:13] <ScottK> slangasek: How would I know?  When I delete files the number 'used' goes down, but Available stays consistently 0.
[03:13] <slangasek> ScottK: tune2fs /dev
[03:14] <andersk> See the tune2fs manpage, -m option.
[03:14] <ScottK> Lookinmg
[03:14] <ScottK> Looking even
[03:15] <StevenK> ScottK: Deleting files but available staying at 0 certainly points to you being over the reserved blocks percentage
[03:15]  * slangasek nods
[03:15] <ScottK> OK.
[03:15]  * ScottK wonders how he got there.
[03:16] <slangasek> the default reserved blocks are ridiculously large on today's large disks, it really ought to be logarithmic
[03:16] <slangasek> ScottK: you wrote a bunch of stuff as a user, then root pushed you over the limit :)
[03:16] <ScottK> Right
[03:16] <StevenK> For things like /home and /srv and such, I will run tune2fs -m 0 after mkfs'ing them
[03:17] <StevenK> Actually, for things where I'm the only user, or I can trust everyone with an account.
[03:17] <ScottK> Well let me go find something big to delete ...
[03:17] <slangasek> StevenK: well, for /home there's not much reason for root to have reserved space, neh?
[03:18] <slangasek> ScottK: reducing the reserved count is easier :)
[03:18] <ScottK> Reduced it to 1 and it still says 0 available
[03:18] <StevenK> slangasek: Not usually. :-)
[03:18] <slangasek> (though if it's not obvious how root pushed you over the limit, maybe there are leaky logs)
[03:19] <slangasek> ScottK: mm, if tune2fs -l confirms, then /that/ might be a sign of fs corruption...
[03:20] <slangasek> assuming that when you deleted stuff, the used count went down and stayed down
[03:20] <ScottK> I'm guessing "Couldn't find valid filesystem superblock" is bad.
[03:21] <slangasek> yes
[03:21] <ScottK> I'm also guessing I'm into it's not worth the trouble, just start over territory.
[03:22] <ScottK> Is there anything useful for a bug I can do first?
[03:22] <slangasek> if you're not going to cry over the data, yes, that's start-over territory
[03:22] <slangasek> if you have kernel logs that show it getting corrupted somehow
[03:22] <StevenK> Actually, it's recoverable
[03:22] <StevenK> You can run mkfs with -n, which will tell you where the backup superblocks are stored
[03:22] <ScottK> StevenK: I'm open to suggestions ...
[03:23] <StevenK> And then point tune2fs at one of the backup superblocks
[03:23] <slangasek> could've been a hardware failure, a kernel bug, someone trying to dial out on the hard drive by mistake, ...
[03:23] <StevenK> And fsck *really* soon
[03:23] <slangasek> so unless you know how it got corrupted, hard to get a useful bug report out of it
[03:23] <StevenK> And it may not be a software bug
[03:23] <ScottK> Well I can try to get the kernel logs off.
[03:26] <ScottK> Now I guess I really need to find the CD drive for this laptop.
[03:27] <StevenK> ScottK: One large partition, and it's /, I'm guessing?
[03:28] <slangasek> ... does strace work for anyone in jaunty?
[03:29] <ScottK> Of course
[03:29] <ScottK> StevenK: ^^^
[03:32] <StevenK> ScottK: Bleh, this is the situation that having one large partition on / is bad :-)
[03:32] <ScottK> Fortunately there's nothing critical on it.
[03:32] <ScottK> There's a few things it'd be nice to save.
[03:33]  * LaserJock makes some backups just in case it's contagious
[03:33] <ScottK> I have it up on the network now, so I'm going to see if I can sftp to it....
[03:33] <StevenK> I would sftp *from* it
[03:33] <StevenK> Since that wouldn't try and write anything
[03:35] <ScottK> Trying that.
[03:35]  * ScottK gets to practice his rusty command line sftp skills.
[03:37] <charlie-tca> slangasek: apparently, that was a bad thing to try
[03:37] <slangasek> charlie-tca: hmm?
[03:37] <charlie-tca> I ran strace on a 64-bit jaunty. It locked everything up and I had to go to a tty and kill it
[03:37] <slangasek> heh
[03:37] <Bsims> Can anyone point me to a tutorial to build multi binary debs... I want to package and host kde 3.5x built against Ubuntu Current...
[03:38] <slangasek> it hasn't been crashing anything for me, except for itself
[03:38] <Bsims> I am not entirely ignorant of dpkg but need help and the Debian New maintaners guide doesn't go into multi package debs
[03:38] <maxb> Bsims: #ubuntu-motu is more appropriate for learning-how-to-package questions
[03:38]  * Bsims smiles thanks maxb 
[03:55] <ArneGoetje> cjwatson: after all remaining buggy translations have been fixed by jtv (will happen these days), we will generate a full export for jaunty and updates for hardy and intrepid. I hope those to be ready on Monday, then I will do the updates on the sprint.
[03:57] <StevenK> ScottK: How goes the recovery?
[03:58] <ScottK> StevenK: sftp'ing my heart out.
[03:58] <StevenK> cd /chest_cavity
[03:58] <StevenK> scp heart donor:
[03:58] <ScottK> Found some un-backed up photos I'd forgotten about ...
[03:58] <ScottK> But they're transferring just fine, so no it's just a matter of doing it.
[03:59] <StevenK> ScottK: Mmmm. Avoid writing to the disk, if you can
[03:59] <ScottK> Just doing a lot of sftp put.
[03:59] <ScottK> Going in the order of how much I care too.
[04:00] <StevenK> Heh
[04:03] <TheMuso> slangasek: https://launchpad.net/bugs/220890 verified.
[04:04] <slangasek> TheMuso: thanks!  You used the test case from the bug description?
[04:04] <TheMuso> slangasek: Yes.
[04:04] <slangasek> great
[04:22] <slangasek> bryce: I've confirmed that my touchpad issue is software (gpm works fine on console); where should I file the bug report?
[04:24] <calc> maybe i can blow up the nightly cd later tonight >:-)
[04:25]  * calc is doing a rebuild with fresh chroot to make sure everything is working properly
[04:26] <ScottK> slangasek and StevenK: Thanks for the help.  I got everything I need.  Now if I can find the CD drive ...
[04:27] <StevenK> ScottK: We won't come over to help you look ...
[04:27] <slangasek> ScottK: glad to hear :)
[04:35] <LaserJock> StevenK: that could be a long trip
[04:35] <StevenK> True
[04:36] <bryce> slangasek: most likely it's a bug in the xinput stuff so should be against xorg-server
[04:36] <bryce> slangasek: subscribe me to the bug and I'll try to follow up on it
[04:36] <slangasek> ok
[04:37] <StevenK> bryce: I noticed that synaptics thought my touchscreen on my Q1 was touchpad, is that known?
[04:37] <StevenK> was a touchpad
[04:44] <ScottK> This will be my first Intrepid fresh install....
[04:45] <LaserJock> ScottK: really? I think I've done about 5-6 so far
[04:45] <ScottK> It's all been upgrades from Hardy until now.
[04:45] <LaserJock> I generally reinstall about every 2-3 months
[04:46] <LaserJock> I think I've done 3 Jaunty reinstalls so far
[04:46]  * ScottK still has one Dapper desktop that was installed before Dapper's release.
[04:46] <LaserJock> that's why I don't like UUID too much
[04:47] <LaserJock> I gott fix things after each install
[04:47] <maxb> LaserJock: but why? I've gone dapper-edgy-feisty-gutsy-hardy-intrepid without a reinstall
[04:47] <LaserJock> I should just not UUIDs but I hate going against the grain
[04:47] <LaserJock> maxb: because stuff usually starts breaking
[04:48] <LaserJock> or I want to try something different
[04:48] <maxb> Would be all the way to jaunty, but I needed to change i386->amd64
[04:48] <LaserJock> I should probably try to slow down though, I'm afraid of wearing out the hard drive in my laptop
[04:49] <LaserJock> it can't be good to keep installing and reinstalling on the same 6GB
[04:50] <LaserJock> bugger, I never can seem to get reportbug to send stuff
[04:50] <LaserJock> isn't it supposed to use a Debian SMTP host?
[04:51] <StevenK> If you configure it too
[04:52] <LaserJock> well, it keeps timing out
[04:53] <LaserJock> I have: smtphost bugs.debian.org in .reportbugrc
[04:54] <LaserJock> maybe rather than worrying about reportbug I should make up a BTS cheat sheet and manually do the emails
[04:55] <LaserJock> I end up copy-n-pasting anyway
[04:56] <ScottK> LaserJock: When you normally send mail, what mail server do you submit to?
[04:56] <LaserJock> ScottK: I just use gmail
[04:56] <LaserJock> I don't have any local client that I use
[04:57] <LaserJock> I guess I could dig up the Gmail SMTP server
[04:57] <ScottK> You can probably convince reportbug to do that too or set up a local postfix to do it (there are decent how-tos)
[04:57] <LaserJock> I think I have exim4 install because of stupid sbuild
[04:57] <LaserJock> *installed
[04:57] <LaserJock> but I don't do anything with it I don't think
[04:58] <LaserJock> I really dislike having a MTA on my machine
[05:11] <ScottK> 243 updates are available ...
[05:33] <mrooney> kirkland: ping!
[05:40] <bbs> hello
[05:40] <bbs> i do kernel work
[05:40] <bbs> is there a spot that the ubuntu kernel is discussed?
[05:41] <greg-g> bbs: #ubuntu-kernel , appropriately enough
[05:43] <bbs> greg-g: figured it out
[05:43] <bbs> asked stupid question
[05:43] <bbs> sorry
[05:52] <hyperair> asac: could bug #248705 be considered for SRU? it seems that 2.24.3-0ubuntu1 was uploaded to intrepid-updates, but not 2.24.3-0ubuntu2, and the changes between the two versions are only that which fixed the said bug.
[05:52] <hyperair> asac: in addition, you were the one who uploaded 2.24.3-0ubuntu2
[05:53] <mrooney> anyone know how to switch to a virtual terminal in a virtualbox instance?
[05:53] <mrooney> Using ctrl+alt+# switches the host even if the guest is grabbing keys
[05:57] <hyperair> mrooney: ssh
[05:57] <smoser> mrooney, http://forums.virtualbox.org/viewtopic.php?t=9615&sid=c79dce75d9b09436397acb59992a316f
[05:57] <smoser> "should be" right control F1
[05:58] <smoser> that is if you actually meant ctrl-alt-F# , maybe you didn't though
[05:58] <hyperair> http://www.virtualbox.org/ticket/41 this says it too
[05:58] <mrooney> smoser: yeah, did :)
[05:58] <mrooney> thanks!
[06:45] <superm1> TheMuso, this was verified with an intrepid disk, so unless they were missing in intrepid too N/A.  I'll reverify with a jaunty daily tomorrow.  I was going to add more stuff to the bug, but launchpad went into maintenance mode 5 or so minutes after I filed it. cjwatson i'll get that added from the jaunty daily as it will be more useful
[07:06] <dholbach> good morning
[07:33] <bryce> heya dholbach
[07:34] <dholbach> hiya bryce
[07:35] <dholbach> hi thekorn, ara, Koon! :)
[07:35] <Koon> o/
[07:35] <ara> hey dholbach, morning :-)
[07:36] <bryce> StevenK: not sure, I've not been following synaptics too closely; check the bug tracker to see if it's known.  If it is, probably needs forwarding to bugzilla.freedesktop.org next.
[07:40] <thekorn> morning dholbach
[07:43] <pitti> Good morning
[07:45] <dholbach> hi pitti
[07:51] <pitti> superm1, slangasek: so after those recent hal-info commits, what's actually left in hotkey-setup? just the module option for the thinkpad? (which should become a modprobe.d script)
[07:51] <pitti> hey dholbach *hug*
[07:52]  * dholbach hugs pitti back
[07:52] <slangasek> pitti: the options that can't currently be set with modprobe..?
[07:52] <pitti> oh?
[07:52] <slangasek> it twiddles bits in /sys
[07:53] <pitti> right, but modprobe install scripts can do that
[07:53] <slangasek> hmm
[07:53] <pitti> well, either way, I was just curious whether there's anything else left
[07:53] <slangasek> would still have to be a separate script because of the complexity, so I don't know that it's really advantageous to move it to modprobe
[07:53] <pitti> so far I'm just aware of that thinkpad module flipping
[07:54] <slangasek> there's also the thinkpad daemon that's run on some hardware, yes
[07:54] <slangasek> /usr/sbin/thinkpad-keys
[07:54] <pitti> slangasek: well, I'd like it to be moved to a modprobe.d script, because then we don't need to penalize every non-thinkpad-laptop user with a no-op init script
[07:54] <pitti> that can still be in the hotkey-setup package, if the rest gets stripped out
[07:55] <pitti> e. g. if all hotkey mappings are migrated now, we should throw them out
[07:55] <slangasek> "throw them out" - I think superm1 already did that?
[07:55] <pitti> oh, so he did!
[07:56] <pitti> (didn't follow -changes in the week I was on holiday)
[07:56] <slangasek> :-)
[07:56]  * pitti hugs superm1
[07:56] <slangasek> I actually started from the other end, so I have a diff here that reduces the ibm.hk to only the essentials, which we can then also get moved over to hal-info sometime soon
[07:57] <slangasek> that leaves the /sys twiddling, the thinkpad_keys daemon (which as a daemon, I think should be managed by an init script...) and one last thing for /proc/acpi/video/*/DOS
[07:58] <pitti> slangasek: daemon init script> *nod*
[08:04] <pitti> slangasek: Keybuk might have a better idea about how to start the thinkpad daemon on thinkpad laptops only (i. e. module load triggered), though
[08:05] <slangasek> pitti: we could not ship a start link for the init script, by default only calling it via modprobe?
[08:06] <pitti> slangasek: right
[08:06] <pitti> (or just put the start-stop-daemon call into the modprobe.d script itself)
[08:06] <slangasek> yeah, I'd rather not do that because it means there's no good way to manage the process
[08:06] <slangasek> invoke-rc.d on upgrades, etc
[08:07] <pitti> right
[08:08] <pitti> kees: was the hardy-security linux -23.48 based on -23.47 in hardy-proposed? or against -23.46 in hardy-updates?
[08:08] <slangasek> doko_: bug #315770> hmm, but why is libio-socket-ssl-perl needed in main?  checkrdepends shows nothing
[08:08] <pitti> kees: if the former, it wasn't verified yet, if the latter, it needs to be merged and reuploaded into -proposed
[08:11] <pitti> jdstrand: ^ or maybe you know
[08:11]  * slangasek wanders bedwards - night, folks
[08:12] <pitti> slangasek: sleep well!
[08:36] <soren> I wish Launchpad would show which archive-admin ACCEPTed stuff, so that I could distribute hugs accordingly.
[08:42] <pitti> soren: if you are talking about NEW, look at the archive day mapping on wiki/ArchiveAdministration
[08:45] <soren> pitti: Hm... Yes, I suppose that's a reasonable approximation. The fact that it seems to have happened in the middle of the night suggests that it's someone with different hemispherocity than myself.
[08:45] <soren> ...so...
[08:45]  * soren hugs StevenK 
[08:46] <pitti> soren: he deserves a hug either way :)
[08:46] <soren> Quite so :)
[08:51] <Necrosan> soren: I am the official hug accepter here.
[08:51] <Necrosan> Dole them out as you see fit.
[08:54] <pitti> lool: rejecing your xine-lib intrepid-proposed upload; it's a merge without merged changelogs (forgot -v), and was perhaps aimed at jaunty?
[08:55] <pitti> lool: ah, perhaps not at jaunty; either way, changelog needs to explain the changes and link to LP bug #s
[09:07] <kirkland> mrooney: pong
[09:07] <evand> Can someone else with access to ubuntu-devel process the mailman queue?  My login information is stored in a still-packed computer that's lacking a keyboard at the moment.
[09:07] <BUGabundo> evand: lol
[09:07] <BUGabundo> evand: you can always retrive it, no?
[09:08] <BUGabundo> although mailman admin/mod login, aint that easy to get
[09:09] <evand> I'd have to ask one of the other individuals with access for the password, or bug IS.
[09:19] <lool> pitti: Uh?
[09:19] <pitti> lool: http://launchpadlibrarian.net/21679435/xine-lib_1.1.15-0ubuntu3.1intrepid1_source.changes
[09:19] <lool> pitti: I merged the security update with the current -proposed upload
[09:19] <lool> pitti: Ok; so you want a clean .changes?
[09:19] <pitti> lool: ah, can you then please reupload with using -v?
[09:20] <lool> pitti: Should I include the original -proposed upload as well?
[09:20] <pitti> lool: yes, please do
[09:20] <lool> Actually I'm not sure I have it anymore
[09:21] <lool> pitti: Hold on before you reject please
[09:21] <lool> Too late
[09:21] <pitti> lool: I rejected it already, but I can fish it out of the rejected queue
[09:21] <lool> pitti: If it's not too long, that would be good
[09:21] <pitti> lool: https://edge.launchpad.net/ubuntu/intrepid/+queue?queue_state=4&queue_text=xine-lib
[09:22] <lool> pitti: Will you also process hardy's unapproved today?
[09:22] <pitti> lool: yes, I'm at it
[09:22] <lool> Great
[09:25] <pitti> lool: can you access that page?
[09:25] <pitti> I'm not sure whether it's restricted to ~ubuntu-archive
[09:25] <pitti> if so, I'll fish it out for you
[09:25] <lool> pitti: Pushing xine-lib_1.1.15-0ubuntu3.1intrepid1.changes again with the initial -proposed upload, the security merge, and the new -proposed upload in the changes
[09:25] <lool> pitti: it's fine I can access it alright
[09:26] <lool> Just finished the new upload
[09:28] <Keybuk> pitti: why do we have yet another daemon for it at all?
[09:29] <pitti> Keybuk: I don't know at all what this is doing; but launching it through a modprobe.d script isntead of rc2.d seems like a good move
[09:29] <Keybuk> why does it exist?
[09:30] <Keybuk> it sounds like the kind of thing that should be a hal add-on
[09:39] <lool> pitti: Thanks for approving xine-lib already
[09:39] <pitti> lool: thanks for doing it
[10:18] <doko_> slangasek: spamassassin libwww-perl libnet-server-perl libnet-ldap-perl suggest it, but maybe these are more recent changes
[10:19] <slangasek> doko_: only suggest?
[10:19] <slangasek> we don't have a closure over suggests in main
[10:19] <slangasek> nor do we want one
[10:19] <doko_> slangasek: but it doesn't show up in component mismatches
[10:22] <slangasek> doko_: OTOH, it also doesn't show up in germinate output AFAICS
[10:23] <slangasek> doko_: so either that's a bug in component-mismatches, or the package is only needed on lpia or something?
[10:24] <slangasek> doko_: nope, not needed on any arch - so I think that's a bug in component-mismatches.  Shall I demote it and see?
[10:25] <slangasek> doko_: oh!  found it - libnet-ldap-perl has a Build-Depends-Indep on it, that didn't get reported by checkrdepends
[10:25] <doko_> slangasek: yes, the demotion sound sounds nicer :)
[10:25] <slangasek> but maybe we can fix libnet-ldap-perl to not need it...
[10:26] <pitti> slangasek: I fixed checkrdepends a while ago to also display B-D-I, weird
[10:26] <slangasek> pitti: checkrdepends gave me a bunch of errors, e.g., grep-dctrl: /tmp/tmp.ZcOkhX1927/jaunty_restricted_Sources: No such file or directory
[10:27] <slangasek> and I was used to getting errors from it the past few times I've used it, so I didn't dig deep enough
[10:27] <pitti> hm, indeed
[10:27] <pitti> will look at that later
[10:28] <slangasek> anyway, libnet-ldap-perl b-d-i seems like a silly reason to pull all those packages into main
[10:28] <pitti> /tmp is probably from gunzip -c
[10:30] <slangasek> well, libio-socket-ssl-perl has been in main since dapper or earlier; but why does it suddenly need all this other junk
[10:31] <pitti> slangasek: seems that there's a newline after 'jaunty', so the command gets split; weird
[10:32] <slangasek> huh, ok
[10:33] <slangasek> doko_, pitti: libnet-ldap-perl only uses libio-socket-ssl-perl for an optional part of its test suite; what do you think about dropping the b-d-i and kicking it (and its deps) to universe?
[10:34] <pitti> slangasek: if that pulls in a whole lot of further libs, fine for me; if it's just that one, I'd rather promote it
[10:34] <doko_> fine for me
[10:35] <slangasek> pitti: there's an MIR right now for the four other perl libs it pulls in
[10:36] <pitti> slangasek: hm, $T/*_Sources expands to jaunty
[10:36] <pitti> _main_Sources
[10:36] <pitti> WTF?
[10:36] <pitti> aaah, found it
[10:37] <pitti> slangasek: apparently a cut&paste error from yesterday's rescue operation
[10:37] <pitti> fixed
[10:38] <alkisg> pitti: Me and some other people are looking for a better user management tool. We saw your evaluation of system-config-users: http://www.mail-archive.com/ubuntu-desktop@lists.ubuntu.com/msg01544.html
[10:38] <slangasek> pitti: cheers
[10:38] <pitti> have to run out for two or three hours
[10:38] <apw> TheMuso, about?
[10:38] <pitti> alkisg: need to run now, please mail pitti@ubuntu.com
[10:38] <alkisg> pitti: ok, ty
[10:39] <slangasek> pitti, doko_: interestingly, the only reason libnet-ldap-perl is in main either is because it's explicitly seeded in supported-development ?
[10:40] <doko_> hmm, maybe ask the server team?
[10:41] <dholbach> hum... where's http://people.ubuntu.com/~ubuntu-archive/removals.txt ?
[10:43] <slangasek> dholbach: bdmurray was asking after it the other day; I don't know whether he found an answer, but I don't know where that's supposed to come from
[10:43] <TheMuso> apw: Yes.
[10:43] <dholbach> slangasek: it always was there :)
[10:43] <apw> TheMuso, i won't ask what time it is there
[10:43] <dholbach> it's even linked from https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing%20Packages :)
[10:43] <slangasek> dholbach: right, but something has to create it. :)
[10:44] <TheMuso> apw: 21:43.
[10:44] <slangasek> and I don't know what that something is
[10:44] <apw> TheMuso, you sync'd alsa-drivers recently with debian
[10:44] <dholbach> slangasek: https://wiki.ubuntu.com/ArchiveAdministration#Removals maybe?
[10:44] <TheMuso> apw: Yes but they have a newer revision I need to get to.
[10:44] <slangasek> dholbach: no
[10:44] <apw> TheMuso, that brought a change to /etc/modprobe.d/alsa-base, which commented out the load of oss
[10:44] <apw> and that is breaking espeak
[10:45] <slangasek> dholbach: we weren't populating it manually - it must have been created by some script, but I don't know what script
[10:45] <TheMuso> apw: Oh right, will fix that when I do the merge. Thanks.
[10:45] <apw> its already uploaded?
[10:45] <TheMuso> apw: No, I need to prepare a merge of 1.0.17a with debian
[10:45] <apw> affecting the jaunty releases, bug #319505
[10:45] <TheMuso> so I'll fix it in that.
[10:45] <TheMuso> apw: and I am following that bug.
[10:46] <TheMuso> apw: thanks for the heads up.
[10:47] <slangasek> doko_: well, we can check with the server team, but they didn't add it; it traces back to the original bzr import of the seeds, so there's no specific rationale :)
[10:47] <apw> TheMuso, the change occured cuase of a threat (literally) from the debian kernel team about alsa sharing not working if they were loaded, so i need to work out if that is also true fo rus
[10:47] <TheMuso> apw: ok
[10:48] <TheMuso> anyway I'm off for the evenin.
[10:48] <TheMuso> evening
[10:48] <TheMuso> apw: You got me just in time. :p
[10:48] <apw> TheMuso, have a good one, will update the bug with my findings
[10:49] <slangasek> cjwatson: you don't remember a rationale for the set of perl packages listed in supported-development, do you? :)
[10:54] <cjwatson> ArneGoetje: cool, thanks
[10:56] <cjwatson> dholbach: removals.txt is no longer relevant because all its data was migrated into Launchpad
[10:56] <cjwatson> slangasek: ^-
[10:57] <slangasek> ok
[10:57] <cjwatson> dholbach: so if you look at https://launchpad.net/ubuntu/+source/<src> and follow links, you should see the removal reason etc.
[10:58] <cjwatson> dholbach: we have a backup copy in case somebody does need the old file, but it shouldn't be necessary any more
[10:59] <dholbach> cjwatson: THANKS muchly
[11:00] <dholbach> cjwatson: I'll update the docs referring to it
[11:01] <__doc__> hi, anybody of you has got a device from 3dconnexion (space ball, navigator etc.?)
[11:02] <cjwatson> dholbach: thanks
[11:06] <ogra> cjwatson, fyi, versatile netboot installer seems to work well in qemu
[11:13] <cjwatson> ogra: superb
[11:13] <ogra> though ports seems down
[11:13] <ogra> ah, not anymore
[11:14] <cjwatson> ogra: http://cdimage.ubuntu.com/ports/daily/current/jaunty-alternate-armel.iso managed to spit something out at least
[11:14] <cjwatson> no kernel or initrd on that though
[11:14] <ogra> yep, i'm just trying that with the netboot installer
[11:14] <ogra> though i wanted to try a normal netinstall first
[11:15] <cjwatson> base-installer might not get kernel selection right
[11:15] <cjwatson> yeah, doesn't look like it uses the metapackages
[11:15] <ogra> but it should offer me to go on without kernel, no ?
[11:15] <cjwatson> maybe
[11:15] <ogra> first i have a different prob though, seems qemu cant resolve
[11:16] <ogra> hmm, or route ... weird, i can ping the gateway but it doesnt get forwarded
[11:17]  * apw has a blank moment, what was the command which let you edit the src directly and made a patch out of it when you exit'd
[11:17] <cjwatson> ogra: it would be useful if you could send me /proc/cpuinfo from that emulated machine
[11:17] <Mithrandir> dpatch-edit?
[11:18] <cjwatson> apw: run what-patch first to find out which patch system the package already uses
[11:18] <ogra> cjwatson, well, it works with my homebrewed kernel usually, i guess its a kernel issue ... i'll try the netinstaller with that one
[11:18] <cjwatson> apw: you generally need to run a command appropriate to the package
[11:18] <cjwatson> ogra: no, I want /proc/cpuinfo because base-installer's kernel test suite needs a copy of it :P
[11:18] <apw> quilt
[11:19] <ogra> cjwatson, ah, k, you'll get it :)
[11:19] <cjwatson> apw: 'export QUILT_PATCHES=debian/patches' and then use quilt normally
[11:19] <cjwatson> apw: that package won't be suitable for the tools that produce a complete copy of the source for you to edit
[11:19] <apw> ahhh, now that is why people moved to quilt
[11:20] <apw> if one is modifying the debian part of a package sync'd from debian (a file in debian which is copied in wholesale) should you be adding that as a patch in the patches directory or just modifying it directly?
[11:21] <cjwatson> just modify it directly
[11:21] <apw> makes life easy :)
[11:22] <ogra> cjwatson, http://paste.ubuntu.com/111192/
[11:23] <cjwatson> ogra: thanks, pastebin tends to mash tabs though. Could you put it on people?
[11:24] <ogra> sure
[11:24] <slangasek> Keybuk: udevadm trigger --action=change isn't documented in the --help output, and only --action=add is documented in the manpage...
[11:25] <ogra> cjwatson, http://people.ubuntu.com/~ogra/arm/qemu/cpuinfo
[11:41] <cjwatson> ogra: thanks, grabbed
[11:41] <ogra> cjwatson, any idea why i cant get over the NAT gw from the VM ?
[11:41] <ogra> works if i just bootstrap a system ...
[11:42] <cjwatson> err, no idea
[11:42] <ogra> so it seems to be an issue with d-i
[11:42] <cjwatson> my approach to qemu networking is to hope it works
[11:43] <ogra> ARGH !
[11:44]  * ogra slaps forehead intil it turns red
[11:44] <ogra> *until
[11:44]  * ogra makes note to next time read carefully what d-i asks him :P
[11:44] <highvoltage> don't stress, ogra
[11:45] <apw> though it is fun to watch
[11:45] <ogra> http:// is not really liked by the mirror input
[11:45] <hyperair> is there a way to get qemu to work with ia64 archs?
[11:45] <hyperair> i'm looking for an ia64 buildd
[11:45] <ogra> its so long ago that i actually used d-i with all these questions :P
[11:45] <hyperair> qemubuilder looks promising, but no ia64 support from qemu
[12:05] <asac> TheMuso: http://launchpadlibrarian.net/20109106/at-spi_1.25.1-0ubuntu2_1.25.2-0ubuntu1.diff.gz
[12:05] <asac> TheMuso: you a) dropped my changelog entry
[12:05] <asac> TheMuso: and b) dropped the patch i added
[12:06] <asac> TheMuso: without a comment ... has this been applied upstream?
[12:06] <asac> TheMuso: i doubt it has been.
[12:06] <ogra> bah, partman takes ages in qemu
[12:06] <asac> TheMuso: debian/patches/05_lp278095_no_environ_access_shutdown.patch
[12:06] <asac> TheMuso: can you readd that? i receive crash reports on firefox again :)
[12:07] <asac> TheMuso: also please readd my changelog entry ... so i dont have to hunt that info on launchpad :=)
[12:21] <asac> TheMuso: alternatively let me know and i can do this ;)
[12:40] <seb128> mvo: could you look to bug #321919?
[12:58] <ogra> cjwatson, base install in qemu is almost done, would be helpful to have ports.ubuntu.com in the preseed file somehow (and indeed the ubuntu-ports dir)
[13:03] <cjwatson> ogra: it should detect it automatically. Which bit didn't detect it?
[13:03] <cjwatson> (the design is that this does not require preseeding)
[13:03] <ogra> oops, console setup just trashed the d-i frames
[13:03] <cjwatson> hmm, new base-installer defaults armel to MODULES=dep
[13:04] <cjwatson> I guess that's reasonable
[13:04] <ogra> cjwatson, well, it asks for a mirror
[13:04] <ogra> and only offers manual input there
[13:04] <ogra> nothing preselected
[13:04] <cjwatson> so the mirror selection component. ok
[13:04] <ogra> and the dir is set to /ubuntu/ instead of /ubuntu-ports/
[13:04] <cjwatson> I can fix that easily
[13:04] <ogra> great
[13:04] <cjwatson> heh, that was never fixed for lpia either
[13:05] <persia> mpt, regarding your comment that ichthux and ubuntume provide filtering controls: are those general solution that are but an apt-get away for other sorts of installs?
[13:05] <ogra> ah, and it seems to let me properly go on without kernel
[13:05] <persia> For lpia we just preseeded it away in the MID image, because there was only the MID image that worked.
[13:06] <ogra> oh, fun now the trashed d-i UI frames changed back to look proper
[13:07] <ogra> oh, wow, i havent seen the automatic updates question yet
[13:08] <asac> TheMuso: ok. false alert i think. the code looks ok now
[13:09] <cjwatson> ogra: fixed for the next d-i build
[13:12] <ogra> cool !
[13:54] <cjwatson> Keybuk: so, empirically, the first obvious effect of removing udevadm trigger from the installer is that it stops being able to detect the network card
[13:54] <cjwatson> Keybuk: and it refuses to do so until I run udevadm trigger; settle
[13:55] <cjwatson> (as in, /sys/class/net contains only lo; upon running udevadm trigger eth0 it appears immediately)
[13:55] <cjwatson> s/it //
[13:55] <elmo> so, err, someone (keybuk) I think, once told me 'udevadm trigger' was how to get the system to see a hot-added RAID array
[13:55] <elmo> what is it in the new world order?
[13:55] <cjwatson> now I know that class devices aren't guaranteed to show up especially immediately but still ...
[13:56] <cjwatson> elmo: my understanding is that trigger is not necessary (any more?) because anything that trigger does should already be in udevd's queue
[13:56] <cjwatson> so ISTM that it's a bug if trigger is needed
[13:57] <elmo> ah, ok
[14:09] <Keybuk> cjwatson: we'll look at the sprint
[14:10] <Keybuk> I'd guess that the network card modules weren't there when udev's installer-startup script ran udevtrigger
[14:10] <Keybuk> and they were installed later
[14:11] <mpt> persia, no idea, all I know is that their Web sites advertise them.
[14:12] <persia> mpt, OK.  I'll chase up with AnAnt or txwikinger at some point then.  Thanks.
[14:16] <cjwatson> Keybuk: that's common practice in d-i
[14:17] <Keybuk> but you don't try and modprobe them?
[14:17] <cjwatson> probably at some point
[14:17] <cjwatson> oh, not like individual network card drivers no
[14:31] <rickspencer3> asac: ping
[14:31] <asac> rickspencer3: hi
[14:32] <rickspencer3> I saw your policy page. Do you want me to type it into pros?
[14:32] <rickspencer3> It looks quite complete, btw
[14:33] <asac> rickspencer3: i think its ok to use the form currently used. I think what we need is some intro text explaining a bit the rational and the spirit of this
[14:33] <asac> and cleaning up the things in brackets et al.
[14:34] <rickspencer3> So you want me to do some wiki gnomiing? Just clean it up here and there?
[14:34] <evand> Anyone have experience with libglade and custom widgets?  The documentation tells me to use the custom widget container, but glade says that it's deprecated.
[14:34] <rickspencer3> asac: Is there an example of a complete policy somewhere on the wiki that would make a good example?
[14:35] <seb128> evand: that doesn't reply to your question but you should try using gtkui nowadays
[14:36] <asac> rickspencer3: Maybe MainInclusionProcess
[14:36] <seb128> evand: otherwise mvo might know about glade specifics
[14:36] <rickspencer3> asac: thnaks
[14:36] <asac> rickspencer3: but well :) ... thats not really more
[14:37] <asac> rickspencer3: i think its really just cleaning up; fix wording and do some intro text
[14:37] <rickspencer3> asac: sure. Whatever I can do to help. n/p
[14:38] <evand> seb128: ok, thanks.  I'm not familiar with gtkui and a google search just lists a bunch of modules for various projects that use a similar name.  Do you have a link to some documentation?
[14:40] <seb128> evand: http://library.gnome.org/devel/gtk/stable/GtkBuilder.html
[14:40] <evand> ah, indeed
[14:40] <evand> thanks!
[14:40] <seb128> you're welcome
[14:40] <seb128> that's the gtk equivalent of libglade
[14:40] <seb128> evand: you have scripts to convert .glade to .ui
[14:41] <seb128> evand: gtk-builder-convert
[14:41] <evand> neat
[14:42] <cjwatson> yeah, that postdates ubiquity's original use of glade and we never converted
[14:43] <asac> rickspencer3: also there is StableReleaseUpdates
[14:43] <evand> cjwatson: any objection to converting to gtkbuilder format at some point over the course of Jaunty development (before FF)?
[14:44] <rickspencer3> asac: tx
[14:46] <calc> anyone know why kdelibs4-dev is not installable on most architectures?
[14:47] <calc> kdelibs4-dev is for kde 3 btw
[14:48] <ScottK> Probably libdrm-dev not installable
[14:49] <calc> ScottK: is that going to be fixed soon?
[14:49]  * ScottK looks at bryce
[14:50] <calc> its breaking OOo so hopefully so ;-)
[14:50] <ScottK> calc: When I looked at it, it seemed that libdrm-dev had a versioned depends on a particular kernel version that wasn't satisfied on any ports arch except armel.
[14:50] <calc> well whatever is making kdelibs4-dev on all non amd64 arch is anyway ;-)
[14:51] <ScottK> If it's catching i386, then it may well be another problem too.
[14:51]  * ScottK looks into it.
[14:51] <calc> well not sure about i386 its been held by stlport atm
[14:51] <Riddell> calc: actually we were going to ask you about dropping kdelibs4c2a from ooo
[14:52] <Riddell> calc: can you make ooo just use the Qt stuff but not the KDE native dialogue stuff?
[14:52] <calc> Riddell: hmm maybe, i'm not certain
[14:52] <calc> if some kde hacker wants to fix kde4 support in OOo that would be great too :)
[14:53] <Riddell> calc: yes that would be the best option of course
[14:53] <cjwatson> evand: not at all, as long as it can work with something like the separated glade file format we have
[14:53] <evand> cjwatson: ok, I'll look into it
[14:53] <calc> Riddell: so the libdrm thing is why its not installable anywhere for right now?
[14:55] <ScottK> That's at least why KDE 4.2 FTBFS on everything except i386, amd64, and armel.
[14:55]  * calc notes his connection may drop soon due to at&t working on the line, its not that he just decided to leave, heh
[14:55] <Riddell> calc: dunno, let me look
[14:56] <calc> Riddell: ok
[14:57] <Riddell> calc: apt is installing it here on my system and in a chroot
[15:00] <calc> Riddell: yea according to scottk it should be failing on most arch due to libdrm being uninstallable
[15:00] <Riddell> libdrm-dev installs for me
[15:00] <Riddell> on i386
[15:01] <ScottK> Yeah, on i386 that's fine.
[15:01] <ScottK> It's the non-armel ports archs
[15:01] <calc> ScottK: is bryce already aware of the issue, i didn't see a bug about it in LP
[15:02] <ScottK> No idea.
[15:02] <ScottK> It's been on my list to ask.
[15:02] <calc> i'll file a bug with some of this log in it
[15:03] <ScottK> You can toss in some kde4libs build logs too if you want.  It failed on all the same archs (which is why I know)
[15:03] <cjwatson> oh, presumably due to kernel desync then
[15:04] <cjwatson> linux-ports desperately needs to be brought into sync
[15:05] <calc> bryce: ping
[15:06] <ScottK> Prior to this we had KDE bulding very nicely on all the ports archs except hppa (and that due to a soyuz bug).
[15:06] <cjwatson> Soyuz bug as in missing architecture: all packages, or something else/
[15:06] <cjwatson> ?
[15:07] <ScottK> cjwatson: Yes.  It's the "If p-a-s says skip any binaries, let's just skip the build for the whole source package" bug.
[15:07] <cjwatson> so you mean "no" :-)
[15:07] <cjwatson> (that's not the bug I was thinking of)
[15:07] <ScottK> Now that I've read what you wrote again, yes.  I meant no.
[15:07] <ScottK> ;-)
[15:10] <johanbr> I'll just restart X. Brb...
[15:11] <mdeslaur> siretart: thanks for the xine-lib merge!
[15:23] <slytherin> Keybuk: Since you are the last uploader of mouseemu, I was wondering if you have any idea why having mouseemu installed is causing problem with permission for /dev/null, /dev/console.
[15:24] <slytherin> Keybuk: directhex suggested it because of presence of udevadm in the init script.
[15:24] <cjwatson> slytherin: I tried to tell you at the time but you'd left: mouseemu only calls udevadm settle, not udevadm trigger
[15:26] <slytherin> cjwatson: Then what could be the problem.
[15:26] <DexterF> hi
[15:26] <cjwatson> slytherin: no idea
[15:26] <slytherin> ok.
[15:26] <cjwatson> but don't pick on it just for using a udevadm command that isn't the one Keybuk identified as breaking stuff ...
[15:27] <tjaalton> ScottK: why would libdrm-dev block the installation of kdelibs4-dev?
[15:27] <slytherin> hmm. so I will have to digg deeper. I will take a look at it when I go home.
[15:30] <ScottK> tjaalton: When I looked at it, that's where the dependency chain stopped.  It's blocking X -dev installs (I forget exactly which package).
[15:30] <tjaalton> ScottK: ok
[15:31] <tjaalton> I've no idea if the ports kernels are going to be updated to 2.6.28 anytime soon, so maybe it needs something else
[15:31] <ScottK> I didn't actually check it for kdelibs4-dev (KDE3), but I did for kde4libs FTBFS.  I'm pretty sure it's the same issue.
[15:32] <slytherin> is anyone working on fixing FTBFS of xorg-server on non i386/amd64 arch? Looks like issue is due to old linux-headers
[15:32] <tjaalton> slytherin: exactly the same issue as above
[15:32] <slytherin> tjaalton: ahh, just saw your message
[15:32] <tjaalton> drm headers moved to the kernel since 2.6.28-4
[15:33] <tjaalton> and I don't understand why the lpia kernel didn't use the same ABI, so libdrm needs to be fixed to match .28-1 for lpia..
[15:33] <ScottK> I don't suppose there's some way libsrm-dev could continue to provide them for the older kernels?
[15:33] <tjaalton> ScottK: different packages for different archs?
[15:34] <tjaalton> somehow I don't like the idea ;)
[15:34] <ScottK> Some arch specific ifdef magic?  Dunno, just know that change totally broke ports.
[15:41] <tjaalton> ScottK: one possible short-term fix would be to not depend on linux-libc-dev on the ports, until they provide the kernel
[15:41] <tjaalton> that would only break some X driver builds
[15:41]  * calc found out at&t is going to be digging around in his yard soon
[15:43] <ogra> sigh, d-i in qemu is really taking its time ...
[15:44] <ScottK> tjaalton: I don't know enough to have an opinion on how best to proceed.
[15:45] <cjwatson> pgraner: ^- see above discussion about linux-ports
[15:45] <cjwatson> pgraner: the desynchronisation is causing userspace problems
[15:45] <tjaalton> pgraner: indeed..
[15:46] <slytherin> how about getting ports kernels updated. :-) But AFAIK, TheMuso is already working on that.
[15:46] <pitti> geser: o_O "$ pkcon resolve hal" -> Fehler: package-not-found : Package name pkcon could not be resolved
[15:46] <pitti> geser: I noticed that my jockey test suite fails, and it seems that pkcon mixes up the package name nwo?
[15:46] <tjaalton> well, adding this band-aid solution would at least allow the non-X parts to build
[15:47] <pitti> geser: sorry, that should have been "glatzor"
[16:00] <Baby> does anyone know how to activate GLX in Xephyr?
[16:09] <Tm_T> ok, should I scream it here if xine packages breaks with dpkg ?
[16:09] <cjwatson> you should file a bug
[16:10] <Tm_T> hrrr, have to try to find working browser then
[16:12] <Baby> you're free to scream if you want too, anyway ;)
[16:13]  * ogra points Tm_T to man ubuntu-bug 
[16:16] <Tm_T> ogra: aaah, that's new to me
[16:16] <Tm_T> anyway, got Konq to work, so, http://paste.ubuntu.com:80/111264/
[16:20] <Tm_T> so something weird happens that causes dpkg: ../../src/packages.c:221: process_queue: Assertion ependtry <= 4' failed.
[16:29] <cjwatson> Tm_T: should be fixed in jaunty
[16:30] <Tm_T> cjwatson: I'm in intrepid, hmmm, so this wasn't my doings then
[16:31] <jcastro> mvo: iirc update-manager disables PPA addresses on upgrade right?
[16:32] <Tm_T> cjwatson: thanks, have to look about this, I got interested
[16:33] <james_w> jcastro: it does. It has a whitelist though, not sure if any PPAs are in that
[16:34] <jcastro> james_w: I was just thinking that it might be a good idea to do a rename on the urls for the new PPAs on the next upgrade
[16:35] <james_w> jcastro: it could probably do that as it disables them.
[16:35] <james_w> jcastro: the worth of it depends on how long the old URLs work I imagine
[16:35] <jcastro> or at least leave a note in a comment
[16:35] <james_w> if they get turned off soon then most people will have had to deal with it before upgrade
[16:35] <mvo> jcastro: yes
[16:36] <mvo> jcastro: the trouble is that external repos (including ppa) quite frequently screw the upgrade calculation
[16:36] <mvo> this is why the external repositories are dissabled during upgrades, there is now a config option to override that
[16:37] <jcastro> mvo: how about a note in the comments when you disable it with a link to the new URL or something?
[16:37] <jcastro> mvo: informing people that the url has changed would be easier than trying to do it for them I think
[16:38] <mvo> jcastro: sure, I could do that, disable and update in one go so that its easier for them to re-enable it
[16:38] <mvo> jcastro: that is a good idea
[16:39] <jcastro> mvo: yeah, they have to reenable it by hand anyway, so if there's a comment there that will cover people who miss the announcements.
[16:43] <mvo> jcastro: thanks, I add that
[16:44] <jcastro> <3
[16:46] <ScottK> mvo: Do you think there's still time for you to work on the backports improvement spec if it were approved?
[16:46] <ScottK> No point in pushing for someone to approve it if not.
[16:46] <mvo> ScottK: what is the url for that?
[16:46]  * ScottK should have anticipated you'd ask that.  Just a moment.
[16:46] <mvo> ScottK: was that the idea to have backports show up unticked in update-manager?
[16:47] <mvo> ScottK: or to use "NotAutomatic: yes" in the release file?
[16:47] <ScottK> It was the NotAutomatic: yes one.
[16:47] <ScottK> https://blueprints.launchpad.net/intrepid-backports/+spec/selective-backport-support
[16:47] <ScottK> mvo: ^^
[16:50] <mvo> ScottK: I sitll like the idea, let me check how much effort it would be
[16:50] <evand> mvo: I noticed you're using the Custom object in libglade.  I need to make use of this, but noticed that it's deprecated in glade.  Any idea what's intended to replace its functionality?
[16:50] <ScottK> mvo: Thank you.
[16:51] <mvo> evand: no, sorry. my guess is gtkuibuilder, but I have not worked that much with it yet, I don't like the addtional glade->ui file step (not a biggie of course :)
[16:51] <evand> mvo: ok, no worries
[16:51] <evand> and thanks
[16:52] <mvo> cheers (also there is not a lot to thank for unfortuantely :/)
[16:54] <superm1> evand, so is the thought to just use '.ui' files instead of glade files then, or '.ui' files specifically where you need the custom widgets?
[16:54] <mvo> jcastro: commited
[16:55] <evand> superm1: to evaluate GtkBuilder and move to that if it's not too much of a headache (that is, we don't have to merge all the glade files back together)
[16:56] <cjwatson> I don't think we'd want a *mix* of .ui and .glade
[16:56] <evand> indeed
[16:56] <superm1> besides the custom widget support, what other benefits does GtkBuilder bring to the table?
[16:57] <jcastro> mvo: um, wow, that was fast, thanks!
[16:58] <evand> I haven't discovered custom widget support in it yet, but I've found this helpful in explaining the differences between the two: http://www.micahcarrick.com/05-30-2008/gtk-builder-libglade-faq.html#3
[17:08] <mvo> ScottK: my current (hopefully not too naive) feeling is that it can done reasonable painless with update-manager so I would say we should write the spec and make update-manager the first target for the implementation
[17:10] <ScottK> mvo: OK.  If you could scribble on https://wiki.ubuntu.com/Backports/SelectiveInstallation a bit with some idea, I can work on fleshing it out.
[17:10] <ScottK> mvo: Thanks for looking into it.
[17:10] <superm1> evand, if worst comes to worst, and gtkbuilder doesn't support using multiple .ui files and/or doesn't support custom widgets, you could always just leave a container in the glade file and add the widgets in the python source i'd think.
[17:10]  * ScottK points NCommander at the discussion above ...
[17:11] <mvo> ScottK: I think we should go with notautomatic instead of pinning, that should make it easier
[17:11] <mvo> ScottK: I'm testing some ideas right now, hopefuly I should have a better opinion by tonight :)
[17:11] <ScottK> mvo: OK.  I'm more interested in the result than the design.  I think backports will become immeasuably more usable if people can enable it and leave it on without fear of unwanted upgrades.  Thanks.
[17:12] <ScottK> Pinning was NCommander's idea anyway ....
[17:12] <mvo> ScottK: agreed!
[17:12] <mvo> ScottK: thanks for the reminder about it, its one of the things that should really be done :)
[17:12] <NCommander> er, what?
[17:13]  * ScottK slaps NCommander around a bit, just to keep him dazed and confused.
[17:15] <tseliot> sabdfl1: you've got mail ;)
[17:17] <evand> superm1: indeed, though I'd ideally like to avoid that :)  Someone on #gtk+ helped me with custom GTK widgets, so I may have that sorted shortly.
[17:34] <davmor2> the new pulseaudio update seems to remove my intel hda audio device from output on Sound Preferences and I get no audio after the login music
[18:06]  * robbiew  fights with broadband...using windows right now...rebooting back to linux and crossing fingers
[18:28] <calc> at&t is running a new wire to my house :)
[19:34] <DexterF> will open vm tools provide me a working Xserver for kub8.10 running in vmware workstation 6.5.0?
[19:58] <directhex> seems my new graphics card definitely doesn;t work on intrepid, with nv or nvidia
[20:08] <calc> i got at&t to upgrade my line the day after i get back from germany :)
[20:08] <calc> going from 3.0/0.5 to 10.0/1.5 :)
[20:08] <calc> still not as good as FIOS but not too shabby
[20:11]  * ScottK hugs his FIOS.
[20:28] <calc> i bet at&t will roll out better stuff once comcast here rolls out their 50/10 this summer
[20:52] <redvamp128> quick question-- where can I find the changelog for kernel updates?
[20:53] <RAOF> aptitude changelog linux
[20:54] <redvamp128> last night I downloaded it and clicked on the update description and it was unavailible
[20:55] <redvamp128> Though one thing to note-- this one seems to make the hard drive a little more quiet
[20:55] <redvamp128> 2.6.24-23
[20:58] <redvamp128> RAOF:  thanks that worked--
[20:58] <ogra> cjwatson, fyi my netinstall finished properly
[21:00] <redvamp128> I know this is a room for ubuntu development-- but I have an interesting issue with using LXDE window manager-- lack of volume control -- has anyone heard of this issue?
[21:01] <redvamp128> Gnome-openbox or Gnome does not have this issue or the XFCE (XUBUNTU-desktop)
[21:02] <kees> doko_: in openjdk-6's Makefile.in, there is this line:
[21:02] <kees> 	  $(TAR) xf $(OPENJDK_SRC_ZIP) -C openjdk; \
[21:03] <kees> since OPENJDK_SRC_ZIP in a tar.gz, tar execs gzip.  but the Makefile.in has exported the "GZIP" environment variable.
[21:03] <kees> gzip will think this is a cmdline argument and die.
[21:04] <kees> later in the Makefile, you can see work-around for this:
[21:04] <kees> GZIP=$(GZIP_ENV) gunzip -c $(distdir).tar.gz ....
[21:04] <kees> doko_: so, mostly, I can't understand how the buildds don't explode when my local builds do.
[21:06] <mneptok> kees: i blame usplash-mnepolo
[21:06] <kees> mneptok: haha, it was pwning my eyes, so I uninstalled it.  :)
[21:10] <cjwatson> ogra: woo
[21:40] <doko_> kees: it's not used, the ALTERNATE_something is used
[21:41] <kees> doko_: something weird is going on with it, but I've worked around it
[21:42] <doko_> works without problems for me
[21:43] <kees> yeah, I think "make" is doing something funny because I have GZIP in my environment
[21:44] <cjwatson> kees: make re-exports variables if they're already present when it starts
[21:44] <cjwatson> kees: more precisely, it leaves their export status alone
[21:44] <kees> cjwatson: ah-ha.  that would do it.
[21:44] <kees> i have an exported GZIP, and when the Makefile sets it to /bin/gzip, the build explodes.  wheee
[21:45]  * kees swore sbuild cleared the environment
[21:45] <cjwatson> kees: you may need either 'export GZIP' or 'unexport GZIP' depending on the direction of the problem
[21:45] <slangasek> sounds like 'unexport GZIP'''
[21:45] <kees> yeah
[21:46] <kees> ah... it's just debuild that had the preserved list...
[21:58] <TheMuso> aw/
[22:22] <kees> doko_: how do you avoid dpkg-source -b screaming about your @lists.launchpad.net Maintainer field?
[22:23] <doko_> kees, oh didn't see it. maybe I should patch it in when generating the control file
[22:25] <cjwatson> my usual solution is DEBEMAIL=cjwatson@debian.org dpkg-whatever
[22:25] <cjwatson> then it's just a warning
[22:25] <cjwatson> we should probably extend dpkg to recognise @lists.launchpad.net as valid for Ubuntu
[22:26] <TheMuso> 8/c
[22:28] <kees> cjwatson: I was pondering that, and I'm not sure it makes sense since upstreams (not in Ubuntu) can use that address too
[22:30] <cjwatson> hmm
[22:35] <DexterF> can't find a package containing /usr/share/kde4/services/desktopthemedetails.desktop
[22:36] <kees> cjwatson: i.e. if I set my DEBEMAIL to something non-ubuntu, it will warn?
[22:36] <DexterF> pointers where I might find that? wanna change the plasma looks on kde4
[22:37] <cjwatson> kees: rather than error, yes
[22:38] <ScottK> DexterF: http://packages.ubuntu.com/search?searchon=contents&keywords=desktopthemedetails.desktop&mode=exactfilename&suite=jaunty&arch=any
[22:38] <DexterF> ScottK: plain weird. I installe kdebase-workspace, shouldn't that have pulled it as a dep?
[22:39] <ScottK> DexterF: I'd have thought so.  Do you have kdebase-workspace-data installed?
[22:41] <DexterF> ScottK: actually, yes. but the file isn't on disk. dpkg -L doesn't list it as well.
[22:41] <ScottK> DexterF: --> #kubuntu-devel
[22:41] <ScottK> Let's discuss there.
[22:47] <blueyed> redvamp128: "aptitude changelog linux"?
[22:47] <slangasek> aw man, why does aptitude keep adding features that lure people into using it
[22:47] <blueyed> (sry, backlog has not scrolled - and I've typed the nick by name, without realizing) ;D
[22:47] <elmo> slangasek: they should be using dselect instead?
[22:48] <slangasek> elmo: synaptic/update-manager > apt-get > dselect > aptitude :P
[22:49] <azeem> where's package-kit in there?
[22:49] <directhex> slangasek, you missed the "ar, gzip, tar, & vi" method of debian package management
[22:49] <blueyed> The question really is, why does apt not support "changelog"? or is there some other tool which allows fetching changelogs?
[22:49] <slangasek> azeem: between dselect and aptitude, maybe
[22:50] <directhex> dselectitude. there's a summer project
[22:50] <azeem> aptitussy
[22:51] <slangasek> blueyed: because apt-get was always intended to be a back-end tool, except that aptitude as a front-end sucks because its author screws around with the dependency resolver
[22:51] <blueyed> ..which combines apt-get install and less /usr/share/doc/../changelog.gz
[22:51] <cjwatson> slangasek: we're likely to be using aptitude for manual package selection in the installer once I get the relevant plumbing working again
[22:51] <blueyed> slangasek: I've never used the aptitude frontend
[22:51] <cjwatson> I think the server team would lynch me if I made them use dselect
[22:52] <cjwatson> ... maybe that should be a hidden preferene
[22:52] <cjwatson> c
[22:52] <slangasek> cjwatson: can we arrange to never display the fact that it's 'aptitude'? :)
[22:52] <slangasek> using aptitude interactively is fine
[22:52] <slangasek> letting it resolve things on its own is suicide
[22:52] <cjwatson> the tasksel UI would just say "Manual package selection"
[22:52] <cjwatson> I don't know whether it says it's aptitude in its UI; I assume it does
[22:52] <slangasek> yeah
[22:53] <slangasek> time to patch the .po files ;)
[23:06] <TheMuso> susudo adduser account-name
[23:06] <TheMuso> woops wrong window
[23:21]  * Mez wonders why 1280x960 is no longer a valid screen resolution
[23:51] <YokoZar> Would anything break if we changed the useragent string in Firefox to identify us as "Ubuntu" rather than as "Linux" ?  Over time, that would allow us to count Ubuntu users much more accurately.
[23:53] <james_w> Ubuntu is already in the user-agent
[23:55] <savvas> Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.5) Gecko/2008121623 Ubuntu/8.10 (intrepid) Firefox/3.0.5
[23:55] <YokoZar> james_w: so how come all the websites publishing browser statistics just say "Linux" ?
[23:55] <savvas> correct
[23:55] <james_w> YokoZar: well, there's a difference between OS and vendor
[23:55] <james_w> presumably they are just recording OS
[23:55] <savvas> Because we're not that big yet :P And we're a strong community hehe
[23:56] <YokoZar> Basically I want to count Ubuntu users using this sort of metric: number of people on web times percentage on linux times percentage of linux on ubuntu -- those last two steps could be much more accurate if they just used that data
[23:57] <YokoZar> admittedly we probably have a disproportionate (compared to other OSes) number of users not on the web, so this would undercount Ubuntu a bit
[23:58] <ajmitch> why do you think there's a disproportionate number not on the web?
[23:59] <savvas> YokoZar: so how do you know which company's web site to count?
[23:59] <savvas> google.com or msn.com search? what if microsoft or google forge numbers to favour something else?