[00:01] <Keybuk> kees: gcc probably doesn't like being compiled with -foh-hai -fi-can-haz-securitah
[00:02] <mneptok> make --onan=true
[00:02] <kees> Keybuk: the compiler part doesn't seem to mind, but the testsuite complains in parts
[00:03] <kees> slangasek: gcc-4.3 wc -l on rules* is 10090.  mpich is just 292 :)
[00:04] <slangasek> oh, well, there's that
[00:04] <slangasek> though maybe it wasn't mpich, maybe it was some package that build-deps on mpich
[00:05] <slangasek> hdf5, maybe
[00:53] <pwnguin> kees: what about gcc-avr? surely cross compilation is more confusing
[00:54] <slangasek> I think gcc-avr inherits all of its specialness from the gcc rules
[00:54] <kees> pwnguin: gcc does ppc cross compiles too.  :)  but yeah, I probably shouldn't try to nominate "2nd most confusing" I bet there are tons
[00:55] <pwnguin> tinyOS comes to mind
[01:19] <kirkland> pitti: broken links to http://people.ubuntu.com/~pitti/ubuntu-cve/unfixed.html and http://people.ubuntu.com/~pitti/ubuntu-cve/unchecked.html on https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
[01:24] <kees> kirkland: I'll fix that, one sec
[01:27] <kees> kirkland, pitti: MIR wiki adjusted.
[01:27] <kirkland> kees: thanks
[02:35] <confused_david> hi
[06:25] <pitti> Good morning
[06:26] <Hobbsee> pitti!
[06:26]  * Hobbsee throws pitti a gummy bear in greeting
[06:26] <pitti> hey Hobbsee!
[06:26] <colo939> morning
[06:26] <pitti> kees: thanks for fixing the wiki
[06:30] <colo939> so are you all members of Ubuntu's development team?
[06:33] <Hobbsee> mostly, yes
[06:34] <colo939> cool, I have to say you guys are really doing a great job
[06:35] <TheMuso> colo939: Thanks for the compliment. It is nice to know our work is appreciated.
[06:36] <colo939> I might be interested in getting involved somewhere in the near future
[06:56] <dholbach> good morning
[07:43] <pitti> bryce: btw, fakesyncs should be Nbuild1, not Nubuntu1, and shouldn't have XSBC-Maintainer
[07:51] <bryce> pitti: ok, I had looked for documentation on how to do fakesyncs but didn't see any so just followed how it had been done previously
[07:51] <pitti> bryce: well, it isn't wrong, but with build1 it's pointed out more explicitly, and it'll get autosynced again as soon as Debian gets a new orig.tar.gz
[07:58] <persia> bryce: General rule is for fakesyncs, only debian/changelog should differ from Debian (and better to use *buildN)
[08:10] <dholbach> hi seb128
[08:11] <seb128> hello dholbach
[08:11] <\sh> moins
[09:05] <asac> pitti: did you do tzdata update?
[09:05] <pitti> asac: yes, why?
[09:05] <asac> pitti: http://paste.ubuntu.com/18981/
[09:06] <pwnguin> heh
[09:06] <asac> pitti: [reed] got his java removed because of it :)
[09:06] <[reed]> I didn't use java anyway ;)
[09:06] <pwnguin> why = ?
[09:06] <pitti> asac, [reed]: seems you don't have hardy-updates for universe?
[09:07] <pitti> Package: tzdata-java
[09:07] <asac> pitti: he says that he has no -proposed at all
[09:07] <pitti> Version: 2008c-1ubuntu0.8.04
[09:07] <pitti> Depends: tzdata (= 2008c-1ubuntu0.8.04)
[09:07] <asac> was tzdata-java updated in -proposed?
[09:07] <pitti> asac: right, for hardy it's in -updates already
[09:07] <[reed]> root@jarodplus:~# cat /etc/apt/sources.list | grep hardy-updates
[09:07] <[reed]> deb http://us.archive.ubuntu.com/ubuntu/ hardy-updates main restricted
[09:07] <[reed]> deb-src http://us.archive.ubuntu.com/ubuntu/ hardy-updates main restricted #Added by software-properties
[09:07] <[reed]> deb http://people.ubuntu.com/~ubuntu-archive/ddebs hardy-updates main universe
[09:07] <pitti> yes, it was
[09:07] <pitti> [reed]: right, no hardy-updates for universe
[09:07] <asac> ok then its just a transitional thing?
[09:07] <pitti> asac: no, it's not
[09:07] <asac> okay ;)
[09:07] <asac> i see
[09:08] <pitti> asac: this will happen very commonly with sources which build binaries for both main and universe
[09:08] <pwnguin> so they DO exist
[09:08] <pitti> yes, in hardy-updates
[09:08] <persia> Is there a way to reduce the chance of this happening?
[09:08] <pwnguin> (packages that build universe and main)
[09:09] <pitti> well, we could add some sanity checks to update-manager perhaps
[09:09] <persia> pwnguin: Lots of them.  Source is in main, but some of the binaries aren't.
[09:09] <pitti> but either way, update-manager *removing* packages is a bug on its own
[09:09] <asac> [reed]: you appear to not have  universe at all in your sources.list
[09:09] <pitti> mvo: ^ it still does that?
[09:09] <pitti> asac: (NB that he just grepped for hardy-updates, not hardy itself)
[09:09] <persia> pitti: fixing update-manager is a way to reduce the impact, but is it not possible to synchronise the -updates push for all binaries in a single source?
[09:10] <pitti> persia: that's already done
[09:10] <[reed]> asac: http://paste.ubuntu.com/18984/
[09:10] <persia> Also, update-manager will still remove packages in certain circumstances, where there's no declared dependency.
[09:10] <pitti> persia: but if someone has hardy-updates/main in their sources.list, but not hardy-updates/universe, that won't help him
[09:10] <persia> pitti: I see.  It's a matter of sources.list, rather than the state of the archive.
[09:11] <pwnguin> people.ubuntu.com?
[09:11] <[reed]> dbgsym packages
[09:12] <[reed]> for generating proper, complete stacks in gdb
[09:12] <pwnguin> sure
[09:12] <asac> [reed]: you dont have hardy-updates at all in your sources.list
[09:12] <[reed]> asac: well, I haven't touched this file in a long time
[09:12] <asac> [reed]: err, same parse error on my side :)
[09:12] <persia> asac: "| grep universe"
[09:12] <asac> yeah
[09:13] <pwnguin> unless theres a problem with that, i'd just well paste the whole thing
[09:13] <persia> [reed]: You'll want to add universe to your hardy-updates line.
[09:13] <[reed]> pasting entire file now
[09:13] <asac> [reed]: ++
[09:13] <[reed]> http://paste.ubuntu.com/18987/
[09:14] <[reed]> guess I could remove the Canonical partner archive... added it for parallels
[09:14] <[reed]> hmm
[09:14] <persia> That's not the issue.  You need to mirror lines 6&7 after line 16.
[09:15] <[reed]> I know... I'm thinking out loud
[09:15] <[reed]> :)
[09:15] <asac> mvo: ^^ for the above (20 lines) ... does apturl add the proper section for -updates as well?
[09:16] <pwnguin> proper care and maintaince of source.list is vital for smooth operation ^_^
[09:17] <mvo> asac: generally it does if universe was enabled at the time when apturl was run
[09:17] <[reed]> pwnguin: and you expect some average user that doesn't know Linux at all to know that? ;) (I'm not an average user by any means, but just thinking of all those users who don't understand this stuff)
[09:18] <asac> [reed]: i think pwnguin tried to be sarcastic :)
[09:18] <pwnguin> most "average users" should the software sources tool. which i expect works, but nobody i know uses it
[09:19] <asac> mvo: you mean "... when -updates was enabled when running apturl" ?
[09:20] <asac> mvo: just wonder if he ended up in this state when installing icedtea plugin through apturl
[09:21] <mvo> asac: I haven't seen the apturl line, but if e.g. the sources.list has "hardy universe" and apturl is run with "apturl apt:foo?section=universe" it will not add anything because universe is enabled already.  if it is not in the file, then it will add it and also add -updates
[09:22] <mvo> hm
[09:22] <asac> mvo: hmm. ok, worth a bug? e.g. add universe to -updates if hardy-updates line exists already?
[09:22] <asac> e.g. if user has not opted out of -updates
[09:24] <mvo> feel free, I'm not sure if we can catch all corner cases, but we can try. was the content of the pastebin manully edited? or only through tools like software-properties/apturl etc
[09:24] <mvo> ?
[09:25] <Mirv> asac: yep, no issue
[09:25] <asac> mvo: at least the dbgsym lines were added manually i guess
[09:25] <asac> [reed]: did you do any other manual operations on your sources.list?
[09:26] <[reed]> hmm, probably uncommented stuff over the years
[09:26] <[reed]> back when I first installed edgy
[09:26] <[reed]> or dapper?
[09:26] <[reed]> can't remember
[09:27] <[reed]> hmm, update manager is offering me more updates now
[09:27] <[reed]> :)
[09:27] <[reed]> 33 more updates
[09:27] <[reed]> and half of these are Firefox-related
[09:28] <[reed]> 19 / 33 updates are Firefox related, hah
[09:30] <[reed]> er, 20 of 33.
[09:31] <asac> [reed]: how did you count that?
[09:31] <asac> :)
[09:31] <[reed]> I looked at the changelogs for all 33, plus I know the ones that are related.
[09:43] <pitti> [reed]: please note that people.ubuntu.com/~ubuntu-archive/ddebs is now called http://ddebs.ubuntu.com/
[09:43] <pitti> this was announced some months ago on u-devel-announce@
[09:43]  * [reed] updates
[10:34] <pecisk> hi people, does FF3 respect /etc/alternatives/mozilla-flashplugin? I have set it to swfdec and removed pluginreg.dat from profile folder but it still gets recreated with Adobe Flash as default swf player, as about:plugins shows
[10:35] <pecisk> another question is - is this a bug or expected behaviour?
[10:40] <MacSlow> how do I force the creation of a -dbg package?
[10:40] <pitti> MacSlow: that needs packaging changes
[10:40] <gnomefreak> pecisk: it uses xulrunner-plugins
[10:40] <pitti> MacSlow: however, you can automatically create those -dbgsym packages
[10:40] <pitti> MacSlow: by installing pkg-create-dbgsym and just building the source package once
[10:40] <MacSlow> pitti, anything I need to pass to dpkg-buildpackage?
[10:40] <pitti> MacSlow: no, it's fully automagic
[10:40] <gnomefreak> pecisk: the exact name is off but look for something like that using 1.9
[10:41] <pitti> MacSlow: if you need them for an existing ubuntu package, they shuold be on http://ddebs.ubuntu.com
[10:41] <MacSlow> pitti, no I want to create it for libgksu I'm testing here locally with a patch of my own
[10:41] <pecisk> gnomefreak: ahhhh so, I see. Well, thanks
[10:41] <pitti> MacSlow: ah, then a local build will be fine, yes
[10:41] <gnomefreak> pecisk: np
[10:46] <Riddell> mvo: you seem to have uploaded a SRU for bug 198292, but you havn't made any comment on that bug
[10:46] <Riddell> leading other people to have created other patches
[10:52] <mvo> Riddell: let me check
[10:54] <mvo> Riddell: oh, sorry - yeah, I uploaded it 8 days ago and forgot to mention that in the bug :(
[10:55] <Riddell> mvo: can you attach your debdiff to the bug, then I'll let it through
[10:55] <mvo> ogra: could you please have a look at bug #231104 - sounds like a broken edubuntu applications.menu file, do you know anything about this? is it fixed in later versions?
[10:55] <mvo> Riddell: sure, give me a sec
[10:56] <ogra> mvo, checking
[10:57] <mvo> Riddell: *cough* I think motion was drive-by-fixing on my part, I think I don't have the uploaded bits anymore :/
[10:57] <mvo> iirc it was a very esay fix, this is why I not bothered too much
[10:58] <Riddell> mvo: let me jog your memory http://people.ubuntu.com/~jriddell/motion.debdiff :)
[10:58] <persia> mvo: You could probably reconstruct by downloading from unapproved and hardy, and running debdiff :)
[11:00] <mvo> Riddell: thanks, I'm updating the bugreport now
[11:01] <ogra> mvo, i attached the file, but cant find anything wrong in there (and i know tons of people have used it successfully)
[11:02] <mvo> ogra: thanks, it might be a) bad CD burn b) old CD that contained a bad file
[11:03] <ogra> yeah, i'd guess so... he doesnt say which app he tried to install though
[11:06] <mvo> Riddell: updated the bug
[11:09] <Riddell> mvo: accepted, is it fixed in intrepid?
[11:10] <Riddell> mm "* Fixed: init script hangs on startup" suggests it is, groovy
[11:10] <mvo> Riddell: yes, it got fixed in debian
[11:10] <mvo> Riddell: thanks and sorry for the confusion
[11:40] <asac> pitti: http://paste.ubuntu.com/19017/
[11:40] <asac> i think its bug 236115
[11:41] <asac> wasnt in the RC1 bug
[11:41] <asac> just copy over?
[11:41] <pitti> uh, wow, WTF? https://edge.launchpad.net/ubuntu/+source/epiphany-extensions/2.22.2-0ubuntu0.8.04.1 shows it as built for amd64
[11:42] <asac> pitti: well ... it wasnt build when you copied it :(
[11:43] <asac> pitti: let me know what i should do ... i can verify that thing for you so you can copy the rest
[11:44] <pitti> cprov: I think I need your help here
[11:44] <Riddell> doko: how come ca-certificates-java is marked as contrib?  it seems to depend on stuff in universe only
[11:44] <pitti> cprov: ubuntu/pool/main/e/epiphany-extensions/epiphany-extensions_2.22.2-0ubuntu0.8.04.1_amd64.deb exists on drescher, and https://edge.launchpad.net/ubuntu/hardy/amd64/epiphany-extensions/2.22.2-0ubuntu0.8.04.1 looks fine as well, but it isn't published in either hardy-proposed nor hardy-updates
[11:46] <doko> Riddell: ohh, please move it to universe; that was for the debian upload (where the recent upload was done for non-free)
[11:46] <Riddell> doko: ok, accepted
[11:47] <sistpoty|work> Riddell: thanks for the xdg-open hint for tk-brief (oh, and dpkg-source tricked me with removing the cvs dir... I'll respin an upload tonight or so)
[11:47] <cprov> pitti: that version is only published in proposed
[11:48] <Riddell> sistpoty|work: ok, poke me when it's uploaded
[11:48] <pitti> cprov: can it be rescued with copy-package to become published in hardy-updates?
[11:48] <pitti> cprov: ATM it's not even in hardy-proposed's amd64 Packages.gz any more
[11:48] <pitti> cprov: (or not yet, it just finished building)
[11:48] <sistpoty|work> Riddell: sure, will do (but I guess it won't happen before 7 or 8 UTC today)
[11:48] <cprov> pitti: and it will be listed in the index within 5 minutes or so
[11:49] <cprov> pitti: I meant the source
[11:49] <cprov> pitti: it's just a matter of waiting, not a bug, right ?
[11:50] <pitti> cprov-lunch: well, not really a bug, I'm just not sure how to recover from this
[11:50] <pitti> cprov-lunch: we copied to -updates before the amd64 build was done
[11:50] <pitti> and deleted from -proposed 4 hours ago
[11:50] <pitti> and now the build arrived
[11:50] <pitti> so we don't have any source to copy-package any more
[11:50] <pitti> just the amd64 binary
[11:56] <pitti> asac: working on it
[11:57] <pitti> Keybuk: do you have some time today or tomorrow to discuss https://blueprints.edge.launchpad.net/ubuntu/+spec/gdm-guest-login ?
[11:57] <Riddell> is there any consensus about what to do with bug 175508 ?
[11:58] <Riddell> bdmurray, ScottK, siretart?
[12:01] <heno> Riddell: IMO it should be removed until we can make it DTRT
[12:02] <heno> which is report bugs in LP or deffer to Apport or something
[12:05] <Keybuk> pitti: sure
[12:06] <Riddell> heno: what about reportbug?
[12:06] <Riddell> currently it e-mails ubuntu-users, which seems pointless
[12:07] <pitti> Keybuk: I wrote an initial braindump now, but I left a big TODO item there, about how to plumb together gdm, that guest session binary, and PAM
[12:07] <pitti> Keybuk: so I'd like to pick your brain about PAM
[12:07] <pitti> Keybuk: maybe we can deal with it on tomorrow's phone call?
[12:09] <heno> Riddell: agreed. It gives an incorrect impression that the issue will be tracked
[12:09] <Keybuk> pitti: sure
[12:09] <heno> Riddell: I would advocate removing that too
[12:10] <pitti> Keybuk: ok, thanks
[12:12] <siretart> Riddell: my opinon is stated in the bug. I find the tool useful and therefore would vote to keep it
[12:13] <siretart> Riddell: it might have bugs and be preferable adapted to offer the user a choice to report a bug either to debian or launchpad, but I wouldn't consider that making the package unreleasable
[12:13] <siretart> Riddell: same applies to reportbug
[12:14] <siretart> in the end, both packages are in universe for a reason
[12:25] <ScottK> Riddell: At UDS, James Westby said he'd fix it.
[12:26] <ScottK> IIRC it's reportbug that mails ubuntu-users.  Reportbug-ng will send stuff to Debian.
[12:26] <ScottK> Reportbug should definitely NOT be removed.  It's quite useful for reporting bugs to Debian when that's appropriate.
[12:27] <ScottK> Reportbug-ng just got removed from Testing for being not sufficiently useful, so removing it for now wouldn't be awful.
[12:27] <ScottK> Riddell:^^^
[12:35] <Riddell> siretart: how is reportbug useful for debian reporting when it reports to ubuntu-users?
[12:35] <heno> We should at least coordinate the use of reportbug (if configured to send to Debian) though.
[12:36] <sistpoty|work> Riddell: it has a -B switch to choose debian's BTS
[12:37] <heno> Don Armstrong (Debian BTS guy) felt that even bugs in unmodified packages were not self-evidently Debian issues because we run them in an Ubuntu environment with our own configurations
[12:38] <heno> so the bugs reported from us should at least be tagged clearly as such (are they?)
[12:38] <siretart> Riddell: by using it with 'reportbug -Bdebian' - at least that's the only way I use it.
[12:39] <heno> siretart: is it obvious on the Debian end that the bug is from Ubuntu?
[12:40] <siretart> heno: sort of, it is at the end of the message if the user didn't delete that from the template.
[12:41] <siretart> heno: the more challenging problem is that most ubuntu users are not aware what happens to their message, read: the have no idea where the report goes to and who is in charge dealing with it.
[12:41] <sistpoty|work> siretart: by default it actually gets stuck at fiordland anyways ;)
[12:42] <heno> ok, so we would need to modify reportbug to provide that info
[12:42] <siretart> sistpoty|work: that's why I configured it in my user config to use /usr/bin/sendmail.
[12:42] <siretart> heno: even better: make it report to launchpad.
[12:43] <sistpoty|work> siretart: heh
[12:43] <heno> what features does it have that apport doesn't?
[12:44] <heno> as in "apport-cli -f -p PACKAGE"
[12:44] <siretart> heno: I don't see how apport and reportbug(-ng) relate.
[12:45] <\sh> siretart: I thought reportbug-ng is past tense for lenny?
[12:45] <siretart> \sh: I expect it to be fixed in time
[12:46] <\sh> siretart: let's hope :)
[12:46] <siretart> heno: reportbug e.g. support package specific hooks for collecting extra data. it respects the Bugs: field of the package, it does not require authentication -- there are so many fundamental differences that I wouldn't even consider comapring it to apport
[12:49] <heno> siretart: they both collect info to help you file a better bug. Apport supports package hooks as well https://wiki.kubuntu.org/Apport
[12:50] <heno> they seem to me to have some overlap :)
[12:50] <heno> though I'm sure there are major differences too
[12:51] <siretart> heno: which are not the same hooks we already have in debian. so we need to reimplement all those nice hooks in debian pacakge again for ubuntu :/
[12:52] <siretart> heno: but I think the most important point for this discussion here is: apport cannot be used to report bugs to debian. that's why I stick to reportbug and reportbug-ng
[12:54] <heno> and I think the question is whether we as Ubuntu should ship a package that does that (or perhaps that should be installed directlt from debian for those who want it) IMO the answer will depend on debian's view on getting bugs from us
[12:54] <heno> (to the extent there is a "debian's view")
[12:56] <sistpoty|work> heno: given that reportbug itself doesn't by default report anything to debian, unless you fiddle with command line switches and configuration, I guess it's the risk of bugs reported to the wrong BTS is minimal
[12:56] <pitti> epiphany-extensions | 2.22.2-0ubuntu0.8.04.1 | hardy-updates | source, amd64, i386, lpia, powerpc
[12:56] <pitti> asac: ^
[12:56] <pitti> lool: ^ as well
[12:57] <heno> sistpoty|work: true, but the default configuration is definitely bad :)
[12:57] <sistpoty|work> heno: heh, yeah :)
[13:01] <siretart> heno: it may be buggy. but still not a reason to remove it, IMO.
[13:03]  * asac hugs pitti 
[13:04] <heno> siretart: ok, I don't have strong feelings about it; if it has a use case and is otherwise used carefully, and isn't causing annoyance in debian then I'm not worried
[13:12] <ScottK> The bigger problem is reportbug-ng that does report bugs to debian by default even though it's supposed to know better.
[13:23] <Keybuk> Finally, Stallman suggested keeping Oyster cards in aluminium foil when they aren't actually being scanned for travel, to prevent them being scanned secretly.
[13:23] <Keybuk> assuming he has spare foil left over from his hat
[13:23] <Hobbsee> oyster cards?
[13:24] <Hobbsee> ah, transport card.
[13:42] <mvo> pitti: how can I force a retrace of bug #205797 ?
[13:42] <pitti> mvo: re-tag it with need-retrace-i386
[13:42] <pitti> mvo: but the retracers are down ATM
[13:42] <pitti> still on my TODO list
[13:43] <mvo> thanks, I added it now
[13:57] <Keybuk> pitti: did you merge devmapper?
[13:58] <pitti> Keybuk: yes, last week or so
[13:58] <Keybuk> pitti: you can have #238793 then :p
[13:58] <pitti> argh, TIL stickyness?
[13:58] <Keybuk> no
[13:58] <ogra> _MMA_, ping
[13:58] <Keybuk> part of the export patch appears to be missing
[13:59] <pitti> Keybuk: ok, I'll have a look; sorry
[13:59] <_MMA_> ogra: Hello sir.
[14:00] <ogra> _MMA_, hey, i was wondering what you think about the idea to pull in ubuntoon into edubuntu in intrepid :)
[14:00] <ogra> i see it isnt in the archive yet
[14:01] <_MMA_> ogra: Sure. I had meant to talk to you in Prague about it. Lemmie give it a update this week (most likely tomorrow) and Ill ping you when done. Sound cool?
[14:02] <ogra> _MMA_, absolutely, no hurry artwork deadline is still far out (and i ted to ignore it slightly in edubuntu anyway :) )
[14:02] <ogra> *tend
[14:02] <_MMA_> ogra: Cool.
[14:05] <lool> pitti: Cool, thanks
[14:06] <lool> pitti: Could you check gcc-defaults/lpia too?
[14:07] <lool> It seems to be there for amd64 and i386
[14:07] <pitti>        gcj | 4:4.2.3-1ubuntu6 | hardy-updates | amd64, hppa, i386, ia64, lpia, powerpc, sparc
[14:07] <pitti> lool: really? it's fine on drescher
[14:07] <lool> pitti: How do you do that madison on all arches?
[14:07] <lool> or dak ls :)
[14:08] <pitti> lool: that's madison-lite on drescher
[14:08] <pitti> which uses the actual archive's Packages.gz
[14:08] <StevenK> Which rmadision hooks into
[14:08]  * lool doesn't have drescher access unfortunately
[14:08] <pitti> rmadison does not have ports
[14:08] <StevenK> lool: ^
[14:08] <StevenK> Oh
[14:08] <StevenK> Pity
[14:08] <lool> I'm using rmadison a lot, I wish there would be a ports' cgi too
[14:10] <lool> pitti: Aha, my script thought gcc was missing because I didn't know how to retrieve the Source version of a binary package when it's different from the source, so I was looking at any binary from this source with this version; there was none for gcc-defaults, but I now have an example to get the source version of a binar
[14:11] <lool> y
[14:11] <lool> pitti: (Source: gcc-defaults (1.62ubuntu6))
[14:11] <lool> I'll update my script now that I have proper sample data
[14:13] <lool> Hmm I see rmadison has a flag to filter which architecture to output; I guess we could simply add support for it in the ubuntu madison cgi
[14:15] <pitti> asac: oh, ffox rc2 changes abi again? I. e. everything needs a rebuild again?
[14:17] <asac> pitti: who said that?
[14:18] <pitti> asac: you created tasks for all of the reverse dependencies for the "RC2 update" bug
[14:18] <asac> pitti: those are investigation bugs. most are already invalid
[14:18] <pitti> oh, ok
[14:18] <asac> pitti: e.g. check for regressions (besides ABI/API which should be ok)
[14:19] <asac> pitti: most likely just firefox-3.0 and xulrunner-1.9 ... and even those were uploaded with lax dependencies
[14:20] <geser> pitti: can you please remove libversion-perl from the NEW queue? I didn't catch that it got removed from intrepid. Thanks.
[14:27] <pitti> geser: done
[14:27]  * pitti yays -- finally a fully DKMSified, packaged, and working dvb-T driver for hardy
[14:32] <ogra> pitti, oh, really ? i didnt see the kernel fix in any changelogs
[14:32] <pitti> ogra: no, in my PPA; I just blogged about it
[14:32] <ogra> ah
[14:34] <geser> kirkland: hi, are you aware that select-editor doesn't write ~/.selected_editor if only one exists and sensible-editor fails to source that file and fails
[14:59] <superm1> pitti, after you get some reports on it, perhaps would you get it into hardy-backports for wider adoption?
[15:03] <pitti> superm1: hm, maybe
[15:03] <pitti> I didn't actually plan to upload it into intrepid, though
[15:04] <pitti> since that would mean I officially have to maintain it for very long :)
[15:04] <kirkland> geser: please clarify....
[15:04] <superm1> ah right :)
[15:05] <geser> kirkland: when I try to call sensible-editor in my intrepid chroot I get: .: 17: Can't open /home/michael/.selected_editor
[15:05] <pitti> superm1: once jockey gets supoprt for an online driver db, I'd rather link it in the db and keep the driver in a ppa
[15:06] <kirkland> geser: does /home/michael exist?
[15:06] <geser> kirkland: sure
[15:06] <geser> kirkland: this only happens when VISUAL and EDITOR are unset
[15:07] <kirkland> geser: right, that's the case where select-editor should kick in
[15:07] <kirkland> geser: let me understand why it can't write that file, though
[15:07] <kirkland> geser: what user is executing it?
[15:07] <kirkland> geser: and would that user not have write access to /home/michael/.selected_editor ?
[15:08] <geser> kirkland: looking at the code of select-editor it calls "update-alternatives --list editor | wc -l" which gives 1 for me and skips the next if where that file is created
[15:08] <kirkland> geser: ah, good catch
[15:24] <kirkland> geser: hey, i've got a fix...  can you open a bug in launchpad against debianutils?  i'll attach a debdiff and get it sponsored asap.  https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/debianutils
[15:36] <kirkland> geser: nevermind, i filed one: https://bugs.edge.launchpad.net/ubuntu/+source/debianutils/+bug/238879
[15:43]  * pitti tosses bug 237317 back to lool
[15:45] <kirkland> geser: debdiff attached.  you can apply the patch locally against /usr/bin/select-editor if you like
[15:47] <kirkland> kees: hopefully you can sponsor the fix for https://bugs.edge.launchpad.net/ubuntu/+source/debianutils/+bug/238879 when you get in
[15:55] <asac> pitti: do you have cycles to let xul + ffox into -proposed today?
[15:56] <geser> kirkland: I've tested the patch and can confirm that it fixes the issue. Thanks.
[15:56] <kirkland> geser: excellent, wanna note that in the bug?  might help accelerate sponsorship.....
[15:58] <pitti> asac: I need to run out in 5 minutes, but I'll touch it now
[15:59] <geser> kirkland: done
[16:00] <kirkland> geser: thx
[16:00] <kirkland> pitti: can you sync the -46 version of ecryptfs-utils in Debian to Intrepid?
[16:00] <asac> pitti: thanks so much.
[16:02] <pitti> kirkland: will happen during autosync, will do tomorrow morning
[16:02] <pitti> kirkland: (sorry, need to run out soon)
[16:02] <kirkland> pitti: good enough for me
[16:02] <kirkland> pitti: thanks
[16:06] <tseliot> pitti: email sent. The links are there.
[16:14] <bdmurray> Riddell: While I'm a bit late and haven't read the whole discussion I think it is worth keeping too
[16:16] <Riddell> bdmurray: I think I'll just leave it and hope someone else sorts it :)
[16:17] <bdmurray> heh
[16:46] <lool> MacSlow: Hey, cairo-clock Recommends compiz: is this really needed?
[16:48] <Riddell> tkamppeter: are you able to merge cups-pdf sometime?  I'm down for it as the last uploader but I think you are a better person to merge it with Debian
[17:02] <tkamppeter> Riddell, OK, I can do so.
[17:05] <MacSlow> lool, well a compositor... that can be either compiz or metacity (with an enabled compositor)
[17:06] <lool> MacSlow: It seems that even without compositor, it will work, just wont be transparent, right?
[17:06] <MacSlow> lool, but since one cannot put "metacity (with enabled compositor)" in the control file I chose compiz
[17:06] <lool> MacSlow: We're pulling cairo-clock in UME now, I'd rather not pull compiz though; perhaps this should simply be covered in the doc -- compiz is the default in Ubuntu anyway, no?
[17:06] <MacSlow> lool, no I intercept that and present the user an error-message.
[17:07] <lool> Oh, so it's handled at runtime already
[17:07] <lool> Not sure we need to have a dep then
[17:07] <MacSlow> lool, of course... that's why I used "recommends" and not "depends"
[17:07] <lool> agoliveira told me it works on his laptop with compositing enabled and not running compiz
[17:07] <MacSlow> lool, but I thought that's what the field "recommends" was meant for
[17:07] <Riddell> tkamppeter: thanks
[17:08] <lool> MacSlow: As you were saying, it's quite an imprecise way of saying "anything providing compositing"; we could use virtual packages for this, but it would be a bit heavy
[17:08] <lool> MacSlow: I think in your case you want a Depends on a compositor
[17:09] <lool> MacSlow: But as there's no virtual provide for this, and it's per user anyway -- or even per session -- I'm not sure you want to reflect in the dependencies
[17:09] <MacSlow> lool, gee... I won't be the one introducing stuff like that :) I'm not enough of a MOTU to forsee all the implication such a suggestion could have.
[17:10] <ogra> just move Recommends: compiz to Suggests: compiz
[17:10] <lool> Yes, that's what I wanted to offer
[17:10] <lool> MacSlow: Would you mind if I downgraded to suggests in intrepid?
[17:10] <lool> Or removed the dep entirely, perhaps adding a README in the package?
[17:11] <ogra> that way even openbox users with xcompmgr can use it without cluttering their disk wih compiz
[17:11] <MacSlow> lool, np
[17:11] <ogra> i think a suggests is fine ... i'd make it even Suggests: compiz | xcompmgr
[17:12] <MacSlow> lool, btw... xcompmgr works too with cairo-clock... at least last time (some months ago) I tested it
[17:14] <lool> MacSlow: Ack; thanks for discussion
[17:15] <MacSlow> lool, you're welcome
[17:16]  * Hobbsee wonders when the apt transition will complete
[17:17]  * lool suggests Hobbsee to stare at cairo-clock until the transition completes
[17:17] <Hobbsee> lool: heh.  i do like that clock
[17:17] <ogra> heh
[17:18] <Hobbsee> lool: but we are supposed to have an alpha release this week, so having stuff installable is probably a reasonable expectation?
[17:18] <Hobbsee> at least, that's what the schedule says
[17:19] <lool> Hobbsee: Who needs APT anyway?  ar ought to be enough for end users
[17:19] <Hobbsee> lool: heh.
[17:19] <Hobbsee> lool: sure, but this is not 1990.
[17:40] <laga> pitti: good job on the v4l-dvb package. i've been meaning to do that for mythbuntu for a long time
[17:46] <mkrufky> i noticed that
[17:46] <mkrufky> wont it break out of tree drivers?
[17:47] <laga> in what way?
[17:47] <mkrufky> err...  it _will_ break out of tree v4l/dvb drivers
[17:47] <mkrufky> replacing videodev by a new videodev, where modules in l-u-m depend on the kernel provided videodev
[17:47] <mkrufky> i have a fix for that, actually :-)
[17:47] <mkrufky> but its not fully backwards compatable
[17:48] <laga> yeah, i was just looking at l-u-m
[17:48] <laga> it'd be nice if l-u-m also used dkms.
[17:48] <mkrufky> yeah, anty media driver in l-u-m would get broken
[17:48] <mkrufky> if he changed his dkms build to -not- replace videodev, that would do it......  although it would only go back so many kernel versions
[17:50] <mkrufky> ...same applies to dvb-core, if there are any out of tree dvb devices in l-u-m
[17:50] <laga> mkrufky: do you know the state of the multiproto api?
[17:51] <mkrufky> it's not in kernel
[17:51] <mkrufky> and never will be
[17:51] <mkrufky> the author chose to fork and refuses any merge attempts
[17:51] <mkrufky> dont bother supporting it
[17:52] <mario_limonciell> laga, dkms shouldn't necessarily be used for everything in lum, but this model for updated drivers and binary drivers only is a good idea.
[17:52] <laga> it's a bit hard not to support it (in the future) as it's the only way to use DVB-S2.
[17:52] <laga> AFAIK
[17:53] <laga> mario_limonciell: well, l-u-m still should provide binaries, of course, but it'd also be nice if it didn't break if someone compiles their own kernel.
[17:53] <laga> granted, it's easy to rebuild.
[17:54] <mario_limonciell> the problem with putting dkms on too much stuff is that you end up having to have a build chain to build it when it needs to be used
[17:54] <mario_limonciell> and then you add extra delay to postinst when you build stuff
[17:54] <mario_limonciell> or during the next boot if you build it there
[17:56] <laga> thats why we have prebuilt modules for people who use the stock kernel. :)
[17:56] <laga> anyways, that discussion is probably fruitless. :)
[18:02] <mkrufky> laga: im only saying that userspace trying to support the multiproto api might be a wasted effort when the developer is unwilling to merge, and another developer is working on a better solution
[18:03] <laga> mkrufky: oh? got a keyword for me to throw at google?
[18:03] <mkrufky> mario_limonciell: i been trying to find you
[18:03] <mkrufky> change your nick much?
[18:03] <mkrufky> no, laga
[18:04] <mkrufky> all i can say is that we wont be held up by developers that dont play nice
[18:04] <mkrufky> at least, not forever
[18:04] <laga> mkrufky: so i guess you won't have an ETA either (for me). i'm moving soon and i'll have a dish there ;)
[18:05] <mkrufky> i dont involve myself with dvb-s at all -- ur asking the wrong guy
[18:05] <mkrufky> im just saying not to waste your time writing userspace software for a dead api
[18:05] <laga> mkrufky: alright, thanks!
[18:05] <mkrufky> then again, there's no telling when a real api will come
[18:06] <mkrufky> others are already working on temporary solutions
[18:57]  * lamont wonders which lib defines ap_get_token
[19:09] <mario_limonciell> mkrufky, while i'm at work I use this nick, when i'm home i use superm1
[19:37] <pitti> lamont: \o/
[19:37] <pitti> laga: \o/
[19:37] <pitti> lamont: sorry, ETAB
[19:38] <lamont> pitti: heh
[19:39] <ion_> pici: Heh
[19:40] <Pici> heh, oh wait.
[19:43] <\sh> pitti: which dvb-t stick do you have? which usb id i mean? ending with :5070 some sort of?
[19:43] <pitti> \sh: 7070 is the product ID
[19:43]  * pitti finds it and plugs in
[19:43] <\sh> pitti: or that...yes...that's why I have too :)
[19:44] <pitti> \sh: standard 29 EUR WinTV Nova-T stick
[19:44] <\sh> pitti: yepp :)
[19:44] <pitti> Bus 003 Device 004: ID 2040:7070 Hauppauge
[19:44] <\sh> pitti: that's the same :)
[19:44] <\sh> one of the newer ones which only works with newer linux-dvb drivers...hehe :) what a conincidence :)
[19:44] <mkrufky> (supported)
[19:45] <\sh> mkrufky: but not in hardy :)
[19:45] <mkrufky> no new cards are _ever_ supported in a distro
[19:45] <mkrufky> http://linuxtv.org/repo for howto, or use pitti's dkms package
[19:45] <\sh> mkrufky: you can't check beforehand..the stick is supported with older prod ids..
[19:45] <mkrufky> never, i said \sh
[19:46] <mkrufky> mario_limonciell: / superm1: whenever you're around, plz ping me
[19:46] <mario_limonciell> mkrufky, i've got about 15 minutes right now
[19:46] <mario_limonciell> pm?
[19:46] <mkrufky> k
[19:46] <\sh> pitti: i'll test it tomorrow in the office..there's the stick laying, wanted to use it for watching the EM during work time ;)
[19:49] <emgent> heya people
[20:35] <Cliph> Having a problem with a one of my meta dpkgs, is this a good place to get some help?
[20:35] <Cliph> or should I go to -motu?
[20:38] <Cliph> I have output and pastebins ready
[22:23] <sistpoty> Riddell: tk-brief uploaded to hardy-proposed again (with the xdg-open change, works like a charm, thanks!)
[22:23] <sistpoty> Riddell: oh, and of course I've also uploaded it to intrepid beforehand
[22:35] <Riddell> sistpoty: accepted
[22:35] <sistpoty> Riddell: thanks a lot!
[23:02] <rubikcube> hmm, I had thought that I had fulfilled everything in the original post already... what do you think? https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/238634