[00:04] <dupondje> seb128: its still broken ?
[00:04] <dupondje> argh, nvm
[00:05] <seb128> dupondje, should be fixed in 2.17.5-0ubuntu2 when it will be published on the mirrors
[00:05] <seb128> you can download the deb from launchpad too
[00:36] <dtchen> kirkland: which players (and backends)? the only issues i've had for my hardware and software are related to xine and reenabling glitch-free for testing.
[00:36] <dtchen> kirkland: please file a bug with that info, and i'll look
[00:37] <kirkland> dtchen: i'll get it for you
[00:38] <dtchen> jdstrand: not to appear daft, but have the speakers been replaced with headphones as another test?
[00:44] <kirkland> wow, gdm is in a bad way
[00:45] <dtchen> even with gtk+2.0 2.17.5-0ubuntu2 bits installed?
[00:46] <kirkland> dtchen: hmm, i think so
[00:47] <kirkland> dtchen: specifically what packages?
[00:47] <kirkland> oh, wait
[00:47] <kirkland> i have a few on 0ubuntu1
[00:47] <dtchen> libgtk2.0\*
[00:49] <kirkland> dtchen: yeah, i'm on 2.17.5-0ubuntu1
[00:51] <YokoZar> kees: Can you give any links ~https://bugs.launchpad.net/ubuntu/+source/wine/+bug/401950  so I can file a good upstream bug telling them how to do it?
[00:52] <kees> YokoZar: well.... I can try.  Wine would be the first package to use filesystem capabilities, so it's kind of new territory.
[00:52] <YokoZar> kees:  Is it documented anywhere?  That might be enough.
[00:52] <kees> YokoZar: I'll go look, there are two halfs: fscaps itself, and the dropping of the capability after memory is allocated
[00:53] <kees> YokoZar: I will try to get pointers to both
[00:53] <YokoZar> Thanks
[01:05] <kees> YokoZar: okay, added some examples with URLs
[01:05] <YokoZar> Thanks kees
[01:06] <kees> np, thanks for poking me to get those -- I couldn't find them earlier.  :)
[01:17] <reed> Has Ubuntu Moblin Remix actually been created yet?
[01:58] <robert_ancell> Has anyone here used PolicyKit before?
[02:22] <robert_ancell> kenvandine, ping if you are up
[03:01] <jdstrand> dtchen: the speakers work-- I plugged my music player into them and listened on them all day :)
[05:37] <jml> slightly OT, but you might like to know that Launchpad is now open sourced. https://dev.launchpad.net/.
[05:47] <ScottK> jml: All of it or some of it?
[05:48] <jml> ScottK: all of it.
[05:48] <ScottK> jml: Welcome news.  Congratulations.
[05:48] <jml> but don't trust me! there's code to be looked at :)
[05:48] <Hobbsee> yay!
[05:49] <ScottK> jml: It's nearly 1AM here and I have to be out the door for $WORK stuff by 6AM, so I'll trust you on the short version for now.
[05:50] <jml> :)
[05:50] <jml> anyway, the party's on #launchpad-dev if you'd like to join us.
[05:51]  * ScottK is already there.
[05:51]  * ghindo is going.
[05:56] <mneptok> wait, Soyuz is open, too?
[05:57] <LaserJock> mneptok: yep
[05:57] <mneptok> nice.
[05:57] <mneptok> i can't wait to run it on my G1 phone.
[05:58] <mneptok> *bah dum tish*
[06:27] <pitti> Good morning
[06:32] <ruslanr> pitti: good morning :)
[06:58] <emgent> GOOD MORNING! http://seclists.org/fulldisclosure/2009/Jul/0279.html
[07:02] <cjwatson> emgent: OpenSSH upstream have no knowledge of the vulnerability; if you do, by all means share
[07:03] <cjwatson> (or at least they had no knowledge a few days ago when it last came up on openssh-unix-dev)
[07:03] <emgent> i think that anti-sec people mailed upstream
[07:04] <cjwatson> upstream explicitly denied having any inside information, and I know them well enough to know they'd just keep quiet if they did
[07:04] <emgent> uhm ..
[07:04] <cjwatson> anyway, got to go
[07:04] <\sh> moins
[07:04] <emgent> cjwatson: kk
[07:04] <cjwatson> there's certainly nothing we can do about it right now
[07:04] <emgent> \sh: good morning.
[07:05] <\sh> hey emgent...how's life? :)
[07:05] <emgent> \sh: real busy but all good :P
[07:06] <emgent> ok i go to work, see you soon people.. i will mail about it quickly
[07:09] <liw> the anti-sec people are out to destroy the full disclosure lists and the security industry, aren't they? why would they tell openssh upstream anything, it's much more effective for their goals to reveal a 0-day exploit without any prior warning
[07:25] <pitti> well, right now I'm not sure whether to take this seriously, or whether it's just boasting
[07:27]  * pitti tends to the latter
[07:29] <\sh> it's all about publicity
[07:32] <bryce> pitti, heya, nice to see alpha-3 right around the corner, however it's caught me in the middle of a couple important merges - mesa 7.5 (released last night) and -intel 2.8.0 (unfortunately released minutes after your freeze announcement)
[07:32] <pitti> bryce: please go ahead, we planned to have them in alpha-3
[07:33] <bryce> pitti, excellent thanks
[07:33] <pitti> bryce: compared to xorg-edgers, the difference should be really small, shouldn't it?
[07:33] <bryce> yep
[07:33] <pitti> bryce: 2.8.0 final? nice \o/
[07:33] <bryce> in fact there's very little difference between the git snapshots and the official release
[07:33] <pitti> mesa | 7.5~rc4-1ubuntu3 |        karmic | source
[07:33] <pitti> that shouldn't be too bad
[07:33] <bryce> right
[07:34] <pitti> bryce: I talked to the kernel guys last Friday on the release meeting, and it was decided to not update the kernel for alpha-3
[07:34] <bryce> also debian packaged mesa 7.5 already so it's just a straightforward merge
[07:34] <pitti> so we have to live with the current one, but it should work just fine
[07:34] <bryce> oh okay, what rc are we at?
[07:34] <pitti> bryce: nice; do we still have a large delta?
[07:34] <pitti> bryce: rc3
[07:34] <bryce> thanks
[07:35] <pitti> bryce: I asked them to pull drm-intel-next, but that itself requires some bureaucracy; but it's just a couple of bug fixes AFAICS, nothing major
[07:35] <kees> cjwatson, emgent: just to make sure you know, the "anti-sec email" to fd is a trojan that will attempt to erase your hard drive if you run it.  please be careful.
[07:35] <pitti> bryce: I had hoped to get ATI KMS in alpha-3, but seems we need to wait for alpha-4 for that
[07:35] <pitti> bryce: but I think with a modprobe.d file you can enable it, can't you?
[07:36] <pitti> bryce: if that's easy, and you want test feedback, I'm happy to write a stanza into the tech overview
[07:36] <bryce> yeah Sarvatt says ati is still a bit jumbled at the moment but we're keeping an eye on it
[07:36] <bryce> or rather he's been keeping an eye on it, I've been hammering on -intel boogz :-)
[07:37] <Sarvatt> are you guys really going to try to get it in alpha 4? would need to jump to mesa 7.6 to use it
[07:37] <bryce> hmm, yeah we probably should solicit -ati testing feedback more firmly
[07:38] <bryce> Sarvatt, well getting -ati with KMS is a big goal for Karmic, and the sooner we get it in the better... but what do you think?
[07:39] <Sarvatt> when's the last time mesa could be upgraded before release? theres no way its going to get brought back into 7.5.x because it depends on radeon-rewrite
[07:40] <LaserJock> kees: the actual email is a trojan?
[07:41] <bryce> Sarvatt, it depends on how major the update is
[07:41] <kees> LaserJock: the program they posted as "the exploit" is an obfuscated trojan.
[07:41] <bryce> Sarvatt, if it is from a well-tested git snapshot that's within a reasonable number of changes, that is usually relatively safe.  But if it's a whole version, like 7.5.0 -> 7.6.0, that's probably not so wise
[07:41] <Sarvatt> if its september you'd probably be looking at a pre rc1 git snapshot getting into karmic release if you want radeon KMS..
[07:42] <LaserJock> kees: ah, I see
[07:42] <kees> LaserJock: http://seclists.org/fulldisclosure/2009/Jul/0289.html linked in the pastebin there.
[07:43] <Sarvatt> 7.4 - 7.5rc1 was 2 months and 7.5 just released 3 days ago
[07:43] <kees> LaserJock: we'll see if they actually release something real, but I'm currently assuming it's just FUD
[07:45] <pitti> Sarvatt, bryce: in my own humble opinion, I'd rather like to see regular git snapshots being uploaded, and we keep instructions how to manually enable KMS and provide feedback
[07:46] <pitti> karmic is a crack release either way, and 10.04 is LTS, so better break it now
[07:47] <pitti> Sarvatt: feature freeze is August 27th, so if ATI KMS isn't enabled by then, it's not going to make the release
[07:47] <\sh> pitti: I thought the next LTS is not really set
[07:47] <Sarvatt> I like pitti's way of thinking :D
[07:47] <pitti> \sh: I think it's pretty firm, though
[07:48] <pitti> Sarvatt: I think we can reasonably make mesa updates until October 8 (with feature freeze)
[07:48] <pitti> so, based on these dates, bryce and you are the best persons to judge
[07:48] <Sarvatt> ohh in that case its not so bad, i was just worried about the state it would be in by august 27th
[07:49] <pitti> meh, I downsized CDs last night, and today's image _grew_ by 2 MB?
[07:49]  * pitti sighs
[07:49] <bryce> pitti, just remember I'm probably going to be gone most of september
[07:50] <bryce> but I can set -ati as a priority for when I'm back.
[07:52] <pitti> bryce: well, do you think it's a realistic target?
[07:53] <pitti> bryce: if it's too brittle, then describing how to install a modprobe.d file would work as well
[07:53] <bryce> yes I do, as long as it gets sufficient attention and folks keep an eye out for bugs and are able to put in patches in september, I don't see it as a showstopper
[07:55] <Sarvatt> pitti: you still need libdrm-radeon1 on top of mesa 7.6 as well as the ddx compiled against libdrm-radeon1 for kms support, the modprobe.d method wont work unless the people are using edgers
[07:56] <pitti> Sarvatt: ah, ok
[07:59] <Sarvatt> i've heard nothing but good things about radeon KMS though in #radeon from people using edgers on karmic, its nowhere near as bad off as intel was at this point a month after 2.6.29-rc1 where KMS got added
[08:02] <Sarvatt> just some suspend/resume problems and performance could be better
[08:02] <bryce> I've always been impressed at the ATI team's attention to stability, they're more conservative about merging development branches into their main
[08:02] <Sarvatt> and its not working on big-endian platforms yet, go figure my only ati machine to test it on is PPC :D it works but the colors are wrong
[08:03] <bryce> I do have to say, the intel team is better at processing bugs; I've got a ton of stale upstreamed -ati bug reports
[08:04] <Sarvatt> helps they are sticking to EXA, most of the intel KMS problems for awhile there were UXA specific
[08:05] <bryce> yeah
[08:05] <bryce> in fact, I'd been enabling EXA for -ati in ubuntu long before they enabled it upstream
[08:08] <Sarvatt> ati seems mostly a 2-3 man show and the main guy works for redhat so probably pays more attention to bugs there :D
[08:09] <bryce> it could be ;-)
[08:16] <bryce> Sarvatt, probably would be a good idea for us to start noting bugs fixed in the radeon-rewrite branch (ala #273329)
[08:17] <StevenK> pitti: I uploaded opal before your freeze, can I accept it out of NEW? :-0
[08:17] <StevenK> s/:-0/:-)/
[08:18] <StevenK> pitti: (Binary NEW)
[08:18] <pitti> StevenK: sure
[08:18] <pitti> the soft freeze doesn't mean "stop doing things", just "stop doing things that introduce breakage"
[08:32] <pitti> StevenK: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt wants to bring hildon back, for cheese; do we still need that in cheese?
[08:34] <pitti> StevenK: hm, you have isdnutils in UNR ship seed?
[08:34] <pitti> that seems a little strange
[08:41] <seb128> slangasek, hey, apparently samba 4.4 broke gvfs smb in some way ... ;-)
[08:41] <seb128> 3.4 rather
[08:41] <slangasek> seb128: make the uploader fix it? :)
[08:42] <seb128> slangasek, good idea ;-)
[08:42] <slangasek> I haven't touched samba 3.4
[08:44]  * smb moans about more samba discussions
[08:45] <highvoltage> smb: heh
[08:45] <ogra> hmm, was there a gtk upload ?
[08:45]  * ogra wonders why totem ftbfs on armel ...
[08:45] <seb128> ogra, since ubuntu was created there was several of those
[08:45] <ogra> haha
[08:45] <seb128> ogra, the question was really clear you have to admit...
[08:45] <ogra> ah, i see gtk was uploaded shortly after totem
[08:46] <ogra> likely still building on arm when totem was attempted ...
[08:46]  * ogra gives back
[08:47] <seb128> ogra, right, seems to be a transitional issue
[08:47] <ogra> yeah
[08:47]  * ogra wishes compiz wouldnt depend on kde stuff, it breaks the world on armel :/
[08:55]  * \sh wishes that the world wouldn't need compiz
[08:55] <directhex> \sh, as opposed to...?
[08:56] <\sh> directhex: it would make things easier ;)
[08:59] <liw> the world doesn't need compiz. the world wants compiz the way it wants sugar in all food -- it satisfied simplified, self-destructive impulses that are remnants of an evolutional era when sweetness was good, but rare
[09:00] <pitti> ScottK: hm, your new upstream release of libcompress-raw-zlib-perl made libio-compress-zlib-perl and libio-compress-zlib-perl uninstallable; I guess they need new versions as well?
[09:00]  * \sh doesn't like sugar in chili
[09:00] <directhex> \sh, gotta add HFCS to everything!
[09:01] <\sh> directhex: whatever HFCS is ...
[09:01] <liw> \sh, I don't like sugar in chili, bread, meat, or ketchup, either
[09:01] <directhex> http://en.wikipedia.org/wiki/High_fructose_corn_syrup
[09:05] <\sh> directhex: too sweet ... /me only uses http://aimas-farms.com/Portals/0/AFRICAN-CHILI-or-scotch-bon.gif <- nasty, hot, strong, excellent, even good for making good sauces
[09:05] <liw> high fructose corn syrup counts as sugar in my book :P
[09:05] <directhex> liw, then you have low standards!
[09:06] <liw> i.e., as long as my doctor will hate me if I eat it, it's sugar
[09:07] <directhex> would your doctor hate you for eating ping-pong balls?
[09:07] <liw> nope, unless they have an effect on my diabetes
[09:08]  * LaserJock sits down to a 1am snack of candy bars and licorice
[09:34] <pitti> linux-headers-2.6.31-3-server | 2.6.31-3.19 |        karmic | amd64
[09:34] <pitti> hmm
[09:34] <pitti> where did the i386 build go?
[09:35] <directhex> you decided to drop support for obsolete architectures!
[09:36] <pitti> lol
[09:36] <pitti> hm, it seems that there's no i386 -server kernel at all any more?
[09:36] <pitti> amitk, smb: ^
[09:37] <pitti> linux-headers-virtual and linux-backports-modules-karmic-virtual depend on them, and thus are uninstallable
[09:37] <pitti> (on i386)
[09:37] <smb> pitti, (apw) it is gone
[09:37] <apw> pitti that sounds wrong
[09:38] <apw> i'll look into it
[09:38] <pitti> apw: thanks
[09:40]  * pitti is looking forward to replying to the "But LP isn't open source" with ".. but it is!" :-)
[09:40]  * ogra wonders why heise hasnt picked it up at all
[09:41] <ogra> slackers ...
[09:42] <apw> pitti, is there a bug for that?
[09:42] <bryce> pitti, "But it must not be 100% opensource.
[09:42] <pitti> apw: no, I just spotted it on http://people.canonical.com/~ubuntu-archive/testing/karmic_probs.html and wondered how it's meant to look like
[09:43] <bryce> pitti, btw both mesa 7.5 and -intel 2.8.0 are now in.
[09:43] <pitti> bryce: I saw, thanks!
[09:43] <ogra> except on arm :P
[09:43] <pitti> I'll wait until mesa, intel, pidgin have built and my NBS/ix components run got published, then rebuild CDs
[09:43] <ogra> eeek, there was a fresh upload of mesa
[09:44] <ogra> ah, but infinity turned down the timeout at least so it will fail after 3h and not block the buildd for 10h
[09:45]  * bryce hates mesa builds
[09:45]  * ogra hates lzma -dbg packages
[09:46] <ogra> its not mesa itself ... its the compressing of the lzma stuff that doesnt work right on armel atm
[09:47] <bryce> ahh
[09:47] <apw> pitti, its a bug in the rename of the i386 server ... will sort it ... i'll make a bug on it
[09:47] <ogra> we raised the buildd timeout to 10h and mesa still failed
[09:47] <ogra> same goes for all of KDE
[09:47] <bryce> ogra, is it something we could conditionalize for arm in our rules file?
[09:47] <bryce> or just a general problem arm needs to sort out?
[09:48] <ogra> we could, but i think it would be cleaner to do it more centralized
[09:48] <bryce> ok
[09:48] <ogra> instead of touching each and every package
[09:48] <ogra> there are 40 (or so) KDE packages
[09:49] <smb> pitti, does this workaround ring a bell to you (bug 387161)?
[09:50] <amitk> pitti: I've got nautilus segfaulting all over the place. Is this a known problem?
[09:50] <pitti> amitk: still with very latest ubuntuone-client from yesterday night? that should have fixed it
[09:50]  * amitk wonders why apport isn't being triggered
[09:51] <pitti> amitk: apport just got reenabled by default last night, too
[09:52] <amitk> ok, I missed the changes from last night. upgrading now...
[09:52] <pitti> smb: just a bell in the sense that I saw another report with the same symptom
[09:52] <ogra> is it supposed to fix sftp in nautilus as well ?
[09:53] <pitti> smb: I asked that guy for a devkit-disks debug output, but didn't get a response yet
[09:53] <pitti> smb: I'll ask for that on this bug as well
[09:53] <smb> pitti, Well I saw others that were affected by the change to read md-meta-data at the end of a full block device. But those usually got "no sense [current]" errors
[09:54] <smb> pitti, Ok, sounds good to me
[09:55] <pitti> smb: apparently dk-disks does something with resets the device
[09:55] <pitti> and perhaps the log says where it crashes
[09:55] <pitti> if the log doesn't help, I'll ask for an strace
[09:55] <slytherin> pitti: FYI ... nautilus-sendto-universe (upstream nautilus-sendto) fails to build against latest empathy. Even 1.1.5 version fails. I have already logged a bug upstream http://bugzilla.gnome.org/show_bug.cgi?id=588302
[09:55] <pitti> slytherin: yeah, I saw; I just quickly tried to render it non-uninstallable
[09:56] <pitti> slytherin: however, ideally this package would disappear at all, and being merged into nautilus-sendto, now that we have empathy in main
[09:57] <slytherin> pitti: Right. Even in that case we will need to first solve the error. It should be fixable by modifying configure script. I just haven't got any time to try it.
[09:57] <slytherin> pitti: My analysis is added in upstream bug.
[09:57] <pitti> slytherin: many thanks
[09:58] <seb128> slytherin, gnome bug #584716
[09:58] <seb128> slytherin, it's fixed in git
[09:58] <slytherin> pitti: One more thing. The package ships a upnp plugin as well and hence it can not just disappear.
[09:58] <slytherin> seb128: let me check. I will port the change tonight.
[09:59] <seb128> slytherin, ideally upstream would roll a tarball, I will try to get that
[09:59] <slytherin> ok
[10:02] <pitti> slytherin: and we don't want that in nautilus-sendto proper?
[10:02] <slytherin> pitti: the dependencies are not in main
[10:02] <slytherin> seb128: In my opinion, it will still fail to build. empathy CFLAGS are not being set by configure script. Please correct me if I am wrong.
[10:03]  * ogra sighs, gdm got so annoying
[10:04] <foka> Hello!
[10:04] <foka> Anyone experienced problems with RTL8111D LAN chip?
[10:06] <seb128> slytherin, I'm busy on other things right now, I can have a look later if you want or try a git build
[10:06] <slytherin> seb128: I will try git build and let you know.
[10:10] <liw> hmm... spatial nautilus on karmic seems to forget size/position of folders
[10:11] <liw> seb128, do you know if spatial nautilus on karmic forget size/position of folder windows is a known bug?
[10:11] <liw> forgetting if I log out and back in
[10:12] <seb128> liw, should be fixed with the gvfs update from yesterday
[10:12] <seb128> if that's still an issue after session restart that's not known no
[10:13] <liw> maybe my mirror is slow, I'll see what happens tomorrow
[10:13] <seb128> liw, what version do you have?
[10:13] <ogra> is there any way in new gdm to switch off the annoying userlist feature ?
[10:14] <seb128> ogra, is there any way you could write clear questions? ;-)
[10:14] <liw> seb128, nautilus 1:2.27.4-0ubuntu2, gvfs 1.3.2-0ubuntu4
[10:14] <seb128> ogra, what annoying userlist?
[10:14] <ogra> seb128, i would like to a) not have to wait 15 seconds until something is shown in the userlist and b) not have to touch my mouse to log in
[10:14] <seb128> liw, and you restarted your session since the upgrade?
[10:15] <liw> seb128, I rebooted, even
[10:15] <seb128> ogra, a) is a ck-list-sessions issue
[10:15] <seb128> liw, ok so not known bug
[10:15] <ogra> seb128, i.e. u would like to have just a "username" field by default as it was in old gdm, something that doesnt force me to click
[10:15] <liw> seb128, filing a bug, then
[10:15] <seb128> ogra, b) just hit enter?
[10:15] <liw> seb128, should I file it against gvfs or nautilus?
[10:16] <seb128> liw, nautilus we can reassign later if required
[10:16] <ogra> seb128, well, that indeed only works if the user list is up
[10:16] <ogra> i'll wait for a) to be fixed and see if that works for me :)
[10:18] <james_w> it's not easy to fix
[10:20] <ogra> seb128, just to confirm, sftp in nautilus works fine again with todays upgrade
[10:20] <seb128> ogra, good
[10:22] <pitti> mvo_: do you know why dpkg's "Reading database" sometimes takes two minutes, and sometimes just half a second? in jaunty and earlier, it would consistently take some 3 seconds
[10:24] <seb128> pitti, mvo_: I noticed that too on both my laptop and desktop configs
[10:25] <james_w> just uploaded a logrotate file for ck, which should at least keep the time to the userlist bounded
[10:25] <james_w> still large though
[10:26] <lifeless> pitti: I've noticed it too; been on my list to strace
[10:26] <ogra> notify-osd crashing with latest updates is known i assume ? (given a new version is just building)
[10:27] <seb128> ogra, works there
[10:27] <ogra> well, i had apport coming up after reboot
[10:27] <seb128> ogra, the new version has no crash fix described in the changes
[10:27] <seb128> use apport to send the bug?
[10:27] <seb128> or wait for the update rather before
[10:27] <ogra> hmm, funnily brightness and volume keys bring it up fine
[10:28] <ogra> yeah, i'll wait for the update first
[10:29] <mvo_> pitti: no, I need to have a look to figure that out
[10:29] <pitti> mvo_: ah, so it's not a magical new "dpkg using xapian now" or so
[10:31] <mvo_> pitti: not that I know of at least :) speaking of xapian, that is much faster when updating now
[10:31] <Adlai`> oh man, if dpkg starts using xapian for searching, I'll be so relieved
[10:32] <Adlai`> a while back, I wrote a python script to search it, but I don't know much xapian so it isn't very smart
[10:32] <pitti> tkamppeter: we currently have a "Apps -> System Tools -> HPLJ 10xx Replaced Paper" entry in the main menu; can we please hide this?
[10:32] <Adlai`> it sometimes comes up with interesting things but isn't very reliable
[10:35] <mvo_> Adlai`: xapian is on the list of things to use more, there is some integration work being done with g-a-i and apt-xapian-index
[10:37] <Adlai`> neato
[10:42] <ScottK> pitti: re  libcompress-raw-zlib-perl, lool already pinged me on it and I'm working on it.  Unfortunately upstream combined 4 modules into one package in the new version so it's a non-trivial update.
[10:42] <pitti> ah, but perhaps easier upgrades in the future
[10:42] <tkamppeter> pitti, I thought already about removing it, it comes from upstream foo2zjs. I wanted to do it today, but then there was your mail about the Alpha 3 freeze.
[10:43] <pitti> tkamppeter: that's fine, adding a NoDisplay to a .desktop file is not intrusive
[10:43] <pitti> lifeless: hm, why does current bzr still default to pack-0.92?
[10:44] <tkamppeter> pitti, OK, will do it this way.
[10:44] <pitti> tkamppeter: thanks; just some desktop polish :)
[10:44] <lifeless> pitti: changing the default forces an upgrade without warning on everyone making new projects
[10:44] <lifeless> pitti: we are cautious about changing it; the next change is scheduled for 2.0
[10:45] <pitti> lifeless: ah, I was just curious; I wondered by I still have to use --1.9 for bzr init, etc.
[10:45] <lifeless> pitti: if you want the best format, use --2a, note that its a one-way upgrade from 1.9 to 2a
[10:45] <lifeless> pitti: you might like to read the upgrading docs in trunk
[10:45] <pitti> lifeless: does LP already get along with 2a?
[10:47] <lifeless> yes
[10:47] <lifeless> LP's code is in 2a format
[10:47] <pitti> nice
[10:48] <pitti> weird, a bzr upgrade --2a doesn't do anything here
[10:49] <pitti> $ diff -Nur backup.bzr/ .bzr
[10:49] <pitti> -Bazaar Working Tree Format 4 (bzr 0.15)
[10:49] <pitti> +Bazaar Working Tree Format 6 (bzr 1.14)
[10:49] <pitti> that's it
[10:49] <pitti> lifeless: ^
[10:49] <lifeless> pitti: you're in a shared repo I suspect
[10:49] <lifeless> cd ..
[10:49] <lifeless> bzr reconcile
[10:50] <lifeless> bzr upgrade --2a
[10:50] <lifeless> (and again, note that its a one-way conversion :))
[10:50] <pitti> oh, indeed, that was from ages ago; thanks
[10:54] <apw> pitti is there any way to validate a control file once its changed, to ask what it means to dpkg/apt ?
[10:54] <pitti> apw: validate for what in particular?
[10:54] <pitti> dpgk -I .deb will show the resulting record for a .deb
[10:55] <apw> i am changing a Depends: and there seem to be some subtlies in how i might encode my new form and wondered if there was a way of saying "tell me what this means now i've written it"
[10:55] <apw> in this case i have different deps for different arches
[10:56] <apw> the docs imply that the [i386] syntax is not valid for Depends: so i am assuming i want to use an | on the two packages
[10:56] <apw> but it would be nice to be able to tell in advance of uploading it, if it means what i think it means
[10:56] <apw> (this is the virtual uninstallable thing)
[10:56] <pitti> right, [i386] only works for build deps
[10:57] <pitti> apw: lintian is pretty good in spotting such things
[10:57] <apw> ahh will give that a spin
[11:08] <pitti> Riddell, lool, cjwatson: anything from the KDE/mobile/platform front worth mentioning for alpha-3 on https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview ?
[11:09] <pitti> s/platform/foundations/ *blush*
[11:13] <Riddell> from kubuntu: netbook and social from the start
[11:13] <Riddell> I can add stuff in a minute
[11:14] <pitti> Riddell: thanks (not urgent)
[11:15] <ogra> hrm, i cant find where in the dpkg code the default value for -z is defined :/
[11:15] <apw> pitti, i assume that this -virtual missmatch is not a blocker for the alpha-3 release
[11:16] <pitti> apw: no, it's not; but I spotted it while reviewing the list
[11:16] <ogra> ah, i guess its "  if(compression == NULL) compression= "9";" in lib/compression.c
[11:17] <apw> pitti, thanks, will get it fixed for the next upload
[11:17] <pitti> apw: so i386 is really meant to have a server kernel then?
[11:18] <apw> no its been renamed to generic-pae, and virtual is meant to be made from that
[11:18] <pitti> ah
[11:18] <apw> so i need to dep on either -server or -generic-pae in meta
[11:18] <apw> i assume that that will do the right thing
[11:18] <pitti> yes, should
[11:19] <pitti> I just wonder why it was renamed in the first place?
[11:19] <apw> its not a server oriented kernel any more, its big memory oriented
[11:20] <apw> its generic with pae enabled, rather than with pae enabled, the tick reduced, and the uo schedulers changed
[11:21] <apw> it was deemed necessary to change the name as people kept saying 'but its not a server i shouldn't have to run a server kernel'
[11:28] <apw> pitti, how is that uninstallable report generated?
[11:28] <pitti> apw: some magic scripts which check satisfyability of dependencies of all packages in main
[11:29] <lool> pitti: No, not really: no new UNR, and ARM stuff is still in flux
[11:29] <apw> so the best way to test is to try and install the packages in a chroot
[11:29] <apw> as presumably they fail to install
[11:30] <pitti> lool: ah, thanks
[11:31] <pitti> apw: probably some dependency which is either missing or in universe, or a Conflicts:
[11:42] <AnAnt> Hello, regarding bug LP 401816, which is the better path ? apply the patch that Debian applied in the new upstream ? or merge with Debian's package for new upstream release ?
[12:11] <Company> what's the right channel to poke the Ubuntu X crew?
[12:13] <seb128> Company, #ubuntu-x
[12:19] <AnAnt> guile-1.8 is in main, right ?
[12:20] <Laney> AnAnt: LP knows
[12:20] <Laney> and I'd merge the new release at this point unless there's a reason not to
[12:21] <AnAnt> well, I don't know a reason not to
[12:22] <AnAnt> except maybe, that there could be many apps depending on guile, so I dunno if upgrading to new upstream would break lots of apps
[12:22] <AnAnt> ah, it's in main
[12:26] <directhex> what uses guile?
[12:27] <directhex> i was reading some stuff into its history...
[12:30] <Laney> you've got gall, you've got guile
[12:30] <Laney> to step to me, i'm a rapophile
[12:31]  * directhex mails Laney to yankland to fill in for MCA with the beastie boys
[12:31] <Laney> I think I'd fit like hand in glove
[12:41] <directhex> yay, mdz made it into an itwire hit piece. i wonder if there's a club
[12:41] <Laney> you should make a launchpad group
[12:42] <Laney> you could have a mailing list and everything
[12:42] <directhex> i wonder if i could get joss to join it
[12:43] <mdz> directhex, misspelled even
[12:44] <directhex> Laney, it looks like a team is the correct format
[12:44] <directhex> Laney, judging by the we-love-pitti team
[12:47] <Laney> for sure
[12:49] <maxb> So, there's just been a 'fix' to LP 391190 uploaded...
[12:49] <maxb> What should I do now, reopen it and retitle it "Font size is too small by default" ?
[12:50] <directhex> mdz, i wouldn't let it get you down. now you're as famous as me, these kinds of articles are inevitable
[12:53] <\sh> what is "helios"?
[12:54] <\sh> it eats more of my cpu time then X which is strange ;)
[12:55] <Keybuk> \sh: screensaver?
[12:55] <ogra> its a screensaver
[12:55] <\sh> oh god
[12:55] <ogra> bah, Keybuk beats me
[12:56] <\sh> ok killed.
[12:56] <\sh> and now I wonder what hammers on my HD at least 2 times per second
[12:56] <AnAnt> Keybuk: is there KMS support for NVIDIA yet ?
[12:57] <slytherin> AnAnt: Not yet. Onlt intel and ati.
[12:58] <slytherin> AnAnt: The support is supposedly planned foe kernel version post 2.6.31.
[12:58] <AnAnt> ah, not in karmic then
[12:58] <slytherin> right.
[12:59] <slytherin> AnAnt: you can use Debian unstable to get latest of everything. :-)
[13:00] <AnAnt> slytherin: I won't get the kernel from thre !
[13:00] <AnAnt> I wont dare
[13:00] <slytherin> AnAnt: Why not?
[13:01] <AnAnt> slytherin: because  I won't dare, besides, I don't think Ubuntu syncs/merges kernel packaging with Debian
[13:02] <slytherin> AnAnt: I mean run Debian unstable on your machine, not pick up kernel from Debian unstable.
[13:03] <AnAnt> oh
[13:03] <AnAnt> slytherin: just to try KMS ?
[13:03] <ogra> slytherin, oh debian already has a kernel newer than .31 ? wow :P
[13:03] <slytherin> ogra: No. They don't have it. But they will have earlier than Ubuntu is my guess.
[13:04] <slytherin> Or rather my hope
[13:04] <ogra> heh, that i doubt very much
[13:05] <ogra> slytherin, you know that the kernel team maintains a PPA that tracks upstream ?
[13:05] <slytherin> ogra: I know. I am going to try .31-rc3 ib jaunty tonight. :-)
[13:05] <ogra> :)
[13:06] <slytherin> These days actually Debian 'experimental' is new Debian 'unstable'.
[13:06] <Laney> how do I get KMS then if I have ATI?
[13:07] <slytherin> Laney: karmic is supposed to have KMS for ATI as well. :-) The kernel support is already there. I am not sure about X stuff.
[13:07] <Laney> do I have to do anything to enable it though?
[13:07] <Sarvatt> you can use KMS on nvidia right now in karmic, sudo apt-get install xserver-xorg-video-nouveau :)
[13:07] <AnAnt> slytherin: btw, did you mean the free NVIDIA or non-free ?
[13:08]  * Laney is using -ati though
[13:08] <slytherin> AnAnt: I am not having any hope with non-free.
[13:08] <AnAnt> slytherin: why's that ?
[13:08] <AnAnt> slytherin: I use non-free, because the colors looked better than the free nv module
[13:08] <slytherin> Laney: I believe not. But it is better to ask kernel developers.
[13:08] <Sarvatt> you need alot of userspace for it Laney, cant use it in karmic now
[13:08] <Laney> maybe when I'm back and actually on my Ubuntu machine...
[13:09] <Sarvatt> https://edge.launchpad.net/~xorg-edgers/+archive/ppa
[13:09] <Sarvatt> it needs libdrm-radeon1 plus mesa 7.6 and a newer ati ddx than karmic's
[13:09] <slytherin> AnAnt: Because you are at the mercy of nvidia.
[13:10] <AnAnt> slytherin: ok, you're right about this, that's problem with non-free generally
[13:11] <AnAnt> oh, nouveau is something different than nv !
[13:11] <AnAnt> that deserves a try indeed !
[13:11] <Sarvatt> yep, and its got KMS
[13:12] <Sarvatt> but no 3D to speak of :)
[13:12] <AnAnt> Sarvatt: 3D as in compiz stuff ?
[13:12] <Sarvatt> no DRI at all
[13:12] <AnAnt> erm, what's DRI ?
[13:12] <ogra> direct rendering interface
[13:13] <AnAnt> is that the thing that compiz needs ?
[13:13] <AnAnt> I don't use compiz anyways
[13:14] <Sarvatt> yeah compiz is 3D only, you can use metacity compositing fine though since its xrender based
[13:15] <Sarvatt> to use KMS with the nouveau package in karmic you'll need to add options nouveau modeset=1 to /etc/modprobe.d/nouveau.conf
[13:16] <AnAnt> ok
[13:16] <AnAnt> thanks
[13:16] <AnAnt> I should try that in Alpha3
[13:17] <Sarvatt> http://sarvatt.com/downloads/nouveau-kms.txt
[13:18] <Sarvatt> theres "some" 3d support if you compile mesa yourself and enable gallium, doesnt run anything more than glxgears and glxinfo here though :D
[13:18] <directhex> mdz, did you intentionally bump the timestamp on your old backlash blog post? it's a the top of planet again
[13:19] <mdz> directhex, no, not intentionally.  I had to twiddle the comment flag to link to Sam's article
[13:19] <mdz> directhex, I've also had that happen when I add a category to an old post.  do you know any way to fix or avoid it?
[13:20] <directhex> mdz, no, sorry. of course, i have access to the mysql backing the blog, so i can hax it if need be in my own case
[13:21] <mdz> my apologies to planet, then. :-/
[13:22] <AnAnt> directhex: I dunno how many packages uses guile,
[13:22] <directhex> mdz, doesn't bug me, i was just curious
[13:22] <directhex> mdz, this ain't #debian-devel, no angry rebukes on the horizon
[13:24] <mdz> directhex, thanks for letting me know.  I've added a post to ask if anyone knows how to avoid the problem in the future
[13:26] <maxb> What is the criteria for being unmoderated on ubuntu-devel@ ? Must you be a MOTU at minimum or can an ordinary user like me request to be considered for unmoderated access after posting responsibly to the list for a while?
[13:27] <AnAnt> directhex: in jaunty, I see about 40 packages depending on guile-1.8-libs
[13:28] <directhex> AnAnt, fewer than tcl. interesting.
[13:28] <AnAnt> directhex: including autogen
[13:29] <directhex> AnAnt, that doesn't surprise me
[13:29] <AnAnt> so, what do you think, merge with Debian's new upstream or just apply the patch ?
[13:31] <mdz> maxb, anyone can be whitelisted if they consistently post on-topic
[13:32] <maxb> Should I just be patient and someone will notice eventually, or should I ask someone to whitelist me?
[13:32] <pitti> AnAnt: if you test the new upstream, a merge would still be better at this point IMHO (just dn't break alpha-3, or postpone the upload after a3)
[13:32] <AnAnt> ok
[13:33] <AnAnt> I'll wait till next week then
[13:43] <subzero> hi at all
[13:44] <lool> How does one dump the macros cpp expands by default?
[13:46] <subzero> i don't know
[13:46] <lool> touch foo.h; cpp -dM foo.h
[13:46] <lool> Was in man gcc not cpp
[13:46] <ogra> heh
[13:47] <ogra> yay for well placed documentaion
[13:47] <lool> actually it's in man cpp too
[13:50] <slytherin> Currently jaunty doesn't identify full HD mode on my external monitor (LCD TV actually). Is KMS expected to resolve that problem in some way?
[13:51] <pitti> slytherin: give the live CD a try?
[13:52] <pitti> slytherin: (supposed, yes; no idea whether it's working on your machine)
[13:52] <slytherin> pitti: I can't. Its a powerpc machine. :-)
[13:52] <directhex> slytherin, what resolution is the TV?
[13:53] <ogra> it didnt work on my external monitor, but its over a week ago that i tried last
[13:53] <slytherin> directhex: you mean size? 32"
[13:54] <directhex> slytherin, most 32" sets i'm aware of have a resolution of 1366x768, and invalid EDID data preventing proper automatic modesetting. and IME most sets smaller than 37" can only do 1080i, not 1080p
[13:55] <ogra> your info is quite outdated :)
[13:55] <ogra> most 32" ones nowadays can do 1080p
[13:55] <slytherin> The TV specification says it has 1080p support.
[13:55] <directhex> i'm gettnig old, then :(
[13:56] <ogra> no its moving very fast :)
[13:56] <directhex> slytherin, support doesn't neccessarily mean "without some scaling, cough"
[13:56] <directhex> ogra, i spent £650 on my 26" set!
[13:56] <ogra> ugh
[13:56] <ogra> when ?
[13:56] <directhex> ogra, about 3 years ago i think
[13:57] <directhex> i could do with something a bit bigger. the furniture has room for a 37-42" depending on the size of the bezel
[13:57] <ogra> yeah, my 37" set i just gave to my sister costed about €1000 four years ago
[13:57] <directhex> and lord knows i enjoy gaming on a big HD telly
[13:57] <ogra> the 42" one i got recently and is aeons better only was €699
[13:57] <slytherin> directhex: Dell sells 24" monitors that support 1080p. So I suppose 32" should have no problem.
[13:58] <highvoltage> I can't see very far so my brain upscales everything quite nicely, I don't need HD :p
[13:58] <directhex> slytherin, oh, monitors have done it for YEARS. i had housemates with 1600x1200 on laptops in 2002
[13:59] <slytherin> didn't know that.
[14:01] <highvoltage> directhex: but 1080p is 1920x1080, so 1600x1200 wouldn't be able to display full HD.
[14:01] <slytherin> anyway, currently nothing higher than 1024x768 is detected. I hope that improves in karmic. As I am going to turn my PC into media center and permanently attach it to the TV.
[14:01] <directhex> highvoltage, this is pre-widescreen days.
[14:01] <highvoltage> directhex: oh wow, ok.
[14:01] <directhex> slytherin, is it connected via VGA?
[14:02] <directhex> slytherin, 1024x768 on an lcd tv sounds EXACTLY like bad EDID to me
[14:03] <slytherin> directhex: yes. And bad EDID is what came to my mind as well.
[14:03] <directhex> slytherin, which driver?
[14:04] <slytherin> directhex: ati (free one), card 9200.
[14:04] <blackxored> hello everybody? anyone from cuba here?
[14:04] <directhex> slytherin, very recent nvidia-glx appears to contain workarounds for bad EDID - i updated from intrepid to jaunty, and i got 1366x768 via VGA despite the bad EDID
[14:05] <directhex> slytherin, alternatively, one can hax it with a custom modeline
[14:05] <blackxored> I'm not silly, I'm just gpg-coordinating anyone
[14:05] <directhex> blackxored, unless the internets got a hell of a lot faster & cheaper in the past 2 years, i doubt it
[14:06] <blackxored> directhex, sad to hear, in #debian-devel is no one either, seems like I'm the only god damn cuban who wants to become a debian/ubuntu devel
[14:06] <blackxored> a technical question, yeah I know RTFM, but for ubuntu applying as a dev is necessary to pgp sign as in debian?
[14:06] <directhex> blackxored, you're the only god damn cuban i've ever encountered on the internets at large, so i admit to not being totally surprised
[14:07] <blackxored> directhex, ;)
[14:07] <directhex> blackxored, no, a signed gpg key is not needed for ubuntu - merely a key with 0 or more sigs
[14:07] <slytherin> directhex: my ibook has jaunty already.
[14:07]  * directhex wonders where blackxored is based
[14:07] <directhex> slytherin, oh, it's a laptop? that complicates matters
[14:08] <blackxored> directhex, so I can apply for ubuntu-motu??
[14:08] <directhex> slytherin, basically, it's broken info burnt into the tv, and only workarounds can fix it
[14:08] <directhex> blackxored, if you have a demonstrable log of contribution, you can apply for ubuntu-motu
[14:08] <blackxored> I've packaged swt-gtk for debian (is in testing now), and I'm working in azureus, any clues?
[14:09] <directhex> blackxored, and if you don't have a demonstrable log of contribution, then just contribute some more, and you WILL have
[14:09] <blackxored> directhex, fine then
[14:10] <slytherin> directhex: hmm. I have tried modelines in past for a friend. I can try that again my my TV. Sadly the TV specification is non-existent in regards to what the refresh rates should be for different resolutions.
[14:10] <directhex> blackxored, sounds like the java team would be a good place for you to be?
[14:10] <directhex> slytherin, a model of TV would be useful
[14:11] <blackxored> directhex, probably since I develop in java, but I also do it in python and ruby, so nevermind, I'm interested in both projects as a whole, I use ubuntu on my workstations and debian in our servers (I'm leeking info here...) :D
[14:11] <blackxored> I've actually try to do my best to see an updated eclipse in debian, since it's orphaned by now
[14:11] <slytherin> directhex: http://www.videoconworld.com/products/lcd/index.php First one in the list
[14:12] <directhex> blackxored, that's a big project. i'd suggest talking to someone javaish..... now if only slytherin were here...
[14:13] <blackxored> blackxored, no, I've just to contribute to it, not maintain man, eclipse is *huge*
[14:14] <slytherin> blackxored: you can try fixing current eclipse package in karmic. :-)
[14:14] <slytherin> anyway, eclipse is in universe. So move to #ubuntu-motu for further discussion. :-)
[14:14] <blackxored> slytherin, I'm working in azureus by now
[14:14] <directhex> slytherin, do you have access to a machine connected to that TV right now? or should we re-discuss this evening?
[14:15] <slytherin> directhex: We should discuss it later.
[14:15] <slytherin> blackxored: ahh, I didn't recognize you.
[14:15] <directhex> okay
[14:15] <directhex> slytherin, i've spent far too much time on mythtv issues, so i have experience with this crap
[14:15] <blackxored> slytherin, "eclipse is in universe" => apt-cache policy eclipse => 3.2.2-5ubuntu3
[14:16] <blackxored> slytherin, current upstream: 3.5
[14:16] <slytherin> blackxored: Ubuntu karmic has 3.4. But it needs lot of cleaning.
[14:16] <slytherin> Once we are done with cleaning it, it should not be very hard to update it.
[14:17] <blackxored> slytherin, ok, there's so any chance I could provide some help when I finish with azureus?
[14:18] <slytherin> blackxored: I will let you know.
[14:20] <blackxored> slytherin, ok sorry about the retrospective , but what you meant with "I didn't recognized you"?
[14:21] <slytherin> blackxored: As in I didn't first know that you were 'Adrian Perez'. I already know that you are working on swt-gtk, azereus and will probably work on eclipse.
[14:22] <blackxored> slytherin, ah right, you know a lot about me ;) anyways, thanks for your time, I has been useful talking this bit, back to work
[14:41] <blackxored> people BTW I've used a pbuilder setup for package building for a long time, there's any way I could turn it into a schroot env and test some X apps with it, any clues?
[14:52] <Sarvatt> blackxored: you can use your current xserver to run x apps in there with a ton of screwing around, but you cant run x in a chroot directly as far as I know right now
[14:53] <Sarvatt> just set up virtualbox or something if you want that :)
[15:09] <blackxored> Sarvatt, I got some guidance in #debian-devel thanks a lot
[15:16] <Riddell> Ampelbein: what's going on with mjpegtools and bug 351017 ?
[15:17] <Riddell> pitti set it to verification-failed last week, there's now an update waiting in the jaunty unapproved queue but I don't see any comment or new patch on the bug
[15:34] <arand> Hello, I'm trying to push for an SRU of gnumeric (libgoffice) as described in https://bugs.launchpad.net/gnumeric/+bug/316502 Are there more (easy) steps that should be done there?
[15:34] <ubott2> Ubuntu bug 316502 in gnumeric "cannot release a graph in gnumeric after click and drag" [Medium,Fix released]
[15:34] <liw> hmm. debdelta requires exact original file to exist, but it that is lost, we _could_ use dpkg-repack to reconstruct something close to the original, then use zsync to update to the exact original, then use debdelta to update that to the new version of the pacakge... slightly complicated, but doable
[15:36] <Riddell> arand: create a debdiff if you know how, else poke someone on the ubuntu desktop team to do it
[15:38] <arand> Riddell: No not completely sure on that, so that would be #ubuntu-desktop then?
[15:38] <Riddell> arand: yes
[15:44] <Keybuk> mvo_: is there a way to have a command run after packages are installed?
[15:46] <pitti> Keybuk: in the user session or as root?
[15:46] <pitti> (user -> interactive upgrade hook; root -> package trigger?)
[15:46] <Keybuk> root is fine
[15:46] <Keybuk> after any package is installed
[15:47] <pitti> oh
[15:47]  * pitti defers to mvo then, sorry
[15:47] <Keybuk> though it's ok if it's just if any package is installed via apt
[15:47] <Keybuk> basically want to catch upgrades
[15:47] <james_w> "trigger /" ?
[15:47] <liw> Keybuk, what is the actual problem you're solving?
[15:47] <pitti> install a trigger with interest on /usr? :-)
[15:47] <pitti> james_w: hah
[15:47] <Keybuk> liw: wiping the old sreadahead pack on an upgrade so it's regenerated
[15:48] <liw> I believe apt has some hooks you could install into /etc/apt
[15:49] <liw> hmm, Apt::Post-Invoke or something perhaps
[15:50] <liw> er, Dpkg::Post-Invoke
[15:50] <liw> I can never remember apt config syntax
[15:51] <liw> there's no Dpkg::Post-Install-Pkgs though
[15:53] <mat_t> jamesh: ping
[15:53] <Riddell> geser: you uploaded a bunch of zope packages to karmic?  they don't seem to have the ZPL included
[15:53] <Riddell> geser: I'll accept them because they're already in debian but it would be best to get that fixed
[15:56] <geser> Riddell: you mean in the .orig.tar.gz?
[15:56] <Riddell> geser: yes
[15:57] <geser> Riddell: did it change in Debian in the last time? because that's the next package which is missing a license in the .orig.tar.gz in Debian
[15:57] <pitti> if they are already in Debian, why not just sync instead?
[15:57] <geser> pitti: I'd have done it, if it didn't need patching to build with python 2.6
[15:58] <pitti> aah
[15:58] <geser> but I already got also a synced package from Debian rejected because the license text was missing in .orig.tar.gz
[15:58] <Riddell> geser: nothing has changed in debian that I can see
[15:59] <mvo_> Keybuk: you can use "DPkg::Post-Invoke"  and hook commands into that, see update-notifier as a example (it touches a file :)
[15:59] <geser> doesn't Debian have that license text requirement in .orig.tar.gz? or aren't they as strict as Debian?
[16:00] <Riddell> geser: they should but as with us it probably depends on the archive admin of the day and what sort of a mood he's in
[16:00] <mvo_> Keybuk: registering a handler here should be a short action though, the UI waits without proper progress to the user during the post-invoke handler
[16:01] <Keybuk> mvo_: in this case, it's rm'ing a file
[16:01] <mvo_> that should be fine I guess
[16:01] <geser> Riddell: it just curious that I stumbled upon this twice in the last few syncs/uploads. I'll contact the Debian maintainer about it.
[16:01] <mvo_> (unless the file is huge?)
[16:01] <liw> mvo_, does DPkg::Post-Invoke get run after each invocation of dpkg?
[16:02] <Keybuk> mvo_: not especially
[16:02] <mvo_> liw: no, the name is misleading - just when its finished (or errored out)
[16:02] <Keybuk> mvo_: its maximum size is probably 7MB
[16:02] <liw> mvo, ok; then some documentation should probably say that :)
[16:29] <Artur25> Hello.
[16:29] <Artur25> Did somebody compile alsa kernel recently?
[16:32] <Riddell> ttx: how is netty-3.1.0.CR1.jar built?
[16:32] <ttx> Riddell: using debian/build.xml
[16:33] <ttx> Riddell: compiles files, excludes a few optional features, JARs them all.
[16:33] <Riddell> ttx: why is the binary jar included in the sources then?
[16:34] <ttx> Riddell: the binary jar is not used. The source tarball is pristine from upstream.
[16:34] <Riddell> ttx: ok thanks, I'll accept
[16:35] <ttx> Riddell: thanks. More coming :)
[16:38]  * ttx thinks java developers should learn that a source package is not their binary distribution with an added "src" directory.
[16:45] <maco> pitti: question about the sudo package. i see the --with-secure-path= set in debian/OPTIONS but then twice again in debian/rules. is the one in debian/OPTIONS ignored?
[16:48] <directhex> can ubuntu-archive unsubscribe from https://bugs.launchpad.net/ubuntu/+source/mono-tools/+bug/402152  plz? it completely slipped my mind that it needs xsp (universe) to build, so needs merging rather than syncing
[16:48] <ubott2> Ubuntu bug 402152 in mono-tools "Sync mono-tools 2.4.2-1 (main) from Debian unstable (main)." [Wishlist,Confirmed]
[16:49] <StevenK> directhex: Done
[16:49] <directhex> StevenK, ta. i'll work on the merge this evening
[16:51] <ogra> infinity, did you do anything to the armel builders ?
[16:57] <ogra> infinity, i dont get http://launchpadlibrarian.net/29325128/buildlog_ubuntu-karmic-armel.mesa_7.5-1ubuntu1_FULLYBUILT.txt.gz ...
[16:57] <ogra> infinity, why did it build now ?
[16:58] <infinity> ogra: I did nothing...
[16:59] <ogra> hrm
[17:05] <ogra> infinity, though http://launchpadlibrarian.net/29325326/buildlog_ubuntu-karmic-armel.qt4-x11_4.5.2-0ubuntu2_FAILEDTOBUILD.txt.gz
[17:06] <ogra> (we're just discussing in #ubuntu-arm)
[17:07] <bdmurray> pitti: Is calibre working for you?  bug 402040
[17:07] <ubott2> Launchpad bug 402040 in calibre "calibre crashed with ImportError in <module>()" [Undecided,Confirmed] https://launchpad.net/bugs/402040
[17:07] <ubott2> Ubuntu bug 402040 in calibre "calibre crashed with ImportError in <module>()" [Undecided,Confirmed]
[17:07] <ubott2> Launchpad bug 402040 in calibre "calibre crashed with ImportError in <module>()" [Undecided,Confirmed] https://launchpad.net/bugs/402040
[17:07] <StevenK> Argh, here too
[17:08] <infinity> ogra: Hrm.  This throws everything off a bit, though.  People claimed this was "an lzma issue", but that build log is just a massive C++ link.
[17:08] <infinity> ogra: Probably just a memory churn issue...
[17:08] <ogra> infinity, yeah, we had probs before with upstart that looked similar
[17:09] <ogra> upstart has a testsuite where one file is really really huge
[17:09] <ogra> it had the same error (with gcc, not g++ though)
[17:10] <infinity> Well, hard to call it the "same error", since there isn't an error.
[17:10] <ogra> well, same output :)
[17:11] <infinity> (or lack thereof)
[17:11] <infinity> sbuild isn't all that smart on how it does this.  It just watches the log.  150 minutes with nothing to stdout, it kills everything.
[17:12] <infinity> So, yeah.  PROBABLY just massive memory churn on that C++ link (and maybe the old 600 minute timeout would have helped for this), but maybe it's actually hanging.
[17:13] <ogra> ogra@osiris:~/Devel/packages/upstart-0.6.1$ ls -lh nih-dbus-tool/tests/expected/test_output_proxy_standard.c
[17:13] <ogra> -rw-r--r-- 1 ogra ogra 115K 2009-07-02 18:22 nih-dbus-tool/tests/expected/test_output_proxy_standard.c
[17:13] <ogra> that was the test the upstart build died on
[17:14] <infinity> Yeah.
[17:14] <infinity> I'm just wary of saying "Oh, it's just slow hardware"...
[17:14] <ogra> can we throw more swap in to help here ?
[17:14] <infinity> Since I'm sure that QT wasn't borderline 145 minutes to link in previous versions, and "just got a bit worse recently", y'know?
[17:14] <ogra> and bump swappiness up
[17:14] <infinity> So, there's probably some underlying issue here.
[17:15] <Keybuk> I think it's a compiler issue
[17:15] <ogra> since we always only saw it dying in dpkg-deb the suspicion was that the newer dpkg brought it in
[17:16] <ogra> i'm just doing a mesa build locally (since 5h) with rolled back dpkg
[17:16] <ogra> to see how long dpkg-deb actually takes
[17:16] <ogra> but now seeing g++ hang is somewhat pointing to a system issue
[17:17] <ogra> more than a SW issue
[17:17] <infinity> Well, technically that line would be calling binutils, not gcc...
[17:17] <infinity> I think.
[17:17] <infinity> Unless I just need morning caffiene.
[17:18] <Keybuk> dunno, in the Upstart case it seems that gcc is what hangs around
[17:18] <ogra> yes
[17:18] <Keybuk> compiling godot.c or something
[17:18] <ogra> i think it was test_output_proxy_standard.c
[17:18] <infinity> Could wait a while for that one.
[17:18] <infinity> *rimshot*
[17:18] <infinity> Anyhow...
[17:18] <Keybuk> ogra: those files aren't compield
[17:18] <ogra> they were
[17:19] <ogra> at least in the log i saw
[17:19] <Keybuk> ogra: bet you $ 1,000,000 ?
[17:19] <ogra> nah, ho am i to argue with upstream :P
[17:20] <Keybuk> it was stalling on nih-dbus-tool/tests/test_node.c before
[17:20] <ogra> oh, right
[17:20] <ogra> but there it died reproducable on the buildd
[17:20] <ogra> i gave it back and got exactly the same in the second round
[17:21]  * infinity fears a hunch...
[17:22] <infinity> Oh, phew.  No, hunch averted.
[17:22] <Keybuk> what was your hunch?
[17:22] <infinity> Keybuk: The base system on two of the armel machines is still Debian/lenny.  Was mildly concerned that might be an issue.
[17:23] <infinity> Keybuk: But, the recently (and mysteriously) successful mesa build was on a lenny machine.
[17:23] <mat_t> ArneGoetje: ping
[17:24] <ogra> we should really run jaunty there :P
[17:24] <ArneGoetje> mat_t: pong
[17:24] <infinity> ogra: All the other armel machines were sidegraded to jaunty, just two never got done.
[17:24] <infinity> ogra: And by the time iwas getting around to doing them, people were telling me I was throwing that hardware away in favour of qemu, or newer v7 kit, so...
[17:25] <mat_t> ArneGoetje: I'm trying to get hold of jamesh regarding the font installer, but no luck so far... is he around at all?
[17:28] <ogra> infinity, newer v7 kit shoul be there soon
[17:28] <ogra> but that will need testing etc
[17:28] <ogra> so we still need somehow fix the issue
[17:28] <ogra> or identify ...
[17:28] <infinity> Yeah.  I'm all for fixing it, it's the indentify part...
[17:29] <ogra> heh
[17:30] <cody-somerville> pitti, I'm not going to patch gdm to launch x-window-manager instead of metacity for now because of an unrelated xfwm4 issue but I'm doing a test build with the other changes and will push ASAP
[17:31] <pitti> cody-somerville: so you'll keep metacity for now? or do without a WM?
[17:31] <cody-somerville> pitti, do without a WM. It seems to work fine.
[17:31] <pitti> cody-somerville: it somewhat does work without any WM, just looks weird if yo invoke the a11y menu (no window decorations, etc)
[17:31]  * cody-somerville nods.
[17:31] <pitti> cody-somerville: but for a3 that's certainly good enough
[17:32] <cody-somerville> pitti, Steve accepted this issue for a2
[17:32] <pitti> cody-somerville: right, but since that's released, I moved it to a3
[17:33] <cody-somerville> doh
[17:33] <cody-somerville> I misread the schedule
[17:33] <cody-somerville> I thought alpha-2 was upcoming
[17:33] <pitti> it's that late already :)
[17:36] <ArneGoetje> mat_t: I don't know
[17:50] <maco> pitti: the a11y stuff will work without window decorations?
[17:50] <pitti> maco: I'm not sure, I didn't actually try the a11y functionality
[17:50] <maco> it cant find any windows by name if i use a tiling wm. i assumed because it doesnt have titlebars
[17:50] <maco> ah
[17:51] <pitti> right, that would be an issue
[17:52] <maco> by the way, you werent around when i asked before, but you're all over the changelog... in sudo, the --with-secure-path, does that need to be set in debian/rules twice (ldap and build-simple) aside from debian/OPTIONS to make it affect the sudo binary?
[17:59] <pitti> maco: I don't know right now, I'd need to have an intense look at the package (sorry, I'm in a meeting right now)
[17:59] <maco> ok
[18:28] <pitti> bryce: what do you think would make more sense for users, nouveau by default, or KMSified nouveau as opt-in?
[18:28] <pitti> bryce: (given that nv by default is pretty much the worst option)
[18:29] <bryce> pitti, my thinking is that KMSified nouveau as opt in makes the most sense, since it enables users wishing to use it the option of using it but we don't force it on them in case it is unstable
[18:30] <bryce> unfortunately I've learned there are still many cards not supported by -nouveau which are supported by -nv
[18:30] <bryce> even aside from KMS (which is also even more limited in the range of cards it supports)
[18:35] <pitti> bryce: well, FSVO "supported" :)
[18:36] <bryce> FSVO == For Some Version Of ?
[18:37] <pitti> "value"
[18:53] <billybigrigger> is anyone else's appearance broken?
[18:53] <billybigrigger> i can't seem to switch gtk themes
[18:53] <billybigrigger> i can switch them in system/appearance, and the preview in appearance works, but then when i close it, gtk is not updated
[19:02] <directhex> there are times when update-maintainer feels silly
[19:02] <directhex> maintainer: ubuntu core developers. WRONG! THAT IS A LIE!
[19:02] <maco> i thought it was supposed to say Ubuntu Developers
[19:02] <directhex> meh, whatever the script changes it to
[19:03] <directhex> point is, sometimes the original-maintainer is more true
[19:04] <maco> scottk said if he's the debian maintainer, he just leaves it in
[19:05] <directhex> i wonder what would happen if dh_installxsp were moved to cli-common-dev
[19:05] <directhex> it would save the need for damn merges
[19:16] <directhex> man, it's ages since i did a merge bug
[19:39] <smb> Someone around who might help me with a question on v4l in Jaunty?
[19:53] <billybigrigger> smb?
[19:55] <smb> Basically its about someone having problems with a gspca driven webcam and cheese, camorama ... because gspca in Jaunty is v4l2 and the apps are v4l1. Now I thought those would get shipped with the compat lib linked in...
[19:55] <smb> bug 352765
[20:01] <veritos> Is it planned to attempt to push the new notification system upstream?
[20:04] <bjf> I'm running Karmic, updated from a Jaunty install. When installing "makedumpfile" it got to "Found kernel: /boot/memtest86+.bin"
[20:04] <bjf> and then it just sits. After about an hour I aborted and tried to install another package. Now I get "E: dpkg was interrupted,
[20:04] <bjf> you must manually run 'sudo dpkg --configure -a' to correct the problem." When I run it, it "hangs" at the same point.
[20:04] <bjf> How do I fix this mess up?
[20:05] <cody-somerville> pitti, updated branch
[20:08] <pitti> cody-somerville: thanks! what was the name again?
[20:08] <billybigrigger> smb, i have the same problem
[20:08] <cody-somerville> https://wiki.ubuntu.com/ARM/BuildEABIChroot
[20:08] <cody-somerville> ooops
[20:09] <cody-somerville> paste error
[20:09] <cody-somerville> pitti, lp:~cody-somerville/gdm/depend-on-minimal-gnome-session
[20:09] <billybigrigger> smb, but the thing is my cam used to work on .30 kernel
[20:09] <billybigrigger> since .31 it hasn't
[20:11] <superm1> cody-somerville, how do you set the default session to come up as !gnome-session after that patch is in gdm?
[20:11] <smb> billybigrigger, Then you would also be able to use your cam with the v4lcompat library preloaded?
[20:11] <billybigrigger> which lib is this?
[20:12] <cody-somerville> superm1, it'll occur automatically
[20:12] <smb> If you look into the bug I posted, there is a description on it
[20:12] <cody-somerville> superm1, or maybe it won't
[20:12] <superm1> cody-somerville, well what session will be picked though?  does it need to be set in dmrc now?
[20:12] <superm1> or does gdm-cdd.conf still do it?
[20:12] <cody-somerville> no
[20:12] <cody-somerville> default session can only be set via dmrc
[20:12] <cody-somerville> as of now
[20:13] <superm1> ugh, that feels, sounds, and smells hacky
[20:13] <cody-somerville> oh it is
[20:13] <cody-somerville> I'm not going to do anything with drmc just yet
[20:13] <cody-somerville> I'm going to petition upstream to allow us to set it in the gdm config again
[20:16] <bjf> dpkg --configure -a is hanging how can I work around it?
[20:17] <superm1> cody-somerville, so what about in the interim for a3 though?
[20:18] <mrec> Hi, is there still some development/bugfixing going on with Ubuntu 8.10?
[20:18] <pitti> cody-somerville: we need to keep the gnome-session dependency; what would be an appropriate xubuntu alternative?
[20:18] <mrec> http://article.gmane.org/gmane.linux.usb.general/15315/match=urb+leak
[20:18] <cody-somerville> pitti, why do you need to keep the gnome-session dependency? Its incorrect.
[20:18] <mrec> this USB bug affects ubuntu intrepid
[20:18] <mrec> lets the system run out of memory after a while with some applications
[20:19] <pitti> cody-somerville: for at-spi integration, gnome-seetings-daemon configuration, and such stuff
[20:19] <ogra> bjf, take a look at /var/lib/dpkg/info/makedumpfile.postinst
[20:19] <cody-somerville> pitti, at-spi should be a suggest like the other suggests I added
[20:19] <pitti> ah, xfce-session
[20:20] <cody-somerville> pitti, gnomne-settings-daemon should be a recommend like I had
[20:20] <pitti> and above all, we need /usr/share/xsessions/gnome.desktop
[20:20] <bjf> orgra, file doesn't exist
[20:20] <pitti> but /etc/xdg/autostart/at-spi-registryd-wrapper.desktop and /etc/X11/Xsession.d/55gnome-session_gnomerc as well
[20:21] <cody-somerville> This isn't how debian packaging is suppose to work. You don't add things as a depends because its convenient.
[20:21] <ogra> bjf, then try sudo dpkg -r makedumpfile and try dpkg --configure -a again
[20:22] <pitti> cody-somerville: ah, wait, we need to seed that anyway
[20:22] <cody-somerville> IMHO you should be able to install gdm and not pull in anything but whats absolutely necessary for gdm to run
[20:23] <cody-somerville> so things like at-spi integration should be suggests and seeded by ubuntu-meta (IMHO)
[20:23] <pitti> cody-somerville: well, but gdm _is_ a gnome session itself
[20:23] <bjf> ogra, same problem "dpkg --configure -a" stops after printing: Found kernel: /boot/memtest86+.bin"
[20:23] <cody-somerville> pitti, not necessarily
[20:23] <ogra> bjf, but the removal of mkdumpfile worked ?
[20:23] <cody-somerville> pitti, It could very well be all xfce if I wrote my a chooser that didn't integrate so heavily with gnome stuff
[20:23] <pitti> cody-somerville: anyway, it looks fair enough right now, so let's upload that to have good dailies tomorrow morning
[20:24] <cody-somerville> pitti, thanks
[20:24] <pitti> cody-somerville: that fixes bug 400901, right?
[20:24] <cody-somerville> pitti, if gdm no longer depends on gnome-session but gnome-session-bin, yes.
[20:25]  * pitti adds bug to changelog
[20:25] <pitti> that's the last (ATM) alpha-3 blocker
[20:25] <seb128> pitti, what change do you upload?
[20:27] <pitti> seb128: r62 in gdm bzr
[20:27] <bjf> ogra, yes, the removal worked
[20:27] <seb128> pitti, hum, k
[20:27] <ogra> hmm, then your problem is not coming from that package at all
[20:28] <pitti> @all, daily desktop/alternate Ubuntu images up for testing
[20:28] <smb> ogra, bjf The message looks like something produced by update-grub
[20:28] <ogra> yeah
[20:28] <bjf> smb, ogra, the full message: Setting up initramfs-tools (0.92bubuntu38) ...
[20:28] <bjf> update-initramfs: deferring update (trigger activated)
[20:28] <bjf> Setting up kexec-tools (20090000-2.0.0ubuntu10) ...
[20:28] <bjf> Searching for GRUB installation directory ... found: /boot/grub
[20:28] <bjf> Searching for default file ... found: /boot/grub/default
[20:28] <bjf> Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
[20:28] <bjf> Searching for splash image ... none found, skipping ...
[20:28] <bjf> Found kernel: /boot/vmlinuz-2.6.31-3-generic
[20:29] <bjf> Found kernel: /boot/vmlinuz-2.6.28-14-generic
[20:29] <bjf> Found kernel: /boot/vmlinuz-2.6.28-11-generic
[20:29] <bjf> Found kernel: /boot/memtest86+.bin
[20:29] <ogra> kexec-tools ....
[20:29]  * ogra wont say a thing about that
[20:29] <ogra> i had my say last release
[20:31] <bjf> ogra, I'll just wait til A3 is available and redo my install, thanks for the help
[20:31] <ogra> bjf, remove kexec-tools
[20:33]  * smb missed that say from ogra. I assume kexec-tools wan't to add something there and get stuck
[20:34] <ogra> smb, kexec-tools was fine until the merge from debian got overridden and someone decided to do a brandnew package instead of merging ... have a look at the version number
[20:34] <bjf> ogra, that cleared it
[20:38] <seb128> cody-somerville, pitti: those gdm suggests should be recommends
[20:39] <cody-somerville> seb128, no they shouldn't be
[20:39] <cody-somerville> seb128, If you want them in Ubuntu, seed them
[20:39] <seb128> cody-somerville, no
[20:39] <cody-somerville> yes
[20:39] <cody-somerville> :)
[20:39] <seb128> cody-somerville, as said the other day apt-get install gdm should give a full functional gdm version
[20:40] <seb128> cody-somerville, yeah, that behaviour is very useful ...
[20:40] <cody-somerville> seb128, Thats not the Debian way of doing things.
[20:40] <seb128> cody-somerville, I'm going to change it to a recommends, want to play change and upload game now?
[20:40] <cody-somerville> seb128, I'm at a great disadvantage when it comes to that game
[20:41] <seb128> so you should try some try to argue in a convincing way
[20:42] <cody-somerville> seb128, I intend to, one sec
[20:42] <mterry> pitti, So let's say I wanted to push a new ubiquity (to fix an issue that makes oem-config unusable), how do I do that in a freeze-friendly way?
[20:42] <seb128> recommends are things which should be installed by default when you want a complete experience of the software
[20:42] <seb128> and gdm lacks power management without gpm for example
[20:43] <seb128> same without the other tools you get no accessibility
[20:43] <cody-somerville> seb128, "Suggests is used to declare that one package may be more useful with one or more others. Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable. "
[20:43] <seb128> which means an user installing gdm will get no power manager nor a11y working
[20:43] <seb128> it's not perfectly reasonable to have no accessibility and power management by default
[20:43] <cody-somerville> seb128, yes it is
[20:43] <seb128> you say that because you don't need accessiblity for example
[20:44] <seb128> you don't do a favor to your users though
[20:44] <cody-somerville> seb128, Its reasonable to find an installation without those things
[20:44] <cody-somerville> seb128, Which is why they should be a suggests
[20:44] <cody-somerville> seb128, and then they should be seeded by the ubuntu seeds
[20:44] <seb128> right, which is why you can remove recommends
[20:44] <cody-somerville> seb128, yes but I can't remove recommends via seeds
[20:44] <seb128> well that's orthogonal
[20:44] <cody-somerville> not at all
[20:44] <seb128> add | xubuntu depends if you want
[20:45] <cody-somerville> No, thats not correct
[20:45] <seb128> but don't break the gdm recommends only to please derivatives
[20:45] <seb128> well find a better way
[20:45] <seb128> but you are not going to break gdm recommends
[20:45] <cody-somerville> This is the correct way
[20:45] <seb128> I will upload a fixed version tomorrow
[20:45] <seb128> no it's not
[20:45] <seb128> read the debian policy about recommends
[20:46] <cody-somerville> seb128, I have
[20:46] <seb128> cody-somerville, well then you argue than power manager and accessibility are important to our users
[20:46] <seb128> +not
[20:46] <cody-somerville> seb128, I agree they're important
[20:46] <cody-somerville> seb128, Which is why they should be seeded
[20:46] <seb128> no you don't
[20:47] <seb128> if they are important they should be recommends
[20:47] <seb128> seed is an ubuntu concept not a debian one
[20:47] <seb128> the policy doesn't take those in consideration
[20:47] <seb128> recommends are what a luser should get installed when doing an apt-get on a base install
[20:47] <seb128> ie what you would expect from a standard experiencez
[20:47] <cody-somerville> seb128, gpm, at-spi are extras
[20:48] <seb128> accessibility is not extra
[20:48] <cody-somerville> seb128, gdm just happens to ship with a default set of desktop files that launch those
[20:48] <seb128> without it you have a class of users who can't use your system at all
[20:48] <cody-somerville> seb128, They're not a dependency in any such way for gdm to run
[20:48] <seb128> they are for it to be usuable for a class of users
[20:48] <seb128> and recommends are not meant to be depends
[20:49] <seb128> but to describe things you likely want when you don't know what you are doing
[20:49] <cody-somerville> seb128, They're suppose to indicate a strong but not absolute dependency
[20:49] <cody-somerville> seb128, Thats incorrect
[20:49] <seb128> ok, let's stop that and say we disagree
[20:49] <cody-somerville> seb128, Recommends declare "a strong, but not absolute, dependency.
[20:49] <seb128> no luck for you don't have upload rights to do your changes
[20:49] <seb128> right
[20:50] <seb128> and having accessibility is a strong recommendation by default
[20:50] <seb128> and having a way to suspend your computer too
[20:50] <cody-somerville> ugh...
[20:50] <seb128> want to try suggesting dropping those from the default install if they are of no use?
[20:51] <seb128> recommends are the equivalent of the seed, ie things we recommend installing by default
[20:51] <cody-somerville> seb128, You're clearly being difficult on purpose. This change will only help Xubuntu and not affect Ubuntu in anyway since you seed the packages anyway.
[20:51] <seb128> if you get those unseeded I'm fine having them not recommended
[20:51] <cody-somerville> s/Xubuntu/<insert other gtk derivative here>/
[20:51] <seb128> well that's not because we have seeds that we should randomly misuse and break recommends and depends
[20:52] <cody-somerville> seb128, No, you're the only thats misusing the relationship fields
[20:52] <seb128> that's not a misuse
[20:53] <seb128> recommends are things that an apt-get install should install as said before
[20:53] <seb128> ie what lusers should get installed to have every feature working
[20:53] <seb128> and that power user can uninstall because they are not hard depends
[20:53] <seb128> that's how they are meant to be used and how they are used for years
[20:54] <cody-somerville> Shipping an autostart desktop file for an application does not mean that application's package should be a recommend, sorry... I just don't buy it.
[20:54] <seb128> the idea is that a lambda user should not have to know that gnome-power-manager need to be installed to have suspend working
[20:54] <seb128> but that if you don't care about it you can uninstall it
[20:55] <seb128> it's not because it has an autostart
[20:55] <seb128> it's because an useful feature which has a button in the UI relies on it
[20:56] <cody-somerville> seb128, no, an application that gdm launches depends on it
[20:56] <seb128> no
[20:56] <cody-somerville> yes
[20:56] <seb128> did you use gdm at all?
[20:56] <cody-somerville> yes, I have
[20:56] <cody-somerville> and there is an autostart file for the chooser
[20:56] <cody-somerville> and the chooser is just a gtk application
[20:56] <seb128> the user list has 3 buttons by default
[20:57] <cody-somerville> seb128, right-o
[20:57] <cody-somerville> seb128, Okay, I can buy gpm being a recommend
[20:57] <seb128> "suspend hibernate restart"
[20:57] <seb128> and the first 2 don't work without gnome-power-manager
[20:57] <cody-somerville> fine, I can agree to g-p-m being moved to recommends
[20:57] <seb128> good
[20:58] <cody-somerville> but the other stuff should be suggests, agreed?
[20:58] <seb128> I will have TheMuso or somebody testing if the banner is accessible without the other tools
[20:58] <seb128> cody-somerville, if that makes the login screen not accessible no
[20:58] <seb128> cody-somerville, you just make impossible for a class of user to use your software
[20:59] <cody-somerville> seb128, which is why they should be a suggest and why you should seed
[20:59] <seb128> cody-somerville, still that defeat the purpose of recommends, which is to provide a good user experience for people not using seeds
[20:59] <cody-somerville> seb128, we don't include a screen reader in ubuntu-standard do we?
[20:59] <cody-somerville> seb128, or sorry, we don't have getty depending on a screen reader
[21:00] <seb128> cody-somerville, gnome-orca: Task: ubuntu-desktop, edubuntu-desktop, xubuntu-live, ubuntu-netbook-remix
[21:00] <cody-somerville> seb128, thats seeds
[21:00] <seb128> well it's default install
[21:00] <cody-somerville> seb128, because of seeds
[21:00] <cody-somerville> seb128, Why doesn't gnome-terminal recommend ocra?
[21:01] <cody-somerville> seb128, and gnome-mag?
[21:01] <seb128> cody-somerville, you don't agree that screen reader is something a class of users depend on?
[21:01] <cody-somerville> seb128, I agree they should be in default install but not a recommends on every single application
[21:01] <seb128> cody-somerville, every single application doesn't have an icon to use the feature and an autostart to run it
[21:03] <seb128> cody-somerville, you still don't get that recommends are things to install to have all the components of the software working
[21:04] <seb128> the reason they are there is that users don't know about suggests and would not understand what to do to get things working if they were not installed by default
[21:04] <cody-somerville> seb128, If they're installing gdm from a base install, I'm pretty sure they understand
[21:04] <seb128> well you argue that recommends are of no use
[21:05] <cody-somerville> seb128, No I don't argue that
[21:05] <cody-somerville> seb128, I argue that recommends are strong but not absolute *dependencies*.
[21:05] <seb128> right
[21:05] <cody-somerville> seb128, look at for example catfish
[21:06] <cody-somerville> seb128, the backends are suggests, not recommends
[21:06] <cody-somerville> seb128, thats the debian way doing things
[21:06] <cody-somerville> seb128, in your definition, they would be recommends
[21:06] <seb128> that's the way one debian package is doing thing
[21:06] <seb128> gvfs recommends gvfs-backends
[21:06] <seb128> firefox recommends ubufox
[21:06] <cody-somerville> Right
[21:07] <cody-somerville> Firefox shouldn't recommend ubufox
[21:07] <cody-somerville> Its abuse of package relationships
[21:07] <infinity> cody-somerville: For Ubuntu, it definitely should.
[21:07] <infinity> cody-somerville: According to Debian policy, anyway.
[21:07] <cody-somerville> infinity, how so?
[21:07] <infinity> cody-somerville: Recommends defines packages "which would almost always be found together, except in the rarest cases", and firefox/ubufox fit that for Ubuntu.
[21:08] <cody-somerville> infinity, I think those sort of relationships should be made via seeds, not in the package
[21:08] <cody-somerville> infinity, but thats just my personal opinion
[21:08] <seb128> cody-somerville, debian has no seed to the recommends definition can't take that in consideration
[21:08] <seb128> to -> so
[21:09] <seb128> you are arguing that recommends should have a different meaning in ubuntu because seeds can be used basically
[21:09] <cody-somerville> seb128, no, I'm not
[21:09] <cody-somerville> seb128, Debian might not use seeds but they do use metapackages
[21:09] <seb128> they don't rely on those
[21:09] <cody-somerville> seb128, yes they do
[21:10] <infinity> cody-somerville: Metapackages in Debian aren't relied on for installation or "system sanity".
[21:10] <cody-somerville> infinity, tasks
[21:10] <directhex> yay tasksel
[21:10] <seb128> cody-somerville, how long have you been actively working on debian?
[21:11] <infinity> cody-somerville: Tasks != metapackages (though we overload them the way we use them), and tasks are STILL not used as recommends in Debian.
[21:11] <infinity> cody-somerville: And, while tasks and tasksel are cool and all, no one uses them to maintain system consistency, just to quickly install a set of packages.
[21:11] <cody-somerville> infinity, Right-o. However, IMHO, it makes sense to use tasks/metapackages/seeds/whatever to define relationships that make sense on the distribution level and keep relationships at the package level to those that only make sense in the scope of the packages.
[21:12] <seb128> cody-somerville, if a software has a feature to launch an another one that's probably because it can make use of it
[21:12] <infinity> cody-somerville: You're arguing that the package isn't part of the distribution? :)
[21:12] <cody-somerville> infinity, In today's world, packages can exist across multiple distributions
[21:12] <cody-somerville> infinity, Thats my thinking
[21:13] <mr_pouit> does gdm specifically require g-p-m?
[21:13] <cody-somerville> mr_pouit, no, it runs just fine without
[21:13] <seb128> mr_pouit, to be able to use the suspend and hibernate button on the login banner yes
[21:13] <cody-somerville> We could patch the login chooser to grey them out/hide them if gpm isn't present if it doesn't do that already
[21:13] <mr_pouit> seb128: is that really so? doesn't it rely on something providing org.powermanagement/whatever?
[21:13] <seb128> mr_pouit, which is what recommends are for having standard features exposed to users working
[21:14] <seb128> mr_pouit, right anything having the same dbus interface
[21:14] <seb128> mr_pouit, which is why I suggested having gpm | xubuntu-gpm before
[21:15] <mr_pouit> we can do that, and everyone should be happy :]
[21:15] <seb128> that's what I argued first
[21:15] <seb128> but cody-somerville doesn't think it's right
[21:15] <cody-somerville> we don't have "xubuntu-gpm"
[21:15] <cody-somerville> but I can agree to gpm to being in recommends
[21:15] <cody-somerville> Its the other stuff that gdm might launch that I think should be suggests
[21:15] <cody-somerville> like gnome-mag
[21:15] <seb128> other things are what make gdm accessible
[21:16] <seb128> you realize that you just argue that we should cut a class of users out?
[21:16] <mr_pouit> (xubuntu-gpm = xfce4-power-manager btw)
[21:16] <cody-somerville> seb128, yes, I realize that
[21:17] <cody-somerville> seb128, which is why we use seeds in Ubuntu to produce a distribution that doesn't do that
[21:17] <seb128> again recommends is debian policy recommendation and doesn't take seeds in account
[21:17] <seb128> recommends are thing you should get when installing the software from a base image
[21:18]  * cody-somerville sighs.
[21:19] <pitti> mterry: wait, I just discovered another bug I'd like to fix in ubiquity
[21:19] <pitti> mterry: so if you need some changes, please commit them now
[21:19] <cody-somerville> seb128, How about I just upload gdm2.20 and you can do whatever you want with your new gdm
[21:19] <mterry> pitti, done
[21:19] <mterry> pitti, thx
[21:20] <pitti> mterry: do you know the process of updateing included source packages and building a source? anything magic with that?
[21:20] <seb128> cody-somerville, feel free if you get somebody to new it for you and you are wanting to maintain it and handle bugs
[21:20] <mterry> pitti, I believe it's just the 'update' rule
[21:20] <mterry> pitti, (make -f debian/rules update)
[21:22] <bassbluete> Hi developer team
[21:23] <bassbluete> at www.ubuntuusers.de I have ad a thread  to stop WiFi blinking for Dell D630 Latidude
[21:23] <bassbluete> it is not possilbe to ad this in the actual ubuntu 9.10
[21:24] <mathiaz> jcastro: hey - is there a ruby team in Ubuntu?
[21:26] <pitti> mterry: any idea what update-local is? I'd rather not wait for the next publisher run for the one-line patch to user-setup which I just uplaoded
[21:27] <mterry> pitti, no, I've never used it
[21:29] <pitti> mterry: are you still going to be around for a while?
[21:29] <mterry> pitti, for about an hour
[21:30] <pitti> oh, ok
[21:30] <pitti> user-setup 1.27ubuntu5.dsc will be published in 90 minutes
[21:30] <pitti> and I'd like ubiquity to pick this up
[21:30] <pitti> but oh well, will do it tomorrow early morning then
[21:31] <slangasek> pitti: something I can help with?  I'm not gone yet, nor is my workday over :)
[21:31] <pitti> slangasek: I fixed bug 402707 in user-setup (unbreaking autologin)
[21:31] <EvanCarroll> is there anyway to update udev in a chroot, I have a failued upgrade to jaunty and one of the post-inst scripts is failing because it can't patch udev
[21:31] <pitti> slangasek: so if you could debian/rules update ubiquity in ~ 2 hours and upload that?
[21:32] <pitti> slangasek: it's not the end of the world, but it's such a simple fix
[21:32] <pitti> slangasek: it just appals my sense of beauty and perfection :)
[21:33] <slangasek> pitti: sure, I can do that
[21:33] <pitti> slangasek: I'm sure cjwatson has a clever way of updating directly from bzr instead of waiting for the publisher, but I don't know it
[21:33] <pitti> and I'd rather not mess things up
[21:33] <pitti> slangasek: thanks!
[21:33] <pitti> good night everyone then
[21:34] <pitti> tomorrow's dailies should be smooth as silk then
[21:37] <superm1> pitti, considering the necessity for a re-roll would that be an opportunistic time if i cherry picked the patch that fixed bug 401971 too?
[23:51] <Ampelbein> Riddell: still there?
[23:53] <Ampelbein> Riddell: regarding mjpegtools, I was in the opinion that -0ubuntu3 got uploaded due to comment 13, https://bugs.edge.launchpad.net/ubuntu/+source/mjpegtools/+bug/351017/comments/13 . But apparently that was not the case so I uploaded it myself.