[00:00] <slangasek> jaredthane: ok.  for that particular request, it is best to package it as part of the existing php5 package, so the typical "intro to packaging" guides aren't going to help you there - you would need to dig into the php5 package specifically and understand how it's put together
[00:02] <jaredthane> slangasek: okay, do any simple, useful examples come to mind?
[00:02] <slangasek> not to me, sorry
[00:02] <slangasek> everything I use is already packaged :)
[00:06] <slangasek> jaredthane: for places to help out with Ubuntu that don't involve creating new packages from scratch, there's https://launchpad.net/ubuntu/+bugs?field.tag=bitesize
[00:07]  * Fujitsu thinks the world must be coming to an end.
[00:08] <Fujitsu> The RM helping in #-motu...
[00:08] <jaredthane> slangasek: thanks
[00:08] <LaserJock> Fujitsu: it makes me feel all warm and fuzzy inside
[00:08] <LaserJock> :-)
[00:09] <sistpoty> Fujitsu: that's why he got a +1 from me when going for motu after a few hours ;)
[00:09] <Fujitsu> sistpoty: Heh, yes.
[00:10] <slangasek> Fujitsu: if it's upsetting your world view that much, I can go away again ;)
[00:10] <Fujitsu> Please don't.
[00:11] <DaveMorris> RM?
[00:11] <sistpoty> release manager
[00:15] <LaserJock> any vim people around?
[00:16]  * Fujitsu is a vimmer.
[00:16] <DaveMorris> LaserJock: just ask ;)
[00:16] <Fujitsu> !ask | LaserJock
[00:16] <ubotu> LaserJock: Don't ask to ask a question. Just ask your question :)
[00:16] <LaserJock> I'm trying to fix a bug involving vim-latexsuite
[00:16] <Fujitsu> :P
[00:16] <Fujitsu> Aha.
[00:16] <LaserJock> yeah yeah yeah
[00:16] <Fujitsu> I haven't used -latexsuite in a while.
[00:17] <LaserJock> vim can't find the files
[00:17] <LaserJock> it installs to /usr/share/vim/addons/
[00:17] <LaserJock> but that's not in vim's path
[00:17] <LaserJock>  /var/lib/addons/ is
[00:18] <LaserJock> I'm wondering if there's some policy that would help me decide what to do
[00:18] <LaserJock> I would think that /usr/share/ would be the FHS place to put it
[00:19] <Fujitsu> That's where it should go.
[00:19] <slangasek> LaserJock: AIUI, there's some kind of vim policy (at least in Debian) that newly-installed add-ons shouldn't be enabled by default, to not trigger disgruntlement of other users?
[00:20] <LaserJock> hmm
[00:20] <LaserJock> apparently it used to work
[00:20] <LaserJock> which has disgruntled many vim+TeX users
[00:20] <LaserJock> now that it doesn
[00:20] <Fujitsu> It did previously work, yes...
[00:21] <Fujitsu> slangasek: It doesn't do anything too evil.
[00:21] <LaserJock> now, there is the vim-addon-manager package
[00:21] <LaserJock> which allows you to turn things off and on
[00:23] <LaserJock> I can see that policy for vim-scripts because people will pick and choose
[00:23] <LaserJock> but vim-latexsuite only does one thing
[00:24] <LaserJock> but I see what you're saying about multiple users and turning on systemwide
[00:39] <LaserJock> ok, I got it figured out, phew
[00:40] <LaserJock> Fujitsu: would this be an "Invalid" bug then?
[00:42] <Fujitsu> LaserJock: What is the problem?
[00:42] <LaserJock> that latexsuite is not enabled by default
[00:42] <Fujitsu> Ah.
[00:42] <LaserJock> which is now the vim policy
[00:43] <Fujitsu> Probably Invalid.
[00:50] <sistpoty> DaveMorris: debian/copyright could be a bit more verbose about upstream copyright (copy one of the source files copyright notice verbatim there)
[00:57] <joejaxx> anyone getting HTTP 403 on securitu.u.c?
[00:57] <joejaxx> security.ubuntu.com*
[00:58] <keescook> joejaxx: yup, expected, should be cleared up shortly.
[00:59] <joejaxx> ok
[01:01] <crimsun> joejaxx: 163042.
[01:01] <joejaxx> ok
[01:08] <LordKow> um which package provides merge-buildpackage?
[01:09] <crimsun> it's part of MoM.  No Freely-available source package currently provides it.
[01:10] <LordKow> ah i see, <3 MoM
[01:10] <crimsun> well, unless you count grab-merge.sh
[01:11] <crimsun> grab-merge.sh is available at http://merges.ubuntu.com
[01:11] <pwnguin> autoreconf -i
[01:11] <pwnguin> configure.ac:7: error: possibly undefined macro: AC_ENABLE_SHARED
[01:12] <pwnguin> ideas?
[01:13] <crimsun> probably autotoolage scew.
[01:13] <crimsun> err, skew, but screw, too.
[01:13] <sistpoty> pwnguin: do you have libtool installed?
[01:14] <crimsun> and which version of automake is installed?
[01:14] <pwnguin> apparently not
[01:14] <sistpoty> hi crimsun btw ;)
[01:14] <pwnguin> sistpoty: that's the trick
[01:15] <crimsun> hi sistpoty
[01:15] <sistpoty> you're welcome... /me is fighting automake at work as well *g*
[01:15] <pwnguin> well, i thought apt-get build-dep would get the build deps
[01:15] <crimsun> pwnguin: autotoolising stuff generally requires the libtool&automake&autoconf stack
[01:15] <sistpoty> (which means that I'm far from having tamed automake yet *g*)
[01:15] <pwnguin> theres already a package, but i thought i'd build from svn
[01:21] <LordKow> ugh whats the best way to do the merge process with pbuilder?
[01:21] <pwnguin> configure: error: Your intltool is too old.  You need intltool 0.35.0 or later.
[01:21] <LordKow> i'd rather not be installing a ton of build-depends on my main system :P
[01:21] <minghua> LordKow: pbuilder has a "login" command.
[01:22] <LordKow> yea but how do i transfer files to the pbuilder environment from outside?
[01:22] <pwnguin> maybe i'll just write the patch from the package source and let upstream handle the merge =/
[01:23] <minghua> LordKow: Just copy them over?  The chroot is under /var/cache/pbuilder/build/.
[01:24] <LordKow> ah duh i could have just looked at the mount output from outside of the env to figure that out, thnx
[01:27] <jdong> LordKow: if you do this often it's a good idea to set up a --bindmount so that you can always share stuff from your outside world :)
[01:27] <crimsun> uh oh, jdong applied for -dev
[01:27] <LordKow> yea going through the pbuilder man right now
[01:27] <crimsun> time for revenge on the backports!!one
[01:28]  * Hobbsee waves
[01:28] <sistpoty> ha, luckily I needn't ask questions any longer, otherwise my first question would've been: "jdong: but you're on crack!" ;)
[01:28] <jdong> crimsun: lol :)
[01:28] <zul> evening
[01:29] <minghua> jdong: I hope you mean --bindmounts.
[01:29] <jdong> minghua: yeah, those thingies :)
[01:31] <crimsun> jdong's +1 will likely be my last vote as an MC member, heh
[01:32] <sistpoty> so crimsun makes me feel guilty again for starting a wave of retirings :(
[01:33]  * jdong hugs crimsun 
[01:33] <crimsun> sistpoty: mine was scheduled way back in July
[01:34] <sistpoty> crimsun: ha, I've been thinking about it earlier, just didn't write a mail yet :P
[01:34] <crimsun> yeah, Daniel and I are going to wrap up, and then I'll be sending off the e-mail.
[01:35] <crimsun> jdong: remember: use this power for good
[01:35] <sistpoty> it's sad to see an experienced member go from -council
[01:36] <jdong> crimsun: you mean "with great power comes great responsibility"? :)
[01:36] <Hobbsee> sistpoty: that was my thought, yes.
[01:36] <Hobbsee> (the crack one(
[01:36] <Hobbsee> !jdong | jdong
[01:36] <ubotu> jdong: <Hobbsee> jdong: yes, but you're FULL OF CRACK!
[01:36] <sistpoty> haha
[01:36] <crimsun> sistpoty: well, it has been quite something for the first round.  Looking forward to better things from the next MC.  Turnover can be healthy.
[01:37] <Hobbsee> crimsun: surely you cant leave.
[01:37] <crimsun> Hobbsee: sure, I would just need to find another job
[01:37] <sistpoty> crimsun: sure it can, and I really hope for it (and did so when resigning..) nonetheless it does make me sad
[01:38] <Hobbsee> crimsun: more alsa?
[01:38] <crimsun> haha
[01:38] <tarzeau> there's no webfrontend for requestsync ?
[01:39] <sistpoty> tarzeau: sure, LP and enter your wish by hand ;)
[01:39] <tarzeau> sistpoty: i thought of a input field like a command line for it
[01:39] <LordKow> um do i really need to use the merge-buildpackage / merge-genpackage script... it looks like i should just be able to build the package like I would any other
[01:40] <sistpoty> tarzeau: no, it's the other way round: requestsync is the frontend for filing a bug (with a specific title and content) on launchpad
[01:40] <tarzeau> sistpoty: yes and i wanted to just have a frontend for requestsync
[01:40] <tarzeau> since installing it on debian sid is like horribly not possible
[01:40] <Hobbsee> LordKow: have a look at the scripts.  it has a particular option on it
[01:40] <crimsun> LordKow: no, you don't.  e.g., I just edit shell command history and proceed.
[01:40] <Hobbsee> tarzeau: uh....why?
[01:41] <tarzeau> ubuntu-dev-tools depends on python-launchpad-bugs (>= 0.2.14); however:
[01:41]  * Hobbsee notes that with frontends, more idiots will file them, and then we'll all have to close them.
[01:41] <sistpoty> tarzeau: having not used it ever, I go with "please sync <packagename> (<version>) from unstable ubuntu override ok" and adhere to the policies in the rest of the bug. worked for me in the past ;()
[01:41] <Hobbsee> tarzeau: it's a script.  just nuke it from the package.
[01:41] <tarzeau> Hobbsee: ok i try that
[01:41] <LordKow> exec dpkg-buildpackage -S -v0.2.3-2ubuntu1 "$@" <-- thats all merge-buildpackage does... its specific for each package but its 1 command :P
[01:42] <Hobbsee> LordKow: yes, and you need to use -v0.2.3-2ubuntu1 in it
[01:42] <sistpoty> and once my manual sync request will no longer get processed, I'll either make a rebellion or will shut up forever (probably the second *g*)
[01:42] <Hobbsee> (does special things with the source changes.
[01:42] <crimsun> meaning, preserving (displaying) the relevant upstream changelog entries is a matter of policy.
[01:44] <tarzeau> i read the part about requestsync at https://wiki.ubuntu.com/SyncRequestProcess
[01:44] <tarzeau> what's target release? hardy for example?
[01:44] <Hobbsee> the development release.  so hardy, yes.
[01:45] <LordKow> crimsun, do you know if aclock.app is in the process of being merged or not? its a 5 second thing with the control file
[01:45] <Hobbsee> make sure you use -s, it's the sponsorship section
[01:45] <tarzeau> Hobbsee: that script fails for some reason, and i've got no clue of python
[01:45] <Hobbsee> ....right.
[01:46] <Hobbsee> no clue of debugging either, it appears.  "fails for some reason", no reason given.  *sigh*.
[01:46] <crimsun> LordKow: generally, check https://bugs.launchpad.net/ubuntu/+source/$source_package_name/
[01:46] <Hobbsee> tarzeau: i'm not psychic, sorry.
[01:46] <tarzeau> Traceback (most recent call last): File "./requestsync", line 119, in ?
[01:46] <LordKow> "There are currently no open bugs." guess not, thanks
[01:46] <crimsun> LordKow: if you don't see a bug report requesting a merge/sync, then generally, no, it's not in the process.
[01:46] <tarzeau>     debiancomponent = debian_component(srcpkg)
[01:46] <tarzeau>   File "./requestsync", line 75, in debian_component
[01:46] <tarzeau>     raw_comp = out.split('|')[2].split('/')
[01:46] <tarzeau> IndexError: list index out of range
[01:46] <Hobbsee> oh, requestsync is possibly broken now, with the rmadison change, too
[01:47] <LordKow> crimsun, well then i shall start the process
[01:47] <crimsun> LordKow: excellent.
[01:47] <Hobbsee> ah, no, it's not.  the old behaviour still works.
[01:48] <Hobbsee> tarzeau: weird.
[01:49] <tarzeau> what about a bot that takes syncrequests right in here? ;)
[01:49] <Hobbsee> tarzeau: because if you make it like that, people think it's acceptable to mass file sync requests.
[01:49] <Hobbsee> and tend to not check the changes first.
[01:49] <Hobbsee> requestsync is not to be abused.
[01:50] <tarzeau> i see
[01:50] <Hobbsee> and because they're signed.
[01:50] <Hobbsee> tarzeau: if you make it easy, even like having that shell sript in there, people seem to use logic like "well, i fthere's a new version in debian, who cares about any ubuntu changes, lets just drop them all"
[01:51] <tarzeau> i've wanted to request two new packages
[01:51] <tarzeau> and this syncing stuff is all done fully manually?
[01:52] <Hobbsee> new pacakges are done automatically
[01:52] <Hobbsee> stuff that has ubuntu changes getting synced is manual
[01:52] <tarzeau> i see
[01:53] <tarzeau> not even half-automatic?
[01:53] <Hobbsee> obviously.  it needs checking
[01:53] <Hobbsee> well, they have a script that then goes and syncs
[01:53] <Hobbsee> but someone has to check if teh changes are still required, etc
[01:53] <tarzeau> i see
[01:54] <Hobbsee> which is why making this stuff easy to run is suboptimal - because people dont do the work required to check if stuff is needed, first.
[01:54] <LordKow> https://bugs.launchpad.net/ubuntu/+source/aclock.app/+bug/163165 why is this invalid?
[01:54] <ubotu> Launchpad bug 163165 in aclock.app "Please sync aclock.app 0.2.3-2  (universe) from Debian unstable (main)" [Undecided,Invalid]
[01:55] <crimsun> 16 Nov 07 18:54   Marco Rodrigues  aclock.app: status  New  Invalid
[01:56] <LordKow> oh its been synched sweet
[01:56] <crimsun> yep. :)
[01:56] <LordKow> still not an "invalid" report though :P
[01:56] <crimsun> well, it is
[01:56] <LordKow> if it has been synched why is it still showing on MOM?
[01:56] <crimsun> MoM is not definitive
[01:57] <minghua> That bug got the version number wrong.  Is it verbatim output from requestsync?
[01:58] <crimsun> I believe it's actually correct.
[01:59] <crimsun> according to the hardy-changes list, that is.
[01:59] <crimsun> https://lists.ubuntu.com/archives/hardy-changes/2007-November/001713.html
[01:59] <crimsun> so the times seem to link up correctly
[01:59] <Hobbsee> mom is not always updated
[02:00] <crimsun> so at the time the sync was requested, the synced source had not been published via the hourly run
[02:03] <minghua> I see.
[02:05] <sistpoty> gn8 everyone
[02:15] <bddebian> Heya gang
[02:33] <LordKow> hm weird dependency problems with balsa and an up-to-date pbuilder env
[02:33] <LordKow> cant even build the version in the repos
[02:40] <jdong> LordKow: have you set up your pbuilder to use universe?
[02:40] <LordKow> you know... i may not have. i did at one point but i think i redid the pbuilder env
[02:41] <crimsun> it's not enabled by default, so if you don't remember, you most probably didn't.
[02:42] <LordKow> well thats the thing. i remember doing it the FIRST time but not after i redid pbuilder ;)
[02:50] <LordKow> this build should be more successful :p
[02:52] <jdong> siretart: wrt bug #159085, I'm assuming the new version is ABI/API compatible with all the gutsy reverse-deps?
[02:52] <ubotu> Launchpad bug 159085 in gutsy-backports "please backport xine-lib_1.1.8-2ubuntu2 from hardy" [Undecided,New] https://launchpad.net/bugs/159085
[02:55] <RAOF> jdong: That's surely not happening.  A good portion of Universe rdepends on xine-lib :)
[02:56] <jdong> RAOF: well I don't know enough about the Xine release cycle to understand what a 0.0.1 bump constitutes...
[02:56] <jdong> and since siretart filed the report, I am assuming he knows what he's doing :D
[02:56] <RAOF> jdong: Oh, I thought we had 1.6 in gutsy.  Ah, whoops.  Yeah :)
[02:58] <jdong> wow, this apbs thing takes bloody forever to build
[02:58]  * jdong considers enlisting his macbook to build too :D
[03:00]  * RAOF suddenly realises why he's getting an obsolete nouveau package.  s/gutsy/hardy/!
[03:03] <jdong> TheMuso: you have any idea what's going on in bug 158706?
[03:03] <ubotu> Launchpad bug 158706 in gnunet-gtk "gnunet-gtk crashed with SIGSEGV" [Undecided,Fix committed] https://launchpad.net/bugs/158706
[03:08] <RAOF> Is anyone actually doing the deluge-torrent merge/sync?  Is bug #139518 having anything done to it?
[03:08] <ubotu> Launchpad bug 139518 in deluge-torrent "Please sync deluge-torrent 0.5.6.2-1 from debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/139518
[03:09] <crimsun> No one appears to have committed to it, RAOF.
[03:10] <crimsun> i.e., it's all yours
[03:10]  * RAOF updates the bug status.
[03:11] <LordKow> bug 163261
[03:11] <ubotu> Launchpad bug 163261 in balsa "New upstream release 2.3.20" [Undecided,New] https://launchpad.net/bugs/163261
[03:13] <crimsun> LordKow: careful.  Your _source.changes doesn't adhere to Ubuntu policy regarding including all debian/changelog entries between the most recent merged Debian source package and the current one.
[03:17] <LordKow> um, which ones are missing?
[03:18] <crimsun> 2.3.19-1 and 2.3.20-1
[03:18] <crimsun> note that I'm referring to https://bugs.edge.launchpad.net/ubuntu/+source/balsa/+bug/163261/comments/1
[03:18] <ubotu> Launchpad bug 163261 in balsa "New upstream release 2.3.20" [Undecided,New]
[03:19] <crimsun> s/edge\.// if you aren't a member of the LP beta testing team
[03:19] <LordKow> oh i forgot -v
[03:19] <crimsun> (correct
[03:19] <LordKow> they're there its just a screwd up changes file, let me rebuild
[03:19] <jdong> crimsun: does backport bug #163033 look sane to you?
[03:19] <ubotu> Launchpad bug 163033 in gutsy-backports "alsa-driver-1.0.15 and assorted newly minted alsa goodies" [Undecided,New] https://launchpad.net/bugs/163033
[03:20] <crimsun> jdong: not particularly
[03:20] <LordKow> do i need to rebuild the package or can i just comment and say "the changelog is complete, i just forgot -v<last ver> in the changes"?
[03:20] <jdong> crimsun: that was my gut feeling. Can you briefly comment on the bug report why it's not a good idea?
[03:21] <LordKow> <-- lazy :p
[03:21] <crimsun> jdong: namely, what does symptoms does the reporter experience [that are fixed in 1.0.15 final] that the linux-backports-modules-$(uname -r) package in gutsy doesn't?
[03:21] <crimsun> jdong: s/does//
[03:21] <crimsun> $1, that is
[03:22] <jdong> crimsun: ah, so any missing alsa patches can be done via linux-backports-modules?
[03:22] <crimsun> jdong: correct, and Tim's/Ben's slated to upload the latest shortly, which contains 1.0.15 final plus a dmic fix for certain Dells
[03:23] <jdong> crimsun: thanks for the info!
[03:23] <crimsun> np
[03:23] <crimsun> [not to mention it's of no real benefit to pull in the "changes" to alsa-base and linux-sound-base, which is really what backporting would achieve in light of the l-b-m updates]
[03:24] <jdong> agreed
[03:26] <jdong> who tends to libotr2?
[03:26] <crimsun> no one.  It's a direct sync from Debian.
[03:26] <crimsun> or, technically, "MOTU" cares for it.
[03:27] <jdong> there's a backport request for hardy->gutsy on libotr and it has reverse-deps with gaim, kopete, and others and I wasn't sure of the compatibility
[03:27] <LordKow> crimsun, does my new changes make ubuntu policy happy? see last comment :)
[03:28] <jdong> so, I guess, my question is if anyone here is familiar with libotr? :)
[03:28] <crimsun> wow, from 3.0.0 (+cvs) to 3.1.0?  ...
[03:28] <crimsun> LordKow: looking now.
[03:29] <jdong> crimsun: the increment looks uneasy, and the person who filed the report is a fresh account so I'm inclined to just flat-out reject it unless someone familiar with otr can tell me this is safe.
[03:30] <crimsun> hehe
[03:30] <crimsun> well, when you're a MOTU, you get to test it, too!  ;)
[03:30] <LordKow> yes as a MOTU you are a massive tool
[03:31] <jdong> :D
[03:31] <jdong>  76 files changed, 6133 insertions(+), 5567 deletions(-)
[03:31] <jdong> gee.... not invasive at all
[03:32] <crimsun> well, it may not be on the magnitude of, say, azureus or xserver-xgl...
[03:33] <RAOF> xgl *may* be going away for hardy.
[03:33] <RAOF> As drivers get good enough to make it more of a hinderance than a help.
[03:33] <crimsun> that would be excellent.
[03:34] <LordKow> with regard to bug 163261, do i need to attach the new dsc, orig src and diff? they are the same just re-signed
[03:34] <ubotu> Launchpad bug 163261 in balsa "New upstream release 2.3.20" [Undecided,New] https://launchpad.net/bugs/163261
[03:34] <LordKow> (same as what is attached that is)
[03:34] <jdong> RAOF: let's hope that happens :)
[03:35] <crimsun> LordKow: you were able to drop the *_DISABLE_DEPRECATED comments in {libbalsa,libinit_balsa,src}/Makefile.* ?
[03:36] <crimsun> LordKow: (you wouldn't need to reupload a new source package.  My comment regarding debuild -v is largely informative.)
[03:37] <LordKow> was i able? MOM was. those were dropped upstream i believe
[03:38] <crimsun> if they are legitimately dropped, please note that in debian/changelog
[03:38] <crimsun> (bddebian was the latest to touch balsa and noted as much in the changelog)
[03:39] <bddebian> What'd I do wrong now?
[03:39] <crimsun> bddebian: hi.  Nothing wrong.
[03:39] <bddebian> :-) Hi crimsun
[03:41] <LordKow> those DISABLE_DEPRECATED comments are there
[03:42] <LordKow> i guess i dont quite understand what you are getting at.
[03:42] <crimsun> LordKow: ok.  Perhaps I'm being obtuse regarding the procedure.
[03:42] <jdong> wow pbuilder-satisfy-depends-dummy is REALLY slick!
[03:42] <LordKow> well, i'd prefer to get the procedure 100% correct so ... what are you getting at? :P
[03:43] <crimsun> LordKow: in the Ubuntu-specific changes listed in debian/changelog [in gutsy's balsa source package], note the top two (most recent) Ubuntu entries.
[03:44] <crimsun> LordKow: because your merged source package [for hardy] will be a new upstream balsa version, you need to ensure that all Ubuntu-specific changes noted in the most recent source package are still relevant
[03:45] <crimsun> LordKow: regardless if they are relevant, you need to note in the merged source package that either they have been dropped (and state a rationale) or they have been retained
[03:48]  * tonyyarusso googles
[03:49] <LordKow> so what you are saying is... if i keep those comments in the makefiles (noted in 2.3.17-1ubuntu2 changes) i still need to report that I'm keeping the makefile comments, or remove them and mention that they were completely removed?
[03:49] <Hobbsee> LordKow: correct
[03:49] <LordKow> i thought the changelog was for changes only. im not changing anything by leaving those comments there am i?
[03:50] <Hobbsee> LordKow: so that when you do something with it next release, you dont have to read 10 billion changelog entries, and wonder what you did, and why you did them, and if they're still relevant.
[03:51] <LordKow> okay i'll go ahead and drop the comments and modify the changelog to mention those removals
[03:54] <jdong> yay gutsy-backports is all triaged
[03:54]  * jdong cringes at the look of feisty-backports
[03:54]  * Hobbsee goes to dump more crack in there, then.
[03:54] <LordKow> er, what im saying is i'll keep the comments in the files :)
[03:54] <LordKow> sorry confusing myself
[04:09] <LordKow> "   * Merge from debian unstable, remaining changes:     - Keep our maintainers in debian/control and debian/control.in     - Retain *_DISABLE_DEPRECATED comments"
[04:09] <crimsun> LordKow: that's the idea.
[04:09] <LordKow> if a person wondered about the comments they could search for DISABLE_DEPRECATED in the changelog and get there instantly
[04:10] <crimsun> precisely.
[04:10] <LordKow> now, how do you attach more than 1 file to a single comment... or include it as the comment?
[04:11] <LordKow> i see
[04:11] <LordKow> ;p
[04:12] <jdong> ok, 4 hours of backports triage for one night is quite enough
[04:12]  * jdong moves on to something else
[04:14] <Hobbsee> jdong: now fix real bugs.
[04:14] <Hobbsee> :)
[04:14] <jdong> haha
[04:14]  * jdong follows up on his gtkpod-aac bug
[04:15] <Hobbsee> jdong: adding crack != fixing bugs.
[04:16] <LordKow> okay hopefully the version i just uploaded to bug 163261 passes
[04:16] <ubotu> Launchpad bug 163261 in balsa "New upstream release 2.3.20" [Undecided,New] https://launchpad.net/bugs/163261
[04:18] <crimsun> heh, I had forgotten that ESR uses [a ]Ubuntu[ base]
[04:18] <crimsun> he, too, has been bitten by the atrocious HDA bugs
[04:23] <jdong> wait do I subscribe motu-uvf or u-u-s for a Universe SRU?
[04:24] <crimsun> the latter
[04:24] <crimsun> (hopefully you aren't pulling in an entirely new upstream version for an SRU!)
[04:25] <jdong> crimsun: lol not this time, this time it's a fairly small debdiff
[05:05] <jdong> whoo I think I wrangled another gtkpod-aac bug to the ground
[05:05]  * jdong hopes he didn't just jinx himself
[05:08] <jdong> should two pending SRU's on a package be combined into one?
[05:12] <crimsun> generally, no.
[05:13] <crimsun> if, however, the changes are orthogonal and well tested, then it's possible.
[05:14] <jdong> crimsun: so one should be verified/uploaded first, then the second one is done on top of that?
[05:19] <crimsun> jdong: ideally, yes, but if the conditions are as described above, then it can be argued into one upload.
[05:20] <crimsun> jdong: it all lies in how it's presented and how the changes are made  : )
[05:21] <jdong> crimsun: well, they are two independent bugs in gtkpod-aac. One involves reverting MP4 Group metadata handling to Feisty's version's behavior, another involves cherrypicking a SVN fix for not being able to add tracks to a local repository.
[05:21] <jdong> as I said, completely different :)
[05:22] <crimsun> I'd say that's fairly safe to combine
[05:22] <crimsun> no xserver-xgl-magnitude ones, though ; )
[05:23] <jdong> they're both fairly small debdiffs and easily reviewable
[05:29] <pwnguin> arg. why does xmlGetProp() return attributes?
[05:29] <pwnguin> would it be so hard to name things according to the standard? =(
[05:40] <jdong> G*** ***** ****ING *******!
[05:40] <jdong> if shutil.move() errors out when a destination exists, I'm gonna impale myself
[05:42] <jdong> no phew it works
[05:42] <pwnguin> please save the cutting for the emo kids
[05:45] <jdong> WHOO! two birds one stone with gtkpod-aac :)
[05:49] <s1024kb> persia: hi
[05:49] <persia> Hello s1024kb
[05:50] <jdong> persia: hey, you up for finishing some gtkpod-aac goodness with  me or busy? :)
[05:51] <persia> jdong: I actually don't have an iPod, nor do I use the package: what do you need?
[05:51] <jdong> persia: no iPod necessary, I just need some sponsorship on a Hardy upload and also a SRU
[05:51] <jdong> no iPod is needed even for verification
[05:52] <persia> jdong: Is the bug in the sponsors queue?  That's about third on my list of things right now, and I'd prefer to catch it then (if someone else doesn't first).
[05:53] <jdong> persia: yeah, I just wanted to make sure I didn't confuse the sponsor queue with my ambivalence
[05:53] <persia> jdong: Ambivalence?
[05:53] <jdong> persia: I see you already got that 135178 doesn't need sponsoring anymore
[05:54] <jdong> persia: and I've opened #145506 for a Hardy sponsor
[05:54] <persia> jdong: Ah.  Yes, I was subscribed to that one from my last look, so received the notice when you requested it be dropped from the queue.
[05:54] <persia> bug #145506
[05:54] <ubotu> Launchpad bug 145506 in gtkpod-aac "gtkpod-aac does not allow adding local tracks, claims iPod is not loaded (gutsy)" [Undecided,In progress] https://launchpad.net/bugs/145506
[05:54] <jdong> persia: and I've opened bug #163283 that is a SRU containing the previous two fixes rolled in gutsy-proposed format
[05:54] <ubotu> Launchpad bug 163283 in gtkpod-aac "[SRU/Gutsy]: Two patches for gtkpod-aac" [Undecided,New] https://launchpad.net/bugs/163283
[05:55] <jdong> the ambivalence was deciding if those two patches should be handled in one or two SRU's, and crimsun swayed me towards one :)
[05:55] <jdong> I just wanted to verify that I didn't leave out any important information for the SRU
[05:55] <s1024kb> persia: i am in my last steps of my package merging, almost done, i want to ask you a question: from where (which file) i can find the changes of the debian version, and i can add them to the changelog of the last ubuntu version i should make now?
[05:56] <persia> I'm generally in favor of having as few updates to a package as possible, with wrapped fixes.
[05:56] <persia> jdong: So 145506 should be declined for gutsy?
[05:56] <jdong> persia: that is correct. 163283 should be the one going into gutsy
[05:56] <jdong> 145506 only needs to go into Hardy
[05:57] <persia> s1024kb: The changes from the last Debian version are documented in debian/changelog in the last Debian version, and can be extracted with debdiff or interdiff between the Debian version the last Ubuntu version was based upon and the last Debian version.
[05:58] <persia> jdong: Declined.  I'll dig into the patches when I hit the queue (if they are still there).
[05:58] <jdong> persia: ok, thanks so much for your time :)
[05:59] <s1024kb> persia: thanks
[05:59] <persia> jdong: No problems.  I like to keep the queue clean, in the hopes that this inspires all the sponsors :)
[05:59] <jdong> hehe :)
[06:08] <LucidFox> I noticed that Launchpad's build servers don't use pbuilder. What is it that they do use?
[06:09] <persia> LucidFox: sbuild
[06:09] <persia> LucidFox: https://help.ubuntu.com/community/SbuildLVMHowto may be useful if you want to replicate that: such a setup has been working well for me.
[06:09] <crimsun> (the wonderful, wonderful world of sbuild)
[06:10] <crimsun> eww, this script has "race condition" written all over it
[06:10] <crimsun> good thing I decided to not ship it in gutsy
[06:12] <LaserJock> persia: ah, you're here
[06:13] <persia> LaserJock: Yes.  Sorry: unexpected activities last night.  prepping things for you is 2nd on my current todo list.
[06:13] <LaserJock> persia: I just had an idea about REVU wilst taking a shower
[06:13] <persia> LaserJock: What's that?
[06:14] <LaserJock> well, I'm thinking perhaps a 2 step system could be employed and perhaps  work with your mentoring thing
[06:14] <LaserJock> I was sort of thinking about how we do bugs
[06:14] <persia> LaserJock: Could you expand?  I've wary of mixing mentoring with other processes: I think that there are lots of people who do well without mentors.
[06:15] <LaserJock> so the 1st step would be "triage", basically going down a checklist similar to what you wrote -motu about
[06:15] <LaserJock> being lintian clean, basic things, and builds
[06:16] <LaserJock> then second step would be an actual thorough review for the acks
[06:16] <LaserJock> now, I was thinking that the 1st step would be a nice activity for the mentees in Step 2 of the mentoring program to do
[06:17] <LaserJock> I'm not sure if this is too complicated or red-tape laden though
[06:17] <ScottK> LaserJock: There's nothing that stops non-motus from giving reviews via ORC now.
[06:17] <ScottK> ORC/IRC
[06:17] <LaserJock> ScottK: no, but I was thinking in a more formal way
[06:17] <LaserJock> as in we have a triaged flag
[06:17] <LaserJock> that they can set
[06:18] <LaserJock> which would bump the priority
[06:18] <ScottK> Right, but since the mentoring program is totally optional, I'm not sure how to work that.
[06:18] <LaserJock> well, it wouldn't be strictly tied to mentoring program
[06:18] <persia> LaserJock: That makes some sense, and I like it.  I'd like to do it much more like we do bugs, and ignore the relationship to the mentoring program.
[06:18] <LaserJock> I'm just thinking "MOTU Hopeful" here
[06:18] <persia> Essentially, allow package check assignment, subscription, etc.
[06:18] <LaserJock> somebody who knows how to use pbuilder and lintian
[06:19] <LaserJock> persia: but I think it'd be an excellent excersice for Step 2 mentees
[06:19] <persia> LaserJock: Right.  I agree that most Contributors could likely do reviews, and that having a better mechanism for them to do so on the reviewing site would be nice.
[06:20] <persia> None of the people who I've worked with through what I'd proposed as "Step 2" needed nay help figuring out what to do: they just needed a little help determining how to promote their activities, and how to build the basis for an application.
[06:21] <LaserJock> persia: well, I was thinking it'd be a good way for them to "show their stuff" and get a little reward for it
[06:21] <persia> Rather, anyone who can generate a good candidate revision, do merges well, etc. can probably help review some of the packages.  I believe there is some discussion about opening comments to all Contributors, if the ordering logic can be kept sane.
[06:21] <LaserJock> but if you don't think it'd be useful fine
[06:22] <LaserJock> well, but see I don't particularly like just opening comments
[06:22] <LaserJock> as it's a bit difficult to follow, IMO, when everybody's just adding comments
[06:22] <persia> LaserJock: It's not that I don't think it would be useful, it's that I believe the appropriate time is between "stage 1" and "stage 2", and that many people won't require mentoring.
[06:22] <LaserJock> perhaps
[06:23] <LaserJock> I was just thinking it would work well with your mentoring scheme
[06:23] <persia> I think comments can work, as long as it is clear that only reviewing comments are accepted.  Social pressure can be brought to bear on people who aren't providing good reviews.
[06:23] <LaserJock> give them something to contribute to that a) makes a difference and b) helps us out
[06:24] <LaserJock> persia: I'm just thinking a more elegant solution is possible
[06:24] <persia> LaserJock: I suppose.  I like to think of different processes that are compatible, rather than one master plan.
[06:24] <LaserJock> well right
[06:25] <LaserJock> bah, I'm having really bad luck getting my points across the last couple days
[06:25] <ScottK> The real problem, as I understand it, is that to enable a class of users to comment, but not adovocate on REVU, the DB schema would have to be changed and that has a lot of risks to it.
[06:25] <LaserJock> maybe I need flow charts
[06:25] <persia> LaserJock: A more elegant solution is definitely possible.  I think there is the start of renewed interest in REVU2, and I know that a staging / testing environment is being configured.
[06:25] <persia> ScottK: The big risk was the lack of a testing environment.  It is hoped that increased infrastructure will address some of that.
[06:25] <LaserJock> well, I don't really care about the tools
[06:26] <LaserJock> tools can be written to do what we need
[06:26] <ScottK> LaserJock: But whatever process we use, we need tool support for.
[06:26] <LaserJock> we need to figure out what we want to do first
[06:26] <ScottK> OK
[06:26] <persia> LaserJock: Ah.  Right.  At a high level, I completely agree that Contributors should be encouraged to help with the New Package process as much as with any of our other processes.
[06:26] <LaserJock> so I realize that we can't implement this in REVU, but we should be looking to REVU2 at least
[06:27] <persia> Further, I believe that MOTUs should not be restricted from participating in the process, even at the first pass (I still do bug triage and initial comments, and don't intend to stop).
[06:27] <LaserJock> persia: no, I'm not restricting, I'm trying to open it up
[06:28] <LaserJock> so one of the big problems is initial turnaround in REVU
[06:28] <LaserJock> so if we harness the vast army of MOTU Hopefuls ;-) to triage REVU
[06:29] <LaserJock> and provide useful feedback to REVU contributors while still keeping the MOTU ack as "sacred"
[06:29] <LaserJock> some MOTUs may prefer the triaging
[06:29] <LaserJock> some don't like to see crappy packages and throw them back
[06:30] <LaserJock> or am I on crack?
[06:30] <crimsun> (well, we're all on crack...)
[06:30] <persia> LaserJock: If you're not on crack, you're not trying
[06:31] <LaserJock> the other thing, IMO, while thinking about NEW packages as bugs
[06:31] <LaserJock> was really they are wishlist
[06:32] <LaserJock> and perhaps we're creating unreasonable expectations in people
[06:32] <persia> LaserJock: I think that there is general support for allowing better access for Contributors to help with REVU, and I've seen a couple people mention that they were looking at it, but I've not seen a spec published yet.
[06:32] <persia> unreasonable expectations?
[06:33] <LaserJock> well, I still feel like we push people to REVU a lot
[06:33] <persia> How do you mean "push people to REVU"?
[06:33] <LaserJock> and Mark and others have sort of promoted REVU/MOTU as the place to get *anything* in
[06:33] <ScottK> LaserJock: REVU is what our process says to use.
[06:33] <LaserJock> well, like people wanting to help, learn to package, become MOTUs
[06:34] <LaserJock> ScottK: s/REVU/packaging for NEW/
[06:34] <ScottK> Yes
[06:34] <persia> LaserJock: That's just a matter of individuals.  Personally, I always point at bugs.  I don't think new packaging or merging is a good way to learn.
[06:34] <LaserJock> and so essentially I think we end up placing too much emphasis on wishlist bugs
[06:34]  * ScottK agrees New packages isn't always (or even usually) the best place to start
[06:35] <LaserJock> so I was wondering if, as a part of the triaging process, if we could have some measure of Importance as well
[06:35] <persia> ScottK: Considering your entry, thanks for that: I've long considered you one of the bug proponents of the start with NEW opinion
[06:36] <persia> LaserJock: Package importance?
[06:36] <LaserJock> like, there's a big difference between some little script that all of 2 people in the world use
[06:36] <LaserJock> and say Kompozer
[06:36] <ScottK> persia: I think it needs to be an option, but isn't best for someone that just wants to help out.
[06:36] <persia> ScottK: Right.
[06:36] <LaserJock> which is where we had a NEW package that was replacing a well-known existing package
[06:37] <ScottK> I showed up with some specific stuff I wanted to accomplish and so New packages was motivationally the right place for me to start.
[06:37] <ScottK> That's an important case, but not, I don't think, the most common.
[06:38] <persia> Hmm.  I still think REVU is best managed as a FIFO queue for reviews.  Now that anything rejected gets sorted to the bottom, we have a better chance of getting everything done.
[06:38] <LaserJock> hmm
[06:38] <LaserJock> perhaps
[06:38] <persia> I think it's about creating a fair system, and then concentrating on response time, rather than creating an imbalanced system.  The volume isn't high enough that we couldn't do it if we tried.
[06:38] <LaserJock> I just can't help but think we're adding too much to Universe
[06:39] <LaserJock> I think we need to figure out what we want to do in some ways
[06:39] <imbrandon> package the $world
[06:39] <LaserJock> if MOTU is about managing the divergence from Debian then I think we should really have very very few packages in Ubuntu not in Debian
[06:40] <LaserJock> and REVU would be mostly about new upstreams, Ubuntu specific packages, and corner cases
[06:40] <persia> LaserJock: Depends on philosophy.  I'm of the opinion that anyone who wants to do something should be able to do that as a concentrated team, and that Universe should include everything for which there is upstream maintenance, source, and a reasonable license.
[06:40] <LaserJock> right
[06:40] <ScottK> Additionally, REVU and Ubuntu can serve as a good step on the way to getting stuff into Debian.
[06:40] <LaserJock> however that philosophy hasn't, IMO, really worked for us all that well
[06:41] <imbrandon> see thats the thing with all this discussion about that, my feeling is that not all MOTU are not about the same thing, some manage the divergance some do new packages some help Hopefulls etc etc etc
[06:41] <LaserJock> imbrandon: mile wide and an inch deep
[06:41] <LaserJock> we get spread so thin that things fall through the cracks
[06:41] <persia> I think of MOTU as coordinating that growth.  As we get more and more non-Debian packages, we need more activity in DCT to ensure that we don't lose that, and also more activity in upstream updates for our local packages.
[06:41] <LaserJock> sometimes rather big things
[06:41] <imbrandon> LaserJock: true, but the hunt for new MOTU is always on ( as it should be )
[06:42] <ScottK> Sure, but we're also volunteers and so divergent interests are going to get divergent stuff done and that's both inevitable and OK.
[06:42] <LaserJock> I'd rather us do a smaller set of things really well and branch out from there
[06:42] <imbrandon> ScottK: right
[06:42] <ScottK> LaserJock: Then convince other MOTUs to work on that smaller set.
[06:42] <persia> I don't think lots of new MOTU is the goal we should seek (although it would be nice).  I'd like to see more encouragement of Contributors.  There are lots of people who can spend a couple hours every weekend, and can do good work, but who don't have the time to keep track of everything for MOTU.
[06:42] <imbrandon> LaserJock: thats kinda what we did , warty was a very small change from sid at the time , then onward
[06:43] <LaserJock> imbrandon: well, I don't think we've done anything particularly well for a couple of releases
[06:44] <LaserJock> but maybe that's my cynacism talking
[06:44] <imbrandon> persia: someone that spends a few hours every weekend SHOULD be a MOTU, just because we diehards give X hours dosent mean that should be the bar, IMHO the MOTU bar shouldent matter on quanity at all, only quality
[06:44] <persia> LaserJock: It sounds like you're talking about focused support for some subset of packages that isn't in main, but isn't all of universe.  If you identify the set, and have some others who agree on the set, you can make a team, subscribe all the packages, and focus.  Look at mythbuntu or ubuntustudio for good examples.
[06:44] <LaserJock> persia: well, I would like to do that yes
[06:44] <LaserJock> but minimally I'd like us to support *every* ubuntu versioned package in Universe
[06:45] <persia> imbrandon: Maybe, but it takes a long time to get enough work done to be considered for MOTU if you only spend a couple hours a week.  I'm not opposed to them becoming MOTU, but think we need to support them better before they get there.
[06:45] <LaserJock> persia: my worry with that is that MOTU has become increasingly just a set of managers
[06:45] <LaserJock> which is no fun for many people
[06:46] <LaserJock> if you look at the number of uploads by MOTUs as a percentage of packages I think it's gone down significantly
[06:46] <imbrandon> persia: i dont think so unless thats recient, in the begning infact untill i became core, i put ~10 hours a week in, and made MOTU in 3 months iirc
[06:46] <persia> LaserJock: *every* ubuntu versioned package is a big list.  After UVF, I generate one of those for every other bug I investigate.  I don't mean to be adding to anyone else's workload, as I'm just integrating Debian fixes.
[06:47] <LaserJock> persia: it is a big list, but that's our mess, we need to take care of it
[06:47] <persia> imbrandon: It depends on the person.  Still, I don't see any reason not to support Contributors just because they don't intend to become MOTU (I certainly didn't).
[06:48] <imbrandon> persia: yea i'm not saying that at all, definately support contributors that dont want to be MOTU
[06:48] <persia> LaserJock: Perhaps.  Personally, I don't care if most bugs affect an ubuntu versioned package or one we pull from Debian, but I can see your point.
[06:48] <warp10> Hi all!
[06:49] <persia> imbrandon: In that case, all is good :)
[06:49] <LaserJock> persia: I'm tired of pissed off upstream complaining about *us* making their software worse than they put out
[06:49] <imbrandon> persia: i just dont think your timeframe from $hopefull to $motu is accurate was my point
[06:49] <imbrandon> :)
[06:49] <LaserJock> Ubuntu shouldn't be making software worse!
[06:50] <imbrandon> LaserJock: well i think alot of that is before they had X users and now since its in ubuntu and ubuntu has become so popular they have X^2 users
[06:50] <imbrandon> and upstream dont understand always that more users == more bugs reported
[06:50] <persia> LaserJock: I've seen upstream complain about us when we pull from Debian as well.  I discussed why the variance was in place, and upstream helped create a patch that worked for both Debian and Ubuntu.  We're different from upstream, but it's no longer worse.
[06:50] <persia> imbrandon: Yes, but sometimes it's the package patches as well.
[06:52] <imbrandon> definatly , and sometimes its just a diffrence of opinion, take koversation , kubuntu set its own defaults for it, config options that was supplied by the program, no patching, and upstream got upset because it wasent "pure" konversation and they beleave every distro should ship "pure" apps
[06:52] <imbrandon> so really each instance has to be looked at indivualy, in that case it was a matter of kubuntu != vannilla kde
[06:52] <imbrandon> imho
[06:53] <imbrandon> it dident claim to be etc etc etc
[06:53] <LaserJock> imbrandon: well, I'm talking about us screwing up
[06:53] <LaserJock> it happens often enough that it does need to be addressed
[06:53] <imbrandon> LaserJock: we're people , we're gonna screw sometimng up sometime no matter how small the focus
[06:53] <LaserJock> yes
[06:54] <LaserJock> but we dont' fix things
[06:54] <imbrandon> all we can do is fix it as it comes
[06:54] <LaserJock> at least not very well
[06:54] <imbrandon> sure, looking at the upload logs we fix things by the minute
[06:54] <LaserJock> we mostly process things
[06:54] <LaserJock> it's like shuffling paperwork
[06:55] <imbrandon> sure, btu thats what distros do, they are the intorgrators, not the developers, distro developers is largly a misnomer short of someone like scott with upstart or ubiguity
[06:55] <imbrandon> but*
[06:55] <LaserJock> sure
[06:55] <LaserJock> but we shouldn't be making software *worse* if we can help it
[06:55] <imbrandon> i 100% agree
[06:56] <LaserJock> and it seems like we spend a lot of time focused on other things
[06:56] <LaserJock> than a lot of other distros
[06:56] <imbrandon> but i can atest thats not the intentions when a package is patched, infact most patches dont originate in ubuntu they are pulled from $RCS
[06:57] <imbrandon> LaserJock: yes we do, and thats one thing that sets us appart from other distros
[06:57] <imbrandon> inotherwords LaserJock i'm 10000% agreeing with you, i just personaly dont see that as "new in ubuntu" or a problem
[06:58] <imbrandon> i mean we do the best we can, the only alternative i see is $close-shop
[06:58] <StevenK> LaserJock: Ponies!
[06:59] <imbrandon> hehe sabdfl cant pay 10000000 more full time developers, and honestly i'm not sure how much of a diffrence it would make past a certain threshold
[07:00]  * imbrandon often wonders how many developers , actual coders MS employs
[07:00] <StevenK> LaserJock: And how are we making software worse?
[07:01] <StevenK> imbrandon: *Many* - the number I've heard is like 30,000, but I don't know if that number is wrong or what
[07:01] <imbrandon> wow
[07:02] <LaserJock> StevenK: by release either broken versions or not paying enough attention
[07:02] <StevenK> LaserJock: The broken versions themselves are not our fault.
[07:02] <LaserJock> no
[07:02] <LaserJock> we rarely intentionally cause problems
[07:03] <LaserJock> but we're not great about recognising unintential breakage and then fixing them
[07:04] <LaserJock> it'd be nice if we could make sure we're supporting the divergence we create
[07:04] <StevenK> Could it be due to the fact that there is >11,000 source packages and only ~30 active MOTUs?
[07:04] <LaserJock> and the almost as importantly, pulling in fixed from Debian when things are fixed upstream
[07:04] <LaserJock> StevenK: that's what I'm saying
[07:04] <LaserJock> there's two things you can do about that
[07:04] <LaserJock> get more MOTUs, which hasn't really worked that well, IMO
[07:04] <ScottK> LaserJock: The trick there is feeding back stuff to Debian/Upstream.  ~80% of my 'merges' I had when Hardy opened turned out to be syncs because I'd done that.
[07:05] <persia> LaserJock: For at least RC, we do a reasonable job of that, and have some tools (although more people pulling would be nice).
[07:05] <LaserJock> or not creating so much divergence
[07:05] <persia> LaserJock: 99% of the divergence is bugfixes.  I don't think that's an ideal solution.
[07:05] <LaserJock> ScottK: right, we aren't pushing upstream nearly enough
[07:06] <LaserJock> persia: but we shouldn't be maintaining *any* bug fixes for any decent length of time
[07:08] <persia> LaserJock: In some cases, yes, but there are often differences between Ubuntu main and Debian required that force us to do so.
[07:08] <LaserJock> right
[07:08] <LaserJock> and we should be maintaining that
[07:08] <LaserJock> not adding new packages and mucking around with stuff we can't maintain properly
[07:08] <persia> Specifically, I get particularly annoyed when Ubuntu people create Debian bugs where the patch doesn't fix a problem in Debian, and may make the package worse.
[07:09] <persia> LaserJock: Why should we limit?  We're volunteers.  People should do what they want, no?
[07:09] <LaserJock> no
[07:09] <LaserJock> they shouldn't
[07:09] <imbrandon> LaserJock: ummm ?
[07:09] <LaserJock> they should do what needs to be done
[07:09] <LaserJock> I think volunteers doing whatever they want is just stupid
[07:09] <imbrandon> see thats the diffrence between $paid and $vol
[07:10] <persia> LaserJock: Maybe.  It's harder to keep them doing that when it's externally defined, and there is no obvious reward.
[07:10] <LaserJock> sure
[07:10] <LucidFox> Wow, a flamewar. *sits down and relaxes*
[07:10] <imbrandon> LaserJock: then that cuts the ~30 active to ~5 active
[07:10]  * Fujitsu thinks we need to *discourage* creation of new packages.
[07:10]  * persia agrees with Fujitsu
[07:10] <Fujitsu> Not ban, but not encourage.
[07:10] <LaserJock> imbrandon: we still might get ahead
[07:11] <imbrandon> sure at the cost of loosing vol and possibly users
[07:11] <LaserJock> at some level I think that's ok
[07:11] <imbrandon> i dont
[07:11] <LaserJock> I sure don't want people to leave
[07:11] <LaserJock> but if you don't want to be a part of the team then well, maybe we aren't the place to be
[07:11] <LaserJock> a ruderless ship isn't going to go anywhere
[07:12] <LaserJock> we *have* to have direction, priorities, leadership
[07:12] <imbrandon> sure but limiting that team in such was makes it undesireable to $vol, and then you need $paid
[07:12] <imbrandon> sure
[07:12] <persia> LaserJock: I guess I'm saying that I don't see a point to a rudder for MOTU: more that I encourage the definition of teams within MOTU to accomplish defined goals.
[07:13] <persia> If the team is not led, it will fail.  If the team is well-led, it can create excellent results.
[07:13] <LaserJock> right
[07:13] <LaserJock> but our users deserve more than "meh, nobody really felt like it"
[07:13] <imbrandon> LaserJock: but i think your trying to push what should be a sub-team goal on a full team
[07:13] <LaserJock> pfft
[07:13] <persia> LaserJock: So, while I've been disagreeing wtih you down the line above, I do encourage you to work with the DCT team to reduce our variance, and perhaps start an upstream-collaboration team to make that cleaner as well.
[07:14] <LaserJock> people have been against subteam for as long as we've tried to do them
[07:14] <LaserJock> I'd for sure support subteams defining goals, etc.
[07:14] <LaserJock> but the fact of the matter is most people need to be told what to do
[07:15] <imbrandon> LaserJock: howso there are tons of flurishing subteams, you just need to get critical mass for it, look at mythbuntu , ubuntu-x etc etc etc
[07:15] <persia> LaserJock: Right.  sub-team is the wrong word.  Other team that collaborates.  Look at the mythbuntu team, or the torrent team, or the desktop team, or the ubuntustudio team.  Not all members of those teams are MOTU, but they do keep certain subsets of packages well maintained.
[07:15] <LaserJock> imbrandon: right, like the python team, games team, multimedia team ...
[07:15] <imbrandon> sure
[07:16] <persia> LaserJock: I don't know about multimedia, but -python and -games have merged with Debian, and tend to keep things well maintained.
[07:16] <LaserJock> persia: right, cause they died off
[07:16] <persia> LaserJock: Not at all.  I'm a member of games, and while we mostly work in alioth SVN, we're certainly not dead.  I also see lots of work from -python.
[07:17] <imbrandon> i dont think merging with upstream means died off, look at pkg-kde on alioth its mostly ubuntu people
[07:17] <LaserJock> right, but we don't have any official MOTU subteams that are actually working well, at least that I'm aware of
[07:18] <imbrandon> ummm we just named ~ 5-10
[07:18] <persia> LaserJock: What is an "offical MOTU subteam"?
[07:18] <LaserJock> we have a team list
[07:18] <persia> Ah.  Right.  The team list needs to be updated: that's a documentation lag.
[07:19] <LaserJock> https://wiki.ubuntu.com/MOTU/Teams
[07:19] <LaserJock> I've seen no activity from any team on -motu
[07:19] <persia> LaserJock: In this channel?
[07:20] <LaserJock> mailing list was what I was thinking of
[07:20] <LaserJock> I'm sure theres some here
[07:20] <imbrandon> why would there be ?
[07:20] <LaserJock> they should have task lists
[07:20] <LaserJock> be coordinating with general MOTU
[07:20] <imbrandon> teams ( i know mythbuntu ) uses its own ML
[07:20] <LaserJock> etc.
[07:20] <imbrandon> mostly
[07:20] <LaserJock> I don't consider mythbuntu to be a MOTU team
[07:20] <persia> LaserJock: Most teams have their own lists.
[07:21] <LaserJock> persia: well, I realize that, I started 2 of them
[07:21] <LaserJock> and they're both dead
[07:21] <imbrandon> LaserJock: what would they be then? they maintain all myth packages in universe and m,ultiverse , afaik none are in main
[07:21] <LaserJock> imbrandon: a derivtive
[07:21] <imbrandon> the OS yes, not the team
[07:21] <LaserJock> which obviously does affect Universe/Multiverse
[07:21] <LaserJock> but I wouldn't consider them a subteam of MOTU per se
[07:22] <persia> LaserJock: OK.  How about -games?  We've some in universe, and some in main.
[07:22] <LaserJock> what about it? sorry
[07:23] <LaserJock> this is sort of tangential to what I was saying before
[07:23] <persia> LaserJock: Is it an "official MOTU team"?  There's almost never a post to ubuntu-motu@
[07:23] <imbrandon> LaserJock: i guess i'm starting to think you see a set of packages that need love and have no team or a dead team, honestly i dont know how to help that, but i dont think that represents universe as a whole
[07:23] <LaserJock> persia: yes, but not a very active one I wouldn't think
[07:24] <imbrandon> -games is very active afaik
[07:24] <persia> LaserJock: Ah.  In that case we should do a little more promotion :)
[07:24] <LaserJock> I think sub team should be doing the *majority* of the work
[07:25] <LaserJock> in any case
[07:25] <LaserJock> I guess I'm off my rocker tonight
[07:26] <LaserJock> well, maybe that should just be it
[07:26] <LaserJock> I just can't sit here and cry over MOTU anymore
[07:27] <imbrandon> ok how about another subject :) feedback for http://search.ubuntuwire.com/xml/annotations.xml ( the sites search.ubuntuwire.com indexes ) and BTW I added a firefox search plugin to the page tonight
[07:27] <StevenK> Yes, there's a problem, and yes it's a hard problem. There is no silver bullet for it.
[07:28] <persia> imbrandon: Do wiki. and help. not automatically inherit from *.ubuntu.com ?
[07:28] <imbrandon> wiki and help are specified at the bootom
[07:28] <imbrandon> bottom*
[07:29] <imbrandon> so they can be labled and refined
[07:29] <persia> imbrandon: Right.  I'm just wondering why.
[07:29] <imbrandon> yes but *. dosent ahve a lable, wiki does, e.g. search ONLY wiki pages
[07:30] <imbrandon> if you notice when you search there is a "Refine this Search" link at the top of the results that can narrow it down to Labels
[07:31] <persia> imbrandon: Right.  I understand now.  Thanks.
[07:47]  * StevenK sighs. qa.d.o/madison.php is busted, which makes filing syncs dreadful.
[07:54] <s1024kb> persia: what will debdiff do?
[07:55] <persia> s1024kb: Generate a patch that would convert one revision into another.  By reviewing the debdiff, you can understand what has changed.
[07:56] <s1024kb> persia: when i run "grab-merge", i see the patch was generated already... is it correct?
[07:56] <persia> s1024kb: I don't know.  I've never used grab-merge, and believe it encourages people not to understand the differences when merging.
[07:57] <s1024kb> persia: you don't use the grab-merge script? so you download the source and merge it by other tool?
[07:58] <persia> s1024kb: Yes.  I download the latest revisions in each of Debian and Ubuntu, review the changes in each from the common source, and build a new revision that I believe to be appropriate for Ubuntu.
[07:59] <persia> s1024kb: That doesn't mean you shouldn't use grab-merge.  Many people do.  It only means I can't answer your questions about it.
[08:00] <s1024kb> persia: you use "debdiff" to generate the patch?
[08:00] <persia> s1024kb: Yes, but that doesn't do a merge, it only generates a patch between two versions.  My workflow isn't likely the easiest to learn.
[08:02] <s1024kb> persia: will you feel it very difficult when you were a beginner? How do you get help and finally overcame the obstacles?
[08:04] <persia> s1024kb: I first learned patch from working on collaborative projects via mailing lists.  I learned debdiff when preparing candidate revisions for simple bugs, an developed my merging process when trying to update the packages I'd changed for the next release.
[08:05] <persia> Each step was not so big, and so seemed not so hard.
[08:07] <s1024kb> persia: have you ever read some useful books or documents about it?
[08:08] <persia> s1024kb: About merging?  There's a page on the wiki (but it moved since last I looked).  About debdiff?  There's the manpage, but it's not very useful if you don't know patch.  About patch, not at all, and I'm still not certain I understand all the details.  I would just recommend reading lots of patches: you can see the format, and understand how it would be applied.
[08:12] <s1024kb> persia: i feel that it's difficults just reading the packing guide and learn packaging...i am searching for more detail documents.
[08:12] <nxvl> i hate asm!!!
[08:19] <imbrandon> section .text   _start
[08:19] <imbrandon> err
[08:20] <Fujitsu> Remarkably relevant.
[08:20] <imbrandon> yea but wrong
[08:20] <imbrandon> heh
[08:20] <imbrandon> section .text
[08:20] <imbrandon> _start:
[08:21] <siretart> jdong: yes, xine is safe in this respect
[08:22] <nxvl> imbrandon: i'm developing a floating-point calc :S
[08:22] <imbrandon> ouch
[08:22] <nxvl> yep
[08:36] <imbrandon> gnight all
[09:58] <s1024kb> what's the difference between the result using the script "grab-merge" and "apt-get source"?
[10:00] <jpatrick> s1024kb: grab-merge gets Debian files as well
[10:01]  * persia wonders why most crashes are in network tools, games, and audio generators
[10:02] <s1024kb> jpatrick: beside that, i see it when using "apt-get source", the merge was done already? is it true?
[10:04] <jpatrick> s1024kb: it shouldn't, unless someone did do it...
[10:06] <s1024kb> jpatrick: if i use apt-get source, i can also merge it by other tools without the grab-merge.sh?
[10:06] <jpatrick> s1024kb: yep
[10:09] <s1024kb> jpatrick: okay, thanks. could you please tell me when i had finished merging and nothing wrong, all the .patch files are created, where i can find the information about the changes to fill the changelog?
[10:09] <jpatrick> s1024kb: ah, you have to do that yourself :)
[10:10] <jpatrick> that's the fun bit
[10:10] <geser> s1024kb: grab-merge.sh fetches the files from MoM while apt-get source fetches the current source package from the archive
[10:13] <s1024kb> geser: just now i download your "svnmailer" for study, because i see that you were the last uploader and i think that i can ask you something i could not understand... :-)
[10:16] <s1024kb> jpatrick: so you mean, i should read the files carefully, find out what have been changed and write them on the changelog with my own understanding?
[10:17]  * wallyweek bumps
[10:17] <geser> s1024kb: yes (or look at the old entries)
[10:17] <jpatrick> s1024kb: or at least any Ubuntu changes that aren't in Debian
[10:20] <s1024kb> jpatrick: i should write the changes of both the patches of the Ubuntu version and the Debian version? right?
[10:21] <jpatrick> s1024kb: you are merging in the Debian patches (if necessary) and writing the remaining Ubuntu changes
[10:24] <s1024kb> jpatrick: does the remaining Ubuntu changes means the difference between my merge result and the last Ubuntu version which is just before this final result?
[10:26] <jpatrick> s1024kb: I didn't mean writing them, but just state them
[10:26] <jpatrick> s1024kb: example: https://lists.ubuntu.com/archives/hardy-changes/2007-November/001182.html
[10:31] <s1024kb> jpatrick: thank you for showing me the format. so i should find out the changes carefully and state them on the file? the changes between my merge result and the last Ubuntu version which is just before this result?
[10:32] <jpatrick> s1024kb: yes
[10:34] <jpatrick> jpatrick: me changes to the Ubuntu version are the ones after the first "*"
[10:34] <s1024kb> jpatrick: i should research the patches carefully and state the changes in my own language?
[10:35] <jpatrick> s1024kb: only if you need to remove them as I did^
[10:36] <quail> Me TV 0.4.3 has been uploaded to REVU (http://revu.tauware.de/details.py?upid=628) and has undergone 1 review, but no advocates. If anyone knows a MOTU with a DVB card then please let them know of our application.  Even in its bare form I think that Me TV is the best way to use DVB on the GNOME desktop.
[10:38]  * DaveMorris grumbles about packages been in repo with certain copyright files, then I can't do the same 
[10:38] <DaveMorris> quail: poke superm1
[10:38] <s1024kb> jpatrick: so if i have nothing to remove, i mean, i accept all the changes, so i have nothing to state?
[10:39] <jpatrick> quail: why have README.Debian if you have nothing to write there
[10:39] <jpatrick> s1024kb: from Debian? You'll have to state any Ubuntu changes remaining
[10:40] <quail> jpatrick: I am just the alpha / beta tester / doc writer for the project but I will look into and get it sorted thanks
[10:41] <jpatrick> quail: version number should be 0.4.4-0ubuntu1 and seeing as it's not in Ubuntu or Debian it should have only: "* Initial release" in debian/changelog
[10:41] <s1024kb> jpatrick: i just don't understand what's does it mean "the changes remaining". we combine the Ubuntu changes to the base version, and we combine the Debian changes to the base version, right? and make them to be the latest version?
[10:41] <geser> s1024kb: you describe the remaining changes between the Debian version you merged and the merged Ubuntu package (i.e. all changes in the debdiff)
[10:43] <s1024kb> geser: does it mean "the changes between the Debian version and my final result"?
[10:44] <geser> s1024kb: say we take a Debian package with version -1 and modify it (-> -1ubuntu1), the Debian maintainer uploads -2 (perhaps with some of the changes Ubuntu did), we merge it and check which of the changes in -1ubuntu1 is still needed and apply on -2 (->2ubuntu1) and list this remaining changes in the changelog
[10:44] <geser> s1024kb: yes
[10:46] <Kmos> geser: in that case, we don't need to include all changelog entries before that version.. because it's only a -1ubuntu1
[10:46] <quail> jpatrick: I have passed that info on to the devolper so we can work all that out :-)
[10:46] <Kmos> or we need to ?
[10:47] <persia> DaveMorris: Which package, which license?
[10:47] <s1024kb> geser: okay, so i can feel free to write down what had been changed as what i see after my research of the files?
[10:48] <geser> s1024kb: yes
[10:49] <quail> jpatrick: do you mind adding your questions / info to here (http://revu.tauware.de/details.py?upid=628) please so to help us keep track things
[10:49] <s1024kb> geser: ^^. so "merging" means we have to find out what had been changed and are they okay and can be merge to the final result? If yes, accept it, if no, remove it?
[10:49] <jpatrick> quail: no problem
[10:49] <geser> Kmos: I don't fully understand your question. Which entries do you want to drop?
[10:50] <DaveMorris> persia: cppunit
[10:50] <quail> jpatrick: cheers :-)
[10:50] <DaveMorris> I did the same for my package cpptest and got told to put the preamble in there as well
[10:50] <DaveMorris> persia: on gutsy btw
[10:52] <geser> s1024kb: yes, check the old Ubuntu changes if they still are needed (and keep them) or if they can be dropped (e.g. obselete, transitional error, etc.)
[10:52] <persia> DaveMorris: Ah.  I think the Ubuntu archive-admins are more careful with copyright than the Debian ftp-masters: likely because they are less experienced, and so more afraid of making a mistake.
[10:52] <s1024kb> geser: okay. ^^ so if they can be dropped, how to do?
[10:53] <jpatrick> quail: done
[10:53] <persia> DaveMorris: Also see Debian bug #437526
[10:53] <ubotu> Debian bug 437526 in libcppunit-dev "libcppunit-dev: old debian/copyright, upgrade to newest standard" [Minor,Open] http://bugs.debian.org/437526
[10:54] <geser> s1024kb: simply don't apply them
[10:54] <Kmos> geser: let's imagine we use a synced version of a package from ubuntu, and we need to to -1ubuntu1 to change something. After we create a specific changelog entry for the package, we need to get oldest changelog entries from ubuntu if it have some ? or we don't need it, because that will inscrease the difference between ubuntu and debian packages.
[10:55] <quail> jpatrick: thanks :-)
[10:55] <Kmos> *from debian
[10:56] <geser> Kmos: when a package got synced (and old Ubuntu changes got dropped) you don't need to readd these old changelog entries again if you need to modify it again later
[10:57] <geser> Hi Hobbsee
[10:57] <Kmos> geser: ah ok =) thanks
[10:58]  * Hobbsee waves
[10:59] <geser> Hobbsee: how was your exam?
[10:59] <Hobbsee> geser: yesterday's was terrible.  todays' was good
[11:00] <pochu> There's a session about how to properly read Stack traces in #ubuntu-classroom in ~1 minute, in case anyone is interested...
[11:01] <txwikinger> thanks pochu
[11:02] <pochu> txwikinger: thank persia :)
[11:02] <geser> pochu: thanks for reminding, I forgot about it
[11:16] <effie_jayx> morning everyone
[11:16] <michaellamothe> evening everyone.
[11:16] <quail> evening michaellamothe
[11:17] <michaellamothe> Hi quail, thanks for the info.
[11:17] <quail> np mate
[11:18] <quail> michaellamothe: about Me TV you might want to poke superm1
[11:20] <michaellamothe> What if he "punch michaellamothe"?
[11:20] <quail> superm1: ping are you about?
[11:21] <DaveMorris> quail: superm1 is in the USA
[11:22] <DaveMorris> let him wakee up 1st ;)
[11:24] <quail> DaveMorris: sorry I not know that
[11:35] <LucidFox> jpatrick, I have addressed your comments regarding kwest on REVU
[11:35] <LucidFox> http://revu.tauware.de/details.py?package=kwest
[11:36] <jpatrick> LucidFox: I must say that's a very good bit of packaging
[11:36] <jpatrick> LucidFox: I'll pbuild when I can and approve it later
[11:36] <LucidFox> thanks
[11:50] <\sh> moins
[11:51] <\sh> Fujitsu, will add the missing cve to the debdiffs..easy one now ,-)
[11:53] <\sh> Fujitsu, oh this 3391 doesn't affect feisty and edgy at all...this file doesn't exist in our version...I think it came with 0.99.5
[11:54] <\sh> Fujitsu, upstream reports: Wireshark could exhaust system memory while reading a malformed DCP ETSI packet.  (Bug 1264)
[11:54] <\sh> Versions affected: 0.99.5
[11:54] <ubotu> Launchpad bug 1264 in malone "Bug keyword search is overly-literal (dup-of: 28975)" [Medium,Confirmed] https://launchpad.net/bugs/1264
[11:54] <ubotu> Launchpad bug 28975 in launchpad "Product search doesn't do partial word" [Medium,Confirmed] https://launchpad.net/bugs/28975
[11:56] <\sh> Fujitsu, but the other ones really affects edgy and feisty...sry for not seeing them..will add them
[12:14] <Fujitsu> \sh: Aha, thanks for looking into that. I just noted them as still open in the CVE tracker. So you can confirm that 3391 only ever affected >= Gutsy?
[12:14] <\sh> Fujitsu, jepp...and this I'll fix for gutsy seperatly :)
[12:14] <Fujitsu> Woo, 47 wordpress CVEs to look through.
[12:14] <Fujitsu> \sh: Isn't it already in Gutsy? I thought we had 0.99.6 there..
[12:14] <\sh> Fujitsu, the other 4 CVEs are only affecting edgy actually, because debian upstream already fixed them in feisty
[12:14] <Fujitsu> !info wireshark gutsy
[12:15] <ubotu> wireshark: network traffic analyzer. In component universe, is optional. Version 0.99.6rel-3 (gutsy), package size 574 kB, installed size 1428 kB
[12:15] <\sh> Fujitsu, right...sorry..:)
[12:15] <Fujitsu> \sh: I think I mentioned that in the bug that I referenced (#80something)
[12:15] <Fujitsu> I'll mark those off, then.
[12:15] <\sh> Fujitsu, feisty is set to fix released :)
[12:15] <Fujitsu> That means we'll be up to date, except for Dapper.
[12:15] <Fujitsu> \sh: Right.
[12:15] <\sh> Fujitsu, edgy I'm patching now
[12:20] <quail> Fujitsu: hiya mate, how are you?
[12:21] <Fujitsu> quail: Hi, not bad. Just finished year 12 exams.
[12:22] <quail> sweet, hope you went well in them :-)
[12:22] <Fujitsu> Hopefully.
[12:22] <quail> Fujitsu: have you got a dvb card?
[12:23] <Fujitsu> Myself, no. But one of the boxes that I set up at school has two dual DVB tuners.
[12:23] <\sh> oh this is so painful...
[12:23] <Fujitsu> \sh: Why?
[12:23] <Fujitsu> Oh, great. Only 1001 open universe CVEs.
[12:23] <\sh> Fujitsu, cherry picking those patches from upstream svn takes so long
[12:24] <minghua> Oh my.  How many CVEs do they issue per year?
[12:24] <\sh> alot
[12:24] <\sh> and we just have a few people checking them
[12:24] <Fujitsu> minghua: ~6000
[12:25] <minghua> Fujitsu: Oh.  Much larger number than I thought.
[12:25] <Fujitsu> A lot of them are for proprietary or unpackaged pieces of software, so don't affect us, which are good.
[12:25] <Fujitsu> *which is good
[12:25] <\sh> but 1001 open cves for universe is a hell of a lot
[12:26] <Fujitsu> It is.
[12:26] <Fujitsu> A lot of them aren't triaged.
[12:26] <Fujitsu> Most of wordpress' 42 are all untriaged.
[12:26] <Fujitsu> (yes, 42. WordPress is very secure)
[12:27] <geser> and wordpress upstream doesn't provide patches but only new versions
[12:27] <Fujitsu> geser: Right, but they normally provide links to the bugs, which link to changesets.
[12:27] <Fujitsu> Since around 2.0.6.
[12:28] <Fujitsu> phpmyadmin upstream is also getting better.
[12:28] <geser> do they still have no changelog?
[12:28] <geser> I mean WP upstream
[12:29] <Fujitsu> The release announcements normally link to a list of closed tickets (which is complete) or a diff.
[12:30] <Hobbsee> so many bugs...
[12:31] <\sh> Fujitsu, if you have problems with phpmyadmin, you could talk to garvin hicking, and give him some greetings from me, too :) he is also developer for s9y and phpmyadmin afaik...
[12:32] <Fujitsu> \sh: Aha.
[12:32] <Fujitsu> Well, I'm looking at updating it in at least Feisty/Gutsy shortly.
[12:32] <Fujitsu> Other releases will be substantially more difficult.
[12:33] <\sh> IMHO it's better propose a separate webapplications archive, or not to package them at all
[12:33] <\sh> drupal is very ok, because they are providing patches
[12:34] <Fujitsu> phpmyadmin and wordpress are getting better.
[12:34] <Fujitsu> And they're two of the main contributors to our CVE lists.
[12:34] <\sh> hehe
[12:35] <\sh> well, I still have openldap2.2 and openldap2.3 on my list for at least 2 CVes
[12:35] <\sh> one is fixed by redhat...so I can grab the patch from them
[12:36] <Fujitsu> Ah yes, I saw them on my list.
[12:36] <\sh> the other one I fixed for gutsy and feisty already, but for dapper and edgy...hell I don't have a clue how to apply it to the complete different source of 2.2
[12:36] <\sh> and upstream: fire and forget about 2.2
[12:37] <Fujitsu> Gaah.
[12:40] <RainCT> Hi
[12:46] <\sh> Fujitsu, we need a real universe security team
[12:46] <Hobbsee> define a real one?
[12:47] <effie_jayx> Hobbsee,  are there many merges going on at the moment?
[12:47] <Hobbsee> effie_jayx: yeah.
[12:47] <Hobbsee> some
[12:48]  * Hobbsee hasnt done any in a while, though
[12:48] <RainCT> what's the best (fastest) way to check if a package is installed, using python?
[12:48] <effie_jayx> Hobbsee,  could I try some later on? I notice there is no doc for merges as a recipe for motu-hpefulls
[12:48] <Hobbsee> effie_jayx: there are multiple merge docs, but i dont think it's made into a recipe yet.
[12:49] <effie_jayx> Hobbsee,  do you think it is suitable for anyone starting out?
[12:49] <Hobbsee> effie_jayx: merging requires some general knowledge of the archive, often not just the original package
[12:49] <effie_jayx> Hobbsee,  rigth
[12:49] <Hobbsee> hmm.  you'd probably be better picking bugs to fix
[12:49] <effie_jayx> Hobbsee,  good then
[12:49] <effie_jayx> I have spent my first hour today
[12:49] <\sh> Hobbsee, a group of people who takes care about security fixes...so we can show as well some responsibilty for universe
[12:49] <Fujitsu> \sh: We really do, but we don't have enough people around to do anything.
[12:50] <Hobbsee> \sh: right, yeah.
[12:50] <effie_jayx> Hobbsee,  maybe I could add a merge latter on... thanks
[12:50]  * Hobbsee is uncertain as to whether responsibility for universe can be shown, just by sheer ratio of package to people.
[12:50] <\sh> Fujitsu, I think more, that it's a problem of "everybody loves new upstream version, but no bug fixing" and sometimes it's really easy to catch those fixes (if it is from other distros or from upstream)
[12:51]  * Fujitsu auctions off chunks of the universe CVE namespace.
[12:51] <\sh> Hobbsee, the same applies to main, imho...we have a lot of CVEs hanging but I think our main security team can't catch up (imho)
[12:51] <Hobbsee> yeah well.
[12:52] <\sh> Hobbsee, just check the list of ubuntu-security
[12:52]  * white waves
[12:53] <white> Fujitsu: maybe you want to write a mail to the security-tracker ML and propose adding the ubuntu suites?
[12:53] <Fujitsu> white: It turns out that we have a separate one for Ubuntu.
[12:54] <white> Fujitsu: why not using debian's and adding ubuntu information there?
[12:54] <Fujitsu> white: I'm sure Kees has his reasons.
[12:55] <\sh> white, because we have different versions to take care of
[12:55] <\sh> white, for dapper, edgy, feisty e.g. there are all coming from debian unstable these days, and those are already fixed in debian because of new upstream versions
[12:55] <\sh> white, so many of the CVEs are not in your tracker
[12:55] <white> \sh: can't that be solved by adding different version checks?
[12:56] <\sh> white, for the actual development version, we (or at least I) using the security tracker as well
[12:56] <white> \sh: what do you mean by "so many of the CVEs are not in your tracker"
[12:56] <Fujitsu> I am, admittedly, using security-tracker.d.n a fair bit while triaging these.
[12:57] <\sh> white, take wireshark now...
[12:57] <white> \sh: to the best of my knowledge, we get the newest CVEs from mitre (some might be reserved, because they are embargoed) and track them
[12:57] <white> \sh: sometimes, we create temp isseus, because there is no CVE yet (but we request it)
[12:59] <white> Fujitsu: if you use your own, can't we somehow synchronize the work on let's say NFUs and stuff?
[12:59] <white> or forwarding to the BTS
[13:00] <Fujitsu> white: I'll talk to Kees about improving collaboration - we need it.
[13:00] <\sh> white, yes, but see e.g. openldap..:) there is at least one CVE open, which can't be easily fixed with the proposed upstream patch...so there is no patch right now, and on debian bts there is a discussion about who to get rid of openldap2.2...but we can't get rid of 2.2 until 2011
[13:01] <white> Fujitsu: thanks
[13:04] <\sh> moins ogra
[13:04] <ogra> hey
[13:05] <jogi> I am a victim of the fsck check failed. UUID unable to resolve.
[13:05] <\sh> ogra, how is suse and family? :)
[13:05] <jogi> two of my /dev/sdXX partitions are completely missing
[13:05] <ogra> sleepy, we just got up ...
[13:05]  * ogra cant remember when he last slept 10h in a row ....
[13:05] <jogi> google got me to bug 106209 . unable to run any sudo commands
[13:06] <\sh> ogra, me neither :)
[13:06] <ubotu> Launchpad bug 106209 in partman-basicfilesystems "fsck Unable to resolve UUID" [High,Confirmed] https://launchpad.net/bugs/106209
[13:06] <jogi> any workarounds?
[13:06] <ogra> well, it was needed ... the last two/three months were really bad ...
[13:07] <ogra> now i'm back in the distro team and sort my duties to share them out ....
[13:07] <jpatrick> LucidFox: kwest gets a +1 from me
[13:07] <\sh> ogra, but still working on edubuntu?
[13:07] <ogra> yup
[13:07] <ogra> but more focused on edu stuff
[13:08] <ogra> edubuntu will turn into a plain addon, so i dont have to care fo standard distro things ...
[13:08] <Fujitsu> ogra: Ah, interesting.
[13:08] <ogra> things that are not 100% edu related (i.e. LTSP) will move where they belong (i.e. LTSP install as done in edubuntu atm will become part of ubuntu alternate)
[13:09] <jogi> jpatrick, is this kwest the Embedded company in de?
[13:09] <\sh> ogra, not bad
[13:10] <jpatrick> jogi: nop: http://kwest.sourceforge.net/
[13:10] <ogra> i had to put some load off my sholders .... and as usual mdz had the ingenious solution :)
[13:10] <ogra> i wish there would be such a solution for Riddell .... he really deserves a break as well
[13:11] <\sh> ogra, that's why he's cto
[13:11] <ogra> yeah
[13:11] <\sh> ogra, hire some kde guys ,-)
[13:12] <ogra> well, i'll be part of kde developent after i sorted my duties .... kdeedu is prety educational ;)
[13:12] <ogra> as i'll stay part of gnome
[13:12] <\sh> ogra, woot
[13:12] <\sh> go ogra go for kde ,-)
[13:12] <ogra> so at least the edu parts will land on my desk
[13:12] <Hobbsee> ogra: define a plain addon?
[13:13] <ogra> Hobbsee, no OS on it
[13:13] <ogra> only apps and deps
[13:13] <Hobbsee> oh right.  cool
[13:14] <ogra> and we'll try to make it usable on ubuntu-desktop/alternate/server and kubuntu if possible (not sure germinate has that cross functionallity tough)
[13:15] <pochu> Nafallo: new gajim release ;)
[13:17] <\sh> ogra, well, I just applied for a position at UI and astaro
[13:17] <Fujitsu> pochu: He's already working on it.
[13:17] <Nafallo> pochu: updating my pbuilder now
[13:18] <pochu> Nafallo: wow, you're fast :)
[13:18] <Nafallo> :-)
[13:18] <\sh> Nafallo, go go go ;)
[13:19] <Nafallo> feed some changes to upstream as well ;-)
[13:19] <ogra> \sh, crossing my fingers
[13:19] <\sh> ogra, well, after pinky and brain never got the world domination...what else I can do...110 people are standing on the street now,
[13:20] <\sh> Nafallo, add contact is not translated into german ;)
[13:21] <\sh> Nafallo, on gutsy that is
[13:21] <Nafallo> \sh: ouch. confirmed bug then.
[13:21] <\sh> Nafallo, bug number? i'll confirm it
[13:22] <Nafallo> \sh: 162584
[13:22] <Nafallo> \sh: 1bug 62584
[13:22] <Nafallo> gaah!
[13:22] <Nafallo> bug 162584
[13:22] <ubotu> Launchpad bug 162584 in gajim "An English menu entry in German locale in gajim" [Low,New] https://launchpad.net/bugs/162584
[13:23] <\sh> Nafallo, done
[13:23] <Nafallo> cheers
[13:24] <Nafallo> \sh: probably just remove the fuzzy string I guess.
[13:24] <mok0> Anyone here working with HPC clusters?
[13:25] <Nafallo> \sh: there are more fuzzies if you want to take a peek ;-)
[13:26] <\sh> Nafallo, next week most likley...I'm working on wireshark in the moment...and on openldap
[13:26] <Nafallo> oki, no worries.
[13:27] <mok0> ... ok, so does anyone here work with a network of machines?
[13:27] <\sh> I think wireshark is the second source I can determine many "goto" statements..
[13:28] <\sh> mok0, ask maswan ;)
[13:28] <mok0> \sh: thanks
[13:28] <Nafallo> \sh: pushed the fix now. will include it in the upload.
[13:29] <\sh> Nafallo, cool :)
[13:38] <persia> Kmos: If you're advocating a sync for bug 160456, you might also want to retitle it :)
[13:38] <ubotu> Launchpad bug 160456 in gnome-phone-manager "New upstream release 0.40" [Wishlist,Confirmed] https://launchpad.net/bugs/160456
[13:39] <persia> If you're just requesting an update, the upstream changelog isn't as important.
[13:41] <bigon> btw only the 0.30 version is in debian
[13:41] <Kmos> bigon: the debian maintainer knows about 0.40, but it's blocked by gnokki bug
[13:42] <Kmos> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451401
[13:42] <ubotu> Debian bug 451401 in libgnokii3-dev "gnome-phone-manager: FTBFS: No package 'gnokii' found" [Serious,Open]
[13:42] <Kmos> it builds fine in gutsy =)
[13:42] <Kmos> persia: i've retitled it.. :)
[13:43] <persia> Kmos: Thanks.  We'll wait for 451401, and then look at the sync.
[13:43] <Kmos> gnutls13 2.0.4 on debian is out
[13:43] <Kmos> :)
[13:43] <Kmos> persia: ok.. i think that's better
[13:45] <\sh> Fujitsu, added the 4 CVes fixes to edgies version..just testbuilding and attaching the debdiff to #132915
[13:48] <\sh> oh wow...this changelog is insane
[13:52] <\sh> Fujitsu, is pittis version of ubuntu-cve still valid?
[13:56] <persia> \sh: Where are you tracking CVEs against Ubuntu?
[13:56] <\sh> persia, kees has a list http://people.ubuntu.com/~kees/ubuntu-cve
[13:57] <\sh> persia, and I'm comparing with NVD rss list
[13:58] <persia> \sh: Thanks for the pointer.
[14:13] <\sh> coffee and a cigarette...
[14:15] <ogra> ++
[14:38]  * Nafallo uploads gajim
[14:48] <Lutin> gnomefreak: any change planned to gwget2 ? if not, I'll ask for a sync
[14:52]  * \sh has a shower now....
[15:02] <james_w> DktrKranz: http://patches.ubuntu.com/a/abraca/abraca_0.2-1ubuntu1.patch <- What exactly does that fix? There is no bug report mentioned.
[15:04] <DktrKranz> james_w, it fixes FTBFS, see https://launchpad.net/ubuntu/+source/abraca/0.2-1
[15:06] <james_w> DktrKranz: thanks.
[15:06] <DktrKranz> james_w, you are welcome :)
[15:18] <rexbron> lionel: Did you know that a new release of murrine is about to be released (taged in svn)?
[15:19] <rexbron> lionel: As Ubuntu Studio wants to use some of the new features, would it be better to package it up ourselves or to wait for debian?
[15:19] <rexbron> Actually, that last question is open
[15:20] <rexbron> persia: Do you have time for a review?
[15:21] <gnomefreak> Lutin: go ahead and ask for the sync im tied up with 2 other packages for now
[15:22] <Lutin> gnomefreak: ok.
[15:22] <gnomefreak> ty Lutin
[15:23] <james_w> rexbron: you could pop over to #debian-xfce and ask Corsac what his plans are. (He's the Debian maintainer).
[15:24] <rexbron> cool
[15:25] <james_w> rexbron: it is on freenode.
[15:25] <james_w> (unlike many #debian channels).
[15:35] <pkern> Hm, is dh_iconcache intentionally lost from debhelper in Hardy?
[15:36] <jpatrick> pkern: replaced by dh_icon
[15:36] <pkern> So the FTBFS this is causing is intentional?
[15:37] <jpatrick> yes
[15:37] <pkern> Fun for breaking the API...
[15:40] <\sh> pkern, hey...good afternoon...you got my mail?
[15:40] <pkern> \sh: No.
[15:40] <\sh> hmm...
[15:40] <pkern> \sh: Sent when to grep the maillogs?
[15:40] <\sh> pkern, I send it to phil at philkern.de
[15:41] <pkern> \sh: envelope from at least? ;)
[15:41] <pkern> Hm.
[15:41] <pkern> It was maildropped...
[15:42] <\sh> Date: Fri, 16 Nov 2007 08:35:44 +0100
[15:42] <\sh> From: Stephan Hermann <sh@sourcecode.de>
[15:42] <\sh> To: phil@philkern.de
[15:42] <\sh> Subject: Your key
[15:42] <\sh> Message-ID: <20071116083544.39ad0d97@DT220>
[15:42] <pkern> \sh: Ah... *cough* The signed key.  Yeah, I received it, thanks. (:
[15:42] <\sh> *gg*
[15:42] <pkern> Read, imported, forgot about it.
[15:43]  * pkern ponders if the Launchpad email interface actually works.
[15:44] <Kmos> pkern: yes, it works
[15:45] <Kmos> https://help.launchpad.net/BugTrackerEmailInterface
[15:45] <pkern> That doesn't tell me if it works, kthx.
[15:45] <bddebian> Heya gang
[15:46] <Kmos> pkern: try it :)
[15:46] <pkern> Kmos: Guess what I did.
[15:47] <\sh> moins bddebian
[15:48] <ogra1> pkern, the LP email interface works since over a year ... (intrestingly we dont promote that fact much)
[15:48] <\sh> ogra1, because of the known issues? most people don't know what gpg is? ,-)
[15:48] <bddebian> Heya \sh
[15:48] <ogra1> well, devs should :)
[15:49] <\sh> ogra1, most people are not devs...even many sysadmins don't know how to deal with gpg...which is a shame
[15:49] <\sh> ogra1, forget about us :)
[15:49] <ogra1> well, i guess most people would prefer the web UI anyway :)
[15:49] <DaveMorris> \sh because most sysadmins use windows ;)
[15:50] <\sh> DaveMorris, well no
[15:50] <pkern> ogra1: Maybe it ignores me then.
[15:50]  * pkern waits a bit more for a new bug to appear on the web interface...
[15:50] <\sh> pkern, which package?
[15:51] <pkern> \sh: abacus.  I already increased the severity of the existing bug so the new one doesn't need to be filed, but I'm still curious why LP chose not to process my mail. ;)
[15:51] <pkern> Maybe it will tell me in some hours.
[15:51] <pkern> \sh: rebuild starting with a...
[15:51] <ogra1> it takes a while, how long did you wait ?
[15:52] <\sh> hmm...I wrote a script in former days...together with siretart to file bugs via email to malone
[15:52] <\sh> where is that again?
[15:53] <pkern> ogra1: 25 min, heh.
[15:53] <pkern> Even debbugs is quicker nowadays. :-P
[15:56] <LucidFox> Looking for one more MOTU to review http://revu.tauware.de/details.py?package=kwest
[15:57] <Kmos> Bug #163357
[15:57] <ubotu> Launchpad bug 163357 in httrack "Please merge httrack (3.42.1-1) from Debian unstable" [Wishlist,New] https://launchpad.net/bugs/163357
[15:57] <\sh> siretart, ping do you happen to know where our lpbugs.py is hiding?
[15:58] <Kmos> \sh: ubuntu-dev-tools ?
[15:58] <\sh> Kmos, hmmm
[15:58] <\sh> nope
[15:58] <Kmos> don't think so
[15:58] <Kmos> i don't have it
[15:58] <\sh> it was in former times during dapper merging I think...
[15:58] <\sh> a brz archive was on tiber.tauware.de
[15:59] <Kmos> isn't now at ubuntuwire.com ? :)
[15:59] <\sh> I can't find it :)
[16:00] <Kmos> can someone check and upload the httrack ? (it includes the debdiff)
[16:02] <\sh> I wonder if we have a backup of those sources
[16:03] <geser> Hi bddebian
[16:03] <bddebian> Heya geser
[16:06] <geser> \sh: requestsync from ubuntu-dev-tools files the sync request per email (and is in python)
[16:07] <\sh> geser, nope...
[16:07] <\sh> geser, I just want the source of our old tool...:)
[16:09] <geser> \sh: if nobody has a copy of it, you need to write a new one
[16:10] <\sh> geser, I think there is somewhere a backup
[16:10] <geser> a well hidden one?
[16:11] <\sh> geser, nope..I think siretart made a backup somewhere...:)
[16:12] <\sh> ok...I think I'll rest a bit....
[16:12] <\sh> cu later.
[16:20]  * RainCT has a question
[16:21] <RainCT> I'm packaging an app that includes images that are only used by the program, images that are only for the documentation (html) and 2 or 3 images that are used by both
[16:23] <RainCT> those for the website go to /usr/share/doc/<name>/html/images/ and the others go to /usr/share/games/<name>/data/
[16:23] <RainCT> now the question is, should I symlink those images used by both, or patch the documentation, using an absolute path?
[16:24] <RainCT> (I've to patch the docs anyways to change the images from "../data" to "./images" anyways, so it shouldn't be too much of a problem)
[16:24] <geser> is the documentation and the program is the same package?
[16:24] <RainCT> no, documentation is in -doc
[16:24] <RainCT> I've split it into 3 packages:  lightyears, lightyears-doc and lightyears-sound
[16:26] <geser> if lightgears-doc uses some images from lightgears, then it would need to depend on it to find the images
[16:27] <Kmos> can someone review bug 163357 ?
[16:27] <ubotu> Launchpad bug 163357 in httrack "Please merge httrack (3.42.1-1) from Debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/163357
[16:27] <geser> if there are only 2 or 3 images duplicate what about shipped them in both packages to avoid a dependency?
[16:29] <RainCT> geser: ok, thanks :)
[16:33] <RainCT> ah and another question. I set a recommend for lightyears-sound on lightyears, and one for lightyears on lightyears-sound. is this right?
[16:34] <geser> does it work without -sounds?
[16:34] <RainCT> (sound isn't required, and I patched the source so that if lightyears-sound isn't installed it will only print a notice saying that it requires the -sound package, instead of the default behaviour that is printing a warning for each sound file it doesn't find)
[16:34] <geser> the recommends is good
[16:59] <pkern> Another email bug report send... Maybe it works this time...
[17:09] <jdong>  /lastlog jdong
[17:09] <jdong> siretart: thanks :)
[17:09] <siretart> jdong: about xine-lib, right?
[17:09] <jdong> yeah
[17:10] <siretart> jdong: well, in fact, I know about exactly one package that gets borken because of this
[17:10] <siretart> jdong: and that one is installing an vdr output plugin
[17:10] <siretart> so perhaps we should backport that one as well
[17:10] <siretart> it's not overly used, though
[17:11] <geser> pkern: can you pastebin your mail?
[17:11] <jdong> siretart: hmm if that plugin backports cleanly we might as well do it
[17:16] <siretart> jdong: it needs a manual upload, since we need to adjust the debian/control file. libxine-vdr has very tight dependencies on the libxine package. on purpose!
[17:17] <jdong> siretart: well you'd be the one capable of doing it ;-) well let's backport xine-lib first then worry about vdr?
[17:17] <siretart> jdong: exactly my point. yes
[17:24] <pkern> geser: http://durotan.0x539.de/~pkern/lp_bug_report
[17:25] <pkern> Hm.  Maybe it wants a clearsigned message?  But how are attachments signed then...
[17:26] <geser> pkern: iirc you can't attach per email
[17:26] <geser> iirc lp ignores mail attachments
[17:26] <pkern> Bah.
[17:26] <pkern> That's *the* feature why I wanted to use email.
[17:27] <pkern> How bloody annoying.
[17:27] <ScottK> pkern: That's LP for you.
[17:27] <pkern> ScottK: I'll go back to Debian, kthx.
[17:27] <jdong> haha
[17:27] <jdong> e-mail attachments would be a great feature
[17:29] <geser> pkern: and the email requestsync generates are clearsigned (e.g. bug #163330)
[17:29] <ubotu> Launchpad bug 163330 in talksoup.app "[Sync request] Please sync talksoup.app 0.0.20040113-1.1  (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/163330
[17:29] <RainCT> should game executables go to /usr/bin or /usr/games?
[17:30] <minghua> yeah, bug 30225
[17:30] <ubotu> Launchpad bug 30225 in malone "Attach files via email" [High,Confirmed] https://launchpad.net/bugs/30225
[17:30] <pkern> Is there a tool to inject files into librarian?
[17:31] <geser> pkern: perhaps bughelper has a tool for it
[17:32] <pkern> But LP just silently discards my mails... that sucks big time.
[17:32] <geser> or apport (it even manages to attach several attachment at a time)
[17:33] <pkern> It does POST requests to attach them that's right.
[17:51] <jdong> siretart: hey do you think we can do another x264 sync from debian-multimedia for Hardy?
[17:53] <jdong> we are on  1:0.svn20070309, d-m has newer snapshot x264_0.svn20070930-0.0.dsc
[17:53] <jdong> upstream svn changelog shows a number of changesets towards faster encoder performance and better output quality
[18:15] <siretart> jdong: I haven't watched x264 upstream, so I dont have a strong opinion on it
[18:16] <siretart> jdong: how about uploading it to the motumedia PPA and test it there?
[18:23] <jdong> siretart: sounds like a plan, I'll investigate it when I get some time
[18:30] <siretart> jdong: I notice you are not in motumedia yet, shall I add you so that you can upload there?
[18:40] <Kr0ntab> good morning folks...
[18:40] <LaserJock> persia: still up?
[18:50] <jdong> siretart: sure, that'd be nice
[19:48]  * imbrandon yawns
[20:01] <siretart> jdong: done
[20:01] <james_w> hi siretart.
[20:05] <siretart> hey james_w!
[20:05] <siretart> james_w: how are you?
[20:06] <james_w> siretart: good thanks, how are you?
[20:06] <siretart> james_w: currently at my gf's parents, working on my personal server, fighting with vexim atm
[20:07] <james_w> sounds like fun.
[20:08] <james_w> thanks for trying to fix one of my bugs just by marking it fixed and using the power of your mind to make it so, but unfortunately it didn't appear to work :)
[20:10] <siretart> sorry?
[20:10] <siretart> in debbugs or malone?
[20:13] <james_w> debbugs. You marked it in the changelog of builddeb 0.92, but I hadn't got around to fixing it yet. I've just sent the mail to unfix it.
[20:13] <Nafallo> jdong: *poke* :-)
[20:13] <jdong> Nafallo: one sec, in the middle of something
[20:14] <Nafallo> jdong: sure, no problem :-)
[20:14] <crimsun> RainCT: the latter.
[20:14]  * Nafallo wonders why the heck he just read zelut as slut...
[20:18] <siretart> james_w: oh, I'm sorry. that was the bug where you said the bug should be fixed in trunk, right?
[20:20] <jdong> Nafallo: ok, sup? :)
[20:20] <Nafallo> jdong: backport of gajim just uploaded to hardy? :-)
[20:21] <jdong> Nafallo: have you filed a bug on gutsy-backports?
[20:21] <Nafallo> jdong: I built it and run it on gutsy locally ;-)
[20:21] <Nafallo> jdong: nope. never remember where and what to include :-P
[20:21] <Nafallo> jdong: they don't do releases THAT often ;-)
[20:22] <jdong> Nafallo: just on product gutsy-backports, remark version wanted, and that you've verified in a pbuilder
[20:22] <imbrandon> ( and hopefully install tested etc too )
[20:22] <Nafallo> jdong: kewl. I'll go and do that then :-)
[20:22] <joejaxx> lol wth?
[20:22] <joejaxx> patches.ubuntu.com has rss feeds? :D
[20:23] <imbrandon> joejaxx: there reciently has been some hacking on patches.
[20:23] <imbrandon> to add new things
[20:23] <joejaxx> imbrandon: oh ok
[20:23] <joejaxx> interesting
[20:23] <joejaxx> then that is why there are only the current patches
[20:23] <jdong> Nafallo: thanks muchly :)
[20:23] <joejaxx> on the rss feeds then
[20:24] <imbrandon> by-release is fairly new too
[20:24] <RainCT> crimsun: well, found it 2 hours ago, but thanks anyways :P
[20:24] <joejaxx> imbrandon: yeah i saw that on there as well
[20:24] <Nafallo> jdong: #163413
[20:24] <Nafallo> baah
[20:25] <Nafallo> jdong: bug 163413
[20:25] <ubotu> Launchpad bug 163413 in gutsy-backports "gajim_0.11.3-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/163413
[20:25] <Nafallo> thank you ubotu
[20:31] <jdong> Nafallo: thanks
[20:32] <Nafallo> jdong: thank YOU :_)
[20:32] <Nafallo> :-)
[20:43] <erable> Hi,
[20:44] <erable> I want to backports qdevelop for Gutsy but it isn't approved
[20:45] <erable> 	
[20:45] <erable> It has been approved
[20:45] <erable> but i had updated it
[20:46] <jdong> erable: I recall that qdevelop was not packaged in Ubuntu at all
[20:47] <crimsun> `rmadison -uubuntu qdevelop` returns nothing.
[20:47] <erable> jdong: so, it's in REVU
[20:47] <crimsun> revu is not the official current development branch
[20:48] <crimsun> (it's not even a branch per se)
[20:48] <erable> ok, excuse-me but I'm a new packager
[20:48] <crimsun> that's fine :
[20:48] <crimsun> :)  even
[20:49] <erable> :) thanks
[20:49] <imbrandon> the correct course from here then would be to get it uploaded to hardy then backported
[20:50] <imbrandon> revu --> hardy --> gutsy-backports
[20:50] <slicer> Hi. How would I find the diff.gz for a package in hardy?
[20:51] <crimsun> slicer: by looking in the archive or by using launchpadlibrarian
[20:52] <imbrandon> from LP it should be linked on a page similar to this for amarok https://launchpad.net/ubuntu/hardy/+source/amarok/2:1.4.7-0ubuntu3
[20:52] <imbrandon> only for what your looking for
[21:11] <gnomefreak> when the ubuntu installer asks to import settings that doesnt include bookmarks and such right?
[21:13] <slicer> crimsun, imbrandon: Thanks :)
[21:27] <\sh> re
[21:37] <crimsun> re \sh
[21:41] <crimsun> the Debian Maintainers Open Beta post should be of interest to those of us who aren't in the NM/DD queue
[21:41] <frenchy> quail: still there?
[21:41] <crimsun> (http://lists.debian.org/debian-devel-announce/2007/11/msg00004.html)
[21:44]  * imbrandon looks
[21:46] <imbrandon> crimsun: wow, thanks for the link
[21:46] <crimsun> given my itinerary, it'll likely take me several years to get to Debian Maintainer ;)
[21:47] <imbrandon> hehe, i think i'll try that out, or atleaste apply
[21:47] <imbrandon> sounds perfect for me, i dont wanna do the whome NM thing right now but i would like to keep my packages up
[21:47] <proppy> crimsun: thanks for the link
[21:49] <proppy> good night
[22:01] <jdong> stupid question, how to turn Makefile.am -> Makefile.in?
[22:02] <imbrandon> autogen.sh ?
[22:02] <\sh> automake
[22:03]  * jdong tries running automake, as autogen.sh didn't exist
[22:03] <\sh> crimsun, cool stuff...I need to find a package which I would maintain and then ask pkern ,-)
[22:03] <Nafallo> hi \sh
[22:03] <\sh> re Nafallo
[22:03] <Nafallo> \sh: sup? :-)
[22:03] <\sh> Nafallo, tired
[22:03] <jdong> is automake recursive?
[22:03] <\sh> ??
[22:04] <jdong> or do I have to run it in the dir with the .am?
[22:04] <Nafallo> \sh: :-)
[22:04] <\sh> jdong, you should run it from top
[22:04] <\sh> jdong, where your first Makefile.am is, and referencing to the other dirs
[22:04] <\sh> jdong, autofoo tools have a good documentation
[22:05] <\sh> anyways...going to bed now
[22:05] <\sh> cu monday :)
[22:10] <jdong> err, it's not good when running autoreconf results in a debdiff with 128 files changed, 9280 insertions(+), 25342 deletions(-)
[22:10] <jdong> right?
[22:10]  * jdong cries about ktorrent
[22:12] <azeem> jdong: what do you patch?
[22:12] <LaserJock> anybody here use some sort of apt cacher?
[22:12] <LaserJock> hello azeem
[22:12] <azeem> jdong: also, see what versions of autoconf/automake were used upstream
[22:13] <azeem> jdong: if you use similar versions, the delta likely gets smaller
[22:13] <azeem> LaserJock: hi
[22:13] <jdong> azeem: ah, that might be it, I might be using a different automake compared to upstream
[22:14] <jdong> azeem: well my patch just trivially removes one .cpp/.h pair from the source tree; I'll go in by hand and edit the Makefile.in file
[22:14] <jdong> it's like 4 lines to change by hand
[22:14] <jdong> better than spamming a gigantic delta
[22:26] <crimsun> hmm, I guess I'd better merge alsa-plugins first in hardy.
[22:27] <crimsun> hopefully in a few hours I'll have the prelim stack for "pulseaudio by default" uploaded
[22:28] <crimsun> anyone have any thoughts regarding having /all/ ALSA-enabled apps routed through PulseAudio [via the alsa-lib pulse plugin]?
[22:28] <crimsun> Fedora 8 apparently does that
[22:28] <crimsun> pros: most apps will just work
[22:29] <crimsun> cons: oss-only apps will still require hackery via padsp
[22:30] <crimsun> cons(2): extra configuration required for specific use cases that require direct/lib-level access to the hardware
[22:30] <Fujitsu> \sh_away: That's the right branch, yes. I've updated the status of all those CVEs in my branch.
[22:32] <jdong> crimsun: I've got a friend who already does that for his Ubuntu setup, inspired by Fedora 8
[22:32] <jdong> crimsun: he's been bugging me to do it for a week now, so I'm guessing it's working well for him :D
[22:32] <crimsun> jdong: to what does "that" refer?
[22:33] <jdong> crimsun: route everything through Pulse
[22:33] <crimsun> ah.  yeah, that's the default Fedora 8 config.
[22:33] <jdong> I think he did mention that WINE required padsp or something to work
[22:34] <crimsun> hmm, considering LTS->LTS and our current uses, I'm strongly considering omitting that.  This means that we will /not/ configure the alsa-lib plugin via ~/.asoundrc.asoundrc
[22:35] <crimsun> It's early enough in the 8.04 LTS dev cycle that if users seem to be enabling it en masse, we'll just put it in there
[22:36] <jdong> crimsun: it shouldn't be hard to revert if some seirous problem pops up during the dev cycle, right?
[22:36] <minghua> LaserJock: I use apt-proxy.  In Debian, though.
[22:36] <crimsun> jdong: revert what?
[22:36] <crimsun> jdong: the setting of ~/.asoundrc.asoundconf to use the alsa-lib pulse plugin?
[22:36] <jdong> the pulse plugin
[22:37] <crimsun> jdong: we already Recommend libasound2-plugins
[22:37] <crimsun> it's the actual configuring ~/.asoundrc.asoundconf that matters here
[22:37] <jdong> crimsun: oh is it configured as a per-user thing?
[22:37] <crimsun> once we set a hint to have the user configure it, it's more difficult to automate /removal/ of it, which is what "reverting" it would entail
[22:38] <crimsun> jdong: generally, yes.  We could provide the global /etc/asound.conf ...
[22:38] <jdong> crimsun: well the simple cop-out is to call it development-version-user responsibility ;-)
[22:38] <jdong> crimsun: ideally it'd be nice to have a control panel type GUI frontend to this asoundrc config option
[22:38] <jdong> but that's probably quite complex
[22:38] <Fujitsu> LaserJock: I use apt-proxy on a Feisty server, though it occasionally does Very Bad Things, and simply doesn't work.
[22:39] <crimsun> jdong: http://launchpad.net/~asoundconf-ui
[22:39] <crimsun> jdong: existed for some time ;)
[22:39] <jdong> crimsun: why don't I get these memos?!
[22:39] <crimsun> without the tilde
[22:39] <crimsun> (http://launchpad.net/asoundconf-ui)
[22:40] <crimsun> GTK+2.0, Qt3, and Qt4 versions
[22:40] <crimsun> (yay for duplication)
[22:41] <jdong> crimsun: this is where we need KDE4 to write a toolkit abstractor, then put that on top of wxwidgets for additional abstraction!
[22:41] <LaserJock> minghua and Fujitsu: either of you us apt-cacher?
[22:41] <LaserJock> *use
[22:41] <corenominal> hi guys
[22:42] <LaserJock> I've now got 3 gutsy machines on my home network
[22:42] <crimsun> jdong: for great abstraction-abstraction justice?
[22:42] <LaserJock> I'd like to not waste too much bandwidth
[22:42] <minghua> LaserJock: No.
[22:42] <jdong> crimsun: definitely :)
[22:45] <minghua> LaserJock: Actually, for a home network, I am starting to believe the best way is to share /var/cache/apt/archives/ among boxes.
[22:45] <corenominal> anyone available to help with REVU queries?
[22:46] <LaserJock> minghua: I was kinda wondering about that
[22:46] <LaserJock> though not as a share, but me rsyncing
[22:47] <LaserJock> I'd have to think about the best way to share that
[22:47] <minghua> Well, if disk space is never a problem, rsync works, too.
[22:47] <LaserJock> I've not used NFS or samba before
[22:48] <LaserJock> nah, I don't think diskspace is an issue
[22:48] <LaserJock> as long as I clean up old stuff
[22:49] <minghua> You won't have much old stuff to clean if you stay at gutsy, I think.
[22:50] <LaserJock> yep
[22:50] <LaserJock> I should also do the same for pbuilder cache
[22:51] <LaserJock> I've wondered before, if pointing Debian and Ubuntu pbuilders to the same apt cache is ok
[22:51] <minghua> You haven't used APTCACHE for pbuilder yet?
[22:52] <minghua> LaserJock: I don't think so.  But it's trivial to separate the caches, so I don't see why you would want to do that.
[22:52] <LaserJock> I think all of my pbuilders pull from the same dir
[22:54] <LaserJock> I never set APTCACHE
[22:55] <minghua> Hmm.  I remember the default behavior is not caching anything.
[23:12] <jussi01> minghua: IIRC, pbuilder default is to cache in /var/cache/pbuilder/aptcache/ ?
[23:14] <minghua> jussi01: It's very possible I am remembering wrong.
[23:15] <jdong> minghua: no, default behavior is to save in /var/cache/pbuilder/aptcache
[23:15] <jdong> but via a hardlink
[23:15] <jdong> so of course if that's on a different fs then /builds it won't cache anything ;-)
[23:18] <minghua> jdong: Good to know.  Thanks.
[23:18] <jdong> no problem
[23:18] <minghua> It's very unlikely that build/ and aptcache/ will be on different partitions.
[23:21] <jdong> minghua: true, unless you're a maniac like me. I love to mount tmpfs on build/
[23:22] <minghua> Heh.
[23:23] <jdong> it really miraculously speeds up the process of small package builds
[23:24] <minghua> jdong: Which is faster, LVM snapshot or tmpfs?
[23:24] <minghua> ...or can you use LVM snapshot on a tmpfs too?
[23:26] <jdong> minghua: haha I'm not sure. IF the build fits into RAM or close to fitting, I can't imagine anything faster than tmpfs
[23:26] <jdong> minghua: but lvm snapshot is good too, as it prevents repetitive building from wearing/fragmenting your /var fs
[23:27] <minghua> jdong: But you still need to decompress the tarball even if you use tmpfs, don't you?
[23:28] <minghua> I was under the impression that LVM snapshot is much faster than decompressing tarballs.
[23:28] <jdong> minghua: yes, which will take $time_to_read_80MB
[23:28] <jdong> minghua: which is probably <5s on most modern hardware. it's the writing out the decompressed contents part that takes bloody forever
[23:29] <minghua> Hmm, makes sense.
[23:33] <crimsun> success!
[23:33] <LaserJock> crimsun: yeah?

