[00:00] <mok0> mrooney: don't worry about it
[00:10] <mrooney> mok0: ahh I see, those are the individual debs for each arch?
[00:19] <mok0> mrooney: yes, they need to be approved too
[00:19] <mrooney> I see, how glorious
[00:20] <mrooney> I should start checking out other needs-packaging requests when I have time
[00:20] <mrooney> is that a good place to start MOTU contributions?
[00:22] <mok0> mrooney: yes packaging from scratch is good, but so is doing bug-work
[00:23] <mok0> mrooney: the current trend is to move focus away from packaging-new-packages to maintaining what we have
[00:24] <mok0> mrooney: merges, syncs...
[00:24] <mrooney> ahh okay, I guess I should learn about harvest more, that would help in finding bugs and patches and such?
[00:24] <mok0> mrooney: getting -0ubuntu* packages into Debian
[00:25] <mrooney> yeah also that, is there a guide for getting an ubuntu package into Debian? I haven't been able to find one on my own
[00:25] <mok0> mrooney: yes that should be an important part of your application
[00:25] <mok0> mrooney: you should maintain a MOTU diary so you can keep track of what you've done
[00:26] <mrooney> ahh okay, I guess I can blog and tag them with 'motu'
[00:27] <vorian> mok0: thanks for reviewing all those plasmoids <3
[01:06] <dolanor> back
[01:07] <dolanor> mok0: updated the hexdiff package with your comments solved :)
[01:07] <dolanor> http://revu.ubuntuwire.com/p/hexdiff
[01:07] <mok0> dolanor: great
[01:08] <mok0> vorian: you're welcome :-) ScottK owes me now
[01:08] <mok0> vorian: or you perhaps  8)
[01:11] <vorian> :)
[01:24] <xoox> How can I automatically backport a package that requires many (backported) dependencies?
[02:01] <rhpot1991> hey guys question about debian/watch file, I made this code just for ubuntu and its host on bzr, do I need a debian/watch file?
[02:02] <lifeless> rhpot1991: yes, at this point
[02:02] <lifeless> rhpot1991: because, there are automated tools that read the package and look for updates
[02:03] <rhpot1991> lifeless: any way for it to play nice with bzr?
[02:03] <lifeless> rhpot1991: not yet, though I'm sure patches would be appreciated :)
[02:03] <lifeless> james_w: which reminds me, upstream integration++
[02:03] <nhandler> You can also use a get-orig-source rule which might work better with bzr
[02:04] <lifeless> nhandler: good point
[02:04] <nhandler> I think there are some examples on the wiki about how to do that
[02:05] <rhpot1991> nhandler: you can do that within the watch file?
[02:05] <rhpot1991> I have that in my debian/rules already
[02:06] <nhandler> lifeless: Correct me if I'm wrong, but I do not think a watch file is a strict requirement. It is just recommend that you have a watch file *or* get-orig-source rule
[02:06] <rhpot1991> nhandler: its reported as a "wishlist" from lintian
[02:06] <lifeless> nhandler: I don't recall; I was wondering what REVU will say myself
[02:06] <lifeless> I'm also not sure what the automated analsis tools do
[02:07] <lifeless> do they try get-orig-source, or only look at watch
[02:07] <nhandler> lifeless: I know the REVU warning says get-orig-source or watch file
[02:07] <nhandler> lifeless: The stuff on qa.ubuntuwire only uses the watch files iirc
[02:07] <RAOF_> lifeless: The UEHS only looks at the watch file; bzr-buildpackage uses either.
[02:08] <nhandler> The issue with get-orig-source is that developers have different opinions about how it works. This means that it is not consistant accross all packages
[02:08] <lifeless> nhandler: when it even exists :P
[02:08] <RAOF_> Yes; that is annoying.
[02:08] <lifeless> it would be nice for watch to handle vcs *upstreams*
[02:09] <RAOF_> lifeless: Why?  Presumably there's a new upstream revision almost immediately.  Doesn't that make the watch file much less useful?
[02:09] <RAOF_> Hooray for capped internet.  apt thinks it'll be another hour before it's finished updating the package lists.
[02:09] <lifeless> RAOF_: I don't see why an upstream release branch would be any less frequent than an upstream tarball site
[02:10] <RAOF> That's not the normal case of VCS packaging, though.  I don't think I've ever touched a packaged-from-VCS package that pulled from a release branch.
[02:12] <lifeless> RAOF: maybe because we make packaging from VCS harder than it should be, so its only used with 'give me crack' packages
[02:12] <rhpot1991> this may be silly but how the heck do I get a file in the downloads section of my LP project then?
[02:13] <lifeless> RAOF: certainly some upstreams do daily tarballs and we tend to ignore those in watch files :P
[02:13] <lifeless> rhpot1991: there is an upload button in the series
[02:13] <RAOF> lifeless: Fair enough.  And having a nice, standard way to describe 'tarball is pulled from release branch' would be a step in that direction.
[02:14] <nhandler> RAOF: You can specify a vcs branch in debian/control
[02:14] <lifeless> rhpot1991: or I thought there was
[02:14] <lifeless> rhpot1991: ask on #launchpad :)
[02:14] <RAOF> nhandler: No, you're thinking of packaging-in-vcs, not packaging-of-vcs-upstream, right?
[02:14] <RAOF> rhpot1991: You first need to make a release, then you can upload to that release.
[02:15] <nhandler> RAOF: Right
[02:15] <RAOF> nhandler: Whereas we're talking about pulling the upstream source from a vcs branch.
[02:15] <nhandler> Yeah, I caught that after I sent the message
[02:17] <RAOF> Although, strictly speaking, I don't think you _can_ specify an (abritrary) branch in the VCS field; there's no format for git.
[02:21] <xoox> How can I automatically backport a package that requires many (backported) dependencies?
[02:21] <rhpot1991> thanks RAOF, lifeless
[02:21] <RAOF> xoox: You need to first backport the dependencies.
[02:22] <xoox> RAOF: That's not very practical is it?
[02:23] <nhandler> xoox:
[02:23] <nhandler> Are you sure all of the Dependencies need to be backported for it to work?
[02:23] <xoox> nhandler: Yes
[02:23] <RAOF> xoox: In what way is it impractical?
[02:25] <xoox> RAOF: There are many dependencies. I detest unnecessary work (backporting each package manually). Proof that the work is unnecessary is that other package managers do it automatically.
[02:26] <RAOF> xoox: Maybe you're talking about something different to what we think you are talking about.
[02:26] <RAOF> xoox: What is it that you actually want to do?
[02:27] <xoox> RAOF: I want to backport a package that has dependencies that need to be packported. If there a N packages in total I want to do 1 'manual' step, not N.
[02:27] <RAOF> xoox: What package?  What, exactly, do you mean by 'backport'?  Why do you need to backport the dependencies?
[02:28] <xoox> RAOF: It doesn't matter but the package is sagemath.
[02:28] <xoox> It is in jaunty I want it in Intrepid.
[02:29] <RAOF> Ok.  And what dependencies need backporting
[02:30] <RAOF> So, we are talking about the same thing.
[02:30] <xoox> I imagine all the math libs. But I guess that is the first problem. It seems I have to manually determine that (I shouldn't have to).
[02:30] <rhpot1991> "Warning! This package could not be extracted; there's no browseable directory for it on REVU"
[02:30] <rhpot1991> do I need to worry about that?
[02:31] <xoox> RAOF: We are talking about the same thing but seemingly have different expectations on how things should work.
[02:31] <RAOF> xoox: So, what I would do is take the Jaunty source package and try to build it in an Intrepid environment.
[02:31] <RAOF> xoox: If that works, great, no further backporting required.  If it doesn't, then we need to backport one or more dependencies.
[02:32] <RAOF> xoox: How would you expect this to work?
[02:32] <xoox> RAOF: package-builder sage-math -> fetches and builds all dependencies. Have you ever used pacman or emerge?
[02:33] <RAOF> No, and it's not a good fit for Ubuntu.
[02:33] <RAOF> I'm not sure why you'd want to (re)build all the dependencies.
[02:34] <xoox> RAOF: I'm talking about a very narrow feature (not the entire packaging system). When packaging dependencies should be retrieved and built automatically.
[02:34] <xoox> RAOF: I only want to rebuild the ones that need to be rebuilt.
[02:34] <RAOF> How do you determine the ones that need to be rebuilt?
[02:35] <xoox> RAOF: A first stab would be intrepid depends on version X and jaunty depends on version Y > X.
[02:35] <rhpot1991> if there are any motu's around this should be a pretty easy one: http://revu.ubuntuwire.com/details.py?upid=5082
[02:35] <nhandler> rhpot1991: I'll take a look
[02:35] <xoox> therefore package source needs to be fetched and rebuilt.
[02:36] <RAOF> xoox: Sounds like a prevu feature request.  You can probably provide a patch :)
[02:36] <rhpot1991> nhandler: thanks
[02:37] <xoox> Everytime I bring this up people seem to get defensive and 'apologist'. I can't understand why this doesn't appeal to anyone else.
[02:37] <RAOF> Because it's not something that we do a lot, and generally needing to backport dependencies rules out actually doing the backport.
[02:38] <RAOF> xoox: It might be a useful feature for prevu.  But it's just not very commonly useful, at least for us.
[02:39] <jdong> I've considerd that idea
[02:39] <RAOF> That's why it hasn't been implemented already.
[02:39] <xoox> jdong: And rejected it?
[02:40] <jdong> it's always failed in my imagination because I can think of and find in the repo, cases where it'd result in a chain of dependencies
[02:40] <jdong> a chain that will basically pull in half of Jaunty
[02:40] <jdong> the alternate approach I've considered is forcibly ignoring build-deps and seeing if the build fails
[02:40] <jdong> if not then good
[02:40] <xoox> jdong: A chain that wouldn't happen by manually backporting?
[02:40] <jdong> if so, then follow to next level of deps
[02:40] <jdong> and repeat.
[02:41] <jdong> xoox: a human backporter is assumed to be smarter at figuring out if a build-dep is serious or a transition-tool during development of the distro
[02:41] <rhpot1991> I see some typos on the details.py page, is there someone who I should alert about these?
[02:41] <jdong> I'm open to the above recursive level-by-level giving in of pulling build deps from Jaunty
[02:41] <jdong> but I'm not open to just-follow-the-build-deps-till-it-stops
[02:41] <jdong> there's something called dist-upgrade for that ;-)
[02:41] <nhandler> rhpot1991: The details.py page on REVU?
[02:42] <rhpot1991> nhandler: yes
[02:42] <rhpot1991> nhandler: I see an issue in lintian for what I just pointed you at too, I'm gonna fix that quick now
[02:43] <nhandler> rhpot1991: File a bug about it on Launchpad. launchpad.net/revu
[02:43] <xoox> jdong: I think following the deps would be okay as long as it prompted you: "You are going to fetch and build X packages. Yes/No"
[02:43] <nhandler> rhpot1991: Good, I was going to comment on that ;)
[02:43] <rhpot1991> nhandler: should it be 1.0 there?
[02:43] <nhandler> rhpot1991: version=3
[02:43] <xoox> In an ideal world it would just be like apt but building from source.
[02:43] <nhandler> rhpot1991: Read the uscan man page
[02:44] <rhpot1991> nhandler: on it, thanks
[02:45] <jdong> xoox: the problem right now is prevu does not have its own dep parser.
[02:45] <xoox> Ignoring build-deps seems imprudent. They are there for a reason and the package creator probably expects those dependencies to be fulfilled.
[02:46] <jdong> xoox: I can tell you as a backporter that 95% of build deps are for transitional rebuilds
[02:46] <xoox> jdong: There is a python apt library no?
[02:46] <xoox> What is a "transitional" rebuild exactly?
[02:46] <jdong> xoox: what good does that do for build-deps?
[02:46] <jdong> xoox: it's when I just uploaded libfoo 1.0->1.1, and now I want to rebuild foo using libfoo-1.1
[02:47] <jdong> if I just say "rebuild foo", depending on archive propagation state it could build against the old 1.0 or new 1.1
[02:47] <jdong> so I put in an explicit build-dep on >=1.1 to make sure the build waits until it can build against the new version.
[02:47] <jdong> the only reason I put in the build dep is for that force-rebuild. Other than that the old 1.0 would work just fine.
[02:48] <xoox> jdong: I see.
[02:48] <jdong> in cases where a build-dep is intentional, the ./configure script should check for it explicitly and the changelog should yell.
[02:48] <jdong> at least I've been asking for the changelog to yell and people have been nodding :)
[02:49] <jdong> and python-apt really doesn't get me much further, I still have to parse build-deps
[02:49] <jdong> It's not too much work to grab diff.gz's for build-dep lists and implement a parser
[02:49] <jdong> I mean, that's what pbuilder-satisfydepends is
[02:50] <jdong> but I guess so far I haven't been troubled by hunting down build-deps to the poitn that I want to invest my effort towards this feature
[02:53] <xoox> jdong: What is the probability of try-build-without-deps-rebuild scheme being implemented?
[02:54] <jdong> xoox: lim(P_implement(year), year -> +infty) = 1.000
[02:54] <jdong> until someone blesses me with free time, I don't know at what point the 0->1 transition occurs :)
[02:54] <jdong> (read: Contribute patches for this behavior)
[02:55] <jdong> xoox: at the same time I'd like the diff.gz's to be grabbed first for a dry-run dependency check before the entire source package is grabbed.
[02:55] <jdong> that way we don't have things like downloading 50TB for OpenOffice to figure out build-deps fail
[02:57] <xoox> jdong: Do you work for canonical?
[02:57] <jdong> no, I don't :)
[03:00] <xoox> Well, thanks for explaining the issues to me.   Where are we having this meeting?
[06:35] <dholbach> #u-meeting
[06:36] <dholbach> geser, nixternal: I know you're likely not going to be there, but I'll try anyway: there? :)
[06:36] <RAOF> Oh.  motu meeting?
[06:36] <dholbach> MC Meeting
[06:37] <RAOF> Ah.  Not so immediately interesting to me, then :)
[06:41] <persia> RAOF, You want a MOTU meeting?  I think the next one isn't scheduled, so if you've something to discuss, please call for one.  It's been a couple weeks.
[06:41] <RAOF> persia: No, not really.  Its just that if there was one on, I could actually turn up!
[06:41] <persia> heh.
[06:45] <ScottK> dholbach: What time is the meeting?
[06:45] <dholbach> ScottK: 7 utc
[06:46] <ScottK> Who's on the agenda for this one?  Is it vorian or is he the next meeting?
[06:46] <dholbach> https://wiki.ubuntu.com/MOTU/Council/Meeting
[06:46] <persia> He's for the next meeting.
[06:47] <dholbach> ScottK: didrocks, huats and Laney
[06:47]  * dholbach gets another cup of coffee
[06:48] <ScottK> Thanks
[06:52] <didrocks> hey dholbach !
[06:52] <dholbach> hiya didrocks
[06:55] <emgent> morning people
[06:55] <huats> morning
[06:55]  * iulian waves
[06:57] <didrocks> morning emgent & iulian
[07:27] <a|wen> how is it, that you split a bug out to track the status for multiple releases at a time? ... do you need to do a nominate for release, or is there another way?
[07:27] <ScottK> That's it.
[07:28] <ScottK> With that, /me goes to bed.
[07:28] <a|wen> thx
[07:49] <pochu> bah I'm late for the meeting :(
[07:51] <dholbach> arnegoetje asked me for help with the ibus-* packages on REVU
[07:51] <dholbach> I'll poke a few of them today - can anybody else help out too?
[07:56] <pochu> dholbach: you were right! I got 85/120 in the TOEFL (and I needed ~80 or even +70)!! :)
[07:56]  * dholbach hugs pochu
[07:56] <dholbach> ROCK
[07:56] <dholbach> congratulations!
[07:56] <pochu> my reading and writing saved me ;)
[07:56] <pochu> thanks :)
[07:57] <didrocks> pochu: really? TOEFL in not on 990?
[07:58] <didrocks> oh, it was TOEIC, not TOEFL :)
[07:58] <pochu> didrocks: I hope it's not ;)
[07:58] <didrocks> pochu: :D
[07:58] <pochu> or you will make me sad
[07:58] <pochu> :)
[07:58] <didrocks> no no, it was for TOEIC (I had to pass both of them :))
[07:59] <pochu> didrocks: I arrived late for the meeting... have you been processed already?
[07:59] <didrocks> pochu: yep, it's done for me :)
[07:59] <didrocks> and everything was all right ;)
[07:59] <pochu> didrocks: cool! congrats :)
[08:00] <didrocks> pochu: thanks ^^
[08:00] <pochu> didrocks: and Laney is last?
[08:00] <didrocks> pochu: exactly
[08:03] <dholbach> Laney: awake?
[08:18] <jono> headed to bed, night everyone!
[08:18] <dholbach> night jon
[08:18] <dholbach> jono :)
[08:19] <lidaobing> dholbach, hello, I am the packager of ibus-*
[08:19] <dholbach> lidaobing: ah great
[08:19] <lidaobing> I want to reply some question (not all)
[08:20] <lidaobing> 1. why don't package ibus 1.1, ibus 1.1 change too much from ibus 0.1.1.*, and there is not enough time to package it for ubuntu 9.04
[08:20] <lidaobing> so I will package 0.1.1 for ubuntu 9.04 and ibus 1.1 for ubuntu 9.10 and 9.04-backport
[08:21] <dholbach> ok
[08:21] <lidaobing> dholbach, and any suggested repos position for packaging?
[08:22] <lidaobing> I use lp:~lidaobing/+junk/<pkgname>, and I have no idea for any better postion
[08:22] <dholbach> lidaobing: I dunno... +junk just seemed like temporary :)
[08:23] <lidaobing> dholbach, I think it just means this repos does not link to a project
[08:23] <dholbach> is there a team already that takes care of the packaging of those input methods
[08:23] <dholbach> lidaobing: maybe talk to Arne about it
[08:23] <dholbach> it's not a blocker, just something I wondered about
[08:23] <lidaobing> it should be link to ubuntu project, but ubuntu does not support this
[08:23] <lidaobing> dholbach, I will fix other problems soon, thanks for your review.
[08:24] <dholbach> ~inputmethod-pkg/ibus-hangul/ubuntu maybe? I'll leave it up to you :)
[08:24] <lidaobing> dholbach, I will have a look
[08:25] <lidaobing> dholbach, whois Arne?
[08:25] <dholbach> lidaobing: oh, I thought you had worked with ArneGoetje already
[08:26] <lidaobing> dholbach, got it, Arne Goetje<EMAIL_ADDRESS>[08:44] <ara> didrocks: congrats!
[09:40] <didrocks> ajmitch_: thanks :)
[09:44] <Laney> dholbach: ...
[09:44] <Laney> I had it in my head that it was 7pm
[09:44]  * dholbach hugs Laney
[09:44] <dholbach> persia, soren: ^
[09:45] <soren> Laney: Aw.. Well, you're up again in two weeks :)
[09:45] <dholbach> I was just about to ask if you guys had time for an impromptu meeting :-)
[09:46] <Laney>  no worries if you don't, completely my fault
[09:46] <Laney> sorry chaps
[09:46] <soren> If we keep it under 20 minutes, I'm cool with it.
[09:47] <dholbach> persia: Señor Hikory? :)
[09:47] <dholbach> geser: maybe you're available now too? :)
[09:49] <persia> Estoy muy distraído
[09:50] <proppy> persia: ukeru
[09:50] <persia> (and I'm secretly glad because I only reviewed about half as many patches as I would have preferred).
[09:51] <Laney> I thought "Man I'll have a nice lie-in so I'm fresh for the meeting this *evening*"
[09:51] <directhex> :(
[09:51]  * Laney sprints off into the sunset, never to be seen again
[09:51] <geser> dholbach: yes, I'm available
[09:51] <dholbach> geser, soren, Laney: shall we take the plunge and head to #ubuntu-meeting?
[09:52] <persia> OK.  That's 3 1/2 of us.  Let's do it.
[09:52] <dholbach> rock on
[09:52]  * Laney shreds
[10:15] <pochu> dholbach: whereabouts?
[10:15] <dholbach> pochu: hu?
[10:16] <pochu> dholbach: Laney's application :)
[10:16] <pochu> or is it already done?
[10:16] <dholbach> pochu: there's the IRC Council meeting going on right now
[10:16] <Laney> noe, at 11
[10:16] <pochu> oh, so 45 minutes
[10:16] <pochu> ok :)
[10:18] <DaveMorris> Hi, I'm trying to track down the cause of a problem in Ubuntu with the QtBrowserPlugin example.  It works fine on Debian but not on Ubuntu.  Is there an easy way (rather than manually) to see which libraries it uses (from ldd) are different from the Debian ones.  IE Which packages have had modifications rather than been direct copies from Debian?
[10:19] <persia> DaveMorris, The version numbers would tell you, as Ubuntu libraries tend to have "ubuntu" in the revision string.
[10:21] <DaveMorris> cheers, I've no idea whats causing it not to work on Ubuntu but would be nice to fix it.  Since we are creating a 3D browser plugin for Geko based browsers
[10:23] <Laney> DaveMorris: You can see the patch Ubuntu applied on http://patches.ubuntu.com
[10:23] <Laney> (or linked from the PTS afaik)
[10:36] <Koon> didrocks: congrats!
[10:51] <Koon> huats: congrats!
[10:51] <huats> thanks Koon
[11:03] <jpds> huats: congrats, mate :)
[11:10] <huats> jpds:  thanks my friend
[11:19] <Rafik> huats> toutes mes félicitations  !
[11:20] <huats> Rafik: thanks !
[11:21] <mok0> huats: felicitations!
[11:21] <huats> thanks mok0
[11:21] <mok0> didrocks: congrat!!
[11:23] <james_w> congratulations didrocks
[11:23] <james_w> et tu huats
[11:23] <huats> merci james_w
[11:27] <lidaobing> dholbach, can you review ibus-hangul again, http://revu.ubuntuwire.com/details.py?upid=5090 (I have come back home from work, so I can response ASAP)
[11:28] <huats> persia: are you still around ?
[11:31] <persia> Not really, but I should be around in about half an hour.
[11:32] <dholbach> hum
[11:32] <dholbach> does Mootbot still spit out meeting summaries?
[11:33] <dholbach> www.novarata.net/mootboot has no meeting entries from Feb-2009
[11:36] <Laney> I never figured it out when we used it for u-uk meetings
[11:37] <dholbach> I just asked in #ubuntu-scribes
[11:37] <lidaobing> dholbach, ibus-anthy is also been uploaded again, http://revu.ubuntuwire.com/details.py?upid=5091
[11:38] <jpds> dholbach: I've contacted the person who runs it in #ubuntu-irc.
[11:38] <dholbach> lidaobing: I'll take a look in a bit - can you make the same changes to the other packages as well? was ibus-table unarchived again?
[11:38] <dholbach> jpds: perfect - thanks muchly
[11:38] <lidaobing> dholbach, OK
[11:38] <dholbach> Laney: seems I'm not admin of ubuntu-universe-sponsors
[11:38] <dholbach> sorry
[11:39] <Laney> no probs
[11:39]  * Laney pokes TheMuso
[11:39] <Laney> can you add me to u-u-s?
[11:40] <directhex> so... is it done? is Laney infused with added awesome?
[11:40]  * Laney is positively effervescent
[11:42] <a|wen> if I have a package in the archive (varnish on hardy) that i want to prepare an SRU for; but the package is (probably in error) uploaded as a native package (varnish_1.0.3-2.tar.gz), how should i then go about it? ... keep it as a native package, or do i have other optoins?
[11:42] <huats> hey Laney
[11:42] <huats> what happened this morning ?
[11:42] <Laney> I got the time 12 hours wrong
[11:42] <huats> dholbach: persia is the one who can add to u-u-s ?
[11:43] <huats> because I'd like to be added to it...
[11:43] <Laney> and TheMuso and DktrKranz
[11:43] <huats> Laney: oh :(
[11:43] <Laney> huats: It's ok now!
[11:43] <huats> congrats !!!
[11:43] <huats> I haven't seen it :)
[11:43] <Laney> thanks muchly
[11:44] <huats> you deserve it !
[11:45] <mok0> Laney!!! Woot!
[11:45] <huats> Laney: do you take care of the glom update or do you want me to do it ?
[11:46] <Laney> huats: I don't mind
[11:46] <Laney> but what do you think to VCS packaging for it?
[11:47] <huats> Laney: I am in favor :)
[11:47] <Laney> cool beans
[11:47] <huats> I know didrocks did quite a lot of stuffs based on james_w work
[11:47] <huats> we should ask him...
[11:47] <Laney> probably a good idea
[11:48] <huats> Laney: I have some stuffs to finish
[11:48] <james_w> congratulations Laney
[11:48] <mok0> Laney: congrats
[11:48] <huats> if by the middle of next week you haven't touched it, I will have a look
[11:48] <Laney> thanks!
[11:49] <directhex> yay Laney
[11:49] <Laney> and from my LP profile it looks like I've been a member for ages
[11:49] <Laney> since I was accidently added in August
[11:49] <didrocks> hum? :)
[11:49] <Laney> didrocks: We want to get the glom package into VCS
[11:50] <didrocks> Laney: you can have a look to the email announcing my MOTUship, there is the log of the conversation and we discussed about that
[11:50] <didrocks> Laney: if you need more clue, do not hesitate :)
[11:50] <huats> didrocks: we won'"t hesitate... you know that :)
[11:51] <Laney> \o
[11:51] <didrocks> huats: from you? I'm sure of it :)
[11:54] <didrocks> dholbach: persia : same question as huats for u-u-s :)
[11:54] <dholbach> didrocks: not an admin, excuser-moi
[11:54] <didrocks> dholbach: *excusez* :p
[11:55] <persia> Adding both of you now...
[11:55] <Laney> (and me please)
[11:55] <didrocks> (dholbach: and don't ask me to speak Deutch as a revenge ^^)
[11:55] <dholbach> didrocks: thanks for the correction :)
[11:55] <mok0> james_w: more and more often, people have their sources in VCS's and do not release tarballs, so the whole idea of the debian/watch file is defeated. Right now I am look at a package where the sources are in LP, and it is quite unsatisfactory that there is no way to do a "uscan --report-status" to see if the code is current. Do you have an idea on how to deal with this?
[11:55] <dholbach> maybe I'll get it .......... one day
[11:56] <huats> thanks persia
[11:56] <persia> Laney, Sure.
[11:56] <didrocks> dholbach: everyone can understand, that's not an issue :)
[11:56] <james_w> mok0: the VCS can tell you if it is current, so perhaps we should come up with a way to allow the VCS to tell you
[11:57] <mok0> james_w: that would be really nice
[11:58] <mok0> james_w: in the current case, I can see that the ~bzrNN number which is part of the package name corresponds to the latest commit.
[11:58] <broonie> but then you're back to requiring some intelligence to assess if upstream should be packaged.
[11:59] <mok0> broonie: yes it is a whole new ballgame
[12:00] <dholbach> a world without tarballs........... one day :)
[12:00] <mok0> broonie: I predict more and more projects will have sliding releases
[12:00] <mok0> dholbach: exactly
[12:00] <dholbach> mok0: I don't think it's a necessarily a frightening scenario - WDYT? :)
[12:01] <mok0> dholbach: oh, no, not frightening, it just doesn't fit very well into our current methodology
[12:02] <dholbach> that's definitely right
[12:02] <mok0> and we might as well start to think about alternative strategies
[12:02] <dholbach> it'd just be sweet if we eliminated the "no shared history" problem wrt branches as we approach them today :)
[12:03] <mok0> Yes
[12:03] <dholbach> even if future debian/rules (or whatever it might be) have to call auto tools or something
[12:03] <mok0> I agree
[12:03] <mok0> Well, we need an abstraction layer on top of all the various building methods people use; rules is as good as any
[12:03] <didrocks> persia: thanks :)
[12:04] <dholbach> it'll be a glorious and sun-shiny day that happens :)
[12:04] <mok0> Ah, Question: What is the best thing about reviewing packages from REVU???
[12:05] <mok0> Answer: You get to type the following often: "less rules" and "less control"
[12:05] <vorian> didrocks, Laney, contrats :)
[12:05] <dholbach> mok0: haha :)
[12:06] <didrocks> thanks vorian ;)
[12:06] <mok0> Of course that's another reason for using "less" over "more" :-)
[12:06] <Tonio_> mok0: got a response from skrooge upstream, last update should fix the issue.... I'll look and let you know for revu
[12:06] <mok0> Tonio_: Super!
[12:07] <Laney> vorian: thanks
[12:07] <Laney> good luck to you next time!
[12:07] <mok0> Skrooge upstream = Uncle Scrooge" ??
[12:07] <vorian> Laney: danke!
[12:08]  * mok0 < lunch
[12:11] <vorian> didrocks: if you truely want to help us on our next release, we will start work on Feb 25/26th on 4.2.1
[12:12] <vorian> i will need to walk you through our work flow :)
[12:12] <didrocks> vorian: just after the bug jub? Great! Which channel you advise me to join? ninja's one? :)
[12:14] <TheMuso> Laney: ?
[12:14] <Laney> TheMuso: Never mind, it's sorted now
[12:14] <Laney> (I just saw that you were an admin of u-u-s)
[12:14] <vorian> didrocks: see your server window "_
[12:35] <freeflying> how can I advocate a package on revu? thanks
[12:36] <Vest84> mok0: hi, you've asked me to add manpage to my package (using manpage.1.ex). if I'm a developer of my software, can I add the page into .orig. package, or I still should use as you said debian/quod.1 directory?
[12:36] <freeflying> Vest84: prefer to add it into upstream
[12:36] <freeflying> :)
[12:36] <persia> freeflying, If the account system is working properly, you should get an advocation checkbox next to the comment box.
[12:38] <Vest84> freeflying: thanks. it means it's better to add man for other distributions, not only to ubuntu. yes?
[12:38] <freeflying> persia: I login, but no such chechbox :)
[12:38] <persia> freeflying, Hrm.  Let me check.
[12:38] <freeflying> Vest84: if you can add it into upstream, then any other distro may benefit from it
[12:38] <freeflying> persia: thanks, dude :)
[12:39] <persia> What's your LP ID again?
[12:39] <freeflying> persia<EMAIL_ADDRESS>[12:39] <Vest84> freeflying: "thanks, dude" :) (again)
[12:40] <freeflying> Vest84: welcome :)
[12:41] <persia> freeflying, You have *three* LP accounts.  You ought merge them :)
[12:41] <persia> freeflying, Try reloading the page, and tell me if the advocation option appears now.
[12:42] <freeflying> persia: got it, thanks
[12:43] <hyperair> i never knew it was possible to have multiple LP accounts, let alone merge them
[12:44] <vorian> hyperair: i think they are talking about REVU accounts
[12:45]  * vorian was guilty of having two
[12:45] <nhandler> hyperair: You can merge multiple LP accounts here https://launchpad.net/people/+requestmerge
[12:45] <persia> hyperair, You do it by doing things with LP with multiple email addresses, and not telling LP about them beforehand.  Merging just cleans up.
[12:45] <hyperair> vorian: i never knew that you could even have multiple revu accounts
[12:45] <persia> vorian, No, multiple LP accounts.
[12:45] <vorian> okie
[12:45] <persia> hyperair, When REVU switched to using LP accounts, people with legacy accounts needed to merge.
[12:46] <hyperair> i see
[12:46] <nhandler> persia: You saw that REVU admins can now merge accounts for people, right?
[12:47] <persia> nhandler, I didn't, but that only helps with REVU.  The multiple accounts I discovered was in LP.
[12:47] <persia> nhandler, Only one of the accounts is used for REVU, but tracking down which took me a couple minutes.
[12:49] <a|wen> if I have a package (varnish on hardy) that is in error uploaded as a native package (varnish_1.0.3-2.tar.gz) ... what should i then do with the next version; keep it as native, or get the original tarball to make it a non-native package?
[12:49] <hyperair> blargh geeez why is evolution taking so long to compile
[12:51] <pochu_> Laney: congrats!
[12:51] <Laney> thanks pochu!
[12:52] <freeflying> dholbach: you would like have a look at http://revu.ubuntuwire.com/details.py?upid=5103 and http://revu.ubuntuwire.com/details.py?upid=5102 again?
[12:52] <persia> a|wen, Make it non-native with the next upstream version.
[12:52] <dholbach> freeflying: can you ask ArneGoetje to review them too, right now I'm a bit hammered, but willing to check them out later today
[12:52]  * dholbach is really crazy busy
[12:53] <a|wen> persia: thx... i'll do that
[12:53] <freeflying> dholbach: ok
[12:54] <persia> Oh, excellent.  Issue 222 is resolved!
[12:54] <a|wen> persia: oh, new upstream relese. it is on hardy, so that want happen... so for an SRU i shoud keep it as native?
[12:55] <persia> a|wen, SRU for new upstream is rare and hard, but do keep that native: the goal is to minimise the debdiff for SRUs.
[12:56] <a|wen> persia: i thought so ... but there will be no debdiffs with a native version, so you could call that minimal ;)
[12:56] <persia> a|wen, You can generate a debdiff on a native package.  It is more likely to fail to apply due to binary blobs, but it can be done.
[12:57] <persia> The goal is to minimize the changes, to address known issues.  Exactly what that means is open to intepretation, but changing the method of packaging is usually not recommended.
[12:57] <a|wen> persia: oh, i didn't know that, i'll give it a try
[12:58] <mok0>  Vest84, I was AFK for a while... of course, you can put your manpage in the tarball! Good idea!
[13:00] <Vest84> mok0: ok, I'm working on it :) studying
[13:01] <mok0> Vest84: let me know if you need any help
[13:02] <pochu_> looks like we are on a killing spree!
[13:02] <pochu_> 4 MOTUs in a row ;)
[13:08] <Vest84> mok0: thank you in forward
[13:08] <mok0> pochu: are they killing MOTUs now? Oh, the horror!
[13:09] <mok0> pochu: users are getting more and more demanding
[13:11] <mok0> Who has admin rights to ubuntu-motu mailing list?
[13:11] <soren> I do.
[13:12] <mok0> soren: can I ask you to approve a message I sent? I used my ubuntu email address and I am not subscribed with that
[13:12] <soren> mok0: It's not in the queue.
[13:12] <soren> dholbach might have already approved it. He's like that.
[13:12] <mok0> soren: huh? It sent me a message that it's held for approval
[13:13] <soren> This is where you say: "But it's only been two minutes since I sent it", and I go: "Yes, he's like that. I just told you."
[13:13] <dholbach> nothing in the queue
[13:13] <dholbach> sorry guys
[13:13] <mok0> I sent it 2 hours ago
[13:14] <dholbach> didn't it go through?
[13:14] <pochu> mok0: was it a reply to nhandler's mail?
[13:14] <pochu> If so, I saw it
[13:14] <mok0> Ah it did, sorry
[13:15] <pochu> mok0: too much ET for me :)
[13:15] <mok0> No it was a reply to the guy who sent a patch to ical2sqlite
[13:15] <pochu> that one too ;)
[13:16] <mok0> Where's quadripro? I want to shake his virtual hand
[13:17] <c_korn> is there a dput option to ommit the upload of the orig.tar.gz file?
[13:19] <persia> c_korn, No.  Whether the orig.tar.gz is uploaded or not is determined by the content of the .changes file.
[13:20] <c_korn> ok, but uploading to the PPAs of launchpad I do not have to upload the orig.tar.gz again when it is already uploaded. but it has to be listed in the changes file to compare the checksums
[13:21] <a|wen> persia: if i try to do a debdiff on the native package i just get a lot of "Use of uninitialized value ... in /usr/bin/debdiff ..."
[13:21] <slytherin> c_korn: when you do 'debuild' use only argument -S instead of -S -sa.
[13:22] <mok0> c_korn: I was gonna suggest that too
[13:23] <persia> a|wen, How are you calling it?
[13:24] <a|wen> persia: "debdiff varnish_1.0.3-2.dsc varnish_1.0.3-2ubuntu0.8.04.dsc"
[13:24] <persia> c_korn, the checksum needs to be listed in the .dsc file, but not in the .changes (unless you're uploading it).
[13:25] <persia> a|wen, And both unpack cleanly with dpkg-source?  Very odd.
[13:25] <persia> a|wen, What happens if you unpack both trees, and run diff -urN on the top-level directories?
[13:29] <directhex> Laney, how does the MOTU wizard's robe & hat feel?
[13:29] <a|wen> persia: both unpack fine, and i get a diff out by running the command
[13:29] <c_korn> I don't know what the difference is, but when I now run dput -f ... it wants to upload the orig.tar.gz
[13:30] <persia> c_korn, Look at your source.changes file.  Is the orig.tar.gz listed therein?
[13:30] <c_korn> yes
[13:30] <mok0> c_korn: _What_ file are you trying to upload?
[13:31] <persia> How did you call debuild?
[13:31] <c_korn> debuild -S
[13:31] <c_korn> dput -f ppa-getdeb scilab_5.1-1~ppa2_source.changes
[13:31] <persia> What is the revision number?
[13:32] <persia> I suspect you've hit a condition designed to reduce mistakes in Debian :)
[13:32] <persia> c_korn, Try calling debuild -S -sd
[13:34] <c_korn> I tried that before. then the orig.tar.gz is not uploaded but the PPA rejects the package because the orig.tar.gz is missing, (the entry in sources.changes [or dsc] is required for checksums I presume)
[13:34] <slytherin> c_korn: was orig.tar.gz ever uploaded to your PPA?
[13:34] <c_korn> yes
[13:34] <a|wen> ugly... the source contains a .svn directory, which doesn't get included in the new .tar.gz ...gives me a huge diff
[13:34] <c_korn> oh, wait
[13:36] <c_korn> damn, I am dumb. I deleted the package in the PPA. the orig.tar.gz does not exist so. sorry for bothering you
[13:41] <a|wen> persia: is there any way i can get the .svn directory to stay in the source when the .tar.gz is being rebuild by debuild? or is it okay to let the .svn directory go?
[13:46] <persia> a|wen, How are you calling debuild?
[13:47] <a|wen> persia: just "debuild -S"
[13:47] <persia> Try debuild -i/^$/
[13:48] <persia> Sounds like someone turned on -i with the default string by default, which would normally be a rather reasonable thing to do.
[13:50] <a|wen> persia: no luck, still the same
[13:55] <soren> a|wen: Native package?
[13:55] <a|wen> soren: yes
[13:55] <soren> a|wen: Then -i doesn't factor into it.
[13:56] <soren> -i specifies stuff that should be left out of the diff.gz.
[13:56] <soren> -I is for leaving stuff out of the orig.tar.gz.
[13:57] <soren> Well.. Or the tar.gz, anyway
[13:57] <soren> (it's not an orig.tar.gz in the case of native packages)
[13:58] <a|wen> soren: thanks a lot, that was the trick
[13:58] <soren> Any time.
[13:58] <a|wen> now it at least only fiddles with the config.sub and config.guess; that should be okay i suppose
[13:59] <soren> I'm curious... Why do you want to leave the .svn directory in there?
[13:59] <a|wen> soren: it is an update to a hardy package ... build in error as a native by debian
[13:59] <persia> a|wen, If config.sub and config.guess are copied at build time or clean time, yes, it's safe to ignore that part of the debdiff.  If someone complains, point out that it's automated, and changing the automation would be a larger change.
[14:00] <a|wen> persia: they are copied at build-time, just checked debian/rules ... so agreed
[14:09] <slytherin> can any archive admin please process sync of xmlgraphics-commons from experimental? I am waiting for it to happen to work on fop merge. Bug 326172.
[14:13] <persia> For those watching, it's traditional to request actions of the archive-admins in #ubuntu-devel, rather than here.
[14:20] <directhex> and to offer them a pint as a reward
[14:20] <quadrispro> hi guys
[14:20] <devfil2> quadrispro: congrats
[14:20] <quadrispro> thank you :)
[14:21] <mok0> quadrispro, congratulations!
[14:21] <quadrispro> too nice, thank you very much
[14:24] <Laney> directhex: Dunno, no gpg key here
[14:25] <directhex> :o
[14:25] <Laney> quadrispro: congrats
[14:25] <Laney> it is a day of new MOTUs!
[14:26] <directhex> how many of those new MOTUs are going to upload sublib, though? :o
[14:26] <quadrispro> Laney: congrats to you too!
[14:27] <Laney> just one
[14:27] <Laney> who is just awesome
[14:27] <DktrKranz> Laney: didrocks, quadrispro: congrats \o/
[14:28] <devfil2> Laney: congrats
[14:28] <devfil2> Laney: now you are a MOTU, so you can upload your miro merge :)
[14:28]  * Laney shreds his axe
[14:28] <Laney> heh
[14:28] <Laney> I will
[14:28] <Laney> (after reviewing it carefully.....)
[14:29] <DktrKranz> Laney: no review, just crack! :)
[14:29] <Laney> those damn contributors, you can never be too thorough
[14:29] <Laney> u-u-s queue is huge
[14:29] <mok0> quadrispro: just in time for REVU day!
[14:29]  * Laney is scared
[14:29] <quadrispro> yes
[14:29] <devfil2> Laney: please remember that you can upload it until FF
[14:30] <Laney> of course
[14:30] <DktrKranz> and remember, first upload *must* be
[14:30] <DktrKranz> 1) a sponsor request
[14:30] <DktrKranz> 2) a SRU
[14:31] <Laney> both of these things?
[14:31] <DktrKranz> one of these :)
[14:32] <Laney> actually I have a long-standing GHC SRU
[14:32] <Laney> ...........
[14:32]  * Laney cackles
[14:32] <persia> Extra points if it's not only both those things, but also for a bug that affects multiple packages because it's fixing a dependency.
[14:32] <DktrKranz> I started with a request for sponsorship for a SRU bug
[14:32]  * devfil2 too
[14:33] <nxvl> huats: congratulations!
[14:33] <huats> Thanks nxvl !
[14:33] <mok0> vorian?
[14:34] <DktrKranz> huats: indeed! congrats (I forgot about "older" MOTUs)
[14:34] <devfil2> huats: congrats
[14:34] <vorian> mok0: yus?
[14:34] <mok0> vorian, bug 328321  should that be closed?
[14:34] <vorian> yes
[14:35] <pochu> quadrispro: congrats!
[14:35] <mok0> vorian: thx I'll do it then
[14:35] <vorian> mok0: thanks
[14:35] <quadrispro> thank you pochu
[14:35] <mok0> vorian: heh funny he closed two bugs bug not his own
[14:36] <vorian> that's what I was just checking, mok0 :)
[14:36] <mok0> ok, another one gone from uus
[14:37] <mok0> hyperair: bug 328063 are you still on it?
[14:38] <hyperair> mok0: no it's done.
[14:38] <hyperair> mok0: could you sponsor it please?
[14:38] <mok0> hyperair: will do it right awayyy
[14:38] <hyperair> okay thanks =)
[14:41] <mok0> another one bites the dust
[14:42] <RainCT> heya
[14:42] <mok0> Hi RainCT, we have 4 new MOTUs with us today
[14:43] <RainCT> mok0: Uhm.. EMENOTUNDERSTAND :P
[14:43] <mok0> RainCT: go back to sleep
[14:44] <RainCT> -.-
[14:44] <mok0> ;-)
[14:44] <RainCT> oh
[14:44] <RainCT> huats, didrocks: congrats!
[14:44] <RainCT> and quadrispro :)
[14:45] <quadrispro> thank you RainCT :)
[14:45] <RainCT> and Laney
[14:45] <RainCT> o.O
[14:45] <RainCT> MOTU flood XD
[14:45] <huats> RainCT: thanks !
[14:45] <mok0> he woke up
[14:45] <Laney> <3 the MC
[14:45] <RainCT> mok0: I've just arrived from school, I've headache and I'm still catching up with mail :P
[14:46] <mok0> RainCT: j/k
[14:46] <dolanor> Hello
[14:47] <dolanor> If an upstream package doesn't have any COPYING but every source file has the LGPL header, is it packageable ?
[14:47] <mok0> dolanor: no
[14:48] <dolanor> even if the website tells so ?
[14:48] <dolanor> http://www.hawksoft.com/hawknl/
[14:48] <mok0> dolanor: we need a file that allows us to distribute the directory tree
[14:49] <superm1> wow 4 new MOTUs. congrats quadrispro Laney huats and didrocks.  sounds like between the 4 of you, you can easily complete the undocumented MOTU initiation tradition of knocking out all the packages on REVU your first day :)
[14:49] <mok0> dolanor: ... you are not packaging the website. Just sayin'
[14:49] <dolanor> mok0: ok, I understand
[14:49] <huats> ;)
[14:49] <RainCT> dolanor: you can repackage the tarball and add the COPYING, as a last resource
[14:49] <huats> BTW, who is no yet involved in the mentoring program  ?
[14:49] <mok0> RainCT: ooh, that is on the edge
[14:49] <huats> so that I can add all the new MOTUs :)
[14:50] <dolanor> RainCT: the probleme is : the developer doesn't reply to email. Maybe he is dead :/
[14:50] <RainCT> mok0: if there is evidence that they want that license then it is accepted
[14:50] <mok0> RainCT: well it makes sense, I agree to that
[14:50] <mok0> RainCT: but in 5 years, the package might still be around and the website is closed donw
[14:51] <mok0> maybe... that's a risk
[14:51] <quadrispro> superm1: thank you :) Do you remember of w-scan? Do you think we should wait until 16-17th Februray?
[14:51] <superm1> quadrispro, didn't that email say it was headed into experimental?
[14:51] <huats> quadrispro: are you interested in joining the MOTU mentoruing program ?
[14:51] <huats> superm1: same question :)
[14:51] <RainCT> mok0: Not sure which effects that would have, but archive admins don't seem worried about this. I think I even have/had some package in Debian where I had to do this..
[14:52] <mok0> dolanor: if at all possible, you should try to get upstream to put a COPYING file in $topdir and package a new tarball
[14:52] <superm1> quadrispro, if you dont see it in experimental, go ahead and build the package from his svn as we discussed before and we'll sync it later when it gets into experimental.  i think now is fine at this point
[14:52] <mok0> RainCT: I see. Well be glad I am not archive admin :-P
[14:52] <quadrispro> huats: it could be exciting, but at the moment I have too many things too, Perhaps, later :)
[14:52] <huats> quadrispro: ok
[14:52] <quadrispro> superm1: ok, thank you
[14:52] <superm1> huats, i'm far too preoccupied with other ubuntu related things to be a mentor, sorry.
[14:52] <huats> superm1:
[14:53] <quadrispro> (huats: congrats to you too :))
[14:53] <huats> and quadrispro: ok
[14:53] <huats> please do not hesitate to contact me if you change your mind
[14:53] <huats> quadrispro: thanks ! and congrats to you too !!
[14:53]  * RainCT glances at huats
[14:53] <huats> RainCT why glances ?
[14:54] <mok0> RainCT: I was just thinking this morning, to insert another stage between "Unreviewed" and "In progress", namely "Copyright", so all packages that pass through reviewing have to pass a stage where the copyright is affirmed
[14:54] <mok0> RainCT: so they would not enter reviewing before the copyright is clarified
[14:55] <mok0> PRobably overkill
[14:55] <RainCT> mok0: not sure. perhaps that could be done with tags (copyright-pending, copyright-verified, ..). I'll add support for tags soon
[14:55] <mok0> RainCT: cool!
[14:55] <quadrispro> could someone add me to universe-sponsors?
[14:55] <mok0> RainCT: you have some code for that?
[14:55] <RainCT> huats: I'm waiting for someone to be assigned to me :). I'm also happy without a mentee, though :P
[14:55] <RainCT> mok0: no, but I'll probably get to it today or this weekend
[14:55] <huats> RainCT: i know
[14:56] <huats> you are on the list
[14:56] <Laney> why should copyright be separate from review?
[14:56] <huats> I have a bit too much things to handle
[14:56]  * vorian cheers for huats and quadrispro
[14:56] <RainCT> okay, just checking :)
[14:56] <quadrispro> vorian: thanks a lot!
[14:56] <huats> so I deal with them in lots :)
[14:56] <Laney> that is one of the major parts of review that people get wrong, isn't it?
[14:56] <huats> RainCT: but don't worry
[14:56] <huats> :)
[14:56] <dolanor> RainCT: So right now, I try to recontact the upstream dev, and if he doesn't reply, I may be OK to add a COPYING myself and package frome that ? (and email the orig.tar.gz to the dev ?.)
[14:57] <persia> quadrispro, Sure.  Doing so now.
[14:58] <Laney> dolanor: It's a bit dubious to add copyright information to someone else's work, imo
[14:58] <mok0> Laney: I agree
[14:58] <RainCT> dolanor: If it's clear enough (based on headers in files in the tarball, statement on the website, etc), yes. Just asking upstream to add the COPYING file to the next release (or release a new revision of the current one adding it, but NOT replacing the current one if is has already entered a distribution) is enough, personally I'd find receiving a tarball annoying.
[14:59] <quadrispro> I see, thank you persia :)
[15:00] <dolanor> Laney: yes, for sure ... But it is written nearly everywhere that it is LGPL, but no COPYING file
[15:00] <dolanor> I understand because of the source tree
[15:01] <dolanor> but I began this package 3 years ago ... still no answers
[15:02] <slytherin> quadrispro: Laney: huats: didrocks: Congratulations. :-)
[15:02] <persia> There's no requirement that there be a file called "COPYING", but the LGPL source preface does say "You should have received a copy of the license with this code..." (or similar veribiage).
[15:02] <Laney> thanks slytherin
[15:02] <huats> thanks slytherin and vorian
[15:03] <dolanor> persia: hmmm, yes, right
[15:03] <RainCT> persia: afaik the package would be rejected without a COPYING file
[15:04] <RainCT> (at least in the case of GPL, but I guess LGPL is the same)
[15:04] <slytherin> AFAIK, COPYING or LICENSE is required.
[15:04] <persia> RainCT, Nope.  It would be rejected for failure to include the license.  Doesn't matter if it's called "COPYING" or "LGPL" or "LICENSE" or what have you.
[15:04] <RainCT> persia: Right.
[15:05] <slytherin> persia: pm?
[15:08] <bddebian> Heya gang
[15:09] <Laney> hi bddebian
[15:09] <bddebian> Hi Laney, congrats :)
[15:13] <sladen> are there any of the ubuntu-mono packagers here
[15:13] <sladen> libtaoframework is still FTBFS;  does it need to depend on cil-2.0 to get System.Windows.Forms?
[15:16]  * ScottK looks around for directhex...
[15:16] <ScottK> He's the one you want.
[15:16] <quadrispro> superm1: 20081106-3~ubuntu1 could be a good version ?
[15:16] <directhex> hm?
[15:16] <quadrispro> superm1: about w-scan
[15:17] <quadrispro> superm1: remember that it will be auto-synced since jaunty+1
[15:18] <dolanor> what to do with upstream package with this tree
[15:18] <superm1> quadrispro, i thought we had decided it would be something that would still need to be manually synced?
[15:18] <dolanor> project_v2.0.1/project/<root>
[15:18] <dolanor> I put the debian dir at the same levec of project ?
[15:19] <chrismurf> hi all, would a MOTU mind reviewing http://revu.ubuntuwire.com/p/pyproj?  mok0 worked with me on it yesterday and advocated for it, I think it's ready.
[15:20] <RainCT> nhandler: merged your branch
[15:20] <mok0> hi chrismurf
[15:20] <chrismurf> mok0, heya!  Thanks again for the help
[15:21] <chrismurf> in hindsight, I think splitting it was the right approach
[15:21] <chrismurf> modifying the debian version now to be split as well
[15:21] <mok0> chrismurf: I think so too... did the DDs arrive at the same conclusion?
[15:21] <chrismurf> haven't bugged them about it - just gonna do it and poke them again ;-)
[15:22] <chrismurf> like you said, I doubt they'll say no
[15:22] <directhex> sladen, tao hasn't seen any love for a while
[15:23] <nxvl> !nixternal | nixternal
[15:23] <mok0> chrismurf: yeah
[15:23] <nxvl> heh
[15:23] <nxvl> it has been updated
[15:24] <mok0> !nxvl
[15:24] <mok0> ubottu: neither do we
[15:24] <mok0> heh
[15:25] <DktrKranz> it's not that funny being on ubottu's list
[15:33] <directhex> sladen, gah, it's a mess tbh
[15:40] <directhex> hm, nope, it's worse than i thought
[15:43] <tgm4883> mok0, I've fixed most of the issues that you commented on http://revu.ubuntuwire.com/p/mythnettv  about COPYING.GPL missing, i'm assuming you are asking that because it is referenced in the COPYING file, but that file does not exist anywhere in the orig.tar or on the authors site.  Am I suppose to get that from elsewhere?
[15:44] <mok0> tgm4883: It is supposed to pre-exist in upstream's tarball
[15:44] <tgm4883> ah
[15:45] <mok0> tgm4883: it is that file that gives us the permission to distribute the source tree
[15:45] <tgm4883> let me contact upstream then, and see what I can find out
[15:45] <mok0> tgm4883: perfect!
[15:45] <Laney> [ubuntu/jaunty] miro 2.0-1ubuntu1 (Accepted)
[15:45] <Laney> good times \o/
[15:45] <tgm4883> cause he just says use GPL or LGPL in that COPYING file
[15:46] <mok0> tgm4883: oh yes he does actually
[15:46] <ScottK> tgm4883: It must have a full, verbatim copy of the license.
[15:47] <mok0> tgm4883, yes so he should include both GPL and LGPL licenses
[15:47] <jdong> ok, RMS lord, forgive me, but I am about to willfully order a Broadcom wifi chipset....
[15:47] <tgm4883> mok0, ScottK ok, i'll see what I can do
[15:47] <mok0> jdong: does it work with Ubuntu?
[15:48] <jdong> mok0: the wl.ko works flawlessly with Linux all the way up to full N speeds
[15:48] <jdong> mok0: but it is a pure blob of evil.
[15:48] <mok0> jdong: inserting trojans, malware and what not
[15:48] <jdong> mok0: from what I understand the driver derives from the same blob used on Broadcom routers that run Linux (like 90% of the market...)
[15:48] <tgm4883> mok0, i've also fixed http://revu.ubuntuwire.com/p/mythnettv-gui per your request, so you can give it a +1, but if mythnettv doesn't get in it's a irrelevant, so you may want to wait
[15:49] <jdong> which probably explains its maturity/stability
[15:49] <ScottK> tgm4883: If upstream won't fix it, you can repack the tarball and add the file (documenting what you've done) as long as it's clear in the context of the package what upstream intended.
[15:49] <mok0> tgm4883: ok, thanks
[15:49]  * ScottK had to do that on his very first package.
[15:49] <jdong> but the ath9k based card I have right now is just... awful under Linux
[15:49] <tgm4883> ScottK, ok thanks
[15:49] <jdong> I had it when it took 10 minutes to associate to a node 3 feet away.
[15:49] <ScottK> jdong: Intel?
[15:50] <jdong> Atheros
[15:50] <ScottK> jdong: I'm suggesting why not get Intel?
[15:50] <ScottK> WFM.
[15:50] <jdong> the other complicating factor is that this is an Apple notebook and I am still interested in the ability to dualboot its proprietary OS
[15:51] <jdong> if it were pure-Linux I would get an iwl4965
[15:51] <jdong> and Apple's HCL consists of... two wifi cards? :)
[15:51] <ScottK> Yum.
[15:51] <jdong> yea funny how people complain about Linux and hardware
[15:52] <jdong> stupidly enough the card works flawlessly under OS X
[15:52] <ScottK> Apple is a special case.
[15:52] <jdong> but I feel somewhat... bad... for going around running OS X on campus
[15:52] <broonie> jdong: Linux claims to work on rather more hardware than OS X does.
[15:52] <ScottK> Since they are really the only purveyors of an integrated hardware/software set.
[15:58] <chrismurf> oh crap - how does one "un"-archive?
[15:58] <chrismurf> found a new button... should NOT have pressed that.
[15:59] <RainCT> chrismurf: on REVU? click on Unarchive :P
[15:59] <chrismurf> oh hey :-)
[15:59]  * chrismurf will not be tempted by other pretty icons
[16:04]  * mok0 finds a button labelled "Do not press, danger!"
[16:04]  * mok0 thinks it is a pretty button
[16:05] <soren> mok0: What colour is it?
[16:05] <mok0> soren: red
[16:05] <soren> Those are the best.
[16:05] <mok0> hehe
[16:05] <mok0> It is behind a small window of glass
[16:09] <Laney> mok0: http://orangesquash.org.uk/~laney/wallpapers/1200682311225.jpg
[16:09]  * chrismurf thinks that's what the little hammer is for
[16:09] <mok0> hehe
[16:09] <DktrKranz> mok0: what about a "click here to have all MOTUs pulled out of the beds to review your package" button?
[16:10] <mok0> DktrKranz: ugh me no like
[16:10] <chrismurf> haha - that seems like a horrible idea for all involved
[16:10] <chrismurf> "Your package has been EXPLODED."
[16:10] <ScottK> I guarantee any package reviewed after that button would not get advocated.
[16:11] <mok0> "Your package has been dissolved and the bytes scattered all over the Internet. You are free to use Google or other service at your disposal to attempt a recovery. Good Luck".
[16:12] <Laney> sounds like charlie and the chocolate factory
[16:13] <RainCT> lol
[16:13] <DktrKranz> mok0: just add "if you ever be able to gather them all again, don't remember to push the button again"
[16:14] <DktrKranz> s/remember/forget/
[16:14] <mok0> Laney: that's your wallpaper? Are you red-green colour blind?
[16:15] <Laney> mok0: I have it on a rotation
[16:15] <Laney> colour blind?!
[16:15] <mok0> Laney: the color is so vivid it makes me want to start a fire
[16:15] <Laney> haha
[16:16] <mok0> Laney: well, if you're colorblind, it would appear to be a nice greyish color, possibly quite soothing
[16:17] <Laney> I like the red
[16:17] <Laney> gets me fired up!
[16:20] <mok0> Laney: I'd hate to see your bedroom decor
[16:34] <jpds> dholbach: Meeting logs should be back.
[16:35] <jpds> dholbach: ^in case you didn't see the above ;-)
[16:36] <dholbach> jpds: THANKS
[16:40] <quadrispro> can a .desktop file use a .SVG as icon?
[16:40] <RainCT> quadrispro: depends on the menu application
[16:42] <RainCT> quadrispro: I think gnome-panel does, but I'm not really sure about this. (btw, in case you don't know, the name of the Icon in the .desktop file should have NO extension - the menu will figure it out by itself)
[16:43] <quadrispro> RainCT: I talk about a .desktop which should be installed in the Applications menu
[16:43] <RainCT> quadrispro: .desktop files are universal (a FreeDesktop.org standards). KDE, XFCE, etc. use them too
[16:43] <quadrispro> ok perfect
[16:43] <quadrispro> thank you
[16:44] <RainCT> quadrispro: I think that if you have a SVG somewhere in /usr/share/icons gnome-panel will pick it up, but you'd better ask on #ubuntu-desktop
[16:46]  * directhex declares it gohometime
[16:46] <persia> The .desktop file *shouldn't* specify a filetype for the icon: only an icon name.
[16:46] <quadrispro> yes, I know it
[16:46] <persia> The menu system will select the appropriate icon from the available icons based on that name.
[16:46] <quadrispro> ok
[16:47] <quadrispro> thank you
[16:47] <persia> the default menus for Xubuntu, Kubuntu, and Ubuntu Desktop can all handle SVG icons.  I'm less sure about other launchers.
[16:59] <pochu> I think I'm going to love this /ignore * PARTS QUITS JOINS :)
[16:59] <pochu> the ":)" is not ignored though :)
[16:59] <pochu> otherwise I'd ignore myself :(
[16:59] <vorian> /ignore pochu
[16:59] <vorian> oops
[16:59] <vorian> :P
[17:00] <pochu> :)
[17:37] <AndrewGee> Hey all. Any MOTUs available to review my package - gpxviewer - It's an application that allows users to look at GPS traces files in GPX format. Thanks :) http://revu.ubuntuwire.com/details.py?package=gpxviewer
[18:05] <Laney> ember: I thought you were a MOTU :O
[18:09] <iulian> Laney: Congratulations!
[18:10] <Laney> thanks iulian!
[18:12] <directhex> rar, i am back
[18:16]  * Laney blinks at bug #95444
[18:16] <sebner> Laney: congratulations!
[18:16] <Laney> rawr
[18:16]  * Laney pounces sebner
[18:39] <dolanor> Any MOTU available to revu/advocate my hexdiff package ? Tool to visually see differences in hexadecimal between files : http://revu.ubuntuwire.com/p/hexdiff
[18:39] <dolanor> AM I the only one to get errors with ubuntuwire ?
[18:41] <dolanor> nevermind, I had to restart firefox because of an update
[18:46] <chrismurf> Is there a second MOTU who could review pyproj?  It's a python wrapper for PROJ.4 (map projection library).  mok0 advocated, looking for one more.  http://revu.ubuntuwire.com/p/pyproj
[18:53] <henrik-hw0> MOTUs: your #1 uploader needs a 2nd advocate on libmirage.
[19:05] <Laney> boo @ cowbuilder
[19:05] <Laney> (-dist). Doesn't work if /home and /var are on separate partitions
[19:22] <henrik-hw0> MOTUs: your #1 uploader needs a 2nd advocate on libmirage.
[19:30] <lfaraone> How hard would it take to get a debdiff accepted for a package in main?
[19:30] <lfaraone> (string fix mostly)
[19:30] <Laney> not very
[19:31] <Laney> subscribe ubuntu-main-sponsors instead of u-u-s
[19:33] <lfaraone> Laney: Ah, I expected a multi-level obsticle course upon completion it would be reviewed by the tech board and signed by the sabdfl. :)
[19:33] <lfaraone> *which upon
[19:42] <asomething> Laney: thanks for the upload! Glad to see a new u-u-s
[19:43] <Laney> no problem!
[19:43] <Laney> the queue is of quite a scary size
[19:43] <slytherin> yes, 140+ is big size for any queue. :-)
[19:45]  * Laney is judiciously unsubscribing u-u-s
[19:48] <asomething> if any one wants an easy one out of the queue, i've got a sync that could use an ACK ;-) Bug #316305 builds in jaunty pbuilder, available in my PPA for testing
[19:49]  * Laney is processing in order
[19:52]  * slytherin is processing java packages.
[19:52] <asomething> heh, worth a shot
[19:53] <asomething> Laney: anyways, congrats on becoming a MOTU
[19:53] <Laney> thanks
[19:53] <Laney> your turn soon, eh?
[19:54] <slytherin> asomething: I never saw ttf-rufscript in repositories. Did you drop plans to package it outside your PPA?
[19:55] <asomething> slytherin: should be in jaunty, I got into debian
[19:55]  * slytherin checks
[19:56] <asomething> http://packages.ubuntu.com/jaunty/ttf-rufscript
[19:56] <slytherin> asomething: yes it is. Don't know how I missed it.
[19:56] <slytherin> :-)
[19:59] <lfaraone> I added a .patch file to the debian/patches folder, dch -i'd, and debuilt the source. Why is it then that debdiff says there were no changes made to the dscs other than the changelog addition?
[20:02] <slytherin> lfaraone: what patch system does the package use?
[20:12] <asomething> what's the point of the Enhances field in debian/control? does it actually do anything? how does it get used?
[20:12] <Laney> probably in package managers
[20:13]  * ScottK mentions ##1234567890 on the off chance people want to join.
[20:19] <chrismurf> asomething, "This field is similar to Suggests but works in the opposite direction. It is used to declare that a package can enhance the functionality of another package. "
[20:20] <asomething> ya, that's what the policy man says, but I guess I'm wondering how it gets used by say synaptic, not very important, just wondering for something I'm working on
[20:26] <dolanor> Any MOTU available to revu/advocate my hexdiff package ? Tool to visually see differences in hexadecimal between files : http://revu.ubuntuwire.com/p/hexdiff
[20:27] <slytherin> how can I create a watch file that parses latest version of a package from this page - http://java.netbeans.org/servlets/ProjectDocumentList ?
[20:27] <dolanor> need 1 more advocate
[20:29] <slytherin> found out already
[20:30] <sistpoty> hi folks
[20:32] <dolanor> hi sistpoty
[20:32] <sistpoty> hi dolanor
[20:33]  * ScottK waves to sistpoty.
[20:33] <sistpoty> hi ScottK
[20:34] <sistpoty> ScottK: any tought tasks for me this friday night?
[20:36]  * sebner winks sistpoty =)
[20:36] <sistpoty> huhu sebner
[20:43] <iulian> Hiya sistpoty.
[20:53] <sistpoty> yay, water pipe broken in our road, so no water until tomorrow afternoon
[20:53] <jdong> what are g-p-m battery warning levels determined by?
[20:54] <jdong> it is kinda silly on netbooks to do the whole DANGER WILL ROBINSON: YOU HAVE 35 minutes of battery left!!
[20:57] <chrismurf> jdong, gconf-editor: /apps/gnome-power-manager/thresholds
[20:57] <maxb> why silly?
[20:57] <sistpoty> hi iulian btw
[20:58] <slytherin> Is it necessary to remove hidden files from upstream archives?
[20:58]  * sistpoty could still put big buckets of water aside for the night :)
[20:58] <jdong> maxb: it makes it sound a lot more urgent than it should
[20:58] <jdong> maxb: i.e. for some systems 10% of battery lasts quite a long time
[20:58] <jdong> while on my large notebook 10% is hurry or openoffice wont close before the system ZAPs
[20:59] <maxb> Well.... yeah, but you said an absolute time, not a % :-)
[20:59] <slytherin> Is it necessary to remove hidden files from upstream archives?
[20:59] <sistpoty> jdong: I assume it's some acpi magic?
[21:00] <chrismurf> jdong, sistpoty, it's a user setting in gconf.  /apps/gnome-power-manager/thresholds.
[21:00] <jdong> I guess that is a gracious definition of "user setting" but thanks :)
[21:03] <ScottK> jdong: KDE if you want user settings ....
[21:03]  * sistpoty coughs at 4.* *g*
[21:04] <sistpoty> but maybe I just haven't properly adjusted yet to the new kde world order *g*
[21:04] <jdong> ScottK: grin :)
[21:05] <ScottK> sistpoty: It's getting there pretty well with 4.2.
[21:05] <sistpoty> ScottK: good to know... I'll check (as in upgrade) every now and then ;)
[21:07] <sistpoty> (and btw.: back when 3 was out, I felt 2.? somewhat better, but funnily, I wouldn't want to look back at 2.* nowadays)
[21:09] <sistpoty> ScottK: I assume it's not possible to sync from debian/new?
[21:10] <ScottK> sistpoty: No, since packages in New aren't publically available.
[21:10] <sistpoty> ah, just what I thought, thanks
[21:10] <ScottK> It's usually possible to fish the packaging out of a VCS somewhere or ask the maintainer for it.
[21:11] <ScottK> Then make a -0ubuntu1 version  of it.
[21:11]  * sistpoty asks myself as maintainer and even better myself as upstream as well *g*
[21:11] <ScottK> ;-)
[21:11]  * sistpoty gives himself OK
[21:11] <ScottK> I did this myself for one package.
[21:11] <sistpoty> heh
[21:11] <ScottK> It's still in New after over a month.
[21:11] <ScottK> So I'm glad I didn't wait.
[21:11] <sistpoty> ok, then I guess you're in the queue above me
[21:12] <sistpoty> (only 1-2 weeks)
[21:14] <sistpoty> crap... I uploaded the *wrong* orig.tar.gz (a local built one instead of the released one)
[21:14] <sistpoty> always these upstream maintainers *g*
[21:14] <ScottK> sistpoty: I can reject it. What package?
[21:15] <sistpoty> ScottK: fauhdlc
[21:15] <sistpoty> ScottK: thanks a lot... I'll respin with the proper tarball
[21:16] <ScottK> sistpoty: Rejected.
[21:16] <sistpoty> thanks ScottK
[21:16] <ScottK> You're welcome.
[21:28]  * sistpoty looks at http://www3.informatik.uni-erlangen.de/Research/fauhdlc/downloads/MD5SUMS.asc to be safe :)
[21:42] <slytherin> ScottK: do you have time to process a sync?
[21:42] <ScottK> slytherin: I can't do sync's from the lP U/I.
[21:43] <slytherin> ScottK: What other ways are possible?
[21:43] <ScottK> Yes, just follow the regular process.
[21:45] <sistpoty> ScottK: can you new a package? fauhdlc (now with proper orig.tar.gz) would be waiting and is completely uncontroversial in regards to copyright, as I wrote all files (and only a co-worker touched a few files recently)
[21:49] <slytherin> ScottK: The package is already in the ubuntu-archive queue. But I am waiting for the package to be synced to evaluate fop merge/sync. That is why I asked you.
[21:50] <slytherin> asomething: deluge sync acked
[21:50] <asomething> slytherin: thanks!
[21:51]  * Laney spied some more ajax on LP just now
[21:51] <Laney> (subscribers list)
[21:52] <ScottK> I see.
[21:52] <ScottK> I may be abel to get to them in a bit.
[22:06] <RainCT> Laney: Uhm, did they get ride of the tags?
[22:07] <Laney> wha?
[22:07] <RainCT> I don't see the tags list anymore
[22:07] <RainCT> great :D
[22:07] <Laney> I still see them
[22:07] <Laney> might be the greasemonkey scripts though
[22:19] <AndrewGee> Hey all. Any MOTUs available to review my package - gpxviewer - It's an application that allows users to look at GPS traces files in GPX format. Thanks :) http://revu.ubuntuwire.com/details.py?package=gpxviewer
[22:30] <Laney> http://launchpadlibrarian.net/22559597/gtranslator_1.9.4-1.build2 why would this ftbfs happen, anyone?
[22:31] <Laney> (I know that adding liblaunchpad-integration-dev fixes is, but why is that necessary for a synced package?)
[22:31] <Laney> s/s is/s it/
[22:36] <sistpoty> Laney: I assume seb128 would now the answer
[22:36] <Laney> mm
[22:36] <Laney> pochu is subscribed to the bug anyway ;)
[22:36] <Laney> he knows all about gnome
[22:37] <sistpoty> Laney: probably on a rdepends of liblaunchpad-integration-dev (or a different binary from launchpad-integration) is wrong in regards to depends
[22:41] <sistpoty> hm... somehow dist-upgrade wasn't kvirc friendly *g*
[22:41] <sistpoty> (and I timed out)
[22:42] <maxb> Laney: I suppose one of the .la files pulled in directly or indirectly via the -l options eventually references launchpad-integration
[22:42] <maxb> grep in the pbuilder environment, maybe?
[22:42] <Laney> maxb: Yeah. Does that indicate a missing depends?
[22:42] <sistpoty> Laney: did you get my response?
[22:42] <Laney> sistpoty: I did, thanks
[22:43] <sistpoty> Laney: that one that a depends was missing from a rdepends of lp-integration? or the former one?
[22:43] <Laney> I need that pbuilder hook that drops you into the environment on a ftbfs
[22:43] <Laney> sistpoty: both!
[22:43] <sistpoty> ok :)
[22:43]  * Laney will grep it up
[22:44] <sistpoty> different question at everyone: the current list where motu-release delegates power is http://paste.ubuntu.com/117858/... is s.th there outdated/do we need more delegations?
[22:45]  * sistpoty admits to have lost oversight over derivatives
[22:57] <ScottK> sistpoty: There's a wiki page somewhere.
[22:58]  * ScottK doesn't recall where
[22:58]  * sistpoty checks google
[22:59] <vorian> Laney: http://paste.ubuntu.com/117866/
[23:00] <Laney> vorian: I found a similar one on the wiki, thanks
[23:00] <Laney> (will that cd line work with pbuilder-dist?)
[23:04]  * sistpoty gets angry at the wiki for *not* hiding what he looks for
[23:04] <sistpoty> erm. for *hiding*
[23:06] <nhandler> Do we have any real policy about what types of packages can be added to the repositories? Somebody uploaded a meta package to REVU that simply installs all of the packages they like to use. I would love to be able to point them to some wiki page that explains what types of packages are appropriate instead of just archiving the upload
[23:13] <sistpoty> nhandler: I assume meta-packages are reserved for derivatives (now don't ask me what derivatives are... as I'd appreciate a pointer myself on this *g*)
[23:14] <sistpoty> nhandler: but in general: package w.o. files in a binary package -> reject
[23:15] <nhandler> sistpoty: Did you send a message before "nhandler: but in general: packages w.o. files in a binary package -> reject"?
[23:15] <sistpoty> nhandler: yep...
[23:15] <sistpoty> nhandler: I assume meta-packages are reserved for derivatives (now don't ask me what derivatives are... as I'd appreciate a pointer myself on this *g*)
[23:16] <ScottK> I think there's a general requirement that a package be potentially interesting/useful to a range of people.
[23:16] <nhandler> sistpoty: Is there actual policy saying that? Or is it more of an unwritten policy?
[23:17] <ScottK> George's favorites isn't in that catagory.
[23:17] <ScottK> nhandler: The other option is to just choose to ignore it.
[23:17] <ScottK> In 6 days, it's not a concern for months.
[23:18] <sistpoty> nhandler: binaries w.o. files -> archive admins choice (and I recall rejects for it). derivatives allowed meta-packages: no written policy AFAIK. So no, there's nothing written... at least to my knowledge
[23:18] <sistpoty> nhandler: but maybe debian policy nowadays says s.th. about binaries w.o. files
[23:19]  * slytherin plans to upload a package which pulls all java packages. :-P
[23:19] <savvas> java-splatter
[23:19] <sistpoty> haha
[23:19] <savvas> :)
[23:20] <slytherin> actually it is a long term plan. I am going to create a jubuntu-desktop package. :-D
[23:21] <sistpoty> slytherin: I guess you should first find out how to get a derivative accepted (and then tell me where the *.....* list of official derivatives is *g*)
[23:21] <savvas> in a long term plan, I see Sun acquiring slytherin :)
[23:21] <maxb> "binaries without files" .... even a metapackage needs a changelog, though?
[23:22] <slytherin> savvas: I wish
[23:22] <sistpoty> maxb: I mean w.o. files as in "/usr/share/doc/<package>/<common_files> excluded"
[23:23] <savvas> maxb: I think you can link one changelog for all the resulting binaries, I'm not sure though
[23:23] <ScottK> We have metapackages for derivatives that are not built out of the official build system.
[23:23] <sistpoty> maxb: otherwise it couldn't even enter the archive (e.g. w.o. changelog.Debian.gz or copyright()
[23:23] <ScottK> So I don't think there is a list of official derivatives.
[23:23] <ScottK> Ichthux and Ubuntu Muslim Edition are two I know of.
[23:23] <savvas> metapackages derived from dummy packages, right?
[23:23] <sistpoty> ScottK: that's the term found on ubuntu.com.... not my idea :P
[23:24] <ScottK> OK.
[23:24]  * directhex starts work on zoroastrian edition
[23:25] <ScottK> We have Ubuntu, Ubuntu Server, Kubuntu, Xubuntu, Mythbuntu, and Ubuntu Studio that do their CD images out of the Canonical infrastructure (plus MID, netbook remix, etc).
[23:25]  * sistpoty starts to wonder if motu-release needs greater power to reject wherever MOTU packages want to go where no other MOTU packager went before *g*
[23:25] <ScottK> Those are all definitely 'official' for most any definition of official you'd want to pick.
[23:25] <ScottK> sistpoty: I think for New packages we can leave that to the archive admins.
[23:25] <sistpoty> hehe
[23:26] <ScottK> Where MOTU release, I believe, may need to weigh in is on stuff they'd never see.
[23:27] <sistpoty> as in new upstream versions uploaded w.o. ack?
[23:29] <sistpoty> ScottK: do we care about linking against openssl w.r.t GPL-2+ in ubuntu?
[23:30] <sistpoty> (i.e. w.o. exception)
[23:30] <ScottK> I think we do.
[23:30] <ScottK> I've certainly downchecked packages for it on REVU.
[23:30] <sistpoty> ScottK: ok, then fqterm is out
[23:58] <sistpoty> is Brendt Wohlberg<EMAIL_ADDRESS>around?


 arraybolt3: now start uploading XD
