[00:10] <jscinoz> persia you here?
[00:10] <crimsun> (idle 9+ hours)
[00:11] <ion_> I’d guess he’ll be awake within an hour. :-)
[00:12] <ion_> I know because i remember our sleep rhythms have a phase difference of about 12 hours. :-)
[00:13] <ion_> Uh, that was a brainfart. Going to sleep when someone else wakes up doesn’t mean that.
[00:13] <Ubulette> crimsun: could you please re-check http://revu.tauware.de/details.py?package=mozilla-devscripts ? I've fixed the FSF address
[00:18] <crimsun> Ubulette: looks good.  Archived, uploaded.  Thanks for your work!
[00:18] <Ubulette> thx
[00:19] <Ubulette> will it be in main or universe ? it's a build-dep for some packages in main
[00:19] <Ubulette> well, s/it's/it will be/
[00:19] <Ubulette> obviously
[00:20] <ion_> Could someone perhaps take a look at http://revu.tauware.de/details.py?package=hardware-connected? (A small program that checks whether given hardware exists in the system; suitable for scripting)
[00:20] <crimsun> Ubulette: it will go into universe per default.  An MIR for main promotion should turn up no issues, but it's up to the Ub moz team to request that.
[00:21] <Ubulette> ok, i'll ask asac then
[00:22] <Ubulette> i'm part of ub moz team btw ;)
[00:22] <crimsun> (yes, I know :-)
[00:25] <crimsun> heh
[00:25] <crimsun> /* Why yes, I do have the NIH syndrome. */
[00:25] <Ubulette> eh?
[00:26] <crimsun> referring to ion_ :-)
[00:26] <Ubulette> oh
[00:28] <jscinoz> Hey guy's i've reuploaded my urbanterror and urbanterror-data packages, fixing most if not all the issues persia brought up on them. Could someone review them if possible?
[00:28] <crimsun> you're queued (save -data; it's too large for me to download without having to resort to MAC-changing hacks)
[00:30] <crimsun> ion_: not a blocker, but consider putting redistribution terms in your man pages, too.  Never know who's going to review it for, say, Debian, and might be more pedantic than me.
[00:32] <ion_> Shall i do it immediately, or for the next release?
[00:32] <crimsun> wouldn't hurt for the former
[00:33] <ion_> Ok, i’ll upload it in a bit.
[00:33] <crimsun> I wouldn't -not- advocate it simply because of them being missing, however.
[00:34] <jscinoz> crimsun were you referring to me with "you're queued..."
[00:34] <crimsun> jscinoz: yes.  I'm processing another source package currently.
[00:35] <jscinoz> oh :)
[00:37] <ion_> I don’t really get how GPL-2 affects documentation (whereas i do understand its implications on *code), but i guess i’ll just throw it to the man pages as well. :-P
[00:38] <ion_> I mean, it’s not as if anyone’s going to create a new product from the man page alone. :-)
[00:54] <ion_> crimsun: Ok, i uploaded a new package with licensing info in the man page. It should be visible on REVU in six minutes or so.
[00:59] <rzr> hi
[01:00] <rzr> i was wondering, i plan to update a new upstream version of package
[01:00] <rzr> is it better to do it debian or ubuntu side ?
[01:00] <crimsun> former if at all possible
[01:01] <rzr> which one to start with ?
[01:02] <crimsun> rzr: do the work in the Debian repo, then request an Ubuntu sync from Debian
[01:02] <rzr> ok that's what i thought too but it may be slow
[01:03] <Ubulette> I've created a set of (Prism) webapps for google maps, with fullscreen and auto-hidden control.
[01:03] <Ubulette> now I want to package that
[01:03] <Ubulette> Does this make sense: http://paste.ubuntu.com/3184/ ??
[01:05] <CheGuevara> homepage goes under source i believe
[01:05] <Ubulette> not here, I want homepages per webapp
[01:06] <CheGuevara> oh right
[01:06] <Ubulette> i've already packaged prism and some webapps so the syntax is correct. Here, I'm not sure about fr and de
[01:08] <Ubulette> i looooove google maps
[01:08] <Ubulette> i can spend hours on it
[01:09] <crimsun> rzr: you can e-mail the maintainers and utilise #debian-mentors on OFTC.
[01:09] <rzr> i am in contact w/ them
[01:09] <rzr> will try then
[01:30] <effie_jayx> hey guys I want to gt back to motu work tomorrow
[01:30] <effie_jayx> any areas where I should focus... or should I jst try bug fixes...
[01:30] <effie_jayx> ?
[01:33] <persia> effie_jayx: bug fixes would be great.  There's also still a large number of packages unique to Ubuntu and missing watch files.  Also, it's coming near time to start testing upgrade paths: if something in Dapper or Gutsy doesn't upgrade to hardy cleanly, this should be fixed.  And there is always the FTBFS queue.
[01:35] <Ubulette> good advices as always
[01:36] <effie_jayx> persia,  great
[01:37] <Ubulette> persia, did you read my question about google maps / prism ?
[01:38] <persia> Ubulette: Yes.  Is this just a selection of prism shortcuts?
[01:38] <effie_jayx> persia,  let me see if I can decode all you said ;)... packages unique to ubuntu (merges) ?
[01:39] <persia> effie_jayx: No.  packages unique to Ubuntu aren't merges, because they aren't maintained in Debian.  See http://qa.ubuntuwire.com/uehs/ for the lists of missing watch files, broken watch files, and packages not in sync with upstream.
[01:39] <Vorian> I can help with watch files
[01:39] <persia> Vorian: We're missing 460.  Please do :)
[01:40] <Ubulette> persia, i've created some css to customize the webapps, that's the added value compared to the -classic one
[01:40] <Vorian> persia: I'm on it :)
[01:40] <persia> Vorian: great.
[01:40] <Vorian> persia: what's the procedure after the watch file is added?
[01:40] <effie_jayx> persia,  k I shall focus on them and see If I can be more productive...
[01:41] <persia> Ubulette: OK.  I can now see the rationale for the package.  Next question: why not have a prism-plugins package that contains all the various services you might want to add later, to save common data, rather than prism-$myapp packages for each interesting set of packages.
[01:41] <persia> ?
[01:41] <nxvl> happy new year!
[01:41] <Vorian> hey nxvl, happy new year to you :)
[01:42] <persia> effie_jayx: OK.  Watch files are good, but if you get bored with them, consider looking at upgrade paths and FTBFS (and always, bugs need fixing).
[01:42] <Ubulette> persia, hmm. those are not plugins at all, but standalone applications.. the difference with any other app is that it's web based, through prism (and xulrunner)
[01:43] <ion_> persia: I uploaded apt-mark-sync 0.0.2-0ubuntu1, as crimsun suggested adding licensing info to man pages as well, but i understand what you wrote in the previous upload’s comments (about waiting for archive admins).
[01:43] <effie_jayx> i am writing this down
[01:43] <persia> ion_: The issue is that once it is in the NEW queue, nobody is going to upload it from REVU.  If it gets rejected, please resubmit.  If it gets accepted, a debdiff (or interdiff) addressing the outstanding issues would be most welcome.
[01:44] <Ubulette> persia, each deb contains at least a .webapp file, a .desktop file and one icon
[01:45] <persia> Ubulette: How about prism-applications then.  I'm just thinking you don't need lots of different debian/rules and debian/copyright, etc. files for each of the web applications.  Different binary packages is good, perhaps all depending on a -common and symlinking to /usr/share/docs/prism-applications-common
[01:47]  * persia wishes LP worked nicely with prism
[01:47] <Ubulette> persia, to share what ? i don't see what would be in the commom package
[01:48] <persia> Ubulette: /usr/share/docs/prism-applications/* (copyright, changelog, README, etc.).
[01:48] <Ubulette> LP, me too, but that mean changing the design (of LP)
[01:48] <Ubulette> +s
[01:49] <persia> Maybe nice to have some documentation on extending it too, which might encourage upstreams using Ubuntu to submit bugs for inclusion of their applications (when they work with prism).
[01:49] <Ubulette> persia, what does copyright mean in that context ? i'm author of the css file, not the icon and of course not of the web site
[01:50] <persia> Ubulette: /usr/share/doc/<package>/copyright is pulled from debian/copyright.
[01:50] <persia> (in which you'd indicate the copyright owners of the css file, and the icon)
[01:51] <Ubulette> yes but then, what is shared in common ? it's always different per webapp
[01:53] <persia> Ubulette: If you have one source package per webapp, you need to store all of a .dsc, a diff.gz, and an orig.tar.gz on the servers, plus a full binary for each architecture for each application.  As these are all small, they would compress together with considerable savings, so the total disk space used by the archives would be smaller.  A minor point (and per-app isn't wrong), but maybe interesting.
[01:53] <persia> By putting them all in a single source package, you only have one debian/copyright (which goes in -common), one debian/rules, etc.
[01:56] <Ubulette> hm. i see. something like prism-webapps as unique source pkg, with dirs grouping webapps per family, one being google-maps (ie my current source tree)
[01:57] <Ubulette> and 1 bin deb per webapp
[01:57] <persia> Ubulette: Right.  As an added benefit, you wouldn't need to go through source NEW for each new webapp (although you still have binary NEW).
[01:57] <persia> Ubulette: Unless there's a strong argument against (say a main/universe split, etc.), you might just stuff all the new binaries into the prism source, if you like.
[01:58] <persia> Actually, I take that back.  The prism source tracks upstream, and prism-webapps would have a different upstream (some LP branch).
[01:58] <Ubulette> i want to keep prism alone.
[01:58] <Ubulette> yep
[02:00] <Ubulette> hmm, i feel there's something good here. thanks
[02:00] <Ubulette> about doing .fr .de .co.jp .whatever, is that a problem ?
[02:01] <Ubulette> it's not really localization
[02:01] <persia> Doesn't google maps mirror it correctly?  If not, you'd get style points by picking a mirror based either on user-locale or user-physical-location (assuming you have a reliable means to determine this).
[02:02] <persia> (so a single app that checked the current status, and called the right prism shortcut)
[02:07] <Ubulette> it's not really a mirror. maps are probably the same but services are not always in sync, and languages are different for everything. seems difficult to auto detect that..
[02:08] <persia> Ubulette: The user locale should at least give you a preferred language.  It's not wrong to have separate binaries, but matches "just works" better if users are automatically redirected to their preferred language environment.
[02:09] <Ubulette> my desktop is US, yet I'm french, and I read/type jp and cn sometimes. which webapp would I want?
[02:09] <imbrandon> presumeably what your locale is set to
[02:09] <imbrandon> thats the reason for it
[02:09] <Vorian> what is the watchfile syntax for git snapshots
[02:10] <persia> Vorian: Does upstream never release at all?
[02:10] <Vorian> my bad
[02:11] <Vorian> thanks for the reminder :)
[02:11] <persia> Vorian: Sure.  Just track the latest release (and the snapshot should be newer).  When upstream makes the next release, it should tell us that we don't need to track a snapshot anymore (which is good).
[02:11] <Ubulette> (I'll do the watch files for mozilla packages, I wanted that to be part of mozilla-devscripts sometimes)
[02:12] <persia> Ubulette: watch files must be in the affected source.  On the other hand, having mozilla-devscripts use the watch files to keep the team informed sounds like a good way to do things.
[02:12] <Ubulette> persia, that's what i meant.
[02:13] <persia> Excellent then :)
[02:13] <Ubulette> -be part of+be used by
[02:20] <rzr> can you suggest me a page to read to sync a package like https://bugs.launchpad.net/ubuntu/+bug/177986 ?
[02:20] <ubotu> Launchpad bug 177986 in ubuntu "please sync package whitedune from debian experimental" [Undecided,New]
[02:21] <persia> rzr: https://wiki.ubuntu.com/SyncRequestProcess
[02:21] <rzr> ok perfect
[02:22] <persia> rzr: We've passed DebianImportFreeze, so you'll want to include a short Rationale explaining why the sync deserves a freeze exception (many do, but to make it easier for the person approving the freeze exception)
[02:23] <rzr> actually i can wait next freeze
[02:23] <persia> rzr: Would the sync you wanted to request not benefit hardy?
[02:24] <rzr> no, i am not hurry
[02:35] <Ubulette> persia, initially, I wanted this google-maps thing to be native (as it was so small). I bet you're opposed to the idea, right?
[02:36] <persia> Ubulette: Yep.  Especially so as other distributions that ship prism would likely also benefit from some nice CSS wrappers to make certain applications look nicer.
[02:37] <Ubulette> yep
[02:38] <Ubulette> i wish some css artists could make google-reader and gmail looks more gnomish
[02:38] <imbrandon> prism is gnome only now?
[02:38] <Ubulette> no
[02:38] <imbrandon> ahh then very bad idea
[02:39] <Ubulette> lol
[02:39] <persia> imbrandon: Why?  If there were selectable CSS to match shipped desktop themes, wouldn't that be an improvement?
[02:40] <imbrandon> sure if it was selectible
[02:41] <imbrandon> but as just discovered with the maps localization , apparently prism apps cant choose css at rumtime
[02:41] <persia> imbrandon: Right.  So let's welcome CSS submissions for Ubuntu, Kubuntu, Xubuntu, etc. and then complain if it doesn't work right (it would be a bug).
[02:41]  * persia advocates wrapper scripts
[02:42] <imbrandon> well with wrapper scripts you have more than one  binary, i'd rather think of it as a bug in prism that cant select css at runtime
[02:42] <persia> imbrandon: That works for me.  File a bug.
[02:43] <imbrandon> after all the css is a conffile in this case and most apps accept a conffile location overide
[02:43] <imbrandon> on cli
[02:43]  * persia doesn't think css should be a conffile, only a configuration file.
[02:44] <Ubulette> changing css at runtime is possible in firefox so as it's also a xul app, prism should be able to do it at some point (it does not now)
[02:46] <Ubulette> google reader is good for languages, you can just change it at runtime in the settings
[02:46] <jscinoz> persia, have you had a chance to review my changed urbanterror packages?
[02:47] <persia> jscinoz: No, and I probably won't be reviewing much again until next Monday (especially for large, complex packages).  I suspect you've fixed most of what I found, and think someone else would likely give you better feedback.
[02:48] <jscinoz> ok cheers :)
[02:49] <jscinoz> also for the old server source package which is no longer needed since both source packages are combined into one, do i need to do something to remove it or just make a comment saying that and leave it?
[02:49] <persia> I already archived it, based on your advertisement for the new package earlier.
[02:49] <jscinoz> thanks :)
[02:55] <imbrandon> mmmm if my meta-data was free i would be happy ...
[02:55]  * imbrandon pondersa moment
[02:56] <imbrandon> anything on revu need doing before i get off in my own little world ?
[02:56] <imbrandon> ugh i have to return to work tomarrow after this long holiday :(
[02:58] <Hobbsee> hum.  now, i didn't mean to upload mplayer
[02:58] <imbrandon> Hobbsee: heh
[04:00] <LaserJock> happy New Year MOTU Land!
[04:00] <joejaxx> LaserJock: !!!! :D
[04:00] <persia> Happy New Year LaserJock
[04:00] <LaserJock> I'm finally back home
[04:01] <Hobbsee> hey LaserJock!
[04:01] <Hobbsee> LaserJock: ponies!
[04:01] <LaserJock> ... with internet
[04:01] <Hobbsee> LaserJock: so, now you have time to put up the ponies, which you carefully wrote while you were away
[04:01] <LaserJock> Hobbsee: ah yeah, I was trying to work on it some over the vacation but the lack of internet was difficult
[04:02] <StevenK> PONIES!
[04:02] <LaserJock> my parents 28.8 dialup was ... painful
[04:03] <StevenK> Where do they live, the Sahara?
[04:03] <Hobbsee> somewhere in australia
[04:03] <LaserJock> no
[04:03]  * StevenK scoffs
[04:03] <LaserJock> Montana
[04:03] <LaserJock> they are only 5 miles from town
[04:03] <crimsun> hey now, I'm on a 28.8 ATM.
[04:03] <LaserJock> but they can't even get full dialup speeds
[04:04] <StevenK> LaserJock: Is their phone line pair gained?
[04:04] <imbrandon> LaserJock!
[04:04] <LaserJock> they are looking into doing internet over satellite
[04:04] <LaserJock> but it's pretty pricey
[04:04] <LaserJock> hi imbrandon
[04:05] <StevenK> Internet over satellite is expensive and laggy
[04:05] <LaserJock> I managed to snag myself a shiny new laptop over Christmas
[04:05] <imbrandon> nice
[04:05] <LaserJock> StevenK: yep, but that's pretty much their only option
[04:05] <StevenK> One-way is ~ 400ms, two-way is ~700ms
[04:05] <StevenK> SSH over two-way satellite is somewhat painful
[04:08] <LaserJock> this new laptop has a big 12cell battery, I've only heard of 6 and 9cell
[04:08] <imbrandon> yea i had to use satalite in TX , was not fun, at times dialup is less laggy
[04:08] <LaserJock> but it gets ~ 5+hrs right now so that's cool
[04:08] <imbrandon> LaserJock: nice
[04:09] <imbrandon> man i'm gonna go nuts no smokin, ugh
[04:09] <LaserJock> imbrandon: heh, I saw that
[04:09]  * StevenK waits for imbrandon to start holding his pen like a cigarette
[04:09] <imbrandon> lol
[04:10] <StevenK> "Trying to quit, are you?" 'Yeah, how can you tell?' "You've been trying to light your pen for three minutes"
[04:10] <imbrandon> BWHAHAHA
[04:10] <imbrandon> sounds about right
[04:10] <imbrandon> i've started chewing toothpicks, i have already went through one whole box in 24 hours
[04:11] <imbrandon> not even 24 hours
[04:11] <StevenK> I'm not sure if splinters are any better
[04:11] <imbrandon> heh, my trashcan by my desk is full og mtdew cans and splintered toothpicks
[04:11] <imbrandon> of*
[04:11] <LaserJock> lol
[04:12] <LaserJock> imbrandon: how's MOTU SRU going?
[04:12] <imbrandon> LaserJock: good, not much action atm but seems to be working out well
[04:12] <imbrandon> i'd imagine mid jan things to pickup
[04:13] <LaserJock> I'm still going through email but it looks like we might need to clarify/document some stuff on -motu ML
[04:13] <imbrandon> i've given up on the flashplugin thing, its a no win any way i have gone about it, i'm for removal at this point
[04:13] <imbrandon> LaserJock: yea, a little clarification might be in order but all in all i think its ok
[04:14] <imbrandon> mostly it was just those not on irc that got confused , but a simple email should clear things up
[04:15] <LaserJock> mhm
[04:15] <imbrandon> we cant even do the 60mb thing with a clear mind, it has security flaws
[04:15] <imbrandon> so to fix the security issues we have to break konqueror
[04:15] <imbrandon> and then presumeably fix it
[04:16] <ion_> I’m going not to ever have started smoking in the first place. :-)
[04:16] <imbrandon> ion_: that would be a good thing
[04:17]  * StevenK quit smoking years ago
[04:17] <imbrandon> adobe really screwed us on this one
[04:18] <ion_> (New tenses for time travelers: going not to have ...ed)
[04:18] <LaserJock> imbrandon: flash?
[04:18] <imbrandon> yea
[04:19] <StevenK> I got sick of being completly out of breath after running up a flight of stairs
[04:19] <imbrandon> StevenK: exactly
[04:20] <LaserJock> why does it do that? just too much crap in your lungs?
[04:20] <persia> StevenK: You just forgot to maintain the extensive level of exercise required to smoke (not that smoking is good, or anything)
[04:20] <imbrandon> LaserJock: deminished lung capasity
[04:22] <imbrandon> lucky for my pocket book though toothpicks are far cheaper and have less side effects
[04:22] <imbrandon> hehe
[04:23] <LaserJock> yeah, cost alone would make me not want to start
[04:23] <imbrandon> $0.50 a box , per week VS. $5 a day for cigarettes
[04:23] <StevenK> imbrandon: Yes, but you look like an absolute tool buying fourteen packets of toothpicks
[04:23] <imbrandon> hahaha
[04:23] <Hobbsee> hahaha
[04:24] <ion_> Who said you don’t look like one for buying cigarettes? ;-)
[04:24] <StevenK> Or asking the supermarket for a cartoon of toothpicks ...
[04:24] <imbrandon> i'm sure they will be far easier to put down
[04:24] <imbrandon> :)
[04:25] <joejaxx> if there is a package that is going into ubuntu but that is not in debian do we ignoren the XSBC-O-M warnings?
[04:25] <joejaxx> ignore*
[04:25] <imbrandon> joejaxx: no it should still have a  @ubuntu maintainer addy iirc
[04:25] <joejaxx> that is interesting
[04:26] <joejaxx> so should i put myself as the original maintainer?
[04:26] <imbrandon> yup
[04:26] <joejaxx> ok
[04:26] <LaserJock> the @ubuntu.com requirement is archive-wide, regardless of source
[04:26] <joejaxx> LaserJock: i was just wondering since it was not in debian :P
[04:27] <joejaxx> so even for native packages?
[04:27] <joejaxx> ie without with -0
[04:27] <xtknight> how come XSBC-O-M is not automatically added for everything sync'd?  (like sometimes when ppl make debdiffs they have to fix XSBC-O-M)
[04:27] <persia> joejaxx: What native package?
[04:27] <imbrandon> yea unfortunately the spec just obsoleted the Maintainer Field imho
[04:27] <LaserJock> joejaxx: yep, just one of the side effects of implementing something archive-wide to "fix" something debian-specific
[04:27] <imbrandon> joejaxx: yup
[04:27] <persia> xtknight: It is added in the binary packages, but we don't modify the source packages.
[04:28] <joejaxx> lol wow that stinks :\
[04:28]  * joejaxx puts himself in there twice :P
[04:28] <joejaxx> j/k
[04:28] <LaserJock> joejaxx: if it's got an "ubuntu" in the version it needs an ubuntu address
[04:29] <imbrandon> and native packages
[04:29] <imbrandon> ( the few of them )
[04:29]  * persia notes that ubuntu maintainers with no XSBC-O-M are welcome, as long as the ubuntu maintainer is a small team or specific person, and the package doesn't exist elsewhere to get an original maintainer.
[04:29] <LaserJock> imbrandon:  if they don't have an ubuntu version they won't need it afaik
[04:30] <persia> LaserJock: There are a few Ubuntu-native packages with Ubuntu native versions (e.g. ubuntu-meta)
[04:30] <imbrandon> LaserJock: native means there is ONLY a ubuntu version ( i dont mean debian native )
[04:30] <joejaxx> so should i just make it native?
[04:30] <joejaxx> lol
[04:30] <imbrandon> joejaxx: no
[04:30] <persia> imbrandon: Some of them have been adopted by debian (who doesn't use -XdebainY amusingly)
[04:30] <LaserJock> imbrandon: I mean "ubuntu" in the version
[04:30] <imbrandon> LaserJock: right i do too
[04:31] <imbrandon> e.g. ubuntu-meta
[04:31] <persia> joejaxx: The only reason to have a native package is if you are truly convinced it isn't useful anywhere else.  There are lots of annoying issues with passing native packages back and forth with Debian, and even worse ones for other distributions.
[04:31] <LaserJock> well we can have Ubuntu native packages without "ubuntu" in the versino
[04:31] <joejaxx> persia: oh ok
[04:31] <imbrandon> LaserJock: right and they still need a @ubuntu addy
[04:31] <LaserJock> and those wouldn't fall under the address checking
[04:31] <LaserJock> imbrandon: no they don't
[04:31] <imbrandon> LaserJock: why not ?
[04:32] <LaserJock> because there is not policy that says so, as far as I know
[04:32] <ion_> Anyone feel like taking a look at http://revu.tauware.de/details.py?package=hardware-connected (a program to check whether certain hardware is connected; for scripting)? I believe i have taken care of the problems pointed out so far. Thanks. :-)
[04:32] <persia> joejaxx: Also, a lot of packages that are mostly Ubuntu aren't native.  mythbuntu-* is a good set of examples.  The packaging is all done in LP, and pulled occasionally into the distro.  Nobody else uses it, but they could if they wish.
[04:32] <imbrandon> sure its the same policy, just because there is ONLY ubuntu changes doesnt make it less a ubuntu change
[04:33] <LaserJock> imbrandon: no, the debian maintainer spec only says that if it has "ubuntu" in the version that it needs an ubuntu address
[04:33] <joejaxx> i only brought it up because i put the version as -0ubuntu1 and dpkg-source was complaining :P
[04:33] <imbrandon> joejaxx: rightfully so
[04:33] <persia> LaserJock: The debian maintainer spec only applies to packages maintained in Debian.
[04:33] <LaserJock> persia: not exactly
[04:33] <imbrandon> LaserJock: ok, thats a bug imho, but ok
[04:33] <LaserJock> it's enforced archive-wide
[04:33] <persia> joejaxx: For non-native, you need to have a separate orig.tar.gz
[04:33] <joejaxx> and this is why i am confused
[04:33] <joejaxx> as i am not a debian maintainer
[04:34] <persia> LaserJock: Right.  That's just pragmatism.
[04:34] <persia> joejaxx: You don't need to have it, but people like to see it in case they have a question about the initial packaging later.  In my opinion, it's largely useless (as long as Maintainer is an Ubuntu address).
[04:35] <LaserJock> persia: right, but that's the "policy" we have
[04:35] <LaserJock> what the archive will and will not accept
[04:35] <LaserJock> anyway, gotta run
[04:35] <imbrandon> l8tr
[04:35] <persia> LaserJock: The policy we have is that all packages need to have an ubuntu maintainer.  We don't have a policy that all packages must have XSBC-Original-Maintainer, although many people use that.
[04:35] <LaserJock> first day back at work tomorrow
[04:35] <joejaxx> i do not even know if i have a ubuntu email yet
[04:35] <joejaxx> lol
[04:35] <joejaxx> or where it points to
[04:36] <joejaxx> if i do have one
[04:36] <imbrandon> it points to your LP prefered mail
[04:36] <joejaxx> imbrandon: is that automatic?
[04:36] <LaserJock> persia: the spec states "If a source package is modified relative to Debian (this can be determined automatically by examining the version number), its Maintainer field should be updated either as above, or with a more appropriate Ubuntu contact if one exists."
[04:36] <imbrandon> joejaxx: semi automatic, run once or twice a week by elmo
[04:37] <joejaxx> oh ok
[04:37] <persia> LaserJock: Right.  "relative to Debian".
[04:37] <LaserJock> so clearly an Ubuntu native package doesn't fall under that
[04:37] <imbrandon> LaserJock: -0ubuntu1 means not in debian but will/could be someday, still relitice
[04:37] <imbrandon> relitive
[04:37] <persia> The argument would be that all our Ubuntu-unique packages are numbered incorrectly, but that's a different issue.
[04:37] <LaserJock> imbrandon: right, but you don't have to have "ubuntu" in the version
[04:37] <joejaxx> uh oh i hope pbuilder does not error out :\
[04:37] <persia> LaserJock: Right.
[04:38] <LaserJock> our versioning is messed up a lot of times
[04:38] <imbrandon> LaserJock: sure , the archive wont accept a 1.0-0 versioned package, thats against policy too
[04:38] <LaserJock> imbrandon: no, but I have native packages that have no "ubuntu"
[04:38] <StevenK> imbrandon: Sure it does, 1.0-0 is valid
[04:38] <imbrandon> StevenK: valid for dpkg , not according to the package guide though
[04:39] <LaserJock> there's nothing that policy that states that a package originating in Ubuntu must have "ubuntu" in the version
[04:39] <imbrandon> LaserJock: true, but the Maintainer spec should imho cover ubuntu native packages too
[04:39] <imbrandon> since they are native someone in ubuntu must maintain them
[04:40] <imbrandon> if "ubuntu" is in the version or not
[04:40] <joejaxx> so just put motu as the maintainer and me as original and that is it right ? :)
[04:40] <persia> imbrandon: Someone needs to maintain them.  If the maintainer is MOTU, we prefer XSBC-O-M, but it's not a policy requirement.
[04:40] <imbrandon> persia: right
[04:40] <imbrandon> joejaxx: correct
[04:41] <imbrandon> joejaxx: whats your LP id ?
[04:41] <joejaxx> lp id?
[04:41] <imbrandon> lp user name
[04:41] <joejaxx> joejaxx
[04:43] <joejaxx> great pbuilder create did not fail
[04:43] <RAOF> /topic
[04:43] <RAOF> Um... right.
[04:44] <RAOF> Happy new year, MOTU :)
[04:44] <imbrandon> joejaxx: check your @@fluxbuntu.org email, i just sent a test message to your @ubuntu.com addy
[04:45] <joejaxx> nope
[04:45] <joejaxx> i did not receive it
[04:45] <imbrandon> give it a few minutes, my @{k}ubuntu.{org,com} email is normaly slow
[04:45] <joejaxx> oh ok
[04:46] <imbrandon> i dident get a bounce , so it should go "somewhere"
[04:47] <joejaxx> up there it is
[04:47] <imbrandon> there you go :)
[04:47] <joejaxx> :)
[04:47] <imbrandon> apparently it works , heh
[04:48] <imbrandon> iirc you have to request if you want something other than @ubuntu.com , e.g. @kubuntu.org or @xubuntu.org
[04:48] <imbrandon> but elmo is normaly happy to accomidate
[04:49] <joejaxx> oh ok :)
[04:52] <imbrandon> ugh, my dad ( hardcore windows guy ) just sent me a link to Freespire
[04:52] <imbrandon> asking "have i seen this yet"
[04:52]  * imbrandon faints
[04:52]  * Hobbsee steals all imbrandon's smokes, then
[04:52] <imbrandon> i guess some linux is better than no linux though
[04:53] <imbrandon> Hobbsee: hehe i made sure they were all gone before new years
[04:53] <imbrandon> just so i wouldent be "tempted"
[04:53] <imbrandon> leaste now if i give up i have to goto the store , no one else in the house smokes
[05:03]  * imbrandon just not realized that sse3 in /proc/cpuinfo == pni
[05:03] <imbrandon> s/not/now
[05:05] <joejaxx> :)
[05:56] <joejaxx> anyone have a link to the repository rules for debian?
[05:56] <persia> joejaxx: What do you mean by "repository rules"?
[05:57] <joejaxx> as in section migration
[05:57] <joejaxx> experimental -> unstable -> testing
[05:57] <joejaxx> etc
[05:57]  * StevenK tries to debug rails not working by strace'ing apache
[05:57] <imbrandon> exirmential -> unstable is manual iirc, no automaitc at all
[05:58] <persia> Ah.  experimental -> unstable is manual, by maintainer action.  unstable -> testing depends on urgency and the presence of new bugs.
[05:58] <imbrandon> unstable --> testing , no new RC bugs and 10 days old iirc
[05:58] <persia> StevenK: Consider using a different front-end, and only using apache as a proxy server.  Rails is known to act oddly with Apache.
[05:58] <RAOF> imbrandon: That matches my observations.
[05:59] <joejaxx> imbrandon: persia yeah but i was wondering if that was posted somewhere
[05:59] <joejaxx> :D
[05:59] <StevenK> persia: I am, though
[05:59]  * joejaxx is building cryptofs
[06:00] <joejaxx> :P
[06:00] <persia> StevenK: Ah.  I never thought stracing the proxy server would be more informative than watching tcp traffic, but perhaps it's just me.  I suspect your routes.
[06:00]  * joejaxx wishes there were more stenographic filesystems :(
[06:01]  * RAOF wonders why joejaxx is interested in stenographic filesystems.
[06:01] <joejaxx> all the current ones lack development and/or are for 2.{2,4}
[06:01] <StevenK> persia: Mongrel works if I connect to it directly
[06:01] <joejaxx> RAOF: :)
[06:02] <persia> StevenK: Ah.  So it's not actually one of the many ways in which Rails doesn't work :)
[06:02] <RAOF> joejaxx: I mean; why stenographic?
[06:02] <StevenK> persia: I have a rewrite rule to throw stuff to the cluster of mongrels, too.
[06:03] <StevenK> persia: It seems Apache is picking dispatch.cgi on it's own
[06:03] <imbrandon> joejaxx: you need to check the Britnet docs probably
[06:03] <imbrandon> joejaxx:
[06:03] <imbrandon> Britney starts considering packages after 10, 5 or 2 days, depending on how
[06:03] <imbrandon> urgent the uploads since the last testing migration are. A package needs to
[06:03] <imbrandon> be in sync on all architectures, and also be less buggy than the package
[06:03] <imbrandon> currently in testing. Also, they must not break another package in testing.
[06:03] <imbrandon> Britney is a python script, mixed with c-code, and available at
[06:03] <imbrandon> http://ftp-master.debian.org/testing/update_out_code/
[06:03] <persia> joejaxx: What's the point?  You'd need a massive library of known clean data to make it worthwhile.  Stenography is interesting because it's hidden, so stenography against single files is easier to hide than stenography against a collection (although I suppose you could download lots of kiddieporn, and nobody would bother digging up your secret stuff while complaining about it)
[06:05] <joejaxx>  RAOF haha sorry i spelled it wrong
[06:05] <persia> StevenK: Very odd.  I always used mod_proxy (but may now be able to safely forget about Rails again).
[06:05] <joejaxx> steganographic
[06:05] <joejaxx> sorry there bag typo
[06:05] <joejaxx> :P
[06:05] <joejaxx> sjdfsljdfslkd
[06:06] <joejaxx> bad*
[06:06] <StevenK> persia: I've set up a Proxy balancer, and have a bunch of rewrite rules
[06:06]  * persia fails completely at being sufficiently pedantic
[06:06] <joejaxx> grr want my thinklight back :(
[06:06] <joejaxx> imbrandon: thanks
[06:06] <persia> StevenK: And it still reaches dispatch.cgi?  Odd.  Some people use pound to avoid some of that.
[06:07] <StevenK> Impressive. Now I get 403
[06:07] <joejaxx> RAOF: i do not want a shorthand filesystem :P
[06:07] <joejaxx> LOL
[06:09] <RAOF> joejaxx: Soft! :P.  Real men keep their binary files in shorthand.
[06:09]  * imbrandon thinks everyone should just use fat16
[06:10] <joejaxx> persia: because i am interested in all things security/crypto{graphic,analytic}
[06:11] <joejaxx> RAOF: lol
[06:11] <joejaxx> imbrandon: bah :P fat12
[06:11] <persia> joejaxx: Sure.  There's a place for stegonography, but I just can't see the point of a filesystem interface.
[06:11] <joejaxx> :P :)
[06:21] <imbrandon> whats /proc/kmsg ? kernel messages ?
[06:42] <joejaxx> i wish we had a experimental target for the repos :(
[06:42] <joejaxx> :P
[06:45] <persia> joejaxx: PPA
[06:46] <Hobbsee> persia: no, ubuntu-only
[06:47] <persia> Hobbsee: How do you mean?  Is not a PPA a place where one can upload ubuntu-targeted packages for review and testing prior to application to the development target?
[06:47] <Hobbsee> persia: was thinking of wanting to build against debian experimental
[06:48] <persia> Ah.  Right.
[06:53] <persia> Does build-depending on sun-java6-jdk work now, or will that cause a FTBFS on the buildds (like it does for my local sbuild)?
[06:54] <imbrandon> i havent seen or heard either way
[06:54] <Fujitsu> persia: If the following fixes it, it will work on the buildds:
[06:54] <imbrandon> id imagine its the same as local though if your upto date
[06:54] <Fujitsu> echo "buildd shared/accepted-sun-dlj-v1-1 boolean true" | debconf-set-selections
[06:55] <Fujitsu> (that's from .bash_history in the buildd chroot)
[06:55] <persia> Fujitsu: Thanks.
[06:56] <imbrandon> Fujitsu: so it works? or you have to add that to the rules ?
[06:56] <Fujitsu> imbrandon: Anything checking that debconf key will work.
[06:56] <imbrandon> cool
[06:57] <imbrandon> bout time hehe
[06:57]  * persia wonders if it makes sense applying that in the schroot source partition
[07:22]  * persia grumbles about NEW packages from debian that wouldn't pass REVU
[07:24] <Fujitsu> persia: eg?
[07:24] <persia> Fujitsu: I'm just looking at whitedune now, but notice that a lot of the NEW packages we pull from Debian pre-DIF generate lintian warnings or informational messages.
[07:28] <StevenK> Hmph
[07:28]  * StevenK grumbles about Apache/Mongrel
[07:29]  * persia suspects pound was invented to get around the bug exposed by that combination
[07:29] <Fujitsu> StevenK: What's not working? I have such a setup on a server around here somewhere.
[07:38] <StevenK> Fujitsu: Stuff that is supposed to be served by Apache such as (stylesheets/) is returning 403
[07:39] <Fujitsu> Missing a chmod o+x somewhere?
[07:40] <StevenK> Not that I can see.
[07:45] <XiXaQ> I'd like to make a request for django docs to be packaged and made available trough the repositories. How do I do that?
[07:45] <imbrandon> XiXaQ: if your not willing to do the packaging yourself just file a needs-pacakging bug
[07:46] <XiXaQ> in launchpad?
[07:46] <imbrandon> yes
[07:46] <persia> XiXaQ: Are the docs in the django source package, and just not in the django binary package, or are they a separate upstream release?
[07:46] <XiXaQ> it's available though a subversion repository, is all I know.
[07:47] <imbrandon> ...
[07:57] <StevenK> Grah, more proxy tom-foolery
[08:24] <persia> mruiz: Just for future note: it's better to drop config.sub and config.guess changes from your debdiff when presenting for review.
[08:27] <minghua> persia: Should we fix it so that config.{sub,guess} changes are not included in .diff.gz?
[08:27] <minghua> (On a second though, it won't help if the previous version is already changing those two files...)
[08:28] <persia> minghua: No.  We should fix the packages so that they fall into the two safe categories: manual updates of config.{sub,guess} (thanks for the }), or if automated, not automating in the clean rule.  debian/rules clean should never make a package less clean.
[08:30] <minghua> persia: But if it's automated, you still need to delete them in clean target, no?  (That's what I mean by "fix it".)
[08:32] <persia> minghua: No need to delete if they will be overridden.  If upstream provides some junk, it's just inflation of diff.gz.  Doesn't affect build-twice-in-a-row either.
[08:33]  * minghua is still not sure what persia means, but decides to drop the topic.
[08:33]  * persia has seen packages that patch these files in debian/patches, and then override them later in debian/rules, which is just bad.  Best to leave them alone if being copied.
[08:34] <persia> minghua: I like the behaviour of debdiff to include all changes to the package.  I don't want to "fix" that.  I personally believe that copying config.{sub,guess} should not happen in the clean rule, as it makes the package less clean.  If it happens in another rule, there is no need to clean up afterwards, as the contents are ignored at build-time.
[08:36] <minghua> persia: "... as the contents (of config.{sub,guess}) are ignored at (source package's) build-time", you mean?
[08:37] <persia> minghua: Right.  Therefore it passes the build-twice-in-a-row test.
[08:38] <huats> morning everyone
[08:38] <huats> :)
[08:38]  * persia notes that it doesn't pass the clean-is-clean test, as `debian/rules clean` doesn't reset the package to the original state, but personally believes build-twice-in-a-row and clean-doesn't-make-it-less-clean are more important tests.
[08:40]  * minghua just deletes config.{guess,sub} in clean target, and since deleting files are not supported when building source package, the .diff.gz won't have anything to do with config.{sub,guess}.
[08:40] <persia> minghua: Don't you end up with a reversion patch in diff.gz?
[08:40] <Iuli> G'morning, huats.
[08:41] <minghua> persia: No.
[08:42] <minghua> persia: dpkg-buildpackage/dpkg-source tell me something along the line of "deleting config.guess can not be reflected in the source package, ignoring this change".
[08:43] <persia> minghua: In that case, deleting in clean: seems sane to me.  Thanks for the demonstration (I've just been looking at the scim source).  I still think copying in clean is wrong (which is what generates the noise in debdiffs).
[08:45] <minghua> persia: I agree with you that copying stuff in clean target is wrong.  And debian-devel list (http://thread.gmane.org/gmane.linux.debian.devel.general/122686) seems to agree, too.
[08:46] <persia> Excellent.  I always like to see others agreeing with me :)
[08:53] <minghua> Ugh.  Why are those digg people keeping submitting some hardy theme proposals as news to their frontpage?
[08:54] <persia> DarkSun88: Best to include a short summary as to why any given update deserves a DIF exception when submitting a merge or sync request.
[08:57] <imbrandon> hrm is there a class browser or soemthing for python
[08:57] <imbrandon> Fujitsu: ^
[08:58] <imbrandon> like if i want to see the methods fro apt_pkg without reading the source
[08:58] <imbrandon> from python-apt
[08:59] <RAOF> imbrandon: import apt_pkg ; help('apt_pkg')
[08:59] <imbrandon> hrm ok
[08:59] <RAOF> You can conceivably do something more funky, but that should get you all the classes and whatever documentation they have.
[08:59] <minghua> "pydoc apt_pkg" is probably easier to type?
[09:00] <rzr> persia: thx for updating the bug
[09:00] <RAOF> minghua: Oh, cool :).  Thanks.
[09:00] <imbrandon> ahh perfect , thnaks minghua
[09:00] <imbrandon> err thanks
[09:01] <minghua> RAOF: I didn't know "help()", thank you for that. :-)
[09:01] <RAOF> Fair trade :)
[09:01] <RAOF> I suppose this is a difference in coding practice.  I invariably do may python learning in a python shell.
[09:02] <RAOF> s/may/my/
[09:02] <persia> rzr: You're the person responsible for whitedune?  Please fix all the lintian warnings and informational messages.
[09:03] <rzr> sure
[09:03] <RAOF> minghua: Just for some additional info, "help()" will get you an interactive-ish version.
[09:04] <persia> rzr: Thanks.  If you're quick about it, you might even get it in before the archive admins sync, which would be preferable for releasing the best package possible with hardy.
[09:04] <rzr> I hope I can do this today
[09:09] <minghua> RAOF: I don't seem to see any difference help on Debian unstable.
[09:11] <RAOF> minghua: help() in a python shell should get you into the help-shell thingy, where you can do such things as "modules" to get a lest of all the modules and stuff.
[09:13] <minghua> RAOF: Ah, you mean help() without any arguments.  I see, thanks.
[09:13] <RAOF> Oh, yeah.  That'd be a better way of putting it!
[09:21] <imbrandon> i'm JUST getting comfy with python, its takin some gettign used to :)
[09:21] <imbrandon> ( esp when my preferd lang is c# )
[09:29] <Amaranth> minghua: You can also do help(gtk.Window)
[09:30] <persia> nenolod: Why is the new libmowgli better?
[10:02] <nenolod> persia, it has a faster memory allocator
[10:03] <persia> nenolod: OK.  How many of the rdepends break if it gets updated?
[10:03] <nenolod> persia, which audacious can transparently take advantage of at runtime (it uses the same API as the old one)
[10:03] <nenolod> persia, zero
[10:03] <persia> nenolod: OK.  Might be worth mentioning these things in your DIF exception request :)
[10:04] <nenolod> probably. i apologise for that. ;)
[10:04] <persia> nenolod: No problem.  You're around, responsive, and have quick answers.  Let me know when the description is updated, and I'll push it.
[10:20]  * persia wonders if Rospo_Zoppo is using a new nick these days
[10:37] <nenolod> persia, done
[10:45] <persia> nenolod: Thanks.
[10:48] <persia> Does anyone know where it is documented that bumping the standards version is considered a good thing to do when making an Ubuntu change?
[10:48] <Kmos> persia: didn't saw it
[10:49] <TheMuso> No. IMO its better to leave it, unless you have a compelling reason to bump it.
[10:49]  * minghua thinks it's a bad thing.
[10:50] <minghua> You should only bump standard version if you've reviewed the package and made sure it complies the new standard.
[10:50] <persia> TheMuso: That's my thought as well.  I'm happy to see a bump from things like 2.0.1, as long as it includes all the changes, but I'm seeing quite a large number of debdiffs including an apparently untested standards bump, and wonder if correcting a document wouldn't be the best way to stop that.
[10:50] <broonie> You're probably seeing that because lintian bleats about it.
[10:50] <persia> minghua: I agree with your expansion, although I'm not sure bumping is always bad.  There's some orphaned or ubuntu-only packages that could really use a proper overhaul.
[10:51] <broonie> So people will bump the version to shut it up.
[10:51] <persia> broonie: I'd like to believe that, but I'm seeing it without other fixes to quell lintian.
[10:51] <broonie> persia: Given how trivial a version update is (even if you do do the check 99% of the time there are no changes) I suspect it's going to get done more than most updates.
[10:53] <persia> broonie: I guess.  Perhaps due to the "I can fix that issue" mentality.  Maybe it's not documented (which would be less bothersome).
[11:12] <bluekuja> good morning everyone
[11:12] <bluekuja> persia, broonie, minghua, TheMuso: :)
[11:12] <persia> welcome back bluekuja
[11:12] <bluekuja> thanks mate :)
[11:13] <bluekuja> persia, are the buildds back on working again?
[11:13] <bluekuja> e.g fixed from that chroot issue
[11:13] <persia> bluekuja: i386, amd64, lpia, and hppa are happy.  powerpc and sparc are waiting for infinity
[11:14] <bluekuja> great, I'll wait them to ask a give-back for some uploads then
[11:14] <minghua> Hello bluekuja.
[11:15] <minghua> Hmm, "waiting for infinity" doesn't sound right... :-P
[11:15] <bluekuja> ^^
[11:16] <geser> minghua: hopefully it doesn't take to long to wait for infinity :)
[11:25] <Seveas> bad, bad joke!
[11:27] <RainCT> hi
[11:27] <RainCT> how can I apply an interdiff to a directory?
[11:27] <persia> RainCT: How do you mean?
[11:28] <RainCT> persia: if I have the old source and an interdiff, how can I apply the interdiff?
[11:29] <RainCT> ah, it's just a normal patch
[11:30] <RainCT> nevermind :P
[11:30] <persia> RainCT: combinediff -z interdiff old.diff.gz | gzip --best -c - > new.diff.gz (see https://wiki.ubuntu.com/MOTU/Contributing and https://wiki.ubuntu.com/UbuntuDevelopement/Interdiff
[11:30] <persia> )
[11:30] <mpt> Yo
[11:30] <persia> Dou?
[11:31] <mpt> I have a question about <https://wiki.ubuntu.com/MOTU/TODO/Weekly>
[11:31] <persia> mpt: What's the question?
[11:31] <mpt> Why does that page exist?
[11:32] <mpt> How could Launchpad be improved to that separate wiki page isn't necessary?
[11:32] <persia> Someone thought it would help get a set of beginners tasks completed every week.
[11:32] <mpt> to -> so
[11:33] <persia> The more general answer is likely more interesting for the bugsquad, as they use that feature more agressively for the bug days.  Having a means by which a team could identify a set of bugs of interest for an event, perhaps with statistics available when the event completes would probably do it, but bdmurray would be a better requirements driver than us.
[11:34] <mpt> hmm
[11:35] <mpt> I wonder if mass bug tagging would suffice for that
[11:35] <persia> Specifically about https://wiki.ubuntu.com/MOTU/TODO/Weekly, launchpad does a pretty good job with tags: we tend to use "bitesize" and "packaging" to create dynamic lists that are similar to that, but more advertisement results in more contributors pushing more solutions, so we like to have things in lots of places.
[11:35] <persia> Maybe, but it misses the green/orange feature.
[11:35] <Fujitsu> Those lists are already produced by searching by tag.
[11:35] <persia> (and filtering)
[11:36] <Fujitsu> Ah, by absence of patch it appears, true.
[11:37] <persia> dholbach is still on vacation, but he tends to try to make those lists contain interesting things for new people to do, and updates it manually weekly.
[11:38] <mpt> Ah, what's the green and orange for?
[11:38] <mpt> I don't see a key anywhere
[11:39] <geser> mpt: the key should be in the source of the page
[11:39] <persia> mpt: key means someone made a patch, or otherwise found a solution.  orange means it needs attention.  The key is actually on the bug day pages (and yes, that's probably a bug)
[11:39] <mpt> geser, heh
[11:39] <Fujitsu> persia: s/key/green/?
[11:39] <mpt> so it is
[11:40] <persia> Fujitsu: Yes.  Thank you.
[11:51] <effie_jayx> morning all
[11:52] <Hobbsee> evening!
[11:53] <mpt> Thanks for your explanations persia
[11:53] <Hobbsee> heya mpt
[11:53] <mpt> hiya Hobbsee
[11:53] <effie_jayx> Hobbsee,  sorry ... for being selfish and not consider alltime zones...
[11:54] <Hobbsee> effie_jayx: no problem :)
[11:54]  * Fujitsu sentences effie_jayx to a year living in $OBSCURE_TIMEZONE.
[11:55] <persia> mpt: Happy to share :)  Please do contact bdmurray and dholbach about that, as I'm sure they'd have some good descriptions of how to meet that feature requirement.
[11:55]  * effie_jayx python's he's way out of Fujitsu's curse...
[11:56] <persia> effie_jayx: Don't knock it until you've tried it.  UTC-11 or UTC+13 is a fairly nice part of the world.
[11:57] <geser> persia: is there also a decent internet connection?
[11:58] <persia> geser: As far as I know, decent net connections only stretch from UTC+9 to UTC-8.  There's OK bandwidth as early as UTC+11, but it gets expensive due to annoying monopoly practices.
[11:58] <nenolod> i only bump standards-version when i know my packages are in line with that version ;p
[11:59]  * Fujitsu shoots Telstra.
[11:59] <persia> nenolod: That's the right way to do it (although one hopes that is soon after the version bump was announced).
[12:00] <effie_jayx> persia,  have I knocked on something?
[12:00]  * persia thought there might be a spot of decent connectivity in UTC-11, but finds that modems are still the normal means there.
[12:01] <persia> effie_jayx: Sorry.  Idiom.  "knocking something" -> "knocking it down" -> indicating something is bad (you called it a curse).
[12:02]  * effie_jayx steps back into the $OBSCURE_TIMEZONE
[12:02]  * persia doesn't think UTC-4 qualifies as obscure
[12:03]  * mpt gets homesick thinking of UTC+13
[12:04]  * Hobbsee occupies UTC+32
[12:04] <Fujitsu> mpt: Ah, so the rumours are true.
[12:04] <minghua> Really?  I thought Hobbsee was in UTC/3 or something.
[12:04] <geser> Hobbsee: the whole timezone? either is it really small or ...
[12:04] <Hobbsee> of course not.
[12:04] <Fujitsu> UTC/3. Sounds interesting.
[12:05] <persia> mpt: UTC+13?  Summer time, or really that far east?
[12:06] <effie_jayx> persia,  I have been trying to read on ugrade paths ... the documentation I found seems missing.. https://wiki.ubuntu.com/Testing/UpgradePaths
[12:06] <StevenK> persia: New Zealand
[12:07] <persia> effie_jayx: Yep.  It's a work in progress.  Basically, testing Dapper -> Hardy and Gutsy -> Hardy for all packages.
[12:07] <persia> StevenK: only half the year (but it answers my question).
[12:08] <effie_jayx> I'm guessing dapper hardy should be fun... with all the python 2.4 to 2.5 changes
[12:09] <persia> effie_jayx: We're expecting some things to break, especially for Dapper -> Hardy.  These might need extra hints in control, or restoration of handlers in the maintainer scripts.  Python is a good example of something that could cause confusion.
[12:09] <effie_jayx> well i look forward to helping there
[12:10]  * effie_jayx considers FTBFS
[12:11] <mruiz> hi all. Happy New Year !
[12:12] <geser> Hi mruiz
[12:13] <persia> Vorian: Please unassign yourself when submitting bugs to the UUS queue.
[12:15]  * Fujitsu finds that part of the process to be silly, but necessary due to Launchpad's lack of a good workflow for sponsorship.
[12:15]  * persia agrees with Fujitsu
[12:16]  * Hobbsee ponders s/for sponsorship//

[12:16] <Fujitsu> We shouldn't really have to hack sponsorship processing into the existing task.
[12:17] <Hobbsee> it really shouldn't be necessary to have to handcode the URL to actually find things, most of the time.
[12:17] <Fujitsu> That too.
[12:17] <Fujitsu> Hopefully Soyuz will sort itself out soon :)
[12:18] <Fujitsu> But then there's the larger problem of latency on a scale that only Launchpad seems to be able to manage. That makes proper navigation impractical.
[12:22] <persia> LucidFox: Are you planning any further updates to bug #179655, or is it ready now?
[12:22] <ubotu> Launchpad bug 179655 in kde4-style-qtcurve "Upgrade qtcurve to 0.55.1" [Undecided,Confirmed] https://launchpad.net/bugs/179655
[12:23] <LucidFox> persia> It's ready
[12:23] <persia> LucidFox: OK.  Which of them get applied?  The last one?  All of them?
[12:23] <LucidFox> All of them.
[12:23] <LucidFox> There are three interdiffs, each for its own package.
[12:23] <persia> Right.  Is it nearly the same source?
[12:24] <LucidFox> They're not necessary to apply all at once
[12:24] <LucidFox> No, upstream distributes each one as a separate tarball
[12:24] <LucidFox> but all with the same version number
[12:25] <persia> Right.  I'm not sure if that is good or not, but I suppose it's life.  Also, what's the problem with uscan & kde-look.org?
[12:25] <LucidFox> kde-look.org uses HTTP redirects
[12:25] <LucidFox> with nondescriptive URLs
[12:26] <persia> Ah.  Nice of them.  Thanks for the details.
[12:28] <persia> LucidFox: Separately, consider applying for =ubuntu-bugcontrol to be able to set Importance.
[12:29] <zoli2k> Hi, I want to build a small ubuntu derivate for a USB key. How can I download the base system?
[12:30] <persia> zoli2k: You probably want to start with the alternate CD, and this isn't really the right place to ask (but I don't know which is the right place).
[12:31] <LucidFox> persia> How do I do that?
[12:31] <zoli2k> persia: I know that there is a script in the ubuntu repo to download the basic binaries but I can't remember for its name.
[12:31] <LucidFox> wait, never mind
[12:32] <mpt> Fujitsu, is that sponsorship problem reported?
[12:32] <zoli2k> I want to add in chroot some packeges and pack it by squashfs.
[12:32] <persia> LucidFox: It also gets you access to the crash bugs, which might be handy, as you tend to fix some of them :)
[12:33] <persia> zoli2k: You might mean debootstrap, but you might mean something else.  I'm not the best person to ask about that.
[12:33] <Hobbsee> mpt: can't we get the bugs fixed that are there now, before adding mroe?
[12:33] <Fujitsu> mpt: Quite possibly not. As it's a significant change, I'd probably try to elicit a response from some UI person first. This seems to have worked.
[12:34] <zoli2k> persia, that's it! thanks
[12:35] <persia> mpt: We have a workaround in place, and it would likely take 6 months for us to change workflows.  Let's wait until this starts to have scaling issues before looking to the next solution (as we'll likely want to keep that for a couple years).
[12:35] <mpt> Fujitsu, you know how to push my buttons
[12:36] <mpt> persia, if it's reported now it's unlikely to be fixed in the next six months, but we may get a head start on designing a better solution
[12:36] <Hobbsee> s/6 months/12 months/

[12:36] <zul> morning
[12:36] <mpt> The fix for bug B can be designed while the fix for bug A is being coded
[12:37] <mpt> So, Fujitsu, tell me about sponsorship
[12:37] <mpt> Is there a summary of the process I can read?
[12:37] <persia> mpt: OK.  If we're looking at something to be implemented in the 6-12 month timeframe, I'd hope our volume would reach the point that we're ready to properly review an interface.  Right now we're only at around 10-20 sponsorships a day, which isn't impossible.
[12:37] <mpt> Pretend I know nothing about what a sponsorship is (because I don't)
[12:38] <persia> !sponsorship
[12:38] <ubotu> Sorry, I don't know anything about sponsorship - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[12:38] <persia> Grumble.
[12:38] <Hobbsee> what's it supposed to be?
[12:39] <persia> https://wiki.ubuntu.com/SponsorshipProcess and https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue might be interesting pages to read.
[12:39] <persia> Hobbsee: I'm not sure yet :P
[12:39] <minghua> !sponsor
[12:39] <ubotu> Sorry, I don't know anything about sponsor - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[12:39] <persia> Actually, I don't thin it comes up enough to need a factoid.
[12:39] <persia> s/thin/think/
[12:39] <minghua> ubotu spends too much time remembering things like pointy sticks. :-(
[12:40]  * Fujitsu reappears.
[12:40] <Hobbsee> persia: the DB is big enough.  a few more wont hurt
[12:43] <mpt> thanks persia
[12:48] <mpt> eek
[12:48] <mpt> "If the patch needs work ... Set the Status to 'Incomplete'"
[12:48] <Hobbsee> what eek?
[12:48] <Hobbsee> heh
[12:49] <Hobbsee> yes, welcome to that rotten janitor.
[12:49] <Hobbsee> so, you get 60 days to fix the patch, or else :)
[12:50] <persia> mpt: It kills rotten patches.  They have been found wanting, so aren't very useful, usually.  If an active contributor submitted it, they are subscribed to the bug, and tend to act.
[12:50]  * Hobbsee would have thoguht that was a fiarly standard use of incomplete, actually
[12:50] <persia> LucidFox: I get output like http://paste.ubuntu.com/3198/ from all the qtcurve packages.  Any suggestions?
[12:50] <Fujitsu> mpt: See how this process is nasty, now?
[12:50] <mpt> persia, but is the bug report devoted to the patch? Or is it about a bug that might get fixed by this patch, or might get fixed by another?
[12:51] <Hobbsee> mpt: usually it's devoted to the patch, but if there's a bug already filed against the issue, it's on that bug.
[12:51] <persia> mpt: Good point.  Current set tends to be about half & half dedicated.
[12:52] <mpt> If the bug report is dedicated to the patch, having it expire is fine
[12:53] <mpt> But if a real bug report gets expired merely because someone made an abortive attempt to fix it, that's not so good
[12:53] <persia> mpt: Arguably, as the issue that was being patched likely still exists (even if reported by the patch submitter)
[12:53] <DaveMorris> which reviewer is it thats emmet.hikory@
[12:53] <DaveMorris> persia: ?
[12:53]  * persia notes that the process hasn't been updated since the introduction of the janitor
[12:53] <persia> DaveMorris: Yes.
[12:54]  * Fujitsu notes that Janitor hopefully won't be properly turned on for a while yeet.
[12:54] <mpt> persia, perhaps it should be a needs-work tag
[12:54] <persia> mpt: Doesn't show in the subscribed queue listing, so not very useful.
[12:54] <Hobbsee> ew, tags.
[12:54] <Fujitsu> I don't like the idea of using tags to store status data, really.
[12:54] <mpt> ergh
[12:55] <DaveMorris> you reviewed my libserial package and mentioned the manpages.  I've looked for how to fix them since you 1st brought it to my attention at the start of Dec, but I don't know how to fix them.  What should I do about it?
[12:55]  * Fujitsu likes the idea of having customisable bug listings.
[12:55] <Hobbsee> can we do tags when reporting the bug now?
[12:55] <LucidFox> persia> Looking into it
[12:55] <Fujitsu> Hobbsee: On the advanced form one can.
[12:55] <Hobbsee> and whenever we're adding comments, etc?
[12:55] <Fujitsu> Hobbsee: No.
[12:55] <Hobbsee> damn.
[12:55] <persia> Hobbsee: On the "complicated" bug form (which isn't, really)
[12:55] <Hobbsee> then tags are not suitable.
[12:55] <Hobbsee> (for my use, anyway, which tries to avoid YALPLP as much as possible)
[12:56] <mpt> Fujitsu, there is no field in Launchpad for storing this particular data. That's what tags are for, storing data that doesn't have its own field.
[12:56] <mpt> "this particular datum", I mean
[12:56] <persia> mpt: yes, but tags aren't visible except on the bug page, which makes them useless when tracking lists.
[12:57] <persia> Further, it's not easy to find a set of tagged patches subscribed to a team (although subscription isn't necessarily the best means of requesting sponsorship).
[12:58] <mpt> Yes, we don't have flexible advanced search
[12:59] <mpt> http://bugs.launchpad.net/ubuntu/?tag:needs-work+subscribed:ubuntu-motu
[12:59] <mpt> One day that URL will work :-)
[12:59]  * Fujitsu dreams of a `Request sponsorship' button which will add a new sort-of-task to the bug and notify the nominated sponsorship team.
[12:59] <persia> mpt: Even with flexible advanced search, the tags don't show in the default list, which makes it hard to know if information is being presented when tags are used (and there isn't an ~ubuntu-motu, it's just ~motu)
[12:59] <Hobbsee> Fujitsu: would be ubuntu-specific, and have to differentiate between main and universe.  won't happen.
[13:00] <Fujitsu> Hobbsee: Do other projects not have a sponsorship workflow?
[13:00] <Hobbsee> Fujitsu: actually, would diversify more than that, with the new seed-based stuff.
[13:00] <Hobbsee> Fujitsu: sure, but theirs would be different to yours
[13:00] <persia> Hobbsee: Not necessarily.  Could be "request sponsor for this task", and use the task definition to determine the sponsoring team.
[13:00] <Hobbsee> and likely not more than 1.
[13:01] <Hobbsee> persia: oh, "ubuntu main"  "ubuntu-universe", and a dropdown list of all the other sponsorship groups, from all projects.
[13:01] <persia> That way people submitting patches to other projects (when they don't have commit access) could use the same feature.
[13:01] <persia> Hobbsee: No.  Detect based on the project against which the task is created.  main/universe is maybe a little tricky, but otherwise it's not hard at all.
[13:01] <Hobbsee> of course, the less braindead solution would be to create groups of sponsorships per-project, and let the user select from them.
[13:01] <Fujitsu> persia: LP already differentiates main/universe for nominations.
[13:01] <mpt> persia, would "it['s] hard to know if information is being presented when tags are used" be fixed if bug 28697 was fixed? Or are you referring to something else?
[13:02] <ubotu> Launchpad bug 28697 in malone "Bug lists should show current search filter" [Medium,Confirmed] https://launchpad.net/bugs/28697
[13:02] <Hobbsee> Fujitsu: only because multiple teams exist, and they use subscribed.
[13:03] <Hobbsee> persia: hmm.  yes, i think that's what i said second.  more or less
[13:03] <LucidFox> persia> Works for me.
[13:03] <persia> mpt: No.  I look at https://launchpad.net/~ubuntu-universe-sponsors/+bugs every day.  The "Status" field tells me which bugs deserve attention, and which bugs should be ignored (or deferred, and the subscriber chastened).  I don't see tags.
[13:04] <LucidFox> Meaning, I followed exactly the procedures on the interdiff wiki page - combinediff followed by filterdiff
[13:04] <LucidFox> and was able to do get-orig-source
[13:04] <persia> LucidFox: I created the new diff.gz files, extracted debian/, set execute permissions for debian/rules and debian/scan-version, and make the call.  Did I miss anything?
[13:04] <LucidFox> no, you didn't
[13:04] <Hobbsee> what's rharding's new nick, now?
[13:04]  * persia tries again
[13:04] <Hobbsee> seenserv is being unhelpful
[13:04] <Hobbsee> hmmm
[13:05] <LucidFox> persia> maybe you used the wrong file for combinediff and/or filterdiff? It seems to me that somehow, the new files contain both the old and new revisions concatenated
[13:05] <Hobbsee> mpt: how do i file a bug against a package in someone's ppa?
[13:06] <Hobbsee> rick_h_: ping
[13:06] <mpt> Hobbsee, ooooooh
[13:06] <mpt> excellent question
[13:06] <RAOF> Hobbsee: What, you can do that?
[13:06] <Hobbsee> RAOF: i don't think so
[13:06] <RAOF> Yeah, neither do I.
[13:06] <Hobbsee> RAOF: but i've found the right irc nick, so i can whinge that way
[13:06] <Fujitsu> Hobbsee: You file it in Ubuntu.
[13:06] <RAOF> Hobbsee: That'd be about his Do packaging?
[13:06] <Hobbsee> mpt: the previous case has been "email one of the ubuntu ML's, due to YALPB, which has now been solved"
[13:06] <Hobbsee> RAOF: yes
[13:06] <persia> LucidFox: The "full interdiff" contains all of the old diff.gz and all of the new diff.gz.  I've become convinced that only the new diff.gz is interesting, but was overridden in the last MOTU Meeting.  Blame Hobbsee
[13:06] <Hobbsee> Fujitsu: i hate you.
[13:06] <Fujitsu> Particularly on SourcePackageNames that have never existed in Ubuntu.
[13:07] <mpt> Fujitsu, where it should be marked invalid because the bug isn't present in the Ubuntu package
[13:07] <rick_h_> Hobbsee: pong
[13:07] <Hobbsee> Fujitsu: but yes, i agree with you
[13:07] <Hobbsee> rick_h_: please update your gnome-do for the new mono :)
[13:07] <RAOF> Oh, it's broken?
[13:07] <joejaxx> Hobbsee: lol
[13:07] <Hobbsee> Fujitsu: actually, you bitch about the fact that ti hasnt' already been fixed, on an ubuntu mailing list.
[13:08] <Fujitsu> Ah yes, that too.
[13:08] <LucidFox> here are the commands that I executed:
[13:08] <LucidFox> combinediff -z gtk2-engines-qtcurve_0.55.1-0ubuntu1.interdiff gtk2-engines-qtcurve_0.52.3-1.diff.gz > test.diff
[13:08] <LucidFox> filterdiff -i 'gtk2-engines-qtcurve-0.55.1/debian/*' test.diff | patch -p0
[13:08] <rick_h_> Hobbsee: ah, hardy update the mono? Sorry been afk over the holidays
[13:08] <Hobbsee> rick_h_: yup.  looks like it's just gone uninstallable in the last few hours, so you're fine
[13:08] <persia> LucidFox: I don't know how I got where I did with all three packages.  It's working now (and I don't know why).  Thanks for the extra testing.
[13:09]  * Hobbsee wishes we could file bugs on people.
[13:09] <joejaxx> Hobbsee: Lol
[13:09] <Hobbsee> or maybe smite them with big pointy sticks, via launchpad.
[13:09] <joejaxx> LOL
[13:09] <Hobbsee> unfortunately, i'ts not a great idea to smite the kernel people.
[13:10]  * persia appreciates packaging that allows combinediff -z kde-style-qtcurve_0.55.1-0ubuntu1.interdiff kde-style-qtcurve_0.52.3-1.diff.gz | patch -p0
[13:10] <joejaxx> Hobbsee: you could file regression bug reports
[13:10] <joejaxx> persia: :)
[13:10] <Hobbsee> joejaxx: yeah, true
[13:10] <joejaxx> i had another packaging question but i forgot what it was now
[13:10] <joejaxx> oh
[13:11] <Hobbsee> persia: i just don't see the point of all this newfangled behavoir, when i'm not convinced it's easier than the old lot
[13:11] <joejaxx> wait nevermind just forgot again
[13:11] <zul> Hobbsee: yeah because kernel people have longer and pointerey sticks than you do
[13:11] <Hobbsee> zul: no, because i appreciate having a working kernel.  if it builds in the first place.
[13:11] <mpt> Ah, Pointerey. Just south of Monterey.
[13:12] <joejaxx> mpt: :P
[13:12] <persia> Hobbsee: interdiff is twice as big as diff.gz.  When you suggested it to me in Dapper, I agreed it was a good way to show differences.  Now I'm having second thoughts, as I think it's easier to sponsor a diff.gz.
[13:13] <Hobbsee> i suggested it?
[13:13] <joejaxx> persia: did you always have the nick persia ?
[13:13] <joejaxx> :D
[13:13] <persia> Hobbsee: Yep.  When I wanted to update libjsw :)
[13:14] <persia> joejaxx: Only since 1987
[13:14] <Hobbsee> ahh
[13:15] <Hobbsee> persia: dapper was a long time ago
[13:15] <persia> Hobbsee: Yes.  That's why I thought it was time for a change.
[13:16] <joejaxx> persia: :P
[13:16] <Hobbsee> :)
[13:18]  * persia summons sdrik
[13:30] <DarkSun88> Hi all
[13:31] <ChrisGibbs> Gday all as well
[13:33] <Vorian> aloha
[13:34] <Kmos> Hobbsee: so.. start it
[13:34]  * broonie grumbles at #74135
[13:34] <Hobbsee> Kmos: so, why did you upload something you knew to be broken?
[13:34] <Hobbsee> https://wiki.ubuntu.com/MOTU/Council/KmosReport
[13:34] <Hobbsee> requested others test a broken patch in #ubuntu-motu and #ubuntu-devel prior to self testing. Agreed to test and try to fix. Further discussion on #ubuntu-motu indicated an upload to PPA with the expectation that the build would fail. The build didn't fail, but luckily the buildd crashing bug was not exposed. Channel discussion requesting justification for this was incomplete, due to external scheduling. Further investigation and testing
[13:34] <Hobbsee> planned. See #ubuntu-motu log for 28th December 13:00 - 14:00 UTC for full transcript of further discussion.
[13:34] <Hobbsee> for reference ^
[13:34] <Kmos> :)
[13:35] <persia> bug #74135
[13:35] <ubotu> Launchpad bug 74135 in runit "runsvdir does not use upstart" [Medium,Fix released] https://launchpad.net/bugs/74135
[13:35] <Kmos> "but luckily the buildd crashing bug was not exposed", I know the same bug wasn't exposed, but I tested it first in pbuilder..
[13:36] <Kmos> and I test it in PPA, but chroot or pbuilder isn't the same.. for some FTBFS for example, it builds fine in pbuilder and not in PPA or buildd
[13:36] <Kmos> *because
[13:36] <Kmos> for example.. libpam-ruby is FTBFS and it builds fine here in my pbuilder (updated)
[13:37] <Kmos> it's a problem specific with buildd options, so that's I sometimes upload to PPA
[13:37] <Fujitsu> Kmos: Right, but buildd FTBFSes are basically a superset of pbuilder FTBFSes, except in some very odd circumstances.
[13:37] <Fujitsu> (like this one)
[13:37] <Kmos> Fujitsu: i've a lot of them here..
[13:37] <Kmos> libpod-constants-perl
[13:37] <Kmos> another one
[13:38] <Fujitsu> Kmos: That fails in pbuilder, but works on the Launchpad buildds?
[13:38] <Kmos> Fujitsu: nop.. works in pbuilder, and fails in launchpad buildds
[13:38] <persia> Kmos: You might try downloading a buildd chroot, and using it with sbuild.  it won't match perfectly, but it will be closer to the buildds.
[13:38] <Fujitsu> Hence a superset.
[13:38] <mpt> persia, Fujitsu, ok, reported bug 179857
[13:38] <ubotu> Launchpad bug 179857 in malone "Package sponsorships involve awkward bugtracker machinations" [Undecided,New] https://launchpad.net/bugs/179857
[13:38] <persia> mpt: Thanks.
[13:39] <mpt> Fujitsu, now, tell me what you meant by "But then there's the larger problem of latency on a scale that only Launchpad seems to be able to manage. That makes proper navigation impractical."
[13:39] <persia> mpt: Likely deserves a spec though, no?
[13:39] <Kmos> persia: that will help.. i need to download the debootstrap for hardy ? or there is any other easy way to do it ?
[13:40] <persia> Kmos: You could download the buildd chroot tarball (and no, I don't know where they live, but I do know they have LP librarian URLs)
[13:40] <mpt> persia, probably. I reported it as a bug partly because without a pre-arranged schedule, blueprints can get forgotten
[13:40] <mpt> and partly because that's what I'm used to doing
[13:40] <mpt> and partly because bugs have tags (e.g. "motu") while blueprints don't
[13:40] <persia> mpt: Agreed (and that's another bug, but perhaps not one for now or soon).
[13:41]  * minghua contributes to the KmosReport page.
[13:41] <Kmos> persia: I'll find it and install it here..
[13:42] <Fujitsu> mpt: https://launchpad.net/ubuntu takes a good 15 seconds to load here. Listing of any number of objects (particularly builds) increases this waiting time somewhat. One cannot efficiently use clickish navigation with such slow page loads. Some resort to composing bug search URLs manually. It's all just too darn slow.
[13:42] <Fujitsu> As well as Soyuz navigation being odd.
[13:43] <mpt> Okay, so slowness is a variety of separate issues
[13:43] <mpt> getting better hardware
[13:43] <mpt> upgrading the DB software
[13:43] <mpt> moving from HTTPS to HTTP for some pages
[13:43] <mpt> having pages with less unimportant stuff on them
[13:44] <Fujitsu> I find it slightly iffy that /ubuntu takes 1.2 seconds of DB query time.
[13:44] <Fujitsu> Although I guess it has to trawl through bug lists.
[13:44] <mpt> and gradually ratcheting down our expectation for how long a page generation should take (once we've finished fixing the actual timeout errors!)
[13:45] <Fujitsu> (is it deliberate that those query stats are at the bottom of each page?)
[13:45] <mpt> erm
[13:45] <mpt> Where do you see that?
[13:45] <Fujitsu> Bottom of the source of every page.
[13:45] <Fujitsu> Ah, might just be edge.
[13:46] <mpt> Oh, an HTML comment
[13:46] <Fujitsu> Yes, sorry.
[13:46] <mpt> That's almost certainly deliberate
[13:46] <Hobbsee> Fujitsu: only 15?  wow.
[13:46] <Fujitsu> Hobbsee: That's only for /ubuntu.
[13:46]  * Hobbsee is used to the old 50+ second load times
[13:47] <Hobbsee> 29 to fully load.  yay, launchpad.
[13:49] <Kmos> https://wiki.ubuntu.com/DebootstrapChroot
[13:49] <Kmos> !deboostrap
[13:49] <ubotu> Sorry, I don't know anything about deboostrap - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[13:49] <Kmos> :(
[13:49] <Fujitsu> The DB server must be under fairly light load today. A listing of 1000 builds takes a mere 13 seconds of query time, whilst it was taking >=22 over the holidays.
[13:49] <Hobbsee> !debootstrap
[13:49] <ubotu> debootstrap is used to create a !Debian or Ubuntu base system from scratch, without requiring the availability of !dpkg or !APT. It does this by downloading !.deb files from a mirror site, and carefully unpacking them into a directory you can eventually !chroot into.
[13:49] <Hobbsee> Kmos: spell thing correctly.  it helps.
[13:49] <Hobbsee> !no debootstrap is used to create a !Debian or Ubuntu base system from scratch, without requiring the availability of !dpkg or !APT. It does this by downloading !.deb files from a mirror site, and carefully unpacking them into a directory you can eventually !chroot into.  See https://wiki.ubuntu.com/DebootstrapChroot for more information
[13:49] <ubotu> I'll remember that Hobbsee
[13:50] <Kmos> :-)
[14:24] <DktrKranz> joejaxx, any news for bug 160257 ?
[14:24] <ubotu> Launchpad bug 160257 in apt-rpm "Please merge apt-rpm 0.5.15lorg3.2-3 from Debian Unstable" [Wishlist,Incomplete] https://launchpad.net/bugs/160257
[14:36] <bddebian> Heya gang
[14:39] <persia> LucidFox: Please close your bugs in your changelogs (I'll do it this time)
[14:40] <bddebian> persia!!
[14:40] <persia> bddebian!!
[14:40] <persia> bddebian: Do you happen to have some free time, a fair bit of bandwidth, and a desire to try a new game?
[14:41] <bddebian> persia: Possibly.  I'm almost done with breaking newpki-client with wx2.6 ;-)
[14:42] <persia> bddebian: Is it worth it?  xca is in REVU, which would be enough to drop newpli-client (but if you're making progress, I'm impressed: that one stumped me).
[14:42] <bddebian> Well I've had help :-)
[14:43] <bddebian> persia: What game?
[14:44] <bddebian> persia: Oh, btw, are you going to request syncs of quesoglc and warzone2100 for Ubuntu? :)
[14:44] <effie_jayx> I have been reading https://wiki.ubuntu.com/PackagingGuide/Howtos/DebianWatch
[14:44] <effie_jayx> I have a couple of questions
[14:44] <persia> bddebian: urbanterror (on REVU).  Just repackaged, supposedly addressing all my review points.  You keep claiming there are no good games, but this one has lots of data, so it might be good.
[14:44] <effie_jayx> when I download current version its the one in gutsy?
[14:44] <bddebian> Ah yeah, I saw that and I've been meaning to check it out
[14:45] <persia> Regarding syncs, I'm just finishing killing the UUS holiday bloat, and am planning a review of mdt next.  Feel free to jump ahead if you want, but I do plan to hit it soon.
[14:46] <effie_jayx> another this is what determines the version number in the begining of the watch file
[14:46] <persia> effie_jayx: It downloads whichever version matches the environment you download in.  I tend to run apt-get source in my chroots to get the right targets.
[14:46] <persia> effie_jayx: The watch file version should be 3.  It is the syntax version for the watch file.
[14:47] <effie_jayx> ok that sorts that out...
[14:47] <persia> If you're downloading with a watch file, it should grab the newest version from upstream.
[14:47] <bddebian> persia: OK, I'll try to get off my lazy ass eventually :)
[14:47] <effie_jayx> ok
[14:47] <effie_jayx> persia,  the one in debian/copyright?
[14:47] <persia> bddebian: lazy?  I'm seeing lots of good changes - certainly more than I've been producing lately.
[14:48] <persia> effie_jayx: huh?  I don't understand your reference to debian/copyright.
[14:49] <effie_jayx> persia,  there I should find where the new versio should be found...
[14:50] <persia> effie_jayx: Right.  debian/copyright should give you information to construct your watch file.  Feel free to add "It was downloaded from $URL" in debian/copyright if it is missing when updating the package.
[14:51]  * broonie wonders what a watch file for "the author handed me a disk in the pub" would be like. :)
[14:52] <persia> hellboy195: Feel free to ask me also if you have any questions about the gmsh merge.
[14:52] <hellboy195> persia: yeah thank you but bluekuja is mentoring me
[14:53] <persia> broonie: Were it my package, there'd be a public mirror with the tar.gz
[14:53] <persia> hellboy195: Please continue with that, it's just many of the changes were mine, so I'm offering extra help if you need.
[14:53] <hellboy195> persia: ok, I'll keep that in mind. Thank you :)
[14:54] <effie_jayx> persia,  you mentioned chroot to download current source. what are you using? pbuilder?
[14:55] <bluekuja> hellboy195, yeah, feel free to ask to persia as well
[14:55] <persia> effie_jayx: I have a collection of LVM partitions with individual chroots.  I use sbuild against snapshots of these.
[14:55] <broonie> persia: doesn't seem much point if upstream isn't doing it
[14:55] <bluekuja> hellboy195, he did the big part of those changes
[14:56] <persia> broonie: I'd consider it a public service, and expect to get the new upstream in a pub, and publish it.  Were I lucky, someone else would feel like updating the package (but I might not be so lucky).
[14:57] <broonie> What advantage does that have over the distro archive?
[14:57] <bddebian> persia: I meant lazy wrt Ubuntu :'-(
[14:58] <persia> broonie: Raphael doesn't file a bug that the package doesn't have a watch file :)
[14:58] <persia> bddebian: D-G is Ubuntu :P
[14:58] <bddebian> heh :)
[14:59] <persia> bddebian: Plus, your efforts on the wx2.4 front help massively with my personal goal of not shipping for hardy.
[15:01] <bddebian> Well jugglemaster doesn't help if it doesn't run :-(
[15:03] <persia> bddebian: Sorry.  I got distracted by REVU & UUS.  I'll get back to that soon.
[15:04] <bddebian> persia: No worries
[15:08] <bddebian> persia: Ah, looks like boswars FINALLY got uploaded too
[15:10] <persia> bddebian: I thought I saw a note about a missing .changes for that.  Did you ever investigate the other strategus scenarios?
[15:11] <bddebian> No, not yet :-(
[15:13] <persia> OK.  We can kill bos, but perhaps not strategus yet.  6 weeks left :)
[15:14] <persia> But perhaps after wormux...
[15:16]  * persia thwacks bddebian for not suggesting mercurial or rcs
[15:17] <bddebian> heh
[15:21] <bddebian> I'm sorry but this "team" maintenance stuff I find to be bullshit
[15:23] <persia> bddebian: Depends on the team.  I like MOTU :P
[15:23] <bddebian> Aye, I meant in Debian
[15:23] <bddebian> In Ubuntu you don't have the "find a DD to upload" constraint for the most part
[15:24] <persia> bddebian: Yes you do.  Sometimes the sponsors queue lags as much as a month, and sometimes REVU lags for three or four.  The six-month cycle helps with that, but...
[15:25] <bddebian> Aye but REVU is NEW, most of these aren't
[15:25] <bddebian> And that's a resource constraint, not a "I"m better than you" constraint
[15:26] <persia> bddebian: Depends on how one defines resource.  Willing sponsors are rare anywhere.
[15:27] <persia> RainCT: Do we really want to keep elfsh around?
[15:27] <persia> Or to put that another way, do we want to support it for five years?
[15:28] <bddebian> persia: If you say so :)
[15:29] <persia> bddebian: present company excluded (thank you) :)
[15:30] <\sh> moins and happy new year everyone :)
[15:31] <persia> happy new year \sh
[15:31] <persia> RainCT: Also, I can't find a changelog for 0.123-3 :(
[15:34]  * persia gives up on the bug for now...
[15:34] <bddebian> persia: Well that's just it, because I've been doing all this games-team shit and some qa stuff I haven't been sponsoring shit in Ubuntu :-(
[15:35] <persia> bddebian: No problem.  You've been doing the stuff on my list, and I've been doing the stuff on yours :)
[15:36] <bddebian> :)
[15:39] <DaveMorris> persia: I've updated my libserial package (http://revu.tauware.de/details.py?package=libserial) but I don't know what to do about the man page problem
[15:41] <persia> DaveMorris: The changelogs are dropped due to an annoyance with CDBS.  You need to define DEB_INSTALL_CHANGELOGS_ALL.  I'm less certain about the manpages, looking now...
[15:44] <DaveMorris> persia: I have the changelog in my packages, as changelog.gz
[15:44] <persia> DaveMorris: Really?  I didn't when I built the last version.  Hmm...
[15:44]  * DaveMorris is looking in libserial0
[15:45] <DaveMorris> the -dev package doesn't have 1 as it symblinks the dir to libserial0
[15:45] <persia> Which would be correct.  Rebuilding the latest, and rechecking.
[15:48] <persia> DaveMorris: My hardy sbuild doesn't include ./usr/share/doc/libserial0/changelog.gz in the generated package.  For the manpages, I'm guessing there might be a doxygen bug.
[15:49] <DaveMorris> persia: oh, my mistake I'm building on gutsy
[15:49] <DaveMorris> regression bug
[15:49] <persia> DaveMorris: That can lead to all sorts of confusions :)
[15:50] <DaveMorris> yeah sorry.  I'll fix it then, what did you say the fix was?  DEB_INSTALL_CHANGELOGS_ALL := Changelog
[15:50] <persia> DaveMorris: something like that ought work.  A better fix would be for someone to migrate the changelog suppression code out of CDBS and into the packages with huge changelogs causing issues for the CDs, but that won't happen soon.
[15:51]  * Hobbsee looks for a wrong build deps bug.
[15:51] <Hobbsee> or an unmetdeps
[15:51] <persia> Hobbsee: Do you want a bug, or something to fix?
[15:52] <Hobbsee> persia: i want something to fix, that i can mentor someone on.
[15:52] <Hobbsee> (it needs to be relatively simple)
[15:52] <Hobbsee> build-dep change would be great
[15:52] <persia> Hobbsee: http://qa.ubuntuwire.com/debcheck/ has all the unmetdeps, updated frequently.
[15:52] <Hobbsee> hum, NBS might work, then
[15:53] <persia> http://people.ubuntuwire.com/~dktrkranz/NBS/ might be interesting for that (still WIP)
[15:53]  * awen_ wonders if the "problem" with cdbs/changelog is an ubuntu-only? seems to work fine when building for sid
[15:53] <persia> awen_: Yes.
[15:54] <awen_> thx
[15:54] <persia> Hobbsee: specifically the 5 packages listed near the top are good candidates for someone to play.
[15:54] <Hobbsee> okay, found one
[15:58] <DktrKranz> persia, I found Debian Maintainers very interested in that, a good coordination with them could lead to easier fixes.
[15:58] <persia> DaveMorris: Looking at your source and the Doxygen manual, I think you get a pass on that.  Be sure to leave a comment explaining why lexgrog can't handle your manpages so that the next reviewer doesn't reject for it.
[15:59] <DaveMorris> ok thanks
[15:59] <persia> DktrKranz: Debian transitions are traditionally painful.  Scripts to make status tracking easier would definitely make people happy.  Purely selfishly, gettting that finished so we can publish on qa.ubuntuwire.com would be a nice way to help be sure we fix them all before release.
[16:03]  * persia is stuck, and encourages others to try to tackle some of the bugs in the sponsor queue.
[16:03] <effie_jayx> when doing a watch file. if it is a ubuntu-specific package the process is different from https://wiki.ubuntu.com/PackagingGuide/Howtos/DebianWatch...
[16:03]  * \sh works on wine 0.9.52...starting over from last years try
[16:04] <effie_jayx> well I gotta split
[16:04] <effie_jayx> today I did lots of ground reading
[16:04] <effie_jayx> this afternood I might get some more done...
[16:05] <effie_jayx> thanks persia ...
[16:08] <DktrKranz> persia, of course. Main structure is already present, it needs some graphical improvements (and someone who can provide suggestions on how to do them) and a couple of bugfixes (e.g.  libflickrnet, recently promoted but listed in universe)
[16:09] <persia> DktrKranz: I can whine about it if you like, but I'm not capable of fixing the issues I'd raise.
[16:10] <DktrKranz> I'm after your previous suggestions, some of them are trivial, others will require more work (and others additional love from canonical, but that's another point).
[16:11] <DktrKranz> anyway, I'm trying to address everyone's needs to have something really useful for everyone
[16:12] <RainCT> persia: About elfsh, I don't even know what it is... :P.
[16:12] <persia> DktrKranz: Thanks.  Let me know when you want another critique.  Regarding serving everyone, if you find a way to collect it straight from the Packages.gz or a local archive, that would be a win.
[16:13] <persia> RainCT: OK.  You seem to be the handler for bug #92949, and based on your statement that it would be removed from Debian soon, I wonder if it is useful for hardy.
[16:13] <ubotu> Launchpad bug 92949 in elfsh "[can-not-install] file overwrite error" [Medium,Confirmed] https://launchpad.net/bugs/92949
[16:16] <DktrKranz> persia, it shouldn't be too hard to collect a list of NBS from {Sources,Packages}.gz, but I fear this method will miss packages who FTBFS. I really don't know if rene is smart enough to address this point, though.
[16:17] <persia> DktrKranz: Ah.  Right.  Maybe the binaries can be dug out of Sources.gz?
[16:19] <RainCT> persia: I really don't know... :(
[16:20] <RainCT> persia: (the maintainer's statement about a replacement is here, btw: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449356)
[16:20] <ubotu> Debian bug 449356 in elfsh "elfsh: should this package be orphaned?" [Serious,Open]
[16:20] <persia> RainCT: OK.  Someone else might upload the patch, or investigate and ask for package removal.  I'm about done for the day now, but I'll look harder next time.
[16:20] <DktrKranz> persia, Sources.gz will list every binary, even if a given package would FTBFS, but I think ports haven't Sources.gz, nor on archive.u.c nor on ports.u.c
[16:22] <persia> DktrKranz: Maybe I don't understand.  I thought that packages shouldn't be considered for NBS due to FTBFS.  Also, there's only one Sources.gz, which applies for all architectures (or should).
[16:23] <persia> RainCT: Hmmm..  Sounds to me like elfsh should be removed, and a needs-packaging bug created for eresi, linked to the ITP.
[16:26] <DktrKranz> persia, yes. I confused a couple of things (probably due to new-year party madness). I'll work on it now.
[16:26] <persia> DktrKranz: heh.  Good luck.
[16:28] <LucidFox> persia> Thanks for uploading!
[16:29] <LucidFox> Looks like chroot problems still persist on sparc and powerpc.
[16:29] <persia> LucidFox: Next time, please be more careful about closing the bugs and targeting the development repos :)
[16:30] <LucidFox> All right.
[16:33] <Vorian> I have a watchfile syntax question :)
[16:34] <Vorian> if the watch should check this : http://releases.vendor.org/current.version.number/software-(.*).tar.gz
[16:34] <awen_> LucidFox: my builds failed on sparc and powerpc, so looks like the chroot problem hasn't been fixed on those two platforms
[16:34] <Vorian> what is the syntax for the current.version.number ?
[16:35] <RainCT> Vorian: (?:.*) should do it
[16:35]  * Vorian checks
[16:37]  * RainCT wonders what awen_ is talking about, as he also got two sparc and powerpc build failures
[16:37] <hellboy195> persia: ping
[16:38] <awen_> RainCT: don't we agree that powerpc and sparc builds all fail with a chroot problem atm?
[16:38] <geser> RainCT: sparc and powerpc have a broken chroot and are waiting for infinity to fix them
[16:38]  * persia dislikes virtual table tennis, but tends to be answer questions
[16:39] <man-di> Vorian: http://svn.debian.org/viewsvn/pkg-java/trunk/eclipse/debian/watch?rev=5243&view=markup might be an example for you
[16:39] <Vorian> ah!
[16:39] <Vorian> R-
[16:40] <hellboy195> persia: ^^ sry. I have to edit the gmsh.install. can I use the old 2ubuntu2 one? but there the first 2 lines with (bin/gmsh /usr/bin
[16:40] <hellboy195> doc/gmsh.1 /usr/share/man/man1 ) were deleted
[16:44] <RainCT> persia: needs-packaging bug filled; I'll look later how to request a deletion. Thanks.
[16:44] <persia> hellboy195: At a quick glance, it looks like those are now included by passing --mandir=\$${prefix}/share/man in debian/rules, but I could be mistaken.  Try the new one, and see if the manpages get included in the binary package.
[16:45] <hellboy195> persia: k, thx
[16:45] <persia> RainCT: It's just a bug with a Rationale.  Subscribe the sponsors as usual.
[16:48] <hellboy195> persia: another question. In the 2ubuntu2 package there is a .xpm for the menu which is missing in debian but isn't it written in the docs that there should also be a png?
[16:48] <persia> hellboy195: Generally a .png looks nicer, but the debian/menu format only works with .xpm, so the .xpm is the minimum requirement.  I tend to be lazy when creating icons, and only do the .xpm.  If you have a nicer .png, please add it.
[16:50] <hellboy195> persia: well in the docs is written to convert the xpm to a .png ^^ but your THE packaging geek so I take the .smp :P
[16:50] <hellboy195> *xmp
[16:50] <hellboy195> *xpm xD
[16:50] <persia> hellboy195: Which doc?  Where?
[16:51] <persia> hellboy195: Also, I'm not the best at packaging: I tend to do small fixes.  I have a lot of opinions, but that's different :)
[16:52] <hellboy195> persia: https://wiki.ubuntu.com/PackagingGuide/SupplementaryFiles  <-- but you're right a missread something with .icons and .xpms ...  well I'm as long here to see that you are a great MOTU ;)
[16:52] <RainCT> persia: Oh, ok. Done (bug #179889).
[16:52] <ubotu> Launchpad bug 179889 in elfsh "Please remove elfsh from Hardy" [Undecided,New] https://launchpad.net/bugs/179889
[16:53] <persia> RainCT: Great.  When 179888 gets done, we can push 179889 to the archive admins.  Thanks.
[16:54] <DaveMorris> Can someone please review my package - http://revu.tauware.de/details.py?package=libserial
[16:55] <geser> RainCT: I guess it hasn't any rdepends or rbuilddepends but could you check and state it in the bug?
[16:55] <RainCT> geser: I checked :). forgot to say it
[16:56] <hellboy195> persia: At the moment I'm writing my changelog entry. is the version number now 2.0.8-2ubuntu3 ?
[16:57] <persia> hellboy195: No.  It would be 2.0.8-4ubuntu1 (the first Ubuntu revision to the fourth Debian revision of 2.0.8)
[16:57] <Vorian> RainCT: that does not seem to work, I tried a couple of variations in addition
[16:58] <RainCT> geser: (well, I checked for rdepends, don't know how to look for r build dependencies)
[16:58] <persia> RainCT: grep-dctrl can help.
[17:00] <hellboy195> persia: ah right :) thx
[17:00] <RainCT> Vorian: it seems releases.vendor.org isn't browseable
[17:00] <persia> RainCT: http://people.ubuntu.com/~pitti/scripts/checkrdepends may also be useful (I haven't tried it, I'm just finding URLs)
[17:00] <Vorian> RainCT: I was giving an example
[17:01] <Vorian> vendor as in software vendor
[17:01] <Vorian> :)
[17:01] <awen_> persia: as a follow-up to Bug 145574 ... the libapache2-mod-rpaf currently in hardy is build from another source than libapache-mod-rpaf
[17:01] <ubotu> Launchpad bug 145574 in libapache-mod-rpaf "[UNMETDEPS] libapache-mod-rpaf - removal request" [Wishlist,Confirmed] https://launchpad.net/bugs/145574
[17:01] <geser> do I remember correctly that package in the clean rule in debian/rules should be listed in build-depends instead of build-depends-indep?
[17:01] <persia> awen_: There are two sources that both build libapache2-mod-rpaf?
[17:01] <persia> geser: Yes.
[17:01] <Vorian> RainCT: I am trying to include watchfiles from http://qa.ubuntuwire.com/uehs/no_watch.php
[17:01] <awen_> persia: yes... libapache-mod-rpaf_0.5-2.1 and libapache2-mod-rpaf_0.5-3
[17:02] <Vorian> first on the list is CCSM
[17:02] <persia> awen_: That's just plain wrong.  Thanks for the correction: I'll go update my comment.
[17:02] <RainCT> Vorian: ah ok. what is the real URL then?
[17:02] <RainCT> :P
[17:02] <geser> RainCT: http://paste.ubuntu.com/3207/ that's the script I found once on the internet and use to check for rbuilddepends
[17:02] <Vorian> RainCT: http://releases.compiz-fusion.org/
[17:03] <awen_> persia: you're welcome... but looks like it's someone in debian that messed it up :)
[17:03] <Vorian> geser: sorry for the mistake yesterday
[17:05] <persia> awen_: Submitted. There are over 100 bugs in the archive-admin queue just now, so it might be a while...
[17:06] <RainCT> geser, persia: thanks :)
[17:06] <awen_> persia: thanks... that's a lot; lucily there is still some time before hardy is arriving ;)
[17:07] <RainCT> Vorian: perhaps you could use the page were the download URL is then
[17:10] <Vorian> RainCT: http://releases.compiz-fusion.org/0.6.0/ccsm-0.6.0.tar.gz the bolded version number is where I am having trouble
[17:10] <Vorian> oops which is
[17:11] <Vorian> http://releases.compiz-fusion.org/0.6.0/ccsm-0.6.0.tar.gz
[17:11] <Vorian> pfft
[17:11] <RainCT> Vorian: IRC doesn't support formatting afaik
[17:11] <Vorian> kk
[17:12] <ion_> It supports bold, inverse and underline. There are also mIRC colors, which are evil.
[17:12] <Vorian> yeah, not if the chan is mode +c
[17:12] <persia> Depends on the client.  bold, inverse, and underline can be disabled.  overstrike can also be enabled through unicode.
[17:14]  * RainCT thinks plain text is sooo nice :P
[17:14] <Vorian> how about this
[17:14] <Vorian> http://releases.compiz-fusion.org/*THIS PART* -> 0.6.0 <- *END* /ccsm-0.6.0.tar.gz
[17:14] <Vorian> :P
[17:15] <persia> Vorian: [\d\.*]
[17:15]  * Vorian checks :)
[17:16] <persia> Err... [\d\.]*
[17:17] <Vorian> hmm
[17:17] <Vorian> *should* it look like this?
[17:17] <Vorian> http://releases.compiz-fusion.org/[\d\.]*/ccsm-(.*).tar.gz
[17:18] <bddebian> ccsm-[\d.]+\.tar\.gz
[17:19] <persia> hellboy195: Your new debian/menu doesn't include the icon.  How did you generate this debdiff?
[17:19] <geser> persia: doesn't lose . it's special meaning inside []?
[17:19] <persia> geser: I don't believe so (at least in perl).  I've seen strange behaviour with missing \ insider
[17:19] <persia> s/r$//
[17:20] <hellboy195> persia: hmm it should. debdiff gmsh_2.0.8-4ubuntu1.dsc gmsh_2.0.8-4.dsc > gmsh_2.0.8-4ubuntu1.debdiff
[17:20] <DktrKranz> geser, that way, "." characted can be in every position, without it only at the end.
[17:20] <ion_> . shouldn’t be escaped inside []
[17:20] <persia> hellboy195: Ah.  You want it the other way.  debdiff old new > review-submission.
[17:20] <hellboy195> persia: so. new debdiff?
[17:21] <persia> hellboy195: Yep.  Also, looks like you've a formatting confusion in the changelog.  Might want to look a the current debdiff, and see if you can make it smaller.
[17:22] <persia> hellboy195: Further, the changelog isn't in version order :(
[17:22] <hellboy195> persia: ah. sry. I'll fix that
[17:23] <persia> hellboy195: No worries.  Thanks for helping :)
[17:23] <hellboy195> persia: np, in the far and now more far away future I also want to be a motu :)
[17:29] <hellboy195> persia: any advice for me how I can make the debdiff smaller?
[17:31] <persia> hellboy195: Visually inspect the debdiff.  If you see any lines that you didn't think you changed with a + and - (but apparently the same), hunt for whitespace differences, and patch the new candidate to more closely match the source.
[17:32] <hellboy195> persia: I'll make a try. :)
[17:33] <hellboy195> persia: are there also a lot of whitespace differences besides the changelog?
[17:35] <persia> hellboy195: I didn't see any, but I only took a quick glance.
[17:35] <hellboy195> persia: ok. I'll look at it carefully and when I'm ready I upload it and ping you
[17:36] <persia> hellboy195: You'd do better to subscribe the sponsors, as I'll likely be asleep (I'm rarely around at this hour).
[17:37] <hellboy195> persia: k, normally bluekuja should also be back. Good Night and thank you very much for you help :)
[17:37] <persia> hellboy195: Thanks for persisting my changes :)
[17:40] <persia> Anyone know Wouter Stomp's nick?
[18:04] <chazco> Can anyone explain the correct way to have a .deb create a mimetype, which will work in both Kubuntu and Gnome?
[18:04]  * broonie wonders about the stream of "removed in Ubuntu" messages for apache stuff hitting the Debian BTS.
[18:05] <persia> broonie: Could you pass an example?
[18:06] <broonie> Â429102
[18:06] <persia> Debian bug #429102
[18:06] <ubotu> Debian bug 429102 in libapache-mod-auth-useragent "please update/request removal of your package" [Serious,Open] http://bugs.debian.org/429102
[18:07] <tuxmaniac> new year greetings all!
[18:07] <broonie> It looks entirely sensible to remove the packages, it's mostly just the subject line that raised an eyebrow
[18:07] <persia> awen_: You might want to be more focused on Debian when reporting things to the BTS.  Especially so before the archive-admins have made a determination.
[18:08] <persia> broonie: The more so when it's not yet the case.
[18:08] <tuxmaniac> can someone please check whether the uploaded revu package http://revu.tauware.de/details.py?package=alliance builds on hardy pbuilder? It seems to be ok with a clean gutsy pbuilder base.
[18:08] <nxvl_work> Ng: ping
[18:08] <tuxmaniac> its a new package and I would like to push it into hardy if I can still do that
[18:08] <persia> tuxmaniac: consider updating your pbuilder (or creating a second chroot tarball)
[18:09] <persia> And yes, FeatureFreeze for hardy isn't for another six weeks, so there's about four more weeks to get through REVU.
[18:09] <tuxmaniac> persia, I would have done that. But I am from a remote part of the world, who are cursed with speeds not more than 256 Kbps
[18:10] <persia> tuxmaniac: Ah.  That makes it harder then :(
[18:10] <tuxmaniac> so it would take pretty long time to do that. thats why thought I will get some help from people around
[18:10] <broonie> .oO(...when I were a lad...)Oo.
[18:10] <tuxmaniac> persia, not that I am not willing to do that. But.. you know the frustration of sudo pbuilder create on such low speed internet
[18:10] <tuxmaniac> :D
[18:10] <persia> broonie: In those days, you didn't reload significant portions of the archive for build-depends repeatedly daily :P
[18:11] <persia> tuxmaniac: I can imagine
[18:11] <awen_> persia: i thought the ubuntu-sponsors had the final word there... but if that isn't the case, I see your point
[18:11] <DktrKranz> tuxmaniac, it's not a problem for me? how long does it takes?
[18:11] <SnackPack> so what's the best way to post a merge for sponsorship?
[18:12] <broonie> persia: Well, actually I just did the downloads via cron while I was asleep/out and didn't really care how long theyt took :P
[18:12] <tuxmaniac> DktrKranz, it downloads around 300 MB of stuff on a gutsy pbuilder base
[18:12] <persia> SnackPack: Prep a merge.  subscribe the sponsors.  See https://wiki.ubuntu.com/MOTU/Contributing
[18:12] <broonie> Providing it was less than ~7 hours
[18:12] <DktrKranz> tuxmaniac, I'll do right now. I'll point you to the log
[18:12]  * tuxmaniac wishes DktrKranz a very happy new year 2008 :D
[18:13] <DktrKranz> :)
[18:13] <persia> broonie: For pbuilder?  Way back, I used local builds so I didn't have to redownload the build-depends every time (but you may be different).
[18:13] <SnackPack> persia: thanks... kinda hard to keep up with all these wiki links.  :P
[18:13] <chazco> Can anyone explain the correct way to have a .deb create a mimetype, which will work in both Kubuntu and Gnome?
[18:13] <persia> DktrKranz: I've a build in progress...
[18:14] <DktrKranz> persia, ah... I'm going to stop it
[18:14] <broonie> persia: pbuilder has always cached the downloaded archives (it was me who got dancer to fix the fact that it used to only do that when the full download completed).
[18:14] <SnackPack> persia: just to verify, submit a debdiff from the *debian* version?
[18:14]  * persia bows to broonie's experience
[18:15] <broonie> which was a tiny bit annoying when your connection kept on flaking out every 'once in a while' and you were trying to build the initial chroot.
[18:15] <geser> tuxmaniac: why does it need gcc-4.1 for building? doesn't it build with gcc-4.2?
[18:15] <persia> SnackPack: generally for a merge, that's best.  Sometimes the tarballs differ, and you have to submit against ubuntu.  Be sure to mention if it's not debian against which you pull the debdiff.
[18:15] <tuxmaniac> geser, i will check
[18:16] <SnackPack> persia: ok, them my diff will just carry previous -ubuntu changes against the latest debian version
[18:16]  * SnackPack prepares
[18:17] <persia> SnackPack: Also, we've passed DIF, so be sure to mention why the package should be merged - it should provide a good feature, or fix a useful bug, or otherwise improve integration in hardy.
[18:17] <tuxmaniac> geser, it should build with gcc4.2 as well
[18:18] <persia> tuxmaniac: How long should this take?
[18:18] <SnackPack> persia: this is a random package I chose from merges.ubuntu.com
[18:19] <tuxmaniac> persia, its big! downlaods quite a lot of stuff. it contains the entire tool set for chip design engineers
[18:19] <persia> SnackPack: That's likely not ideal then.  We've passed the point where random package updates are helpful.
[18:20] <geser> tuxmaniac: while you update the build-dependencies please also replace the tetex packages with texlive. btw: please also fix the version: it should be -0ubuntu1
[18:20] <tuxmaniac> geser, hmm. points noted
[18:20] <SnackPack> hmm
[18:23] <SnackPack> I did one of the beginners tasks, the dontzap one
[18:23] <SnackPack> how do I know for sure wether or not to even attempt to fix a bug?
[18:24] <geser> tuxmaniac: it would be nice if you could also fix the many "implicit declarations" during build (especially the incompatible ones). Perhaps upstream can help you with it.
[18:24] <persia> SnackPack: If it's a bug, it would be good to fix it.  It's just that we're not looking to pull all the new upstream versions, change to patch systems, etc. from Debian at this point, but really focus on bugs.
[18:24] <tuxmaniac> geser, I am already contacting the upstream folks with respect to that.
[18:25] <persia> tuxmaniac: build failed.
[18:25] <tuxmaniac> persia, same as what bddebian has put?
[18:25] <persia> Yep.
[18:25] <tuxmaniac> hmm.
[18:27] <SnackPack> persia: the reason I ask is I already did the dontzap bug, #90434, but it was rejected due to "If we end up using dontzap by default..."
[18:27] <SnackPack> recorded as not needing to be fixed
[18:27] <persia> bug #90434
[18:27] <ubotu> Launchpad bug 90434 in xorg-server "please enable dontzap by default" [Wishlist,Confirmed] https://launchpad.net/bugs/90434
[18:28] <persia> SnackPack: You'll find it easier to get patches for bugs against packages in universe accepted.  X is fairly critical, so the maintenance team is fairly conservative.
[18:29] <tsmithe> persia, nixternal; i've uploaded a new version of mscore which should address (most of) your problems. those that haven't been addressed (eg the xpm icon) will be fixed upstream next release. thanks.
[18:29] <persia> tsmithe: Any timeline on next upstream?  Maybe we can pull a couple things from CVS into debian/ ?
[18:30]  * SnackPack won't refer to the beginners task list anymore
[18:31] <persia> SnackPack: https://launchpad.net/ubuntu/+bugs?field.tag=bitesize or https://wiki.ubuntu.com/DesktopTeam/WeeklyTODO might be good places to try.
[18:31] <tsmithe> persia, not yet, and nothing wanting from cvs, either
[18:32] <persia> tsmithe: OK.  I likely won't get to it until Monday, but someone else might hit it first.
[18:32] <tsmithe> what things did you have in mind, persia - just the icon?
[18:33] <persia> tsmithe: From CVS?  Any of "those that haven't been addressed..." that might have been available.  If that isn't anything yet, we can always patch later.
[18:33] <persia> I just doubt a new upstream release before Feature Freeze, so think we should track to make sure it's in best shape for release.
[18:34] <geser> tuxmaniac: your package uses the default compiler (in hardy is it gcc-4.2) even if you list gcc-4.1 in build-depends
[18:34] <tsmithe> persia, i think the only thing not being addressed, having a check back on revu, was the icon
[18:34] <tuxmaniac> geser, oh
[18:34] <tsmithe> and there is an icon provided for the desktop file spec, in any case, which gnome and kde and xfce all use, so the major user base is covered
[18:35] <persia> tsmithe: fluxbox will be broken.  Everything else should be fine.
[18:35] <tuxmaniac> geser, actually it isnt my package but a package that I am dead interested in and helping the uploader sort out things with Ubuntu/Debian which he is not so familair with. I am already making some changes inthe package. Thanks a lot for your support.
[18:36]  * persia notes that powerpc & sparc should be rebuilding soon.  From now, FTBFS mails on those architectures actually mean something again
[18:36] <tsmithe> persia, is it possible to include binary files in debian/? (seeing as it is distributed as a diff..) if so, i could whip up an icon temporarily.
[18:36] <tuxmaniac> geser, please give in your valuable feedback as and when you find. it would help in the process
[18:36] <persia> tsmithe: XPM is ascii :)
[18:36] <tsmithe> oh
[18:36] <tsmithe> haha i will do that, then!
[18:48] <\sh> if someone has time ... wine 0.9.52 is ready for upload to universe http://www.sourcecode.de/~shermann/wine/0.9.52/
[19:02] <tsmithe> persia, nixternal, apachelogger; the current upload of mscore <http://revu.tauware.de/details.py?upid=1139> now has the xpm icon, with no further issues outstanding.
[19:05] <chazco> Hi... i've been told here is my best bet to ask... I'm creating a .deb which needs to set up a new mime time (application/tmd.textmaker, based on the extension .tmd). I made a .deb manually which works on Ubuntu, but not on Kubuntu... can anyone point me in the right direction for getting it to work on both from one .deb (its not going to be part of the repos... or at least not yet)
[19:07] <mruiz> persia, thanks for your upload (bug 178869). Should I request the backport to gutsy ?
[19:07] <ubotu> Launchpad bug 178869 in gnome-voice-control "[FTBFS] gnome-voice-control due to automake-1.9 build-dep" [Medium,Fix released] https://launchpad.net/bugs/178869
[19:08] <LaserJock> chazco: I'm not sure of the specific answer,  but you might try to find a KDE package that would have mime types and see how they do it
[19:09] <chazco> LaserJock - yep, i've looked at kaffeine (which creates a .kaffeine based mime-type)... i think I see how it works, but was hoping to find if there is a better all-in-one style solution
[19:09] <chazco> Gnome uses the mime xml files... but KDE seems to use an additional .desktop file
[19:11] <LaserJock> chazco: yeah, you'll probably have to do both
[19:11] <chazco> Ok... just seems like an overly complicated way of doing it... thanks :)
[19:13] <LaserJock> chazco: heh, welcome to open source :-)
[19:14] <chazco> Getting used to it :) I'm new to this so I'm not 100% sure of the accepted ways to do things
[19:15] <zul> happy new year LaserJock
[19:15] <LaserJock> same to you zul
[19:31] <Vorian> \o/
[19:31] <Vorian> found a package i could create a watch file for!
[19:40] <LaserJock> Vorian: awesome ;-)
[19:40] <Vorian> LaserJock: this is fun :)
[19:40] <Vorian> LaserJock: I should have started doing this a long time ago :)
[19:40] <Vorian> the package also needs updating it seems ....
[19:43] <mruiz> is it correct to fill a bug if a package doesn't have a watch file?
[19:43] <Vorian> mruiz: they are mostly here http://qa.ubuntuwire.com/uehs/no_watch.php
[19:45] <LaserJock> mruiz: persia's on a watch file crusade to make sure that at least all packages in Ubuntu but not in Debian have watch files
[19:45] <Ubulette> question about copyrights: if I reuse a gif from http://www.google.com/intl/en/options/, and convert it to PNG for a prism webapp, what should I say for the copyright ?
[19:46] <Vorian> \o/ it builds in hardy
[19:46] <Ubulette> is this acceptable: "prism-google-maps.png has been converted to PNG from http://www.google.com/options/icons/maps.gif and is then (c)2007 Google"
[19:46] <Ubulette> ?
[19:47] <LaserJock> Ubulette: yikes I'm not sure
[19:47] <LaserJock> I'm unsure you are allowed to use that icon
[19:48] <mruiz> Vorian, I was looking there... my question is if I need to fill a bug
[19:49] <Ubulette> LaserJock, well, the webapp will point to google maps so it's not a reuse for something else
[19:50] <LaserJock> Ubulette: right, but without a license you don't really have to right to take it
[19:51] <LaserJock> you could probably shoot google an email and ask
[20:02] <Vorian> mruiz: I would think so, in order to get a sponsor to upload it
[20:02] <mruiz> ;-)
[20:03] <Vorian> :)
[20:13] <Ubulette> LaserJock, hmm, prism already ships gmail, greader and other google icons. the prism package is triple licenced GPLv2, LGPLv2.1 and MPL 1.1. I'm not sure mozilla obtained those under a clear license either.
[20:13] <Ubulette> I could file a bug against prism to ask
[20:16] <ion_> Also the facepoop package seems to contain an icon without licensing information.
[20:54] <LaserJock> anybody having problems updating Hardy pbuilders?
[20:54] <LaserJock> I'm getting: E: Internal Error, Could not perform immediate configuration (2) on libstdc++6
[20:55] <Kmos> LaserJock: your mirror is updated ? =)
[20:55] <LaserJock> Kmos: should be fairly yes
[20:55] <slangasek> LaserJock: mvo is working on fixing an apt bug
[20:56] <LaserJock> slangasek: oh, ok
[20:56] <slangasek> says on #ubuntu-devel that the ETA is "tomorrow"
[20:56] <geser> LaserJock: apt-get update libc6 tzdata
[20:56] <man-di> LaserJock: I had the same problem today
[20:56] <geser> LaserJock: and proceed as usual
[20:56] <man-di> LaserJock: workaround was dpkg -i libstdc++6 and gcc-4.2-base manually
[20:56] <geser> LaserJock: s/update/install/
[20:57] <LaserJock> I can wait if it's gonna be fixed by "tomorrow"
[21:00] <geser> LaserJock: and how do you want to install the fixed apt?
[21:01] <LaserJock> geser: I don't know, I assume that tomorrow I can update it alright
[21:01] <LaserJock> or did it really get screwed up
[21:03] <geser> you will need to install the fixed apt first
[21:03] <LaserJock> oh really?
[21:03] <man-di> LaserJock: dpkg -i .. as I said above helps
[21:04] <geser> apt-get install libc6 tzdata helps too
[21:04] <LaserJock> right, but I assumed that the fix would "fix" it without taking manual intervention
[21:05] <geser> with the new apt this bug would get fixed but you need to have the new apt installed first
[21:05] <geser> how else do you want to benefit from the bug fix?
[21:06] <LaserJock> well, it depends on the type of bug
[21:06] <LaserJock> what I was saying was that I assumed a dist-upgrade would work to fix it when the fix is released
[21:07] <geser> the problem is that apt doesn't generate the ordering right for the current update
[21:07] <LaserJock> right
[21:07] <LaserJock> I didn't know what the problem was
[21:07] <LaserJock> so I assumed it would fix itself
[21:08] <geser> the fixed apt will get build against the libs which you try to upgrade now and fail due to an apt bug
[21:09] <geser> you will probably need to fix it manually now
[21:09] <LaserJock> right
[21:15] <cyberix> Is it guaranteed that something will some day happen to patches that are ins sponsors queu?
[21:15] <cyberix> Or should I e.g. be active in some way?
[21:16] <LaserJock> they should be mostly processed within a day or two normally
[21:18] <LaserJock> ok, well now my pbuilder is really messed up
[21:19] <geser> pbuilder login --save-after-login and upgrade it manually
[21:19] <LaserJock> man-di: all you did was ibstdc++6 and gcc-4.2-base?
[21:19] <LaserJock> geser: that's what I'm trying to do, it wants to remove like everything
[21:19] <nenolod> hi
[21:19] <man-di> LaserJock: yes, and after that a normal aptitude upgrade
[21:20] <LaserJock> hmm
[21:22] <LaserJock> I wonder if I installed the wrong version of libstdc++6 and gcc-4.2-base
[21:22] <man-di> LaserJock: I just installed the newest ones from /var/cache/apt/archives
[21:22] <LaserJock> hmm, that's what I did
[21:22] <cyberix> Something wrong with the report? -> https://bugs.launchpad.net/ubuntu/+source/pq/+bug/176645
[21:22] <ubotu> Launchpad bug 176645 in pq "improve package description" [Low,Confirmed]
[21:23] <LaserJock> man-di: now I get several: cpp-4.2: Depends: gcc-4.2-base (= 4.2.2-4ubuntu2) but 4.2.2-4ubuntu3 is installed
[21:24] <man-di> 4.2.2-4ubuntu3 is my version too
[21:24] <man-di> LaserJock: then install cpp-4.2 4.2.2-4ubuntu3 too
[21:24] <man-di> all at once
[21:24] <geser> LaserJock: I upgraded my notebook two hours ago and ran into the same problem and could fix it with apt-get install libc6 tzdata
[21:25] <man-di> geser: hm. for me apt-get wasnt able to do any install
[21:27] <LaserJock> geser: yeah, I was a bit too messed up to get apt-get to work
[21:27] <LaserJock> got it now though
[21:27] <LaserJock> just had to dpkg the whole lot of gcc stuff
[21:28] <LaserJock> cyberix: no, nothing wrong with it
[21:28] <LaserJock> although I wonder if the status is right
[21:30] <LaserJock> geser: I'll try your way on my Main pbuilder as I haven't done anything with it yet
[21:31] <geser> man-di: I had to upgrade the two packages with apt before I could update the remaining packages
[21:32] <man-di> geser: me too, just two different ones, interesting
[21:33] <LaserJock> geser: yep, that worked for me
[21:45] <`Matir> I'm looking to help out the MOTUs.  I've read the Contributing doc on the wiki but was wondering if there is a preferred way for new people to help out/get started.
[21:45] <nenolod> `Matir, make/fix packages
[21:48] <LaserJock> `Matir: well, there's so many ways it's a bit hard to give a specific answer
[21:49] <LaserJock> but generally, as nenolod say, fixing existing packages and creating new ones are common
[21:49] <`Matir> So just look at bug reports for ones that are reasonable to fix?
[21:50] <LaserJock> that's definitely a good place to start
[21:50] <LaserJock> `Matir: have a look at https://wiki.ubuntu.com/MOTU/TODO/Bugs
[21:51] <nenolod> hi LaserJock
[21:51] <`Matir> ok, thanks
[21:51] <LaserJock> hi nenolod
[21:58] <StevenK> LaserJock: PONIES!
[22:00] <LaserJock> StevenK: working on it
[22:03] <nenolod> what's the deal with ia32-libs SDL?
[22:03] <nenolod> is someone going to fix that? :P
[22:22] <SnackPack> nenolod: is there a bug report on it?
[22:56] <LaserJock> Fujitsu: around?
[23:01] <Fujitsu> LaserJock: Sorta.
[23:46] <Larose> If my package doesn't use "configure" and "configure-stamp" in debian/rules, can I remove it or should I keep it empty ?
[23:47] <LaserJock> you can remove it
[23:48] <Larose> LaserJock: ok, thanks
[23:48] <LaserJock> Larose: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules