[00:07] <timothywcrane> is there anyone in here who can upload Sauerbraten fixes? No updates without the fix, all have updates. Fix on launchpad board. I admit I am begging.
[00:13] <NCommander> RainCT, ping?
[00:13] <RainCT> NCommander: pong
[00:14] <NCommander> RainCT, if I roll the sauerbraten fixes, will you upload?
[00:16] <RainCT> NCommander: what changes are it?
[00:16] <NCommander> I'm looking for the patch now
[00:19] <NCommander> gtg
[00:20] <RainCT> NCommander: Doesn't he mean bug 252037, which has to be processed by a core dev?
[00:24] <RainCT> Laney: (it's on production now, with anchor)
[00:25] <RainCT> good night
[00:51] <slangasek> in a cdbs package, how can I ensure that reverse-patches is only ever called after make distclean in the clean target?
[00:51] <slangasek> google search seems to think that this is the default behavior for cdbs simple-patchsys
[00:52] <RAOF> I thought the default behaviour was to reverse-patches _before_ running the clean target.
[00:53] <slangasek> that's not what https://wiki.duckcorp.org/DebianPackagingTutorial/CDBS says, for instance; and it's not a sane default either way :P
[00:53] <slangasek> ah, behavior was changed in bug #387103
[00:54] <slangasek> great, so to support tarball-in-tarball, they've instead broken being able to patch build systems via simple-patchsys
[00:54]  * slangasek exudes nothing but love in the direction of simple-patchsys
[00:54] <StevenK> In the form of a rusty knife?
[00:55] <slangasek> StevenK: I was thinking "hepatitis C cultures", but ok
[00:55] <StevenK> Haha
[00:56] <StevenK> So, a rusty syringe
[00:56] <slangasek> heh, and there's a follow-up to that bug from pitti that was never acknowledged, awesome
[00:57] <slangasek> oh, there are also follow-ups from /me/ to that bug :)
[00:57] <StevenK> Hah
[00:58]  * slangasek considers unarchiving and reopening the bug
[00:58]  * slangasek also considers what the heck he's going to do in the short term to get libgweather working right
[01:00] <StevenK> slangasek: Ah, I was wondering.
[01:00] <slangasek> StevenK: yes, I'm not touching either cdbs or simple-patchsys by choice :-P
[01:06] <tbielawa> hello to all
[01:06]  * slangasek waves
[01:06] <tbielawa> :)
[01:14] <slangasek> makefile-clean:: apply-patches
[01:14] <slangasek> include /usr/share/cdbs/1/rules/simple-patchsys.mk
[01:14] <slangasek> clean::
[01:14] <slangasek>         make -f debian/rules cleanbuilddir
[01:14] <slangasek> CHEMICAL.  FIRE.

