[00:00] <mok0> directhex: this is not the right channel for OSX support  ;)
[00:01] <crimsun> superm1: yeah, it has been very fun gleaning that from the Windows INFs :-)
[00:02] <directhex> mok0, on ubuntu, of course. it's been running ubuntu since dapper
[00:03] <mok0> binarymutant: check with jmarsden, who wrote the text
[00:03] <mok0> directhex: heh
[00:03] <cyberix> How do I get something into main?
[00:04] <directhex> cyberix, is there a compelling reason for canonical to give it commercial support?
[00:04] <binarymutant> mok0, you think it should be changed to? or am I just crazy?
[00:04] <directhex> mok0, http://www2.apebox.org/wordpress/wp-content/gallery/00-single/IMG_0120.JPG
[00:05] <cyberix> directhex: ttf-mph-2b-damase would add to main the missing fonts that are required for being able to display wikipedia.org front page correctly
[00:05] <mok0> directhex: that's an Apple monitor alright
[00:05] <directhex> s/monitor/computer/
[00:05] <mok0> hehe
[00:06] <mok0> binarymutant: I think you need to check with jmarsden and ask what the meaning is
[00:06] <binarymutant> will do mok0
[00:06] <mok0> binarymutant: thx
[00:07] <stgraber> directhex: Apple computer with Microsoft keyboard and mouse running on Linux, funny mix
[00:08] <directhex> stgraber, yes! ^_^
[00:14] <james_w> universe's sponsor queue is back to being smaller than main's
[00:14] <james_w> let's try and keep it that way :-)
[00:15] <Hobbsee> good effort!
[00:15] <Hobbsee> james_w: got any specs you want to discuss at UDS?
[00:15] <james_w> not really, I'm feeling pretty un-inspired this cycle
[00:15] <james_w> apart from bzr stuff of course
[00:16] <james_w> I always enjoy joining in to random sessions though
[00:16] <Hobbsee> james_w: well, the bzr stuff should probably get added to the tracker, so it does get scheduled, and so people can subscribe to it, and get less clashes.  Please do it ASAP :)
[00:16] <james_w> Hobbsee: yeah, I should. Not sure what specs it will have yet though :-)
[00:16] <james_w> I'll work on that tomorrow, thanks for the reminder
[00:17] <james_w> Hobbsee: what specs are you proposing?
[00:17] <Hobbsee> james_w: think quickly.  You can always refine later.  ;)
[00:17] <Hobbsee> james_w: probalby one on retaining ubuntu developers, and making it easier to contribute
[00:17] <james_w> good ones, I'd like to contribute to those
[00:18]  * directhex wonders if anyone at UDS will be in a position to mention the ubuntu-archive-friendly consequences of the mono 2.0 transition currently underway
[00:19] <lifeless> what consequences?
[00:21] <directhex> lifeless, less disk consumption, mainly
[00:21] <nellery> StevenK: do you recall why libxi-dev was added to build-depends in your upload to
[00:21] <nellery> https://edge.launchpad.net/ubuntu/+source/anyremote
[00:22] <StevenK> nellery: Because it uses headers from it, I believe.
[00:23] <directhex> debian NEW permitting, anyway
[00:23] <nellery> StevenK: ok thanks a lot.
[00:24] <nellery> james_w: would ^^ answer your question to why libxi-dev was added to build-debs
[00:24] <nellery> for Bug 298496
[00:25] <StevenK> If it #include <X11/extensions/XInput.h> it requires libxi-dev
[00:27] <james_w> ./src/xemulate.c:#include <X11/Xlib.h>
[00:27] <james_w> ./src/xemulate.c:#include <X11/extensions/XTest.h>
[00:27] <james_w> they are the only X11 related includes from a quick grep
[00:29] <StevenK> And XTest includes XInput
[00:29] <StevenK> You know, headers being recursive and such? :-)
[00:30] <lifeless> StevenK: 'if it includes XTest | Xinput'
[00:30] <lifeless> :)
[00:32] <james_w> but it doesn't use any symbols from XInput from what I can see
[00:34] <mok0> Mmmm, armel builds in progress... nice
[00:35] <Hobbsee> NCommander: poke?
[00:42] <Hobbsee> right.  Spec added.
[00:42] <james_w> \sh: please check open sponsor requests before uploading a package.
[00:45] <james_w> thanks Hobbsee
[00:45] <Hobbsee> james_w: you're welcome
[00:54] <handschuh> hmm when did the encoding of the diff files @ revu changed to text/plain ?
[01:05]  * jdong finishes boiling his blood over unsupported flash installer scripts at the forums.
[01:05] <jdong> I tried. and I failed. sort of like my recent academic career
[01:06] <Hobbsee> just nuke the forums.
[01:07] <ajmitch> sounds good to me
[01:23] <directhex> jdong, i noticed that thread
[01:23] <directhex> i wonder WHY i noticed that thread.
[01:31] <jdong> directhex: yeah I hope the rest of the peanut gallery can see that it's not a great script to be running.
[01:31] <jdong> I'm through arguing with him.
[01:32] <directhex> jdong, but using -y with apt is always the right thing to do!
[01:34] <directhex> and so is using rm -f, just in case you changed those perms for a reason. and using remove/install
[01:52] <crimsun> jdong: we'll be discussing the future of flashplugin-nonfree at UDS.
[01:52] <jdong> crimsun: neat. What kind of future, like whether or not we're gonna punt it out of the repository, or better support for it?
[01:53] <crimsun> jdong: those issues are on the table
[01:54] <crimsun> (I suspect the discussion will involve hacking nspluginwrapper to not hog cpu, too.)
[01:56] <jdong> crimsun: very nice. Well I wish the best of success... comparing my Ubuntu experience to OS X on the same system, flash and sound are the two biggest day-to-day discrepancies I see
[01:58] <crimsun> well, the alpha 64-bit plugin of non-Free Flash is already a huge step forward in lessening the cpu nastiness, but there's quite some ways to go
[02:19] <TheMuso> jdong: What sound issues do you have?
[02:25] <jdong> TheMuso: mostly distortion -- blipping sometimes associated with system load
[02:25] <jdong> it's better when I disable ondemand CPU frequency scaling, dunno if that's placebo effect or not
[02:27] <TheMuso> jdong: Is your hda codec fully supported in Linux?
[02:29] <Hobbsee> jdong: ah, another distortion person!
[02:31] <jdong> TheMuso: it's an ALC885 I believe, iMac 8,1
[02:31] <jdong> TheMuso: to get any sound I have to set model to mbp3
[02:31] <TheMuso> jdong: Yeah thats been fixed in later alsa code, i.e 1.0.18 I think so the mbp3 flag is not needed.
[02:31] <TheMuso> My MacBook Pro is in the same position, although I don't get distortion at all.
[02:31] <TheMuso> Not that I've noticed anyway.
[02:32] <jdong> TheMuso: well the last time I used 1.0.18 I had a beautiful kernel panic in alsa code :)
[02:32] <jdong> so I might hold off for a bit. I'm somewhat gun-shy now
[02:32] <TheMuso> heh
[02:33] <TheMuso> jdong: Was that the final 1.0.18 release?
[02:33] <jdong> TheMuso: yeah
[02:33] <crimsun> I'm running the 20081116 snapshot with nary a panic.  Where did it splode?
[02:34] <jdong> Nov  2 18:32:59 droptop kernel: [77439.410052] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
[02:34] <jdong> Nov  2 18:32:59 droptop kernel: [77439.410066] IP: [<ffffffffa066d274>] snd_hda_codec_amp_read+0xc4/0x150 [snd_hda_intel]
[02:34] <jdong> let me know if the rest is useful to pastebin
[02:34] <crimsun> yes, the entire thing.  (Please file a bug affecting linux if you haven't.)
[02:34] <jdong> crimsun: affecting Linux for... a self-compiled alsa 1.0.18 failing?
[02:35] <crimsun> jdong: good point.  Well, it needs to get looked at somehow.
[02:36] <jdong> crimsun: fwiw full pastebin at http://paste.ubuntu.com/73630/
[02:36] <crimsun> jdong: ok.
[02:36] <jdong> crimsun: at the time I was using Skype
[02:37] <jdong> it seems like the skype auto-microphone-gain-adjustment feedback loop triggered that call path
[02:39] <crimsun> TheMuso: I'm looking redoing the source package for alsa-driver.  It's madness ATM.  Will send e-mail to pkg-alsa-devel once I have something less vapourware.
[02:39] <crimsun> looking at*
[02:39] <jdong> crimsun: I made an attempt at DKMS'ing alsa-driver...
[02:39] <jdong> then I realized dkms actually makes you list all the .ko's and where to install them.
[02:39] <ajmitch> slightly overkill?
[02:39] <jdong> then it went on a "TODO: perl hack" list and never got touched :D
[02:40] <jdong> ajmitch: *shrug* guess Dell never had to package something with 50+ .ko's?
[02:40] <jdong> the Fedora dkms RPM of alsa-driver definitely listed out every .ko and an install path for each.
[02:40] <TheMuso> crimsun: Ok, I guess what we want to be able to do is track it in git, and pull/merge commits from upstream as we want them.
[02:40] <jdong> it looked painful.
[02:40] <ajmitch> especially if they change in a future release
[02:40] <ajmitch> jdong: besides, the answer to that is Python :)
[02:41] <TheMuso> DKMS is not the answer for alsa kernel modules.
[02:41] <jdong> ajmitch: oh they CHANGE depending on ./configure flags :)
[02:41] <TheMuso> IMO
[02:42] <crimsun> yeah, I considered dkms some bit ago, and while it makes sense for an upstream vendor with a known subset of codecs to support, it's not feasible at package install.
[02:43] <crimsun> I even had the usual madness of "oh, let's anticipate which audio devices the user /might/ insert".  Yeah, crack.
[02:44] <ajmitch> which would include any usb or bluetooth devices?
[02:46] <crimsun> yeah, like "hda-intel" + "usb-audio" + "snd-bt-sco" and whatnot.  The problem is, what if I hotplug something requiring a more specific driver (e.g., usb-usx2y or usb-caiaq)?
[02:46] <superm1> snd-bt-sco is still in existence with 2.6.27+ though?
[02:46] <TheMuso> crimsun: Or you insert a PCI card into a desktop that you want to use, say ice1712/24
[02:46] <crimsun> TheMuso: precisely
[02:47] <crimsun> superm1: well, it's still shipped in intrepid
[02:48] <crimsun> (as in, since this work is going into pkg-alsa-devel, we don't have just Ubuntu kernels to consider)
[02:48] <TheMuso> That makes things even more hairy.
[03:19] <crimsun> directhex: does bug 175273 still affect you in a recent Ubuntu release?
[03:20] <crimsun> (bah, should have checked /wi first)
[03:23] <binarymutant> if anyone has any time on their hands I would appreciate very much an advocation for my package, http://revu.ubuntuwire.com/details.py?package=charm . Thanks :)
[03:48] <sjdurfey> i installed Banshee and the restricted codec set from the repos, and i cannot get anything to play, Banshee just gives me an orange box with an "x" in it on every song in my library, anyone have any ideas as to why?
[03:49] <Hobbsee> did you restart banshee?
[03:49] <sjdurfey> yeah
[03:49] <Hobbsee> did you change the address of the library?
[03:50] <sjdurfey> nope, still the same drive
[03:50] <Hobbsee> hm.  Then i don't know ;)
[03:50] <sjdurfey> hehe, damn
[03:51] <sjdurfey> now, i have to remount the drive manually everytime i restart my machine, and i built my library, restarted, and then remounted, could that have anything to do with it?
[03:56] <Hobbsee> possibly, if it's given it a different mount point
[03:57] <mneptok> O:)
[03:58] <ajmitch> yay
[03:58] <ajmitch> now we can live free from the threat of impending doom
[03:58]  * Hobbsee throws mneptok into some hot lava
[03:58]  * mneptok extrudes an igneous crust
[03:59] <Hobbsee> ajmitch: there's always impending doom..
[03:59] <mneptok> yeah, this *IS* -motu
[03:59]  * mneptok scampers
[03:59] <ajmitch> mostly harmless
[04:00]  * mneptok is not to be fed after midnight
[04:03] <binarymutant> should I just ditch everything after the first paragraph in my readme.source?
[04:06] <binarymutant> or is dpatchhttps://wiki.ubuntu.com/README.sourceHowTo
[04:06] <jmarsden> binarymutant: Pick the relevant bit of that wiki page for the patch system you are using
[04:07] <binarymutant> jmarsden, well I was using the entire dpatch example, should I just ditch everything after the first paragraph of it though?
[04:07] <Hobbsee> oh, so that's where that was from
[04:07] <jmarsden> binarymutant: It's up to you ... the page was just some examples to help people create the file easily.
[04:08] <binarymutant> jmarsden, also it's dpatch deapply-all
[04:08] <jmarsden> Hobbsee: I plead guilty?
[04:08]  * Hobbsee still doesn't agree with part of it
[04:08] <jmarsden> Care to propose a fix?
[04:10] <Hobbsee> jmarsden: something to the effect of: "To undo patches that have been previously applied to the source package, run:"
[04:11] <mneptok> wininst.exe
[04:11] <Hobbsee> jmarsden: it's probably a little pedant-ish, but it doesn't fulfil the role of dh_clean, or any of that, iirc.
[04:13] <jmarsden> Hobbsee: Is it supposed to?  Per Policy 4.1.4 it is supposed to say how to "Remove source modifications that are currently being applied when building the package."
[04:13] <Hobbsee> jmarsden: well, check with persia, but i thought the only thing it did was undo the patches.
[04:13] <Hobbsee> maybe it has changed, and i'm out of date
[04:13] <jmarsden> Right, and those are the only source modifications being made, right?
[04:14] <persia> Well, depends on the package.  lsdiff -z *.diff.gz is a good way to double-check.
[04:14] <jmarsden> I was a *total* beginner when I wrote that wiki page, BTW and in many ways I still am one...
[04:14] <Hobbsee> i wouldn't bet on it
[04:15] <binarymutant> I think it makes sense the way it is...except for the dpatch unapply-all should be dpatch deapply-all
[04:15] <persia> mneptok, It's a policy violation to use extensions for programs in the default path.  Please patch your application to use "wininst" instead.
[04:15] <mneptok> persia: so *that's* why i got a lot of crap for "mnep.tok"
[04:16] <NCommander> Hobbsee, repoke
[04:17] <persia> slytherin: nuking doesn't need a REVU Hacker.  Any REVU Admin can do it.
[04:24] <jmarsden> binarymutant: OK, s/unapply-all/deapply-all/ fix is now applied to the wiki :-)
[04:26] <binarymutant> very cool jmarsden, I also think your right about the way it reads
[04:26] <jmarsden> Maybe.  I need to think a bit more about the more philosophical change _Hobsee and _persia seem to be suggesting...
[04:27] <persia> jmarsden, It's probably better to insert the '_' in the middle :)
[04:27] <jmarsden> Ah, oops... :)
[04:27] <jmarsden> Give me props for at least *trying* not to alert you unnecessarily!
[04:28] <persia> Doesn't matter.  I read everything here anyway, and the other isn't spelled with two 'b's.  Anyway, which philosophical change am I suggesting?
[04:29] <jmarsden> Well, via Hobb_see, that the "Remove source modifications that are currently being applied when building the package" language which Policy 4.1.4 says the README.source is supposed to document, may not be 100% fulfilled by the stuff I have put in there...
[04:29] <persia> The key instructions are 1) How to get the source from the unpacked state into a good state for review of the build target, and 2) How to get the source in the state for review of the build target into the preferred state for uploading.
[04:30] <persia> The fact that this doesn't necessarily get the source into a pristine upstream state is irrelevant.
[04:30] <jmarsden> OK... so better to keep it simple and leave that part as is, you are hinting?
[04:31]  * persia hunts for a URL, and actually reviews the document
[04:32] <jmarsden> https://wiki.ubuntu.com/README.sourceHowTo and http://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource
[04:32] <persia> I find the language very confusing.
[04:32] <jmarsden> It's as close to policy as I could get... or that was my intent.
[04:33] <persia> Essentially, you *don't* want to "generate the fully patched source" before you "modify the source and save those modifications" when following the dpatch or cdbs examples.
[04:33] <persia> You've covered the base use case for policy, but it's hard to read.
[04:33] <persia> The quilt example works well, except/unless you want to insert patches into the stack at a different level.
[04:34] <persia> Also, if I remember the ML discussions about this, there were supposed to be default snippets in quilt, dpatch, CDBS, etc., so debian/README.source could say "This package uses quilt.  Please see /usr/share/doc/quilt/patching-with-quilt for further information".
[04:35] <persia> I'd be opposed to adding any of the examples to any new packages.
[04:35] <Elbrus> nellery: ping
[04:35] <persia> That level of detail is only required if the package constructs it's own patch system, else we have lots of duplicated content in the archives, and need to patch in lots of places if the behaviour of a patch system changes.
[04:36] <jmarsden> OK.  Would you be opposed to adding them to any of quilt/dpatch/CDBS that don't yet have such examples included?  That was actually a thought of mine at the time I first created the page.
[04:36] <persia> Elbrus, In nearly all cases, it's better to provide some context with a ping, and often it's better to ask things generally.
[04:36] <Elbrus> nellery: I am trying to understand why the changes are needed in nedit...
[04:36] <persia> jmarsden, No, not at all.  I think there's already some work done in Debian to that effect though: it may not be worth duplicating the effort.
[04:36]  * persia is not entirely up-to-date on this particular issue.
[04:37] <jmarsden> OK.  I don't see one in dpatch in Intrepid, for example
[04:37] <persia> Might have gotten caught by the Lenny freeze.  Check Debian VCS.
[04:37] <persia> (and BTS)
[04:37] <jmarsden> OK, can do.
[04:37] <Elbrus> nellery: my version runs on my machine so I wonder if/why the lesstif2 is not enough
[04:38] <persia> jmarsden, If they don't appear there, submitting good texts as patches to the BTS would probably make sense.  Once there, applything them in Ubuntu is mostly a question of timing.
[04:39] <jmarsden> OK.  I'm still mroe comfortable in the Ubuntu world than the Debian one... I need to grow up and start learning how to deal with upstream stuff :-)
[04:39] <Elbrus> persia: sorry, I see.
[04:40] <Elbrus> was just looking at bug 299318 and try to learn something from it
[04:40]  * Elbrus did the QA for Debian on nedit
[04:47] <persia> Elbrus, Thanks for catching that.  The Maintainer change is clearly a result of cut&paste, and wrong.
[04:48] <persia> Considering the only change to lesstif2 in Ubuntu is a scrollwheel inversion patch, I don't know why it wouldn't work, and suspect that's leftover cruft as well.
[04:49] <persia> Elbrus, Are you sure you don't need to build-dep on libxext-dev and libxp-dev ?
[04:50] <Elbrus> persia: it builds on sid... haven't tested yet on Ubuntu
[04:50] <persia> Hobbsee, Can you shed any light on this?
[04:50] <Elbrus> persia: I can try if you want.
[04:50] <persia> Elbrus, Last change to Ubuntu before the merge was April 2007, so things may have changed :)  Given you recently looked at the package, I suspect you're right.
[04:51] <Elbrus> persia: well, I just don't want to create regression because of me nosing around...
[04:51] <Hobbsee> persia: have i modified it?
[04:52] <persia> Hobbsee, You're the last uploader.
[04:52] <Hobbsee> oh.  damn.
[04:52] <persia> Hobbsee, From what Elbrus says, looks like a sync, but I'm hoping you can remember that far back.  The current merge doesn't look carefully tested.
[04:53] <Hobbsee> oh, of nedit.
[04:53] <Hobbsee> i was thinking that i didnt' remember lesstif2...
[04:54] <persia> Right.  The question is about bug #299318
[04:54] <StevenK> Is the bug about update-notifier being broken known?
[04:54] <persia> It's clearly a bad merge, but whether it should be fixed as a merge or sync'd remains an open question.
[04:54] <StevenK> (jaunty)root@liquified:~# /usr/share/update-notifier/notify-reboot-required.: 8: gettext.sh: not found
[04:54] <Hobbsee> persia: why is it a bad merge?
[04:55] <persia> Hobbsee, At least, failed to include maintainer change properly.  Given lesstif2 changelogs, I suspect the motif change may not be required (also based on Elbrus' testing).
[04:56] <Hobbsee> persia: oh right, his merge. not my changes.
[04:56]  * Elbrus did not very extensive testing, but at least nedit runs and performs tasks...
[04:56] <persia> Hobbsee, No.  I'm not criticising your past work in any way.
[04:56] <Hobbsee> persia: not critism - just still trying to get context on what the question is, how i'm involved, and what actual bit is wrong.  However, i think i've almost accomplished that ;)
[04:57] <persia> Hobbsee, Yeah.  It's been a while since you last looked at that one :)
[04:57] <Hobbsee> persia: maintainer change isn't required - it got orphaned after we touched it.
[04:57] <Elbrus> can I build against jaunty already using pbuilder?
[04:57] <persia> Elbrus, Certainly.
[04:58] <Hobbsee> bug 81103
[04:58] <Elbrus> I get: E: No such script: /usr/share/debootstrap/scripts/jaunty
[04:58] <persia> Hobbsee, Right, but we should reflect that in Original Maintainer.
[04:58] <Hobbsee> StevenK: in what?
[04:58] <Hobbsee> persia: indeed.
[04:58] <StevenK> Hobbsee: Hm?
[04:59] <Hobbsee> [15:54] <StevenK> Is the bug about update-notifier being broken known?
[04:59] <Hobbsee> StevenK: in..intrepid?  jaunty?
[04:59] <StevenK> Hobbsee: Oh. Jaunty
[05:00] <Hobbsee> StevenK: then yes, i think so.  assuming you mean 'break' by "wanting to upgrade you to intrepid"
[05:00] <StevenK> Hobbsee: update-notifier, not update-manager
[05:01] <jmarsden> persia: I can't see a patch for the README.source for dpatch in Debian BTS... where can I find its VCS?  And in general, how can one find a VCS for a given package, come to that -- is there a neat way to know where to find the VCS?
[05:01] <Hobbsee> StevenK: oh, right.
[05:01] <Hobbsee> persia: if it runs, and builds, then it's probably fine to drop the changes now.
[05:01] <StevenK> (jaunty)root@liquified:~# /usr/share/update-notifier/notify-reboot-required
[05:01] <persia> jmarsden, apt-cache showsrc $(package) would have a Vcs-* entry.
[05:01] <StevenK> .: 8: gettext.sh: not found
[05:02] <Hobbsee> persia: beyond that, i don't remember specifics
[05:02]  * Elbrus just remembered reading somewhere you need to add a link to gutsy...
[05:02] <persia> Hobbsee, Thanks for double-checking.  I'll repurpose the merge, and request the sync.
[05:02] <jmarsden> persia: Aha, I did apt-cache show not showsrc   Thanks.
[05:03] <StevenK> Elbrus: Right
[05:03]  * Elbrus is starting building nedit in jaunty now
[05:03] <Hobbsee> persia: cool, OK
[05:12] <jmarsden> binarymutant: dpatch in Jaunty (dpatch 2.0.30) has a default file at /usr/share/doc/dpatch/README.source.gz which you can (and therefore should) point to instead of using text from my wiki page
[05:16] <persia> sebner, When you get a chance, could you check to see if binfmt_misc solves https://blueprints.launchpad.net/ubuntu/+spec/hellboy195 and update the status accordingly?
[05:27] <Elbrus> persia: nedit build without changes and seems to run exactly like on debian... again: no extensive testing, but writing and saving works
[05:34] <binarymutant> thanks jmarsden
[05:35] <jmarsden> No problem.  Now I'll have to see about submitting by CDBS one as a patch to its maintainers, I suppose :-)
[05:35] <jmarsden> s/by/my/
[05:38] <hyperair> hi. who maintains revu?
[05:39] <hyperair> http://revu.ubuntuwire.com/feed.py?package=codelite <-- MOD_PYTHON ERROR
[05:40] <sjdurfey> if i downloaded eclipse from the website, am i also going to need all the dependencies that were required for the version from the repo?
[05:41] <persia> hyperair, The REVU Hackers maintainer REVU.
[05:42] <persia> Elbrus, Thanks for checking.  I've requested a sync of your upload to the repos.
[05:42] <hyperair> persia: and where do i find them?
[05:42] <persia> hyperair, Usually here.
[05:42] <persia> sjdurfey, Quite likely, although you'll want to check the upstream website to determine which packages you need.
[05:42] <sjdurfey> ok, thanks
[05:44] <hyperair> persia: um so how do i ping them or whatever?
[05:45] <persia> hyperair, You already have.
[05:45] <hyperair> uh i did?
[05:46] <persia> The main issue is that it's night for most of them.  The one awake at this hour is probably either commuting, or in a foul mood due to a late evening of work.
[05:47] <persia> Yeah.  Most of them ping on "REVU" or "REVU Hackers".
[05:47] <persia> In general, it's a handy thing to have an alert on a team.
[05:47] <jmarsden> hyperair: So, you can retry maybe every 4 hours until someone responds :-)
[05:48] <hyperair> i see
[05:48] <hyperair> okay
[05:48] <hyperair> what does "REVU Day" mean?
[05:48]  * persia recommends every 6-8 hours, to avoid annoying people
[05:49] <persia> It's the day the REVU Coordinator tries to get every MOTU to review some packages.
[05:49] <hyperair> i see
[06:22] <dholbach> good morning
[06:27] <iulian> Morning Daniel.
[06:27] <dholbach> hi iulian
[06:33] <highvoltage> howdy dholbach and iulian
[06:33] <dholbach> hi highvoltage
[06:34] <iulian> Hey highvoltage.
[06:36] <porthose> g'night all
[07:47] <hyperair> could someone explain to me what this lintian warning means? W: codelite: possible-unindented-list-in-extended-description
[07:50] <ScottK> hyperair: Run lintian -v on the package.  That should give you a very detailed explanation.
[07:50] <hyperair> ScottK: k thanks
[07:52] <hyperair> ScottK: doesn't seem any more detailed than earlier
[07:52] <ScottK> OK.  Sorry I'm out the door right now and don't have time to give detailed help.
[07:53] <wgrant> hyperair: Try -i instead
[07:53] <hyperair> wgrant: alrighti 'll try that thanks
[07:53] <soren> hyperair: Could you put the entire control file on pastebin?
[07:55] <hyperair> http://revu.ubuntuwire.com/details.py?package=codelite
[07:55] <hyperair> soren: it's there
[07:55] <hyperair> soren: i'm fixing a bunch of lintian errors right now, and that popped up.
[07:56] <hyperair> soren: http://pastebin.com
[07:56] <hyperair> shit
[07:56] <hyperair> wrong url
[07:56] <soren> hyperair: I see it now.
[07:56] <persia> hyperair, Package descriptions have a very distinct way to handle lists.
[07:56] <soren> Right, lintian explains it pretty well.
[07:56] <soren> And links to debian policy which explains it even better :)
[07:56] <hyperair> soren: yeah it does, but i don't get it. i don't have any unindented lines!
[07:56] <soren> It's not indented enough :)
[07:56] <soren> Read 5.6.13 of debian policy.
[07:56] <hyperair> soren: eh what?
[07:56] <hyperair> soren: got a link?
[07:57] <soren> http://www.debian.org/doc/debian-policy/ch-controlfields.html
[07:57] <persia> hyperair, After removing the indent for the description, you don't have any indent left.
[07:57] <hyperair> soren:  thanks
[07:57] <soren> 4 seconds of google. Bam!
[07:58] <hyperair> persia: i don't understand. what indent?
[07:58] <soren> hyperair: Have you read 5.6.13 yet?
[07:59] <hyperair> soren: yeah. but i still don't get what's wrong with my control file =\
[07:59] <soren> One space at the start of the line (which all of your lines have) just means "this line is part of the extended description).
[07:59] <hyperair> soren: yes, i know that. i have one space at the start of my lines. so what's wrong?
[08:00] <persia> hyperair, You have a list that doesn't meet the criteria for lists (second bullet point in the description of the extended description)
[08:00] <soren> Any application presenting this data is allowed (probably even encouraged) to reformat these lines by removing the linefeeds you added and use something more fitting for the way it's presenting it.
[08:00] <soren> Obviously, that'll mess up your list.
[08:01] <hyperair> soren: so what should i do?
[08:01] <soren> Any line beginning with two (or more) spaces will be left as is.
[08:01] <hyperair> oh so i should indent it with one more space?
[08:01] <soren> Yes.
[08:01] <hyperair> soren: okay thanks
[08:02] <hyperair> now i just have to figure out how to write manpages
[08:02] <persia> soren, Not only "encouraged" but "mandated" by policy: "Successive lines of this form will be word-wrapped when displayed."
[08:02] <hyperair> and then write 5 of them
[08:02] <hyperair> and figure out a way to shfit /usr/share/codelite/plugins to /usr/lib/codelite/plugins
[08:03] <soren> persia: "will" makes it a prophecy which in my book is less than a mandate :)
[08:04] <persia> soren, Was policy proscriptive, I'd agree.  As policy is supposed to be descriptive, I suspect that all current tools do wordwrap.
[08:05] <hyperair> hmm is there a lintian that won't complain about this? E: codelite_1.0.2432-0ubuntu1_source.changes: bad-ubuntu-distribution-in-changes-file jaunty
[08:05] <Yasumoto> RAOF:just so you know, almost done with updating the changes for miro
[08:05] <Hobbsee> hyperair: the jaunty one itself, probably.
[08:06] <Hobbsee> hyperair: you can just ignore it, though
[08:06] <soren> hyperair: Yeah, don't worry about that one.
[08:06] <hyperair> alright
[08:10] <RAOF> Yasumoto: Cool.  I was wondering about that ;)
[08:10] <Yasumoto> RAOF: I was down at a Usenix conference repping the SoCal linux expo last week, it through off my schedule
[08:10] <Yasumoto> sorry :-X
[08:11] <RAOF> No problem at all, it's not like the deadline's pressing.
[08:11] <Yasumoto> yeah, true
[08:11] <Yasumoto> thanks for the advice so far :)
[08:11] <RAOF> Thanks for taking an interest in Miro.
[08:17] <hyperair> if i'd like to add a bunch of diversions for a package, should i use dpkg-divert in preinst and postrm or what?
[08:17] <RAOF> Yeah.
[08:17] <persia> You should probably try to make the package not need them though.  They are *very* annoying to get right.
[08:17] <hyperair> ok
[08:18] <hyperair> persia: well, you see, there's this package i'm thinking of packaging.. which is geany-dark-scheme or something of that sort
[08:18] <Yasumoto> So to properly update the changelog,I should just walk through the changes from the last ubuntu releases(since the last merge) and double-check if they're in the vanilla debian package?
[08:18] <hyperair> persia: the thing is that the stuff in it overrides the data files for geany,, but at the same time, without geany, it's useless
[08:19] <persia> Yasumoto, If you're doing a merge, preserve *all* the previous Ubuntu changelog entries, but then only report on the preserved changes by examining how your package differs from Debian.
[08:19] <hyperair> persia: any suggestions besides dpkg-divert?
[08:19] <persia> hyperair, Then surely that's a bug in geany: that it doesn't have a facility to allow for additional data to be added post-install.
[08:21] <hyperair> persia: unfortunately so. the colour schemes for the files are all in /usr/share/geany, and they have to be overriden if it is to be changed
[08:21] <Yasumoto> persia: thank you, yeah, I'm working on a merge. By "report", does that mean I should delete anything that's included in debian, include notes on what's found in the ubuntu package? I feel like I'm not grokking this right, sorry :/
[08:22] <persia> Yasumoto, Your final changelog should be the old Ubuntu changelog + any new changelog entries from Debian + a new changelog entry from you.
[08:23] <persia> In the new changelog entry, you want to have one item "merged with Debian.  Remaining Ubuntu changes:" and list the specific changes you are preserving.
[08:23] <Yasumoto> ohhhh
[08:23] <Yasumoto> thank you
[08:25] <huats> morning everyone
[08:30] <eMerzh> if someone has time to review my package, i wld be verry happy :p ( http://revu.ubuntuwire.com/details.py?package=sqliteman )
[08:36] <Yasumoto> good morning huats
[08:36] <huats> morning Yasumoto
[08:44] <Yasumoto> RAOF: if you have some time, mind looking at my preliminary changelog? http://pastebin.ubuntu.com/73754/
[08:45] <Yasumoto> jk, update: http://pastebin.ubuntu.com/73756/
[08:58] <mr_pouit> persia: imho that was not very useful to add a watch file to xfce-mcs-plugins-extra, as it'll be deprecated with xfce 4.6 ;)
[08:58] <RAOF> Yasumoto: Looks about right, although you're missing the dropping of the needless democracyplayer-data package.
[08:59] <persia> mr_pouit, Oh, then yes, it was probably useless.  I just found it when I was cleaning up ~/src/scratch today, and pushed it to help clear UEHS.
[09:01] <Yasumoto> RAOF: good, catch, I didn't see that
[09:06] <RAOF> Yasumoto: I always debdiff my merges against the Debian base while reviewing my changelog; that makes it easy to spot.
[09:09] <slytherin> persia: do you have GCJ installed at present?
[09:09] <persia> slytherin, No.
[09:12] <slytherin> persia: ok. Whenever you get time, can you please check if omegat starts with GIJ runtime? My last changelog entry indicates it should run, but it was not working yesterday. I am working on putting changes back into Debian.
[09:14] <persia> slytherin, Do you need that tested in intrepid, jaunty, sid, or lenny?
[09:15] <slytherin> persia: intrepid is fine.
[09:16] <Yasumoto> RAOF: attached to the bug
[09:16] <Yasumoto> thanks for your patience, lemme know if there's anything else I can fix
[09:17] <Yasumoto> I'm off to bed, I'll see you guys tomorrow
[09:21] <persia> slytherin, Fails to startup because I don't have ~/.omegat/omegat.prefs
[09:22] <slytherin> persia: Wow. On my machine it simply throws a null pointer exception. Are you using version from repositories?
[09:23] <persia> slytherin, Yep.  Intrepid version, intrepid repos.  update-alternatives adjusted to always use gcj.
[09:23] <persia> (mind you, it's all purged now, but I was using that)
[09:39] <voland> persia, hello. is this a right place to ask why i get an error usin pbuilder?
[09:39] <voland> *using
[09:40] <persia> voland, It can be.  Ask your question.  If it's not the right place, someone will point you elsewhere.
[09:41] <voland> I've got such error 'fb2parser.c:27:51: error: /usr/include/libxml2/libxml/xmlmemory.h: No such file or directory' I have libxml2 packge installed
[09:41] <voland> There is such file
[09:42] <slytherin> persia: I wonder what is wrong with my machine. I will check once again when I go home.
[09:42] <mok0> voland: you need libxml2-dev installed
[09:42] <voland> mok0, I have tem installed
[09:42] <persia> voland, Is it in your build-dependencies?
[09:43] <voland> yes
[09:43] <soren> libxml2-dev? Not just libxml2?
[09:44] <voland> soren, yes
[09:44] <mok0> voland, find line 27 in fb2parser.c and paste it here
[09:44] <soren> $ dpkg -L libxml2-dev | grep /usr/include/libxml2/libxml/xmlmemory.h
[09:44] <soren> /usr/include/libxml2/libxml/xmlmemory.h
[09:44] <soren> It's certainly there.
[09:45] <soren> voland: I'm much more interested in the build log from pbulider.
[09:45] <soren> pbuilder, even.
[09:45] <voland> #include </usr/include/libxml2/libxml/xmlmemory.h>
[09:45] <mok0> hmm
[09:46] <mok0> voland: edit it to become <libxml2/libxml/xmlmemory.h> insted
[09:46] <mok0> instead
[09:46] <voland> ok
[09:50] <voland> soren, here it is an interesting part of log http://paste.ubuntu.com/73779/
[09:52] <voland> mok0, I've done it but nothing happens
[09:55] <soren> voland: That's not the part of the log I'm interested in, actually.
[09:55] <soren> voland: Can you put the whole thing somewhere?
[09:56] <voland> ok
[09:56] <foolano> voland: i guess you need  -I/usr/include/libxml2 somewhere
[10:45] <iulian> james_w: Thanks for the uploads!
[11:35] <SUNWjoejaxx> anyone have an example of a really simple kernel module source code package?
[11:37] <persia> kqemu-source
[11:38] <SUNWjoejaxx> ok thanks
[11:48] <eMerzh> call to anyone who want / can review a package, ...i just correct mine for lasts errors ...(http://revu.ubuntuwire.com/details.py?package=sqliteman)
[11:51] <handschuh> eMerzh: sorry for beeing not detailed enough the last time
[11:52] <handschuh> eMerzh: http://paste.ubuntu.com/73816/ - this is how your changelog is supposed to look like
[11:52] <eMerzh> ah.. ok, no problem
[11:53] <eMerzh> otherwise, something else?
[11:54] <handschuh> eMerzh: looks good. but still reading
[11:54] <eMerzh> ok thanks
[11:56] <handschuh> eMerzh: your debian/sqliteman.1 says "NOVEMBRE 2008"
[11:57] <handschuh> eMerzh: delete the empty line in debian/watch (between version=3 and http://...)
[11:58] <eMerzh> Oups =)  -"RE" +"ER"
[11:59] <eMerzh> ok... i add it because at building i had a warning on it
[12:00] <handschuh> does this watchfile even works?
[12:00] <handschuh> s/works/work
[12:01] <joaopinto> hi
[12:05] <handschuh> eMerzh: ok watchfile is fine - just delete the empty line in the middle
[12:06] <eMerzh> ok
[12:48] <handschuh> If a package that I have created passed revu and got into the ubuntu-repositories, am I allowed to update this package directly?
[12:48] <persia> handschuh, If you're an Ubuntu developer.
[12:48] <voland> how can I add xml2-config --cflags into source for ppa packaging?
[12:49] <persia> handschuh, More generally, it falls into the same category as the rest of the packages in Ubuntu, but the sponsors are always happy to upload updates.
[12:49] <directhex> handschuh, you still need to file debdiff/diff.gz updates to launchpad - you can just get to be more... insistent... when going on a sponsor hunt
[12:50] <handschuh> persia: so getting an update through revu is likely faster than a new package?
[12:50] <directhex> handschuh, might i suggest a trident? a normal spear isn't very good at pinning sponsors down
[12:50] <persia> handschuh, No.  Updates don't go to REVU.
[12:50] <persia> handschuh, More specifically, you'd submit patches to packages in the archive through bugs, and the sponsors process those.
[12:50] <joaopinto> can someone advocate http://revu.ubuntuwire.com/details.py?package=amoebax ? Thanks
[12:51] <persia> directhex, sponsors are slippery.  Nets are more useful.  The trident is to be used *after* the net.
[12:51] <handschuh> persia, directhex: thats good news to me  - thanks
[12:51] <persia> joaopinto, The latest upload has already been rejected.  It's exceedingly unlikely to be sponsored without more comments or uploads.
[12:52]  * handschuh buys some tridents and nets
[12:52] <joaopinto> ops, sorry didn't noticed the last comment
[12:52] <joaopinto> :\
[12:53] <persia> joaopinto, No problem.  Happens to everyone :)
[12:54] <joaopinto> I had the wrong idea the cdbs edit patch would add the patch to the patches list
[12:56] <voland> could someone tell where to dig with this libxml? or where can i ask. don't think it's a demand, it's just a request ^
[12:56] <azeem> voland: try to be more specific
[12:56] <azeem> your question is highly dependent on the particular build system of the package
[12:57] <voland> here it is a build log from my ppa: http://launchpadlibrarian.net/19751646/buildlog_ubuntu-intrepid-i386.easyreader_0.1.2-1ubuntu2_FAILEDTOBUILD.txt.gz
[12:58] <voland> someone told me to use 'cc `xml2-config --cflags`' in compile prosess, so my question is where sould i put this? in witch file?
[13:01] <voland> as you can see dependences are satisfied, but it can't find header files...
[13:01] <voland> sorry for dusturbing you all but i simply want to build this package
[13:02] <joaopinto> voland, if your package has a Makefile, you would add it to CFLAGS, the xml2-config
[13:02] <voland> *disturbing
[13:03] <voland> in my makefile.in there is this line: PACKAGE_CFLAGS = @PACKAGE_CFLAGS@
[13:04] <azeem> voland: so check what it gets expanded to in Makefile
[13:04] <voland> and in src directory in makefilei.am there is anoter one: INCLUDES = \$(PACKAGE_CFLAGS)
[13:07] <voland> there is no makefile in my directory
[13:08] <voland> onle makefile.am and makefile.in
[13:08] <voland> *only
[13:09] <voland> sorry, i forgot to run ./configjre
[13:11] <slytherin> voland: Is this the first time you are compiling something from source?
[13:13] <voland> slytherin, no, but this troubles faced me for the first time
[13:16] <slytherin> voland: the reason I am asking is that you do not seem to be very familiar with autotools based compilation.
[13:17] <eMerzh> handschuh, thanks for your comments, package updated
[13:19] <voland> slytherin, yes, i'm not very familiar. my problem is: if i want to check my package with pbuild it returns me an error like this: /usr/include/libxml2/libxml/xmlmemory.h:16:31: error: libxml/xmlversion.h: No such file or directory
[13:20] <voland> i have this package (libxml2-dev installed), but nothing solves
[13:21] <slytherin> voland: when you say, I have ﻿libxml2-dev installed, where is it installed?
[13:21] <voland> slytherin, /usr/include/libxml2/
[13:22] <slytherin> voland: pbuilder does not use packages installed on your machine.
[13:22] <voland> yes, but it is in my dsc file in depend section
[13:23] <voland> in build-depends section
[13:26] <slytherin> voland: what is the link to your ppa?
[13:28] <azeem> voland: probably the same error again, -I/usr/include/libxml2 missing
[13:33] <voland> azeem, yes, because makefile was rewrited by configure script
[13:33] <azeem> well, of course
[13:33] <voland> slytherin, http://ppa.launchpad.net/telenga/ubuntu
[13:34] <azeem> 14:00 < azeem> voland: so check what it gets expanded to in Makefile
[14:39] <eMerzh> sorry to insist, if someone could review again my package ( http://revu.ubuntuwire.com/details.py?package=sqliteman )
[15:08] <bddebian> Heya gang
[15:20] <hyperair> regarding the packaging codelite in revu, there are stuff in /usr/share/codelite/plugins (.so files, and lintian complains), but to shift the plugins dir to /usr/lib requires quite an extensive patch. is the whole lintian-must-be-clean rule set in the stone or something?
[15:20] <james_w> no
[15:20] <james_w> but that is a fairly serious problem
[15:33] <AnAnt> Hello, can someone have a look at the patch in bug 298273 ?
[15:34] <slytherin> AnAnt: I guess superm1 is the most qualified person for review. :-)
[15:34] <AnAnt> superm1: ping
[15:36] <superm1> AnAnt, at a first glance, are you sure you have enough recommends?  generally dkmsified packages need recommends on the headers and libc6-dev.
[15:37] <AnAnt> kernel-headers?
[15:37] <superm1> AnAnt, yeah kernel headers
[15:37] <superm1> eg linux-headers-generic | linux-headers
[15:37] <AnAnt> it recommends kernel-package
[15:38] <superm1> which pulls in a bunch of stuff that you dont want
[15:38] <superm1> dpkg-dev
[15:38] <superm1> po-debconf
[15:38] <superm1> bzip2
[15:38] <AnAnt> superm1: well, the original package (which uses module-assistant) was like that
[15:39] <AnAnt> superm1: this package supports both DKMS & module-assistant
[15:39] <superm1> AnAnt, that's because the original package would have generated debs
[15:39] <AnAnt> superm1: well, it still does, because it still supports module-assistant
[15:39] <superm1> hmm
[15:39] <AnAnt> superm1: if you look at the postinst & postrm, you'll see a check if dkms exists, then dkms will be used
[15:40] <superm1> i'll have to look a little bit closer later today then.  can you assign the bug to me and i'll give it a shot in a chroot later and see if the behavior looks right?
[15:40] <AnAnt> sure
[15:40] <AnAnt> superm1: & thanks
[15:41] <AnAnt> done
[15:50] <hyperair> james_w: it's actually pretty hard, because everything seems to depend on a function GetInstallDir or something, and that defaults to /usr/share or /usr/local/share on linux
[16:12] <jsmidt> I uploaded a package to revu called thepeg hours ago.  dput said it was successful but there is nothing on the website and I received no new email.
[16:13] <persia> jsmidt, You wouldn't get email.  Which package?
[16:13] <jsmidt> thepeg
[16:15] <persia> jsmidt, It was rejected.  Is your GPG key in launchpad?
[16:15] <jsmidt> Yes, I uploaded the same package to my PPA successfully.
[16:16] <jsmidt> Does PPA use the same key?
[16:16] <persia> Yes.
[16:16] <persia> Next, have you previously logged into the web interface of REVU?
[16:16] <jsmidt> yes
[16:18] <persia> Right.
[16:18]  * persia tries to decode harder
[16:19] <persia> jsmidt, What's your LP ID?
[16:19] <jsmidt> jsmidt
[16:24] <persia> Well, at least the signing key matches.  Hmmm...
[16:25] <jsmidt> persia, thanks a lot for all this.
[16:25] <persia> No problem.  That's why there are REVU Admins :)
[16:26] <persia> jsmidt, I don't know why it didn't work.  I'll shove it back in the queue, and see if it works this time.
[16:26] <jsmidt> okay
[16:28] <persia> requeued.  Check back on REVU in ~ 10 minutes.  If it's not there yet, complain here again.
[16:28] <jsmidt> okay
[16:30] <mok0> In the jaunty version of nut, configure prefix is changed from /usr to /, libdir is still /usr/lib, which means that the *.so link in the libupsclient1-dev package is void
[16:30] <mok0> I wonder what the intention is
[16:41] <jsmidt> persia, it worked! Thanks a lot again.
[16:42] <persia> jsmidt, No problems.  Probably just a race between your login, syncing credentials from LP, and the upload.
[16:45] <iulian> james_w: Regarding the powersave merge... those changes are in translations/. I've no idea why it showed up in the diff.
[16:45] <iulian> james_w: I'm re-doing the merge and looking up carefully.
[16:46] <james_w> iulian: there was more than that
[16:46] <james_w> you don't have to document the translations/ stuff, as that is automatic
[16:46] <iulian> james_w: http://paste.ubuntu.com/73903/plain/
[16:47] <persia> also, the automated merge tools do *especially* badly with translations.  Except in special cases, it's generally better to just use the Debian translations.
[16:47] <iulian> james_w: Do I have to document the changes from debian/patches/series?
[16:48] <iulian> Since I removed a couple of patches I had to remove them from series as well.
[16:48] <james_w> iulian: things like the removal of ${misc:Depends}
[16:48] <james_w> the bits added to README.Debian
[16:49] <iulian> james_w: That is documented (Remove Security section from README.Debian.)
[16:49] <iulian> Debian changed README.Debian a little bit.
[16:50] <james_w> your diff from Debian *adds* lines
[16:52] <persia> Elbrus: fpc isn't sync'd because it has Ubuntu variation: it needs a merge.
[16:53] <persia> james_w, Did you have a special interest in that, or were you just helping because you had time?
[16:53] <james_w> persia: with fpc?
[16:54] <persia> Yes.
[16:54] <james_w> it was on the sponsors' list
[16:55] <persia> james_w, Then no worries :)
[16:57] <iulian> C* translations/power-management.pot and I see only power-management.pot.UBUNTU. Shouldn't it have a .DEBIAN as well?
[16:58] <iulian> I remember that I renamed it to don't show UBUNTU.
[16:58] <iulian> And I believe this is why it showed up in the diff.
[17:02] <devfil> mok0: next time can you please ask the previous uploader before working on a merge?
[17:03] <mok0> devfil: sorry did you waste time on collectd?
[17:03] <devfil> mok0: yes
[17:03] <mok0> devfil: I looked for you
[17:03] <iulian> persia: Like you said that the automated merge tools are badly with translation. Don't you think it should have had a .DEBIAN as well?
[17:03] <iulian> Hmm, am I missing something?
[17:03] <mok0> devfil: did you work out the problem with the package
[17:05] <persia> mok0, devfil Please 1) file a bug when you're starting a merge, if you're going to take more than 5 minutes and you aren't the previous uploader, and 2) check bugs against the package when you start the merge.
[17:05] <mok0> persia: yes it was dumb
[17:05] <devfil> mok0: have you tested if it build fine or not? If I remember right it doesn't build due to a problem in nut
[17:06] <mok0> devfil: right.
[17:06] <mok0> devfil: I filed a bug against nut
[17:06] <mok0> bug 299489
[17:06] <devfil> mok0: also NCommander but in debian, I was waiting for the fix in order to upload the package
[17:06] <mok0> devfil: but there was also an issue with perl.c
[17:07] <NCommander>  ?
[17:07] <devfil> mok0: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505101
[17:08] <mok0> devfil: you wanna link to that bug?
[17:11] <devfil> mok0: done
[17:11] <mok0> devfil: thx
[17:15] <mok0> devfil: sorry I stepped on your toes
[17:15] <jdong> aasdfasdfs
[17:24]  * NCommander attacks the universe sponsor queue
[17:24] <superm1> NCommander, could i prod you to take a look at a backport request?
[17:24] <NCommander> superm1, link
[17:25] <superm1> NCommander, https://bugs.edge.launchpad.net/intrepid-backports/+bug/298785
[17:25] <NCommander> superm1, did you test build on intrepid?
[17:27] <superm1> NCommander, that PPA is an intrepid PPA
[17:27] <iulian> james_w: W: powersave source: patch-system-but-direct-changes-in-diff translations/power-management.cs.p
[17:27] <NCommander> So the package from jaunty builds on intrepid without changes?
[17:27] <superm1> NCommander, yup
[17:27] <iulian> james_w: ... o and 9 more
[17:28] <NCommander> superm1, I'm a little tied up, if you can post the extact versions to verify, and confirm they install without issue (aka verification), I'll ACK it if there are no evil rdepends
[17:28] <iulian> james_w: I still get those changes in the diff.
[17:28] <superm1> NCommander, sure i'll add a log showing that later
[17:30] <iulian> james_w: http://paste.ubuntu.com/73916/plain/
[17:31] <james_w> iulian: does the clean target in debian/rules do something to change them?
[17:32] <NCommander> superm1, I'm somewhat concerned about the rdepends. How well has this been tested
[17:32] <iulian> james_w: No, I already checked that.
[17:33] <superm1> NCommander, i've got multiple users on several PPAs, including ~superm1 and ~commandir.  not to mention the commandir team is recommending this as their installation method on their website atm http://www.commandir.com/content/view/53/75/
[17:33] <NCommander> Please post that in the verification comment
[17:36] <NCommander> nxvl, ping
[17:36] <iulian> james_w: It seems that someone modified it without documenting it in the changelog. I checked the debian package (0.15.20-3) and lintian didn't complain.
[17:37] <iulian> james_w: Should I try to manually merge it?
[17:38] <iulian> james_w: I believe this is the only way we can do to get rid of those changes.
[17:39] <iulian> If you have a better solution, that would be great.
[17:39]  * NCommander thinks Launchpad ate my upload
[17:41] <iulian> Make it burp.
[17:43] <CarlFK> I am building dvgrab-3.2 from cvs.  I copied the debian/ dir from apt-get source dvgrab.  I had to add quotes to a line in rules to get it to build.  I am guessing someone else is going to bump into this.  where should I send a patch?
[17:44] <CarlFK> should I post it to https://bugs.launchpad.net/ubuntu/+source/dvgrab ?
[17:48] <slytherin> persia: there?
[17:50] <RainCT> btw, what happened with the MOTU Meeting last Friday?
[17:50] <persia> Sortof.
[17:51] <persia> RainCT, loosely, we decided to talk more.  I have partial minutes compiled, and expect to send them within the next 14 hours.
[17:52] <slytherin> persia: did you notice any other errors than the error about missing .omegat/omegat.prefs when you launched omegat with GIJ?
[17:56] <RainCT> persia: OK.  /me couldn't assist because he was at school :(
[17:57] <james_w> iulian: please attach your latest patch to the bug report
[17:57] <iulian> james_w: I already did :)
[17:57] <persia> slytherin, No.  It immediately failed to start with a FileNotFound
[17:57] <NCommander> ember, ping
[17:58] <james_w> iulian: please also mark them as patches, it makes sure they end up as text/plain
[17:58] <slytherin> persia: Ok. Because I am seeing two exceptions, file not followed by null pointer. I get file not found with openjdk as well but the app starts and creates preferences file.
[17:59] <james_w> iulian: you've dropped the old changelog entries
[18:00] <iulian> james_w: Oups, the Ubuntu ones, right?
[18:00] <james_w> yep
[18:01] <iulian> Forgot about the changelogs. Will upload a new diff in a moment.
[18:01]  * jdong grins
[18:01] <jdong> Unable to mount USB 2.0 Root Hub: Cannot claim device.
[18:01] <jdong> why thank you, Nautilus :)
[18:02] <james_w> iulian: I also don't think all of debian/NEWS should be dropped
[18:02] <james_w> I'm not sure about completely removing the postinst, due to the dbus reload, but I'm not confident enough to say either way
[18:03] <iulian> james_w: OK, I will re-add the NEWS file.
[18:04] <james_w> iulian: no, not all of it
[18:04] <iulian> Yup
[18:06] <iulian> james_w: What would you like to keep form this http://paste.ubuntu.com/73934/plain/ ?
[18:06] <iulian> s/form/from/g
[18:07] <eMerzh> me again, someone to review a package .... thaanks ;) http://revu.ubuntuwire.com/details.py?package=sqliteman
[18:07] <iulian> james_w: 0.15.20-1 ?
[18:07] <NCommander> iulian, svk has been copied into updates, it should be generally available within a few hours (depending on how long your mirror takes to update)
[18:08] <james_w> iulian: look at the version numbers
[18:08] <james_w> one entry has been added since the last merge
[18:08] <james_w> so there was only one before
[18:08] <iulian> NCommander: That's awesome, who's the 2nd ACKer?
[18:08] <james_w> so removing the file just removed one, now it removes two
[18:08] <NCommander> iulian, you only need one, someone forgot to set it to verification-done
[18:08] <james_w> does the new entry apply to Ubuntu?
[18:09] <jsmidt> I am trying to package a package that will be maintained by the entire High Energy Physics team in Launchpad.  I want to put an email for the team.  Launchpad doesn't list one, just says all notifications are sent to all members.
[18:09] <jsmidt> Is there a way to set up an email that goes to all members?
[18:09] <jsmidt> Or is there an LP address that forwards to all members?
[18:09] <Laney> You can have mailing lists for teams on LP
[18:10] <jsmidt> Laney, do you have to be the team administrator to set that up?
[18:11] <Laney> jsmidt: Probably
[18:12] <Yasumoto> jsmidt: yeah, I believe so
[18:12] <slytherin> jsmidt: it is possible so either set a mailing list or to set mail preference so that mail gets sent to all members. In both cases you have to be admin.
[18:13] <jsmidt> Thanks Laney Yasumoto and slytherin, I will look into this.
[18:16] <Yasumoto> jsmidt: what are you trying to package?
[18:16] <jsmidt> thepeg and herwig
[18:16] <jsmidt> Later a few others.
[18:16] <iulian> james_w: I believe the new entry does apply to Ubuntu.
[18:17] <james_w> iulian: I agree
[18:18] <iulian> james_w: I suggest to keep it and remove the last one, 0.12.0-1.
[18:18] <james_w> I agree
[18:18] <iulian> OK
[18:29] <binarymutant> if anyone  has the time I would greatly appreciate a review/advocation of my package, http://revu.ubuntuwire.com/details.py?package=charm, thank you :)
[18:42] <iulian> james_w: Patch has been attached.
[18:42] <james_w> I saw
[18:44] <NCommander> binarymutant, I'm reviewing now
[18:44] <binarymutant> thanks NCommander
[18:47] <NCommander> binarymutant, advocated
[18:48] <binarymutant> ty
[18:48] <NCommander> binarymutant, you need to find a second person to look it over
[18:49]  * persia prepares to reject charm
[18:49] <NCommander> persia, O_o?
[18:49] <sebner> hrhr
[18:50] <persia> NCommander, I try to reject everything I can.  Sometimes I slip, and something gets through.
[18:50] <NCommander> persia, there was one cosmetic issue I noted, but not enough for me to withhold an advocation (whoever uploads can quickly fix it, the changelog probably should have an additional newline)
[18:51] <sebner> persia: I like your humor =)
[18:51] <persia> sebner, Thanks :)
[18:51] <sebner> persia: mind helping me with a REVU package review?
[18:51]  * NCommander REJECTs persia's sense of humor
[18:51] <NCommander> sebner, I'll help as well
[18:51] <NCommander> I'm in a sponsoring mood
[18:51] <persia> sebner, When I finish this one.
[18:51] <sebner> GREAT
[18:52] <NCommander> sebner, link?
[18:52] <sebner> Mostly I try to convince the uploader aka upstream to fix the source files because of license headers ^^, but if you find any other issues I'm happy
[18:52] <iulian> james_w: Thanks again.
[18:52] <sebner> NCommander: http://revu.ubuntuwire.com/details.py?package=netactview
[18:52] <james_w> iulian: thank you
[18:54] <nxvl> NCommander: pong
[18:55] <sebner> nxvl: ping!
[18:55]  * nxvl hides
[18:55] <nxvl> sebner: i lost your bug
[18:55] <nxvl> sebner: can you please resend the bug number
[18:55] <NCommander> nxvl, I need an SRU ack
[18:56] <nxvl> NCommander: bug number
[18:56] <sebner> nxvl: What about a cronjob that sends you a daily email reminder? :D :D :D
[18:56] <nxvl> sebner: :D
[18:56] <nxvl> sebner: last week has been really busy
[18:57] <nxvl> but since i've national holiday from Thu i will have time for you
[18:57] <nxvl> :D
[18:57] <NCommander> nxvl, https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/drgeo/+bug/257797
[18:57] <sebner> nxvl: well sounds great but to me it seems that sebner has priority low and others high :P
[18:57] <fabrice_sp> james_w: Hi. About bug #298286
[18:58] <james_w> hi fabrice_sp
[18:58] <guest22> A question for REVU admins: I uploaded a package update to REVU yesterday, but it still hasn't shown up. Any suggestions?
[18:58] <slytherin> guest22: have you ever logged in to revu?
[18:58] <fabrice_sp> I'm the upstream maintainer of packaging for Ubuntu, and the versions has been added by Christian Marillat
[18:59] <nxvl> sebner: for NCommander is easy, just build test and ACK, patches review are harderd
[18:59] <nxvl> harder
[18:59] <persia> guest22, which package?
[18:59] <fabrice_sp> james_w: that's why I know that versions are not mandatory (and also, I published the package since gutsy in sourceforge repository)
[18:59] <guest22> slytherin: Yes, I'm currently logged in.
[18:59] <nxvl> sebner: and if security vulnerabilities included, is worst
[18:59] <guest22> persia: xnav
[19:00] <sebner> nxvl: hehe, ok ok. don't worry. I'm just happy you are still interested ;P
[19:00] <NCommander> nxvl, er, what?
[19:00] <nxvl> sebner: for all 3/4 releases it's needed QA, rebuild, PoC and such
[19:00] <guest22> persia: see http://revu.ubuntuwire.com/details.py?upid=2442
[19:00] <slytherin> guest22: did you login before uploading the package? The thing is that your GPG public key will get imported from launchpad to REVU on first login.
[19:00] <nxvl> NCommander: is just ONE release
[19:00] <nxvl> NCommander: not much work
[19:00] <fabrice_sp> james_w: so should I put a justification of removing required versions in changelog?
[19:00] <NCommander> nxvl, I have a second ack for you
[19:01] <james_w> fabrice_sp: I don't see why that is justification
[19:01] <nxvl> sebner: also, i was hoping you to become a MOTU and stop pinging me :P
[19:01] <slytherin> guest22: oh, so you mean your latest upload has not appeared on revu, right?
[19:01] <persia> guest22, I see the reject.  What's your LP ID?
[19:01] <NCommander> nxvl, https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/open-vm-tools/+bug/278711
[19:01] <guest22> slytherin: Yes, correct.
[19:01] <sebner> nxvl: well, my application was sent 12 days ago ;-D, MOTU != SRU :P
[19:02]  * NCommander wishes he was a member of SRU so he could ACK himself
[19:02] <guest22> persia: Strange, the dput seemed to succeed without any errors. LP ID is 186922.
[19:02] <nxvl> NCommander: k, i will check them at night
[19:02] <NCommander> ;.;
[19:03] <nxvl> now i need to fight with FF
[19:03] <NCommander> FF?
[19:03] <fabrice_sp> james_w: this package is already working in old versions of Ubuntu, without that high required version, and in my ppa, I have the version built on Hardy and Intrepid without required versions and they are working
[19:03] <persia> guest22, https://launchpad.net/~186922 is 404.
[19:03] <handschuh> slytherin: uiflite-package: I talked to the upstream-author and he refuses to release the package seperatly
[19:03] <fabrice_sp> james_w: the problem with that versions is that it makes harder to backport the package
[19:04] <james_w> fabrice_sp: why did Christian add them then?
[19:05] <guest22> persia: Sorry, I don't understand. I see the bug status at https://bugs.launchpad.net/ubuntu/+bug/186922 .
[19:05] <slytherin> handschuh: personally, I would not want the package to enter archives in such case. But talk with other people to see what they say. Add comment on revu about the discussion we had and upstream's response.
[19:05] <persia> guest22, Right.  I need to know who *you* are, not which bug :)
[19:06] <fabrice_sp> james_w: because the debian packager of this package (not Christian, but the original one) had hard time to find a stable version of ffmpeg basically. But in Ubuntu, ffmpeg versions are stable
[19:06] <slytherin> guest22: what was the dput command you used?
[19:06] <james_w> fabrice_sp: ok, that's more of a reason
[19:07] <guest22> slytherin: dput revu xnav_0.04-0ubuntu1_source.changes
[19:07] <guest22> persia: You need the maintainer email or GPG id?
[19:07] <slytherin> guest22: try - dput -f revu xnav_0.04-0ubuntu1_source.changes
[19:07] <handschuh> slytherin: -done-
[19:08] <persia> guest22, I need the launchpad login.
[19:08] <persia> slytherin, That won't help.  It's on REVU.  It was rejected.
[19:08] <guest22> slytherin: Done. As before, received message "Successfully uploaded packages", so no different from last time.
[19:08] <fabrice_sp> james_w: ok. So if I put that comment (dependencies not needed as ffmpeg versions are stable) in the changelog, it would be ok?
[19:09] <fabrice_sp> james_w: (or similar)
[19:09] <slytherin> persia: I always use -f with revu
[19:09] <guest22> persia: Launchpad login is bwohlberg
[19:09] <james_w> fabrice_sp: I think so, I'd appreciate a comment from siretart
[19:10] <guest22> persia: Is this related to the recent (at least, since the last time I uploaded anything) unification of revu and launchpad logins?
[19:10] <persia> slytherin, That only helps when it doesn't say "upload successful"
[19:10] <persia> guest22, It may well be.  Have you combined your accounts on the REVU website?
[19:10] <fabrice_sp> james_w: ok. In the meanwhile, I'll put back quilt and fix the changelog
[19:11] <fabrice_sp> also, for siretart, I've uploaded a new version of DVDStyler in revu ;-)
[19:11] <guest22> persia: yes, I have. Latest upload just showed up. Did you fix something?
[19:12] <persia> guest22, I've been poking things, but hadn't yet confirmed enough to fix.  Maybe a combination of what I've done and the reupload.
[19:12] <guest22> persia: Anyway, seems to be OK now, thanks for the help.
[19:12] <persia> In future, it's just one command for me to simulate the reupload, which may save you bandwidth.
[19:14] <guest22> persia: Noted. While I'm here, I have a question about another launchpad bug (https://bugs.launchpad.net/ubuntu/hardy/+source/photoml/+bug/243791). It hasn't received any attention for a *long* time: is there somewhere I can make a request for it to be reviewed?
[19:15] <slytherin> guest22: the bug status is 'fix released'
[19:15] <persia> guest22, It says it's fixed.  Shouldn't need any more attention.
[19:17] <guest22> slytherin: It's fix released in Intrepid, but there's also a request for an update to be released in Hardy, which has status New/Undecided
[19:17] <guest22> persia: see response to slytherin.
[19:18] <persia> Oh.  Just needs someone to backport the fix from Intrepid, and present to the SRU team then.  Waiting on a volunteer.
[19:19] <guest22> persia: I've already uploaded a deb diff for Hardy. Is that what you're referring to, or do you mean it's waiting for someone to construct the backport using the debdiff?
[19:19] <persia> binarymutant, I couldn't find a strong enough reason to reject charm, but I did find another minor issue.  Take a look, and if you want to fix that (and the one NCommander found), I'll happily ACK the result.  If not, I'll push.
[19:19] <persia> guest22, Did you subscribe the relevant SRU team?
[19:19] <guest22> persia: Yes: MOTU Stable Release Updates
[19:20] <guest22> persia: Is that not correct?
[19:20] <NCommander> persia, what was it?
[19:21] <persia> guest22, That's all correct.  I wonder why it didn't get attention.  In that case, complain for an SRU review.
[19:22] <guest22> persia: Where do make the request for an SRU review?
[19:22] <binarymutant> thanks persia
[19:23] <persia> guest22, Well, on LP, but if that didn't work, ask here.
[19:23] <guest22> persia: OK, will do. Thanks again.
[19:23] <persia> binarymutant, Just let me know which soonish, as I'm headed out in a bit.
[19:24] <guest22> Any SRU members here? Coud you please take a look at bug https://bugs.launchpad.net/ubuntu/hardy/+source/photoml/+bug/243791
[19:25] <binarymutant> persia, as for 2: what do you mean should include the GPL paragraphs as instructed by the GPL?
[19:28] <persia> binarymutant, There's a section in the GPL entitled "How to use the GPL" that expects a couple paragraphs to be in each source file.  The current source only says "This is GPL".  Since the GPL is included in the tarball, this is fairly obvious, but still a minor issue.
[19:30] <binarymutant> okay I'll contact upstream about that, as for 1: should it just be the path and nothing else? since that particular version of dpatch hasn't been released in ubuntu yet
[19:34] <siretart> fabrice_sp: james_w: hi. I notice you've hilighted me regarding ffmpeg? what's up?
[19:39] <directhex> siretart, it's full of patents and you're a bad human being? ;)
[19:39] <directhex> hm. is there a righ thing to do with expired, incomplete bugs?
[19:40] <persia> binarymutant, I'd put something like "This package uses dpatch for patch management.  See /usr/share/doc/... for details".
[19:40] <james_w> hi siretart, now are you?
[19:40] <binarymutant> thanks persia
[19:40] <persia> Oh, if that dpatch isn't in Ubuntu, it's harder.
[19:40] <james_w> siretart: we were discussing bug #298286. fabrice_sp said that it doesn't need versioned B-D on ffmpeg stuff due to Ubuntu having a stable ffmpeg.
[19:43] <persia> binarymutant, Do you expect that version of dpatch to be in Jaunty?
[19:44] <binarymutant> persia, I think jmarsden said that 2.0.30 would be in jaunty but I'm checking right now
[19:45] <binarymutant> it is
[19:45] <slytherin> persia: can you please confirm bug 298400 and add comments if any. Iwill try to submit a debdiff tomorrow.
[19:47] <persia> slytherin, That should make most things build with the JDK for the arch, rather than with gcj, right?
[19:48] <slytherin> persia: right. in our case it will be mostly openjdk as usually java packages are arch:all
[19:49] <persia> slytherin, Right, and since OpenJDK is becoming the default environment on a steadily increasing set of architectures, that should only be to our benefit.
[19:51] <slytherin> persia: yes.
[19:55] <eMerzh> sorry to insist, but if someone could look at (http://revu.ubuntuwire.com/details.py?package=sqliteman) i would be very glaaaad to correct eventual errors
[19:57] <fabrice_sp> siretart: and also saying that I've uploaded an updated version of dvdstyler in revu (http://revu.ubuntuwire.com/details.py?package=dvdstyler) :-)
[20:08] <kumy> hi all, can someone help me to understand what's my problem with lintian. when I run $ lintian -I frogd_1.0-0ubuntu1.dsc
[20:08] <kumy> I: frogd source: no-complete-debconf-translation ... what should be translated in my dsc??? mok0 you know about my package, do you have any hint ?
[20:10] <kumy> -Kmos-, i'll try that
[20:10] <directhex> hm. try and patch usplash, or finish a bottle of whisky.
[20:10] <slytherin> kumy: your package probably presents a question to user and that is not translated.
[20:11] <siretart> james_w: sorry, my laptop crashed and then I went off for dinner
[20:12] <james_w> siretart: no problem
[20:12] <siretart> james_w: thanks, I'm more or less fine. Swamped with day-job work pretty badly. I barely find time to do any merge :(
[20:13] <siretart> fabrice_sp: regarding the patents issues in ffmpeg, I think we worked out a pretty usable compromise. still I think we make way to much fuss about that topic. still waiting for the TB to respond on this issue though
[20:14] <siretart> james_w: fabrice_sp: regarding the package: there is no such thing as a 'stable' ffmpeg.
[20:14] <jdong> siretart: no TB response on the codec patent issue yet?
[20:14] <siretart> fabrice_sp: the versioned build-depends have nothing to do with stability. it marks which version of ffmpeg is required to build the package. removing it removes information which backporters help to decide if a package can or should be backported
[20:15] <fabrice_sp> siretart: I know ffmpeg is not a stable package, but at least, the ubuntu package is more stable than the one made by Christina Marillat
[20:15] <fabrice_sp> siretart: in this case, the version of ffmeg that ubuntu ships are fine
[20:15] <siretart> jdong: no, unfurtunately not. collin suggested that we can enable the h261 encoder, which we now have in jaunty though. yay
[20:15] <siretart> fabrice_sp: please define 'stable'
[20:16] <fabrice_sp> this codec patent issue also affect mpeg2 encoding?
[20:16] <jdong> siretart: interesting :) I would expect the decision to be either (A) Ubuntu cares about software patents (B) Ubuntu doesn't.
[20:16] <jdong> fabrice_sp: all MPEG2+ codecs are covered by active patents, yes.
[20:16] <fabrice_sp> in my case, I can encode a DVD, that plays fine
[20:16] <siretart> in any case, your changelog entry is false. it really has nothing to do with stability
[20:16] <siretart> jdong: it's not as easy as that. we need to look at the issue more closely than that
[20:17] <jdong> fabrice_sp: if you look at a distro like, say, OpenSuse, which cares about patents in the USA where it operates, literally the only thing libavcodec supports is the fully Free formats :)
[20:18] <siretart> jdong: AFAIUI, for everything in ffmpeg (except AAC and MP3) there is no difference between shipping encoders or decoders. so I don't see the problem why we really need to exclude the h263 encoder
[20:18] <fabrice_sp> siretart: ok, so I just change it to the original one (deleted required versions of lib..), it's ok?
[20:18] <siretart> jdong: as for mp3, ffmpeg doesn't support mp3 anyway, but uses libmp3lib for that. AAC is a way more interesting issue
[20:18] <fabrice_sp> I really thought that -unstripped verison of libavcodec was created because of patent issues
[20:19] <jdong> siretart: right, that's how I understand it too. Except for AAC where the playback is "royalty-free" for "some time", but both MP3 and AAC's encoder+decoder patent encumberance isn't GPL-compatible
[20:19] <jdong> siretart: I've always found it a bit strange that we feel okay about shipping the decoders but not the encoders
[20:19] <siretart> fabrice_sp: that's right. to work around the current ubuntu licensing policy. as indicated, I've notified the TB and am still awaiting a decision
[20:19] <kumy> slytherin: hum... all seems to be fine now... I deleted all the generated packages and tryed again, now it works fine... sorry for disturbing
[20:20] <jdong> it seems like most other distros with dedicated legal depts try to stay away from support for encoding or decoding the encumbered formats
[20:20] <siretart> fabrice_sp: jdong: james_w: if anyone of you is at the next UDS, please raise that issue with members of the TB and the archive-admins
[20:20] <siretart> jdong: like gentoo or mandriva? both ship a uncrippled ffmpeg for years!
[20:21] <jdong> siretart: :) Prime examples :D
[20:21] <jdong> I was thinking like RedHat or Novell
[20:21] <siretart> that's another story.
[20:21] <siretart> the key difference is that both sell boxed versions of their distribution
[20:21] <jdong> Gentoo I guess has an interesting side... they don't technically "ship" anything :)
[20:21] <james_w> siretart: I am, but I am not comfortable enough with the issues to do so, sorry.
[20:22] <siretart> the MPEG LA charges for 'sold units'. neither ubuntu nor debian 'sell' units of ubuntu
[20:22] <siretart> neither does debian, btw.
[20:22] <directhex> debian doesn't sell units of ubuntu? :o
[20:22] <jdong> well even back when they had separate downloadable versions that are NOT sold, this was the case too.
[20:22] <siretart> james_w: they also have a mirror network for their distfiles. of course they distribute the stuff. I'm pretty confident that they even distribute binpkgs of ffmpeg
[20:23] <jdong> can we really safely say we don't sell any units of Ubuntu hence we don't have to pay the royalty?
[20:23]  * jdong is obviously a legal idiot
[20:23] <siretart> I wouldn't sign that statement, but you now get the impression why I say it's not as easy as that
[20:23] <siretart> you have to look pretty closely at the matter
[20:24]  * directhex declares free software illegal in the principality of sealand, expects all distrtos to close their doors by attempting to follor the wules of every country everywhere at once
[20:24] <fabrice_sp> actually, 32 packages rdepend on -unstripped versions of libavcodec, so these are 'riskies' app, then
[20:25] <siretart> fabrice_sp: look more closeley. they depend alternatively on the -unstripped versions
[20:25] <fabrice_sp> also, that mean that the dvdstyler package won't be accepted in Ubuntu, until this issue has been solved?
[20:26] <siretart> in anycase. WTF is wxsvg NOT IN DEBIAN?!
[20:26] <directhex> siretart, because you haven't packaged it yet?
[20:26] <handschuh> slytherin: you are a debian developer, right?
[20:26] <siretart> directhex: marillat obviously did package it.
[20:26] <fabrice_sp> because it's using libavcodec?
[20:27] <siretart> fabrice_sp: I didn't say anything about dvdstyler. whats the matter with it?
[20:27] <directhex> siretart, i've been less than impressed by marillat's packaging. does that sound harsh? he does important work conceptually, but... well... time for him to run through REVU
[20:28] <fabrice_sp> siretart: it's a package that I uploaded in revu, and you made a comment some time ago. I uploaded a new version, but it depends on -unstripped libavcodec to encode in mpeg2
[20:28]  * fabrice_sp agree with directhex
[20:29] <siretart> fabrice_sp: okay. in that case I'd suggest that you install an shlib.local file so that the binary package correctly depends in libavcodec-unstripped-52
[20:29] <siretart> and get that to multiverse
[20:29] <directhex> i don't think there was a single usable file in his moonlight package... mmmmhmmmmm... perhaps debian/compat was okay
[20:30] <siretart> forget his packaging.
[20:30] <fabrice_sp> siretart: ok.  Anyway, it should be the case of all dvd app's that are encoding in mpeg2, right?
[20:30]  * siretart points to http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2008-November/002221.html
[20:31] <siretart> fabrice_sp: at least for now, yes. Things may change if we find a better solution, but for now, that's the best I've come up with
[20:32] <siretart> I agree that our packaging pretty sophisticated. I can everyone just recommend to have a look at ffmpeg-debian's debian/rules file and compare it to marillat's version :-)
[20:32] <fabrice_sp> siretart: ok. For the moment, will update dvdstyler
[20:33] <siretart> and help would be more than welcome on that!
[20:33]  * siretart points to http://svn.debian.org/viewsvn/pkg-multimedia/experimental/ffmpeg-debian/debian/rules?rev=1549&view=auto
[20:35]  * fabrice_sp had some fights with ffmpeg to understand why dvdstyler was coredumping in Intrepid, until I discovered -unstripped libraries :-)
[20:36] <NCommander> directhex, ping
[20:37] <directhex> pang!
[20:38] <siretart> btw, jaunty has bumped SONAME on libavcodec51->libavcodec52. also the API has changed a bit I think.
[20:39] <siretart> I wondered why libavcodec51 hasn't been removed yet from jaunty
[20:39] <directhex> siretart, and debian?
[20:42] <siretart> directhex: in experimental. not unstable/lenny.
[20:43] <fabrice_sp> james_w: about the versions: the ones provided in debian/control of wxsvg are not usable (it's a too high for Jaunty), so they have to be changed
[20:43] <fabrice_sp> (speaking of bug #298286)
[20:44] <directhex> siretart, that's okay. we're planning on uploading, well, 50 would be a conservative estimate on the number of source packages heading for experimental from the three pkg-mono teams
[20:44] <directhex> unless lenny jumps out of the door pronto
[20:44] <NCommander> directhex, does that include a new mono version?
[20:45] <directhex> NCommander, oh yes. that's stuck in NEW right now
[20:45] <NCommander> argh
[20:45] <directhex> NCommander, well, a 2.0 package is. we have 2.0.1 ready to upload once NEW is over with - and upstream handed us some 2.2 preview tarballs today
[20:45] <NCommander> directhex, I'm currently working to get the current mono building on armel
[20:45] <NCommander> (glibc issues, nothing mono specific AFAIK)
[20:46] <directhex> NCommander, that would be very welcome news. can you try with 2.0, see if it makes a diff?
[20:46] <NCommander> Wait, what?
[20:46] <NCommander> Oh
[20:46] <NCommander> Link to the package?
[20:47] <NCommander> directhex, ^
[20:47] <directhex> well, NEW means NEW means 'not for you, peasant'. http://svn.debian.org/viewsvn/pkg-mono/mono/trunk/debian/ though
[20:47] <siretart> fabrice_sp: if wxsvg is the same quality as the average marillat package, I'd suggest to not sync it but repackage it properly. However I did NOt investigat it yet at all
[20:48] <siretart> directhex: sounds fun!
[20:48] <directhex> man, everyone's being mean to christian tonight
[20:48] <directhex> NCommander, feed it http://ftp.novell.com/pub/mono/sources/mono/mono-2.0.1.tar.bz2
[20:48] <NCommander> directhex, when do you expect to be uploading :-/
[20:49] <fabrice_sp> siretart: that's my point: why do we need to merge from a non official debian source? For me, it sounds more logical to do it from 'scratch'
[20:49] <directhex> NCommander, when NEW finishes mucking about. which, knowing the secret cabal, is another 3 weeks. which is gonna totoally screw with the timing for my jaunty work. ho hum
[20:49] <NCommander> so fix the version in jaunty presently, then try this one
[20:50] <NCommander> Is that what your telling me? ;-)
[20:50] <NCommander> We're getting a nice backup of FTBFS due no mono period.
[20:51] <directhex> NCommander, armel isn't on the mono arch list right now is it?
[20:51] <NCommander> It is
[20:51] <directhex> wait, yes, it is
[20:51] <NCommander> I dunno how stable mono on armel is however
[20:52] <directhex> hang on, why does it FTBFS? it's built in  sid
[20:52] <NCommander> glibc mismatch
[20:52] <directhex> http://ftp.es.debian.org/debian/pool/main/m/mono/mono-jit_1.9.1+dfsg-4_armel.deb
[20:52] <NCommander> We have a newer glibc
[20:52] <NCommander> mono's prototypes and glibc's headers are having a disagreement
[20:52] <NCommander> This happens all the time on port architectures :-)
[20:52] <directhex> urgh. well, patches more than welcome in that case
[20:52] <NCommander> ARM is great
[20:52] <NCommander> I actually get to show normal devs what porting is like
[20:52] <NCommander> WOOO
[20:53] <directhex> anything that doesn't break on older glibc is a bonus
[20:53] <NCommander> Yeah
[20:55] <directhex> you still have a little bit of time to get into 1.9.1-5 and lenny ;)
[20:57] <NCommander> directhex, it looks like the ARM arch dependent code is what self-destructed
[20:57] <NCommander> Probably a safe bet its still broken on 2.x
[21:09] <NCommander> directhex, I'm looking at the 2.0.1 tarball, the same code I had to change to fix mono on Ubuntu ARM hasn't changed, so the same patch will have to be applied
[21:09] <NCommander> directhex, my patch is backwards compatible with older glibcs
[21:11] <directhex> NCommander, fantastic. reportbug it please :)
[21:11] <NCommander> Let me wait for this to finish building, make sure we have no more suprises
[21:11] <NCommander> (unlikely, but better safe than sorry)
[21:12] <directhex> NCommander, it only modifies the arm_mini.c (or whatever it's called) files, no risk ot affecting other arches?
[21:12] <NCommander> actually arch/arms/tramps.c, but yeah
[21:12] <joaopinto> is patches/00list required for the cdbs patchsys ?
[21:13] <RainCT> joaopinto: nope
[21:13] <directhex> joaopinto, no, but cdbs is sick filth
[21:13] <laga> oh? someone who doesn't like cdbs?
[21:13] <joaopinto> erm, I got an erroneous review :\
[21:13] <joaopinto> didrocks, don't agree, I love cdbs
[21:13] <RainCT> joaopinto: from a MOTU?
[21:14] <joaopinto> http://revu.ubuntuwire.com/details.py?package=amoebax
[21:14] <directhex> laga, cdbs is fine as long as you never need to make changes to how it thinks reality should be. veer off the straight and narrow, and it becomes doom
[21:15] <RainCT> joaopinto: well, it's her pre-breakfast look :P
[21:15] <directhex> this is where you say "we use it for mythtv and it's fine"
[21:15] <joaopinto> directhex, cdbs tries to address a majority of build cases, and does it quite good
[21:17] <RainCT> Hobbsee: I've given you Reviewer status on REVU, which I've just seen you hadn't, and removed that comment from amoebax so that it doesn't move it down to "needs work"
[21:17] <joaopinto> can someone advocate the amoebax package ?
[21:18] <ajmitch> joaopinto: I'm guessing it was because of your misleading use of a .dpatch suffix for the patch
[21:18] <joaopinto> ajmitch, thatwas not me, I have just provided the name, edit-patch decided to use dpatch
[21:18] <csilk> Is it necessary to have menu icons/shortcuts and desktop files in a a new package or is it ok for the initial release to be command line launched?
[21:18] <ajmitch> either way, I'd probably suspect the same thing at a glance, before breakfast :)
[21:19] <ajmitch> and before caffeine
[21:19] <joaopinto> :D
[21:19] <joaopinto> csilk, if its a desktop app, it should be started from the menu
[21:20] <csilk> In that case do you know of any good ubuntu docs on desktop files?
[21:20] <csilk> I've searched the wiki but there doesn't seem to be much on that topic
[21:20] <joaopinto> hum, Hobbsee is right, the patch is not being applied
[21:20] <RainCT> csilk: https://wiki.ubuntu.com/MOTU/Packages/DesktopFiles, http://standards.freedesktop.org/desktop-entry-spec/latest/
[21:21] <joaopinto> hum there is something odd, with 00list is not applied either
[21:21] <RainCT> joaopinto: 00list is definitely not used by cdbs simple-patchsys
[21:22] <RainCT> joaopinto: the problem is the file's extension
[21:22] <RainCT> joaopinto: it should be .patch, not .dpatch
[21:22] <csilk> Thanks RainCT
[21:22] <RainCT> csilk: or easier, just look at some existing file, imitate it, and then run desktop-file-validate on it to find the errors that it very likely will have :P
[21:22] <joaopinto> hum, let me redo the patch, if cdbs edit patch decided to provide .dpatch, there is a bug
[21:23] <RainCT> joaopinto: cdbs-edit-patch gives it the name you tell it :P
[21:24] <csilk> RainCT, sounds like a plan, thanks.
[21:24] <joaopinto> Please make the changes necessary for the patch 02-desktop-fix.patch
[21:24] <joaopinto> looks good now
[21:25] <joaopinto> Trying patch debian/patches/02-desktop-fix.patch at level 1 ... success.
[21:25] <joaopinto> ok, it's working now
[21:25] <csilk> Another question, I'm not sure how to handle source taken from cvs, how do I remove all the cvs specific files and dirs in a sane standard way before packaging?
[21:26] <RainCT> csilk: iirc,    find -type d -max-depth=1 | grep 'CVS' | xargs rm -r
[21:26] <RainCT> csilk: try it without the   xargs rm -r   first
[21:27] <RainCT> err, and without the -max-depht=1
[21:27] <joaopinto> why not find -type d -name "CVS" ?
[21:27] <csilk> RainCT, so I'm basically just rm'ing the cvs stuff?
[21:27] <joaopinto> -exec rm ?
[21:27] <RainCT> csilk: yep
[21:28] <RainCT> joaopinto: that'd be an option, too :)
[21:28] <csilk> I assumed there would be some standard MOTU prefered way
[21:28] <csilk> cool, rm it is
[21:28] <joaopinto> that grep is not that save, there could be a "MyCVSgame" dir :P
[21:28] <joaopinto> safe
[21:28] <csilk> I'll manually check if I miss anything with the grep
[21:28] <RainCT> joaopinto: then we should hit the guy who gave it that name *g*
[21:29] <joaopinto> csilk, find . -type d -name "CVS" -exec rm -r {} \;
[21:29] <joaopinto> csilk, there is no need to check, find does not fail
[21:30] <csilk> thanks
[21:36] <joaopinto> amoebax was reuploaded with the s/dpatch/patch
[22:32] <ryanakca> I'm patching sources with cdbs-edit-patch ... is there a stock README.source in another package that I could just copy over?
[22:32] <RainCT> ryanakca: There is. (But I don't know where.. /me doesn't like this new README.source nonsense :P)
[22:35] <ryanakca> RainCT: *nod*... imho, if you want to build the sources yourself, either a) you installed something to build them and our packaging will work like magic, or b) you're compiling by hand, and smart enought to use GNU patch
[22:35] <RainCT> ryanakca: well, it's for other Maintainer to know how they are supposed to modify your package
[22:36] <RainCT> ryanakca: but, except for some special cases, that is just obvious or can be found very easily
[22:36] <ryanakca> RainCT: ah... *nod*
[22:36] <RainCT> I mean, why would you want to include information about how to use cdbs-edit-patch in every damn package? :P
[22:36] <RainCT> (and then, what if the syntax for it changes? :P)
[22:36] <ryanakca> does it get installed to /usr/share/doc/<foo>/ ?
[22:38] <RainCT> ryanakca: nope
[22:38] <ryanakca> Wouldn't that cause a pile of redundant README's ? Wouldn't it not be better off to stick right in the new maintainer's manual that if you see ``quilt'' in the depends, or the <foo patchsys> rule in debian/rules, you should read that man page?
[22:38] <ryanakca> ah, ok...
[22:38] <ryanakca> I see see. I don't get the use, but complaining won't change anything either... *starts hunting* :)
[22:39] <RainCT> Yeah.. Not sure if including that file is a "must" or a "should" in the Policy, but I'm not following it.. I only have it in one package, and because my sponsor wanted it :P
[22:40] <ryanakca> RainCT: I'm trying to update the aoeui package in Debian... and... well... same situation :)
[22:41] <RainCT> Actually, I thought Policy is menat to reflect the "common use". I have seen less than 5 packages having such a file, so I dunno from where that rule came from :P
[22:42] <RainCT> «If running dpkg-source -x on a source package doesn't produce the source of the package, ready for editing, and allow one to make changes and run dpkg-buildpackage to produce a modified package without taking any additional steps, creating a debian/README.source documentation file is recommended.»
[22:42] <RainCT> so it isn't necessary :)
[22:43] <eMerzh> RainCT,or everyone else... if you are in a reviewing moood....please considere to have look to ( http://revu.ubuntuwire.com/details.py?package=sqliteman ) Thanks a lot for your patience :)
[22:43] <RainCT> ryanakca: btw, is it you who blogged about dvorak *lots* of time ago on planet.ubuntu.com? :P
[22:43]  * ryanakca is reading http://www.mail-archive.com/debian-policy@lists.debian.org/msg22445.html
[22:43] <ryanakca> RainCT: most likely
[22:43] <ryanakca> RainCT: but... my blog went kaput... so I lost most of my articles...
[22:44] <RainCT> ryanakca: Then you almost convinced me that dvorak is cool :P. But I don't feel like learning to type again :P
[22:44] <RainCT> ryanakca: one thing I wonder.. do you have any problems switching between QWERTY and Dvorak?
[22:45] <ryanakca> RainCT: doesn't take that long... get yourself a long english essay / <random course> project to type, change the keyboard map and print off one of those tent references off of dvzine.org ... dvorak7min helps too
[22:46] <ryanakca> RainCT: Yes... well... for the first 30s - minute... kindof confusing... but after that no problem...
[22:47]  * RainCT (re, Debian.sources) isn't against the 6 lines boilerplate text telling where the docs for the patch system are, btw, but thinks that reproducing them entirelly is plainly stupid
[22:47] <ryanakca> I find typing with QWERTY for long stretches of time uncomfortable now... might just be because the keyboards / desks at school way too high to be good for anybody's wrists
[22:47] <RainCT> heh
[22:48] <RainCT> ryanakca: I shall try it out some day :)
[22:48] <RainCT> perhaps next summer :P
[22:48] <ryanakca> Anyways... cdbs-edit-patch doesn't have a /usr/share/doc/quilt/README.source ... methinks it would be easier to just switch to quilt than to draft one up myself....
[22:49] <RainCT> ryanakca: file a bug :P
[22:49] <ryanakca> doesn't have an equivalent of...
[22:49] <ryanakca> *nod*... in Debian I suppose, and then link to it from LP?
[22:50] <RainCT> ryanakca: Yep, in Debian (package is cdbs)
[22:50] <ryanakca> ok, will do :)
[22:50] <RainCT> thanks
[22:52] <ryanakca> Hmmm... ``no patch has documentation (see dpatch template)''... is that for in the changelog or in the patch itself? And where can I find said dpatch template? Would it be this line at the end of the dpatch(1) ? dpatch patch-template -p "01_some_patch" "A random patch" <random.diff >debian/patches/01_some_patch.dpatch
[22:55] <RainCT> ryanakca: EMENOTUNDERSTAND :P
[22:56] <ryanakca> RainCT: *sigh*, no do I... I'll send a reply off to my sponsor :)
[23:03] <sjdurfey> whenever i suspend my computer, and bring it out of suspension, i cannot get my wireless connection to come back on, even if i try to manually bring it back up, is there a fix for this?
[23:07] <directhex> depends on the wireless driver
[23:08] <sjdurfey> how do i figure out which driver it is?
[23:08] <directhex> right click on the network manager icon, connection information
[23:09] <directhex> it tells you
[23:09] <kumy> mok0: i've uploaded an updated version of frogd, could you review it when you have spare time?
[23:09] <sjdurfey> driver: rt61pci
[23:21] <RainCT> ryanakca: btw, I suppose Dvorak also works fine with non-US keyboards?
[23:22] <directhex> sjdurfey, i think "known bad" drivers are generally unloaded on suspend then loaded on resume
[23:23] <directhex> sjdurfey, i don't know the mechanism for it though
[23:23] <sjdurfey> is that know bad driver?
[23:25] <RainCT> ryanakca: or rather, does it support special chars (like ç)?
[23:25] <sjdurfey> wow, i certainly mistyped that, haha "is that a known bad driver?"
[23:35] <RainCT> ryanakca: nevermind, found it :)
[23:49] <RainCT> well, i'm off
[23:49] <ryanakca> RainCT: use the us dvorak-intl map
[23:50] <ryanakca> and, g'night :)
[23:54] <RainCT> ryanakca: yep, I'm using the Spanish one right now :)
[23:55] <ryanakca> :)
[23:56] <lfaraone> which is better for a beginnger: CDBS, or debhelper?
[23:56] <RainCT> ryanakca: and typing damn slow :P
[23:57] <RainCT> well, see ya!
[23:57] <ryanakca> RainCT: is it a variant of the english layout, or is it a completely new map?
[23:57] <ryanakca> See ya