[23:35] <LaserJock> hmm
[23:35] <LaserJock> it's getting annoying have two gmail accounts for one computer
[23:35] <tonyyarusso> so just forward one
[23:36] <LaserJock> one is my wife's
[23:36] <LaserJock> I don't want to get all her stuff
[23:36] <LaserJock> I hadn't thought about how annoying that would be
[23:36] <tonyyarusso> oh
[23:36] <tonyyarusso> wait, why is this annoying?
[23:36] <LaserJock> cause I have to sign out of mine every time she wants to look at her email
[23:36] <minghua> LaserJock: Use a decent MUA. :-)
[23:37] <LaserJock> then I've got to sign back in
[23:37] <LaserJock> I'm used to just having gmail open 24x7
[23:37] <crimsun> err, don't you two have separate user accounts?
[23:37] <LaserJock> crimsun: no
[23:37]  * tonyyarusso is with crimsun ...
[23:37] <tonyyarusso> why not?
[23:37] <LaserJock> I tried that once
[23:37] <LaserJock> didn't really work
[23:37] <tonyyarusso> how so?
[23:37] <minghua> LaserJock: Use two browser profiles.
[23:37] <crimsun> eh?  I have three different accounts just for me.
[23:37] <LaserJock> cause then it was me having to log out for her to log in
[23:38] <tonyyarusso> then you'd have the fast user switch thing to your advantage
[23:38] <LaserJock> yeah, I'm not sure I want to do fast user switching
[23:38] <minghua> (No, that wouldn't work either...)
[23:38] <LaserJock> it might work though
[23:38] <tonyyarusso> Or you could have one of you use epiphany and one firefox, etc.
[23:38] <LaserJock> crimsun: heh, I've only ever used one account on my computers, Windows, OS X, and Linux
[23:38] <crimsun> an unprivileged one for Ubuntu development, an privileged one for administration, and another for package testing
[23:38] <crimsun> (the last is unprivileged)
[23:39] <LaserJock> hmm, interesting
[23:39] <crimsun> I've been doing Leopard's "unprivileged Guest account that gets wiped - sort of" for ages - and I'm definitely not the first ;)
[23:39] <LaserJock> it never ceases to amaze me how little I actually use my computer :(
[23:44] <geser> LaserJock: have you looked at https://addons.mozilla.org/de/firefox/addon/3255 ?
[23:45] <LaserJock> something like that
[23:45] <LaserJock> and it was more complicated
[23:45] <LaserJock> than just logging out