| machina | Hi, I have a question. To fix this upgrade bug ( Bug #206862 ), should I follow the steps outlined here? https://wiki.ubuntu.com/MOTU/Contributing#Preparing New Packages | 02:43 |
|---|---|---|
| ubottu | Launchpad bug 206862 in xsensors "New upstream version (0.60) available" [Wishlist,New] https://launchpad.net/bugs/206862 | 02:43 |
| persia | machina: That package is maintained in Debian. You might want to work with Nick Rusnov to follow up on Debian bug #446530 | 02:44 |
| ubottu | Debian bug 446530 in xsensors "xsensors: New upstream version (0.60) available" [Wishlist,Open] http://bugs.debian.org/446530 | 02:44 |
| persia | But yeah, if you're preparing a new upstream, and it's for Ubuntu only, that's roughly the right procedure. | 02:46 |
| machina | persia: I read the Debian bug report and noticed that Siegfried's call for a follow up on the bug was left unanswered. So I thought I might just package it for Ubuntu, then worry about the debian upstream later... | 02:46 |
| persia | The packaging is about the same for either Debian or Ubuntu. If you prep some work, and contact the maintainer to get it uploaded, you might do well. | 02:47 |
| persia | If not, sure, just update in Ubuntu (but be warned that this may make merging hard if the orig.tar.gz differs in Debian later) | 02:48 |
| machina | I'm pretty new to packaging, what kind of prep work would you mean? | 02:50 |
| persia | OK. I tend to do the following when updating a package. | 02:52 |
| persia | 1) Download the new source | 02:52 |
| persia | 2) Try to apply the previous diff.gz | 02:52 |
| persia | 3) review any patches to the source to make sure they still apply and solve the relevant issue. | 02:52 |
| persia | 4) loot for any bugs in Ubuntu and try to fix them | 02:53 |
| persia | 5) look for any bugs in Debian and try to fix them | 02:53 |
| persia | 6) Look at some other distributions to see if they have any patches that look interesting (and try to apply them) | 02:53 |
| persia | But that's sorta general. Do you know how to manipulate package sources, or are you still learning this? | 02:54 |
| machina | i don't remember much, so yea i'm still learning | 02:55 |
| machina | I know how to apply patches & such though | 02:55 |
| persia | And how to use the various patch systems for debian-format source packages? | 02:56 |
| machina | i'd have to refer to a wiki for that | 02:57 |
| persia | That's OK. I'm just trying to gauge the level of description you need :) | 02:57 |
| persia | I'd guess you're in a good state to try to follow the steps above. Just ask here when you run into something you're unsure about. | 02:58 |
| machina | alrighty thanks | 03:00 |
| nxvl_ | persia: isn't easier use uscan; uupdate? | 05:21 |
| === nxvl_ is now known as nxvl | ||
| === asac_ is now known as asac | ||
| persia | nxvl: uscan only downloads upstream if the watch file works (not often in my experience for packages that don't get much maintenance), and uupdate might work: I just don't tend to use it. | 05:49 |
| persia | Plus neither of them do the rest of the hunting about to get something in good shape vs. just pushing a new upstream. Again, this is more important when there isn't active coordination between distro and upstream maintainers. | 05:50 |
| nxvl | persia: oh! that might be it, i always work really close with upstream | 05:55 |
| nxvl | persia: and try to get 0 patches | 05:55 |
| nxvl | in the packages i maintain, i mean, which are the ones that i usually update | 05:56 |
| persia | That's the best option, if you're the maintainer. When dealing with packages that someone else maintains that haven't been updated in a while (or even more fun, with packages with no maintainer), other bits become useful. | 05:56 |
| persia | But that's a matter of whether one actually cares about packages, or is just trying to keep the distro relatively current and bug-free (in the latter case, one is much more likely to need to use my full list of steps) | 05:57 |
| nxvl | yeah, well i maintain my packages in debian | 06:00 |
| nxvl | :D | 06:00 |
| * persia tries to avoid owning packages, but is becoming increasingly unsuccessful. | 06:00 | |
| nxvl | heh | 06:01 |
| nxvl | yeah, i gived up long ago | 06:01 |
| nxvl | :D | 06:01 |
| === RAOF_ is now known as RAOF | ||
| dholbach | good morning | 07:37 |
| thekorn | hey MOTUs! | 08:06 |
| thekorn | if anyone feels like doing some packaging reviews | 08:06 |
| thekorn | http://revu.ubuntuwire.com/p/python-fusepy or http://revu.ubuntuwire.com/p/zeitgeist-filesystem | 08:06 |
| thekorn | might be a good start of this pre-christmas week ;) | 08:06 |
| persia | thekorn: Just a couple notes on python-fusepy: 1) some of the upstream files don't appear to have a license, 2) why choose GPL for the packaging when the code is ISC? | 08:25 |
| thekorn | persia, thanks for looking at this package, 1.) my understanding of the packaging process is that I just package what the upstream author gives me, so if he decides to not add a license to the header of his examples, it is his decision | 08:31 |
| thekorn | and I also thought that adding the license to debian/copyright covers the issue of missing license headers | 08:32 |
| persia | thekorn: You are entirely correct about packaging only what upstream gives you in terms of licenses. Where this gets tricky is that you need to be able to demonstrate not only that you have a license to distribute it to Ubuntu, but that you have a license to permit Ubuntu to distribute it to users. | 08:32 |
| persia | And no. Only getting upstream to release something different, or deleting stuff from the tarball addresses licensing issues. That said, there are some fuzzy areas: it all depends on how well it's argued. | 08:33 |
| persia | For instance, if you had some reference that demonstrated that these unlicensed example files were intended for open release, you could include that documentation, which might cover it. | 08:33 |
| persia | But the default state of code is that it cannot be distributed without explicit permission from the author. | 08:34 |
| thekorn | ok, so ther are tow solutions: get in contact with the author and ask him to add a license or give me explicit permission, or remove the examples from the package? | 08:35 |
| persia | That's my opinion. | 08:35 |
| wgrant | And it is also the generally held opinion around here, I believe. | 08:36 |
| persia | For fairness, I'll mention that others believe that one can argue that some files can be distributed without license headers if there is a COPYING or similar file in the root directory of the package. Since there isn't in this case, I'm not sure that argument applies. | 08:36 |
| thekorn | ok, thanks, I think will will contact him, having a package without examples is bad | 08:36 |
| persia | thekorn: OK. I recommend mentioning that you're packaging it for a distribution, and need the explicit grant of redistribution rights. | 08:37 |
| persia | Because the author is perfectly correct to distribute without explicit licensing if those files are only intended for educational purposes, and only intended for original recipients of the tarball from upstream. | 08:38 |
| persia | Unless, of course, if the author is distributing from Honduras or Nicaragua, in which case the files do not automatically carry implicit reservation of rights, but I wouldn't want to count on that. | 08:39 |
| persia | thekorn: What about the second question? | 08:39 |
| thekorn | persia, honestly, I did not think about this, I used what dh_make created for me, is this an issue if the packaging license is different to the code license? | 08:41 |
| persia | That's again a matter for debate. I like to keep them the same as the contents of the diff.gz are typically considered the packaging, and it means that any patches added to diff.gz automatically are license-compatible with upstream. | 08:41 |
| persia | Of course, there are others who believe that use of the GPL is more important than supporting upstream: for them, your choice is correct. | 08:42 |
| persia | (because ISC code can be imported into GPL code, but GPL code cannot be exported to ISC) | 08:42 |
| persia | This is complicated because some people argue that small patches are not sufficiently significant works on their own to carry a license, and so adoption regardless of license compatibility may be considered fair use in some jurisdictions. It's also complicated because if you borrowed packaging hacks from GPL packaging, you need to preserve that, if you believe the hacks are significant enough to warrant licensing. | 08:44 |
| * directhex kicks persia out of GNU-related groups, for suggesting that using GPL *isn't* the most important goal | 08:44 | |
| thekorn | hmm, this license stuff makes me crazy, I'm not a lawyer! | 08:44 |
| persia | thekorn: I suspect the majority of us aren't. That's why I tend to use the following rules | 08:44 |
| persia | 1) Everything must be licensed to be DFSG-free (or at least Ubuntu-free). | 08:45 |
| persia | 2) Packaging should be the same license as upstream | 08:45 |
| persia | Following these rules means you end up having a lot of back-and-forth with upstream about licensing, and there are some restrictions about pulling patches from other's packaging for certain packages, but should protect you from any legal implications. | 08:46 |
| persia | (of course, if you want real advice, speak to someone who is authorised to dispense advise) | 08:47 |
| thekorn | you should this rules to a section of the packaging guide ;) | 08:47 |
| persia | thekorn: Seems it already exists: https://wiki.ubuntu.com/PackagingGuide/Complete#Copyright%20Information | 08:50 |
| persia | At least some of that comes directly from one of my -classroom sessions, but it's been fleshed considerably since then. | 08:50 |
| persia | Bascially, rule #1 is the first bullet in the first list, and rule #2 is interesting thing 3 about debian/copyright | 08:51 |
| thekorn | persia, ah ok, thanks. I had a hard time reading this huge wiki page, I must have missed this section | 08:51 |
| thekorn | another solution for my special case would be to just include the one file (fuse.py, which has a license header etc.) I need into my product (zeitgeist-filesystem) into the package | 08:52 |
| thekorn | which should be ok license wise, | 08:52 |
| persia | Well, it's only the examples (and memory3.py) that don't have licenses. You'd have to modify the original tarball. | 08:53 |
| persia | It's worth an email to upstream. If that doesn't result in a fix soon, then removing the extra files (which aren't used for most stuff), and including something in README.Debian explaining where to download examples would work. | 08:53 |
| thekorn | persia, ok thank you very much. I'm contacting upstream now | 08:54 |
| persia | thekorn: Good luck. | 08:55 |
| thekorn | thanks | 08:56 |
| * persia is enjoying REVU. Anyone else have a request (or shall I just pick one?) | 09:05 | |
| thekorn | persia, thanks for looking at zeitgeist-filesystem on REVU too | 09:22 |
| persia | thekorn: Same set of issues, really :) | 09:34 |
| thekorn | persia, with one difference: I'm upstream for zeitgeist-filesystem, so communicatin should be a bit smoother ;) | 09:35 |
| persia | thekorn: We can hope :) | 09:35 |
| Rhonda | I wonder, is it possible to list more than just 10 strings in the the translations part of launchpad? Given that it takes a bit to load even that it would be much more convenient to have more than just 10 on a page. :/ | 10:23 |
| persia | There's some way to interact with .pot files. Ask in #launchpad@freenode | 10:27 |
| Rhonda | Yes, I saw that - somehow that would though be just a workaround. :) | 10:29 |
| persia | There may also be a way to translate more strings at once (I'm not sure: I've not used Rosetta in years). | 10:30 |
| Rhonda | Well, one can translate 10 strings at once through the web interface. | 10:31 |
| dpm | Rhonda, you can hack the URL to specify a bigger batch size (i.e. more translations to be presented on a page). Let me give you an example... | 10:32 |
| dpm | Rhonda, for example https://translations.launchpad.net/ubuntu/karmic/+source/evolution/+pots/evolution/ca/+translate?start=10&batch=30 -> you can specify the batch parameter to get more translations shown on the web UI - IIRC the limit is 30 or 50, though | 10:35 |
| Rhonda | dpm: Oh, didn't know about the batch argument, cool! Usually I _do_ hack URLs where it's obvious, but I didn't know that there's such an argument. :) | 10:36 |
| dpm | Rhonda, yes, I think they stopped showing it so that people do not overuse it. There didn't use to be a limit on the batch size either, but it was then limited for performance reasons AFAIK | 10:40 |
| AnAnt | Hello, I am developing a software that has some files covered under GPL3+ & others under CC-BY-SA, how should I put the copyright files ? | 10:53 |
| AnAnt | concat both licenses in the COPYING files ? | 10:53 |
| AnAnt | btw, the question is regarding upstream software | 10:53 |
| persia | First, check the CC and GPL sites to get some opinions on compatibility. MY memory is that not all versions of the GPL are compatible with all versions of CC-BY-SA. | 10:56 |
| persia | Second, you'll want to specify which files fall under which licenses in debian/copyright | 10:56 |
| AnAnt | persia: do I have to specify which files in upstream's COPYING too ? | 10:57 |
| persia | http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html shows an example with GPL and LGPL that might give you a starting point. | 10:57 |
| persia | No, Upstream is different. | 10:57 |
| persia | So, Upstream should either include two license files (neither needs be named COPYING, so long as they are clearly named), or put both in COPYING with some description. | 10:58 |
| persia | Then, in each upstream file, specify which license applies. | 10:58 |
| AnAnt | persia: thanks | 10:59 |
| directhex | only cc-by-sa 3.0+ is dfsg | 11:11 |
| directhex | CC isn't GPL-compatible | 11:12 |
| persia | directhex: I thought there was some version of CC that was compatible with some version of the GPL. Are you sure that never got resolved? | 11:17 |
| directhex | persia, i'm going by gnu.org, not that i trust those rabble-rousers | 11:18 |
| === alkisg1 is now known as alkisg | ||
| persia | directhex: Hrm. I thought I saw something, but the only mention of CC-BY-SA-3.0 on gnu.org I can find is a declaration of it's compatibility with GFDL1.3. I see lots of negative stuff about CC-BY-SA 2.0. I see nothing about CC-BY-SA 2.5. | 11:44 |
| directhex | not the most comprehensive resource | 11:44 |
| persia | No, but it provides handy guidelines. I suppose each upstream is basically on their own when it comes to selecting from what sources they may draw. | 11:45 |
| Quintasan|Szel | persia: hi, the rest of the vote will be on MOTU Council mailing list? | 11:54 |
| persia | Quintasan|Szel: Yes. So far, it's looking good. If the others don't vote in a few days, I'll just record them as abstaining, and complete processing your application (probably near the end of the week) | 11:55 |
| Quintasan|Szel | persia: Okay, thanks for letting me know :) | 11:56 |
| slytherin | A bit off topic. Does anyone have a link to a howto about adding help to a GTK application? | 12:02 |
| jbicha | slytherin: try the guides at the bottom of http://library.gnome.org/devel/guides | 13:07 |
| slytherin | jbicha: thanks | 13:07 |
| quadrispro | ehy guys, should I wait for an ubuntu-sru ACK before uploading to -proposed or not? | 13:32 |
| matti | I would wait. No harm done in waiting ;p | 13:32 |
| matti | Sit back and relax. | 13:32 |
| matti | Have some tea ;p | 13:32 |
| slytherin | quadrispro: You must wait. | 13:34 |
| quadrispro | Yep, so I know the process well :) | 13:35 |
| quadrispro | thank you | 13:35 |
| matti | ;p | 13:35 |
| matti | Please, don't call it "The Process" ;p | 13:35 |
| matti | It should like my work place ;p | 13:35 |
| matti | s/should/sounds/ | 13:35 |
| === elky is now known as Guest4966 | ||
| === ttx_ is now known as ttx | ||
| ScottK | It looks like oprofile is in serious need of a merge and doko is unlikely to get to it soon, so if someone is looking for profitable work to do .... | 14:46 |
| hyperair | profitable? | 14:46 |
| ScottK | hyperair: As in useful. | 14:47 |
| hyperair | ah | 14:47 |
| hyperair | =) | 14:47 |
| slytherin | hyperair: Have you ever successfully setup remuco-vlc in karmic? | 14:49 |
| hyperair | never tried, really | 14:49 |
| hyperair | ..speaking of remuco, i'm supposed to get it updated in debian! | 14:49 |
| * hyperair facepalms | 14:49 | |
| * hyperair prepares to fire off an RFS | 14:50 | |
| slytherin | hyperair: I was able to use remuco-totem. But -vlc doesn't work. | 14:50 |
| hyperair | i'll give it a go later | 14:50 |
| slytherin | And I think there is some serious problems with Sony Ericsson phones. They always give me trouble with bluetooth. | 14:50 |
| hyperair | mine's a sony ericsson s500i | 14:51 |
| hyperair | it works wonderfully | 14:51 |
| hyperair | both with remuco and without | 14:51 |
| hyperair | as in, the builtin bluetooth control thing works pretty well too | 14:51 |
| slytherin | then it is problem with my phone. | 14:52 |
| hyperair | probably | 14:52 |
| hyperair | i'd try with a windows machine to see whose fault it is | 14:52 |
| slytherin | hyperair: I don't have a windows machine. | 14:53 |
| hyperair | oh well =\ | 14:53 |
| hyperair | if your bluetooth transmitter uses usb, you could try getting virtualbox to hijack it, if you have a virtual machine with windows on it | 14:54 |
| === mehdid_ is now known as mehdid | ||
| slytherin | hyperair: that is not an option either. My laptop has sufficient memory to run VB but it is powerpc. My PC is i386 but not sufficient memory. :-P | 14:55 |
| hyperair | heh i see | 14:56 |
| hyperair | ouch =p | 14:56 |
| hyperair | does the PC have issues with bluetooth? | 14:56 |
| hyperair | also, what kind of troubles did you have with your phone? | 14:57 |
| slytherin | All sorts of. Pairing doesn't work reliably (pin dialog doesn't come up on PC). File transfer doesn't work etc. | 14:57 |
| slytherin | hyperair: you are still using thirdparty sources for compiling client right? | 15:05 |
| hyperair | slytherin: no. not at all. | 15:06 |
| hyperair | the client was only included once oben (upstream) got rid of the need for including third party sources. | 15:07 |
| hyperair | something about stubs | 15:07 |
| slytherin | ok. | 15:07 |
| slytherin | hyperair: Are you anyway familiar with the client code? | 15:10 |
| hyperair | slytherin: not at all. but i'm educated somewhat in java. (it's the only language my formal education has covered, and one of the languages i really loath) | 15:12 |
| slytherin | hmm. I guess I will have to take my own help. :-) | 15:13 |
| hyperair | slytherin: you could poke the author. | 15:14 |
| slytherin | hyperair: I want to debug why the client does not detect bluetooth capability on my wife's phone. Will check code first. | 15:18 |
| bddebian | Heya gang | 15:30 |
| === runasand_ is now known as runasand | ||
| dholbach | who can I interest in running a session at the next Ubuntu Developer Week? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep still has a couple of empty slots :) | 16:06 |
| EzraR | how long does it take a package to get into testing from unstable | 16:44 |
| maco | 10 days i think | 16:45 |
| EzraR | if a package was added to testing a couple days ago will it be in testing in time to get added to lucid? | 16:45 |
| EzraR | oh nice | 16:45 |
| EzraR | thats not long | 16:45 |
| EzraR | if said package fixes a bug can it get upgraded in karmic (not backports) | 16:47 |
| EzraR | a bug that makes the package not work by default | 16:47 |
| EzraR | would that be a SRU? | 16:48 |
| cjwatson | EzraR: http://wiki.ubuntu.com/StableReleaseUpdates; if the package is just plain non-functional, then yes the fix may be eligible for a stable update | 17:04 |
| cjwatson | EzraR: 10 days> but this depends on other things, 10 days is just the normal minimum | 17:04 |
| === ghostcube_ is now known as ghostcube | ||
| EzraR | ok so once it hits lucid put a SRU request | 17:15 |
| EzraR | thnx | 17:15 |
| joaopinto | will python2.5 be removed on Lucid ? | 17:30 |
| ScottK | I would imagine so, but it's up to doko. | 17:49 |
| randomaction | Any idea what's happening here? Package was apparently synced twice (bug 402089, bug 484679), but is still at older version. | 21:15 |
| ubottu | Launchpad bug 402089 in fox1.6 "Please sync fox1.6 1.6.25-1.1 (universe) from Debian unstable (main)." [Wishlist,Fix released] https://launchpad.net/bugs/402089 | 21:15 |
| ubottu | Launchpad bug 484679 in fox1.6 "Please sync fox1.6 1.6.36-1 (universe) from Debian unstable (main)." [Wishlist,Fix released] https://launchpad.net/bugs/484679 | 21:15 |
| === elky is now known as Guest4966 | ||
| geser | randomaction: interesting, usually the AA sync script complains when the switch to overwrite the ubuntu delta got forgotten | 21:20 |
| === Guest4966 is now known as elky | ||
| randomaction | I think I'll reset one of these bugs to Confirmed and ask AAs to look once again. | 21:28 |
| ScottK | randomaction: Is it a v3 source package in Debian? | 21:31 |
| randomaction | it's not afaict (no debian/source/format) | 21:33 |
| geser | randomaction: you could try if slangasek or james_w have time to look at it as this seems to be special | 21:33 |
| geser | ScottK: the first sync which failed is from July | 21:33 |
| ScottK | Oh. | 21:34 |
| ScottK | md5sum mismatch? | 21:34 |
| joaopinto | hi | 21:34 |
| ajmitch | different upstream version | 21:34 |
| joaopinto | is there any utility that lists conflicting packages from a repository ? I mean doing a recursive analisys | 21:34 |
| randomaction | yep, second sync is for newer upstream | 21:34 |
| persia | kees: I was trying to make mk-sbuild-lv work on ports architectures, and I wondered if there was a difference between -updates and -security on security.ubuntu.com (there is a vast difference on ports.ubuntu.com) | 21:46 |
| joaopinto | hum, any idea how apt install recommends deals with conflicts ? If a package is recommended but conflicts with an installed package is it simply not installed ? | 21:47 |
| StevenK | persia: It has just worked for me before? | 21:47 |
| geser | joaopinto: try it out in a pbulder? | 21:48 |
| persia | StevenK: Then you were 1) defining an lpia chroot, and 2) using security.ubuntu.com ${RELEASE}-updates for security (if you enabled security) | 21:48 |
| joaopinto | geser, I would need to find a conflict case :P | 21:48 |
| persia | StevenK: Or at least it failed completely to work for me with powerpc and armel (until I changed some stuff). | 21:49 |
| StevenK | persia: I was undoubtedly doing both of those | 21:49 |
| persia | There was a bunch of special-case code to make lpia chroots work on i386 or amd64 machines. I'm not sure they would have worked for a native lpia schroot. | 21:50 |
| slangasek | randomaction, geser: the fox1.6 sync failure isn't due to the missing 'force' switch, it's because the source package in Debian is broken and has no sourceful Section field | 22:04 |
| slangasek | (this only gets detected when trying to flush the syncs to the archive, so is easily overlooked) | 22:04 |
| slangasek | randomaction, geser: documented now in bug #484679 | 22:06 |
| ubottu | Launchpad bug 484679 in fox1.6 "Please sync fox1.6 1.6.36-1 (universe) from Debian unstable (main)." [Wishlist,Won't fix] https://launchpad.net/bugs/484679 | 22:06 |
| geser | slangasek: thanks for looking at it | 22:07 |
| randomaction | slangasek: thanks for looking | 22:07 |
| === Adri2000_ is now known as Adri2000 | ||
| === jMyles_ is now known as jMyles | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!