[00:11] StevenK: will you be handling on the libsdl1.2 merge? (I'm looking at bug 180221 ATM) [00:11] Launchpad bug 180221 in libsdl1.2 "sound doesn't work using libsdl1.2debian-pulseaudio binary package" [Medium,Fix committed] https://launchpad.net/bugs/180221 [00:12] handling the* [00:13] It needs to be merged again? [00:13] yep, new upstream version [00:14] Grumble. asc doesn't differ with Debian [00:15] crimsun: Yeah, I'll look at merging it. I'll bleat if I have any issues [00:15] StevenK: ok, thanks. === tritium_ is now known as tritium [01:10] imbrandon, ping. [01:10] imbrandon, Where can I find the script to sync accounts with launchpad groups on a machine? [01:16] somerville32, it's part of the revu code [01:16] Would adding myself as a MOTU candidate to the MOTU meeting agenda be appropriate? [01:17] DarkMageZ, have you contacted debian-legal yet ? [01:17] DarkMageZ, or did you chicken out? === wolfger_ is now known as wolfger [01:19] nenolod, i'm polishing the email. i'll send you my draft soon [01:19] groovy === Gunirus_ is now known as Gunirus [01:21] nenolod, I see the code to grab the gpg keys but are you sure the code for getting the ssh keys are in the revu trunk? [01:21] YokoZar: normally you'd send an e-mail to motu-council@u.c detailing your application. It's standard practice to CC people who can vouch for you. [01:21] crimsun: I've already done that [01:22] YokoZar: if you feel you need to say something in the meeting, then sure, please do add yourself. [01:23] crimsun: Ahh, but otherwise it's just handled by email fine? [01:26] yes [01:26] (I just re-read the e-mail from Sat.) [01:27] nenolod: no it isnt part of revu, somerville32 one moment [01:27] i'll find the bzr branch === Elly is now known as Elly-latitude [01:28] Fujitsu: do we have that on LP under the ubuntuwire project yet ? [01:29] imbrandon: It's in a bzr branch under my ~, I think. [01:29] * Fujitsu looks. === Elly-latitude is now known as Elly [01:29] orko:~fujitsu/lpusers is the bzr branch. I'll symlink it under my public_html. [01:29] kk, cool [01:30] somerville32: ^^ [01:30] somerville32: http://people.ubuntuwire.com/~fujitsu/bzr/lpusers [01:30] Erm, permissions issue, I think. [01:31] 403 :] [01:32] somerville32: note when looking at it, its talored for our use , so i would audit it before using it [01:32] somerville32: bzr branch it. [01:32] Fujitsu has done a great job at abstracting most of it though, so should be fairly simpe to cusomize [01:33] simple* [01:33] That was quick [01:33] It branched just like that *snap* [01:33] It's only one file, so... [01:33] i'd imagine there are only a few revisions, we dident have it in bzr for a long time [01:33] and its only one file [01:33] imbrandon, sorry. my mistake. i thought he was looking for GPG. :) [01:34] I just associated bazaar with natural slowness no matter what :P [01:34] somerville32: It's only slow when branching enormous trees from LP, really. [01:34] or pushing them [01:34] hehe [01:35] That too. [01:35] Though bzr+ssh works. [01:35] would be cool if bzr kept stats on how many times a branch was "branched" [01:36] to be fair, bzr 1.0 is scads faster than what was in feisty. [01:36] The HTTP server would have to do that. [01:36] Fujitsu: right but that wouldent work for bzr+ssh etc [01:36] crimsun: It's quite good, except for huge trees over HTTP(S). [01:36] Fujitsu, Does this script crawl sub-teams? [01:37] somerville32: +rdf does that automatically. [01:40] somerville32: as i said its talord for our use ( like where the sshd looks for key files and such, you'll likely want to change some bits ) [01:40] just fyi [01:40] Such as looking to ensure you're there? lol [01:41] That bit's probably not so necessary now that we're not screenscraping. [01:41] such as /home//.ssh/authorized_keys on a "default" system instead of /srv/ssh-keys/.key [01:42] and it assumes there is already a ubuntu-dev system group [01:42] and a few other misnomers [01:42] yea the sanity check for me probably isnt needed anymore now that +rdf works [01:43] before it was html scraping and it was needed to ensure the LP ui dident change unexpectedly on us [01:43] Is there a reason why you place the keys in /srv/ssh-keys/ instead of the user's home directory? [01:43] to make backups on the UW servers easier [01:43] we backup the critical services but not user data [01:43] It also means that we don't have to create ~user/.ssh if it doesn't exist, setting permissions. [01:44] right [01:44] Is it possible to get sshd to look in both places? [01:44] no , unfortunately [01:44] So I'll have to change the AuthorizedKeysFile option? [01:45] leaste not openssh-server with ubuntu, never looked into another sshd [01:45] somerville32: either that or the script [01:45] i would change the former though [01:45] personaly [01:46] bbiab [01:46] What is the token for the username? [01:46] %h is home directory from what I can gather [01:46] %u [01:47] somerville32: Note that the script allows users to manually add additional keys to the file, if they wish. [01:47] #AuthorizedKeysFile %h/.ssh/authorized_keys [01:47] AuthorizedKeysFile /srv/ssh-keys/%u.key [01:47] ^^ orko's sshd_config option [01:47] if thats what you mean [01:59] hmm [01:59] well, [02:00] DarkMageZ is about to send the report of our analysis of zsnes's legality to debian-legal. :) [02:03] What is the result? [02:04] Heya gang [02:04] Hi [02:05] Hi ion_ === lando__ is now known as lando [04:39] is it okay for files to retain the redhat name? [04:39] TheMuso: If your up for looking into a powerpc FTBFS, http://launchpadlibrarian.net/11144671/buildlog_ubuntu-hardy-powerpc.papaya_0.97.20031122-5.3_FAILEDTOBUILD.txt.gz is available... [04:39] pwnguin: Context please. [04:40] dpkg-query -S redhat-* [04:41] dpkg: *redhat-** not found. [04:41] hmm [04:41] does it only search installed stuff? [04:41] yep [04:42] ok, well for example [04:42] install-data: /usr/share/app-install/desktop/redhat-manage-print-jobs.desktop [04:44] the desktop file itself also has Categories=GTK;Monitor;System;X-Red-Hat-Base; [04:47] I'd say look at the licensing of the files in the package and see if Redhat claims any trademark restrictions. === tritium_ is now known as tritium [05:09] ScottK: I'll look at it when I get a chance, thanks. === Vorian_ is now known as vorian [05:21] hi. [05:22] aloha :) [05:22] does anyone know if the audacious-1.4.5 / audacious-plugins-1.4.4 task has been looked at yet? [05:22] it fixes some critical bugs [05:22] and people keep filing duplicate upgrade requests [05:26] TheMuso: Great. [05:39] bddebian: did you get anywhere with your jugglemaster segfault? [05:41] Heya bddebian. [05:43] slangasek: No :-( persia was going to check it out. [05:43] Hi ScottK [05:44] slangasek: I almost have newpki-client building with wx2.6 too. Maybe it'll segfault as well. :) [05:47] bddebian: you have a backtrace posted anywhere for the segfault? [05:47] It's less than helpful but let me check [05:50] slangasek: I have like every dbg and dbgsym package on the planet installed and I get this: http://paste.debian.net/46105 [05:51] eew it uses dpatch, maybe I don't care enough to look into it. :) [05:51] hah, it segfaults in the C++ constructors? [05:52] well, this will be fun [05:52] yeah, weird huh? [05:52] nah, "fun" [05:52] weird would be if it segfaulted in the destructors on startup [05:52] heh [05:53] persia also noticed some weirdness on amd64 with -fPIC [05:53] In fact I don't think it even built on amd64 [05:56] hmm, this is the package that was newly uploaded and depends on wxwindows 2.4, innit [05:56] yup [05:56] well, I'll see for myself soon enough what happens on amd64, since that's where I started [05:56] /usr/bin/ld: jmdlx.o: relocation R_X86_64_32 against `JMFrame::sm_eventTable' can not be used when making a shared object; recompile with -fPIC [05:57] Yep, that's it [05:57] * slangasek rolls his eyes [05:57] Dear upstream, your source code is a waste of electrons. Hugs and bunnies, Vorlon [05:57] hah [05:58] $ wx-config --ld [05:58] g++ -shared -fPIC -o [05:58] $ [05:58] yes, that's a completely wrong way to be linking an executable kthx [05:58] Yeah, I had to change that. It was doing --ldflags [05:58] I know, it is still wrong but.. [06:00] ah, right, I see that's part of the patch. Well, the original sin is still upstream's [06:00] aye [06:01] hum, this should work [06:03] ok, which of the apps did you try to run that gave you this segfault? [06:03] jmdlx [06:03] right, the only one that's wxwidgets, gotcha [06:04] no segfault on amd64 [06:04] will try i386 [06:04] what'd you change? [06:06] I got rid of the wx-config --ld bit and restored the $(CXX) invocation [06:07] f**king lameage :-( [06:11] hmm, that seems to fix the segfault on i386 for me [06:12] * bddebian is an idiot as usual [06:12] lots of Pango-WARNINGs about invalid UTF-8 strings... [06:13] related to the style [06:13] Yeah, it still needs some work with UTFication [06:14] er, all ascii is valid utf8 though [06:14] so the problem seems to be with passing something in that's not really a C string [06:15] Does it bomb or just throw warnings? [06:16] throw warnings [06:16] but there's also garbage on the window [06:17] :-( [06:23] wouldn't the easy way of this to just be to kill the jmdlx package and say "Qt and aalib are good enough"? [06:23] would work for me :-) [06:24] I mean, yeesh, all it does is render a juggling stick figure [06:24] Still have newpki-client and ctsim though. I've talked to the ctsim developer/maintainer and he isn't to keen on switching :-( [06:26] Anyway, I have to get my fat arse to bed. Thanks for looking at that! Would you mind passing along what you changed? [06:26] slangasek: I wonder if I could convince to fix bug 180274 ... [06:26] Launchpad bug 180274 in bluez-libs "Please sync bluez-libs (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/180274 [06:26] Uh oh, wife is up now [06:27] convince you, even === asac_ is now known as asac === doko_ is now known as doko [08:54] slangasek: Thanks ever so much for a sane solution for jmdx :) [08:57] persia: I'm not convinced that the saner solution wouldn't have been to punt the package... :) [08:58] slangasek: I'd agree with that, but don't really want to carry extra deviation if we can help it. With luck, Helmut will apply your patch, and wx2.4 will be that much closer to going away. [08:58] Now if only there was a similarly sane solution for gnue-* [08:59] (and, no, that's not a request. Those packages are in odd limbo, and are more likely to get tossed than fixed) [09:02] Hello, if I am packaging software, from which the source is in SVN, how should I mention that in the watch file ? [09:03] AnAnt: Can you convince upstream to make a release? [09:03] AnAnt: watch files dont support SVN [09:04] persia: they put release as jar file [09:04] would probably I nice feature to have [09:04] AnAnt: with a version number in jar name? [09:04] man-di: I disagree: snapshots are harder to maintain. [09:04] persia: in Java-Country thats unfornately a common way we need to go [09:05] man-di: Really? Upstream releases are that unreliable? Unfortunate :( [09:05] man-di: I don't remember ? but the jar has binary, the java source code is in SVN [09:05] persia: some upstreams release only binary builds [09:05] man-di: Hmm. Can they not be educated (with a stick, if necessary)? [09:06] persia: I tried with electro shocks for some...and failed [09:06] persia: normal answer: You dont need the source, use our binary build [09:07] AnAnt: There's some guidelines on using get-orig-source to pull from VCS at https://wiki.ubuntu.com/PackagingGuide/Basic#head-4bb01b3c07548aaf98e85ac7eb7983e632f8eb38, but not much a watch file can do :( [09:07] man-di: Right. Lovely. Definitely the right spirit. I suppose they'd object to maintaining a set of source tarballs for each release in a LP project? [09:07] AnAnt: if the jar has a version number in its name you can at least match the binary jar to notify you when new release was made [09:08] persia: too much work for them [09:09] persia: they press some button in their development IDE and *whoops* they have a binary jar release [09:09] man-di: Hmm. It's usually a two or three line script. Oh well. [09:09] persia: thats all they wanna do [09:09] Fujitsu: are you coming to the debian miniconf? [09:09] man-di: hmm, look, the software is josm [09:09] man-di: Have we filed bugs against eclipse and netbeans to generate source tar.gz files as part of the same click? [09:09] speaking as a Java coder: most Java coders have no clue [09:10] AnAnt: I looked at josm some time ago...and cried out loud [09:10] persia: hehe [09:10] man-di: http://josm.openstreetmap.de, and I am actually making a package for the nightly build, which they say that it is stable [09:10] persia: that would be neat [09:10] man-di: cried out loud for what ? [09:11] man-di: Even if they were distro-local patches, it would help in some cases, and pushing upstream makes everyone's life easier :) [09:11] AnAnt: because it didnt work with free runtimes [09:11] persia: most java upstreams know only windows [09:11] man-di: What do they use for IDE? [09:12] persia: most people use Eclipse, Netbeans, JBuilder, IntelliJ [09:12] * persia used TogetherJ and NetBeans back when a Windows & OS/400 Java developer [09:12] man-di: free runtimes ? [09:12] man-di: all the jar files they depend on are GPL'ed [09:12] AnAnt: GCJ and all classpath based runtimes [09:12] man-di: they only require sun java [09:12] AnAnt: thats the problem [09:12] AnAnt: Does it work with icedtea? [09:13] man-di: I think they are doing a version for that (I saw that icedtea in their SVN log) [09:13] persia: I think they are doing a version for that (I saw that icedtea in their SVN log) [09:13] AnAnt: I read all the rows :) [09:13] ok [09:13] AnAnt: thats nice but GCJ would be better [09:14] AnAnt: More generally, if you can get it to work with icedtea, we'd consider it free in Ubuntu, but having it work with gcj would be vastly superior, as it could also be free in Debian. [09:14] but, is there a problem if I made the package Depend & Build-Depend on sun java jdk ? [09:14] AnAnt: It goes in multiverse [09:14] AnAnt: it depends on non-free software then (and this software is not portable) [09:15] man-di: so in Debian too it would be i non-free, right ? [09:15] contrib [09:15] ok [09:15] does Debian consider icedtea free ? [09:15] if all code is GPL [09:15] debian has icedtea yet [09:16] has *no* icedtea yet [09:16] so to use icedtea, I should do: update-java-alternatives -s ? [09:16] man-di: oh yes, indeed, they don't [09:17] AnAnt: No, use JAVA_HOME=.....something.... [09:17] AnAnt: purge sun java, install icedtea. Better, use sbuild or pbuilder, and set your build dependencies. [09:17] AnAnt: for building I mean [09:17] yes, I use pbuilder indeed [09:18] I think i'll use sun java, it worked like that [09:18] AnAnt: That makes it multiverse, which is not preferred. Please at least give it a try. [09:19] persia: I want to put the package in Debian too [09:19] man-di: Is icedtea in plan for Debian, or is it waiting for the "official" source release? [09:21] man-di: ok, I have a question, if a package is built with icedtea jdk, would it work with sun java jre ? and vice versa ? [09:23] persia: we want to use the same source package as for Ubuntu [09:24] AnAnt: it should [09:24] kubuntu channel operator has said me here i can get help, i am not good enoght to do a debian package for my application http://ubuntuforums.org/showthread.php?t=652843 [09:24] man-di: Is the current Ubuntu source not DFSG free? Should I be reading debian-devel-java@ archives? [09:24] so if someone is interested to do it :) let me know [09:25] persia: it ist afaik [09:25] bucatoamano: We would help you package it if you had questions, but we don't take packaging requests. [09:25] ok [09:25] man-di: That's what I thought from looking. I'm not sure why it was in universe. [09:25] persia: ok, I have another question, the latest release is josm-1.5, yet I am packaging the nightly build, which according to the website is also stable (but not a release), so how should I version it ? 1.6r or what ? [09:26] icedtea is in universe ? [09:26] bucatoamano: If you'd like to make a packaging request, put a tar.gz somewhere as part of an upstream project, and file a bug against "Ubuntu" (no source package) with the "needs-packaging" tag. [09:26] persia: AFAIK (I may be wrong) its in universe because GCJ is the default runtime in Ubuntu and one Java runtime in main is enough [09:26] bucatoamano: The bug should have a short description of the package, a link to the upstream project homepage, and a small advertisement to interest one of the packagers. [09:26] man-di: I meant universe vs. multiverse :) [09:27] persia: I'm a lazy Debian-man so I dont know for real [09:27] persia: ah [09:28] persia: I think its just that we dont uploaded it yet, I needs some adjustments, Ubuntu and Debian are more different then one would expect [09:28] AnAnt: I like to grab 1.5 and apply the additional changes as patches in most cases, as this tends to cause less end-user confusion. If you want, 1.6~svnyyyymmdd is the common construction for snapshots just before release, and 1.5+svnyyyymmdd is the common construction for snapshots when there is not a near upcoming release. [09:28] ok [09:29] man-di: Depends on expectations :) I think of them as fairly different, despite sharing >95% of source. [09:30] persia: the lest 5% is that what makes it complicated anf big packages like icedtea hit that problems easily [09:30] man-di: Yep. It doesn't help that that 5% tends to be things like the kernel, libc, etc. :) [09:30] persia: e.g. there is libgif-dev vs. libungif-dev [09:31] ok I think there is a problem in ubuntu's java virtual packages [09:31] man-di: I thought that transition was happening for both. [09:31] ok I think there is a problem in ubuntu's java virtual packages , java-compiler, java-virtual-machine, java-runtime,... [09:31] persia: last I looked at it we needed one for Ubuntu and the other for Debian [09:31] none of them depend on icedtea [09:31] AnAnt: they are virtual pacakges [09:32] oops sorry [09:32] AnAnt: and provided by some packages [09:32] Official word is from comparing bug #174252 with Debian bug #410287. [09:32] Launchpad bug 174252 in libungif4 "transition to libgif" [Undecided,In progress] https://launchpad.net/bugs/174252 [09:32] Debian bug 410287 in mirrors "mirror submission for debian.mirror.web4u.cz" [Wishlist,Open] http://bugs.debian.org/410287 [09:32] AnAnt: for Build-Depends use real package names, not virtual packages, please [09:32] java2-runtime depends on icedtea, bad me ! [09:32] Errr. Debian bug #401287 [09:32] Debian bug 401287 in libgif4 "libungif to libgif transition" [Wishlist,Open] http://bugs.debian.org/401287 [09:33] man-di: 1. why ? 2. how about in Depends ? [09:33] AnAnt: to get reproducible builds, for Depends use "real package | virtual package" [09:33] man-di: Looks like any variance there is just a matter of transition schedules. libgif is the future. [09:35] persia: firefox-dev was another issue, sure, all are transitions in action but the problem is that big packages that you wanna keep in sync on both distros always hit some transition-in-the-works [09:35] man-di: Well, yes. Dktrkranz is working on a tool that parses rene output and generates a nice transition tracker web page. Should help everyone. [09:36] StevenK: 180274> on Monday when I'm on archive duty, or at very least, tomorrow when I can pretend to be awake and don't have to fight off typos like "tomowwor" [09:36] hmm, I think java-* virtual packages should depend on java[12]-* virtual packages [09:49] white: Regrettably not. The family has decided that we must go on holiday - I can't attend LCA at all. [09:49] bah [09:50] man-di: they support IcedTea since October [09:50] white: I concur. [10:04] * persia notes that MOTU SWAT may want to examine bugs subscribed to the security team to pull several universe bugs that are being filed around now [11:35] Hobbsee: what about catching up now? [11:35] Hobbsee: do you have my Australian mobile number? [11:37] white: i don't think i do [11:38] white: 9th or so is good, though [11:39] Hobbsee: you got mail [11:39] 8th or 9th would be good [11:39] cool, OK [11:40] i forgot to write an email to the sydney ml, but if you know anyone, just bring them along ;) [11:40] i don't. i suggest you email them [11:40] well, i know of some, but only on irc, etc [11:40] well who is there? [11:41] btw can anyone reproduce http://bugs.gentoo.org/show_bug.cgi?id=203777 ? [11:41] bugs.gentoo.org bug 203777 in Vulnerabilities "dev-libs/libcdio < 0.78.2-r2 Buffer overflow via long filename in Joliet (CVE-2007-6613)" [Normal,Assigned] [11:46] * persia notes that it is a very good idea to subscribe to a bug when posting a debdiff. [11:50] Hobbsee: got my phone number? [11:50] white: yes [11:51] good :) [11:51] Hobbsee: i'll read mail until tomorrow/sunday and then leave Germany, so either mail me place/time or call me on tuesday, when I am in .au :) [11:52] ok [12:00] Gday all [12:00] heya ChrisGibbs [12:00] ChrisGibbs: fancy going south and getting your key signed? white is looking for people to meet [12:02] when? [12:05] ChrisGibbs: wednesday [12:05] hi all [12:06] Hobbsee: Soz to plead ignorant but "key signed" ??? [12:06] ChrisGibbs: do you have a gpg key yet? [12:06] !gpg [12:06] gpg is the GNU Privacy Guard. See https://help.ubuntu.com/community/GnuPrivacyGuardHowto and class #8 on https://wiki.ubuntu.com/ClassroomTranscripts [12:07] Hobbsee: nope haven't bothered yet [12:07] ChrisGibbs: ahh. you'll need it for packaging [12:08] Hobsee: Think i came in 1/2 way through a conversation.... looks like i will half to catch up :) [12:17] Hello, if the copyright holder be someone other than the author, should that holder be some company (as Canonical?) or could it be some group (that is not actually a company) [12:19] AnAnt: When a work is created, copyright is held by the author. In some cases, the author may choose to assign copyright to someone else (another person or some corporate entity (whether registered with a government or not)). [12:20] persia: yeah, could that someone else be some group, which is not a corporate entity ? [12:20] Once copyright is assigned, the assignee becomes responsible for licensing. In general, except in work-for-hire situations, it is best for the author to either retain copyright, or assign to some party holding copyright for a larger work for which the creation under consideration is but one part. [12:21] MOTU Q&A today ? [12:22] AnAnt: "corporate entity" means any group of persons that carries an individual identity. Most nation states allow registration of selected corporate entites, which entitles registered entities to many of the rights of natural persons, but unregistered entities are acceptable for copyright ownership, so long as there is a well defined identity (although most nation states do not honor protection of principles from liability claims in such cases) [12:22] AnAnt: in US law it can afaik be anyone [12:23] man-di: Not just US. Applies to all signatories of the Berne convention. [12:23] AnAnt: in german law the assignment issue is a bit more cimplicated [12:23] mruiz: Holiday break, but ask a question here, if you like. [12:23] man-di: Do you need confirmation from the assignee to assign copyright in Germany? [12:23] persia, I do [12:24] persia: the german law doesnt know copyright assignment [12:24] man-di: Even for work-for-hire? [12:25] persia: depends [12:25] I'm no lawyer [12:25] what a complex issue [12:26] AnAnt: What are you trying to accomplish. While none of us is your counsel, we can probably point to a similar case that might be a way to resolve your need. [12:26] ? === cprov-away is now known as cprov-out [12:26] * persia notes that several major German companies appear to assert copyright over the content on their website, and thinks German copyright must be complex indeed. [12:27] persia: well, we are doing a distro based on ubuntu, called "Ubuntu ME", so some of us did some artwork packages [12:27] persia: we are not a company, we are just some people on a mailing list [12:27] persia: anyways, I am doing the packaging [12:28] persia, full interdiff uploaded ;-) [12:28] persia: so I dunno wether to set the copyright holder to the named persons who did the work, or what [12:28] persia: so I dunno wether to set the copyright holder to the authors, or what [12:29] AnAnt: OK. There are three simple ways to address that. 1) list the individual copyright holders in debian/copyright, 2) have all the individual copyright holders agree there is a "Ubuntu ME team", and assign copyright to the team (yes, this is questionable in some jurisdictions, but if all the individuals continue to agree, there will be no problem: see earlier note about liability protection), 3) register your team with some nation state. [12:29] #1 is the common solution (it's easiest) [12:30] mruiz: Why tell me? Better to get the status, assignment, and subscriptions correct :) [12:31] persia, as you did the last comment... status, assignment and subscription are ok ... ;-) [12:31] Hobbsee: Soz got booted from server, what were you saying b4 about meeting up with white? [12:31] mruiz: Sure, but I usually process the queue in one or two swipes a day. Someone else will likely upload it. [12:32] ChrisGibbs: meeting. wednesday probably. sign keys, which you'll need for doing anything packaging based, bzr based, etc. lunch or dinner - unsure which. [12:32] Hobbsee: hmmm i have to work on Wednesday, i will ask on Mon if i can score an RDO [12:32] cool [12:33] ChrisGibbs: beersigning yeaaaaaaah :) [12:33] persia, I know... that's the idea: interaction with the entire team :-) [12:36] Bah! packages.qa.d.o doesn't report contrib/ and non-free/ anymore ! [12:43] I did an upload to REVU 15 minutes ago, yet I can't see it on REVU's website [12:44] AnAnt: which package? [12:45] I was working on a watch file fix (bug 180113) but UEHS doesn't list the package (gnustep-ppd) anymore and my contribution isn't uploaded yet. Any idea? [12:45] Launchpad bug 180113 in gnustep-ppd "Debian watch file doesn't work" [Low,Incomplete] https://launchpad.net/bugs/180113 [12:45] persia: usplash-theme-ubuntume [12:46] mruiz: Interesting. Does the old watchfile work again for some reason? [12:46] persia, let me check... [12:47] AnAnt: I don't see it in either the upload queue or the rejected queue. [12:47] persia, I got the same error [12:47] AnAnt: I do see http://revu.ubuntuwire.com/details.py?package=usplash-theme-ubuntume however, so I'm guessing you hit just the wrong timing :) [12:49] mruiz: In that case, I'd recommend reporting that you can still reproduce the bug, and that your patch still fixes it, and resubmitting to the sponsors queue. On the other hand, I don't understand why this package was in UEHS anyway: it looks like a sync from Debian, in which case the watch file is better submitted to Debian. [12:50] many patches work in Debian... how is the procedure to submit them ? [12:51] mruiz: The reason we don't include packages from Debian in UEHS is that we rely on the Debian maintainers for the updates in most cases. When we get enough hands to be able to keep everything in UEHS up to date, maybe chasing those will be more interesting. There is one exception: we do include orphaned packages in UEHS, but that is only because there is no Debian maintainer: if it is maintained, we don't want to update without a good reason. [12:51] persia: meaning what? [12:52] mruiz: To submit bugs to debian, first test on Debian (chroots and VMs are popular). If you can reproduce, you file a bug in the BTS by sending mail. http://www.debian.org/Bugs/Reporting provides an overview of the process. [12:53] persia: so I should just re-upload ? [12:53] persia: isn't REVU on revu.tauware.de ? [12:53] AnAnt: Assuming you are talking about "a good reason", that being it includes some new feature or bugfix that a member of ubuntu-dev believes will improve the next release sufficiently to be worth possibly having different tarballs from the Debian update. [12:53] AnAnt: It's already uploaded, no? Also, REVU works at both sites: same machine, different names. [12:54] persia: how do I know that it is uploaded ? [12:54] AnAnt: You see the page with your upload (from the URL I provided above). [12:55] persia: ah, ok, it's on REVU now, thanks [12:56] ok, can anyone please review: http://revu.tauware.de/details.py?package=usplash-theme-ubuntume ? === Hobbsee_ is now known as Hobbsee === cprov-out is now known as cprov [13:34] mruiz: Only one of debdiff or interdiff is required. Debdiff when the orig.tar.gz is unchanged, and interdiff when it is changed. Native packages always get only a debdiff. [13:50] Wow, multiverse FTBFS almost reduced to zero. :-) [13:59] * mruiz writes persia's comments [13:59] I need some guidance with the bug 180131, please [13:59] Launchpad bug 180131 in gshutdown "Debian watch file doesn't work" [Low,In progress] https://launchpad.net/bugs/180131 [14:01] mruiz: what help do you need? [14:02] mruiz: If I understand correctly, the scan should only see released sources, not release candidates. [14:03] mruiz: I think the problem is with upstream versioning. In Debian/Ubuntu terms 2rc > 2 [14:03] vorian, interesting... [14:04] mruiz: if you only use (*.) the scan will produce results for anything that follows the program- [14:06] A little help please. if a package is split with one of the package being -common, where should .desktop file go? [14:24]