[00:00] Howbidie! [00:09] im confused, say i need to patch a package. I download the current source. Untar it, make the orig, dh_make it, edit the source code as necsarry and then debuild. What do I then do with the source changes? I upload the diff.gz to LP, but what about the actual source changes? [00:10] doofy`: They're in the diff.gz. But that's not actually what you want to do. [00:11] so assuming i found a bug that needs fixed in LP what would i do? [00:12] https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff [00:12] There it is! [00:13] thats just changing stuff in the decsription under debian/control [00:13] is the same relevant for actual changes of source code? [00:13] doofy`: Yes. You generally want to use a patch system, but it's the same process. [00:14] patch system? [00:15] doofy`: Such as dpatch, quilt, or simple-patch-sys (for CDBS). [00:15] okay thats what I assumed [00:15] where do the patches get uploaded to? [00:16] They're in the debdiff. [00:16] (The patches end up in debian/patches, generally) [00:16] they arent actually in the diff.gz though are they? I looked through it an saw nothing of that sort [00:17] if they aren't, then something's gone wrong with your source package building [00:18] that's where all changes to the source are supposed to be placed; the orig.tar.gz is meant to be unmodified from upstream - or at least, unchanging in the archive for any given upstream version [00:20] I can get everything to work with no errors... I just don't really understand what I'm doing and how its relevant to actually going through and fixing a bug. The documentation seems a little lacking in that aspect [00:20] i suppose if i keep working on it ill figure it out, just started today [00:21] doofy`: if you want to patch an existing package: "apt-get source pkgname" to get an unpacked source directory, make your changes, add a new changelog entry (with dch -i), debuild -S to get a new source package, debdiff old.dsc new.dsc to get a debdiff [00:23] then upload the debdiff to LP? that was MUCH easier to follow than the doc :) thank you [00:24] I'll get some sleep now. I'll look at the package again after I wake up. Please advocate, unless you find something to complain about. http://revu.tauware.de/details.py?package=malbolge [00:25] Oh, and good night for now [00:38] hi === Pici` is now known as Pici === Pici is now known as Added === Added is now known as Pici [00:56] Why does lintian complain "W: jedit: unknown-section universe/editors"? [00:59] blueyed: it should be "editors" [01:02] pochu: thanks. But wasn't there something where you had to use "universe"?! I remember having to use section "universe/misc" or something similar for uploading to ppa. [01:02] blueyed: for a ppa, but not for the archive :) [01:03] blueyed: for ppa it's so it gets build-depends from universe or from whatever you specify in section [01:03] blueyed: but for the archive the component is handled via overrides AFAIK. [01:03] pochu: I see.. thanks. [01:07] But that may be "fixed" now for ppa.. IIRC I have not adjusted my latest virtualbox-ose-modules upload for ppa.. [01:24] blueyed: Correct, everything in PPA is now overridden to main. === keffie_jayx is now known as effie_jayx [01:31] I've got a question regarding the "package removal policy" when the package has not yet been removed from Debian. [01:32] I filed LP#175426 requesting the removal of "gengameng" in hardy since it is now superseded by flatzebra and has only ever been used by the burgerspace game. [01:33] unfortunately, i haven't been able to request the removal from Debian since the new burgerspace hasn't made it into testing. [01:33] Why does that stop you removing it from unstable? [01:34] Won't it stick around in testing until there are no rdepends? [01:34] Fujitsu: well, I'm not sure about that one and I'd rather not risk removing burgerspace entirely from Lenny... [01:37] I was thinking about subscribing ubuntu-archive to the bug to try to get it removed from hardy before it gets sorted out in Debian [01:39] according to LP#188292, it also fails to build from source, so I guess it wouldn't go into hardy anyways... === santiago-php is now known as santiago-ve [02:06] If you know (and like) jEdit, please review: http://revu.ubuntuwire.com/details.py?package=jedit :) [02:18] Heya gang [02:19] Howdy-ho [02:19] Hello ion_ [02:19] What’s up? [02:24] Watching the SuperBowl, doing year end close for work and looking at some packages. You? :-) [02:25] Superbowl was baseball, right? [02:25] I’m just resting and watching some crappy TV show. :-) [02:25] No superbowl is the "real" football ;-P [02:26] Ah, that. :-) [02:29] I don’t really know much about that sport, only that they guys are in clown suits and the game starts with one dude bending over, another sniffing his butt and the former throwing the ball to the latter. [02:29] haha [02:30] ...And that they stop the game for commercial breaks :P [02:31] A LOT :( [02:31] Or because someone dropped the ball. Or because someone *caught* the ball, or... ;) [02:31] Well, you can always fast-forward over the commercial breaks. And in my case, the sports, too. ;-) [02:32] cant fast forward live tv [02:33] Put it on pause, let your DVR cache it for ½ hr, then come back and fast-forward over the ads. :-) [02:33] can't watch it at church either [02:33] I'm not sure a 1/2 hour buffer would be sufficient. [02:34] how does everyone analyze diffs once they are posted to LP? Is there programs that allow you to compare the changes? [02:36] I tend to use "less" [02:36] A diff is already in a nice form to analyze. :-) [02:37] If it’s an interdiff with -p0, then patch the diff with it and compare with interdiff -p1 [02:38] the file is huge in this case :o but i suppose it was for a version update of brasero [02:38] You could filterdiff out anything that's not in debian/ [02:39] would you suggest getting a mentor... I'd love to contribute to ubuntu and i'd like to get working as soon as i can [02:40] I didn't have a mentor, but I suppose it depends on how you work. If you're happy to ask the whole channel questions you probably don't need a mentor. [02:40] i'd prefer to ask the channel questions :) so that answers it [02:41] RAOF, how long did it take you to actually be able to work on things dilligently? [02:42] Not too long, actually. I started out by finding bugs in packages I wanted to use, finding that upstream had a patch that fixed it, and uploading debdiffs to LP. [02:43] any advice to tell debuild to not package the emacs backup files (*~) ? [02:43] eddyMul: Remove them before debuilding? :) [02:44] RAOF: I've been doing that. It gets boring after a while.... :p [02:44] RAOF, finding the bugs through launchpad or what? [02:44] doofy`: As in "oh, crap. banshee appends a ", " to the end of all my files". [02:45] doofy`: Finding things that don't work like you want them to in software that *you* use. [02:45] Getting things that you care about to work is a lovely incentive :) [02:45] then you would just look for upstream versions of that software that had the necesarry modifications or would you actually do the coding? [02:46] The former; I'd look at the upstream bugzilla, and often someone else would have seen this and fixed it. [02:46] Or I'd report it to the upstream bugzilla, and someone would make a patch which I could then integrate into the Ubuntu package. [02:48] the people that are actually making the patches are the ones who work on specific projects usually, yes? [02:48] Indeed. And I've done a little work that way, too. [02:49] (Banshee's cd-error-correction hookup code is mine, for example) [02:50] neat [02:51] It was pretty simple, actually, and did something that I wanted. [02:51] Hurrah for open-source! [02:52] im trying to figure out what im really interested in haha so i can figure out what to contribute to [02:52] Yup. Start by working out what you're interested in :) [03:00] its amazing to me how all this stays organized [03:01] When everyone keeps scratching her own itch, the whole keeps improving. :-) [03:01] The amazing power of theoretical capitalism :) [03:02] doofy`: It's far from organized (at least where upstream development is concerned) [03:03] in some ways i feel im better suited working on some upstream project [03:03] You can certainly do both :-) [03:03] Improve some upstreams build environment ;-) [03:04] work on an upstream project and submit those patches for ubuntu :) === Pricey is now known as PriceChild [03:25] Would a MOTU be so kind as to give liblouis a look over? I'm the uploader, so one ack should be fine: http://revu.tauware.de/details.py?package=liblouis [03:25] And in turn, I shall review packages, starting in a few minutes. [03:26] TheMuso: I'll take a look. [03:27] RAOF: Thank you very much. [03:28] brb [03:29] Why must licesing suck? [03:31] RAOF: Yeah I know. I even asked upstream about this, and they said its all GPL v2. [03:32] Except for the exceptions and additional restriction, obviously. [03:32] Unless they're actually just meant to clarify things which are already implicit in the GPL. [03:33] (In which case it'd be nice for them to say that ;)) [03:36] Yeah. === boomer` is now known as boomer [03:37] Well, Sun's lawyers have to check that its all ok, and the guy who made it work with autotools said the code is fine, but yeah I know, its something I'm not sure of [03:37] A second opinion would be nice of course. [03:38] Is that what vcs-svn is meant to be used for? I thought vcs-svn was for when the packaging was in svn? [03:39] I don't know. [03:39] Hrm maybe you're right. [03:40] I think that https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023332.html supports my understanding, but it's not direct. [03:41] Yeah, I'll pull it then. [03:44] RAOF: If you aren't comfortable with the licesning, I understand. I don't like it much, but I'm told its GPL2, which is why I felt ok uploading it for review. [03:44] c [03:44] Ugh? [03:44] :) [03:46] TheMuso: If Sun thinks its valid GPL, then I'm happy enough with that. You can at least say you investigated it to the best of your ability if the archive-admins reject it :) [03:47] Yeah I know [03:47] I'll wait for a second opinion however, if one is forthcoming. [03:51] why does pbuilder download packages? http://pastebin.ca/890856 [03:52] To satisfy dependencies [03:53] so, it didn't create a .deb file, how do I know what to fix? [03:54] I'm looking at another package as an example and I'm confused as to what I need to change [03:54] sun is normaly pretty decient about lic concerns , if they say gplv2 i would trust it imho [03:55] are there any more detailed instructions for packaging besides those on the wiki? [03:55] firefly2442: http://www.debian.org/doc/maint-guide/ [03:55] imbrando1: Yeah I know. However, you should take a look at it, as there is an "all rights reserved" clause in the license. [03:57] Hrm. ushare wasn't uploaded. Unless someone is doing that now, I'll do so. [03:57] TheMuso: Any checks I can run on the binary? I'm not really sure what it's meant to do :) [03:57] RAOF: What do you mean exactly? The binaries are only for testing the library. [03:58] I'll just pass on the binary-testing, then. You presumably know that they work :) [03:58] Yeah, I was running all of them to see if I could get docs outa them. Doing tests just to make sure they worked was part of it. [03:58] Yay, got my first package into Debian [03:58] LucidFox: Cool. [03:59] Hm. Thinking of which, I wonder if StevenK would like to close an ITP for me :) [04:00] StevenK is a DD? === imbrando1 is now known as imbrandon [04:00] Yup. [04:00] LucidFox: correct ( as are alot of ubuntu devs ) [04:00] LucidFox: but i wouldent let him hear you accuse him of being a DD :) [04:00] lol [04:01] TheMuso: Thinking of which, want to have another Sydney MOTU dinner sometime in the next couple of weeks? [04:02] Well, I have another package on m.d.n needing sponsorship - I was wondering if he could help [04:03] LucidFox: your better off mailing the mentors ml, StevenK rarely sponsors packages he isnt involved with [04:04] but i cant speak for him, just givein you a heads up [04:04] Ah [04:04] slangasek: lucas took care of the QA upload before I left for the Superbowl part I was at. Thanks though. [04:04] RAOF: Sure. You know there was one recently? [04:04] I didn't attend, but there was oe. [04:04] ScottK: pats lost :( [04:05] imbrandon: Aren't Boston and NYC pretty equidistant from KC? [04:05] * imbrandon as a temp pats fan :) [04:05] * ion_ misread that and thought imbrandon lost his pants. [04:05] s/as/was [04:09] Please review http://revu.tauware.de/details.py?package=sadms [04:18] Hmm. Does it make sense to advocate a REVU package if the same software, but packaged by a different person, is waiting in Debian's NEW? [04:18] (specifically talking about libgee) [04:18] Not really, IMO. [04:18] That's the second time that's happened recently, though. [04:20] RAOF: But if you want to ask the others if they're interested, I'd be happy to make the trip down to attend. [04:20] We might want to suggest more strongly people submitting packages to revu file ITPs, too. [04:20] * minghua wonders if the Debian NEW package has an ITP. [04:20] TheMuso: Cool. I was in Perth for the last one, I now remember. [04:20] yup, it does [04:21] Where can one find out about how to submit an ITP? I intend to submit my package to Debian also. [04:21] www.debian.org/wnpp I think [04:21] And, if not a maintainer, should I use mentors to host it? [04:21] I use emacs' reportbug, myself. [04:21] minghua: Thanks. [04:21] http://www.debian.org/devel/wnpp/ [04:21] LucidFox: Thanks. [04:22] Yeah, that's the correct link. :-P [04:22] slomo, perhaps you could look at the diff between your libgee and the one on REVU, and merge them once it passes NEW? [04:23] Emacs's reportbug was bad last time I knew it. [04:24] I don't use Emacs or reportbug, I file all bugs by mail [04:26] Does a Debian package need to pass NEW when moving from contrib to main? [04:26] No AFAIK. [04:27] You need a sourceful upload for contrib to main transition, unlike Ubuntu's main and universe. [04:40] You also need FTP masters to take some action on over-rides too, I believe. [04:40] or maybe that's just priority [04:55] yeah, I think it does end up in NEW in Debian [05:09] Oh. Sorry for the misinformation. === greeneggsnospam is now known as jsgotangco [05:31] hello all... I'm interested in doing some dev work, but specifically interested in user-interface design/development. Can someone recommend a good mailing list to join, or some pointers on where to go/who to contact? Thanks. [05:32] richbl: It sounds like you may be more interested in upstream development? Most of the Ubuntu's interface comes straight from GNOME. [05:34] RAOF: yeah, I've been tracking GNOME dev, and just got on their MLs... is there any UI work done here? [05:34] Although there certainly are Ubuntu-only projects; the installer (Ubiquity), displayconfig-gtk, those sort of things. [05:34] Obsolete library removal bug filed. Horray! [05:35] RAOF: I'll take a look at those specifically. Is there a UI "lead" I should contact? [05:35] (for Ubuntu, that is) [05:35] Not as far as I'm aware. [05:35] It's entirely possible that I just haven't been paying attention in the right places, though :) [05:35] richbl, if you are interested in improving the UI of ubiquity, pop in #ubuntu-installer and you can talk to evand and cjwatson [05:35] richbl: Do you have any interest in KDE? [05:36] richbl, although there was a share of usability that was discussed at UDS this last october [05:36] richbl, so there are pending changes [05:36] ScottK2: that's a good question... personally, I'm more familiar with Gnome and have more of a history there... but I'd be interested in at least following up with folk(s) on the KDE side of things [05:37] ScottK2, don't steal him! he wanted to come to us first :) [05:37] What's the process--in general--for handling UI consistency between us (dev) and designers (them) :) [05:38] richbl: The reason why I ask is in Kubuntu we've got a no kidding U/I usability expert for KDE doing a fair amount of work with us and so there's actual studies that you can base work off of. [05:38] For a quick background... I'm originally a dev from Microsoft (uh... I hope I don't get beaten)... did some dev/UI work on Flight Simulator a while ago (long long ago, it was Word 1.0) [05:38] Back when Flight Simulator was cool. [05:39] BTW, I wrote my college thesis with Word 1.0 [05:39] I was kinda' responsible for getting FS from char to Windows (at least a good portion of UI) [05:40] ScottK2: cool... I still have an easter egg lurking in Winword 6.0 (pre-Office, IIFC) [05:41] richbl: ooo nice. [05:41] richbl: Nice to see you embracing the open source movement. [05:41] I never used the pre-Office Word on Windows. Only on Mac. [05:41] Good to know there's someone on KDE who does UI/consistency stuff... anyone on the Gnome side that does similar? [05:42] richbl: For KDE, there's some good linkage here: http://weblog.obso1337.org/2008/2007-kde-usability-reports/ [05:42] richbl: If that leads you to ideas, you can certainly join us on #kubuntu-devel. [05:42] TheMuso: yeah... I still have friends at MS these days, but my personal feeling is that the company just got too big... and it lost the "campus" feel... [05:43] richbl: For a start, GNOME has the GNOME interface guidelines, although thats not always looked upon favourably by Ubuntu devs. [05:43] i may be mistaken, but I thought mpt did usability for GTK stuff? [05:43] superm1: afaik he does. [05:43] ScottK2: thanks, I'll check it out... [05:43] yeah i remember he sat in on the installer usability session [05:43] he also did a usability test on launchpad with me at UDS. [05:43] superm1: same. [05:44] Very cool that folks do usability testing... didn't know that... very cool. [05:44] Yeah. Of course he's an LP developer which means he's alsmost certainly unqualified for U/I design IMO. [05:44] what's LP dev? [05:44] https://edge.launchpad.net/~mpt [05:44] Launchpad developer [05:45] TheMuso: regarding the Gnome interface guidelines, any reason why they're not followed? [05:45] Launchpad is Canonical's distribution management system [05:45] Scott: gotcha... still getting my feet wet with tools [05:45] Ubuntu (no suprise) uses it. [05:45] Understand. [05:45] every FOSS project seems to have their own way ;) [05:46] Yes, well Launchpad isn't a FOSS project (just to be clear). [05:46] Which is part of what Launchpad is meant to solve. [05:47] gotcha... I'll take a look and see... I think I've filed bugs through it... if that's the same tool for public bug filing... [05:47] And is what's given as the reason it's *not* open-source (yet, apparently). [05:48] There are lots of reasons given, none of which make a lot of sense to me, but don't worry, I'm not going to do another 4 hour rant on LP should be Free. [05:48] Awwww! [05:49] HA! I think I'll politely step around the issue for the moment... [05:49] No problem. [05:50] * ScottK2 wonders if it's a coincidence that LP is suddenly oopsing on me. [05:50] So... to sum... I have some actions to follow-up on the Kubuntu side (another IRC channel) ... anything I can do for follow-up on the Gnome side? [05:50] (pardon me if I've missed anything in the scroll) [05:50] richbl, i'd say you should try to talk to mpt if you get a chance [05:51] he can point you in the right direction [05:51] ah yes... got his page up now [05:51] thanks [05:51] best of luck [05:52] Please polish my favourite GNOME :) [05:52] TheMuso, if you're still around... you had mentioned that the Gnome interface guide really doesn't seem to get followed... can you elaborate please? Is it a bad guide, or else? [05:55] RAOF: Are you familiar with the mesa library packages? [05:56] tonyyarusso: Are you around? [05:56] ScottK2: I've played with building nouveau's DRI? I'm not particularly familiar with the packaging, though. [05:56] OK. I'm trying to understand some transitions to figure out what to do with a merge. [05:57] I'm gonna ask anyway. Maybe I'll get lucky [05:57] Heh. [05:57] xlibmesa-gl-dev xlibmesa-gl xlibmesa-glu are Sarge -> Etch transitional packages, but they don't appear in Ubuntu until Edgy. [05:59] So I was hoping you'd know if we need to keep depends on those for Hardy or not. It doesn't seem to me that it'd help Dapper - Hardy. [05:59] But I've really no idea. [05:59] I don't know either, sorry. [05:59] OK. [05:59] Maybe someone else ... [05:59] I've only really been playing around with mesa in Gutsy/Hardy. [06:04] ScottK2: I am. === marcel__ is now known as marcel [06:13] tonyyarusso: I noticed the other day that kompozer is in the top 20 packages not in Debian by popcon. [06:14] I think it you modified your package for Debian, you'd have an easy time getting sponsored. [06:16] ScottK2: Yeah, the "be a good citizen and contribute back to Debian" thing has been smoldering on the to-do list for a long time. However, since Debian doesn't have as stringent of deadlines to worry about, my personal life is super busy, and I want to make sure I do my research well enough to make sure I do it "the right way", I've been putting it off so far. [06:17] ScottK2: However, last spring I did talk with asac and Kaze, and I think we were able to get most if not all non-dfsg stuff removed from it already, so that helps. [06:17] tonyyarusso: While you're here, I don't suppose you follow the gstreamer-devel ML? Slomo (I think) has just posted a tempo/bpm-finding plugin to it, a week ago or so. [06:17] tonyyarusso: Debian is getting close to their first soft freeze for the next release, so it's be really good to do it sooner rather than later. [06:18] ScottK2: Can you provide me a date offhand? [06:19] RAOF: I don't, although I may have to go check out the archives after today to look for that. Any idea what stage it was at? [06:20] tonyyarusso: Checked in to cvs & pretty much ready to roll, I think. I'll check my backlog. [06:20] RAOF: cool! [06:20] tonyyarusso: Full freeze is sched in July, but things start getting frosty in March. [06:21] ScottK2: All right - I have two days off in February, a week in March, and my hecticness-index will drop by about half in early June, so I'll see what I can do. [06:22] tonyyarusso: Yup. Checked in to gst-plugins-bad cvs, as of the 27th. As well as a commit to gstpitch, which may make gstreamer a one-stop shop for you :) [06:22] meanwhile, looking at Thunderbird, Wireshark, and Claws to see how I should do the transition for Dapper upgraders [06:22] RAOF: Wow - and with that it could actually be scripted on a command line I would think, right? [06:23] gst-launch is a fine tool, if you don't need the abilities that python-gstreamer gives you :) [06:23] tonyyarusso: The Claws one is done properly. I haven't looked at the rest. [06:23] Good night all. I'm off to bed. [06:26] ScottK, night [06:39] It seems odd to me that the transition packages have a Depends to pull in the new one, but nothing to actually get rid of the obsolete package other than a not in the description saying "this can be removed afterwards", but they all seem to do it the same way, so I guess I won't argue too much... [06:40] Policy check: Are we trying to have "Ubuntu MOTU Developers" listed as the maintainer of everything in universe? [06:48] Not everything. [06:48] Everything that has Ubuntu changes [06:48] tonyyarusso: If you have a better idea to handle transition packages, by all means let everyone know. [06:49] I think binary packages compiled from directly imported Debian packages also have "Maintainers" field changed these days? [06:50] minghua: I'm not sure of the inner workings of the different keywords (Replaces, Conflicts, etc.) - would any of them do something reasonable? If not, how come nobody's implemented a keyword for this yet? (it seems to come up a lot) [06:51] StevenK: So if it is a package that is NOT in Debian at all (yet), and thus has a 0ubuntuX version naming, would that fall into that category or not? [06:52] tonyyarusso: What function are you proposing a keyword for? "This package makes package foo obsolete, so you can remove foo after you install this one"? [06:52] tonyyarusso: Not important and frequent enough to worth a keyword, IMHO. [06:52] minghua: yeah, such that it would automatically remove foo after a successful installation of the replacement. [06:53] minghua: fair enough - I don't really know how often it is; just seemed like someone might have tried it for elegance. [06:53] The "automatically installed" feature already implemented should solve part of this problem anyway. [06:55] Doh. I'm going to have to submit one of the most trivial bug reports known to mankind. I just noticed a typo in a Tracker applet notice. === Allan_ is now known as Hit3k [06:55] "Conflicts: foo" means "This package will not install if foo is installed" [06:55] "Replaces: foo" means "foo will be automatically uninstalled prior to installing this" [06:56] LucidFox: That's not true? Replaces: means "dpkg will not complain when I overwrite files owned by that package"? [06:56] Replaces sounds close, but I'd think it would want to be a "wait and make sure this one installs okay first, then uninstall it" kind of thing. [06:56] RAOF, tonyyarusso> Makes sense. [06:57] LucidFox: Not true for Conflicts as well. [06:57] So replaces means "Ignore errors about existing files owned by foo, and uninstall foo after this package is installed"? [06:58] Yes to the first, no to the second. Both packages will be installed, but the files in both packages will now be owned by the most-recently-installed package. [06:58] You can have versioned Replaces, which makes moving files between packages possible. [06:59] RAOF> Ah. [07:00] but if both conflicts and replaces are present, the old package _will_ be uninstalled, right? [07:00] Yes. [07:07] If two packages provide the same file (no matter the version) in the same namespace, then they either need to conflict or use update-alternatives. [07:08] Or "Replaces" [07:08] ScottK2: ^ [07:09] ScottK2: btw, where are you getting the data for this "top 20" thing? I'm not sure where to look. [07:10] Are Qt4 packages under GPLv3+ allowed? [07:10] (I know that Qt3 is) [07:10] Good morning [07:11] Hello, warp10 [07:11] ScottK2: And update-alternatives doesn't fix the namespace issue on its own. Both packages need to provide a differently named file and update-alternatives provides the mechanism for one of them to obtain the "conflicting" name. [07:11] heya LucidFox! [07:12] ScottK2: Maybe you're thinking of dpkg-divert? [07:12] Oh yeah, that was the other thing I needed to learn. How to do changes as a debdiff instead of the whole thing, or however that works. [07:12] hello all. i'm trying to get my program into ubuntu (multiverse perhaps?) but i'm not exactly sure on the procedure .. i've followed the instructions and even tried to upload it to revu(i don't think it worked). now i'm not sure what i'm supposed to do next. can anyone steer me in the right direction? [07:13] mikemorrison> Did you join the Ubuntu contributors team? [07:14] mikemorrison> If you did, ask a REVU admin to sync the keyring - after that, you will be able to upload to REVU [07:16] soren: Yes. That's true. [07:16] tonyyarusso: There was some wnpp discussion on (I think) debian-devel ML where it came up recently. [07:16] Hmm, I know normally debian/changelog has something like (LP: #180382) after each thing, but I have a bug that was marked as "Fix Released" by a previous version, but this version addresses a concern brought up later in a comment on the old bug. Should I still reference the bug in the changelog? [07:17] ScottK2: presumably there's a fair bit lurking in packaging documentation as well? [07:17] doh [07:17] nvm me, I can't keep my different questions straight. ty. [07:17] soren: I was thinking of alternatives as a way to work around the namespace collision is a softer way than conflicts. [07:17] ScottK2: Indeed. [07:18] is/in [07:18] tonyyarusso: If you aren't fixing the bug that was filed, then I wouldn't mention the bug in the changelog. [07:18] LucidFox: yes, i joined in december. i was able to upload to revu, but the package never showed up. [07:19] * ScottK2 really going to bed now. [07:19] mikemorrison> Did you upload the changes file? [07:20] And was it a source package that you were trying to upload? [07:21] yeah it was a changes files, but it was binary only deb. [07:21] the diff file says "+ - zoom in/out support (xine-lib)." what is the package for the xine-lib? [07:22] mikemorrison: It needs to be a _source.changes. [07:24] well, i haven't released the source code for my program. so how do i get a binary only package uploaded? or is that not possible? i thought that is what multiverse was for... [07:25] As a rule it's for source packages that have limitations on distribution or modification that preclude Universe. [07:26] Additionally, I doubt many MOTUs are going to be interested in expending effort on getting binary only packages into the archive. [07:26] So even if it's legal, it's not easy. [07:28] * ScottK2 really really going to bed. Good night again. [07:28] ScottK2: thanks for the info.. gnight [07:32] mikemorrison> Why don't you release the source? [07:34] among other reasons, i haven't decided on a license yet, and the code currently isn't really in a state that i wish to make available. [07:35] * tonyyarusso never likes that reason [07:36] Isn't that exactly why it would help to make it available? [07:36] Also, why would it be good enough to be in the Ubuntu archives if the code isn't good enough to release? [07:38] haha.. i certainly don't mean the code is bad or anything.. i just mean i don't have comments and the coding style isn't necessarily consistent throughout [07:38] Yeah, RAOF's seems to be the most important question to me. [07:39] * Fujitsu doesn't think we really want to distribute closed, never before heard of software to our poor users. [07:39] good morning [07:40] Hey dholbach. [07:40] heya dholbach [07:40] hey Fujitsu [07:40] heya warp10 [07:40] how's it going? [07:40] Good morning. [07:41] heya cyberix [07:41] Not bad, dholbach. Yourself? [07:41] I'm looking after first advocate for my package malbolge. I've fixed all broblems that have been brought up. http://revu.tauware.de/details.py?package=malbolge [07:41] very good :) [07:42] Fujitsu: haha.. yeah i see your point. i've released my program for the maemo platform(nokia n800/n810) and after going through that procedure i just thought it would be neat to have in ubuntu as well. [07:46] mikemorrison: You are right. Multiverse is for binary only packages. [07:46] Not just for binary-only packages. [07:46] Well [07:46] cyberix: Not entirely. Mplayer is (or was) in multiverse. [07:47] I would even bet on that multiverse contains more source-available packages than binary-only one. [07:47] No, but "binary only packages" should go into Multiverse. [07:47] who puts packages in multiverse? MOTU? [07:48] Well, they shouldn't really go into multiverse, but that's the best place they can go within Ubuntu. [07:48] Aloha: Yes, MOTU are responsible for both universe and multiverse. [07:48] minghua, thnx [07:48] mikemorrison: The problem is that you need two MOTUs to advocate your package and MOTUs are not really willing to work on such packages as they do not appreciate them. [07:49] cyberix, i don't know that you can speak for everyone on that [07:49] mikemorrison: So you need to have powerfull friends as MOTUs or get some powerfull friends from among MOTUs. [07:49] mikemorrison> Don't be ashamed of the code [07:50] mikemorrison: On the other hand it will be a lot easier to add those comments to the source, or to just post the source with lacking comments. [07:50] You won't believe how many free software has _really_ bad code [07:50] s/many/much [07:50] superm1: I'm talking about my own experience about trying to get a binary package into Ubuntu. [07:50] and yet its developers don't hesitate to open it - even if they can't prettify it, others will [07:50] cyberix, i believe it really depends on the type of binary package [07:51] take for example alsa-firmware [07:51] that will be multiverse destined [07:51] and we were able to push it in and out of revu within today [07:51] Yes, if it seems important you may earn diplomacy points. [07:51] I suppose this is not the case. [07:52] on the other hand packaging say a windows executable that is wrapped around a wine launcher, that's less likely to gain acceptance after the previous fiasco [07:52] On the other hands I did manage to get two advocates for a packaged windows binary, while my current public domain, unix software doesn't seem to get any advocay. [07:52] ah that was you :) [07:53] Well, it's hard to appreciate binary-only packages, as there needs to be other incentives. But a blanket statement of "MOTUs are not really willing to work on such packages as they do not appreciate them" is too much IMO. [07:53] mikemorrison> As for the license, we can help you choose one, depending on what you want others to be able to do with your code [07:53] * Fujitsu wasn't amused with pq. [07:53] it's not really that important what license you choose, as long as it's free - as the copyright holder, you can always relicense it [07:53] or double-license [07:56] GPLv3 would be the most restrictive? [07:56] There was a thread on debian-devel about the highest popcon rank packages that are not in the archive, which is an interesting read. It would be nice if we can view binary-only packages for Ubuntu in a similar way. [07:57] minghua: Someone would have to go through and work out which multiverse packages are binary-only... [07:57] cyberix: I'd suggest you read the license or talk with someone who understands them before choosing one, instead of asking such general questions. [07:58] Fujitsu: Yeah. What I really meant, though, it that we should have some policy of "no binary-only packages unless there is evidence of a significant user base". [07:59] WOW, we've had some busy reviewers [07:59] The official multiverse policy is anything that's distributable, I believe. [07:59] dholbach, you missed a fun revu day :) [07:59] * dholbach adds all the NEW packages to http://wiki.ubuntu.com/MOTU/ReportingPage [08:00]