[00:36] <arraybolt3> heh, got my equivalent of $dayjob on the other line right now :P so give me a bit
 No worries ;)
[05:24] <arraybolt3> Has anyone already uploaded libfm-qt? And also where can I see the NEW queue so I can answer these questions for myself later?
[05:26] <arraybolt3> nvm, found it for myself, libfm-qt still needs uploaded
[05:31] -queuebot:#lubuntu-devel- New binary: libfm-qt [amd64] (noble-proposed/universe) [1.4.0-0ubuntu1] (lubuntu)
[05:32] -queuebot:#lubuntu-devel- New binary: libfm-qt [s390x] (noble-proposed/universe) [1.4.0-0ubuntu1] (lubuntu)
[05:32] -queuebot:#lubuntu-devel- New binary: libfm-qt [armhf] (noble-proposed/universe) [1.4.0-0ubuntu1] (lubuntu)
[05:32] -queuebot:#lubuntu-devel- New binary: libfm-qt [ppc64el] (noble-proposed/universe) [1.4.0-0ubuntu1] (lubuntu)
[05:34] <arraybolt3> Is there any special process involved in getting new binaries into the development release? I don't think https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages has any relevant information on that.
[05:34] <arraybolt3> (new binaries from existing source packages I mean)
[05:35] -queuebot:#lubuntu-devel- New binary: libfm-qt [arm64] (noble-proposed/universe) [1.4.0-0ubuntu1] (lubuntu)
[06:08] -queuebot:#lubuntu-devel- New binary: libfm-qt [riscv64] (noble-proposed/universe) [1.4.0-0ubuntu1] (lubuntu)
[06:21] <guiverc> just noting this, but I've received a report that Lubuntu noble 'hung' during install  (~30 mins to install to ssd system; 5-10 for ubuntu desktop).. another reported lubuntu took far longer than xubuntu ; neither person (#ubuntu-next) reported bugs..
[06:27] <arraybolt3> We've had a bunch of install problems recently right? I'll take a look tomorrow and see if there's something to be sorted out.
[06:28] <arraybolt3> Maybe also tackle some other items on The List other than just the LXQt upgrade and the network and Bluetooth managers.
[06:29] <guiverc> i was just noting it... we can 'monitor' at this stage.. I did an install earlier today & all was good (7 mins, but I have no comparison for the time)... repeated install with encryption & failure-to-install...   install issues maybe need attention (with slow boot we can wait until bug report filed)
[06:29] <guiverc> we're very early in the cycle
[06:30] <arraybolt3> Yeah. Still, no install is no bueno
 arraybolt3: You have upload access to do binary NEW for packages you already have upload access to. You'll have access for source NEW once you're a MOTU