[01:15] <StevenK> Haha
[01:16] <slangasek> so to work around simple-patchsys brokenness, we do: unpatch; patch; distclean; unpatch
[01:16] <slangasek> \o/
[01:17] <StevenK> Ha
[01:17] <StevenK> Which poor CDBS maintainer is going to feel your wrath?
[01:17] <slangasek> do I really have to pick only one? ;)
[01:18]  * StevenK grins
[01:20] <slangasek> oh, hah; even better, bug #424080 was fixed with a change that eliminated the reason for the bug #387103 change
[01:22] <emgent> slangasek: the true fire is bug 255819
[01:22] <emgent> :)
[01:23] <StevenK> Ha!
[01:23] <slangasek> ... clever
[01:23] <slangasek> this is why I never install anything with "slack" in its name
[01:23] <emgent> hahaha
[01:23] <emgent> old Legend.. Devian Vs Slackware
[01:24] <emgent> s/Devian/Debian/
[01:40] <sharms> if I want to build a package for intrepid but the clean script will fail on hardy, is there a way to tell pbuilder to skip calling make clean?
[01:42] <RAOF> sharms: Build the source package in an Intrepid chroot?
[01:42] <sharms> I was hoping to just get away with a pdebuild command
[01:42] <sharms> some flag like --do-make-clean-in-pbuilder-chroot
[01:43] <RAOF> Hm... dpkg-buildpackage -nc doesn't run the clean target, IIRC.
[01:46] <slangasek> which can be used only in conjunction with -b or -B, yes
[01:48] <sharms> ah ha --use-pdebuild-internal
[01:49] <sharms> ++to pbuilder docs
[01:56] <slangasek> RAOF: so, you probably work with cdbs more than I do; aside from the tarball case, is there any reason why one would be /expecting/ reverse-patches to be run before clean?
[01:56] <slangasek> (before I go patching this behavior away)
[02:02] <greg-g> I have a build question for someone.  I requested a sync for a lib (liblicense) and LP shows that it has been successfully built for Intrepid, but when clicking on the link under "resulting binaries" gives me a 404
[02:02] <greg-g> https://edge.launchpad.net/ubuntu/+source/liblicense/0.8-1/+build/686396
[02:03] <greg-g> is there something I am missing?
[02:07] <vorian> greg-g: which binary arch?
[02:08] <greg-g> 386
[02:08] <vorian> drats, irssi fail
[02:08] <vorian> i see it greg-g
[02:09] <vorian> clear your cache maybe?
[02:09] <greg-g> vorian: from here?  https://edge.launchpad.net/ubuntu/intrepid/i386/liblicense3/0.8-1
[02:10] <vorian> yes
[02:10] <greg-g> hmmm
[02:10] <vorian> greg-g: pm me your email, i'll send you the build log
[02:19] <RAOF> slangasek: It seems to be the most common behaviour when using debhelper? (the clean: target often depends on unpatch).  I can't think of a technical reason why you'd want that behaviour, though.
[02:23] <slangasek> RAOF: well, you want clean: to depend on unpatch because 'clean' is the policy-mandated target :)
[02:23] <slangasek> and in the debhelper case, unpatch is often done before make distclean because you're writing the rules by hand, and you generally aren't patching the build system so don't run into problems doing it this way
[02:24] <slangasek> and it's the simpler way to do it
[02:24] <slangasek> but cdbs needs to handle the not-simple cases...
[02:28] <RAOF> Right.  clean: obviously has to do the unpatching, and in simple cases that's most easily handled by making it a dependency of clean:.  I don't think anyone would _depend_ on that behaviour, though.
[02:33] <slangasek> RAOF: alrighty, well, patch committed to bzr, and bug being filed upstream :)
[03:12] <sn9> would putting the kqemu in intrepid into hardy be a backport, or an SRU?
[03:15] <RAOF> Almost certainly a backport, but it depends on why you'd be putting it in Hardy.
[03:15] <sn9> the version is unchanged, except for the -ubuntu1 suffix
[03:15] <sn9> it closes 6 launchpad bugs or so
[03:17] <RAOF> So there are a bunch of patches applied?  That could be SRU worthy (but would probably be sru'd as a bunch of patches against Hardy's kqemu, not by copying Intrepid's source package).
[03:18] <sn9> intrepid's source pkg _is_ a bunch of patches against hardy's kqemu
[03:19] <sn9> at least at this point
[03:21] <sn9> the only changes at all are to fix the packaging peculiarities inherited from debian
[03:25] <sn9> RAOF: i imported the intrepid source pkg unchanged into my ppa, but with a hardy target, and installed it from there. works perfectly
[03:25] <slangasek> erm, no, the changes are implementing new features
[03:25] <slangasek> * Adding DKMS support
[03:26] <sn9> that's what closes some of the launchpad bugs
[03:26] <slangasek> which is fine, but I wouldn't expect that to pass muster for an SRU
[03:27] <RAOF> Yeah.  Adding DKMS support is hardly going to fix any regressions :)
[03:27] <RAOF> Looks like you'll want to backport it.
[03:28] <sn9> ok, i'll file against hardy-backports. since i've already tested it, it's got a head start anyway
[03:33] <sn9> ubottu: bug 255909
[03:38] <sn9> seems to me, that request can probably go directly to "Triaged" state, right?
[03:49] <lifeless> are we debian-sync frozen yet ?
[03:50] <RAOF> lifeless: Autosync is off, yes.
[03:50] <persia_> lifeless: In an automated fashion, yes.  Of course, if you've a good reason, manual sync is accepted
[03:50] <lifeless> new package
[03:51] <sn9> RAOF: "Triaged" is ok in this case, right?
[03:51] <lifeless> antlr3 if you are curious
[03:51] <lifeless> I'm just paging in process
[03:51] <RAOF> sn9: I don't think you've got the two required "it works" confirmations for the "triaged" state; but see the Backports documentation.
[03:52] <persia> lifeless: Deadline for new packages is FeatureFreeze (August 28th).  On the other hand, you have to acually want the new package now, as opposed to it being automatically pushed.
[03:52] <sn9> RAOF: oh, it needs two? "Confirmed" then?
[03:52] <RAOF> !backports > sn9
[03:52] <RAOF> I'm not sure what the correct status is; but backports use the statuses to mean specific things.  See the doucmentation.
[03:53] <sn9> i did -- that's why i said "Triaged"
[03:53] <RAOF> Hm.  Then ignore me :)
[03:53] <sn9> slangasek: should i ignore RAOF? :)
[03:54] <RAOF> That documentation is authoratative; my memory of it is not :)
[03:54] <lifeless> hmm, its already in intrepid, now that I get around to checking all my facts
[03:54] <lifeless> so its really easy to sync :>
[03:54] <lifeless> (as in not-needed)
[03:55] <persia> lifeless: rmadison is your friend :)
[03:55] <lifeless> persia: yes, but its so damn slow
[03:56] <sn9> RAOF: hmm, seems one needs to be an admin to set "Triaged"
[03:59] <lifeless> $ time rmadison  antlr3
[03:59] <lifeless> real    0m3.193s
[03:59] <lifeless> $ time apt-cache madison
[03:59] <lifeless> real    0m0.027s
[03:59] <persia> Yes, but that only covers your local apt-cache: not so ideal if you're running hardy.
[04:00] <lifeless> persia: huh? just add all suites you want to sources.list as deb-src
[04:01] <lifeless> $ time apt-cache madison antlr3
[04:01] <lifeless>     antlr3 | 3.0.1+dfsg-2 | http://archive.ubuntu.com intrepid/universe Sources
[04:01] <lifeless>     antlr3 | 3.0.1+dfsg-2 | http://ftp.au.debian.org sid/main Sources
[04:01] <lifeless> real    0m0.519s
[04:02] <persia> lifeless: I suppose, although that can be confusing with trivial use of apt-get source if there is unexpected version skew.
[04:03] <persia> (and yes, there are ways around that too)
[04:03] <lifeless> like putting your distro's version at the top of sources.list :P
[04:04] <persia> Well, no, that's insufficient.  If the versions are the same, it will pull from the top, but if a lower entry has a newer version, it will pull that instead unless you set priorities for the sources.
[04:05] <persia> This distinction is unlikely to be important for intrepid, but can be useful if e.g. Debian has a new upstream version and we want to backport some of the fixes to fix our bugs without pulling the new upstream version.
[04:05] <lifeless> oh hmm
[04:05] <lifeless> anyhow, yes - but I know to look closely :P
[04:05] <persia> So, yes, you can set priorities for the sources, and put them all in sources.list, and everything does the right thing (plus you can specify *which* version you want when you pull, which is nice for SRUs).
[04:05] <lifeless> and often do want to grab newer versions, e.g. to see if a backport will play nice
[04:06] <persia> On the other hand, I tend to have chroots for each distrorelease I may want, and just call apt-get source foo there to get the right data (without looking closely).  With that workflow, rmadison is more informative (although it does take a few seconds).
[04:07] <persia> lifeless: Sure.  It entirely depends on one's workflow.  If one tends to be focused on a small number of packages, my model is far too much overhead.
[04:08] <lifeless> persia: I have chroots too
[04:08] <lifeless> but they are on my home server which is fairly regularly ETOOFAR
[04:09] <persia> Right.  I've 16 entries from schroot -l on my laptop, and more on my workstation.  Like I said, perhaps too much overhead.
[04:28] <kostmo> Hey all, I've put some more work into my pyrocket package - was wondering if any MOTU's are around to advocate? http://revu.ubuntuwire.com/details.py?upid=3240
[04:43] <kostmo> Is anyone on this channel so late?
[04:43] <NCommander> kostmo, I am, but I'm not an MOTU
[04:43] <NCommander> Just a REVU admin
[04:44] <kostmo> any suggestions on the right time of day to find a MOTU here?
[04:44] <persia> kostmo: It's not late for everyone :p
[04:44] <persia> MOTU are here all day, every day.
[04:45] <persia> (There are MOTU from UTC+11 through UTC-7 currently, and more timezones would be welcome)
[04:45] <kostmo> i c
[04:46] <persia> Which reminds me: MOTU Meeting in 15 minutes in #ubuntu-meeting !!!
[04:46] <nxvl> i would say that the channel is more active while i'm sleeping (on europe work tine)
[04:46] <kostmo> can I pitch my package at the motu meeting? :)
[04:46] <persia> kostmo: Please don't.
[04:46] <nxvl> persia: i almost forgot it!
[04:47] <Hobbsee>  oh noes!  a meeting!
[04:47] <kostmo> sure
[04:47] <kostmo> I guess I'm having a difficult time finding interested MOTUs - my package serves a pretty niche function
[04:48] <persia> kostmo: What does your package do?  Why is it cool?  Why should it be included in Ubuntu?
[04:49] <Hobbsee> kostmo: most people find that, i think...
[04:49] <kostmo> My package "pyrocket" is a driver for several of the USB rocket launchers that you might find on ThinkGeek or other novelty shops
[04:50] <nxvl> heh
[04:50] <nxvl> geek toys
[04:50] <kostmo> It exposes a few features of the devices that aren't accessible from the Windows drivers
[04:50] <StevenK> Haha
[04:51] <StevenK> kostmo: Such as? :-)
[04:51] <nxvl> kostmo: persia is a toy lover, but only if can get it out of his pockets and people would say "ooohhhhh!!!"
[04:51] <nxvl> persia: don't you?
[04:51] <StevenK> Bwahaha
[04:52] <persia> I'd definitely be interested in such a device, and *very* interested in the driver.  Unfortunately, I've not seen any of the cube-warfare class of stuff in local shops.
[04:52] <nxvl> i forgot how HORRIBLE gentoo was
[04:52]  * nxvl rm -rf vm
[04:52] <NCommander> nxvl, why are you running gentoo O_o?
[04:52] <kostmo> For example, on one of the Dream Cheeky launchers, my program allows super fine control of the aiming mechanism, where the bundled Windows application only allows rough positioning
[04:52] <nxvl> NCommander: just for vm fun
[04:53] <kostmo> and I have a webcam interface that's begging for some augmentation with computer vision
[04:53] <NCommander> nxvl, ugh, BTW< the comment about persia's toy will forever be etched into my mind. Just like COBOL77, and brainfuck (also goes by the names MIPS assembler, and dak)
[04:53] <kostmo> to auto-track your missile targets
[04:54] <persia> NCommander: See, if you'd actually seen my smallest laptop, it wouldn't be so disturbing :)
[04:54] <persia> (Sharp 922SH)
[04:54] <nxvl> heh
[04:54]  * nxvl love's persia's laptop
[04:54] <NCommander> persia, my mental image of you now involves a trenchcoat, a hat, and ...
[04:54] <NCommander> ugh
[04:54]  * NCommander twichs
[04:54]  * persia a
[04:55]  * NCommander hides from persia 
[04:55]  * persia has the trenchcoat and the hat, even the special trenchcoat liner with extra pockets
[04:55] <NCommander> Speaking of which, persia , you need to merge your REVU accounts
[04:55] <nxvl> he doesn't use any case or backpack or nothing, just his belt
[04:55] <persia> NCommander: Why?  I already have too high a number in statistics.
[04:55] <NCommander> persia, I guess you don't miss your reviewer status ;-)
[04:55] <persia> nxvl: I don't wear a belt: pockets always win
[04:56] <kostmo> persia, as an advocate, I suppose you would want to be able to run the program with the device yourself?
[04:56] <nxvl> heh
[04:56] <nxvl> ok
[04:56] <persia> NCommander: I'm an admin: I fixed that with a sledgehammer when I discovered it.
[04:56] <nxvl> s/belt/where the belt should be/
[04:56] <nxvl> persia: better?
[04:56] <NCommander> without context, this conversation would probably persia on some of those predator watch lists
[04:56]  * NCommander unfixes it, and then modifies REVU's code to reject alter_user.py -n persia ;-)
[04:57]  * persia wants the sledgehammer back
[04:57]  * NCommander uses it on persia
[04:57] <NCommander> Unless of course you vote yes to me becoming a contributator developer so I can get the shiny @ubuntu.com email
[04:57] <kostmo> I was wondering if maybe I should post a video on youtube of pyrocket in action, since not a lot of MOTU's probably have the hardware themselves
[04:58]  * persia is amused to note that earthquakes sound like thunder when one is sufficiently close
[04:58] <persia> Anyway, #ubuntu-meeting is the place to be ...
[04:58]  * NCommander thinks persia should go AFK, earthwake
[04:59] <NCommander> persia, when's the next motu meeting?
[04:59] <persia> NCommander: Now.
[04:59] <NCommander> wow
[04:59] <NCommander> Amazing timing I choose to bitch at the right time :-)
[04:59] <nxvl> ScottK: did you get change to review the merge?
[05:00] <kostmo> StevenK, are you a MOTU?  I could go into more enticing details about pyrocket if it would generate interest
[05:00] <nxvl> kostmo: is pyrocket in revu?
[05:00] <LaserJock> ScottK: you around?
[05:01] <kostmo> yup: http://revu.ubuntuwire.com/details.py?upid=3240
[05:01] <ScottK> nxvl: Patch failed for me again.  Only a little.
[05:01] <ScottK> LaserJock: Barely.
[05:01] <nxvl> ScottK: on patching?
[05:02] <LaserJock> ScottK: nvm then, I've got some questions about matplotlib (maintained by python-modules-team)
[05:02] <kostmo> btw, I just added support recently for another model - the Striker II USB Laser Guided Missile Launcher
[05:02] <ScottK> LaserJock: OK.  How about tomorrow.
[05:02] <LaserJock> ScottK: I can ask another day if you're busy/tired
[05:02] <LaserJock> ScottK: np
[05:03] <kostmo> the rockets for Striker II are pretty lame, but at least you get a pan/tilt USB laser pointer
[05:03] <StevenK> C
[05:03] <StevenK> Bah
[05:04] <StevenK> Call me when some Patriot Missle Systems get USB connectivity.
[05:05] <kostmo> They just had one of these launchers on woot.com
[05:05] <kostmo> and one guy was asking if they work on linux: http://www.woot.com/Forums/ViewPost.aspx?PostID=2327015&PageIndex=1&ReplyCount=47#post2327044
[05:06] <kostmo> and yes, they do - but they need my package
[05:06] <nxvl> kostmo: the pachage has a needs-packaging bug on LP?
[05:07] <kostmo> nxvl: yes, here: https://bugs.launchpad.net/ubuntu/+bug/242910
[05:09] <kostmo> even though they're kind of random toys, I think having support for them in Linux is a positive thing for linux adoption in general
[05:10] <kostmo> StevenK, I do have plans in the next release for automatic tracking of targets, if that counts
[05:10] <kostmo> not quite a Patriot missile, but a step in the right direction
[05:11] <tgm4883_laptop> Maybe a dumb question, but when doing get-orig-source, should the tar end up the same name as the package name that i'm aiming for in the repo?
[05:11] <kostmo> This guy has a webcam built into it, if you haven't seen it before: http://dreamcheeky.com/index.php?pagename=product&pid=41
[05:16] <persia> tgm4883_laptop: It should be $(package-name)_$(version).orig.tar.gz
[05:17] <tgm4883_laptop> persia, right, so for instance, if I was making mythstream-parser-youtube and the downloaded tar was just named youtube4.tar.gz I would want it to end up as mythstream-parser-youtube_4.orig.tar.gz
[05:18]  * SolarWar is looking for advocates (http://revu.ubuntuwire.com/details.py?package=qlix) Its a package of an (awesome) GUI application that allows users to sync music to Zunes and other MTP devices 
[05:18] <persia> tgm4883_laptop: Right.  Note that if you don't need to mangle the tarball manually, uscan will create a symlink for you.
[05:19] <tgm4883_laptop> persia, awesome, thanks
[05:24] <kostmo> I'm wondering if I would need to find a MOTU with USB rocket launcher hardware in order to advocate pyrocket?
[05:33] <SolarWar> kostmo, i don't think advocators care about whether the software works, just that the packaging adheres to standards
[05:34] <persia> SolarWar: Well, it's supposed to be both, although testing is typically minor.
[05:35] <SolarWar> i see
[05:35] <emgent> moin
[05:35] <slangasek> I'm trying to decide whether SolarWar is trolling me
[05:35] <SolarWar> hrm?
[05:36] <slangasek> SolarWar: "advocators don't care if the software works" :)
[05:36] <kostmo> actually I was wondering what degree of responsibility MOTU's do have for the functionality of the package
[05:36] <SolarWar> slangasek, did you mention something to contrary earlier? I was afk for a bit
[05:36] <SolarWar> :)
[05:37] <SolarWar> slangasek, i think it would be fairly difficult to test packages that require certain hardware, whether its rocket launchers or MTP devices
[05:37] <slangasek> SolarWar: no, I didn't; I'm just musing to myself whether you're trolling, since I'm predisposed to flying into a rage at people who don't take responsibility for the quality of packages that they upload :)
[05:38] <persia> SolarWar: Generally we like to have at least one good test report from a MOTU, or several good test reports from non-MOTU.
[05:38] <persia> In the case of awkward hardware, there is sometimes a call for testers (one example would be a new DVB app in hardy)
[05:39] <kostmo> is it appropriate to post requests for MOTU advocates or testers on the motu mailing list?
[05:39] <persia> kostmo: We prefer not for advocates.  If you've one advocate on the packaging, and can't find a tester, that would be appropriate.
[05:39] <SolarWar> slangasek, I didn't know that about your personality :) good to know- by quality of packages you don't mean the packaging itself, but the upstream software right?
[05:40] <slangasek> SolarWar: I mean that the package as a cohesive whole should be usable... :)
[05:40] <slangasek> (and integrate well with the system)
[05:40] <SolarWar> (also- i didn't mean to troll, no one who has commented on my package has said anything about well the upstream program works, but i welcome bugreports since i'm the author!)
[05:40] <SolarWar> persia, oh, okay- that sounds fair
[05:41] <kostmo> so there's the whole "polling" vs. "interrupt" thing that contrasts IRC with the mailing list
[05:41] <kostmo> it can be quite a time investment to troll for interested MOTUs
[05:42] <kostmo> and I mean "troll" in a good way
[05:43] <kostmo> I feel like to catch the attention of someone that might be interested, I would want to repost the same info on IRC at some frequency
[05:43] <persia> kostmo: Indeed.  The optimum frequency is about every 30 hours, to both hit MOTU in all timezones, and not get below 24 hours (which makes some people refuse to review).
[05:44] <persia> It's less bad when we have organised REVU Days, but this cycle we've not been very good about organising those.
[05:44]  * SolarWar has been yelled at for pitching Qlix 
[05:44] <SolarWar> too often.
[05:44] <kostmo> \me is glad he is not SolarWar
[05:44]  * kostmo is a bit new to irc
[05:44] <SolarWar> i *like* being me
[05:45] <persia> Each person does best being themselves, and we are each that because of our interactions with each of the rest of us.  Ubuntu.
[05:45] <kostmo> nice.
[05:51] <beuno> so, I keep on getting: W: bzr-upload source: native-package-with-dash-version
[05:51] <beuno> and I can't quite put my finger on what I'm doing wrong
[05:51] <beuno> any ideas?
[05:52] <slangasek> is the .orig.tar.gz file missing from your parent directory?
[05:52] <slangasek> (or misnamed)
[05:53] <beuno> it's there. It may be misnamed.  It should be the exact name as the parent dir?
[05:54] <emgent> moin warp10
[05:55] <warp10> hi emgent
[05:58] <beuno> slangasek, solved it, thanks  (permissions issues)
[06:00] <xnevermore> When updating a packaging for a new upstream version, what do I do with the debian patches that are in the previous version package?
[06:02] <persia> xnevermore: Review them.  Apply those that are still required, or fix useful bugs.  Drop those that are adopted upstream or rendered irrelevant by upstream changes.
[06:05] <kostmo> I have a question about package maintenance: I know that getting a package initially accepted into Universe requires 2 MOTU advocates.  Once that package is accepted, if the Upstream author releases a new version, how does the repackaged version get accepted back into Universe?
[06:05] <kostmo> is it 2 motu's each time?
[06:05] <RAOF> No.
[06:05] <persia> Someone files a bug asking for a new version, and attaches the updated diff.gz.  That requires one MOTU to sponsor the new version.
[06:05] <StevenK> kostmo: Nope, just ask for sponsorship
[06:06] <kostmo> ok, thanks
[06:07] <persia> Mind you, the testing requirement for new upstreams is usually more strictly enforced, so for a rocket launcher, your choices may be more limited.
[06:08] <kostmo> persia, which choices do you mean?
[06:08] <persia> kostmo: choices for sponsors
[06:09] <TomJaeger> Are there any MOTUs around that would be willing to review my awesome gesture recognition application?
[06:09] <TomJaeger> It's very well-received, see http://ubuntuforums.org/showthread.php?t=837032
[06:10] <persia> TomJaeger: The URL to the app is likely a more powerful incentive than the URL to comments about it :)
[06:10] <persia> Also, there's a MOTU Meeting on now, so few people are likely to review.
[06:11] <kostmo> I was especially curious about the sponsorship requirements - because I'm wearing both hats - as the upstream developer and the packager - I have some really cool computer vision stuff in the works for "pyrocket", but I'm trying to decide whether it would be best to get it into the initial version, or a later release
[06:12] <TomJaeger> Sorry, didn't know about the meeting.
[06:13] <TomJaeger> Anyway, the website of the app: http://easystroke.wiki.sourceforge.net/#content
[06:13] <persia> TomJaeger: And the REVU link?
[06:13] <kostmo> persia, your suggestion to TomJaeger brings a question to mind for me - would polling Ubuntu Forums for user interest in "pyrocket" make a persuasive argument for MOTU advocacy?
[06:14] <persia> kostmo: Not pursuasive, although it may help with the testing requirement if no MOTU has the hardware.
[06:14] <TomJaeger> It's on top of this list: http://revu.ubuntuwire.com/details.py?package=easystroke
[06:14] <persia> There you go :)  Now anyone who isn't busy in the meeting can get to a place to do the review with one click.
[06:14] <kostmo> so MOTU's are unswayed by the din of the masses
[06:18] <ajmitch> kostmo: I've heard they're more easily swayed by bribes
[06:19] <kostmo> I have some high quality USB rocket launchers...
[06:20]  * kostmo is off to code up a sweet rocket launcher demo to win MOTU favor
[06:22] <dholbach> good morning
[06:31] <xnevermore> if I have to alter a dpatch, should I rename it? what other changes do I have to make?
[06:32] <ScottK> xnevermore: No.  Just document that you've changed it in debian/changelog
[06:32] <xnevermore> ScottK: do I add a credit to myself in the patch itself?
[06:33] <ScottK> It's a judgement call.  For a minor change I wouldn't.
[06:33] <xnevermore> alright. fair enough. thanks
[06:37] <TomJaeger> persia, your comment still puzzles me.  If I can demonstrate that users like my application and that I stand behind it and listen to my user's concerns, surely that's more important than having a shiny homepage? (Which frankly, I don't because I'd rather spend my time improving the software than with marketing)
[06:37] <dholbach> hiya nxvl :)
[06:37] <persia> TomJaeger: Not the homepage: the REVU page.  Having a quick click to review tends to make reviewers more likely to actually perform the review.
[06:37] <persia> It's not about the application homepage.
[06:38] <nxvl> dholbach: :D
[06:38] <persia> Many reviewers will look at an application on it's own merits, rather than looking for a strong userbase, so the interested users may not matter to the reviewer, as long as the application is good and the packaging is done right.
[06:38] <TomJaeger> well I'd already posted the REVU link a million times, that never accomplished anything
[06:39] <nxvl> dholbach: time for GBJ is reaching
[06:39] <nxvl> actually we are on GBJ time NOW
[06:39] <dholbach> yeah and I look forward to it :)
[06:39] <dholbach> I'm going to mail all organisers in a bit
[06:40] <nxvl> i'm very excited about that, i have just been noticed that the Gnome dev, the debian deb, the OOo guy and the kde contributor are going to be there!
[06:40] <nxvl> it's awesome
[06:41] <slangasek> "the" Gnome dev?
[06:41] <StevenK> Isn't that Vincent?
[06:41]  * StevenK hides
[06:41] <dholbach> slangasek: you know... the guy who wrote GNOME
[06:41] <nxvl> heh
[06:41] <StevenK> The guy who started it doesn't work on it any more
[06:41] <nxvl> the peruvian gnome dev
[06:41] <slangasek> oh, we're talking about Peru :)
[06:42] <nxvl> we have one on each project
[06:42] <nxvl> one in ubuntu, actually 2 now
[06:42] <nxvl> one in debian (actually 2 now counting myself)
[06:42] <nxvl> one in gnome
[06:42] <slangasek> so "the Debian dev" == Rudy Godoy?
[06:42] <nxvl> one in KDE, and one in OOo
[06:43] <nxvl> yup
[06:44] <slangasek> ah, well, say hi to him for me then. :)
[06:44] <nxvl> i will!
[06:44] <nxvl> he's a good friend of mine
[06:44] <nxvl> the FOSS community in peru is really close and small
[06:46] <nxvl> slangasek: are you busy or have some time to review a package update?
[06:46] <slangasek> nxvl: I'm busy trying and failing to detach myself from the computer so I can sleep
[06:46] <nxvl> heh
[06:46] <nxvl> :D
[06:46] <nxvl> i'm on the same problem
[06:46] <nxvl> :D
[06:47] <nxvl> but my packages are waiting for me
[06:47] <nxvl> i've just noticed that augeas released a new version
[06:48] <TomJaeger> persia, I'd be happy if I had gotten MOTUs interested on "the app's own merit", but that hasn't been the case, so what was I supposed to do?  It seems to me that you don't have the manpower to review every package, so I felt it might be helpful to tout the app a little bit, rather than just being annoying.
[06:48] <ScottK> persia: Explain.
[06:48] <NCommander> persia, yup
[06:49] <persia> TomJaeger: Understood.  This cycle has been incredibly poor for REVU.  At the recent MOTU Meeting, we've had a couple people who might help get REVU working smoothly again, which may help you.
[06:50] <persia> So, to provide context: I was asked " What do you think about individual maintainers for packages not in Debian.", to which I said I was very strongly against it.
[06:50] <nxvl> agreed
[06:50] <nxvl> we don't work that way
[06:50] <persia> The reasoning for this is that I think we operate best as a team, and one of my favorite things about Ubuntu Development is that we work collaboratively.
[06:50] <NCommander> But we do have packages that have a Maintainer (@ubuntu.com)
[06:51] <ScottK> Sure.  It's allowed.
[06:51] <NCommander> But that doesnt't stop NMUs here
[06:51] <persia> That said, I've nothing against smaller teams declaring support for a set of packages, but that's different.
[06:51] <persia> NCommander: Yes, but I don't like that anyway (and we don't even acknowledge the concept of NMU usually)
[06:51] <persia> Note that there is value to having packages specifically maintained.
[06:51] <NCommander> I personally don't have an issue with individual maintainers as long as anyone form the MOTU team can update a package
[06:52] <persia> I think that is best expressed in Ubuntu by subscribing to the package in LP, filing regular update bugs, and working with upstream (documenting this in the bugs),
[06:52] <persia> If someone is doing a good job of this, others are likely to leave them to it.
[06:52] <NCommander> So why not mark the maintainer then?
[06:52] <NCommander> Since that's essentially what they are doing
[06:52] <persia> Further, if someone has demonstrated expertise in a package or set of packages, others are likely to point to them when an opinion is sought.
[06:53] <nxvl> NCommander: yes, you can use the maintainer field with your name, but NMU are allowed and don't need special versioning
[06:53] <NCommander> Right
[06:53] <persia> NCommander: Because I simply don't see *any* value in marking the maintainer: what is the point?
[06:53] <nxvl> and people are free to change the maintainer field if they feel like
[06:53] <NCommander> By having your name in the Maintainer field, it makes it offical your the first person you go to support, and who handles it
[06:53] <ScottK> persia: My use case is if you want your package in Ubuntu, you have to volunteer to maintain it.
[06:53] <persia> NCommander: Except that we delete that information from all binary packages.
[06:54] <persia> ScottK: I don't agree with that: I'd rather have things get in because people are interested, and get dropped if they cannot be maintained.
[06:54] <NCommander> let me rephrase
[06:54] <slangasek> persia: well, the possible advantage I see is having a way to flag that a package has ended up de-facto orphaned
[06:54] <nxvl> ScottK: yes, but it doesn't stop the community to work on your package
[06:54] <persia> slangasek: We have that: http://qa.ubuntuwire.com/uehs/
[06:55] <persia> It's a rare case that anything appears on UEHS for long if it isn't orphaned (and yes, that includes packages orphaned in Debian)
[06:55] <nxvl> ScottK: i have some package with my name in the Maintainer field, but i won't get mad if for example you touch it without asking me first
[06:55] <ScottK> Agreed.
[06:55] <NCommander> where do the meeting logs go to?
[06:55] <persia> nxvl: But someone might.  I don't like the possibility because it may be misinterpreted.
[06:55] <slangasek> persia: what am I supposed to see here?
[06:55] <slangasek> the "not in sync with upstream" bit?
[06:55] <ScottK> It's just a question if you aren't willing to sign up to mind the package, why should I be troubled to upload it.
[06:55] <persia> NCommander: irclogs.ubuntu.com
[06:55] <StevenK> Into the depths of mootbot
[06:55] <nxvl> persia: agreed
[06:56] <nxvl> persia: but the only thing we can make against it, is specifically say that on a policy or something
[06:56] <persia> slangasek: Any of the classes: those with no watch file, those not in sync, or those with no upstream checkable.  Note that there are some false posivites in the first and third case, but not so many.
[06:56] <persia> nxvl: Which means more policy, which I don't like.  More policy raises the bar to participation.
[06:57] <slangasek> persia: well, it's the false-negatives that concern me
[06:57] <nxvl> mmm
[06:57] <persia> slangasek: Packages that appear maintained and aren't?
[06:57] <nxvl> true
[06:57] <ScottK> persia: Barriers to useless cruft in the archive are no bug.
[06:57] <slangasek> persia: suppose someone is an upstream, gets their package sponsored into universe, then disappears
[06:57] <slangasek> it won't stop being in sync with upstream, but that doesn't mean it's being "maintained" in any useful sese
[06:57] <persia> ScottK: I don't see it that way at all: not much of what comes through REVU is best classed as "useless cruft", and anything removed in Debian is auto-removed from Ubuntu.
[06:57] <slangasek> sense
[06:58] <persia> slangasek: I guess, but is it broken?
[06:58] <slangasek> well, but ScottK was specifically raising the point of packages that are added to Ubuntu by someone that aren't present in Debian
[06:58] <StevenK> Actually, I have something that wasn't
[06:58] <nxvl> persia: but the only case in which i think someone can get mad is while having a strong debian concept in mind
[06:58] <slangasek> so there's no guarantee that there's anyone /anywhere/ maintaining this package
[06:58] <slangasek> s/package/software/
[06:58] <persia> nxvl: As we encourage people to read Debian documentation, that's not at all unlikely.
[06:58] <nxvl> mmm
[06:58] <StevenK> Compare 'rmadison -u debian twin' and 'rmadison twin'
[06:58] <nxvl> true
[06:59]  * nxvl stops talking
[06:59] <nxvl> :D
[06:59] <persia> slangasek: Sure, but maybe it's not broken.  I think broken-ness is better tracked by bugs than by some random string somewhere
[06:59] <persia> Note that plenty of packages come from Debian, have "maintainers", but are pointlessly broken and nobody is watching them.
[06:59] <slangasek> (fwiw, I'm not convinced that ScottK's is the right solution to this problem, because I'm concerned that once you apply the "maintainer" label you'll trend toward having package unhealthy package feifdoms, which we've consciously tried to avoid)
[07:00] <nxvl> persia: but either we need a policy saying a) we don't accept maintainers b) maintainers are allowed, but anyone can touch the package
[07:00] <persia> That might not even be the assigned maintainer's fault: if I use gnue as an example, upstream became messy and incompatible, and the maintainer would have had a hard time keeping the package in shape even if he was so inclined.
[07:00] <ScottK> slangasek: I'm not either, but I'm fresh out of ideas to avoid drive bys
[07:00] <nxvl> i don't see more alternatives
[07:00] <persia> nxvl: That's a contradiction.  I want to stop with "We don't accept maintainers".
[07:01] <persia> ScottK: I don't mind drive-bys.
[07:01] <persia> I've had a few packages that were drive-by, but I used them, and I updated them for another cycle.
[07:01] <nxvl> persia: then i'm lost, what's your point
[07:01] <ScottK> persia: I think that's the source of a lot of the Ubuntu only stuff.
[07:01] <persia> I don't want to promise to maintain them, but I like them being around.
[07:02] <persia> nxvl: That I'm against the idea of having an individual "Maintainer" set in debian/control for uploads to Ubutu.
[07:02] <ScottK> persia: It's currently allowed.
[07:02] <nxvl> that's what i meant (or tried to) with a) we don't accept maintainers
[07:02] <slangasek> persia: there's a non-zero chance that some of these packages are non-broken, yes; but I think there's also a higher than usual chance that they are, and I've personally never accepted the argument that Ubuntu (or Debian) should make all the software available that they can and let users alone decide what's useful or not, because there are central costs associated with doing that
[07:03] <persia> ScottK: Yes, but discouraged.  I'm not fussy enough to push policy stating it to be prohibited.
[07:03] <persia> slangasek: I'm not supporting the case that *everything* should be available, although certain dictators have expressed that view in the past.
[07:03] <nxvl> what i try to do is, when i have special interest on a package i try to get it in debian and maintain it there
[07:03] <nxvl> then ask for a sync into ubuntu
[07:03] <ScottK> I will confess that when I have to do an Ubuntu upload of a package I maintain in Debian, I don't change the maintainer.
[07:04] <persia> I just don't see any value to enforcing that a given application is maintained by an individual within Ubuntu.
[07:04] <ScottK> I'd get annoyed if I couldn't do that.
[07:04] <\sh> ScottK: we always had special cases where we never changed the maintainer
[07:04] <slangasek> ScottK: setting it up for the day when you can troll the Ubuntu mailing lists complaining that the maintainer field wasn't changed? ;)
[07:04] <persia> ScottK: That's technically a violation of the Debian-Maintainer-Field rule, but you're not alone in that, which is one of the reasons we're a little flexible on that rule when the actual Maintainer is involved.
[07:04] <nxvl> ScottK: same here
[07:05]  * slangasek notes that all the packages he maintains in Debian, /do/ have a changed maintainer field when uploaded to Ubuntu
[07:05] <slangasek> it helps that most of these are team-maintained in the first place :)
[07:06]  * persia would not complain if LP automagically X-SBC-Original-Maintainered everything on sync source import, as long as teams had a mechanism to declare maintenance.
[07:07] <\sh> but I agree with slangasek here...we should focus on packages which are used most in our usecases and drop cornercase stuff...which can save bandwidth, time, and resources...or we swamp da debian distro with NM-application in a short period of time
[07:08] <persia> I agree with that as well.
[07:08] <NCommander> persia, minutes and points of discussion went to the list
[07:08] <persia> I'd like to see less cruft.  I'm just very strongly of the opinion that setting "Maintainer" is not the right way to achieve this.
[07:08] <nxvl> i also don't like the maintainer idea since it can turn in the community saying "it's not our fault, it's $MAINTAINER's fault"
[07:08] <persia> Right, when it is *our* fault.
[07:08] <nxvl> persia: the thing there is that sync are untouched imports
[07:09] <nxvl> persia: so the maintainer is still responsable for it in one or other way
[07:09] <slangasek> persia: let me pose the question another way.  If a package has no upstream, no Debian or Ubuntu maintainer, and only users who would be better served by another package already in the archive, how do we go about detecting that this is cruft?
[07:09] <\sh> nxvl: that's already the normal way to go..."it's not ubuntus fault, na it's not even debians fault, it's fault of upstream, and it's not even upstreams fault, it's fault of the fingerpointed guy who pushed the patch in
[07:09] <persia> nxvl: Not at all.  Several Debian maintainers have expressed that they aren't, and that expression has been supported all members of our technical board.
[07:09] <slangasek> systematically, that is?
[07:09] <\sh> nxvl: that's wrong...source in debian != source in ubuntu regarding the different toolchains...
[07:10] <persia> slangasek: Systematically, I've no idea, but I do think that we've too many barriers to removal now.
[07:10] <\sh> better to say, the outcome of the source in both distros
[07:10] <nxvl> persia: if the maintairs have expressed it, i can't go against it
[07:10] <NCommander> Can someone sum what been discussed since I wrote the notes
[07:10] <NCommander> (and persia, your two cents on the issue)
[07:10] <persia> It took me *3* releases to get a broken game with questionable licensing removed when upstream had a name change.
[07:11] <slangasek> hmm, why so long?
[07:11] <NCommander> persia, in ubuntu or debian?
[07:11] <slangasek> why is the procedure more than "file bug, subscribe ubuntu-archive, watch it be removed"?
[07:11] <persia> slangasek: Not sure.  It kept getting bounced between archive admins, and generally ignored.
[07:11] <ScottK> I don't think it is.
[07:11] <slangasek> oh
[07:11] <persia> Finally I had someone poke one of the archive-admins at UDS and verbally abuse them until they removed it.
[07:12] <NCommander> persia, that's a break down of proceedure, but the policy itself is fine I think
[07:12] <persia> Also, that is the procedure, it's just not been well supported by archive-admins historically.
[07:12] <NCommander> ANd more of an exception then a rule
[07:12] <slangasek> persia: fwiw, from my perspective it helps if submitters are more assertive with setting bug statuses in cases like that
[07:12] <persia> NCommander: Well, it's been common historically.  We've had lots of trouble getting cruft removed despite support amoung MOTU.
[07:12] <NCommander> I dunno, removal requests are pretty rare, but when they do happen, they happen relatively fast
[07:13] <ScottK> Personally I've had great success with getting stuff removed.
[07:13] <NCommander> Hrm
[07:13] <persia> (and that's for identified cruft)
[07:13] <slangasek> persia: e.g., if another archive-admin has set the bug to 'incomplete', I'll skip over it in my weekly archive day
[07:13] <NCommander> Maybe we need a "Nominate for Removal" link in LP
[07:13] <slangasek> expecting it to come back to 'confirmed' before it's ready for me to act on
[07:13] <persia> slangasek: That makes sense.
[07:13] <NCommander> ScottK, same, and no problems with Debian (although there is usually a week lag time)
[07:13] <persia> ScottK: That's good to hear: I'm probably working off older assumptions.
[07:13] <ScottK> The biggest problem is getting people to look and file the removal bugs.
[07:14]  * NCommander agrees with ScottK 
[07:14] <ScottK> If someone want practice, go ask for removal of sylpheed-gtk1.
[07:14] <xnevermore> If a dpatch that was written for an old package version will not apply on a new one, what is the best way to edit that patch to make it work? or is it best to create a new one that does the same thing?
[07:14] <persia> Well, we've that problem for lots of classes of issues.
[07:14] <NCommander> What we need are guidelines for "cruft" and perpahs a set team which during frezes does extactly that
[07:14] <ScottK> xnevermore: dpatch-edit-patch.
[07:14] <NCommander> Go through universe/multiverse and weed out the junk
[07:14] <persia> xnevermore: Yes, although the old patch may well help inform how to achieve that.
[07:15] <persia> Actually, removals during freezes tend to be discouraged, unless there is a strong reason for removal.
[07:15] <NCommander> persia, let me rephrase
[07:15] <ScottK> Not a bad time to file the bugs though.
[07:15] <NCommander> THey go through during the freeze
[07:15] <NCommander> File removal requests
[07:15] <persia> No, and excellent time to file the bugs.
[07:15] <NCommander> ANd if no one protests and steps forward to update the package
[07:15] <NCommander> It goes after that release
[07:16] <ScottK> NCommander: We don't need to wait that long.
[07:16] <NCommander> (call it a time-delayed removal)
[07:16] <ScottK> No need.
[07:16] <ScottK> If something gets removed, you can always add it back in.
[07:16]  * NCommander nods
[07:17] <persia> Indeed, although the archive-admins tend to get overwhelmed with duties as release nears, and it may be that the removals aren't the highest priority (which is understandable)
[07:17] <NCommander> I still think having a strike force of people to do this would work wonders
[07:17] <persia> NCommander: Start one.
[07:17] <NCommander> persia, How?
[07:17] <ScottK> NCommander: Make a team on Launchpad.
[07:17] <ScottK> NCommander: Write to the MOTU ML asking for volunteers.
[07:17] <ScottK> NCommander: Get to work.
[07:17]  * NCommander creates ubuntu-cruft-busters :-)
[07:17] <NCommander> Unless someone has a better name
[07:17] <persia> NCommander: Make a team on LP.  Document the activities and responsibilities of team members, and post to ubuntu-motu for team members.
[07:18] <ScottK> persia is more process oriented than I am.
[07:18] <persia> Heh :)
[07:18]  * NCommander is extremely process oriented
[07:18] <ScottK> Note actually doing the work wasn't on his list.
[07:18] <persia> I think it's important to tell people for what they are signing on before asking them to join a team.
[07:18] <NCommander> The idea of having a team came from my ICS training
[07:18] <ScottK> Bah.  You get fewer volunteers that way.
[07:19] <NCommander> Any ideas a team name
[07:19] <NCommander> universe-cruft-busters, ubuntu-garbage-collection?
[07:19] <\sh> oh another team
[07:19] <persia> No, there's no reason that the person organising the team does the work, as long as the person organising the team is confirming that the work is being done in a timely manner.  I've no problem with meta-busyness
[07:19] <persia> ScottK: Yes, but you also have fewer people running away screaming when they find out what they are doing.
[07:19] <NCommander> I'll help get this project off the ground
[07:19] <nxvl> ScottK: but you are more complain oriented than persia
[07:19]  * nxvl hides
[07:20] <nxvl> :D
[07:20] <persia> NCommander: Note that if you don't want the overhead of a team, you could also just call for volunteers on the ML, and build the team if you later thought it helpful to have one (e.g. a ML)
[07:20] <ScottK> NCommander: My suggestion would be find the oldest version of GCC in the archive and see if anything that build-deps on it should stay.
[07:20] <NCommander> ScottK, GCC is all main
[07:20] <persia> Yes, GCC would be nice to kill.  Also, there's not a few libraries that have one source per version: porting to only have one version of the library would be a huge win.
[07:20] <ScottK> NCommander: Not the older ones
[07:21] <nxvl> NCommander: packages in univers can depend in main packages
[07:21] <NCommander> SO you two are voluteering to help, right?
[07:21] <ScottK> NCommander: In Hardy will killed off a gcc2 something package.
[07:21] <ScottK> NCommander: I'm volunteering to give advice and order you around.
[07:21] <NCommander> ScottK, you'd make a wonderful politician
[07:22] <ScottK> Nope.  Too honest.
[07:22] <nxvl> true
[07:22] <ScottK> A politician wouldn't tell you that, just do it.
[07:22] <nxvl> that's why we love ScottK
[07:22] <persia> NCommander: I'd be happy to help.  Note that my supply of tuits is rapidly reaching historical lows, so you may not find this as beneficial as you might assume.
[07:22] <NCommander> tuits?
[07:23] <ScottK> nxvl: Speaking of honesty: I reviewed your courier merge.  The story does not yet have a happy ending.
[07:23] <ScottK> NCommander: The round ones.
[07:23] <NCommander> I don't get it
[07:23] <nxvl> ScottK: the patch still doesn't apply, or it applies, but it's not in good shape?
[07:23] <NCommander> and ...
[07:23] <StevenK> NCommander: "round tuit"
[07:23] <StevenK> NCommander: Say it out loud
[07:23] <NCommander> Still don't get it
[07:23] <StevenK> Sound it out?
[07:24] <ScottK> nxvl: DIdn't apply, I decided to sort it out manually.  Merge is pretty good, but needs a little more work.
[07:24] <NCommander> too-it?
[07:24] <StevenK> NCommander: Now you're getting it
[07:24] <NCommander> ... *sigh*
[07:24] <NCommander> Anyone know where the make a team button on Launchpad is?
[07:24] <nxvl> ScottK: mm odd
[07:24] <nxvl> ScottK: i tested the patch in different sandboxes and have no problems with it
[07:25] <ScottK> NCommander: --> #launchpad - They have a whole team dedicated to ignoring questions.
[07:25] <nxvl> ScottK: let me upload the package to my ppa
[07:25] <ScottK> nxvl: No need.
[07:25] <NCommander> ScottK, damn it, you just made soda fly through my nose
[07:25] <ScottK> nxvl: I won't trust PPA code just now anyway.
[07:25] <nxvl> why?
[07:26] <ScottK> Unsigned repo + DNS Cache Poisoning.
[07:26] <nxvl> the sign thing
[07:26] <ScottK> Yep.
[07:26] <ScottK> I deleted all the packages out of PPAs I control.
[07:26] <nxvl> true
[07:26] <ScottK> nxvl: The problem was you bumped standards version to 3.8, but then didn't update the package to 3.8.
[07:27]  * persia questions the value of updating the standards version when updating packages except for ubuntu-local packages
[07:28] <nxvl> ScottK: i did that?
[07:28] <ScottK> persia: Generally I agree, but the actual maintainer standards version for courier is 3.5.6
[07:28] <ScottK> nxvl: That's what was in your diff.
[07:28] <nxvl> and didn't document it on the changelog
[07:29] <nxvl> i should confuse terminals
[07:29] <ScottK> Right.  Changelog still said 3.7.3
[07:29] <nxvl> working in a car in more that one package at the time is not the best to do
[07:29] <ScottK> nxvl: If you'd been a MOTU already and uploaded that, what would you do now?
[07:29] <persia> ScottK: Ah, yes, that hits the ancient-standards-version test :)
[07:30] <nxvl> ScottK: fix it
[07:30] <nxvl> :D
[07:30] <persia> nxvl: And how would you have known to fix it?
[07:30] <nxvl> updating it to 3.8.0
[07:30] <ScottK> persia: Actually until the last lintian upload 3.7.3 was classified as ancient.
[07:31]  * StevenK scoffs
[07:31] <NCommander> ScottK & persia: https://edge.launchpad.net/~ubuntu-cruft-busters
[07:31] <ScottK> Lintian had the nice feature of basing ancient standards on when a policy was issued, not when it was superceded.
[07:31] <persia> 3.7.3 shouldn't have been considered "ancient"!
[07:31] <ScottK> That was, I htink my second Lintian bug to get fix.
[07:31] <ScottK> persia: Agreed.  The test was logically flawed.
[07:32] <persia> ScottK: Indeed.  Thanks for sorting that.
[07:32] <StevenK> NCommander: s/universe and multiverse/the Ubuntu archive/
[07:32] <ScottK> I pointed out that under the test if policy didn't change for 2 years, the current policy would be ancient.
[07:32] <NCommander> StevenK, change maded
[07:32] <persia> Yeah: there's no reason not to cut cruft from main/restricted as well.
[07:32] <StevenK> NCommander: Approve my membership :-)
[07:32] <NCommander> Trying to figure out how ;-)
[07:32] <ScottK> If it has a cool badge, I'll join.
[07:32] <StevenK> Click links, I think
[07:32]  * StevenK hides
[07:33] <persia> NCommander: Click on the edit button from https://edge.launchpad.net/~ubuntu-cruft-busters/+members or wait for the email with the special approve link.
[07:33] <NCommander> I'm going to use a garbage can
[07:33] <NCommander> persia, yeah, just found it
[07:33]  * persia wants a garbage can
[07:33] <StevenK> Works for me
[07:33] <SolarWar> NCommander, whats your timezone?
[07:33] <nxvl> persia: actually i wouldn't
[07:33] <NCommander> Eastern Standard
[07:33] <NCommander> -5 UTC
[07:33] <NCommander> or a nice gun
[07:33] <StevenK> Garbage can
[07:34] <SolarWar> NCommander, does that make you EST?
[07:34]  * NCommander looks for the svg for the GNOME garbage gan
[07:34] <NCommander> SolarWar, yes
[07:34] <slangasek> persia: hrm, a disturbing thought that we would have left anything in main/restricted in such bad shape that it should go straight from there to archive removal
[07:34] <slangasek> (on a "cruft" basis, that is)
[07:34] <StevenK> slangasek: Cruft could be NBS
[07:34] <SolarWar> okay just checking, i've seen you active during normal hours, and now, on abnormal hours
[07:34] <SolarWar> :)
[07:34] <persia> slangasek: consider the case where something is required for main, but replaced, and ejected to universe: is it necessarily useful in universe at that time?
[07:34] <slangasek> StevenK: NBS is already dealt with by the archive admins
[07:34] <StevenK> In which case it does go straight from main to removed
[07:35] <ScottK> slangasek: KDE3 is going straight out the window as KDE4 replaces it.
[07:35] <NCommander> Anyone know where I can find the icon for the GNOME trash icon
[07:35] <NCommander> SolarWar, I have a sleep disorder
[07:35] <slangasek> ScottK: but we don't need a special group to /track/ that, do we?  The parties responsible for KDE4 are handling it?
[07:36] <persia>  /usr/share/icons/Human/scalable/places/user-trash.svg
[07:36] <ScottK> slangasek: True.  That's just an example.
[07:36] <persia> slangasek: Does it hurt to have a group that also does that?
[07:36] <ScottK> slangasek: I think we'd have been better off it that'd happened with serpentine.
[07:36] <persia> Yes, sepentine is an interesting example.
[07:36] <SolarWar> NCommander, is that a fact?
[07:36] <NCommander> SolarWar, chronic delayed sleep syndrome
[07:37]  * NCommander has a nice blue one, but this will work
[07:37] <slangasek> persia: no, I'm just thinking out loud that I find the prospect of main being in such a state disturbing
[07:37] <nxvl> ScottK: it seems to be 3.8.0 complaining or i'm to sleepy to notice the diferences now
[07:37] <persia> slangasek: It's rare, and usually "fixed" by tossing the relevant cruft into universe
[07:37] <persia> It's just that tossing it into universe isn't always the right solution.
[07:37] <slangasek> NCommander: is that accompanied by restless leg syndrome?
[07:37]  * nxvl will check tomorrow
[07:37] <ScottK> nxvl: I didn't see Homepage: was one thing I noticed.  I'm pretty sure you'll need README.source.
[07:38] <ScottK> OK.
[07:38] <NCommander> slangasek, Maybe, define the symptons
[07:38] <slangasek> NCommander: "your legs move"
[07:38] <NCommander> (my leg shakes a lot)
[07:38] <NCommander> then yes
[07:39] <slangasek> here, have some of these drugs that the nice man on the TV sold me
[07:39] <slangasek> they'll make your legs stop moving
[07:39] <StevenK> And probably the rest of you
[07:39] <persia> Let's call it "sleep".  Perhaps with fishes.
[07:39] <nxvl> mmm starting with the fact that i need to follow several checklists
[07:39] <NCommander> ScottK, StevenK persia, check your profile pages :-)
[07:40] <hagabaka> what's the difference between xorg-driver-fglrx and xorg-driver-fglrx-envy?
[07:40] <SolarWar> NCommander, that sucks :-/
[07:40] <persia> hagabaka: The source from which it was installed.
[07:40] <NCommander> Thanks
[07:41]  * NCommander will accept new icons
[07:41] <ScottK> Speaking of sleep ....
[07:41] <hagabaka> also what version of fglrx is packaged in hardy? i can't really tell from "7.1.0-8-6+2.6.24.502-502.30_i386"
[07:41]  * ScottK says good night again.
[07:41] <NCommander> sladen, trying to kill me with that junk ;-)?
[07:41] <\sh> ScottK: good night :)
[07:41]  * persia declares that fail2ban would appreciate a bunch of help, if anyone wants to look at a package for general updating.
[07:42] <NCommander> when did Ubuntu wiki add openid support?
[07:43] <nxvl> night all!
[07:43]  * NCommander makes a wiki page
[07:45] <SolarWar> ScottK, night night
[08:00] <jpds> NCommander: Some time ago, help.u.c has it too.
[08:00] <NCommander> jpds, ?
[08:01] <jpds> NCommander: The OpenID stuff?
[08:02] <NCommander> seems every ubuntu service has it now
[08:02] <NCommander> jpds, BTW, come join cruft busters ;-)
[08:03] <persia> NCommander: Previously the wiki had a hack to use LP has a backend for authentications (since Edgy or so).  OpenID is significantly cleaner.
[08:03] <NCommander> Ah
[08:03] <jpds> NCommander: Yeah, it makes things way easier.
[08:03] <NCommander> It seems to have come after REVU openid
[08:03]  * NCommander wonders if it was inspired by that
[08:03] <SolarWar> anyone know if application developers need to do anything special to hook into apport?
[08:03] <jpds> NCommander: It came before ;-) What are cruft busters?
[08:05] <persia> SolarWar: Have the upstream build system provide unstripped binaries by default (for compiled languages).
[08:05] <NCommander> jpds, https://edge.launchpad.net/~ubuntu-cruft-busters
[08:05] <persia> Otherwise the upstream build system needs to be patches: Ubuntu provides stripped binaries, but the stripping process also saves the dbgsym packages for apport use.
[08:07] <SolarWar> persia, so the program i packaged up, is in c++, it has the ggdb flag set (for debug symbols when it compiles) my package creates two packages- the normal stripped package, and the dbg symbol package, is that sufficient?
[08:07] <NCommander> jpds, and https://wiki.ubuntu.com/CruftBusters
[08:08] <jpds> NCommander: Nice idea. /me joins
[08:08] <NCommander> persia, care to look at the wiki page and make any suggestions
[08:08] <NCommander> I wrote up an inital proceedure to keep people going on the same page
[08:09] <persia> NCommander: We've twice that number of packages, at least.
[08:09] <NCommander> I don't want to scare people :-)
[08:09] <persia> Better to appear accurate than to try to keep people from learning the truth because they may be scared.
[08:10]  * NCommander fixes the number
[08:10] <persia> That said, scaring people may help in recruitment.
[08:10] <persia> NCommander: Check LP/ubuntu for the current number
[08:10] <NCommander> I'm just going with a rough estimation of 14000+
[08:10] <persia> Is it that hard to look up?  Must I provide you a URL?
[08:10] <NCommander> yes
[08:10]  * NCommander is smacked
[08:11]  * persia uses https://launchpad.net/ubuntu/intrepid to accomplish that
[08:12]  * NCommander registers #ubuntu-cruftbusters
[08:12] <persia> Why?  Surely it's better to coordinate here and in #ubuntu-devel to get best quality comments.
[08:12]  * persia points at the current occupants of #ubuntu-backports as an example of why
[08:13] <NCommander> Well, I figure its good to have a seperate channel for when Cruft Blasting Day :-)
[08:13] <jpds> poor Mez.
[08:13] <persia> Nah.  Here is good.  Gets more interest.  Same as for REVU days.
[08:13] <NCommander> Works for me
[08:13] <NCommander> What do you think of the current Procedure on doing a cruft-buster removal?
[08:14] <persia> Also, do you intend to have the team subscribed to related bugs?  What is the "cruft busters bugs page"?
[08:14] <NCommander> Each team has a bugs page
[08:14] <persia> One never assigns an archive-admin to a bug: one merely doesn't assign anyone, and subscribes them.
[08:14] <NCommander> I would open a Removal Progress on Firefox2
[08:14] <NCommander> er, meant subscribe
[08:14]  * NCommander fixs
[08:15] <persia> Ah, the LP bugs page.  Note somewhere that people should subscribe the team page to such bugs.
[08:15] <NCommander> persia, maybe you can word it better then I can
[08:15] <NCommander> (I'm not great with wikis)
[08:15] <persia> Lastly, "file patches" is not best: better to upload patches, no?  Especially if you are restricting the team to people who can upload.
[08:15]  * persia isn't great with time.
[08:15] <NCommander> Oh
[08:15] <NCommander> D'oh
[08:16] <NCommander> Well, its restricted to MOTU, or those sponsored by an MOTU to join
[08:16]  * NCommander clarifies
[08:19] <NCommander> I think firefox2 should probably start working on being removed from the archive
[08:28] <NCommander> persia, mail sent to motu
[08:28] <persia> NCommander: Great.  Now you just need to help people to join the team and get the work done :)
[08:29] <persia> While certainly not authoritative, you may find that some of the QA resources are good at identifying possible candidates for renewal or removal.
[08:29]  * NCommander tackles \sh and drags him away
[08:29] <\sh> hum?
[08:29] <NCommander> \sh, join the cruft busters, a group dedicated to removing moldy packages from the archive
[08:29] <NCommander> \sh, https://edge.launchpad.net/~ubuntu-cruft-busters
[08:30] <NCommander> (see email to motu for more details)
[08:30] <persia> \sh: Do you really fear a lot of personal attacks to get team members to resign?
[08:30] <NCommander> You get a cool orange garbage can as a bragging right :-)
[08:31] <\sh> persia: no...but the paragraph can be easily mis-interpretated
[08:31] <NCommander> persia, it seems the email to the mailing list works quite well
[08:31]  * emgent huggs \sh 
[08:32] <NCommander> or I just wrote good notes
[08:32] <NCommander> although I think nixternal isn't going to like me after he gets pinged to death
[08:32] <persia> \sh: I guess.  Personally, I don't think any of us would do that, and if someone did, I'd rather discuss it, rather than needing to explicitly tell them not to do so in advance.
[08:33] <persia> NCommander: email can be an effective means of communication, and some discussions are worth two months.  I just feel that we ought actually review things when we way we will.
[08:34] <NCommander> persia, any comments on my minutes?
[08:34] <NCommander> wow, another cruft buster joins
[08:34] <persia> \sh: Also, did you get the same impression from https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004275.html ?
[08:34] <NCommander> I'm soon going to have a complete #u-motu collection :-)
[08:34] <persia> NCommander: Thank you for writing up the minutes
[08:34] <NCommander> No problem
[08:35] <NCommander> gmail also makes it easy to keep track of all the threads
[08:35] <NCommander> emgent, you be cruft buster
[08:35] <persia> NCommander: Just don't co-opt the entire SWAT team: we need security support too :)
[08:36] <NCommander> We need Ubuntu-MOTU cards
[08:36] <NCommander> persia, Powers: Ability to reason. Weakness: Voting
[08:36] <persia> Yes, but I have the special "Quash Vote" power, which takes a month to recharge.
[08:36] <NCommander> you know
[08:37] <NCommander> I have enough free time I might make a Ubuntu MOTU trading card thingy
[08:37] <persia> FTBFS is more interesting than MOTU cards, surely :)
[08:37] <NCommander> slangasek would be an ultra-rare with Release Ubuntu Distro ability
[08:37] <NCommander> (he's going to see that on the scrollback and go WTF)
[08:38] <slangasek> yes, yes I am.
[08:38] <emgent> hehhe
[08:38] <persia> Still 467 packages to go...
[08:38] <NCommander> slangasek, Ubuntu developer trading cards :-)
[08:38] <NCommander> Maybe make FTBFS and bugs be event cards ...
[08:38] <NCommander> ...
[08:39] <NCommander> I should stop on this train of thought before I go create a game or something producive
[08:39] <slangasek> NCommander: explaining this does not cause the "WTF" to diminish
[08:39] <persia> NCommander: Yes, go kill cruft, fix FTBFS, etc.  You'll feel better in the morning.
[08:40] <NCommander> I dunno, we could sell it for money or include it with every Ubuntu CD sent via shipit ...
[08:43] <\sh> persia: nope..
[08:44] <persia> NCommander: When you have time, could you rewrite the model to be significantly more verbose and closer to the original proposal?
[08:44] <persia> Based on \sh's comments, I think the summarised version may be confusing to some.
[08:44] <NCommander> persia, come again
[08:44] <NCommander> I was just about to put slangsek on qdb.us
[08:44]  * NCommander runs
[08:45] <persia> NCommander: Differences between https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004275.html  and https://lists.ubuntu.com/archives/ubuntu-motu/2008-August/004389.html
[08:46] <persia> Also, which some chatter is good to maintain our team spirit, too much random poking or abuse is generally to be avoided.
[08:46] <NCommander> I'm aware
[08:46] <NCommander> I'll post it tommorow
[08:47] <emgent> dholbach: your face is in my launchpad profile now, lol :-)
[08:48] <dholbach> :)
[08:48] <NCommander> There won't happen to be an #ubuntu-* fortune file, would there?
[08:49] <NCommander> SO our insanity can be collected for future generations?
[08:50] <persia> Generally we try to avoid such insanity, but conceivably such a package could be constructed.
[09:20] <Iulian> G'morning
[09:25] <huats> morning everyone
[09:25] <huats> TheMuso: are you around ?
[09:57] <stefanlsdx> hi guys :)
[09:59] <emgent> moin stefanlsd :)
[10:13] <didrocks> Hi everyone,
[10:14] <didrocks> I'm currently working on bug #61039
[10:14] <didrocks> I have already be done some work on it (see https://wiki.ubuntu.com/DidierRoche/MOTU/bugsaction)
[10:14] <abogani> Good morning all!
[10:15] <didrocks> but I don't really know what is the right way to manage the icons installation (as there is a lot of them: for 27 games)
[10:15] <didrocks> as it is more explicity explained on the previous link, the question is in the "TODO AND QUESTION" question, if you need more information, do not hesitate to ask :)
[10:19] <persia> didrocks: Are you sure you want to add all those?  That's a *huge* extra chunk of stuff to get installed.
[10:20] <persia> Mind you, most of them are good games, and separate executables.
[10:21] <didrocks> persia: I spoke about it with the debian upstream maintenair and he is ok for putting them (if I provide the debdiff :))
[10:21] <persia> didrocks: Yes, he would be :)
[10:21] <persia> sgt-puzzles would also benefit from improvement of the debian menu files to use the icons.
[10:22] <persia> Although there are surely wiser xdg-compliant locations, I tend to err on the side of putting everything in /usr/share/pixmaps and /usr/share/applications/
[10:22] <didrocks> but /usr/share/pixmaps are not only for pixmaps image files ?
[10:23] <persia> If you using the same names for the pixmaps and .desktop files as for binaries in /usr/games/ there is a relatively low chance of conflict.
[10:23] <didrocks> ok, so, I should rename in debian/rules <package_source>/icons/blackbox-32d24.png to usr/share/pixmaps/blackbox.png
[10:24] <didrocks> but I really do not see how to do it in a clever way (that is to say, not putting 27 install lines in debian/rules) :)
[10:24] <persia> didrocks: Yes.  Also, if you can provide a 32x32 .xpm for each of them, that would make the debian menu look good too (which is especially nice if you're sending the patch to Debian)
[10:24] <persia> dh_install
[10:25] <didrocks> with a .install file, that's it?
[10:25] <persia> Then in debian/sgt-puzzles.install (or debian/install) put "./icons/*png usr/share/pixmaps" or something.
[10:25] <joaopinto> Hello
[10:26] <persia> Yep.  That makes debian/rules easier to read, and lets you manage the install separately.  Mind you, it's only good to do this if the maintainer is using debhelper.
[10:26] <didrocks> this is the case here, hopefully :)
[10:27] <didrocks> so, the idea is to create <game_name>.xpm
[10:28] <didrocks> and then dh_install to install them using a debian/sgt-puzzles.install file
[10:28] <persia> didrocks: Yes indeed.  You can also probably move the manpages install into dh_installman and the help into part of dh_installdocs
[10:28] <persia> Of course, this might not work (depending on permissions, etc.), in which case leaving it in the current way is best.
[10:29] <didrocks> if some renaming is necessary (like <game_name>-32d24.png to <game_name>.png, is it possible to use in debian/sgt-puzzles.install some bash scripting?
[10:29] <didrocks> ok, I note that about manpages and help :)
[10:30] <persia> No.  If you're going to rename things, you need to do that in debian/rules.  dh_install cannot rename, and cannot set special permissions.
[10:30] <didrocks> persia: is there a good example with renaming or stuff like that (even if I will not use it there), just for next time I will need it :)
[10:32] <persia> Generally I just call install -m$(permissions) $(source) $(target).
[10:33] <persia> If this can be automated in some way, you could use a make directive of some sort, although most people seem to give up and use the shell for loop.
[10:33]  * persia likes $(foreach ...) and pattern-matching targets, but these are hard to explain
[10:33] <didrocks> so, just put the shell script loop in debian/rules to call install -m..., isn't it?
[10:34] <didrocks> (for the easy way before going further ;))
[10:34] <persia> didrocks: If you want to learn make properly, no, but that's the easy way.
[10:35] <didrocks> ok, I will try to give a look at $(foreach ...) as for pattern-matching, I think I'm used to it :)
[10:35] <didrocks> persia: thank you so much for your time and patience :)
[10:35] <persia> Note that in my experience, most Debian Maintainers are more comfortable in shell than in make, so doing it that way may also make it easier to get reviewed and applied in Debian.
[10:35] <didrocks> oh, ok, noted!
[10:35] <persia> (but debian/rules *is* a makefile, so people who have the freedom to do it properly in make should)
[10:36] <didrocks> ok, that's a long time I hadn't touch a complex makefile by hand (IDE's rules...), but I will take a look on it
[10:37] <didrocks> so, now, I just have to get back to work on it, thanks a lot!
[10:52] <huats> hello persia
[10:54] <persia> huats: Hello.
[10:54] <huats> how are you ?
[10:54] <persia> OK.  You?
[10:55] <huats> so do I :)
[11:01] <SolarWar> once a new package makes its way into ubuntu, do I need to go through the approval process again (eg two advocates) to keep the package up todate or is there a different process for packages that are already in ubuntu ?
[11:02] <SolarWar> keep the package up to date -> with respect to the upstream tarball
[11:03] <persia> SolarWar: A different process.  You just open a bug against the package, attach the updated diff.gz, and subscribe the sponsors queue.
[11:03] <SolarWar> whats a sponsor?
[11:04] <persia> someone who uploads stuff for people without upload permission.
[11:05] <persia> SolarWar: You may find it useful to read https://wiki.ubuntu.com/MOTU/Contributing
[11:06] <SolarWar> persia, thanks this is usefull now
[11:06] <SolarWar> previously i was just concerned with packaging correctly :)
[11:07] <thekorn> hi MOTUs! - I've got two workflow related questions:
[11:07] <thekorn> what's the way to get python-sphinx into hardy?
[11:08] <thekorn> and what is the best way to get the latest release into intrepid?
[11:09] <POX__> ask for sync with Debian ?
[11:10] <huats> warp10: thanks for the approval in the team ;)
[11:11] <warp10> huats: my pleasure! It's 150€, thanks :)
[11:11] <huats> ;)
[11:11] <huats> ok
[11:11] <huats> didrocks will pay them for me :)
[11:11] <DktrKranz> warp10, wasn't tax free for the first year?
[11:12] <warp10> DktrKranz: acceptation and application review fee. First year is free indeed 0:-)
[11:13] <persia> thekorn: FOr hardy, I think you'd need backports, but for intrepid a sync addresses the problem.
[11:15] <thekorn> persia, ok, thanks, but debian does not have the latest version yet, so I have to ask for an update there first, right?
[11:15] <persia> Oh.  I thought 0.4.2 might have been the latest.  What is the latest?
[11:15] <thekorn> 0.4.3
[11:15] <persia> POX__: What do you think the chances are of an update in Debian?
[11:16] <POX__> persia: I uploaded newest package lately, so changes are good ;P
[11:16] <POX__> oh, 0.4.3 is released
[11:16] <POX__> I uploaded 0.4.2
[11:16] <persia> That's what I thought.  Will you get shot for another update?
[11:17] <POX__> I didn't receive RFS for 0.4.3 yet
[11:17] <POX__> if I get one, I'll probably upload to experimental for now, 0.4.2 is waiting for transition into testing
[11:17] <persia> thekorn: Are you able to prepare an update for 0.4.3 to submit an RFS, or do you need someone else to do that?
[11:18] <POX__> persia, thekorn: I will ask Maintainer to update it
[11:18] <thekorn> persia, honestly, I've never done real packaging
[11:18] <persia> POX__: Even better.  Thank you.
[11:18] <thekorn> persia, POX__ , thanks so much
[11:19] <persia> thekorn: Just wait a bit and watch debian Experimental.  0.4.3 ought get there in a bit, and we can sync from Experimental.
[11:19] <thekorn> cool, super
[11:19] <thekorn> one question, what's an RFS?
[11:19] <directhex> request for sausage
[11:19] <persia> Request-for-Sponsorship.
[11:20] <persia> It's a Debian abbreviation used to describe the sort of email one sends to a list to request upload sponsorship in Debian.
[11:20] <persia> Sending an RFS is roughly analogous to subscribing the sponsors queue.
[11:20] <thekorn> persia, thanks
[11:37] <jelmer> hi!
[11:38] <jelmer> One of the comments I received for my packages uploaded to REVU is that I should use a patch system
[11:38] <didrocks> huats: I have so many credits because of you :) (sorry network breakage at my company ^^^)
[11:38] <jelmer> the package is maintained in a Bazaar branch though, is that sufficient?
[11:39] <directhex> jelmer, is it a native package, i.e. the package itself has a debian/ directory which is used for making ubuntu packages?
[11:39] <jelmer> directhex, no, it's not a native package but upstream is in bzr as well
[11:40] <persia> jelmer: So upstream is in bzr, and packaging is in bzr, and you want to keep it that way to ease merging of patches for new upstreams?
[11:40] <directhex> jelmer, as part of the packaging process, do you (the package maintainer) make any changes whatsoever to files outside the debian/ folder ?
[11:40] <jelmer> persia, yep
[11:40] <jelmer> yes, there are some minor changes I made outside the debian folder
[11:41] <persia> jelmer: Then you *don't* want a patch system, but you do want to make sure to have good Vcs-* information in debian/control
[11:41] <persia> Unfortunately, we've not currently a good system to handle the permissions for those :(
[11:42] <persia> jelmer: Which package?
[11:42] <jelmer> persia, loggerhead
[11:42] <persia> loggerhead is becoming an Ubuntu package?  My
[11:43] <ara> hello, one quick question, does anyone remember the command to get the candidate version of a package for all ubuntu versions???
[11:44] <directhex> apt-cache policy?
[11:44] <persia> ara: How do you mean?  rmadison will tell you the most recently available version for each release, but candidates typically need to be larger than this, and are often manually constructed.
[11:44] <ara> persia: rmadison is what i was looking for, ta!
[11:45] <persia> Kopfgeldjaeger: Yes, patch systems are nice, but no, they aren't always the solution.  If one manages a source package in a VCS, having a patch system can make it significantly *more* difficult to reconcile upstream updates.
[11:54] <zorglu_> apt-get doesnt handle http redirect ?
[11:54] <wgrant> I believe that is correct.
[11:55] <zorglu_> ?
[11:55]  * zorglu_ is amazed
[11:55] <zorglu_> W: Failed to fetch http://urfastr.net/apt/http://fr.archive.ubuntu.com/ubuntu/dists/hardy/restricted/binary-i386/Packages.gz  302 Found
[11:56] <azeem> maybe it's because of security considerations
[11:56] <zorglu_> http redirect is a security hole ?
[11:56] <StevenK> zorglu_: apt doesn't handle 30x redirects.
[11:57] <zorglu_> StevenK: any specific reason ? or just a poor http implementation
[11:57] <wgrant> Debian bug 479350
[11:57] <wgrant> That has rationale.
[11:59] <zorglu_> wgrant: well the rationnal is "no support because some mirror are misconfigured"
[11:59] <zorglu_> wgrant: i dont know for you, but im not ultra convinced :)
[12:00] <StevenK> zorglu_: No, that isn't the rationale at all.
[12:00] <StevenK> zorglu_: mod_speling isn't misconfiguration, it allows the mirrors to provide packages the user didn't ask for, which is *bad*.
[12:01] <POX__> thekorn: Mikhail told me that he will ask for an upload of sphinx 0.4.3 once 0.4.2 will migrate into Lenny (9 days)
[12:01] <zorglu_> StevenK: and this is not misconfig ?
[12:01] <POX__> he's busy with other pacakges at the moment so 0.4.3 will not be uploaded to experimental
[12:01] <StevenK> zorglu_: How exactly is mod_speling a misconfiguration?
[12:01] <zorglu_> StevenK: so it is properly configured but provide bad packages ? i dont get it
[12:03] <StevenK> zorglu_: Okay, so it isn't a misconfiguration, it's that mod_speling provides functionality that can redirect users to download packages that they didn't ask for, if apt follows the redirect. This is a bad thing.
[12:04] <zorglu_> you call that the way you want :)
[12:04] <azeem> I think we called it like that all the time
[12:04] <zorglu_> "bad thing" is a nice word too
[12:05] <zorglu_> ok so the solution to this mod_speling issue is not to support http redirect ?
[12:05] <persia> zorglu_: "bad thing" == "unacceptable unrequested misconfiguration of user systems"
[12:05] <zorglu_> not to fix/enhance mod_speling to give the proper package ?
[12:05] <azeem> StevenK: however, the rogue Release.gpg would not validate against the GPG key the user has, would it?
[12:05] <StevenK> azeem: Hold on
[12:05] <azeem> unless the user ignores or disables that
[12:06] <zorglu_> well if the user disable the security, it is its problem
[12:06] <StevenK> azeem, zorglu_: Okay, say apt did follow the redirect. You see an upgrade to base-files in the Packages.gz file. You go to download it, but the mirror admin has deleted that .deb, and put base-files_4.0.haha_all.deb there instead which runs "rm -rf /" during the postinst.
[12:06] <StevenK> No touching of the Packages.gz or Release.gpg needed
[12:06] <persia> azeem: Imagine the case where it replaces e.g. apt-file with e.g. aptitude, and both are signed by the same key.
[12:06] <StevenK> persia: Not even, it's even simpler. ^
[12:07] <zorglu_> StevenK: ???
[12:07] <zorglu_> StevenK: how does this relate to http redirect ?
[12:07] <persia> StevenK: That gets caught by the incorrect checksum on package download (for those sufficiently paranoid to check)
[12:07] <azeem> StevenK: wouldn't the Packages.gz's md5sum then be out-of-sync against the data in Release?
[12:08] <thekorn> POX__, thanks for your information
[12:08] <StevenK> azeem: Packages.gz doesn't need to be changed
[12:08] <persia> azeem: Only if someone reran the archive scripts.  It's the content of the file that wouldn't match to Packages.gz.
[12:08] <azeem> StevenK: or what do you mean with "you see an upgrade... in the Package.gz"?
[12:08] <azeem> persia: which file?
[12:08] <StevenK> azeem: I mean a new legimate upgrade is there.
[12:08] <azeem> ok
[12:08] <zorglu_> StevenK: how all this relate to http redirect
[12:08] <persia> I think the case of grabbing e.g. 0.4.2-3ubuntu3~hardy1 instead of 0.4.1-2ubuntu6.1 was more insidious
[12:09] <azeem> why would apt download base-files_4.0.haha_all.deb?
[12:09] <StevenK> But the mirror admin deleted the .deb, and put base-files_4.0.haha_all.deb in it's place, and enabled mod_speling so it downloads it.
[12:09] <StevenK> azeem: The asumption here is that apt follows 30x redirects
[12:09] <azeem> "it's place"?
[12:09] <azeem> ok
[12:09] <persia> azeem: It's somewhere in the directory.
[12:09] <geser> doesn't apt compare the md5sum of the downloaded deb against the one in Packages.gz?
[12:09] <azeem> but then the md5sum of base-files_4.0.haha_all.deb wouldn't match the deleted .deb's md5sum in the Packages.gz
[12:10] <zorglu_> geser: i hope so :) or it is a major security hole :)
[12:10] <zorglu_> geser: and suddently http redirect is really a very small issue :)
[12:10] <geser> I hope so too, else the gpg signing of the archive would be useless
[12:11] <zorglu_> geser: because this would mean that any mirror admin could crack *many* computers
[12:11] <azeem> StevenK: my point is that maybe the reservations against http redirects are from times when we didn't have Release/Packages file signing
[12:11] <zorglu_> hence my repeated question: how all this related to http redirect
[12:12] <azeem> ah, I now understand mod_speling implications
[12:12] <persia> zorglu_: If you're certain it is safe now, you'd do best to attach a patch and make a case to the bug, rather than here.
[12:13] <zorglu_> persia: im not the maintainer of this
[12:13] <StevenK> Neither are we
[12:13] <persia> Firstly, apt isn't in universe, and secondly, it's exceedingly unlikely to be accepted as a variance from Debian.
[12:13] <zorglu_> else you would have http redirect for a long time: )
[12:13] <azeem> persia: I think Kamion makes a good point, only allow redirects for the same filename
[12:13] <persia> zorglu_: How does whether you are the maintainer have anything to do with you submitting a patch and explanation why the patch is now safe?
[12:13] <zorglu_> persia: the likelyhood to be included
[12:13]  * persia is fairly certain that nick is deprecated
[12:14] <zorglu_> persia: aka the fact i do the patch has nothing to do with feature in it or not
[12:14] <persia> zorglu_: Right.  Still, adding to the bug would be useful.  Arguing here is pointless.
[12:14] <azeem> and I think the reservations about mod_speling are not all security implications, but just annoyances for users, cause it would hand out the wrong .debs if the one they want is not there, and then APT would complain
[12:14] <persia> Also, the assumption that someone else would create the patch because you argued with them is presumptive.
[12:14] <azeem> s/not all/not at all/
[12:14] <zorglu_> persia: ok lets be productive. i would like to do a mirror. how can i workaround this "feature" of no http redirect in apt-get
[12:15] <\sh> the easy solution: ipvs and forward your old ip to the new one....
[12:15] <azeem> zorglu_: why do you need it?
[12:15] <persia> zorglu_: Don't require redirect in your mirror implementation.
[12:15] <zorglu_> ok so no way to work around this ?
[12:15] <azeem> zorglu_: work around /what/?
[12:15] <zorglu_> the "feature" :)
[12:15] <azeem> zorglu_: other mirrors seem to get along fine
[12:15] <\sh> zorglu_: what do you want? mirror.domain.tld is deprecated and now you want to redirect to mirror2.domain.tld?
[12:16] <persia> zorglu_: What problem are you experiencing?
[12:16] <\sh> why not forward the ip:port to anotherip:port?
[12:16] <zorglu_> \sh: the bandwidth would be used on both servers (if i understand what you mean)
[12:17] <\sh> zorglu_: hmmm? no
[12:17] <zorglu_> \sh: what 'forward an ip" means then ?
[12:17] <nixternal> NCommander: pong! :)
[12:17] <\sh> TCP  media.dev.webzooms.tv:1935 rr
[12:17] <\sh>   -> fms-edge-2.dev.webzooms.tv:1 Route   1      0          0
[12:17] <\sh> something like this
[12:17] <sistpoty|work> hi folks
[12:17] <nixternal> woo, someone wants to help REVU coordination...yay \o/
[12:18] <zorglu_> \sh: at the BGP (ip routing) level ?
[12:18] <\sh> zorglu_: bgp has nothing to do with it
[12:18] <zorglu_> \sh: ok what is your dump ? what 'forward an ip" mean ?
[12:19] <StevenK> BGP is a routing protocol.
[12:19] <zorglu_> \sh: you mean "forwarding the tcp connection at the netfilter level" ?
[12:19] <persia> Well, even a routing information protocol
[12:20] <stefanlsd> Im doing a merge - in the debian rules I have    -$(MAKE) distclean         . Does the - there mean anything special?
[12:20] <sistpoty|work> stefanlsd: it means ignore if make distclean fails
[12:20] <persia> stefanlsd: It means to ignore errors returned from the command.
[12:20] <\sh> zorglu_: ok to make it easy
[12:20] <sistpoty|work> (e.g. if there would be no Makefile because make distclean was already run before)
[12:20] <\sh> zorglu_: your mirror has ip : 192.168.1.2 and your apache listens on port 80
[12:20] <persia> stefanlsd: Generally this is discouraged as it's better to trap specific errors, but it's not worth preseving an Ubuntu variation for.
[12:21] <\sh> zorglu_: your new machine has the ip 192.168.1.9 and has an apache on port 80, too
[12:21] <stefanlsd> thanks guys
[12:21] <zorglu_> \sh: ah ok, here you assume both computer are on the same LAN
[12:21] <stefanlsd> persia: If i am doing an ubuntu revision anyways to fix something else, should I then try trap the error rather?
[12:21] <nixternal> NCommander: I am getting ready to head to work, but I will be back on in a bit...If you guys are interested in creating a REVU team, I so support that because my time has shrunk to about null right now
[12:22] <\sh> zorglu_: it doesn't matter on which lan/wan/ip they are on...it's really transparent
[12:22]  * persia doesn't think we need an LP team for that, just interested people working with the REVU Coordinator to help throughput
[12:22] <zorglu_> \sh: ok so i keep listening
[12:22] <DktrKranz> Kopfgeldjaeger, package accepted into universe ;)
[12:22] <\sh> zorglu_: it's layer 4 switching the whole idea
[12:22] <\sh> zorglu_: http://www.linuxvirtualserver.org/software/ipvs.html
[12:23] <zorglu_> \sh: if you get a solution without using both server bandwidth and without http redirect, im all hear :)
[12:23] <Kopfgeldjaeger> DktrKranz: wwoooo \o/ thank you :)  *hug*
[12:23] <wgrant> You could of course be boring and just repoint the DNS name...
[12:24] <persia> And maybe run both servers for 3xTTL to be safe.
[12:24] <\sh> zorglu_: the bandwidth of the new server is used only..., only for the start point (thinking about mirror.domain.tld will directed to 192.168.1.2) you need your old machine...or a new one with the old ip
[12:24] <wgrant> persia: I'd hope so.
[12:24] <\sh> wgrant: damn...that's the easy solution ,)
[12:24] <zorglu_> not a working solution unfortunatly
[12:25] <zorglu_> all that for some misconfig mirror several years ago...
[12:25] <persia> zorglu_: Why is that not a working solution?
[12:25] <\sh> zorglu_: the whole idea is this : http://www.howtoforge.com/set-up-a-loadbalanced-ha-apache-cluster-ubuntu8.04
[12:25] <persia> zorglu_: Also, please state the problem you are encountering.
[12:26] <zorglu_> persia: ok i need apt-get to implement a normal http
[12:26] <\sh> zorglu_: the old machine with old ip takes the connect and forwards it to another server, another server has different default route but real connects your clients
[12:26] <zorglu_> persia: how do i do that ?
[12:26] <zorglu_> persia: and i would llike ubuntu people to get it too :)
[12:26] <persia> zorglu_: No.  What problem are you experiencing for which you believe that to be a solution?
[12:26] <zorglu_> persia: tomorrow if possible :)
[12:27] <zorglu_> a mirror system
[12:27] <\sh> this is what big boys do...first think, then plan, then think again, replan, then implement ;)
[12:27] <\sh> zorglu_: archive.ubuntu.com is nothing else then a mirror system
[12:27] <persia> OK.  There are lots of mirrors.  Explain the problem.
[12:27] <zorglu_> i guess i got communication problem
[12:28] <\sh> zorglu_: it's behind a dns rr..and other people are just doing layer 4 switching which means, they are using f5 network big ip, or ipvs, or whatever lb system is there, to just hide the real servers
[12:28] <zorglu_> lets me think a bit, maybe i can workaround this "feature"
[12:28] <persia> zorglu_: What doesn't work?
[12:28] <zorglu_> after all apt-get has this feature for year, it is not anywhere close to be fixed
[12:29] <zorglu_> \sh: they do a lot but dont support proper http in apt-get :)
[12:29] <directhex> how can a source package generate binaries in both universe and main?
[12:29] <persia> directhex: The source must be in main, and nothing in main must depend or build-depend on some of the binaries.
[12:29] <zorglu_> \sh: do you know if fedora/redhat and go, got the same "feature" ?
[12:30] <StevenK> zorglu_: It *does* support "proper" HTTP, it chooses not to follow 30x redirects.
[12:30] <persia> zorglu_: What issue do you encounter which would be fixed by apt supporting redirects?
[12:30] <\sh> zorglu_: apt4rpm has the same feature, yum is broken by default, zypper I don't know, and smart is following apt afaiks
[12:30] <zorglu_> \sh: yum support http redirect ?
[12:30] <\sh> zorglu_: yum is broken...
[12:30] <directhex> persia, i mean physically. how's it set in the source package?
[12:30] <persia> directhex: It's not: it is set in the archive.
[12:31] <zorglu_> \sh: you mean he got "features" :)
[12:31] <\sh> zorglu_: no I mean it's broken
[12:31] <zorglu_> \sh: what do you mean by broken ?
[12:32] <directhex> persia, oh. i see. hm, looks like a sync might be enough rather than a merge then
[12:32] <persia> z
[12:32] <\sh> zorglu_: it only support rpm-md repos...and it's totally slow and the last time i used it for sles9 it didn't even have a good and working architecture recognition system
[12:32] <persia> directhex: I've lost context.  What are you trying to accomplish?
[12:32] <zorglu_> \sh: ah ok
[12:32] <zorglu_> \sh: well maybe it got http, that's all i need for now
[12:33] <zorglu_> now i just have to setup a fedora vm to test :)
[12:33] <\sh> zorglu_: but as I said, you have an infrastructure problem...your problem is not apt or http...a 30x redirect something temporarily...and not a good use for a package mirror
[12:33] <zorglu_> thanks guys :)
[12:33] <zorglu_> \sh: i could trivially implement the system i want if apt-get would respect http
[12:33] <directhex> persia, i want to update the package "monodoc". the 1.2.6-1ubuntu1 merge made some changes to the build process in order to avoid making monodoc-http Depends: on something in universe. monodoc-http is itself already in universe, so i don't see the problem
[12:33] <persia> zorglu_: What system?  WIth a use case, it may be able to do so.
[12:34] <directhex> persia, and the monodoc source package is in main, in case that wasn't clear
[12:34] <zorglu_> persia: may being the operating word :)
[12:34] <persia> directhex: No source in main may build-depend on any binary in universe, although it may generate binaries that end up in universe.
[12:34] <zorglu_> ok all in all thanks for the info
[12:34] <persia> Bah.  Without any explanation, there's no chance at all.
[12:35]  * \sh gives up...that's too semi-amateure..well, and normally he will have the same problem with yum or whatever not following 30x and not using whatever he tries to do
[12:35] <directhex> persia, aha, i hadn't noticed the differing build-depends
[12:35] <persia> directhex: Yeah.  stuff on the border is tricky.
[12:36] <directhex> looks like a merge, then. how tiresome
[12:36] <directhex> then waiting for u-m-s. wheeeee
[12:36] <persia> directhex: Is u-m-s that much worse than u-u-s?
[12:40] <directhex> much more fickle, maybe?
[12:40]  * DktrKranz did a quick stat: u-u-s has *116* unique packages to be reviewed, u-m-s has *72*
[12:42] <DktrKranz> half the open bugs in u-m-s are debian/upstream tasks which should be removed from the list, actually
[12:43] <dholbach> DktrKranz: better use https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-main-sponsors and https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-universe-sponsors
[12:44] <DktrKranz> dholbach, exactly. I have my own LP queries to exclude uninteresting remote bugs from sight.
[12:45] <directhex> am i the only one who finds MOTU/Contibuting entirely unclear in places?
[12:46] <sistpoty|work> hm... seems like there's more revu documentation spread across the wiki, which needs to get updated
[12:48] <persia> directhex: It's massively out of date.  What is confusing?
[12:49] <directhex> persia, i just find the bit on mergine new upstream from debian unclear
[12:50] <stefanlsd> Does anyone have a view on the following bug and patch - https://bugs.launchpad.net/ubuntu/+source/netkit-tftp/+bug/217537     . I am doing a merge of the netkit-tftpd from Debian and this bug isn't fixed.  It looks ok to me, but I dont really understand enough C to make a decision on it...
[12:52] <sistpoty|work> superm1|away: did you come around merging nvidia-settings yet? if not, mind if I'll take a look at it tonight?
[12:53] <sistpoty|work> oh, tseliot: just saw that you removed conflicts from nvidia-settings. I'll need to undo this. Just a hint: versioned conflicts should almost never be dropped
[12:56] <persia> directhex: Do you mean "If your revision is a merge from Debian..." ?
[12:56] <directhex> persia, yeah.
[13:04] <persia> directhex: Which part is confusing?
[13:04] <directhex> persia, use of the word "new"
[13:04] <persia> directhex: Ah.  How do you think it should be phrased?
[13:05] <directhex> persia, if i want to merge 1.9-1.2 from debian, and 1.2.6-1ubuntu3 is the ubuntu version, then which number goes where in "debdiff packagename_version-debianrevision.dsc packagename_version-newrevision.dsc" ?
[13:05] <directhex> the debian version is newer, and the debian version is the debian version
[13:05] <directhex> perhaps i should diff 1.9-1.2 1.9-1.2! \o/
[13:06] <persia> Maybe.  I was thinking that the "new" revision would be the one the merger prepared.
[13:06] <stefanlsd> If i have a patch file that someone provided, and I want to include it in a merge ubuntu release.   Is the recommended way to use  dpatch.. ?
[13:06] <geser> stefanlsd: depends on the package
[13:07] <stefanlsd> geser: the package currently is not using any patching system (dpatch or cdbs..)
[13:07] <stefanlsd> or any other i dont know about :)
[13:08] <geser> stefanlsd: how big are the changes?
[13:08] <stefanlsd> geser: small. difference of 3 lines...
[13:10] <geser> stefanlsd: they apply it directly, adding support for dpatch or quilt would be bigger than the patch itself
[13:10] <geser> stefanlsd: if the package uses cdbs you could use simple-patchsys (or how it is exactly called)
[13:11] <stefanlsd> geser: ok. thanks, will do.  Just thought it may be easier in the long run for maintainability - but cool. will apply directly :)
[13:13] <ScottK> If the patch is relevant to Debian, you'll want to send it to them in a bug so they maintain it.  ;-)
[13:13] <stefanlsd> ScottK: nodnod. I will submit upstream also
[13:27] <ScottK> YokoZar: Could the vm.mmap_min_addr change for wine perhaps be off by default.  It seems like something only a minority of apps need and I don't generally find myself thinking, "Hey, it's a Windows executable, I think I want less security on this."
[13:28] <YokoZar> ScottK: I don't think it's a good idea.  A good chunk of modern apps are making 16 bit calls somewhere along the line, including stuff like the .net installer (!)
[13:29] <directhex> the ms.net installer works?
[13:29] <ScottK> OK.  I thought from reading mail is was old stuff only.
[13:29] <YokoZar> ScottK: It is.  But remember that Windows applications often made DOS system calls even as late as 99
[13:30] <directhex> YokoZar, which is lovely for those of us running 64-bit windows, which has no 16-bit subsystems
[13:31] <YokoZar> directhex: I imagine it'll be at least 5 years before we see win64 apps that aren't also win32
[13:32] <directhex> YokoZar, MOAR registers!
[13:38] <tseliot> sistpoty|work: what's the use case for those conflicts and recommends? Currently each nvidia-glx-VER Recommends: nvidia-settings
[13:42] <sistpoty|work> tseliot: the use case of the conflicts is to ensure that the upgrade path works
[13:42] <tseliot> sistpoty|work: the upgrade of what?
[13:43] <sistpoty|work> tseliot: since iirc the nvidia-settings binary used to live in nvidia-glx (or whatever the conflicts are against) and then has been moved to nvidia-settings (and part time overlapped)
[13:43] <sistpoty|work> tseliot: so you couldn't install both at the same time
[13:44] <tseliot> sistpoty|work: ok but this is no longer the case
[13:44] <sistpoty|work> tseliot: so in case there is a system, which still has the older version (with the conflicting file) installed, that upgrades to intrepid, the upgrade might fail
[13:44] <sistpoty|work> (because you don't know wether apt will upgrade one or the other package first, if there are no conflicts specified)
[13:46] <sistpoty|work> I guess it might be safe to drop the conflicts in this case, as I guess we can assume that we don't support upgrades from a pre-LTS version, but they don't really hurt
[13:56] <tseliot> sistpoty|work: good point. In Update manager I think we check the nvidia-glx package first and upgrade it according to the hardware detection perform through nvidia-common.
[13:56] <tseliot> sistpoty|work: the gutsy package of nvidia-settings conflicts with nvidia-glx, nvidia-glx-new
[14:06] <tseliot> sistpoty|work: I was worried about the Recommends which made nvidia-settings install the old nvidia packages
[14:09] <sistpoty|work> tseliot: dropping recommends is no problem
[14:10] <tseliot> sistpoty|work: ok, then we've come to an agreement ;)
[14:10] <sistpoty|work> heh :)
[14:14] <bhavi_> Hello all
[14:15] <bhavi_> please help me : http://pastebin.com/d101d4489 is this a correct rules file?
[14:18] <superm1|away> sistpoty|work, no i got distracted by some other stuff that popped up.
[14:18] <superm1|away> you can have it if you want, otherwise i should be able to try again this weekend
[14:19] <sistpoty|work> superm1|away: well I won't come around before somewhen this evening... I'll just drop a note here when I start, ok?
[14:19] <superm1|away> okay sound good
[14:32] <bddebian> Heya gang
[14:32] <huats> hey bddebian
[14:33] <sistpoty|work> hi bddebian
[14:33] <ScottK> Heya bddebian.
[14:33] <bddebian> Hi huats, sistpoty|work, ScottK
[14:33] <ScottK> bddebian: Got all those RC bugs fixed yet?
[14:34] <bddebian> Heh, not quite.  I thought you were taking care of them? :)
[14:38] <geser> Hi bddebian !1!
[14:38] <bddebian> Heya geser
[14:38] <persia> sistpoty|work: tseliot: The only supported upgrade path to intrepid is from hardy, so we might be able to drop all the conflicts stuff from nvidia-settings
[14:39] <sistpoty|work> persia: unless there could be funny situations like for xserver-xorg-driver-ati (which was gone after dapper, but never conflicted against, and hence broke my intrepid upgrade *g*)
[14:42] <persia> sistpoty|work: Oh my.  Yes.  Still, if the conflicts were in hardy, the necessary bits should have been wiped for intrepid (but we may need new conflicts for intrepid)
[14:43] <sistpoty|work> persia: well, the question is if all packages that contained file conflicts had new versions in hardy. if so it's safe to drop the conflicts. if one of them vanished it's not safe.
[14:43] <persia> sistpoty|work: I'll defer to proper investigation then.
[14:44] <sistpoty|work> either that or I'm conservative and just leave them there. it definitely won't hurt to have them (and we can't sync anyways iirc, but I'm gonna find out more once I start really looking at it *G*)
[14:46] <tseliot> sistpoty|work, persia: the packages which conflicted with nvidia-settings are nvidia-glx nvidia-glx-new. *Currently* they're both in Intrepid but are deprecated. Keeping the Conflicts wouldn't hurt
[14:47] <persia> tseliot: OK.  If you think it won't hurt anything, I won't protest.
[14:48]  * persia just wants to avoid another upload ping-pong match when the nVidia-using machine may be turned on a few weeks before intrepid release
[14:48] <sistpoty|work> persia: keeping versioned conflicts can *never* hurt ;)
[14:49] <sistpoty|work> (unless these were wrong in the first place of course
[14:49] <sistpoty|work> +)
[14:49] <persia> sistpoty|work: Well, except where it blocks a sync that means we don't have so much work to do later, but in this case, yes, there are other reasons we can't sync.
[14:49] <persia> heh
[14:50] <sistpoty|work> heh, well hurt in the sense of introducing a bug *g*
[14:50] <tseliot> persia: the upgrade to the new nvidia packages (with the new name schemes) should be smooth, nvidia-common will deal with it, since it's used by Update Manager. If however you decide to dist-upgrade from the command line, nvidia-common will bug you to death with Debconf until you install the suggested package ;)
[14:50] <persia> tseliot: Then that package should be recommended.
[14:51] <persia> Putting more special-casing into Update Manager should be avoided until we have little choice due to freezes.
[14:51] <tseliot> persia: currently it is recommended by Update Manager, however it should become  a dependency since recommended packages are not installed by default on Hardy
[14:52] <tseliot> and without nvidia-common the upgrade will fail
[14:52] <tseliot> persia: ok, it won't fail but you will keep using a driver which doesn't work
[14:53] <persia> tseliot: nvidia-common is recommended by update-manager (the package) or by an Update Manager hint?
[14:54] <sistpoty|work> oh, update manager should really have the hint to not leave my gf's laptop without X after an upgrade *g*
[14:54] <sistpoty|work> (tried two times, failed two times)
[14:54] <tseliot> persia: I was convinced that nvidia-common was recommended by the package but it's not...
[14:55] <persia> tseliot: It oughtn't be, because many users don't need nvidia.
[14:55] <persia> sistpoty|work: Figure out the issue, and put in a hint if you like.  I suspect it's a matter of making X critical.
[14:55] <tseliot> persia: nvidia-common is just a simple python script and has the nvidia modalias files as its dependencies
[14:55] <persia> Anyway, I think update-manager hints should be a last resort: we should make the packages work cleanly anyway.
[14:56] <sistpoty|work> persia: I guess it's the "if person in front of box == sistpoty then make upgrade harder" part ;)
[14:56] <persia> tseliot: Yes, but I may not want it on an intel system, if I've only a 2G disk.
[14:56] <persia> sistpoty|work: Oh, right.  I thought you'd like that bit.
[14:57] <sistpoty|work> *g*
[14:57] <tseliot> persia: I understand. BTW jockey-common recommends nvidia-common
[14:57] <persia> tseliot: Which I don't like either: it offends my sense of purity.
[14:59] <tseliot> persia: nvidia-common is 53kb
[14:59] <ScottK> So if I use jockey to deal with my non-free wifi card driver I get nvidia-common installed by default?
[14:59] <tseliot> ScottK: yes, I guess so
[14:59] <persia> ScottK: Yes.
[14:59] <ScottK> That sounds wrong.
[15:00] <persia> tseliot: In the 2G scenario, that is still a lot.
[15:00]  * persia notes that it's very much not easy to fit Ubuntu in 2G anyway, so every byte matters.
[15:00] <tseliot> ScottK, persia: you should discuss this with pitti
[15:00] <persia> tseliot: See, every time I discuss something with pitti I get reminded of things I should do first :)
[15:01] <tseliot> persia: it's not a bad thing, is it? :-P
[15:01] <persia> tseliot: Well, it means I'm unlikely to actually get to the complaint part :)
[15:02] <tseliot> heh
[15:03] <tseliot> ScottK: my replacement for guidance-backends is ready (x-kit). I have also added the support for x-kit to Jockey
[15:04] <ScottK> tseliot: Great.
[15:04] <tseliot> ScottK: the code is here: https://code.launchpad.net/~albertomilone/xorgparser/main
[15:04] <ScottK> In KDE4 we can drop it anytime.
[15:05] <ScottK> tseliot: Is it in Intrepid yet?
[15:05] <tbielawa> good morning everyone
[15:05] <tseliot> ScottK: not yet. We're working with bryce and pitti so as to introduce it soon
[15:05] <ScottK> Sounds good.
[15:05] <tseliot> ScottK: the gnome-control-center should use it too
[15:06] <ScottK> tseliot: Would you please talk to the mythbuntu people about it.
[15:06] <tseliot> ScottK: I guess that only superm1 will use guidance
[15:06] <tseliot> ScottK: sure
[15:06] <ScottK> Yes.
[15:06] <superm1> well we'll switch to xkit when its ready
[15:06] <superm1> no problem
[15:07] <tseliot> superm1: great. The API is ready. If you give me a link to your code I can give you a hand
[15:08] <superm1> tseliot, let me see, it should be the mythbuntu-common bzr branch
[15:08] <superm1> https://code.edge.launchpad.net/~mythbuntu/mythbuntu/mythbuntu-common
[15:08] <ScottK> superm1: I also see an rdepend on ubiquity-frontend-mythbuntu
[15:09] <superm1> ScottK, yeah that was before mythbuntu-common was depending on it directly
[15:09] <superm1> so that will need to be resolved too
[15:09] <ScottK> So that's just a matter of dropping the depends then?
[15:10] <superm1> ScottK, yeah it will be
[15:11] <tseliot> superm1: ok, I'll have a look at it.
[15:12] <superm1> ScottK, okay i fixed that in ubiquity bzr
[15:13] <tseliot> superm1: is it only vnc.py that uses guidance?
[15:15] <tseliot> superm1: if so, it will take me only few minutes to replace the guidance code with x-kit's
[15:15] <superm1> tseliot, yeah that's it
[15:15] <tseliot> great :-)
[15:35] <JontheEchidna> Ok, so I lost internet connection while uploading to revu
[15:35] <JontheEchidna> and now it says that the file is already on the server
[15:35] <Hobbsee> dput -f
[15:36] <ScottK> or rm the .upload file
[15:36] <JontheEchidna> rm'ing the upload file worked
[15:36] <JontheEchidna> thanks
[16:13] <RainCT> is there some list of %x thingies which can be used in .desktop files? :P
[16:20] <persia> RainCT: What do you mean?  Experimental keys?  Experimental values?
[16:21] <persia> On an unrelated note, if anyone is good with schroots: how can I get a usefully populated /sys in a chroot?
[16:21] <sistpoty|work> persia: you could bind-mount one *g*
[16:22] <persia> Specificially, timidity currently won't install in my chroots, but installs fine on a normal system.  Apparently this comes from a lack of anything in /dev/snd/
[16:22] <superm1> persia, you could just mknod stuff in /dev/sdn during debian/rules
[16:22] <persia> sistpoty|work: OK.  How?  /proc/mounts lists /sys as mounted, it just doesn't have any useful data.
[16:22] <superm1>  /dev/snd that is
[16:22] <persia> superm1: Yes, but I don't really want to do that, if I can avoid it: it's a terribly dirty hack.
[16:23] <persia> Essentially, nothing should build-dep on timidity anyway, so this is only interesting in the case of building images.
[16:23] <sistpoty|work> persia: s.th. like mount -o bind /sys /var/stuff/chroots/unstable/sys
[16:23] <superm1> persia, i promise i won't tell anyone :)  I  think bind mounts are the only way to get useful stuff though
[16:23] <sistpoty|work> (adjust pathes as necessary)
[16:23] <superm1> you could just bind mount your /dev/snd instead then
[16:23] <persia> superm1: I think I need useful, as broken entries may well also cause the installation to fail
[16:23] <superm1> rather than a whole directory and introducing the security vulnerabilities
[16:24] <persia> (why is it a good idea to start daemons at installation time again?  Can't they be started later?)
[16:24] <laga> they can
[16:24] <laga> but i forgot how to do that ;)
[16:24] <superm1> so that users can start using apps immediately rather than having to read about how to start them or rebooting
[16:25] <ScottK> persia: Because the package is supposed to work after you install it.  For a daemon to work it has to run.
[16:25] <superm1> dh_installinit has a parameter to control this behavior
[16:26] <persia> ScottK: Yes, I know, and in every other case I want that.
[16:27] <persia> superm1: Yes, but that doesn't solve this one.
[16:27] <persia> sistpoty|work: bind mounting seems to populate /sys, but it doesn't trigger udev
[16:27] <ScottK> So edit exit 0 in at the top of the init and remove it later.
[16:27] <sistpoty|work> persia: then bind-mount /dev as well
[16:29] <persia> sistpoty|work: Right.  Thanks.  I can now prove the problem.
[16:30] <sistpoty|work> np
[16:30] <persia> So, in order to install timidity, one must first have working device files in /dev/snd/ and secondly have run the asoundconf set-default-card macro
[16:31] <persia> Now I just have to figure out how to do this within the context of a chroot (or maybe hack around it)
[16:42] <RainCT> persia: serpentine for example has "%U" in the Exec= line
[16:42] <RainCT> persia: ah, found it, nevermind
[16:43] <RainCT> they are explained in the spec, I just hadn't noticed them before
[16:44] <persia> RainCT: http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
[16:44] <persia> Oh.  You already found it :)
[16:44] <RainCT> persia: yes, but thanks anyway :)
[17:08] <tgm4883_laptop> I tried uploading something to REVU last night (mythstream-parser-youtube) and everything appeared ok, but it doesn't appear on http://revu.ubuntuwire.com/
[17:09] <tgm4883_laptop> I believe I've followed all the instructions at https://wiki.ubuntu.com/MOTU/Packages/REVU
[17:13] <sistpoty|work> tgm4883_laptop: did you login with openid to revu yet?
[17:14] <tgm4883_laptop> yes
[17:14] <sistpoty|work> tgm4883_laptop: and merged accounts?
[17:14] <tgm4883_laptop> no
[17:14] <sistpoty|work> tgm4883_laptop: then please do so ;)
[17:14] <tgm4883_laptop> ah ok
[17:14] <tgm4883_laptop> sec
[17:14] <tgm4883_laptop> will i need to reupload?
[17:14] <sistpoty|work> tgm4883_laptop: I can put your package right back in the queue
[17:15] <sistpoty|work> tgm4883_laptop: did you intent to make a native package btw.?
[17:15] <RainCT> sistpoty|work: merging accounts isn't necessary to be able to upload
[17:15] <sistpoty|work> RainCT: oh... interesting :)
[17:16] <tgm4883_laptop> apparenlty I don't have an old revu account
[17:16] <persia> RainCT: But it does appear to send a refresh event, which can fix some failures.
[17:16] <sistpoty|work> RainCT: I'll call move_uploads then, and see what happens
[17:16] <tgm4883_laptop> sistpoty|work, I don't believe so.  By native package, you mean packaged specifically for a debian system?
[17:17] <sistpoty|work> tgm4883_laptop: yes... at least that's what's left in revu's queue... but it seems s.th. is wrong/missing there
[17:17] <persia> What does move_uploads do?
[17:17] <sistpoty|work> RainCT: did you just call move_uploads as well?
[17:17]  * persia always uses cp to reinsert into the queue
[17:17] <RainCT> persia: process the queue
[17:17] <RainCT> sistpoty|work: nope, I'm just looking at the file in rejected/
[17:18] <sistpoty|work> RainCT: strange, where have the other two files gone to?
[17:18] <sistpoty|work> (.dsc, .tar.gz
[17:18] <sistpoty|work> +)
[17:18] <tgm4883_laptop> sistpoty|work, ah yes, I didn't write the software, just packaging it, so it isn't meant to be a native debian pckage
[17:18] <RainCT> tgm4883_laptop: btw, the Maintainer must have an @ubuntu.com address; set it to MOTU Team if you don't have one (you can leave your name as XSBC-Original-Maintainer)
[17:18] <tgm4883_laptop> which means my versioning is incorrect
[17:19] <sistpoty|work> ugh... seems like cron *might* have interfered... and it seems like either the date of my box or of spooky is wrong *g*
[17:19] <RainCT> sistpoty|work: what time do you have?
[17:19] <tgm4883_laptop> RainCT, ok, i'll change that to our team address
[17:19] <sistpoty|work> RainCT: 18:19
[17:20]  * RainCT and the server where irssi is running too
[17:20] <RainCT> I'll change it on spooky (it says :22)
[17:20] <sistpoty|work> and indeed... cron interfered... I should look better when calling date prior to calling move_uploads: "Fri Aug  8 18:19:58 CEST 2008"
[17:20] <sistpoty|work> must have been murphy biting me there *g*
[17:21] <sistpoty|work> anyway, tgm4883_laptop: package is up now
[17:22] <tgm4883_laptop> i'm a little fuzzy on the version numbering schema, I thought I followed what lintian was telling me, but it keeps giving me the warning
[17:22] <tgm4883_laptop> sistpoty|work, thanks
[17:22] <sistpoty|work> np
[17:23] <tgm4883_laptop> for future uploads, is it going to work automatically or do i need to come in here and ask every time?
[17:25] <RainCT> persia: I don't see why merging might fix anything
[17:25] <RainCT> unless it's magic :P
[17:25] <sistpoty|work> tgm4883_laptop: it should work automatically. *should* *g*
[17:26] <tgm4883_laptop> ok, i'll fix up these other parser packages I have and test it out
[17:26] <tgm4883_laptop> need to fix the version thing though first I suppose
[17:32]  * sistpoty|work heads home... cya
[17:44] <persia> RainCT: I've been considering it magic, yes.
[17:47] <warp10> NCommander: thanks ;-)
[17:47] <NCommander> warp10, Welcome to Cruft Busters :-)
[17:47] <NCommander> Now we just need some people to file some bugs
[17:48] <warp10> NCommander: indeed. IIRC you set up a wiki page, right?
[17:48] <NCommander> yeah
[17:49] <warp10> NCommander: link?
[17:49] <NCommander> Grabbing it
[17:50] <NCommander> warp10, https://wiki.ubuntu.com/CruftBusters
[17:50] <NCommander> comments, criticisms, concerns are welcome
[17:50] <azeem> cool, the new Launchpad doesn't let me add comments to bugs
[17:50] <azeem> (we're still using sarge at the uni)
[17:50] <warp10> NCommander: ah, yeah... /me subscribes to the page
[17:51] <NCommander> I'd like to work on removing older GCCs from the archive
[17:51] <NCommander> Probably a good place to start anyway
[17:51] <NCommander> ANd firefox2
[17:53] <warp10> NCommander: Indeed. What about opening the LP ML for the team?
[17:53] <NCommander> warp10, I put a request in
[17:53] <warp10> NCommander: that would be a good place to discuss these topics
[17:53] <NCommander> It says "The list will be available in a  few minutes"
[17:53] <NCommander> So LP must have it almost set up
[17:54] <warp10> NCommander: ah, great... the last ML I requested needed manual approval by LP admins
[17:55]  * persia notes that the CC has asked for teams to be created on lists.ubuntu.com instead of lists.launchpad.net when they are for Ubuntu purposes.
[17:56] <jpds> Requests for new Ubuntu mailing lists should be sent to rt@ubuntu.com.
[17:57] <warp10> persia: ah, right: good point. I forgot that
[17:57] <NCommander> CC?
[17:57] <RainCT> NCommander: community council? :)
[17:59] <persia> NCommander: They who are the ultimate arbiters of all things Ubuntu
[17:59]  * NCommander hides in fear of them
[18:00] <warp10> NCommander: irrelevant: resistance is futile!
[18:00]  * RoAkSoAx saludos :)
[18:00] <NCommander> I dunno what I should even email them to ask about the list
[18:01] <persia> NCommander: Just send an email to rt@ with text like "Please activate the $foo list for $purpose".
[18:01] <persia> That said, I don't think you need a special list for the cruft-busters.
[18:02] <jpds> NCommander: With a link to team page and LP. Etc, etc.
[18:02] <NCommander> well, if this project becomes at all popular, then I'll do that
[18:02] <persia> NCommander: What do you imagine as a use for the email list?
[18:03] <NCommander> persia, decision of packages to be removed, and questions Cruft Busters
[18:03] <persia> If it's coordination, it's probably better to do here, or on ubuntu-motu@ or ubuntu-devel@ if absolutely required (although universe has more cruft than main)
[18:03] <persia> That's definitely much better on those lists.
[18:03] <NCommander> ok, we stay on motu unless people bitch
[18:03] <persia> !ohmy
[18:03] <persia> :p
[18:04] <NCommander> people get steamed and act like Debian Developers.
[18:04] <NCommander> Happy now persia ?
[18:04] <warp10> LOL
[18:04] <jpds> !lol
[18:04] <jpds> :p
[18:04] <persia> Well, no, but I don't have as easy a time complaining about that.
[18:04] <laga> omg
[18:05] <persia> Grrrr..  Why on earth should one run ./configure during clean!
[18:05] <warp10> jpds: argh :P
[18:06] <RainCT> warp10: I understand how you feel :P
[18:06] <warp10> RainCT: :D
[18:11] <jpds> warp10: /msg ubottu !prayer
[18:12] <tgm4883_laptop> To upload a change to something I already uploaded to REVU, do I just use the -f flag or is there another way?
[18:13] <persia> tgm4883_laptop: Remove the .upload file.
[18:14]  * persia grumbles about libgtk1.2 being part of the recommends stack for devscripts, and wonders if anyone feels like trying to finally kill GTK1.2
[18:14] <slytherin> tgm4883_laptop: -f should work
[18:15] <tgm4883_laptop> ok, i pushed it.  I'll check it in 5 minutes to see if it worked automatically
[18:15] <slytherin> persia: me, me, gtk1.2 has really lived its life.
[18:15] <warp10> jpds: :D I am wondering how many else command there are that I don't know... /me looks for a list
[18:15] <directhex> noo, 1.2 is still needed!
[18:15] <persia> slytherin: You're famously busy right now, but if you think you've time to port the remainders to gtk2+, I shan't complain that much.
[18:15] <directhex> iirc vmware-agent, which handles resizing the desktop in linux guests when you resize the vmware window, is linked against 1.2
[18:16] <persia> directhex: For what?  You do know it's incapable of rendering in most locales at this point, don't you?
[18:16] <slytherin> persia: once I am done with java FTBFS. :-D
[18:16] <persia> directhex: Get a real VM :p
[18:16]  * slytherin still has only 512MB RAM. So no VM.
[18:21] <persia> slytherin: On that note, did you get a chance to update the MoveToUniverse page?
[18:22] <slytherin> persia: no. was too busy. have much free time today with no office tomorrow. So will do now.
[18:23] <persia> slytherin: Excellent.  I've some time blocked in about 17 hours to review it :)
[18:23] <slytherin> persia: of course I have a write a testimonial and a hello planet post before that. :-)
[18:23] <persia> heh
[18:23] <slytherin> but should be done in 2 hours.
[18:47] <slytherin> persia: geser: I wonder why none of you is on Planet Ubuntu.
[18:48] <persia> slytherin: I don't write anything of interest for there.
[18:49] <slytherin> persia: But you have a blog, right?
[18:49] <persia> slytherin: Nope.
[18:49] <slytherin> oh
[18:49] <persia> When I'm doing well, I put as much as 10Kb a day here, and similar in email.  Blogging just seems redundant at that point.
[18:50] <slytherin> :-)
[18:51] <persia> (plus nobody wants to read a blog about ways to package and pointless device classes: they would rather have their questions answered.
[18:56] <tacone> is there a command to know if a given .deb file have all dependancies satisfied and can be installed ?
[18:57] <persia> tacone: dpkg -i
[18:57] <tacone> persia: don't that actually installs the deb ?
[18:57] <tacone> s/don't/doesn't/
[18:57] <persia> Ah.  dpkg --no-act -i
[18:57] <tacone> oh. thanks :)
[18:58] <persia> --simulate also works, if you like typiing more characters, or find it easier to remember
[18:58] <tacone> nice
[19:55] <slytherin> tacone: in case yiu have gdebi installed and using gnome, just double click the deb
[20:22] <tacone> slytherin: thanks, I was looking for a programatic method, anyway :)
[20:34] <sistpoty> ah... those desktop effects somehow snug into my kde and are right now making me nervous *g*
[20:35] <sebner> sistpoty: I'm near to use ohmy! for your k word :P
[20:35] <sistpoty> haha
[20:36] <sistpoty> sebner: well, anything better out there with which I can stay at my favourity mua (which doesn't manage to sign mail currently however)? *g*
[20:36] <sistpoty> favourite even
[20:37] <sebner> sistpoty: mua?
[20:37] <sistpoty> sebner: mail user agent
[20:37] <sebner> sistpoty: I don't use/like evolution :P
[20:37] <sebner> TB ftw"
[20:37] <sebner> !
[20:37] <sistpoty> sebner: hehe, neither do I (it starts with a k *g*)
[20:38] <sebner> sistpoty: kevolution? :P
[20:39] <sistpoty> sebner: yep, just a little bit more lightweight... but I have the feeling that this might change soonish *g*
[20:39] <sebner> sistpoty: to TB? very good choice :D
[20:39] <sebner> huhu YokoZar
[20:39] <sebner> YokoZar: are the staying with stable wine branch?
[20:40] <YokoZar> sebner: I'm not certain actually.  Wineconf happens to be in September so I plan on asking around there about the best way forward
[20:41] <sebner> YokoZar: kk :)
[20:41] <sistpoty> sebner: btw.: still unaddressed bug from me: bug #245591 *eg*
[20:41] <YokoZar> sebner: My main concern is no regressions compared with 1.0 for whatever version we use.  Wine's not making another stable release, but maybe someone could make a "semi-stable" release that at least passes that (namely Dan Kegel, Wine 1.0's release manager, who happens to be a big Ubuntu guy :) )
[20:42] <sebner> YokoZar: well, regressions .. bad but new unstable releases may support new apps/games since a lot improvements happened
[20:42] <sebner> sistpoty: gnome-terminal does what you want :P
[20:42] <sistpoty> haha
[20:43] <sebner> sistpoty: lol! just read your comment xD
[20:43] <slytherin> sistpoty: I head claws-mail is good, never tried though.
[20:43] <sistpoty> slytherin: but claws-mail is no window-manager, is it? *g*
[20:44] <sebner> sistpoty: ehm. question: why ctrl-alt-n? I open a new tab with ctrl+t
[20:44] <slytherin> sistpoty: I was replying to your MUA comment
[20:44] <sistpoty> slytherin: the point is that I want to stay with it... after so many years of fighting its bugs *g*
[20:44] <slytherin> :-)
[20:45] <sebner> sistpoty: stockholm syndrom :P
[20:45] <YokoZar> sebner: I know, but not having regressions is like a main feature of Ubuntu :)  -- in the past I didn't care too much, but now that we have an actual stable release we're upgrading from expectations are different
[20:45] <slytherin> At office I use Ubuntu like Windows. I use whatever apps are installed by default. :-P .... except the fact that I installed terminator. :-)
[20:45] <sistpoty> sebner: it always used to be ctrl-alt-n for konsole... my fingers have learned that shortcut (and it's easier to type than ctrl-t, as n is right-hand whereas t is left-hand together with left-hand modifier key)
[20:46] <sebner> YokoZar: True but as we passed LTS ... I want to see intrepid more like edgy :P
[20:46] <sebner> sistpoty: makes no sense to me xD
[20:46] <laga> you want intrepid to be more unstable than hardy? ;)
[20:47] <sebner> laga: intrepid unstable *is* more stable than hardy :P
[20:47] <sistpoty> sebner: may I blame you user of the "adler-such-system"? :P
[20:47] <ScottK> YokoZar: Maybe we should have two packages then.  wine and wine-unstable or some such.
[20:47] <laga> haha
[20:47] <sebner> sistpoty: hrhr
[20:47] <sebner> ScottK: seems double work to me and not worth it
[20:48] <ScottK> We could use Debian as the basis for wine and let YokoZar go nuts on wine-unstable so not double work.
[20:48] <ScottK> Probably a little extra bugfixing, but no worries about regressions.
[20:49]  * sebner say: You little stable fanboys and runs away xD
[20:49] <sebner> *says
[20:49] <sistpoty> ScottK: not too sure about this... this would shift primary attention to wine (as from unstable), right?
[20:50] <sebner> sistpoty: version: 4:4.0.83-0ubuntu2 --> may update to current version if it still happenes
[20:50] <sistpoty> ScottK: maybe the same idea but have wine-stable and wine?
[20:50] <ScottK> Maybe.
[20:50] <ScottK> Generally I think you want people who don't now much to install the stable one, so I like my approach better, but either way.
[20:51] <sistpoty> *shrug*
[20:51] <YokoZar> ScottK: At this point our Wine package for 1.0 is superior to the Debian one for other reasons
[20:51] <ScottK> OK.
[20:51] <sistpoty> sebner: no idea... I've configured my shortcut the way I like it, and it works now *g*
[20:51] <ScottK> Just trying to maximize benifit and minimize pain.
[20:53] <sebner> sistpoty: then be happy with it :P
[20:53] <sebner> huhu norsetto
[20:53] <norsetto> hi sebner
[21:00] <sistpoty> sebner: btw.: I still haven't seen a motu-application from you... gogogo ;)
[21:01] <sebner> hrhr
[21:01] <sebner> sistpoty: ask norsetto :P
[21:02] <sistpoty> sebner: I doubt norsetto will fill in the application for you :P
[21:02] <sebner> sistpoty: but I think in 1-2 months so it doesn't make sense before release so end october I think
[21:04] <sistpoty> sebner: don't be shy. apply now ;)
[21:04] <sebner> sistpoty: no no. first some other things to do ;)
[21:05] <sistpoty> superm1: FYI I'm starting merging nvidia-settings now
[21:05] <superm1> sistpoty, okay sounds good.  i wasn't going to get to it again until sundayish so that should be fine
[21:06] <sistpoty> kk
[21:07] <sistpoty> superm1: just OOI, you specified lp bugs with LP: #bugno,bugno,bugno... does that work? (as vim doesn't seem to highlight it correctly)
[21:07] <crimsun> yes, it does.
[21:07] <superm1> sistpoty, it should work
[21:08] <crimsun> oh wait, no
[21:08] <crimsun> you need LP: #foo, #bar, #baz
[21:08] <crimsun> the leading hash is necessary
[21:08] <sistpoty> crimsun: hm... OTOH bug #195241 seems to prove that it at least did work in the past
[21:13] <crimsun> ah, it's \s*
[21:14] <crimsun> (?:,\s*\#\d+)*
[21:15] <crimsun> but that's just for generating the source package
[21:16] <crimsun> (and is that private due to the stack trace?)
[21:17] <sistpoty> (probably more due to coredump, but I guess so)
[21:23] <slytherin> wow, hamster-applet is an approved module of next GNOMErelease.
[21:26] <Laney> ember: Hey, did you forward your disable update notification patch for Wordpress to Debian?
[21:27] <Laney> (just got annoyed by it on my Debian server)
[21:30] <alex-weej_> http://alex-weej.blogspot.com/2008/08/sucata-run-2008.html
[21:31] <alex-weej_> http://alex-weej.blogspot.com/2008/08/sucata-run-2008.html
[21:33] <laga> nice car. you bought it because of the head unit, right?
[21:36] <laga> alex-weej_: so the goal of the whole race is to raise 1000 pounds?
[21:36] <alex-weej_> laga: just our team haha
[21:36] <alex-weej_> there are about 100 teams
[21:36] <alex-weej_> btw sorry for double post, i thought /amsg was only network-wide
[21:36] <alex-weej_> i did it once here and then again on gimpnet :S
[21:36] <alex-weej_> i am now getting loads of abuse
[21:37] <alex-weej_> way to shoot myself in the foot
[21:37] <alex-weej_> and yes, the head unit is pretty awesome haha
[21:37] <alex-weej_> dog saliva less so
[21:37] <alex-weej_> and it's not a race, we will die if it's a race!
[21:39] <laga> alex-weej_: best of luck. looks like an awesome event
[21:39] <alex-weej_> cheers :D
[21:39] <alex-weej_> we are 3% of the way lol
[21:39] <laga> although 1000 pounds isn't that much compared to the amount of money spent on cars and gas ;)
[21:40] <alex-weej_> before anyone else grills me for spam, sorry. "/amsg" works for all networks at once in X-Chat, CAUTION!
[22:06] <sistpoty> did I grumble about ubuntu breaking reportbug yet?
[22:06] <sebner> sistpoty: nope
[22:06] <sistpoty> *grml* about ubuntu breaking reportbug *g*
[22:09] <sistpoty> aha, the world is small, so henning (whom I met once and smoked some pot^W cigarettes with) reported a bug about ubuntu's reportbug as well *g*
[22:10] <Laney> Luckily reportbug -B debian still works
[22:11] <sebner> sistpoty: a bug about the bugreporting tool? doesn't this break *everything*? ^^
[22:12] <sistpoty> Laney: nope, it doesn't... it relays via fiordland even if told otherwise :(
[22:12] <sistpoty> sebner: hehe, the universe will explode now *g*
[22:12] <sebner> sistpoty: tick tick tick
[22:12] <Laney> sistpoty: Oh, I think I edited the smtp server in reportbug.conf
[22:12] <sebner> BUMMMMMMMMMMMMMMMm
[22:19] <NCommander> does anyone know if the .changes files on things uploaded to either Ubuntu or Debian are saved
[22:19] <sistpoty> NCommander: actually these are published on the changes-lists
[22:19] <NCommander> Or given a package, and its dsc, a quick way to regenerate the .changes file without rebuilding every source package?
[22:19]  * NCommander was hoping for something he could wget ...
[22:20] <sistpoty> NCommander: the changes-lists are public, so you can wget these
[22:20] <sistpoty> NCommander: e.g. https://lists.ubuntu.com/mailman/listinfo/intrepid-changes
[22:20] <NCommander> I need to generate .changes for every source package and a few thousand binary packages for importation into dak
[22:21] <NCommander> I was hoping for a format that would be easier to parse ;-)
[22:21] <sistpoty> NCommander: maybe dpkg-genchanges might also be s.th. what you're looking for?
[22:21] <jpds> NCommander: https://edge.launchpad.net/ubuntu/intrepid/+source/irssi-plugin-otr/0.2-1
[22:22] <jpds> NCommander: There's a "View changesfile" link to the .changes
[22:22] <sistpoty> jpds: an now for a ppa :P
[22:22] <NCommander> That's a start
[22:22] <NCommander> Do you know if something like that exists for Debian?
[22:22] <jpds> sistpoty: https://edge.launchpad.net/~jpds/+archive
[22:22] <jpds> "(changesfile)"
[22:23] <NCommander> sistpoty, dpkg-genchanges requires you to rebuild the source package
[22:23] <sistpoty> jpds: (phew) no changes file public there :)
[22:23] <slytherin> persia: added some packages for evaluation to MoveToUniverse page.
[22:23] <NCommander> very painful when your dealing with the entire Debian archive
[22:23] <sistpoty> NCommander: for debian, there is a list as well, but I've never managed to recall the list url
[22:24] <jpds> sistpoty: Actually.. it is.
[22:24] <sistpoty> jpds: but only for your own ppa hopefully?
[22:24] <sistpoty> jpds: otherwise I'd subscribe you to bug #159304
[22:25] <jpds> sistpoty: Ah, good point.
[22:27] <sistpoty> jpds: oh my, I just found your changes file by guessing :(
[22:27] <sistpoty> (signed even)
[22:28] <jpds> Really should chmod 0600 like REVU.
[22:29] <NCommander> why aren't changes files that publically accessible? (it seems they are never pubically shown anywhere)
[22:30] <jpds> NCommander: Because if it has not been uploaded to Ubuntu/Debian, someone can grab the source package and upload it themselves.
[22:31] <NCommander> I meant more like files that have bene uploaded
[22:31] <sistpoty> NCommander: .changes files are basically tickets
[22:31] <sistpoty> NCommander: they are only meant to grant access for *one* upload
[22:32] <sistpoty> NCommander: after that the version is in the archive, and no other upload with the same .changes file is valid (aka the ticked has expired)
[22:32] <NCommander> yeah
[22:32] <NCommander> Its just anonying because dak has no mechanism it seems to import without each file having a changes
[22:32] <NCommander> You can easily see how that's going to get anonying real quick
[22:33] <sistpoty> NCommander: actually I doubt that you'll need to rebuild a package to generate a .changes file
[22:33] <sistpoty> (at leat an unsigned one)
[22:33] <NCommander> The .dsc and the changes aren't that different
[22:33] <NCommander> I can probably cook a utility to do the changes
[22:34] <sistpoty> NCommander: from an archive POV the .dsc is a description of the (source) package
[22:34] <NCommander> But there is a depricated "import-archive" dak command that can. in theory, do what I want
[22:34] <sistpoty> NCommander: while the .changes file is only a "ticket"
[22:34] <NCommander> I meant the contents are similar
[22:34] <NCommander> Its only a few changed fields between the two
[22:35] <sistpoty> NCommander: not really... the .dsc describes parts of the source package... the .changes parts of the *upload*
[22:35] <sistpoty> NCommander: it's quite different if you add binary packages to it
[22:35] <sistpoty> (to the upload)
[22:35] <NCommander> I just need to import source packages ATM
[22:35] <NCommander> Well, this archive importer might do what I need it to
[22:37] <NCommander> I still will need to build a source package builder to roll any new source packages
[23:16] <NCommander> I need some regex help
[23:16] <NCommander> If I got the name the full name of the dsc file, how can I determine the orig package file
[23:16] <NCommander> i.e hello_2.2-2.dsc to hello_2.2.orig.tar.gz
[23:27] <RainCT> NCommander: Python?
[23:51] <sistpoty> gn8 everyone