[01:17]  * lamont grumbles at the loss of his dearly beloved non-ports symlink on cdimage.ubuntu.com
[01:18] <lamont> slangasek: did you do that?
[01:18] <slangasek> your what?
[01:19] <lamont> cdimage.ubuntu.com had a 'non-ports' symlink at the same level as 'ports' (pointing to '.') so that I could rsync *ports/
[01:20] <lamont> and alpha 1 is thursday?
[01:21] <slangasek> I still see the non-ports symlink on cdimage...?
[01:21] <lamont> feh
[01:21]  * lamont loses
[01:21] <lamont> never mind
[01:21] <slangasek> ok
[01:21] <slangasek> phew, so it's unrelated to my fumbling with jeos ;)
[01:22] <lamont> it's there, it's just not in alpha-order. :-(
[01:22] <lifeless> welcome to ext3
[01:24] <jdong> POSIX: Please Offer Scapegoats In eXcess
[01:24] <jdong> :)
[01:55] <nxvl_work> i need a gove-back for corewars
[02:04] <nxvl_work> also for debian-history
[04:29] <lamont> lifeless: iz find vs sorted output, yeah.  I keep forgetting that
[06:31]  * minghua doesn't understand why the mail to -devel-discuss about ghostscript doesn't mention the LP bug number.
[07:02] <slangasek> so the desktop tasks are currently uninstallable because gnome-session conflicts with the old bug-buddy, and the new bug-buddy build-depends on a lib not in main.  Is anyone available to take a quick (but appropriately thorough) look at https://wiki.ubuntu.com/MainInclusionReportElfUtils ?
[07:05] <slangasek> hmm, or is the review part only ubuntu-archive?
[07:05] <slangasek> in that case I'll just lie in wait until someone wakes up :)
[07:05] <StevenK> slangasek: You want to jump on pitti or doko.
[07:06] <slangasek> since you're mentioning doko, does that mean it's not an ubuntu-archive activity?
[07:06] <StevenK> slangasek: The approval process is up to pitti or doko. Once it's approved, actually promoting it from universe to main *is* -archive
[07:07] <slangasek> StevenK: that's not documented on https://wiki.ubuntu.com/MainInclusionProcess then?
[07:07] <slangasek> it just says "archive administrators"
[07:08] <Amaranth> I've never seen anyone else do a MIR
[07:08] <Amaranth> Usually it's pitti since the main concern is security
[07:11] <StevenK> slangasek: "If the report exists and is acceptable, the report will be marked 'approved'." -- it doesn't mention who marks it as such. :-)
[07:12] <slangasek> StevenK: so the archive administrators look for the report, but doko decides if it's acceptable? :)
[07:12] <StevenK> slangasek: I except so, actually. Well, doko or pitti
[07:20] <Mithrandir> geser: if you could just give us a space-separated list, that works.
[07:30] <slangasek> here's an easier one, who can rebuild ubuntu-meta for the recent seed changes? :)
[07:30] <StevenK> I can, if you want me to
[07:31] <slangasek> yes please
[07:33] <LaserJock> StevenK: pitti and iwj were doing MIR approvals last I saw
[07:33] <Mithrandir> morning slangasek
[07:33] <StevenK> LaserJock: iwj isn't any more.
[07:33] <Mithrandir> LaserJock: iwj no longer works for Canonical though, and he hasn't shown much interest in continuing being a member of the community either.  So I doubt he's going to do any more MIR reviews.
[07:34] <Mithrandir> StevenK: that's slightly harsh to say; he left the company, but you're saying it as if he's dead.
[07:34] <StevenK> I didn't mean it like that.
[07:34] <LaserJock> Mithrandir: iwj left Canonical?
[07:34] <LaserJock> I didn't know that
[07:34] <Mithrandir> LaserJock: yes.
[07:35] <StevenK> I just meant to say he isn't doing MIR approvals any more
[07:35] <Mithrandir> LaserJock: http://lists.debian.org/debian-ctte/2007/11/msg00003.html
[07:35] <slangasek> Mithrandir: morning
[07:36] <slangasek> yeah, why on -ctte of all places... :)
[07:37] <Mithrandir> because he sent an email there when he joined Canonical so people would see if he ended up in a position of conflict of interest.
[07:37] <LaserJock> Mithrandir: huh
[07:38] <LaserJock> well, good luck to him
[07:38] <slangasek> Mithrandir: are you sure? I thought he sent the first mail to -project
[07:38] <slangasek> ah, http://lists.debian.org/debian-ctte/2005/06/msg00010.html went to both lists
[07:38] <Mithrandir> slangasek: maybe he sent to -project too, I'm not sure.
[07:39] <Mithrandir> I'm a few years behind on reading -project mails. :-/
[07:39] <slangasek> anyway, I haven't bothered announcing my employment on -ctte, because obviously everyone on the -ctte is part of the cabal and therefore already knows
[07:40] <StevenK> slangasek: Updating ubuntu-meta, I'll finish after I pick up my wife
[07:40] <slangasek> StevenK: cheers
[07:50] <pitti> Good morning
[07:51] <LaserJock> hi pitti
[07:53] <pitti> tjaalton: hm, xserver-xorg-input-elographics wants to go to universe; is that intended?
[07:53] <thegodfather> poor elographics touch screens
[07:54] <thegodfather> they are sweet toys
[07:55] <tjaalton> pitti: what do you mean?
[07:57] <tjaalton> pitti: "wants to go to universe", that part I don't understand :)
[07:57] <pitti> tjaalton: it was in main so far
[07:57] <tjaalton> yes
[07:57] <pitti> but now nothing is holding it there any more
[07:57] <tjaalton> oh
[07:57] <pitti> no reverse dependencies, no seedings
[07:58] <pitti> tjaalton: I guess it was a dependency of -input-all or something, and now isn't any more
[07:58] <pitti> it could be because the package is obsolete, or it could be a bug
[07:58] <tjaalton> pitti: probably so
[07:58] <slangasek> yes, it's probably one of those :)
[07:59] <tjaalton> I'll do a xorg merge today, so I'll readd it so that it stays in main for now
[07:59] <tjaalton> I'm not sure how that driver works with input-hotplug, besides there is evtouch
[07:59] <tjaalton> although I don't have the hardware to test either :)
[08:02] <slangasek> tjaalton: hrm, what happened to your ircnick anyway? :)
[08:03] <dholbach> good morning
[08:06] <tjaalton> slangasek: it got dropped in the turmoil ;)
[08:06] <pitti> tjaalton: can you have a quick look on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt, 'Source and binary demotions to universe'?
[08:06] <pitti> tjaalton: there are some X client programs
[08:07] <tjaalton> pitti: sure
[08:10] <tjaalton> pitti: oh, actually we discussed about these yesterday (ie. apps that are not in the bundles)
[08:11] <tjaalton> pitti: and it seems that I missed some from the removal request
[08:11] <pitti> I suspected so, but maybe some fell through the dependency cracks and should be kept
[08:12] <tjaalton> pitti: editres, listres, viewres are in x11-utils
[08:13] <tjaalton> beforelight is going to be added to x11-apps I think, but bitmap, ico, xf86dga and xgc are just noise and could be dropped from the archive
[08:13] <tjaalton> ico & xgc are abandoned upstream
[08:14] <mjg59> Is anything still using dga?
[08:14] <mjg59> If so, can we make them stop?
[08:15] <slangasek> what replaced DGA?
[08:15] <mjg59> Graphics cards that worked
[08:15] <slangasek> hah
[08:16] <mjg59> The speed benefit you get now is generally less than you'd get by using the acceleration
[08:16] <StevenK> mplayer will still talk DGA
[08:17] <mjg59> mplayer would talk swahili, klingon and esperanto if the maintainers found a single machine that managed 0.001 extra FPS as a result
[08:18] <StevenK> Bwahaha
[08:19] <doko_> slangasek: it's changing; I'm doing mir's now, but I'm not ubuntu-archive
[08:19] <slangasek> doko_: ok
[08:19] <slangasek> doko_: pitti is handily killing this one for me, so I'll file that away for future reference :)
[08:20] <Chipzz> Keybuk: wrt your svg problem from yesterday, this may be usefull: http://webkit.org/blog/122/webkit-3-10-new-things/ ; it has 6 links to svg usage in browsers, which also work in firefox
[08:20] <Keybuk> Chipzz: I managed to open it in Inkscape and go through the "layers" of the image
[08:21] <Chipzz> Keybuk: ok nevermind then :)
[08:22] <Chipzz> mjg59: doesn't SDL use DGA?
[08:31] <mjg59> Chipzz: It can do, but I don't think it's the default
[08:32] <pitti> tjaalton: ok, so I remove editres, listres, viewres, ico, xf86dga and xgc,and keep beforelight in main for now?
[08:33] <pitti> dholbach: hm, all the ubuntu-calendar* want to go to universe; is that deliberate?
[08:34] <dholbach> pitti: we didn't depends on them for ages, I don't know - were they in supported?
[08:34] <pitti> dholbach: apparently something depended on them until recently
[08:35] <pitti> (I guess some artwork package)
[08:35] <dholbach> I don't think so
[08:35] <pitti> hm, nothing
[08:36] <pitti> aah
[08:36] <dholbach> what was it?
[08:36] <pitti> they were unseeded
[08:36] <pitti>   drop support for ubuntu-calendar*, since they haven't been updated for years (ok mdz@)
[08:36] <tjaalton> pitti: you can remove beforelight as well, it'll get in debian soonish and I'm sure no-one needs it in the meantime ;)
[08:36] <pitti> tjaalton: ok
[08:37] <tjaalton> are we going to have a new kernel for alpha1?
[08:43] <pitti> tjaalton: *flush*, thanks for having a look
[08:44] <tjaalton> pitti: thanks for pointing out!
[08:46] <pitti> seb128: so apparently gconf and gconf2 source duplicate each other; which is the good one?
[08:47] <pitti> seb128: from what I can see, gconf was the old gnome 1.x version
[08:47] <pitti> and now Debian renamed gconf2 to gconf
[08:47] <slangasek> gconf source is at 2.20.1-1 now, and builds the gconf2 package
[08:47] <seb128> pitti: gconf, I did sync it yesterday and was waiting for it to build everywhere to remove the other one, you are too quick ;-)
[08:47] <seb128> debian renamed it
[08:47] <pitti> seb128: well, it can't build
[08:47] <seb128> why?
[08:47] <pitti> seb128: it's exactly the same version as gconf2
[08:48] <pitti> i. e. even if the binaries would build, they would fail to upload
[08:48] <seb128> urg, didn't, notice that
[08:48] <pitti> seb128: so I just remove the gconf2 source, and everything should be good
[08:48] <seb128> yes
[08:48] <seb128> you can also remove gnome-vfs2 while you are at it
[08:48] <seb128> it has been renamed gnome-vfs
[08:48] <pitti> ah, great
[08:49] <seb128> yeah for GNOME1 stack being cleaned ;-)
[08:49] <mjg59> Are we finally rid of Gnome 1.x apps?
[08:49] <pitti> gnome-vfs2 | 1:2.20.0-0ubuntu3 |         hardy | source
[08:49] <mjg59> A glorious day indeed
[08:49] <pitti>  gnome-vfs | 1:2.20.1-1ubuntu1 |         hardy | source
[08:49] <pitti> seb128: so I take it our changes were merged to gnome-vfs?
[08:49] <mjg59> And good to do this in an LTS release
[08:50] <slangasek> debian-qa have been chipping away at the gnome 1.x libs for a while, but they're not all gone yet
[08:50] <seb128> pitti: yes
[08:51] <mjg59> slangasek: Without gnome-vfs and gconf, nothing especially interesting will be instalable
[08:51] <slangasek> I didn't say any of them were interesting
[08:51] <mjg59> (Pretend I can spell. I've drunk most of a bottle of mead)
[08:51] <pitti> libgtk1.2 and glib1.2 are still there in particular
[08:51] <mjg59> Yeah, gtk 1.x apps are going to be harder to shift than gnome 1.x ones
[08:51] <mjg59> xmms, for instance
[08:52] <mjg59> Which has mostly been a victim of "We're not just going to port this to GTK 2, we're going to entirely refactor it in the process"
[08:52] <mjg59> On at least three separate occasions
[08:52] <pitti> seb128, Riddell: did you recently touch ttf-gentium? it seems someone removed the source package, but not the binary
[08:52] <seb128> pitti: I didn't
[08:53]  * pitti rescues the source from gutsy
[08:53]  * pitti hugs copy-package
[08:56] <MacSlow> Greetings everybody!
[08:57] <pitti> Riddell: any idea what to do about the kuickshow mess? kdegraphics-dev depends on it, but it's in universe and needs imlib (universe, gtk 1 crack)
[08:57] <pitti> hey MacSlow
[08:57] <MacSlow> hoy pitti, Riddell
[08:58]  * Fujitsu would be glad to have GTK1 off MOTU's plate :P
[08:58] <slangasek> Fujitsu: help debian-qa kill it? :)
[08:58] <pitti> Riddell: and latest kdebase depends on pmount again; I guess that's a wedged merge, and Debian still has the dependency?
[08:58] <TheMuso> Fujitsu: And all those glib1.2 transitions that still need doing? :p
[08:59] <Fujitsu> slangasek: Or get it promoted. One of them.
[08:59]  * slangasek snorts
[09:00] <StevenK> slangasek: Did you commit your seed changes?
[09:00] <StevenK> Hah, actually, never mind, you can't.
[09:00] <slangasek> I had no seed changes to make
[09:02] <pitti> mvo: applying patch 03_branding to ./ ... failed.  <- aptitude FTBFS
[09:03] <mjg59> For The Brilliant Futuristic Space?
[09:03] <mjg59> (Yes, I know)
[09:03] <slangasek> it's probably going to FTBFS anyway, the maintainer did a brilliant job of updating it in unstable
[09:03] <mjg59> There's very little porting to move glib 1.x to glib 2.x in most cases
[09:04] <mjg59> And if you pass -DENABLE_DEPRECATED_WIDGETS (or something), gtk1.x to 2.x is almost as easy
[09:04] <slangasek> oh, or perhaps not, the new lib aptitude b-d's on seems to have better luck building on hardy than sid :)
[09:04] <Amaranth> People still use xmms?
[09:04] <Amaranth> I thought Debian dropped it
[09:04] <mvo> pitti: just got the ftbfs mail, strange
[09:04] <slangasek> I use that xmms clone, audacious
[09:05]  * Fujitsu last used xmms around 2002, I think.
[09:05] <pitti> seb128: you are too good and fast; latest evolution-sharp from unstable still seems too old for our e-d-s version :)
[09:05] <mjg59> Amaranth: xmms is still pretty stable compared to the others
[09:05] <seb128> pitti: yeah, I know about this one also ;-)
[09:06] <seb128> pitti: are you doing a round of GNOME cleanup today?
[09:06] <mjg59> bmp looked like a promising replacement, until they decided to go all itunes
[09:06] <pitti> seb128: specifically I'm walking through http://people.ubuntu.com/~ubuntu-archive/testing/hardy_outdate.txt and see what got stuck
[09:06] <seb128> pitti: you can likely ignore most of GNOME things, I'm taking care of those
[09:07] <pitti> seb128: great
[09:07] <pitti> that helps a lot
[09:07] <seb128> pitti: libgpod requireds the sg3-utils promotion, there is a MIR in the queue for you if you want to unblock this one, that will give support for the nano generation
[09:07] <Amaranth> mjg59: isn't that what xmms2 is too?
[09:07] <Amaranth> wait, it's more like mpd meets itunes
[09:07] <seb128> new nanos rather
[09:09] <mjg59> Amaranth: Yeah
[09:13] <Riddell> pitti: kdebase/pmount and kdegraphics/kuickshow are both merge problems, I'll fix them
[09:13] <pitti> Riddell: thank you
[09:13] <pitti> Riddell: do you know if anyone is on the kdepim FTBFS? (dh_install: kdepim-doc missing files (/usr/share/doc/kde/HTML/en/kdepim-apidocs/*), aborting)
[09:16] <Riddell> pitti: mm, didn't I fix that?
[09:17] <Riddell> pitti: aye, it's all done https://edge.launchpad.net/ubuntu/hardy/+source/kdepim/4:3.5.7enterprise20070926-1ubuntu5
[09:18] <Amaranth> 3.5.7enterprise?
[09:18] <pitti> Riddell: well, but that version is where I got the FTBFS for (on i386)
[09:18] <Amaranth> I don't see kirk anywhere :P
[09:18] <pitti> http://launchpadlibrarian.net/10546384/buildlog_ubuntu-hardy-i386.kdepim_4%3A3.5.7enterprise20070926-1ubuntu5_FAILEDTOBUILD.txt.gz
[09:18] <Riddell> oh, missed that one
[09:19] <Riddell> grump, all this KDE 4 bits and I do silly things with KDE 3
[09:27] <pitti> Riddell: python-qt4 depends on python-elementtree; since that's in 2.5 now, it should depend on python2.5 | python-elementtree; do you want me to do that change, so that p-qt4 becomes installable again?
[09:30] <pitti> Riddell: that should clean a lot on http://people.ubuntu.com/~ubuntu-archive/testing/hardy_probs.html
[09:31] <slangasek> calc: there are an awful lot of OOo bugs listed as targetting the alpha1 milestone, are those there because you're working on them and planning for them to all land in time or because some user has it out for you? :)
[09:32] <Amaranth> Or someone moved them from gutsy
[09:33] <pitti> Riddell: heck, I'm just doing it
[09:36] <dholbach> pitti: iirc he has taken a day off today
[09:37] <pitti> dholbach: who?
[09:37] <dholbach> pitti: Riddell?
[09:37] <pitti> dholbach: ah; right, I know, but I spoke to him 20 minutes ago :)
[09:37] <dholbach> ah ok
[09:37] <dholbach> :)
[09:49] <pochu> pitti: is it ok to depend on a universe package as long as it depends first on a main package? python2.5 | python-elementtree (python-qt4 is in main)
[09:50] <slangasek> yes, that's valid
[09:51] <pochu> Thanks.
[09:53] <pitti> pochu: given that I just did that change in python-qt4 my answer should be clear :)
[09:54] <pitti> pochu: just FYI, for build dependencies it is even ok to have a b-dep "universe-pkg | main-pkg"
[09:54] <pitti> pochu: it's not very nice, but the buildds can handle it, so if it helps to drop a Debian delta, it can be done
[09:54]  * slangasek takes notes
[09:54] <slangasek> :)
[09:55]  * pochu too :)
[09:55] <StevenK> pitti: I need to keep the .preinst symlink magic for gimp still, right?
[09:55] <seb128> StevenK: until hardy yes
[09:55] <pitti> StevenK: if you mean the code that changes symlinks back to directories, yes
[09:55] <StevenK> Well, until the first hardy+1 merge
[09:55] <pitti> since that's in gutsy final
[09:56] <StevenK> Yup, okay
[09:56]  * pitti looks forward to the post-hardy merges; I saw too many debian deltas which are just upgrade fixes from dapper
[09:56] <StevenK> seb128: I should be uploading gimp 2.4.2-1ubuntu1 soonish
[09:58] <seb128> StevenK: good
[09:59] <seb128> StevenK: would you consider a stable upload also for it or there is too many changes?
[09:59] <seb128> I've enough of users complaining on launchpad that gutsy has a candidate version when a new stable is available
[09:59] <pitti> superm1: thanks for the sg3-utils MIR; just for the future, can you please use the standard template instead of copy&paste from an old MIR? Thanks
[10:00] <StevenK> seb128: Hah
[10:00] <StevenK> seb128: So 2.4.2-1ubuntu1~7.10 ?
[10:01] <StevenK> I don't see anything too brutal in the changelog
[10:01] <seb128> StevenK: rather 2.4.2-0ubuntu1, I don't think we want to merge with Debian in a SRU
[10:02] <seb128> StevenK: though asking for a backport of the hardy version might be easier
[10:02] <StevenK> Oh no, we really don't. Given the change I just re-enabled
[10:04]  * StevenK wishes the Debian->Ubuntu debdiff wasn't stuffed full of po stuff
[10:06] <StevenK> seb128: Test-building gimp now
[10:06] <pitti> superm1, seb128: sg3-utils looks good, promoted
[10:06] <pitti> slightly too late for publisher, but *shrug*
[10:06] <seb128> pitti: danke
[10:06] <seb128> StevenK: cool
[10:08] <StevenK> seb128: I'll think about what to do for gimp 2.4.2 in Gutsy. Not sure at this point.
[10:08] <seb128> StevenK: ok, thanks
[10:09] <pitti> StevenK: ignore the calls for putting new upstream versions into gutsy? :)
[10:09] <seb128> StevenK: bug #157642
[10:09] <ubotu> Launchpad bug 157642 in gimp "gimp 2.4 *final*  in gutsy" [Undecided,New] https://launchpad.net/bugs/157642
[10:09] <seb128> pitti: I don't like getting new version, but the differences between rc and 2.4 are small and looks like it would make quite some user stop complaining
[10:10] <pitti> seb128: (just joking)
[10:10] <pitti> seb128: yes, if it's only a few justifieable high-impact bug fixes we can consider it
[10:10] <seb128> the number of discussions on forum, list and bug tracker indicates they take that as an issue, not sure why though, that's not very rational
[10:10] <seb128> most of them have no issue, they just feel it's unprofessional
[10:10] <pitti> but if there are some actual problems with the RCs, there shuold be bug reports
[10:11] <pitti> if it's just for the name, then *shrug*
[10:11] <seb128> right, that's my point
[10:11] <seb128> well, they argue that the changes are only some bug fixes
[10:11] <pitti> the old story
[10:11] <seb128> and that have release candidate written with a typo on the splash looks unprofessional
[10:11] <pitti> typo?
[10:12] <Riddell> pitti: thanks (for python-qt4)
[10:12] <pitti> Riddell: you're welcome
[10:12] <seb128> pitti: bug #164609
[10:12] <ubotu> Launchpad bug 164609 in gimp "Spelling error in gimp (nothing that major) (dup-of: 145524)" [Undecided,New] https://launchpad.net/bugs/164609
[10:12] <ubotu> Launchpad bug 145524 in gimp "Splash screen typo error" [Undecided,Fix committed] https://launchpad.net/bugs/145524
[10:13] <pitti> "conadidate", sweet
[10:13] <seb128> indeed ;-)
[10:13] <pitti> it has 306 hits in Google, so it is clearly a valid word *duck*
[10:14] <pitti> (yes, most of them are about this buglet)
[10:15] <pitti> cjwatson: perl looks fine here, synced
[10:22] <seb128> pitti: <pitti> seb128: it's exactly the same version as gconf2
[10:23] <seb128> pitti: that's not true
[10:23] <seb128> pitti: 2.20.0-1 against 2.20.1-1
[10:24] <pitti> seb128: I blame not having had tea yet
[10:24] <seb128> ;-)
[10:25]  * seb128 hugs pitti
[10:25] <pitti> (darn, I thought I looked twice and thrice)
[10:35] <cjwatson> pitti: thanks
[10:35] <cjwatson> mjg59: gtk 2.x porting> except when you have custom controls or care about exact font behaviour, e.g. putty
[10:36] <TheMuso> cjwatson: Do you object if I do your brltty merge?
[10:37] <cjwatson> TheMuso: not in the least, please do
[10:41] <seb128> TheMuso: hi, did you read my comment about gnome-orca yesterday? You have an update listed on the wikiTODO, could you have a look at merging on Debian which has a new version now?
[10:42] <TheMuso> seb128: I didn't see your comment, but I'll have a look.
[10:42] <seb128> TheMuso: thanks
[10:43] <seb128> pitti: your bug-buddy upload built correctly ;-)
[10:43] <seb128> let's rebuild gnome-python-desktop now
[10:43] <pitti> shall I give it back?
[10:43] <pitti> or does it need an upload
[10:43] <seb128> pitti: what? gnome-python-desktop? it needs a rebuild due to libtotem-plparser soname change, I'll do it now
[10:44] <seb128> s/rebuild/upload
[10:44] <pitti> ah, that; appreciated, I saw it this morning on the NBS list
[10:44] <seb128> pitti: there is several empty files in the NBS list, any reason those are not cleaned automatically nowadays?
[10:44] <pitti> seb128: we shuold never do that automatically
[10:45] <seb128> pitti: or does it just need somebody running the command?
[10:45] <seb128> pitti: right, but I mean that's easy cleaning usually, no?
[10:45] <pitti> seb128: it sometimes gets confused if a package is just in needsbuild, or so
[10:45] <pitti> seb128: yes, the 0 ones are easy, they just need a quick sanity check
[10:45] <seb128> pitti: I was just wondering if I should have a look
[10:45] <pitti> seb128: if you want to, please go ahead
[10:45] <seb128> pitti: ok, will do that
[11:10] <StevenK> Sigh
[11:10] <StevenK> "It's unprofessional" We have deadlines to meet, and Gimp released 2.4.0 *the day after we released*. That's just mean.
[11:12] <StevenK> seb128: Did you read these bug reports? Apparently, we need to update gimp and *keep updating it*
[11:12] <StevenK> Never mind working on Hardy.
[11:13] <StevenK> seb128: In better news, gimp built, just lightly testing it.
[11:16] <seb128> StevenK: I don't care about the "keep updating it", I think they have a point about the candidate typoed version looking unprofessional, I would have no issue to point them to the SRU policy for minor version updates
[11:16] <StevenK> seb128: Sure, but let's shut them up for a little while with 2.4.2?
[11:17] <seb128> that would be nice indeed
[11:17] <mpt> I'm trying to think of a parallel to this in other OSes
[11:17] <mpt> Where a major version of the OS is released with a "release candidate" version of one of its apps
[11:18] <StevenK> seb128: Gimp looks good, uploading. It'll take a while.
[11:18] <StevenK> mpt: What would we do? 2.4.0 was released the day after.
[11:18] <broonie> I'd expect most distros will have done that at least once, though a lot of the time it won't be as visible as here.
[11:19] <mpt> I'm not talking about "distros" so much
[11:19] <StevenK> mpt: And we already had 2.3 in Gutsy for testing
[11:19] <mpt> Linux distributions offer reams of pre-1.0 software, but that's much better-hidden
[11:20] <cjwatson> mpt: it doesn't arise in other OSes because the same organisation is usually doing (almost) all the applications and so (almost) all the applications can be released in step
[11:20] <mpt> yes
[11:20] <cjwatson> you can't just ignore the organisational aspect ...
[11:21] <broonie> Might be interesting to trawl the free software shipped with Solaris and see what's in there...
[11:21] <mpt> Right, and meanwhile there's bazillions of people who don't know that
[11:21] <mpt> So the mental models need to meet somewhere
[11:22] <mpt> StevenK, I honestly don't know :-)
[11:23] <broonie> Sometimes this stuff gets avoided by people simply not uploading prerelease versions when they might end up in a release but that ends up with people complaining about old versions.
[11:25] <StevenK> broonie: And a war of attrition about versions is no fun
[11:26] <Mithrandir> mpt: what other OSes actually ship any applications by default?
[11:26] <StevenK> And Wordpad and Notepad don't count. :-P
[11:27] <cjwatson> IE and Safari are applications
[11:27] <cjwatson> (even if IE is more tightly integrated than it ought to be)
[11:27] <Mithrandir> cjwatson: arguably.
[11:27] <Mithrandir> IE at least is very, very tied into the rest of the OS.
[11:27] <StevenK> And Apple pushed back Leopard how much?
[11:27] <seb128> window media player is also an application
[11:27] <Mithrandir> I don't know how hard it is to replace Safari with Firefox on a MacOS installation.
[11:28] <Mithrandir> seb128: I've so far failed to remove it on my systems, at least.
[11:28] <broonie> It's pretty straightforward.
[11:28] <pitti> . o O { we need more buildds }
[11:28] <StevenK> seb128: I'd count that as more an annoyance. :-P
[11:28] <Mithrandir> broonie: how would you go about removing it?  It's not just a .app, is it?
[11:29] <broonie> Mithrandir: I'd trash the .app :/
[11:29] <mpt> Mithrandir, Windows, Mac OS X ... was that a trick question?
[11:30] <cjwatson> while I disagree with the precise form of Mithrandir's question, it's clear that those operating systems ship many fewer applications
[11:30] <cjwatson> which is an important point for us to convey
[11:30] <Mithrandir> and none developed by third parties on an independent schedule, I believe.
[11:30] <StevenK> But they control them themselves.
[11:31] <StevenK> We don't control Gimp or Gnome upstream
[11:31] <mpt> Mithrandir, drag it to the Trash., like broonie said
[11:31] <Mithrandir> mpt: what then happens if you click an HTTP link in your chat client?
[11:31] <broonie> Solaris is probably getting closer to what Ubuntu is doing - they do ship things like GNOME, but they keep them at arms length from the core OS.
[11:31] <mpt> Mithrandir, it opens whatever your default browser is
[11:32] <mpt> The only catch is that there isn't an equivalent of Ubuntu's "Preferred Applications" window (any more)
[11:32] <mpt> So each browser (e.g. Firefox, Camino, Opera) has a "Default browser:" menu in its own Preferences window
[11:33] <Mithrandir> then it might look like mac os ships with at least one application.
[11:34] <broonie> It ships with iTunes, iPhoto and stuff too.
[11:35] <Mithrandir> and those are easy to remove and replace with other apps too?
[11:35] <mpt> Mail, iChat, QuickTime Player, TextEdit, iSync, a bunch of utilities
[11:35]  * StevenK waits for dput to stop completly and utterly not sharing his upstream bandwidth
[11:35] <mpt> "Easy" depends on how much migration you want
[11:36] <mpt> e.g. Mail 2.0 and later uses a proprietary maildir variant
[11:36] <StevenK> Sigh. Of course it does.
[11:36] <mpt> but "remove", yes, drag them to the Trash
[11:36] <Mithrandir> mpt: for mail, stuff like mailto: links then open correctly in your preferred email client.
[11:37] <mpt> I assume so, I've never tried
[11:37] <mpt> Mail has a "Default Email Reader:" menu in its Preferences, so I guess so
[11:38] <mpt> foo@example.com
[11:38] <mpt> yep, works
[11:41] <mpt> The other catch is that there's no equivalent to Synaptic's "Mark for Complete Removal"
[11:43] <StevenK> Phew. Gimp uploaded
[12:24] <soren> mvo: If the Pre-Depends field in the installed package doesn't match that in the Packages file, apt will think they're not the same package, right?
[12:24] <freeflying> Znarl: ping
[12:28] <pitti> mvo: we need to flip on apport notifications for alpha 1; do you plan an update-notifier upload soon? if not, I'll do it
[12:38] <mvo> pitti: feel free, I have currently no plans, but please build from bzr
[12:38] <pitti> right
[12:38] <mvo> soren: yes, then it will do its reinstall dance
[12:39] <soren> mvo: Thought so. Thanks.
[12:54] <pitti> argh, sparc just exploded
[12:54] <pitti> http://people.ubuntu.com/~ubuntu-archive/testing/hardy_probs.html
[12:55] <pitti> something in the last few hours caused sparc to become totally uninstallable; any idea?
[12:55]  * thegodfather sighs
[12:55] <thegodfather> pitti: i'll check
[12:56] <Hobbsee> pitti: the yada plague.  or the effects of the MOTU drinking game.  either way.
[12:56] <thegodfather> pitti: but i blame gtk or something along those lines :)
[12:56] <pitti> pretty weird, it causes packages on the level of automake to become uninstallable
[12:56] <pitti> thegodfather: that would hardly cause debhelper uninstallability
[12:57] <thegodfather> pitti: are you sure ? :)
[12:57] <pitti> thegodfather: not unless it introduced something like Conflicts: libc6, kernel, libgcc1 :)
[12:58] <Mithrandir> pitti: perl is uninstallable on sparc.
[12:58] <pitti> aah
[12:58] <pitti> just buildd desync then, I guess
[12:58] <Mithrandir> and perl was uploaded an hour ago
[12:58] <pitti> right, needsbuild on spar
[12:59] <pitti> c
[12:59]  * pitti bumps
[12:59] <thegodfather> and probably can't build
[12:59] <thegodfather> given that nothing is installable
[12:59] <pitti> thegodfather: why not?
[12:59] <pitti> the chroots shouldn't just upgrade then?
[12:59] <pitti> it's not the first perl upload we did, and it never killed the buildds, so I hope this one will get through, too
[13:00] <thegodfather> pitti: chroots autoupdate, right. but if nothing can be installed, you won't be able to install perl B-D either
[13:00] <thegodfather> pitti: can't check here yet.. the problem is not propagated to my local mirror yet
[13:00] <Mithrandir> thegodfather: all of the perl build-deps are installable.
[13:00] <thegodfather> (not in details at least)
[13:01] <thegodfather> ok
[13:01] <pitti> thegodfather: don't worry; I think it'll sort out itself
[13:01] <thegodfather> yeps i am not worried at all
[13:01] <thegodfather> machine is already powered off
[13:01] <Mithrandir> pitti: maybe stop the sparc buildds until the perl one has built?
[13:01] <Mithrandir> that is, bump perl (as you did), then turn them off until the binaries are published
[13:02] <Mithrandir> so we don't get 5000000 failures
[13:02] <pitti> perl is the very next thing on the list
[13:02] <pitti> Mithrandir: yes, I'll stop all but one sparc buildd
[13:03] <pitti> bah, sejong is building gcc-snapshot; that won't get in the way for a long time :)
[13:03] <Mithrandir> heh
[13:03] <pitti> so  I'll just watch it
[13:21] <pitti> lool: ah, just saw your avahi commits to the unstable branch; cool, that means we can sync soon? or do we still have ubuntu specific diffs?
[13:21] <lool> pitti: I'm still merging
[13:22] <pitti> (well, lpia is already ubuntu specific, so thanks for adopting that)
[13:22] <lool> Well at some point Debian might use it and it makes for a smaller delta; I hope the other members don't mide the esoteric keyword in the middle of the other ones :)
[13:22] <lool> pitti: Do you know whether enable_avahi can be dropped?
[13:23] <lool> pitti: I mean, it seems avahi is enabled by default on Ubuntu on my installs
[13:23] <pitti> lool: we enable it by default now, but I'm not sure whether we still provide an UI for those scripts
[13:23]  * pitti checks
[13:23] <lool> Thanks
[13:23] <pitti> in edgy we added a checkbox to network-admin
[13:23] <pitti> no, that's gone
[13:24] <pitti> Riddell, Hobbsee: do you still need enable_avahi and avahi_status in Kubuntu? do you wrap those in any UI?
[13:24] <Hobbsee> tjaalton: are you running debuild with -v <last ubuntu version> at all for your merges?
[13:24] <Hobbsee> pitti: no idea, sorry
[13:24] <lool> pitti: Cool; I guess I can drop the status script as well then
[13:25] <pitti> lool: I'd say, just kill them; if there is some UI left in Kubuntu we just drop that as well
[13:25] <pitti> lool: right
[13:26] <lool> pitti: Last but not least, there's a patch only allowing access to a certain group of users for avahi dbus operations (IIUC); that's an Ubuntu security team patch I guess?
[13:26] <lool> (The changelog were it was introduced isn't visible any more)
[13:26] <pitti> lool: hm, do you have a pointer to the patch?
[13:26] <pitti> lool: ah, what's the name? I'll look in codebrowse
[13:27] <lool> pitti: http://people.ubuntu.com/~lool/03_foreground-console.patch
[13:27] <pitti> http://codebrowse.launchpad.net/~ubuntu-core-dev/avahi/ubuntu/annotate/jriddell%40ubuntu.com-20071004142607-butdopb0zjgjialq?file_id=03_foregroundconsole-20061227134554-7psb6nnukxdrf5nt-68
[13:27] <lool> Changes a group check by a console check IIUC
[13:28] <pitti> lool: what does AVAHI_PRIV_ACCESS_GROUP expand to?
[13:28] <pitti> lool: ATM at_console shouldn't even work
[13:29] <lool> pitti: AC_ARG_WITH(avahi_priv_access_group,AS_HELP_STRING([--with-avahi-priv-access-group=<group>],[Priviliged access group for Avahi clients (netdev)]))
[13:29] <pitti> we need to ConsoleKit'ify dbus for that
[13:29] <lool> Defaults to netdev
[13:29] <pitti> bwah
[13:30] <pitti> lool: no, netdev definitively sounds wrong to me
[13:31] <pitti> lool: except if normal users don't actually need to call the SetHostName function
[13:31] <lool> pitti: In a default install, I'm in netdev
[13:31] <pitti> lool: if this is something that shouldn't normally be called, dropping that change looks fine to me
[13:31] <pitti> lool: right, but we want to get rid of all those silly groups
[13:32] <pitti> i. e. we should not base access policy on them any more
[13:32] <lool> pitti: The comment in the Ubuntu changelog is "Restrict access to privileged Avahi dbus functions to console users"; I think it's about being able to set the hostname, but I guess that's only the avahi visible hostname
[13:32] <pitti> lool: and I don't see why on earth users should set the host name (avahid should do that on its own)
[13:33] <pitti> lool: right, but that should usually be equal to the real hostname?
[13:33] <pitti> and we don't have an UI for changing it either
[13:33] <lool> Perhaps it's the description of their host ("pitti's computer"); chekcing the source...
[13:34] <pitti> + eth0 IPv4 PDF creator @ localhost.localdomain           Internet Printer     local
[13:34] <pitti> + vmnet8 IPv4 donald [00:50:56:c0:00:08]                    Arbeitsplatzrechner  local
[13:34] <pitti> lool: so the description would be 'Arbeitsplatzrechner', but that's a service type, not a hostname
[13:34] <pitti> 'donald' is the hostname, and there's no UI to change that
[13:35] <pitti> lool: tell you what; drop the change, I send a question to Lennart
[13:35] <pitti> lool: if we need to care about that method, we can think about access policy once we have a robust idea of what we would need it for
[13:36] <lool> pitti: Checking the source it seems this is to update the RR fields sent via mdns
[13:36] <lool> pitti: I think it's to be able to change hostname
[13:36] <lool> pitti: I mean, you're supposed to be able to call "hostname" to change hostname, but then avahi needs to send some updated mdns data on the network
[13:37] <lool> That's my guess at the use case; what it actually does it simply update an internal hostname string
[13:37] <lool> And it calls "register_stuff()" presumably to register the name via mdns
[13:37] <lool> pitti: i'll drop the change; thanks
[13:38] <pitti> lool: but in this case network-admin should just poke avahid to re-read the hostname
[13:38] <lool> I don't quite get why there's a hostname argument to SetHostname in the first place; it should be read from the system on startup and on update
[13:39] <lool> It defaults to reading from the system anyway
[13:53] <tjaalton> Hobbsee: umm, no.. that would add the debian changelog between merges?
[13:53] <Hobbsee> tjaalton: which is the point, no?
[13:53] <Hobbsee> well, to the .changes file
[13:54] <tjaalton> man debuild doesn't mention that
[13:54]  * Hobbsee summons the mighty Keybuk
[13:55] <Hobbsee> tjaalton: true.  it's only for merges - where we want to see what's changed, to see what's actually changing on our systems
[13:55] <cjwatson> Hobbsee is correct
[13:55] <tjaalton> ok, I'll use it from now on
[13:56] <cjwatson> tjaalton: debuild refers to dpkg-buildpackage for many of its options
[13:56] <Hobbsee> hurrah, i'm right for once!
[13:56] <cjwatson>        -vversion
[13:56] <cjwatson>               Use changelog information from all versions strictly later than version.
[13:56] <cjwatson> dpkg-buildpackage(1)
[13:56] <tjaalton> the latest xorg upload makes clean installations work again
[13:57] <Hobbsee> \o/
[13:58] <tjaalton> the xserver symlink is no more
[14:04] <Keybuk> Hobbsee: ?
[14:04] <Hobbsee> Keybuk: thought you might enjoy giving tjaalton the ritual yelling for not doing merges properly
[14:04] <Hobbsee> but colin's beaten you to it.
[14:04] <Hobbsee> without the yelling
[14:05] <ogra> yeah colin is bad at yelling :)
[14:06]  * tjaalton trembles
[14:06] <ogra> he's the walking patiency :)
[14:06] <Hobbsee> ogra: yeah, he seems more the "i'm really disappointed with you for doing this" type
[14:18] <cjwatson> asac: could I give you my netbase and wireless-tools merges?
[14:18] <cjwatson> you seem a better choice for those than I
[14:20] <cjwatson> cricket, eagle-usb, fakeroot, klibc, makedev, mbr, and xinetd are up for grabs too
[14:20] <asac> cjwatson: yes I think so ... how much do our packages diverge from debian?
[14:20] <cjwatson> asac: not all that much
[14:20] <cjwatson> just four or five fairly isolated changes in each
[14:21] <asac> cjwatson: ok ... enqueued. will take a look
[14:21] <cjwatson> asac: thanks
[14:21] <ogra> asac, do you have an idea if upstream wants to keep the bad behavior for self signed ssl certs for final ? (you have to go into the guts of your settings and enable it on FF 3 instead of getting an easy popup to accept it)
[14:21] <cjwatson> I haven't actually figured out how to accept self-signed certs in firefox 3 yet - the place it directed me to in the preferences doesn't seem to have it
[14:22] <cjwatson> ogra: can you help me out, if you've worked it out already?
[14:22] <ogra> go to the advanced prefereance, then give the url manually and click on add-exception (from teh top of my head)
[14:23] <ogra> (encryption tab in advanced)
[14:23] <cjwatson> which bit of Edit -> Preferences -> Advanced -> Encryption?
[14:23] <asac> ogra: do you have a page with a self sign cert at hand?
[14:23] <ogra> ah, you need to click on "view certificates" to get to the add exception thing
[14:23] <ogra> cjwatson, right
[14:24] <ogra> asac, https://www.educonlinux.eu
[14:24] <cjwatson> ogra: I don't see where to enter a URL there
[14:24] <cjwatson> there is no "add exception" button
[14:24] <cjwatson> oh, under Servers
[14:24] <cjwatson> that's incredibly hard to find
[14:24] <ogra> yep
[14:24] <ogra> took me 30 min to find out its not the servers fault ... and then 1h to fond the setting
[14:25] <ogra> *find
[14:26] <ogra> i think the popup here something they urgently should add back again ... there are many self signed certs out there
[14:26] <asac> ogra: i will ask upstream about their plan
[14:26] <asac> ping me in a few days :)
[14:26] <ogra> a warning makes sense though ....
[14:26] <ogra> will do :)
[14:39] <\sh> asac, are you working on the sec fixes for ff? (backporting them from .10?)
[14:40] <\sh> or did I miss an update...hmmm
[14:40] <asac> \sh: i think we already rolled them
[14:40] <\sh> asac, yeah I missed it...
[15:00] <Asusu> hello. I'm trying to build a python application from source using autoconf, however there seems to be missing a dbus-1.pc in ubuntu, however there seems to be a /usr/lib/pkgconfig/ndesk-dbus-1.0.pc
[15:01] <Asusu> Is this an Ubuntu packaging problem or a python problem? Or is it I may be missing some package?
[15:04] <Pici> Asusu: In 7.10 I see this: libdbus-1-dev: usr/lib/pkgconfig/dbus-1.pc
[15:04] <Asusu> I got 7.10, don't have that file :(
[15:05] <Asusu> can you please run on your system dpkg -S dbus-1.pc
[15:05] <seb128> Asusu: that's what he just did and copied to you
[15:05] <Asusu> to see what package I have to install please?
[15:05] <stdin> "libdbus-1-dev" < is the package
[15:05] <Asusu> oh sorry xD very sorry didn't see the package
[15:05] <Asusu> thanks! :)
[15:06] <seb128> Asusu: you can use http://packages.ubuntu.com for such questions
[15:06] <Asusu> I have, but didn't find a solution there
[15:06] <Asusu> however maybe I didn't use it well
[15:07] <tkamppeter> mvo, bdmurray (or anyone else from QA), I have posted some SRUs for which my packages already got approved into -proposed, but I did not hear any results of the QA testing process. Can you test test these. The SRUs are: bug 163594, bug 149511, bug 153152, they should not end up like bug 65618 last year.
[15:07] <ubotu> Launchpad bug 163594 in foo2zjs "[Edgy/Feisty/Gutsy SRU request] getweb script of foo2zjs needs update of download URLs" [Medium,Fix committed] https://launchpad.net/bugs/163594
[15:07] <ubotu> Launchpad bug 149511 in ubuntu-meta "[Gutsy SRU request] hplip is needed by HPIJS" [Medium,Fix released] https://launchpad.net/bugs/149511
[15:07] <ubotu> Launchpad bug 153152 in hplip "Fax utility not adding files to job." [Undecided,Fix committed] https://launchpad.net/bugs/153152
[15:07] <ubotu> Launchpad bug 65618 in foo2zjs "Firmware upload to LJ 1000/1005/1008/1020 broken (fix to be proposed as Edgy update)" [Medium,Fix released] https://launchpad.net/bugs/65618
[15:08] <pitti> pochu: please do not modify Maintainer: for fakesyncs, and do not use 'ubuntu' version numbers; use 'build1'
[15:09] <slomo_> pitti: it's a sync from pkg-gnome svn, i.e. the version is not yet in debian
[15:09] <pitti> slomo_: right, but it should be autosynced on the next opportunity?
[15:10] <slomo_> pitti: so correct would be -0build1?
[15:12] <cjwatson> "ubuntu" in a version number means "inhibit automatic syncing"
[15:12] <pitti> not sure, but it should work; or ~1svn or so maybe?
[15:12] <pitti> slomo_: I don't think we have existing common practice for this case
[15:12] <slomo_> pitti: ok, so i could name it whatever i want as long as it doesn't contain "ubuntu" and is lower than the debian upload? good to know :)
[15:12] <slomo_> in the past i made -0ubuntu1 versions of such stuff too
[15:13] <pitti> slomo_: it's not really wrong, we just need to file a manual sync request the next time
[15:15] <slomo_> pitti: well, i'll file the sync request anyway when i upload that version to debian :)
[15:15] <pitti> slomo_: :) (great)
[15:16] <pochu> pitti: will do, thanks.
[15:35] <h4x0r7h1s> Any plans to remove at.deny from Hardy?
[15:35] <h4x0r7h1s> as per malone #151611
[15:35] <ubotu> Launchpad bug 151611 in at "[security] at.deny exists" [Undecided,New] https://launchpad.net/bugs/151611
[15:45] <cjwatson> h4x0r7h1s: I don't even understand how that's a bug, much less a security problem
[15:45] <cjwatson> it denies access to system users that should never need to use at, but nevertheless allows it for normal users
[15:46] <h4x0r7h1s> cjwatson:  log in as a normal non-sudo user and add an at job to run /home/my/user/hammer.sh that does $0 | $0
[15:47] <pitti> h4x0r7h1s: there are easier ways to shoot yourself in the foot
[15:47] <h4x0r7h1s> cjwatson: if you rm at.deny and add an at.allow that contains only 'root' (or no at.allow at all) only root can create at jobs
[15:47] <cjwatson> h4x0r7h1s: not a bug; you could do the same without at
[15:47] <pitti> h4x0r7h1s: and that would change what?
[15:47] <h4x0r7h1s> pitti:  it'd change the ability for a user to create a confusing issue where the machine goes down every night at 12:47 am ;)
[15:47] <pitti> h4x0r7h1s: sleep 3600; <fork bomb here>, then disown
[15:47] <cjwatson> if you wanted to have it run while you're not logged in, you could do nohup 'sleep 10000; whatever' (or something of that general nature)
[15:48] <cjwatson> there is no call to break at
[15:48] <h4x0r7h1s> pitti:  more pertainently, I don't want users to have privileges they may not necessarily need
[15:48] <pitti> h4x0r7h1s: but at is a convenience, not a privilege
[15:48] <ogra> you are free to change it on your install ;)
[15:48] <cjwatson> h4x0r7h1s: dpkg --purge at
[15:49] <cjwatson> or set at.deny/at.allow up yourself
[15:49] <h4x0r7h1s> pitti:  one nice hack was to use nc to send a reverse shell every 15 minutes, which took me about 5 hours to figure out how these guys re-owned a server again and again after I fixed the firewall
[15:49] <cjwatson> the default configuration does *not* grant them any extra privileges
[15:49] <cjwatson> it merely allows them to do something that they could do anyway in a different way
[15:49] <h4x0r7h1s> cjwatson:  so, without at being installed, normal users can add time-based jobs?
[15:50] <cjwatson> h4x0r7h1s: yes, see what pitti and I said above
[15:50]  * ogra wonders how many out of 10 million users might make use of that at all ? 
[15:50] <pitti> h4x0r7h1s: sure, just leave a process running in the background
[15:50] <h4x0r7h1s> heh true.  But what about through a reboot?
[15:50] <cjwatson> crontab @reboot
[15:50] <tkamppeter> Anyone from QA around? Anyone who can finally accept SRUs?
[15:51] <cjwatson> cron and at are useful facilities. I'm sorry that you had a problem, but there is no call to misdescribe it as a security flaw.
[15:51] <pitti> tkamppeter: you should subscribe sru-verification to those bugs if they aren't already
[15:51] <h4x0r7h1s> Literally every security configuration guideline I've ever read says to make sure {at,cron}.deny do not exist ... hell there was a CERT alert about .deny files existing by default and being blank I though
[15:52] <pitti> h4x0r7h1s: but really, at that level you have to disable every kind of service
[15:53] <pitti> heck, you can use .procmailrc to run stuff
[15:53] <cjwatson> guidelines for hard lockdown of highly vulnerable systems are not the same as what it is appropriate to ship by default
[15:53] <cjwatson> security has a social element; if you make the system useless by default, most people will just go through and undo all your "security" measures
[15:54] <h4x0r7h1s> pitti:  .procmailrc is world writable and run automatically for users that haven't logged in in ages?
[15:54] <h4x0r7h1s> cjwatson:  I've never used at ;p
[15:55] <h4x0r7h1s> ever
[15:55] <pitti> h4x0r7h1s: why world-writable? (it should be 0600)
[15:55] <ion_> *plop* Are you sure you want to do that?    *plop* Are you sure you want to do that?    *plop* Are you sure you want to do that?    *plop* Are you sure you want to do that?    Sooner or later users will just turn that off. :-)
[15:55] <cjwatson> h4x0r7h1s: many people have, and do
[15:55] <ogra> h4x0r7h1s, it will be run if you send that user a mail ...
[15:55] <pitti> h4x0r7h1s: so far we were not talking about running stuff as another user
[15:55] <h4x0r7h1s> ogra:  ah, so you can make something externally triggerable
[15:55] <pitti> ion_: argh Vista *kittensdie* argh
[15:55] <cjwatson> and I bet you *have* used cron, and there is nothing you can do with at that you can't do with cron
[15:56] <cjwatson> (at least from a high-level perspective; fine details obviously differ)
[15:56] <tkamppeter> pitti, thanks, I thought the verification-needed tag and the subscribing to ubuntu-sru was enough. I will subscribe them to sru-verification now.
[15:56] <pitti> tkamppeter: it should help speeding it up
[15:56] <h4x0r7h1s> cjwatson:  ubuntu doesn't seem to ship a cron.deny or cron.allow
[15:57] <h4x0r7h1s> cjwatson:  meaning only root can use cron by default  :p
[15:57] <cjwatson> h4x0r7h1s: incorrect
[15:57] <h4x0r7h1s> cjwatson:  well, I sure as fuck don't have one by default.
[15:57] <cjwatson> "If neither of these files exists, then depending on site-dependent configuration parameters, only the super user will be allowed to use this command, or all users will be able to use this command. For standard Debian systems, all users may use this command."
[15:58] <cjwatson> crontab(1)
[15:58] <pitti> h4x0r7h1s: works on a default install; my backup relies on it :)
[15:58] <cjwatson> h4x0r7h1s: please lose the swearing or you will be asked to leave
[15:58] <cjwatson> it is not necessary
[15:58] <h4x0r7h1s> cjwatson:  ah interesting
[15:59] <h4x0r7h1s> $ at
[15:59] <h4x0r7h1s> You do not have permission to use at.
[15:59] <pitti> that's your local configuration
[15:59] <h4x0r7h1s> cjwatson:  I removed my /etc/at.{allow,deny} and it did this... does at behave as cron?
[15:59] <cjwatson> h4x0r7h1s: their semantics are not identical
[15:59] <h4x0r7h1s> alright.
[15:59] <cjwatson> see the manual pages
[16:00] <h4x0r7h1s> (cron just complains about cron.pid permissions)
[16:00] <ogra> you should see that:
[16:00] <ogra> ogra@laptop:~/devel/hardy/ldm$ at
[16:00] <ogra> Garbled time
[16:00]  * ogra didnt touch his defaults
[16:00] <cjwatson> ogra: incorrect invocation
[16:00] <cjwatson>        at [-V] [-q queue] [-f file] [-mldbv] TIME
[16:00] <cjwatson> $ at 5pm
[16:00] <cjwatson> warning: commands will be executed using /bin/sh
[16:00] <cjwatson> at>
[16:00] <ogra> cjwatson, well, i didnt want to set anything ... just show i dont get the "permission denied" :)
[16:01] <pitti> (^ use atq)
[16:01] <cjwatson> right, but thought it was worth mentioning in case people got confused by the error message
[16:01] <h4x0r7h1s> ogra:  I get garbled time if I have the default at.deny
[16:01] <ogra> yeah
[16:01] <h4x0r7h1s> ogra:  I can't use cron at all though
[16:01] <ogra> well, revert what you changed then ;)
[16:01] <cjwatson> h4x0r7h1s: you don't use cron by running cron(1)
[16:02] <ogra> "crontab -e" would be what you want for cron
[16:02] <h4x0r7h1s> cjwatson:  ah ok.
[16:02] <ogra> see the manpages ;)
[16:03] <jgoss> talk to howie?
[16:03] <jgoss> sorry
[16:18] <superm1> sure pitti, i hadn't realized there was a standard template when I made it (this was my first one).  I'll make sure in the future to do so.
[16:18] <pitti> superm1: thanks
[16:25] <tkamppeter> bdmurray, mvo, can you have a look at my SRUs?
[16:26] <tkamppeter> mvo, bdmurray, I have posted some SRUs for which my packages already got approved into -proposed, but I did not hear any results of the QA testing process. Can you test test these. The SRUs are: bug 163594, bug 149511, bug 153152, they should not end up like bug 65618 last year.
[16:26] <ubotu> Launchpad bug 163594 in foo2zjs "[Edgy/Feisty/Gutsy SRU request] getweb script of foo2zjs needs update of download URLs" [Medium,Fix committed] https://launchpad.net/bugs/163594
[16:26] <ubotu> Launchpad bug 149511 in ubuntu-meta "[Gutsy SRU request] hplip is needed by HPIJS" [Medium,Fix released] https://launchpad.net/bugs/149511
[16:26] <ubotu> Launchpad bug 153152 in hplip "Fax utility not adding files to job." [Undecided,Fix committed] https://launchpad.net/bugs/153152
[16:26] <ubotu> Launchpad bug 65618 in foo2zjs "Firmware upload to LJ 1000/1005/1008/1020 broken (fix to be proposed as Edgy update)" [Medium,Fix released] https://launchpad.net/bugs/65618
[16:29] <pitti> tkamppeter: some of those are certainly hardware specific; did you get any feedback from the submitters?
[16:30] <pitti> tkamppeter: you should ask for it again in the bugs, if not
[16:30] <pitti> tkamppeter: for bugs which are not hw specific, providing a test case in the bug report will help the verification team
[16:32] <calc> slangasek: i'm working on them
[16:32] <pitti> hi calc, good mornign
[16:33] <calc> pitti: good morning
[16:33] <pitti> calc: please poke me when you upload the gutsy-proposed OO.o, so that I can wave it through in a timely manner
[16:33] <calc> pitti: already uploaded yesterday, i'll see if i got a message back from lp
[16:34] <pitti> calc: no, it's not in the queue, I checked it some hours ago
[16:34] <calc> hmm yea i think i know why
[16:35] <tkamppeter> pitti, they have all a test case in the initial description now, only problem is that they are all on printer drivers, so they need all a printer of a certain class of devices.
[16:35] <calc> pitti: i forgot to manually update the changelog to gutsy-proposed, i wish dch -i would take the last used target for the new entry
[16:36] <pitti> tkamppeter: hm, and adding a queue with that driver without the hardware is not possible to demonstrate the bug? (such as outputting to file:/)
[16:36] <geser> pitti: Hi, please give-back lablgtk2. Thanks
[16:36] <tkamppeter> pitti, bug 149511 can be tested also without printer by doing only the "sudo dpkg -r hplip" and after that "ldd /usr/bin/hpijs | grep libhp".
[16:36] <ubotu> Launchpad bug 149511 in ubuntu-meta "[Gutsy SRU request] hplip is needed by HPIJS" [Medium,Fix released] https://launchpad.net/bugs/149511
[16:36] <calc> pitti: i'll be uploading it in about 5min
[16:36] <pitti> calc: dch -i> oh, doesn't it any more?
[16:36] <pitti> geser: done
[16:39] <tkamppeter> pitti, the fax issue of bug 153152 is difficult, as hp-sendfax will not show its GUI without fax queue and it seems also that CUPS will not set up a fax queue without the hpfax backend creating a valid fax URI.
[16:39] <ubotu> Launchpad bug 153152 in hplip "Fax utility not adding files to job." [Undecided,Fix committed] https://launchpad.net/bugs/153152
[16:39] <calc> pitti: well previous entry was gutsy-proposed i did a new dch -i yesterday and it set it back to gutsy without me noticing
[16:40] <pitti> calc: weird; I'm pretty sure that earlier dch versions didn't do that
[16:40] <calc> pitti: its possible i did something weird, or perhaps a patch got dropped somewhere
[16:41] <calc> hmm yea dch -i doesn't use the previous entry target, just verified it again
[16:41] <calc> so new dch -i set to 'gutsy' again
[16:41] <tkamppeter> pitti, bug 163594 is no problem at all, no printer supported by foo2zjs is needed.
[16:41] <ubotu> Launchpad bug 163594 in foo2zjs "[Edgy/Feisty/Gutsy SRU request] getweb script of foo2zjs needs update of download URLs" [Medium,Fix committed] https://launchpad.net/bugs/163594
[16:42] <calc> pitti: ok its uploading now so it should be done in 20m or so
[16:42] <pitti> calc: thanks
[16:45] <keescook> morning
[16:46] <pitti> hey keescook
[16:50] <geser> Hi keescook
[16:50] <cjwatson> calc: I'm told that dch in hardy DTRT
[16:50] <cjwatson>     + Make -r use the distribution specified in the previous changelog entry by
[16:50] <cjwatson>       default (Closes: #364510)
[16:51] <cjwatson> 'DEBCHANGE_RELEASE_HEURISTIC=changelog' in ~/.devscripts helps, too
[16:53] <calc> cjwatson: oh ok
[17:01] <keescook> hiya pitti, geser.  :)
[17:34] <geser> pitti: do you mind if I give you a small list of packages to give-back?
[17:34] <pitti> geser: no, not at all; please don't put commas in between
[17:35] <geser> pitti: acepack camera.app charmap.app connect.app displaycalibrator.app easydiff.app gnustep-back gnustep-examples gnuwash.app gomoku.app gworkspace gridlock.app helpviewer.app innerspace.app ladder.app lapispuzzle.app latex.service
[17:36] <pitti> geser: running
[17:36] <geser> pitti: thanks
[17:38] <calc> pitti: its done uploading now
[17:42] <pitti> sparc buildd hamsters, pedal faster!
[17:42] <pitti> well, we actually need more hamsters
[17:44] <ScottK> hmmm, hamster.
[17:46] <pitti> calc: accepted, thanks
[17:46] <calc> pitti: thank you :)
[18:06] <geser> doko: I'm looking at gmetadom which you last touched. I don't understand your changelog entry "Fix build failure with g++-4.3." as I only see changed to debian/ files in http://patches.ubuntu.com/g/gmetadom/gmetadom_0.2.5-1ubuntu1.patch
[18:12] <ogra> pitti, one question to an archive admin ... do we still have a blacklist opportunity for syncs from debian?
[18:12] <cjwatson> ogra: yes
[18:12] <pitti> ogra: yes, we do
[18:12]  * ogra needs to find a way to maintain ltsp ... that gets tricky now that we have upstream tarballs 
[18:12] <ogra> ah, cool
[18:13] <ogra> whom do i poke to add all the ltsp stuff to it ?
[18:13] <cjwatson> any archive admin, or ubuntu-archive@lists
[18:13] <cjwatson> with a list of source package names
[18:13] <cjwatson> ltsp-utils is already on there
[18:14] <ogra> ltsp-utils is dead since ages and will be gone if lenny is released
[18:14] <cjwatson> there's no cost to dead stuff on the blacklist :)
[18:14] <ogra> its an anachronism  and debian suffers heavily from it :)
[18:15] <ogra> thanks :)
[18:44] <mvo> slangasek: how does the CD look? I guess you will not want me to update compiz (+ depends) just now?
[18:53] <calc> mvo: ping
[18:53] <tkamppeter> pitti, I have updated all my SRU bugs and added testing methods which work without printer to all of them.
[18:54] <pitti> calc: oops, seems you used -v wrongly on the SRU; sorry, I didn't check the .changes file
[18:54] <pitti> tkamppeter: awesome, thanks
[18:57] <pitti> tjaalton, bryce: latest xorg merge rendered xserver-xorg-video-all uninstallable on sparc, which (I guess) is the main cause for the current sparc uninstallability mess
[18:58] <mvo> hello calc
[18:58] <bryce> pitti: hmm, do we still support sparc?
[18:58] <mvo> calc: patch> haven't looked at it yet :(
[18:58] <pitti> bryce: I didn't hear otherwise
[18:58] <pitti> and I guess it's just pulling in a driver which doesn't exist on sparc
[18:59] <bryce> pitti: I don't know offhand what was in the xorg update, but I know some of the pending changes may be removing some sparc-specific hacks from the xorg postinst script
[18:59] <bryce> ah, hmm
[18:59] <pitti> bryce: this is from http://people.ubuntu.com/~ubuntu-archive/testing/hardy_probs.html
[18:59] <pitti> bryce: so it's not postinst, just pure dependencies
[18:59] <bryce> okay
[19:00] <slangasek> I'm not aware that any of the pending changes were disabling sparc at this point?
[19:00] <slangasek> but anyway, that would only affect sbus video detection if it did, AFAIK
[19:00] <pitti> hi slangasek
[19:00] <slangasek> mvo: the CDs look disastrous, but nothing a day of hard work won't fix.  updating compiz might be inconvenient. :)
[19:01] <slangasek> pitti: heya
[19:01] <pitti> slangasek: so, I tried to get *-desktop installable, but it needs much more beating
[19:01] <bryce> slangasek: I'm anticipating that gravity's reworking of the postinst stuff will drop the sparc-specific stuff from those scripts
[19:01] <slangasek> bryce: then I may be thwapping him in the near future :)
[19:01] <pitti> seb128: just to confirm, you are on the outstanding MIRs?
[19:01] <bryce> (I also listed the particulars in pitti's hardware-detection spec)
[19:02] <bryce> slangasek: I don't honestly know if those hacks are still relevant with current sparc hardware, but if so, they'll need to be migrated to more appropriate locations (like into x.org itself)
[19:03] <slangasek> sure, but you don't pull support out from under users before that migration is done, this isn't Gentoo ;)
[19:03] <bryce> I'm hoping this can all be done transparently, but realistically I anticipate breakage for poor sparc folks at least once or twice during hardy
[19:03] <bryce> hehe
[19:03] <mvo> is someone here that knows about the kde build system? Riddell maybe? it seems that "make dist" is not cool for a kde package and the generated tarball need stuff like admin/cvs.sh (why?) and refuses to build without it. I really want to update the kde bits of compiz, but it gives me a headache currently
[19:03] <slangasek> what I know of the kde build system gives me hives, sorry
[19:04] <azeem> isn't that cmake?
[19:06] <mvo> azeem: don't ask difficult questions :) at least the package I'm working on dosn't use cmake, not sure about kde in general
[19:07] <azeem> heh, ok
[19:07] <azeem> kde4 is doing cmake I think
[19:07] <slangasek> kde4 was supposed to be moving to cmake
[19:07] <slangasek> kde3 uses automake + horror-show
[19:08]  * azeem just found out today that another downside of "we don't need convenience libs" cmake is that it loves to link in static, unrelocatable libraries to shared objects
[19:09] <slangasek> ah, then things are looking up for kde build systems, aren't they
[19:09] <azeem> while googling for solutions I found some cries for help on kde lists
[19:10] <seb128_> re
[19:10] <seb128_> pitti_: I was asking, what MIRs do you speak about?
[19:11] <pitti_> seb128_: sorry, my network connection sucks this afternoon
[19:11] <pitti_> seb128_: well, didn't you mention some ggz and other stuff which the new gnome needs?
[19:12] <seb128_> mine as well
[19:12] <seb128_> pitti_: ggz is required for gnome-games to build but that's not creating installability issues
[19:13] <seb128_> pitti_:
[19:13] <seb128_>   ubuntu-desktop: Depends: hal-device-manager but it is not installable
[19:13] <seb128_>                   Recommends: gimp-print but it is not installable
[19:13] <seb128_>                   Recommends: restricted-manager but it is not installable
[19:14] <seb128_> pitti_: should those unseeded?
[19:14] <slangasek> hal-device-manager already is
[19:14] <slangasek> except that StevenK didn't upload ubuntu-meta like he said he would
[19:15] <slangasek> restricted-manager probably belongs in the seed and is just not installable because it's restricted, no?
[19:15] <slangasek> (no idea on gimp-print)
[19:15] <tjaalton> pitti_: the intel driver was uninstallable before, that's the reason why -all is uninstallable on sparc
[19:16] <tjaalton> the latest xorg merge didn't do anything, AFAICS
[19:16] <calc> mvo: ok no problem :)
[19:17] <calc> mvo: i noticed without the fallback change i mentioned i didn't do it appears that apt-get update tries to download .lzma packages files and fails and doesn't fall back right
[19:17] <calc> mvo: the change is probably simple but i didn't want to risk breaking anything
[19:19] <seb128_> slangasek: gimp-print is deprecated
[19:19] <mvo> calc: oh, the patch adds support for those too? I have a look tomorrow, I guess tomorrow is the apt day then :)
[19:20] <calc> mvo: yea, i think changing the one function i mentioned in the email will probably correct the fallback issue if Packages.lzma doesn't exist
[19:20] <seb128_> slangasek: right for restricted manager, it was a lack of restricted source in my pbuilder
[19:21] <calc> apt-pkg/acquire-item.cc pkgAcqIndex::Failed
[19:21] <calc> mvo: ^ that function
[19:21] <mvo> calc: ok, I check it out
[19:21] <slangasek> seb128_: s/deprecated/obsoleted/? since it's not present in hardy
[19:22] <tjaalton> pitti_: suncg6 needs a rebuild
[19:22] <seb128_> slangasek: right, the gimp upload StevenK did today has
[19:22] <tjaalton> but that's not the cause
[19:22] <seb128_> "   * Ubuntu changes dropped:
[19:22] <seb128_>      - Since we aren't in a freeze, and we can make this change now, restore
[19:22] <seb128_>        the Conflicts and Replaces against gimp-print and stop building with
[19:22] <seb128_>        --without-print.
[19:22] <seb128_>      - Re-add NEWS, README and README.Debian to gimp.docs."
[19:22] <calc> as soon as apt and dpkg are ready i'm going to do a test lzma build and then upload OOo using lzma support (after asking cjwatson of course) ;)
[19:22] <calc> which should help shrink our daily cd images
[19:22] <mvo> yeah
[19:22] <mvo> calc++
[19:23] <slangasek> seb128_: ok, sounds like someone with access should pull it from the seed
[19:23] <seb128_> looking to do that now
[19:23] <slangasek> calc: if you mean you're going to upload it before the alpha, aren't you forgetting to ask someone else? :)
[19:23] <elmo> you guys are coordinating soyuz updates for lzma... right?
[19:24] <seb128_> re pitti
[19:25] <pitti> **ngggg** network
[19:25]  * pitti declares dinner time, bbl
[19:25] <calc> slangasek: oh it will likely be after alpha-1 due to launchpad needing changes as well, but yea i'll ask you too ;-)
[19:26] <calc> slangasek: btw my alpha-1 targeted bugs probably won't make it until alpha-2
[19:26] <calc> considering that is 2 days from now
[19:27] <calc> and i don't want to kill the buildds any more than i have with the gutsy-update this close to the alpha
[19:27] <tjaalton> pitti: you probably didn't see my reply?
[19:27] <slangasek> seb128: are you available to help work on seed merging and uploading -meta, since pitti is incapacitated?
[19:28] <slangasek> seb128: I could do the seed merging and give you a place to pull it from if you like, though I'm not sure it's worth it
[19:28] <slangasek> as opposed to, y'know, just pulling from hardy.ubuntu :)
[19:28] <calc> OOo 2.3.1 should make it into the archive before alpha-2 also
[19:28] <seb128> slangasek: I'm getting the seed right now
[19:28] <slangasek> seb128: ok, thanks
[19:28] <seb128> slangasek: bzr is just taking some time
[19:28] <seb128> np
[19:28] <Kmos> http://archive.ubuntu.com/ubuntu/dists/hardy/ -> why there isn't Contents-* there ?
[19:29] <calc> Kmos: too much churn was the reason i heard
[19:29] <jdong> likewise as calc
[19:29] <jdong> only generated for releases.
[19:29] <Kmos> only be there when alpha-1 is out, right ?
[19:29] <calc> jdong: oh i heard it was due to all the debian imports
[19:29] <seb128> slangasek: I'm removing gimp-print from the desktop seed, anything else?
[19:30] <calc> if that is the case then it might be reenabled by dec 13 when debian import freeze happens
[19:30] <slangasek> calc: right, so if they're not going to make it until alpha-2, that implies that they were never really showstoppers for alpha-1 and under the New World Order, should not have been tagged with the milestone.  I'm guessing what you're needing is some kind of todo list for which bugs you're prioritizing to work on first?
[19:30] <slangasek> seb128: 11:25 < pitti> slangasek: I already merged to the edubuntu seeds, others are outstanding
[19:30] <seb128> ok
[19:31] <calc> slangasek: yea pretty much
[19:31] <slangasek> seb128: so merging the changes from hardy.ubuntu over to xubuntu/kubuntu/anything I've forgotten that's seeded
[19:31] <calc> slangasek: i didn't realize that was considered a showstopper list (oops)
[19:31] <seb128> alright, doing that
[19:31] <calc> slangasek: is there an easy way to tag stuff similiarly for todo that can be searched for in LP?
[19:31] <slangasek> calc: yeah, it's kind of a new outlook on the milestone lists.  I'll talk with the release team about your use case
[19:32] <slangasek> there's the "nominate for release" functionality, but that's going to be more long-term and may be less useful if what you want is "show me the next few things on my TOOD"
[19:33] <calc> slangasek: yea, maybe even have some sort of way to tag milestoned bugs as non-showstopper, so we would still mark them as a milestone but be able to filter them out
[19:34] <tjaalton> pitti: x-x-v-intel on sparc should be removed, it was mistakenly built there (fixed in -5)
[19:35] <tjaalton> er, 2.1.1-5
[19:39] <calc> cjwatson: ping
[19:48] <slangasek> calc: well, the issue with that is that if a bug is tagged for a particular milestone, and isn't a showstopper, it's likely to still be open when the milestone happens and then there's a lot of busywork to move the bugs from one milestone to the next
[19:48] <slangasek> calc: whereas if they were targetted appropriately to begin with, this would be a non-issue
[19:59] <geser> pitti_: another give-back batch: gtkfontsel mgcv mines.app poe.app open.app preview.app price.app projectmanager.app r-cran-mnp r-cran-maps r-cran-mapdata r-cran-vgam r-cran-xml rssreader.app stepbill.app stepulator.app steptalk terminal.app textedit.app timemon.app volumecontrol.app viewpdf.app wmshutdown wmcliphist xsu xosd renaissance
[20:00] <somerville32> Whats a giveback?
[20:00] <slangasek> rescheduling of builds
[20:01] <LaserJock> somerville32: like when a dependency wasn't available when a package was upload and so FTBFS
[20:01] <somerville32> ok
[20:02] <LaserJock> although that might not be the best example because I think depwaits are usually automatically retried
[20:04] <calc> slangasek: hmm yea that is true
[20:04] <calc> slangasek: so maybe something like a todo milestone would be better
[20:05] <calc> slangasek: or a general release milestone for bugs that need to be fixed in the cycle but not by a particular timeframe
[20:05] <seb128_> ogra: could you try to merge the ubuntu seed changes to edubuntu?
[20:05] <slangasek> calc: anyway, for the time being feel free to use the list as you are (though you may want to go ahead and move your OOo bugs from alpha-1 to alpha-2 now :) and I'll get back to you with something that's hopefully both blessed and works for you
[20:05] <slangasek> calc: oh, if you just want "need to be fixed in the cycle", please nominate for release
[20:05] <ogra> seb128_, do you need that tonight ?
[20:05] <slangasek> we have that one already :)
[20:06] <ogra> slangasek, thanks for the look at nbd btw :)
[20:06] <calc> slangasek: there isn't a hardy-alpha-2 available in the drop-down yet
[20:06] <seb128_> slangasek: apparently not
[20:06] <slangasek> cjwatson: I need an adult!
[20:06] <seb128_> maybe pitti_ has been disconnect before doing the change or something
[20:06] <calc> slangasek: perhaps all the available target milestones for a release should be in the drop-down once a release starts?
[20:06] <ogra> slangasek, oooh, thats hard in here
[20:06] <calc> slangasek: so then people don't need to juggle them later? :)
[20:06] <slangasek> seb128_: apparently not what?
[20:06] <slangasek> calc: yes, this is my theory too :)
[20:07] <seb128_> slangasek: ubuntu changes are not merged to edubuntu
[20:07] <slangasek> ogra: nbd> sure thing, they're easy to do when the upstream/Debian maintainer comes into the channel and says "please sync, I've merged all your changes"
[20:08] <slangasek> seb128_: hmm, ok
[20:08] <ogra> seb128, i'm merging now ...
[20:08] <seb128_> ogra: thanks
[20:08] <seb128_> ogra: you probably want to upload edubuntu-meta once you have done that too
[20:09] <ogra> seb128, indeed :)
[20:09] <ogra> i havent checked out the seeds yet since it wasnt clear yet how we handle the new CD structure
[20:10]  * ogra twiddles thumbs ... waiting for bzr
[20:10] <slangasek> new CD structure?
[20:10] <pochu> I thought there was to be no cd at all
[20:11] <ogra> slangasek, edubuntus main CD will vanish
[20:11] <ogra> pochu, wrong
[20:11] <slangasek> ogra: oh
[20:11] <pitti_> geser: running
[20:11] <ogra> edubuntu will become a plain addon on top of ubuntu-desktop or server
[20:11] <geser> pitti_: thanks again
[20:12] <slangasek> ogra: hrm, I'm guessing no one's done the work on telling debian-cd about this?
[20:12] <pochu> ogra: I see. So you will need to install Ubuntu and later the add-on, right?
[20:13] <ogra> slangasek, i dont even have the spec finished :/
[20:13] <ogra> pochu, right
[20:13] <slangasek> ogra: right, then I suppose edubuntu-meta shouldn't be changed yet either ;)
[20:13] <ogra> ltsp will move into ubuntu-alternate
[20:13] <ogra> slangasek, well, i can change it back any time :)
[20:14] <ogra> if there is stuff that should rather be merged *now* i'm fine to do that
[20:15] <lool> StevenK: gimp-print is being removed by the new gimp, but ubuntu-desktop depends on gimp-print
[20:15] <ogra> slangasek, i dont want to keep unneeded stuff in main though my seeds
[20:15] <lool> StevenK: Perhaps you need to remove gimp-print from the ubuntu-desktop deps?
[20:15] <lool> slangasek: Might affect CDs images?  ^^^
[20:16] <slangasek> ogra: you probably need to merge the edubuntu seed in order to get working CDs at all for alpha
[20:16] <seb128_> lool: already done
[20:16] <lool> seb128_: Thanks
[20:16] <ogra> slangasek, yeah, even though they might gain my nothing if we change it later
[20:16] <ogra> :)
[20:16] <ogra> *me
[20:16] <calc> what is the name of the page that you add MIRs to?
[20:17] <slangasek> ogra: well, if you'd prefer to skip out on alpha-1 for edubuntu due to the pending reorg, I can live with that
[20:17] <ogra> oh sigh, STRUCTURE has conflicts ...
[20:18] <calc> ah i found it 'UbuntuMainInclusionQueue'
[20:21] <seb128_> ogra: I think pitti did the seed merge now
[20:22] <pitti> right
[20:22] <pitti> ogra: oh, sorry, I should have looked into this channel first
[20:22] <pitti> ogra: I already committed
[20:22] <seb128_> pitti: I wrote it in the query but you probably didn't notice
[20:23] <pitti> I misinterpreted it
[20:23] <ogra> pitti, hmm
[20:23] <pitti> ogra: sorry again *hug*
[20:23] <ogra> the seeds are pretty out of sync in STRUCTURE it seems
[20:23] <ogra> be careful with that
[20:24] <pitti> ogra: don't worry, I didn't touch it; edubuntu doesn't need jeos
[20:25] <ogra> indeed :)
[20:25] <ogra> the supported sets are out of sync as well, not sure that good
[20:28] <seb128_> ogra: can you do the edubuntu-meta ubuntu if an upload is required?
[20:28] <ogra> sure
[20:29] <seb128_> thanks
[20:40] <seb128_> geser: any reason Debian doesn't need the schism Build-Depends change?
[20:40] <geser> seb128_: I don't know if Debian is also affected
[20:41] <seb128_> geser: why would the ftbfs be ubuntu specific?
[20:42] <geser> seb128_: good question, do Debian and Ubuntu use the same xorg packages or there still some difference
[20:42] <seb128_> geser: they use mostly the same packages nowadays
[20:43] <geser> seb128_: I just checked the Debian build logs and it builds fine in Debian
[20:43] <geser> some B-D seems to pull libxext-dev in
[20:44] <seb128_> geser: well, that's easy enough, if libxext-dev is required by the source it should have Build-Depends on it and no depends on an another package triggering it
[20:44] <seb128_> geser: so the bug is valid in Debian
[20:44] <seb128_> geser: if it's not required by the source then the Build-Depends is wrong
[20:45] <geser> seb128_: ok, will open then bugs in Debian for it
[20:45] <seb128_> geser: in any case we don't need a delta with Debian there ;-)
[20:45] <seb128_> geser: thanks
[20:47] <tjaalton> pitti: in case you missed my replies;
[20:47] <tjaalton> pitti: x-x-v-intel on sparc should be removed, it was mistakenly built there (fixed in -5)
[20:48] <pitti> tjaalton: I missed them, crappy network
[20:48] <tjaalton> and suncg6 is now being rebuilt, but those two were uninstallable long before the xorg upload :)
[20:48] <cjwatson> calc: pong
[20:48] <pitti> tjaalton: you mean that the -intel package itself should be removed from sparc? or that video-all shoudl stop depending on it?
[20:48] <cjwatson> slangasek: on my way
[20:49] <tjaalton> pitti: intel does not belong in sparc
[20:49] <tjaalton> video-all doesn't depend on it on sparc
[20:49] <pitti> tjaalton: hm, but the mere presence of -video-intel can hardly cause uninstallability of xorg?
[20:50] <slangasek> cjwatson: does that mean you saw and understood the context of that comment, or am I just getting what I deserve for being funny? :)
[20:50] <tjaalton> pitti: no, the real reason was suncg6 which was built against the old xserver (and becaus of that, Provides: x-x-v-1.0)
[20:50] <slangasek> cjwatson: anyway, can we get an alpha-2 milestone in lp?
[20:50] <tjaalton> +e
[20:51] <pitti> tjaalton: hm, I don't see a sparc deb for -intel in either the archive nor in NEW
[20:51] <tjaalton> -intel-dbg, sorry
[20:51] <cjwatson> slangasek: I saw and understood
[20:51] <slangasek> ok ):
[20:51] <slangasek> :)
[20:51] <cjwatson> slangasek: all milestones from HardyReleaseSchedule are in place now
[20:51] <pitti> tjaalton: same thing, I checked all debs from the source
[20:52] <slangasek> cjwatson: great, thanks!
[20:52] <tjaalton> pitti: ok, I'm confused as well :)
[20:52] <pitti> tjaalton: ah, now I see:
[20:52] <pitti> xserver-xorg-video-intel-dbg | 2:2.1.1-4ubuntu2 |         hardy | lpia, sparc
[20:52] <pitti> xserver-xorg-video-intel-dbg | 2:2.2.0-1ubuntu1 |         hardy | amd64, hppa, i386, ia64, powerpc
[20:53] <pitti> but well, that's just -dbg, and thus shouldn't cause any major uninstallability at all
[20:53] <tjaalton> right
[20:53] <pitti> tjaalton: so, let's blame suncg6
[20:53] <tjaalton> yes, let's
[20:53] <pitti> tjaalton: thanks
[20:54]  * pitti bumps its builds score
[20:54] <tjaalton> but I don't understand how it would be causing this trouble a month after it was built
[20:54] <slangasek> because no one's looked in a month? :)
[20:55] <pitti> I'm reasonably positive that this morning it wasn't that bad yet
[20:55] <tjaalton> heh, but how would it escalate like this
[20:55] <pitti> xserver-xorg-video-intel-dbg/sparc removed
[20:55] <tjaalton> pitti: it wasn't, I looked at the list couple of times this morning
[20:56] <pitti> right, and I look at it every other day
[20:56] <pitti> so I guess it must be something else as well
[20:58] <tjaalton> yep
[21:06] <knowmad> Hi, I'm looking for an assist in customizing a usplash screen for a LiveCD. I have the screen working for my desktop workstation but the LiveCD is proving more troublesome. My current error message is -- "usplash: can't get console font: Invalid argument". Any pointers?
[21:07] <sladen> knowmad: how are you trying to set the usplash replacement;  do you have a replacement theme package.  Do you have a font correctly referenced in that?
[21:09] <knowmad> no, i have not created a theme. i'm using a C script that we found in an example of building a customized usplash page. i think a theme would be even more difficult than just getting a screen to build.
[21:10] <sladen> what is this "C script"
[21:10] <knowmad> we essentially replace the default /usr/lib/usplash/usplash-artwork.so with our own
[21:10] <knowmad> dang, i knew you were going to ask me that
[21:10] <sladen> it sounds much more risky/complicated/dangerous that having a theme that provides a usplash-artwork.so
[21:10] <knowmad> one of my co-workers find it; i think it came from the examples
[21:11] <sladen> my recommation is to   apt-get source   one of the other themes
[21:11] <knowmad> the wiki entry for building a custom usplash didn't really talk about creating a theme. do you have a recipe?
[21:11] <knowmad> nice idea. i was toying with that in the back of my mind. so i get source then....
[21:11] <sladen> rename it (edit debian/control and debian/changelog), build that and install it
[21:12] <sladen> of course, everything in Ubuntu has source, source that you are legally allowed to modify and improve
[21:12] <sladen> it is one of the guiding principals of Free Software
[21:12] <knowmad> good point. so besides renaming i just replace my png file with the one that comes in source?
[21:13] <knowmad> i'm more comfortable with code than the packages; i just haven't taken the time to understand the deb build process
[21:13] <sladen> eg. grab  apt-get source xubuntu-artwork-usplash
[21:13] <knowmad> getting it now
[21:13] <sladen> sudo apt-get builddep xubuntu-artwork-usplash
[21:14] <sladen> base your own    foobuntu-artwork-usplash  package on that
[21:14] <knowmad> ok, i think i get it; looks like i have a bit of file renaming to do
[21:14] <sladen> actually use  gobuntu-artwork-usplash
[21:14] <sladen> it's even simpler
[21:16] <knowmad> oh, thanks!
[21:16] <sladen> what we could do with in the long-run in a webpage/script that creates a theme package from a PNG in one go
[21:30] <geser> pitti: are build failures "Chroot problem" automatically retried? and what to do with "Failed to upload" build failures?
[21:31] <elmo> chroot problems are not automatically retried, AFAIK
[21:31] <geser> so should I ask for give-backs in such cases too?
[21:32] <elmo> yep, assuming the problem was transient
[21:35] <geser> elmo: can you do give-backs?
[21:35] <knowmad> sladen: i've edited the files in the usplash dir and the debian/control and debian/changelog. now how do i make this into a deb?
[21:36] <elmo> geser: not really, sorry
[21:36] <geser> ok, I'll ask pitti then
[21:38] <sladen> knowmad: debuild -S
[21:38] <knowmad> thanks
[21:38] <sladen> knowmad: oh, without the -S for the binary .deb
[21:38] <cjwatson> -b not -S
[21:39] <knowmad> ok, i'll report back
[21:39] <cjwatson> 'sudo apt-get install devscripts fakeroot; sudo apt-get build-dep <source package name>' first
[21:39] <pitti> geser: just give me a list
[21:40] <pitti> geser: for failed-to-upload we should find out the particular reason
[21:40] <knowmad> i fubarred the changelog; it's erroring with badly formatted trailer line
[21:40] <pitti> geser: one common case is that a package was moved to main/universe while pacakges were built
[21:41] <macd> knowmad, did you use 'dch' to edit the changelog?
[21:43] <knowmad> no, though i found where i went wrong; debuild wants the date string in a very particular format; i'll try dch next time.
[21:43] <geser> pitti: please give-back: crack-attack pdfedit sdcc pam-p11 tomboy
[21:45] <geser> pitti: one example for "failed to upload" is compizconfig-bindings: see https://edge.launchpad.net/ubuntu/hardy/+source/compizconfig-bindings/+builds
[21:46] <knowmad> debsign is failing now saying i don't have gpg or pgp; i ran `apt-get install gnupg` but it's already installed; thoughts?
[21:47] <ScottK> What's the exact error?
[21:48] <knowmad> Could not find a signing program (pgp or gpg)! debuild: fatal error at line 1174: running debsign failed. I can't locate gnupg binary (fyi, i'm working in a LiveCD envirnoment of gutsy)
[21:50] <ScottK> Sorry then. If you've got it installed, I'm not sure what would cause that.  You might look in ~/.gnupg to make sure all the config files are present.
[21:52] <geser> knowmad: "which gpg" does give you an output?
[21:52] <knowmad> Good call; i had forgotten to set HOME in the chroot so it wasn't finding that dir. However, my binary is still MIA.
[21:52] <knowmad> geser: nada
[21:53] <geser> knowmad: you are in a chroot?
[21:53] <knowmad> yes
[21:53] <geser> knowmad: do you have gnupg installed inside the chroot?
[21:54] <knowmad> yep, it's say it is but the binary is gone. i'm going to try a force reinstall
[21:55] <sladen> knowmad: unless you have a PGP key, you'll probably have difficulty signing---there should be a .deb in the parent directory though!
[21:56] <knowmad> good point but debuilg is dying with a fatal b/c it can't find my gpg binary so no .deb
[21:56] <knowmad> where are the downloaded .deb's kept for apt?
[21:57] <knowmad> nevermind
[21:57] <ScottK> knowmad: You can also just tell debuild not to sign it.
[21:58] <knowmad> ok, got gpg binary installed now; what's the flag to not sign?
[21:59] <ScottK> knowmad: man dpkg-buildpackage
[22:00] <knowmad> that explains why i couldn't find it in debuild docs
[22:05] <knowmad> ok 'debuild -b -us -uc' did the trick with no errors; now i have a .deb file in the parent dir; so now for the test (drumroll)
[22:07] <knowmad> no install errors but my new usplash theme is not coming up as an option when i run `update-alternatives --config usplash-artwork.so` as advised in Usplash wiki docs; i'm going to have to review my source files
[22:23] <pitti> geser: builds retried
[22:24] <pitti> geser: ah, compizconfig-bindings looks weird; it failed to upload because the binaries were already built in gutsy
[22:25] <pitti> geser: I have no idea why they got duplicate build records
[22:26] <geser> so this should fix itself with the next upload?
[22:26] <geser> and no action is needed?
[22:26] <pitti> geser: there's nothing to fix AFAICS
[22:27] <pitti> geser: the binaries are all built and in the archive
[22:27] <geser> ok, I will ignore it (there are enough other build failures to fix :)
[22:28] <pitti> good night everyone
[22:39] <knowmad> sladen: OK, i have now successfully built a package (woohoo!) that still fails with font errors and now with "No usable theme found for 640x480". Any ideas for debugging these errors? BTW, thanks for helping me build the pkg. If I ever get my usplash image to work having a pkg is going to be nice for maintenance.
[22:53] <tormod> anyone who would like to sponsor merges, please? bug #164387 and bug #164379
[22:53] <ubotu> Launchpad bug 164387 in laptop-mode-tools "please merge laptop-mode-tools 1.35-1 from Debian unstable main" [Undecided,New] https://launchpad.net/bugs/164387
[22:53] <ubotu> Launchpad bug 164379 in linux-wlan-ng "please merge linux-wlan-ng 0.2.8+svn1839+dfsg-2 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/164379
[22:55] <sladen> knowmad: see if you can get the non-modified goubuntu-theme package with installed
[22:56] <knowmad> does anyone know why usplash would complain about not being able to "get console font"? This is happening for both the gobuntu-artwork-usplash pkg in gutsy as well as my custom pkg built from it
[22:56] <sladen> knowmad: then figure out what got changed  (diff -ru goubuntu/ foobuuntu/)
[22:56] <sladen> knowmad: oooh.  right
[22:56] <knowmad> sladen: i think i just addressed your suggestion
[22:56] <knowmad> yeah, best i can find on google are references to CONSOLEFONT in /etc/rc.conf but ubuntu does not have that config file
[22:56] <sladen> cjwatson_: ^^console-setup stuff?
[22:58] <sladen> knowmad: did anything get changed previously, eg.  vga=  on the kernel commandline?
[22:59] <knowmad> no, i just started with a clean copy last night about 11pm; hadn't gotten that far yet to start changing kernel configs; in fact, i'm not entirely sure where to do that for isolinux
[23:01] <sladen> knowmad: okay, can you try debugging that issue and ensuring that it's reported somewhere in the bug tracker
[23:03] <knowmad> yes, i can make sure it's reported for gobuntu-artwork-usplash; i'm a bit in the dark on debugging; you were asking cjwatson_ about console-setup; should i look in there?
[23:04] <sladen> knowmad: start by googling for "can't find console font"---and the error message you got
[23:04] <knowmad> ok
[23:04] <knowmad> btw, that msg was Invalid argument
[23:05] <knowmad> and google finds no matches for "Can't find console font: Invalid argument" :(
[23:06] <sladen> try a shorter substring
[23:08] <knowmad> yeah, still not much coming back for me.  i just compared the usplash-theme-xubuntu.c source to mine based on gobuntu and i don't see much differences. still looking....
[23:10] <sladen> double check the xubuntu one does actually work
[23:11] <sladen> the gobuntu one may only be provide a single colour depth
[23:14] <knowmad> hmm, i thought i had tested it but now i'm getting the same console font error; perhaps if i build an iso and try running it the way it will be done in real life i'd have better luck
[23:15] <knowmad> and btw, i was using the wrong terms in my search which is why no results (darn typos!)
[23:15] <sladen> knowmad: are you running on amd64, powerpc, sparc, or something weird
[23:16] <knowmad> nope, nothing like that
[23:17] <knowmad> sladen: do you think that usplash should work in chroot with proper X display support?
[23:17] <sladen> usplash -c
[23:18] <knowmad> yep, that's the command (plus -v for more output)
[23:18] <sladen> usplash doesn't use X, but will switch away from it to another virtual console
[23:18] <knowmad> ah, of course..
[23:19] <knowmad> and indeed it works fine from outside chroot environment on the same workstation
[23:20] <knowmad> it's kinda funny; i get the graphic image flashing onto the screen then disappearing
[23:21] <knowmad> well, it's time to call it quits for now; i may jump back on later if i make any headway on this issue; thanks for all the help!