[15:38] <R> When I try to install Lubuntu on new modern machines without a CD, it crashes because it is searching CD. I tried to correct the source file - comment the rows with cd. Refresh and try again. But the problem persists. Is there a solution to this problem? I want Lubuntu on my machines!
[15:41] <kc2bez> It isn't really looking for a physical CD. This question belongs in the support channel though.
[15:42] <kc2bez> !support | R
[15:59] <R> Sorry for the second asking, but i am lost your answer! when trying to install lubuntu on new modern machines (without tcd)- it faults, because it is searching for CD! I trying to edit source file - I comments rows with cd and only web is available! But it is stil crashed - the problem persist! Is there a solution to this issue?
[16:00] <kc2bez> Let's move this to the support channel please.
[16:01] <R> Ok, Thank you!
[19:13] <tsimonq2> arraybolt3: Yo, so do we have some testing yet as to whether we'll need runtime deps too? https://git.lubuntu.me/Lubuntu/libfm-qt-packaging/commit/d5ecfb6681f6624ee64a78d435b15b03e2ce8955
[19:13] -ubottu:#lubuntu-devel- Commit d5ecfb6 in Lubuntu/libfm-qt-packaging "Add lxqt-menu-data as a build dep"
[19:13] <tsimonq2> arraybolt3: I'll upload as-is (assuming I don't find anything else) simply to move the needle forward, but we should keep an eye on it.
[19:13] <arraybolt3> I already uploaded that :)
[19:14] <tsimonq2> I didn't even check yet ;)
[19:14] <arraybolt3> I thought adding a build dep also pulled in a runtime dep if needed?
[19:14] <tsimonq2> I *think* there's some automagic there?
[19:14] <arraybolt3> ${misc:Depends}
[19:14] <tsimonq2> Would be worth double checking, though. Just something to keep an eye on.
[19:14] <arraybolt3> kk
[19:15] <arraybolt3> once the NEW binary gets through I can start uploading Stage III stuff
[19:15] <arraybolt3> I'm using a PPA in the mean time to accelerate things and am up to pavucontrol-qt
[19:18]  * Eickmeyer triages bug report.... bug 2043310
[19:18] -ubottu:#lubuntu-devel- Bug 2043310 in calamares (Ubuntu) "Calamares installs rather slow" [Undecided, New] https://launchpad.net/bugs/2043310
[19:19] <tsimonq2> XD
[19:19] <Eickmeyer> "feels rather slowly (around 30min) and then finishes well."
[19:19] <Eickmeyer> 💀
[19:19] <tsimonq2> ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
[19:19] <tsimonq2> I know exactly what that is
[19:20] <Eickmeyer> I was about to chalk it up to "opinion" based on hardware performance. 💀
[19:22] <tsimonq2> Responded.
[19:24] <Eickmeyer> 🤌
[19:24] <Eickmeyer> (for lack of snapping fingers)
[20:02] <tsimonq2> arraybolt3: https://lists.ubuntu.com/archives/lubuntu-devel/2023-November/002003.html <3
[20:03] <tsimonq2> arraybolt3: https://twitter.com/LubuntuOfficial/status/1723793721328582912 <3
[20:27] <arraybolt3> tsimonq2: thanks for the vote of confidence :)
[20:27] <tsimonq2> Of course, Aaron :)
[21:02] <kc2bez> I concur with tsimonq2
[21:07] <tsimonq2> git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/lubuntu/commit/?id=a598d2b00869f80c0ac1229f1958485751c78883
[21:07] -ubottu:#lubuntu-devel- Commit a598d2b in ~lubuntu-dev/ubuntu-seeds/+git/lubuntu "Demote quite a bit of packages to recommends."
[21:07] <tsimonq2> https://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/lubuntu/commit/?id=c22a02182e96f682bf04f971c464e9b1ee90ee3c
[21:07] -ubottu:#lubuntu-devel- Commit c22a021 in ~lubuntu-dev/ubuntu-seeds/+git/lubuntu "Add lxqt-menu-data as a depends, in case it doesn't get pulled in by another package HEAD noble"
[21:13] <kc2bez> Quite a bit of packages. Much packages. :P
[21:27] <tsimonq2> All of the packages. :P
[21:27] <tsimonq2> https://launchpad.net/ubuntu/+source/lubuntu-meta/24.04.1
[21:28] <kc2bez> That should setup minimal nicely.
[21:29] <tsimonq2> I think so, too.
[22:00] <guiverc> it'll make many end-users happy too (comments on 'bloat' etc)
[22:01] <tsimonq2> If anyone has further feedback on demotion/promotion between depends/recommends, as well as options for the minimal install and pkgselect, let me know.
[22:01] <tsimonq2> Also, I will be updating the wording to match the new Ubuntu Desktop Installer (default install vs full install)
[22:01] <tsimonq2> Maybe have three options, default, minimal, full
[22:01] <tsimonq2> *shrug*
[22:02] <tsimonq2> I'll play with it, any opinions in either direction would be cool
[22:11] <tsimonq2> arraybolt3: I sent you a Matrix PM for you to look at, at your convenience, with more details/next steps.
[22:12] <tsimonq2> arraybolt3: In the meantime, I'm going to go through what you've already prepared for packaging, and continue the LXQt 1.4 transition.
[22:12] <tsimonq2> arraybolt3: If you're going to be on tonight, just let me know so we can coordinate. Same with wxl, teward, or kc2bez if you'd like to assist.
[22:17] <tsimonq2> A little promo for the manual :D https://twitter.com/LubuntuOfficial/status/1723827150548000985
[22:19] <tsimonq2> Reviewing lxqt-qtplugin.
[22:19] <tsimonq2> I'm literally just skimming a git diff to make sure I don't see anything crazy, and then uploading. ;)
[22:19] <tsimonq2> You know better now. :P
[22:22] <tsimonq2> https://launchpad.net/ubuntu/+source/lxqt-qtplugin/1.4.0-0ubuntu1 will FTBFS due to depwait
[22:24] <tsimonq2> This one *shouldn't* FTBFS due to depwait: https://launchpad.net/ubuntu/+source/obconf-qt/0.16.3-0ubuntu1
[22:25] <tsimonq2> Oh shoot, I almost forgot to concurrently upload to Backports.
[22:31] <tsimonq2> This one should also be good: https://launchpad.net/ubuntu/+source/pavucontrol-qt/1.4.0-0ubuntu1
[22:33] <tsimonq2> libfm-qt FTBFS on all Jammy arches. Very nice, very cool, great success.
[22:35] <tsimonq2> Just waiting for armhf to finish building in Backports Staging, so I can update symbols.
[22:36] <tsimonq2> (Note for other packagers: this is something that's prone to happen when Backporting. Jammy uses a completely different GCC version, Qt version, and KDE Frameworks version than Noble, so some symbols are bound to change.)
[22:36] <arraybolt3> depwait - meaning dependncies aren't there yet, right?
[22:37] <tsimonq2> Correct. ;)
[22:37] <arraybolt3> kk cool
[22:37] <arraybolt3> yeah that's why I haven't uploaded the Stage III things yet
[22:37] <tsimonq2> Right, no I get it :)
[22:37] <tsimonq2> If nothing else, we can get some testing for Backports.
[22:40] <tsimonq2> As an example of the aforementioned symbols diff:
[22:40] <tsimonq2> - (arch=!armel !riscv64)_ZTSSt23_Sp_counted_ptr_inplaceIKN2Fm12BookmarkItemESaIvELN9__gnu_cxx12_Lock_policyE2EE@Base 1.1.0
[22:41] <tsimonq2> +#MISSING: 1.4.0# (arch=!armel !riscv64)_ZTSSt23_Sp_counted_ptr_inplaceIKN2Fm12BookmarkItemESaIvELN9__gnu_cxx12_Lock_policyE2EE@Base 1.1.0
[22:41] <tsimonq2> > typeinfo name for std::_Sp_counted_ptr_inplace<Fm::BookmarkItem const, std::allocator<void>, (__gnu_cxx::_Lock_policy)2>
[22:41] <tsimonq2> + (arch=!riscv64)_ZTSSt23_Sp_counted_ptr_inplaceIN2Fm11PlacesModelESaIS1_ELN9__gnu_cxx12_Lock_policyE2EE@Base 1.4.0
[22:41] <tsimonq2> > typeinfo name for std::_Sp_counted_ptr_inplace<Fm::PlacesModel, std::allocator<Fm::PlacesModel>, (__gnu_cxx::_Lock_policy)2>
[22:42] <tsimonq2> Let's see if this upload fares any better: https://launchpad.net/~lubuntu-dev/+archive/ubuntu/backports-staging/+sourcepub/15378536/+listing-archive-extra
[22:42] <tsimonq2> oh wait hurr durr
[22:42] <tsimonq2> I need to remove all those MISSING lines XD
[22:42] <tsimonq2> sec, fixing in a ~ppa3
[22:42] <arraybolt3> If you'd like, pavucontrol-qt probably also won't die in depwait
[22:43] <arraybolt3> I can snag that myself in a sec though
[22:43] <tsimonq2> Already done, I think
[22:44] <tsimonq2> Kay, this one should be it: https://launchpad.net/~lubuntu-dev/+archive/ubuntu/backports-staging/+sourcepub/15378537/+listing-archive-extra
[22:45] <tsimonq2> arraybolt3: You're more than welcome to upload anything; the archive is special compared to PPAs in that depwait packages are automatically retried when they become resolvable.
[22:45] <tsimonq2> arraybolt3: As long as you can verify with a local build that Lintian's clean and it doesn't FTBFS, I'm cool with you uploading straight to the archive + to Backports Staging.
[22:45] <arraybolt3> Oh, I didn't know that depwaits were automatically rebuilt.
[22:45] <arraybolt3> That's why I was holding off :P
[22:46] <arraybolt3> kay, I guess I'll get to explo...ER...packaging then.
[22:46] <tsimonq2> arraybolt3: Literally, all I'm doing for Backports Staging is taking the exact source I uploaded, checking out a brand new backports/jammy branch, creating a new changelog entry appending ~ppa1 to the end of the existing (NOT greater!) version number with Jammy as the codename, then uploading that and force-overriding the Backports branch.
[22:46] <tsimonq2> Hah, cool :D
[22:46] <arraybolt3> oh nice I somehow deleted libfm-qt out of my PPA 🤦
[22:47] <tsimonq2> Well, you have access to ~lubuntu-dev's PPAs now too ;)
[22:47] <arraybolt3> handy, thanks!
[22:48] <tsimonq2> As a general rule of thumb, unless we're talking emergency-level fixes, upload to Backports Staging, wait for it all to build and publish, copy it over to Backports, then *once you verify the copy is successful* you can nuke it from Backports Staging (without waiting for the publisher on Backports to finish).
[22:48] <tsimonq2> I just did that with Vim, actually :)
[22:49] <tsimonq2> With the LXQt 1.4 stack, in lieu of Britney not being set up for us org-wide, let's wait for a round of manual QA testing, and copy it over all at once.
[22:50] <arraybolt3> sounds good
[22:50] <arraybolt3> alright, got libfm-qt back where it goes in my PPA so I can continue working through the stack
[22:50] <tsimonq2> Sweet!
[22:51] <arraybolt3> And our next victim is...
[22:51] <arraybolt3> qps
[22:51] <arraybolt3> here we go
[22:51] <tsimonq2> I'll take a lap + some fresh air, so go ahead and tackle whatever you'd like. I'll sync up with you in a sec, just post status updates :)
[22:51] <tsimonq2> If both of us are on this, we should be able to crank it out fairly quickly.
[22:52] <arraybolt3> sounds good
[22:54] <arraybolt3> qps needs added to our list of "packages to make a new branch for when we start developing a new release"
[22:54] <arraybolt3> it's still on a Mantic branch
[22:54] <arraybolt3> anyways, fixing
[23:03] <arraybolt3> Days since I had to put a full copy of the CC-BY-4.0 license in a package: 0
[23:03] <arraybolt3> Seriously, this needs to be a default license in Debian.
[23:03] <arraybolt3> er, a common one I mean
[23:05] <tsimonq2> Hah yeah, I can agree with that one. I really appreciate your attention to detail when it comes to copyright.
[23:05] <tsimonq2> Let's see... I'll grab...
[23:05] <tsimonq2> qtermwidget
[23:05] <arraybolt3> also, can we add bumping build dep versions to https://phab.lubuntu.me/w/packaging/packaging_for_new_upstream_releases/?
[23:06] <arraybolt3> I don't think I can do that myself
[23:07] <tsimonq2> .
[23:08] <arraybolt3> thanks :)
[23:08] <tsimonq2> Of course :)
[23:09] <arraybolt3> oh boy, arm(64|hf) and s390x builders must be slammed
[23:09] <tsimonq2> If you upload to Noble, that gets priority over all those PPA uploads you see queued. Those will build faster.
[23:10] <tsimonq2> As for Backports, yeah it might go towards the back of the line, but I'd imagine there's some prioritization in there.
[23:10] <arraybolt3> anything that won't depwait on libfm-qt will get that advantage :)
[23:10] <tsimonq2> Right ;)
[23:10] <arraybolt3> I think qps probably will survive though
[23:10] <tsimonq2> I mean, most of them should, to be honest. At least, the leafier packages.
[23:19] <arraybolt3> qps go brrr
[23:20] <arraybolt3> hopefully should be building soon
[23:21] <tsimonq2> Good timing, qtermwidget was just uploaded as well.
[23:21] <tsimonq2> I can take screengrab?
[23:21] <arraybolt3> sure
[23:26] <tsimonq2> Packages to add on that list> screengrab too.
[23:26] <tsimonq2> arraybolt3: Do you have another one quite yet, or still chewing on what you have? :)
[23:26] <arraybolt3> Just finished the Jammy backport
[23:26] <arraybolt3> got to get the dog in and fed, brb
[23:26] <tsimonq2> I forget that I'm faster than you XD
[23:26] <tsimonq2> No worries
[23:27] <arraybolt3> I've broken things going too fast, so I try to err on the side of thoroughness :P
[23:27] <tsimonq2> No worries :P
[23:28] <arraybolt3> also I had an entire license to insert into the last package :P
[23:30] <tsimonq2> true, true
[23:34] <arraybolt3> *snatches lximage-qt
[23:34] <arraybolt3> *
[23:34] <tsimonq2> screengrab done, grabbing lxqt-about
[23:37] <arraybolt3> what in the world
[23:37] <arraybolt3> lximage-qt's copyright file has some issues :P
[23:37] <tsimonq2> ...oh?
[23:37] <arraybolt3>   8 License: GPL-2+ and LGPL-2.1+
[23:37] <arraybolt3> don't think that's a valid line :P
[23:37] <arraybolt3> or if it is it's certainly not one I've ever seen
[23:38] <tsimonq2> git blame that... is that #SimonsFault :P
[23:38] <arraybolt3> huh, though actually
[23:38] <arraybolt3> https://github.com/lxqt/lximage-qt/blob/master/AUTHORS
[23:38] <arraybolt3> so... it is accurate... but is it valid...
[23:38] <arraybolt3> idk what to even think of that, I'm guessing they were trying to summarize and didn't realize that was going to dual-license instead.
[23:39] <arraybolt3> also this gem:
[23:39] <arraybolt3> Copyright: 2013-2016 Hong Jen Yee (PCMan<EMAIL_ADDRESS>?
[23:39] <tsimonq2> Lmfao, I have no idea what LXQt upstream was thinking (as usual) XD
[23:39] <arraybolt3> that question mark is probably my fault
[23:40] <arraybolt3> but... I think I'm going to rebuild this from scratch. There's too much weird here.
[23:40] <tsimonq2> I don't think the builders are really hindering us, by the way. That's cool.
[23:40] <tsimonq2> Alright. :)
[23:40] <tsimonq2> I'm sure I'll get to a big hurdle eventually, right now I'm just breezing through the last bits for lxqt-about.
[23:41] <arraybolt3> Stamp of approval or disapproval please:
[23:41] <arraybolt3>   8 Comment: Yes, that's actually what upstream chose as the license. I don't get it
[23:41] <arraybolt3>   9  either.
[23:42] <tsimonq2> If it was me, I'd just keep the first sentence XD
[23:42] <tsimonq2> Also, looks like screengrab needs patching too:   Could not find a configuration file for package "KF5WindowSystem" that is   compatible with requested version "5.101.0".
[23:42] <tsimonq2> looking
[23:43] <arraybolt3> +1 on wording
[23:43] <arraybolt3> oh are you kidding me

