[01:07] Hi, may I ask an upload question? [01:09] ok, I'll ask anyway. I uploaded a couple of packages a few weeks ago, I have tried to upload new versions but they never appear, any hints? [01:10] upload where? [01:10] to http://revu.ubuntuwire.com/uploads.py [01:11] nevermind, as if my magic they appeared just now, *slighly sheepishly I'll leave*..... [01:12] :) [01:20] Could someone review http://revu.ubuntuwire.com/details.py?package=easystroke ? Thank you. === zookoafk is now known as zooko === nhandler_ is now known as nhandler [04:19] hello everybody [05:08] Hi gnomefreak [05:09] hi emma [05:45] good morning [05:46] Howdy-ho [05:46] morning [05:46] good morning! [05:46] dholbach: did you saw jono's mail? [05:47] nxvl: yes [05:47] :D [05:47] I'll get to it later on [05:47] (lots and lots and lots and lots of stuff to do) [05:47] take your time [05:47] * dholbach hugs nxvl [05:47] :-) [05:47] * nxvl HUGS dholbach back [05:48] oh great a glorious master of the universe... where does one suggest a patch for libgtk2.0-cil? [05:49] DBO: In a bug against the gtk-sharp2 package. [05:49] DBO: https://wiki.ubuntu.com/SponsorshipProcess [05:50] thank you =) [05:51] its a one line patch to fix a memory leak that was already committed into GTK-sharp trunk... do i need to go through that whole process dholbach? [05:53] DBO: The bug filing is not optional [05:53] DBO: Well, someone has to commit the fix and upload it. If you want to do most of the work, it makes it easier for others. If you don't have time, someone else may read the bug. [05:53] DBO: But you could just dump the patch on the bug if you want. [05:54] Well, I suppose the bug filing _is_ optional, really. I've got a stake in the outcome and might eventually find time to hunt this down without a bug. [05:55] its just in the Gtk.Metadata file... [05:56] RAOF, that change [05:56] http://anonsvn.mono-project.com/viewcvs/trunk/gtk-sharp/gtk/Gtk.metadata?rev=109594&view=auto [05:57] here is the diff [05:57] http://anonsvn.mono-project.com/viewcvs/trunk/gtk-sharp/gtk/Gtk.metadata?rev=109594&r1=107494&r2=109594 [05:57] DBO: Put that on a LP bug please. You can assign it to me if you want. [05:58] can do boss [05:58] whats your LP name? [05:58] raof [05:58] Nice and simple. [05:59] * RAOF is fond of this nick. He hasn't come across a nick collision yet. [06:00] okay [06:00] done [06:01] DBO: What's the bug number? [06:01] https://bugs.launchpad.net/ubuntu/+source/gtk-sharp2/+bug/254855 [06:02] basically Gtk# leaks every pixbuf you load from your icon theme. It just so happens you wont notice this unless you do this an aweful lot. GNOME Do does this, and thus can leak an aweful lot of memory [06:24] hey guys, will updating via disk destroy my linux? [06:25] I'm on fiesty fawn [06:26] Gustov: Depends on how you upgrade. You may want to ask for advice on the upgrade path in #ubuntu [06:30] I was hoping usb [06:30] the prob. is I can't get internet [06:31] Gustov: One can upgrade with no internet access. On the other hand, you may need support to do so, which is why I suggest #ubuntu: our support channel. [06:32] okay, thanks [06:48] time to sleep now [06:48] read you later! [06:48] does anyone have experience with KHotKeys breaking in 4.1? [07:40] Can someone please give back libjboss-cache1-java? [07:41] slytherin: On i386? [07:41] slytherin: given-back [07:41] persia: yes [07:44] * TheMuso likes being able to retry builds rather than having to ask an admin to do it. [07:45] TheMuso: Well, we still have an ask-an-admin model, but there are now >100 admins, rather than just 4 :) [07:45] persia: True. [07:45] * persia waits for wider sync privileges [07:45] Is that coming? [07:46] I hope so. [07:46] supposedly. [07:46] Currently, I can fake it fairly well, so it looks like I did a sync, but many people make mistakes doing that. A LP UI would be an improvement. [07:46] * persia had to sync a few packages manually in hardy, as the automated tool couldn't [07:47] I seem to recall the LP people bemoaning the fact that a bunch of archive tasks are achieved by running scripts on the datacentre. [07:47] yeah, they are. [07:48] RAOF: RIght. It's a matter of getting the tools from somewhat kludgy scripts into Soyuz, and then exposing a UI. [07:51] saivann_: feel free to upload both gnucash 2.2.6 and libaqbanking 3.5 to gnucash PPA, both hardy and intrepid [07:51] details in my email [07:53] persia: and them reliably working, yes. [07:53] persia: there's not really a lot of demand for it, though [07:53] Hobbsee: How is the demand measured? I could be demanding. [07:54] https://blueprints.edge.launchpad.net/soyuz/2.1 shows the next features for soyuz [07:54] persia: I have been sent another list of soyuz specs where we are asked to prioritize [07:54] persia: very similar to the specs for malone, but way shorter [07:55] siretart: I'm happy to share feedback if you like. [07:55] siretart: I doubt it, most of them are Implemented [07:55] Anyway, https://blueprints.edge.launchpad.net/soyuz/+spec/sync-workflows is on the 2.1 list, and the one I was talking about just now. [07:55] persia: did you already respond to my call for help in prioritizing the specs? [07:56] siretart: Not formally: I'm not in either of the groups you asked for feedback. Do you want commentary and prioritisation for the entire list? [07:56] persia: oh yes, you work for canonical now. but there aren't a lot of archive admins, or canonical people pushing them. [07:56] persia: I see you did already comment on 2 specs, but a general prioritisation would be exactly what the launchpad crew has asked us to do [07:57] Hobbsee: That canonical is one of my clients doesn't necessarily mean I have any more or less influence than I have anyway. [07:57] persia: oh, you got hired by canonical? [07:57] persia: OTOH, MOTU pushes many bugs that they want fixed, so it probably gets lost in the noise. [07:58] siretart: The easiest thing would be to say "Yes", although it's more complicated than that. [07:58] persia: well, then I will say an easy 'congrats'! :-) [07:58] persia: may I ask what you are going to work on? [08:00] persia: Cool! Congrats. [08:00] siretart: Yes, but I can't answer. Mobile stuff is part of it. [08:00] Anyway, back to the point. [08:00] ah, that's enough for me :-) [08:00] siretart: So, should everyone provide feedback and prioritisation to the list of specs? [08:01] persia: I asked every member of the release and SRU team for that, yes [08:01] siretart: Right. I'm not on those teams, and you've just asked me, which is why I'm confused :) [08:03] I have opinions, but don't want to add noise to your workflow. [08:03] oh right, you're motu-council. Does motu-council work a lot with bugs? [08:03] persia: no, the feedback is quite low, I'm happy with any response [08:03] Not in their role as MOTU Council. Mind you, each of the members does. [08:04] siretart: I'll dig up the email again and number them 1 through 15 then. If you're looking for more feedback, I'd also encourage you to add to the thread that you'd like more feedback from other interested MOTU. [08:05] Personally, I think Hobbsee and wgrant are fairly active in LP-watching, and likely have opinions, although I think neither is currently a member of either of the targeted groups. There are likely also other interested people. [08:05] persia: the thing is that I'm going to leave on VAC for 2 weeks starting on tomorrow. I need to make an interim report and hand the task over to sistpoty, I think (he doesn't know about that yet, though ;) [08:05] Well, he does now :) [08:05] * StevenK was just about to say that [08:05] i'm still thinking on what stuff i'd like to prioritise. [08:05] i'll have to respond to it tomorrow [08:05] he's not around, I need to call him on the phone this afternoon [08:05] siretart: I'll get it to soonish then. [08:06] persia: Hobbsee: thanks! [08:06] s/it to/to it/ [08:06] siretart: poke me if i haven't done it in 24h ? [08:07] Hobbsee: You may not have 24h :-) [08:07] i don't expect to need it. i'm just not about to do it at uni [08:07] good morning! [08:09] Hobbsee: ok [08:09] heck, i can't even sign into LP here. === _neversfelde is now known as neversfelde [09:16] I have a question about the process of getting a package into intrepid: Should I, in addition to posting the package on REVU, also file a launchpad bug report (or maybe have someone file it for me)? [09:20] morning everyone [09:31] so should I file a bug report or not? [09:31] TomJaeger: from what I've read on ML, yes you should [09:32] and assign it to the person or team in charge of that package [09:32] okay, thanks. [09:38] warp10: u around? [09:41] TomJaeger: You'll want to assign yourself if you are packaging it for REVU. [09:41] stefanlsd: here! [09:41] BUGabundo_work: Generally, you shouldn't assign anyone else a bug unless you know for certain they want it assigned to them. [09:42] okay, I'll assign it to myself [09:43] warp10: aah cool. i just wanted to ask about the watch file i did for mp3wrap and the submission to debian. you posted that - 'Just noticed you didn't add the tag to autoclose the bug in debian/changelog.' Just wanna understand how i should of done it so i can make sure i do it properly next time... [09:45] stefanlsd: It's easy: in debian/changelog if you add something like (LP: #XXXXXX), where XXXXXX is the bug number, the bug is autoclosed when the package is uploaded into archives [09:47] warp10: oh ok. didnt realise that. So i should of put the bug itself in the changelog with the LP: # i was closing by the submission. makes sense. thanks. [09:48] stefanlsd: exactely. You can put the tag wherever you want. Usually it is at the end of the line explaining the change you made that fixes that bug, and you can even add more than one, in case the changelog closes several bugs. [09:57] done ( https://bugs.launchpad.net/ubuntu/+bug/254893 ) [09:57] Launchpad bug 254893 in ubuntu "[needs-packaging] easystroke 0.2.1" [Undecided,New] [10:01] who would like to make dholbach a very happy man? http://revu.ubuntuwire.com/details.py?package=python-wadllib http://revu.ubuntuwire.com/details.py?package=python-launchpadlib [10:03] james_w: Perhaps not using "edge" in the homepage? Anyway, my python packaging isn't good enough for a proper review. [10:04] persia: ah, thanks [10:05] Also seems a bit odd to demand debhelper 7, and use a debhelper 5 style rules file. [10:07] dh $@ ftw :) === ApOgEE- is now known as ap0 [10:07] Well, unless one wants to support backports, in which case debian/compat of 7 is a bit agressive. === ap0 is now known as ap0g33 [10:07] Right. [10:08] What, you mean we support releases older than Intrepid? :) [10:08] Given the specific libraries, and my personal opinions as to the reasons for the packaging, supporting backporting seems a reasonable goal. [10:08] Yes, certainly. [10:09] * wgrant expects it will need to be SRUed heavily. [10:09] wgrant: SRUed? Why? [10:09] I'd think SRUing ports of all the rdepends would be a bit of a stretch from the no-new-features-in-SRU guidelines. [10:11] persia: Better than breaking every time LP feels like it needs to change something. [10:11] wgrant: I guess. Are we certain that this isn't going to change as often? [10:12] james_w: You appear to have set Vcs-Bzr to a branch only you will have commit access to. This seems anti-social :) [10:12] persia: It is labeled beta. [10:12] s/seems/is/ [10:12] RAOF: it's bzr, you can have commit access to your own branch :-) [10:12] wgrant: Depends on the definition of "beta" then. [10:12] james_w: Yes, but packaging can't be coordinated safely with the variance. [10:12] james_w: Given you've listed me as a maintainer, I'd hope to have write access to the cannonical trunk :) [10:13] persia: It has 'beta' in the REST URLs it uses, IIRC. [10:13] RAOF: if I do that then I don't get commit access [10:13] persia: I'm not sure I understand [10:13] james_w: Well, you could put it somewhere to which both of you have access. [10:14] james_w: OK. I branch your packaging branch. I change it. I upload. RAOF wants to make changes. From where does he pull? [10:14] Or put it somewhere where the people with upload rights have access and can merge from unprivileged branches, which makes a whole lot more sense. [10:14] Does each person changing need to mangle the Vcs-* headers? [10:14] I'm not sure that's a problem, though. MOTU will be maintaining it, motu should definitely have commit access, and I don't think !motu should have commit access. [10:14] RAOF: Right. [10:15] Well, I can see the case for allowing certain !motu commit access to certain packages, but generally that makes sense. [10:15] Right. Until we have a debian-maintainer style permission system, I think keeping commit rights equivalent to upload rights is not unreasonable. [10:15] persia: Why shouldn't package branches have the same permissions as the package itself? [10:16] RAOF: We do. [10:16] RAOF: It is only used for one package, AFAIK. [10:16] Oh, wow? Which one? [10:16] wgrant: Well, it's not always done that way in Debian. I suppose part of that might be differences in workflow between SVN and BZR. [10:16] dkms [10:16] And why aren't we using this more? [10:16] RAOF: Soyuz only got it recently. [10:16] RAOF: Because it requires TB approval for each case, and manual adjustment by LP admins. [10:16] RAOF: And I don't think its use has been authorised by the RB. [10:17] *TB [10:17] Once the UI gets cleaner, we ought be using it more. [10:17] And there's no UI for it, right. [10:17] Ah. So it's not finished enough to really use. Check. [10:19] Nice thing about the implementation is that it's inclusive: rather than being that some person can upload, it's that some person can *also* upload. [10:20] hello persia [10:20] how are you ? [10:20] TheMuso: are you around ? [10:20] huats: OK. It's less hot here because of the storm. [10:20] persia/wgrant: what would be the process james_w should follow ? Change Vcs-Bzr before submitting it to REVU ? At that point he still needs to commit changes... [10:20] hum... [10:20] you are lucky :) [10:20] it is way too hot in here... [10:21] Koon: There's no good model that has been established to permit accurate Vcs-* in REVU packages by non-MOTU. [10:22] I'd suggest setting Vcs-Bzr to the value it should be once the package is in the archives. The uploader should also push the corresponding bzr branch. [10:22] RAOF: But will the uploader? It may be that that doesn't happen. [10:23] Man, wouldn't NoMoreSourcePackages be useful here... [10:23] RAOF: I would suggest setting it to the developer branch, and if the uploader thinks about it, change it when he pushes the branch somewhere else [10:23] Koon: But that makes "Maintainer" inaccurate by default. [10:24] Mind you, in most cases, Vcs-* is inaccurate and potentially harmful in Ubuntu anyway, so perhaps it doesn't matter much. [10:25] nxvl: http://daniel.holba.ch/blog/?p=146 [10:25] nxvl: excellent work! :) [10:25] RAOF: NoMoreSourcePackages wouldn't necessarily solve this: while there might be a facility to preserve history (or possibly not, depending on how the uploader uploaded), james_w would still not be able to commit to the branch that contained correct information, and someone would need to manually adjust things. [10:26] persia: with RAOF suggestion it's Vcs-Bzr which is inaccurate by default :) it's kind of chicken-and-egg anyway. the only way to be accurate is to remove it (accurate by omission) [10:26] Koon: Precisely. If later the maintainer wishes to use a VCS, it can be added. [10:26] persia: but the sponsor would be using bzr, whereas that's not guaranteed now [10:27] james_w: That's not guaranteed with NoMoreSourcePackages either, or at least from the last rumours I heard. [10:27] Something about supporting the dput use case? [10:27] Doesn't that violate the basic principle of NMSP? [10:27] persia: if there are NoMoreSourcePackages then you can't dput anything [10:27] dput is going away soon for other reasons, anyway. [10:28] james_w: Ah. I heard talk about having an autocommit of changes on dput [10:28] wgrant: What reasons would those be? [10:28] persia: Well, at least for PPAs SFTP will apparently be supported. It will allow things like removing .changes replay vulnerabilities, and allowing upload-time feedback on whether an upload failed or not. [10:29] persia: yes, but that's not NMSP. NMSP is somewhere that we might go, but it's not the starting point. Initially there will be the autocommit on dput [10:29] wgrant: No reason dput can't do sftp. [10:29] persia: True. [10:29] james_w: See, if that gets enabled, disabling it becomes interesting. === _neversfelde is now known as neversfelde [10:29] persia: yep [10:29] On the other hand, if that doesn't get enabled, bootstrapping problems ensure. [10:30] s/ensure/ensue/ [10:30] As a result, I imagine dput support (possibly over sftp) would remain for a while. [10:30] Although, I suspect people are more careful with GPG keys than SSH keys, so think that's not a positive step, entirely. [10:31] The .changes replay hole needs to be fixed. [10:31] That is one of many issues. [10:32] Personally, I think the "target distribution" is the way to solve that: use e.g. "intrepid-persia" for my PPA. [10:32] That way it fails if I push it somewhere else. [10:32] Indeed, that would make sense. [10:33] And stop people from shooting themselves in the foot, too. [10:33] That also conveniently breaks pocket-copies from PPA to archive, which I suspect are inherently unsafe for other reasons. [10:33] (e.g. unexpected dependencies, etc.) [10:33] Particularly with the lack of ogre-model [10:34] Well, that, and the ability to depend on other PPAs which may or may not have wholly new packages. [10:34] (which is external to the control of the PPA concerned) [10:59] Adri2000: ping === saivann_ is now known as saivann [13:09] devfil: pong [13:10] Hello [13:10] Adri2000: I've reply at the bug for the merge of amsn, can you take a look at it? [13:10] could some review http://revu.ubuntuwire.com/details.py?package=amoebax ? Thanks [13:11] devfil: yep [13:14] devfil: I don't think amsn should depend on both tk8.5 and tk8.4 [13:14] and upstream confirmed me it should work just fine with tk8.5 [13:14] fix for kde4 thing: ok [13:15] makefile patch: if you choose to drop that ubuntu change, you should mention it in the changelog [13:16] I agree that this change isn't really useful, it just sounds more logicial to do that way. but if we want to reduce the delta with debian, let's drop it [13:18] devfil: got my comments? [13:18] Adri2000, no [13:20] Unless the change still accomplishes something useful (fixes a bug), it's better to reduce delta. If a bug exists without the change, let's keep the delta. [13:22] persia: the change is just about moving some clean commands from debian/rules to the upstream Makefile (where they really should be) [13:23] devfil: I'll put them in the bug report [13:23] Adri2000: Yeah, I don't think it's worth keeping that. The commands are still in diff.gz [13:25] Adri2000, why we should continue to make hard the next merges? the makefile problem seems to be only an esthetical choice [13:25] we should drop useless changes like this [13:26] devfil: yes, that's what I was saying, see the bug report [13:26] you should just mention that you dropped the change in the changelog [13:27] and anyway the patch is going upstream (I just told them about it) [13:34] Adri2000: done [13:41] devfil: you don't mention in the changelog the ubuntu changes you are dropping [13:41] Adri2000: is it a [13:41] "must"? [13:41] I don't know, at least I think it's better [13:42] also, how is the debian/amsn.desktop removal a useful change to keep? [13:42] Adri2000: when you use grab-merge.sh to do a merge and you have a conflict and the best solution is from debian you mention that you have choice debian solution? [13:43] devfil: I would just mention that the Ubuntu change is dropped in the changelog. [13:43] devfil: Rationale isn't needed so much [13:43] Adri2000: It isn't installed, but also messenger.xpm is useless, maybe the best solution is to report this to debian and for now to don't drop them [13:44] Afternoon all. Anyone up for a review of http://revu.ubuntuwire.com/details.py?package=goocanvasmm ? :> [13:44] devfil: I think so yes [13:45] devfil: how is bug #249534 fixed by your merge? [13:45] Launchpad bug 249534 in amsn "Using amsn 0.97 from ubuntu repository it ask me to download a TLS module, but then it doesn't work testing Intrepid 64-bit (no problem using version 0.97.1 compiled)" [Undecided,New] https://launchpad.net/bugs/249534 [13:45] Adri2000: the new version fixes the problem [13:46] it is a problem of the new windows servers [13:46] no [13:46] the bug is about a tls module [13:46] not about not being able to connect [13:47] the not being able to connect is bug #243722 [13:47] Launchpad bug 243722 in amsn "Amsn 0.97 doesn't work testing intrepid 64-bit. There is no way to connect to it. But server works correctly using pidgin and others.." [Undecided,Confirmed] https://launchpad.net/bugs/243722 [13:47] which is indeed fixed in amsn >= 0.97.1 [13:48] Adri2000: the tls problem is fixed in the new version, I'm sure about this, but if you don't I can ask the user to try the new version and then to mark the bug as fixed [13:49] devfil: can you reproduce the tls bug with the current 0.97 package? [13:49] Adri2000: let me try [13:53] Adri2000: not needed to test, it is already tested in the 0ubuntu6 package (thanks to DktrKranz) [13:53] s/tested/fixed/ === fta_ is now known as fta [13:54] hi folks [13:55] Hi sistpoty|work [13:55] hi geser [13:56] devfil: if you're sure that upload fixes this bug, then close it manually explaining why it is fixed, but do not close it in your unrelated merge [13:56] hi sistpoty|work :) [13:56] hi Adri2000 [13:57] Adri2000: done [13:58] devfil: also I'd suggest adding a new line in the changelog saying the new upstream release fixes the connection bug (LP: #243722), because with the current "merge .. (LP: #...)" it seems to me these are all merge bugs [13:59] Adri2000: next time, can you please explain me all the changes before? so I don't need to do a lot of debdiff, thanks [14:01] devfil: wait until I tell you it's ok to upload your debdiff, but I think it's good to do such live reviews :) [14:02] Adri2000: done, there are other changes that [14:02] I should do? [14:02] Heya gang [14:02] devfil: have you listed the dropped ubuntu changes? [14:02] bddebian: heya bddebian ! [14:02] bddebian: Hey. NBS needs *you* :) [14:02] Adri2000: yes [14:03] devfil: cool, let me do a final check and I think we are done [14:03] hi bddebian [14:05] Heya Adri2000, persia, sistpoty|work [14:05] persia: NBS? [14:06] bddebian: http://people.ubuntu.com/~ubuntu-archive/NBS/ : I'm just remembering some of your package upload marathons, and thought I could tempt you: if you've forgotten, no worries. [14:08] dholbach: \o/ [14:08] dholbach: awesome [14:08] :-) [14:10] devfil: please upload, that should ok [14:10] Adri2000: ehm... what? [14:11] s/upload/attach your debdiff to the bug/ [14:11] Adri2000: done [14:12] I've already uploaded it [14:12] thanks [14:12] Ah NBS as in Not Build from Source? [14:13] built even [14:13] bddebian: Yep. [14:13] * persia hunts the wiki [14:15] https://wiki.ubuntu.com/UbuntuDevelopment/NBS seems to be a reasonable summary. [14:15] devfil: FYI I'm updating the package to 0.97.2, so there will be your merge and the new upstream release in the same upload [14:15] How can I remove a folder in debian/myapp when using cdbs [so that it's not in the binary package]? [14:16] Adri2000: so why you don't have done the merge? [14:17] Kopfgeldjaeger, I believe you can use the install/package:: rule [14:17] ok, thank you [14:18] I am not just sure wether it's called before or after the CDBS dh_install, but I believe it's before [14:18] persia: I'll see what I can do [14:18] Kopfgeldjaeger: do not include it in debian/myapp.install file. [14:18] bddebian: It's up to you: if you're busy with other stuff, that's well understandable. [14:19] slytherin: i don't do that anyway [14:19] devfil: I could. but you had already put a debdiff in LP, and we try to not duplicate efforts. so I review what you've done and use it. [14:19] Kopfgeldjaeger: then I think the folder won't end up ni .deb [14:19] Kopfgeldjaeger: https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml#id2480675 is likely what you seek. [14:20] it works, thank you [14:20] persia: You know me, I don't do anything :) [14:21] bddebian: Which is precisely why I thought you'd like NBS: it's uploading things without actually changing them: the very definition of not doing anything :) [14:25] heh [14:31] devfil: there is a duplicated patch [14:32] Adri2000: ? [14:32] debian/patches/04_settingoff_autoupdate.dpatch [14:32] debian/patches/05-disable_newVersionCheck.dpatch [14:32] the first one was added by the debian maintainer [14:33] it seems he sometimes forgets to add things to the changelog [14:33] so I agree it's not easy for us... [14:33] Adri2000: are you sure that they are the same? [14:33] err no you're right [14:34] ok, forget what I said :) [14:34] Adri2000: I'm not a stupid, maybe I can be wrong but I usually do a testbuild for each debdiff ;) [14:36] devfil: Mistakes are not about intelligence: they are just a result of being human :) In this case, it's not yours, but next time it might be... [14:36] geser: you're uploading crack :P [14:49] geser: FYI ... I am already working on libjboss-cache1-java FTBFS. So don't put your time on fixing it. [14:52] slytherin: it still FTBFS? I didn't have time to look at it [14:54] geser: yes, due to aop classes. We need to bypass then. But there is another problem. The jar file in resultant .deb has no class files. [14:55] geser: forget the second part. It was my mistake. [15:01] slytherin: It failed again after the rebuild? [15:08] persia: yes [15:08] :( [15:31] I uploaded a package (musica) to REVU, but I don't see it on http://revu.ubuntuwire.com/index.py [15:31] the upload looks to have succeeded [15:32] and trying to upload again yields "already uploaded" [15:33] kirkland: the "already uploaded" is a dput safety mechanism, you can override it if you need to [15:33] kirkland: did you log in to REVU first? [15:33] james_w: i have not.... logging in now.... [15:34] that will import your GPG key from launchpad, which should mean that your upload will be recognised next time [15:34] kirkland: Remember to delete your .upload file locally. [15:34] if you already had an account then I believe you can merge them [15:35] james_w: i have uploaded to revu before [15:35] james_w: this one seems to be misbehaving [15:36] If the upstream software is GPL, can the packaging be BSD? [15:36] kirkland: There was recently a change in keyring management that reset the keyring. [15:36] LucidFox: Yes, but that's a bit odd. The resulting package is GPL. Be cautious of the advertising clause. [15:37] okay, i deleted my upload file, and dput to revu again [15:38] and I logged in [15:38] And now wait 5 minutes :) [15:38] the packager specifically said revised, so no advertising clause [15:40] dholbach: pm? [15:41] tuxmaniac: sure [15:52] kirkland: Your package is there? [15:52] persia: yep, just showed up ;-) [15:52] Excellent :) [15:52] persia: see musica [15:52] http://revu.ubuntuwire.com/revu1-incoming/musica-0808051650/lintian [15:53] the last one is probably a mistake? [15:53] it would be great to fix the second. [15:53] james_w: i can fix the first 2 [15:54] rockin' [15:54] kirkland: Not the third? [15:55] persia: i'm not sure I understand the 3rd warning [15:55] kirkland: if this isn't meant to be a native package then you didn't have a correctly named .orig.tar.gz in the parent directory while building the source package [15:55] kirkland: Essentially, it couldn't find the orig.tar.gz when you built the source pacakge. [15:55] if it is meant to be native there should be no "-" in the version number [15:56] the .tar.gz has to be precisely named: musica_0.1.orig.tar.gz === lmr_ is now known as lmr[lunch] [16:39] If I don't want a (AUTHORS)-file to be included in my binary package [I do not include it anywhere myself, but cdbs does], should I just remove it in install/myapp:: ? [16:42] geser: persia: The build failure for libjboss-cache1-java is a mess. I feel like chasing a car at 100mph on a bicycle. :-( [16:45] slytherin: how got the DD then got it build? [16:45] geser: That is a question I keep asking to myself again and again. :-) [16:46] geser: probably they didn't and they will realize the mess once there is a rebuild for those packages [16:48] geser: I will try updating that package to latest upstream version sometime this weekend. Let's what happens. [16:50] lol :) [16:50] avidemux (1:2.4.3-0.0) unstable; urgency=low [16:50] * New upstream release. [16:50] * Move to cmake (I still hate cmake). === Marce_ is now known as Marce === philwyett_ is now known as philwyett === nixternal_ is now known as nixternal [17:18] How many characters per line are 'allowed' in a man page? [17:20] Kopfgeldjaeger: as usual 80 I suppose [17:20] OK. Thanks. [17:21] Kopfgeldjaeger: man pages wrap automatically, so there isn't really a strong limit to 80 chars [17:21] huhu sistpoty|work btw ^^ [17:21]