[23:43] <arraybolt3> someone please make up my mind
[23:43]  * arraybolt3 goes and files an upstream bug
[23:48] <tsimonq2> omfg, lol
[23:48] <tsimonq2> That's terrible.
[23:48] <tsimonq2> I commend you again for your copyright analysis skills. :P
[23:49] <tsimonq2> Kay, this should fix screengrab: https://launchpad.net/~lubuntu-dev/+archive/ubuntu/backports-staging/+sourcepub/15378626/+listing-archive-extra
[23:49] <arraybolt3> woot
[23:49] <tsimonq2> I'll grab lxqt-admin next
[23:51] <arraybolt3> https://github.com/lxqt/lximage-qt/issues/645
[23:51] -ubottu:#lubuntu-devel- Issue 645 in lxqt/lximage-qt "Confusing and contradictory licensing information" [Open]
[23:53] <arraybolt3> I think I'm going to leave lximage-qt on the back burner and return to it once I get a reply, since I can't make a very useful copyright file until I know what on earth is happening here. GPL-2+ and LGPL-2.1+ is (I think?) equivalent to just GPL-2+, so until I know what's LGPL, I'm just going to add to the confusion if I finish it now.
[23:54] <tsimonq2> arraybolt3: This is kind of bad, if I was, say, an Archive Admin... but does the copyright really *change* between releases?
[23:54] <tsimonq2> arraybolt3: If it was a *regression* in copyright notices, I would say yeah, definitely hold off.
[23:54] <tsimonq2> arraybolt3: That being said, if it's shipped in a few releases, it's unfortunate, sure, but it shouldn't be a blocker for a new release.
[23:55] <tsimonq2> arraybolt3: Also, lximage-qt is a fairly small part of the LXQt stack, so if you *really* want to wait, we can. I'm going to leave the final judgement call up to you, fellow Lubuntu Developer :)
[23:56] <arraybolt3> I mean, I can probably do something with it in its current state, but assuming upstream is responsive (which they usually are), it'll be added work to regenerate the file now and then regen or tweak it again later.
[23:57] <tsimonq2> Fair enough, you could always leave it as-is for now, only doing year bumps.
[23:57] <arraybolt3> If we finish the rest of the stack and this is still left, I'll do it as-is, sound goo?
[23:57] <tsimonq2> Sounds good :)
[23:57] <arraybolt3> That's a good idea actually
[23:57] <arraybolt3> I'll just do your thing and we'll revamp later.
[23:57] <tsimonq2> Sounds good, no worries either way.
[23:58] <tsimonq2> Just don't forget to let me know what you tackle next so we don't dup work :D