| soc | hi, i packaged the fonts of the android mobile platform, could someone review them? http://revu.ubuntuwire.com/details.py?package=ttf-droid | 01:49 |
|---|---|---|
| === hyperair1 is now known as hyperair | ||
| vorian | Laney: are you about? | 02:31 |
| === jono_ is now known as jono | ||
| savvas | darn, aptitude 0.5.0 didn't make it with its fancy aptitude-gtk gui in ubuntu :\ | 03:03 |
| persia | savvas, Should it have? | 03:05 |
| savvas | persia: I don't have anything to back it up except for the wish to try it out - so probably no :) | 03:06 |
| persia | savvas, Try it out in a PPA. If you come up with a convincing reason, it could be a candidate. | 03:06 |
| persia | That said, it's fairly core, so time is of the essence. | 03:06 |
| savvas | you're right, I'll do that! | 03:07 |
| savvas | persia: come to think of it, it should wait for another release and a proper review - there's a dependency on apt-xapian-index package that looks quite interesting | 03:14 |
| savvas | I'll give it a go in my ppa though, maybe I'll find something radical :) | 03:17 |
| persia | savvas, Good catch. We'll certainly catch it for autosync for jaunty+1. | 03:18 |
| serialorder | microsoft sure is creative... oh wait I have seen this model before: http://news.zdnet.com/2424-9595_22-256995.html | 03:31 |
| === Jazzva_ is now known as Jazzva | ||
| === hyperair1 is now known as hyperair | ||
| * ScottK runs python3.0 for the first time. | 05:08 | |
| === emgent_ is now known as emgent | ||
| fabrice_sp | Hi, I've used requestsync to request a sync for icu4j package (bug #314615), and Package Archive admin has been directly subscribed, without the sponsorship step. | 05:50 |
| ubottu | Launchpad bug 314615 in icu4j "Please sync icu4j 3.8.1-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/314615 | 05:50 |
| fabrice_sp | Is there a problem? (the -s flag doesn't work in requestsync) | 05:51 |
| persia | fabrice_sp, There've been a few bugs reported against requestsync. You might try tweaking the code to point at staging.launchpad.net, and fiddle a bit to determine if you've found one. | 05:52 |
| fabrice_sp | ok persia. And about the bug? Will P-A-a reject the request as no sponsorship has been done? | 05:53 |
| persia | Or ignore it. I'd recommend subscribing the sponsors now. | 05:54 |
| fabrice_sp | ok | 05:54 |
| fabrice_sp | thanks | 05:54 |
| fabrice_sp | thanks for the ack, persia ;-) | 06:19 |
| iulian | G'morning. | 06:19 |
| fabrice_sp | (and there is a bug in the launchpad interface, as according to syncrequest, I am a member of ubuntu-dev) :-S | 06:19 |
| fabrice_sp | Morning iulian | 06:20 |
| iulian | Hiya fabrice_sp. | 06:20 |
| === emgent_ is now known as emgent | ||
| binarymutant | hi all, just wondering if someone could point me to some Ubuntu ruby policy, I've read Debian's policy and can't seem to find Ubuntu's | 06:46 |
| dholbach | good morning | 06:46 |
| persia | binarymutant, In practice, they are identical. | 06:47 |
| binarymutant | thanks persia :) | 06:48 |
| liw | binarymutant, I don't know much about Ruby, but generally, unless Ubuntu has documented doing something differently, you can assume that Debian's stuff applies to Ubuntu as well | 06:48 |
| binarymutant | okay thats what I thought, just making sure thanks :) | 06:48 |
| fabrice_sp | good morning dholbach | 06:57 |
| dholbach | hiya fabrice_sp | 06:58 |
| didrocks | good morning o/ | 07:05 |
| dholbach | hi didrocks | 07:06 |
| didrocks | hi dholbach :) | 07:16 |
| _ruben | this probably not the best place to ask but dont know any better place .. when i use debmirror to create a local mirror, why do some packages get deleted when there's a new version available, and others do not (keeping old versions around which could come in handy) | 07:52 |
| liw | _ruben, do you have more than one release ("distro") in the mirror? if so, the old versions might be in those | 08:06 |
| _ruben | liw: true, but the downloaded list output by debmirror tends to be a fair bit larger than the deleted list | 08:07 |
| === hyperair1 is now known as hyperair | ||
| \sh | moins and happy new year :) | 08:16 |
| thekorn | hi \sh! happy new year to you too | 08:38 |
| soc | good morning, i packaged the fonts of the android mobile platform, could someone review them? http://revu.ubuntuwire.com/details.py?package=ttf-droid | 09:47 |
| === Skiessio is now known as Skiessi | ||
| Laney | vorian: hi | 10:05 |
| === asac_ is now known as asac | ||
| === thekorn_ is now known as thekorn | ||
| === jcfp is now known as Guest38683 | ||
| === Guest38683 is now known as jcfp | ||
| === nhandler_ is now known as nhandler | ||
| === ember_ is now known as ember | ||
| slytherin | calc: I was trying to analyze the build failure for jaxme. What I am not able to understand is that the function names mentioned in the error don't even exist anywhere. | 13:20 |
| vorian | Laney: I was just trying to catch you on irc before i responed to your reportbug bug | 13:56 |
| Laney | vorian: Oh ok, I'll post a thread | 13:57 |
| Laney | we should still update to the new version whatever happens, as the default (bugs.debian.org) SMTP server is broken apparently | 13:58 |
| ScottK | Laney: There isn't a good default we can put there. | 13:58 |
| Laney | Why can't we use Debian's default? | 13:59 |
| Laney | reportbug.debian.org | 13:59 |
| ScottK | Oh. Actually that might work. | 13:59 |
| ScottK | Historically the problem has been that any generic mail server you put in there would need to be an open relay. | 13:59 |
| Laney | the point is that Debian recently changed their default and we still have the old one | 13:59 |
| ScottK | OK. | 14:00 |
| Laney | but I accidently started a discussion which now blocks my upload :( | 14:00 |
| ScottK | What bug are we discussing? | 14:00 |
| Laney | bug 314556 | 14:00 |
| ubottu | Launchpad bug 314556 in reportbug "Please merge reportbug 3.48 from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/314556 | 14:00 |
| Laney | see Don Armstrong's change | 14:00 |
| vorian | I feel some would have strong feelings both ways | 14:05 |
| vorian | (that's too much use of feel) | 14:05 |
| slytherin | is the server used by requestsync an open relay? | 14:07 |
| mgdm | I would hope not... | 14:08 |
| Kalidarn | does anyone know how the RELEASE.gpg file is made | 14:08 |
| Kalidarn | it looks like a detached clearsigned signature | 14:08 |
| Kalidarn | ive tried making my own for sha1s but... i havn't been able to | 14:08 |
| Laney | 288 # get server address | 14:08 |
| Laney | 289 mailserver = os.getenv('DEBSMTP') | 14:08 |
| Laney | 290 if mailserver: | 14:08 |
| Laney | 291 print 'Using custom SMTP server:', mailserver | 14:08 |
| Laney | 292 else: | 14:08 |
| Laney | 293 mailserver = 'fiordland.ubuntu.com' | 14:08 |
| mgdm | Oh, I was taking open relay to mean you could relay to anywhere from anywhere | 14:09 |
| Kalidarn | http://mirror.internode.on.net/pub/ubuntu/releases-DVD/8.10/release/MD5SUMS.gpg | 14:10 |
| slytherin | mgdm: I meant without auth, from a ubuntu.com address, to any address. | 14:10 |
| Kalidarn | im wondering how that was created | 14:10 |
| Kalidarn | it's obviously a clearsigned detached signature of http://mirror.internode.on.net/pub/ubuntu/releases-DVD/8.10/release/MD5SUMS | 14:10 |
| slytherin | calc: found the reason for jaxme FTBFS. | 14:11 |
| mgdm | slytherin: eeek! | 14:11 |
| mgdm | slytherin: that's basically the same thing | 14:11 |
| Laney | I don't think it works like that | 14:11 |
| Laney | it probably relays from anywhere to LP/ubuntu/canonical | 14:12 |
| ScottK | So we changed it to default to report to Debian? | 14:12 |
| ScottK | This is a very bad idea. | 14:12 |
| StevenK | Kalidarn: Look at the --detach-sign to gpg | 14:12 |
| Kalidarn | yeah i tried that | 14:12 |
| Kalidarn | it didnt clearsign though | 14:12 |
| StevenK | Kalidarn: Then you want -a, too | 14:12 |
| Laney | ScottK: No, the default is to die unless you configure bts=debian | 14:12 |
| Laney | die with a message pointing to ubuntu-bug | 14:13 |
| Kalidarn | thanks StevenK | 14:13 |
| Kalidarn | that did work :) | 14:13 |
| Kalidarn | sign i am newb ;) | 14:13 |
| ScottK | Laney: isn't bts=debian the default? | 14:13 |
| Laney | ScottK: The configuration process will set you up to bts=debian, sure, but the patch we've applied kills it before you even get that far | 14:14 |
| ScottK | Laney: I don't see that in your debdiff. | 14:14 |
| Laney | if not self.options.bts or self.options.bts == "ubuntu": | 14:15 |
| Laney | bts isn't configured by default, so it bombs out there | 14:15 |
| Laney | or if the user previously had it set to "ubuntu" | 14:15 |
| ScottK | I see. | 14:17 |
| ScottK | OK. | 14:17 |
| Laney | I just wonder if it should allow you to carry on instead of sys.exit(1) in the unconfigured case (for bts=ubuntu I agree that this is probably correct) | 14:18 |
| ScottK | Laney: Since you have the package that it's wanted to file the bug against and ubuntu-bug is installed by default (I'm pretty sure) why not just fire it off in this case? | 14:21 |
| ScottK | Or try anyway. | 14:21 |
| Laney | I don't know. I'll fire off a mail with options later. I guess some people might think that discouraging end-users from using reportbug at all is a good aim | 14:25 |
| ScottK | Laney: Having it end up someplace useful is even better. | 14:26 |
| * Laney agrees | 14:28 | |
| dholbach | would somebody to give a session at Ubuntu Developer Week about "how to collaborate best with Debian"? | 14:30 |
| Laney | ScottK: Do you think it's a good idea to update reportbug anyway? There's no regression from what's in Jaunty now, and 3.47 could break at any time for people who haven't set up an alternative SMTP host to use | 14:30 |
| dholbach | we still have some open slots | 14:30 |
| Laney | dholbach: Someone from Debian might be best to do that? | 14:30 |
| dholbach | Laney: best somebody from Ubuntu and somebody from Debian? :) | 14:31 |
| Laney | well, yes | 14:31 |
| Laney | Debian: Here's what we want you to do | 14:31 |
| Laney | Ubuntu: Here's how to do it? | 14:31 |
| dholbach | it'd be great to talk about how to forward patches, which patches, how to use the bts, etc | 14:32 |
| dholbach | how to link bugs in LP | 14:32 |
| dholbach | who to talk to | 14:32 |
| dholbach | etc | 14:32 |
| === AstralJa1a is now known as AstralJava | ||
| hanska | ScottK: ping | 15:00 |
| ScottK | hanska: Pong. | 15:12 |
| hanska | ScottK: are you one of the bash-completion maintainers? | 15:13 |
| ScottK | hanska: No. | 15:13 |
| hanska | ScottK: sorry then, I was looking for the maintainers, and I saw your name on LP | 15:13 |
| ScottK | Virtually everything in Ubuntu is at least formally team maintained. I'd suggest looking at debian/changelog to see who's been active on the package. | 15:13 |
| ScottK | Weird. | 15:13 |
| hanska | ScottK: the fact is that Ubuntu guys keep forking an old version of bash-completion | 15:14 |
| hanska | while me and other guys have already released newer versions | 15:14 |
| hanska | (the Debian team became upstream a while ago, and now we also have Fedora and Gentoo guys with us) | 15:14 |
| hanska | so.. I was sending a mail, I'd like to know whom to send it to :) | 15:14 |
| ScottK | Right. | 15:16 |
| slytherin | hanska: send it to ubuntu-motu@lists.ubuntu.com | 15:16 |
| ScottK | Even better subscribe first so it doesn't get moderated. | 15:16 |
| slytherin | hanska: oh wait, the package is in main, so send to ubuntu-devel-discuss@l.u.c | 15:16 |
| hanska | slytherin: I was sending it to the guy who provided the debdiff, the MOTU who did the actual upload | 15:16 |
| hanska | s/MOTU/I_don't_know_how_people_uploading_in_main_are_called/ | 15:17 |
| hanska | :) | 15:17 |
| slytherin | they are called core-dev. | 15:17 |
| slytherin | :-) | 15:17 |
| hanska | ah, great :) | 15:17 |
| hanska | slytherin: ubuntu-devel-discuss or just ubuntu-devel? | 15:24 |
| hanska | (I saw also the latter @ l.u.c) | 15:25 |
| ScottK | hanska: devel-discuss and subscribe first so it doesn't get moderated. | 15:25 |
| slytherin | hanska: ubuntu-devel-discuss. | 15:26 |
| hanska | ScottK: I believe that posting through gmane doesn't get moderated either | 15:26 |
| ScottK | OK. I'd find that suprising. | 15:26 |
| hanska | Sent. Let's see if it arrives. | 15:27 |
| hanska | (otherwise I'll just cancel the post, subscribe and re-send) | 15:28 |
| ScottK | hanska: lists.ubuntu.com does helpfully send backscatter to tell you you're moderated. | 15:29 |
| hanska | ScottK: seems like it arrived, instead. Please check :) | 15:29 |
| hanska | (I believe gmane.org is automagically accepted, since it requests a confirmation mail before sending the *first* mail) | 15:30 |
| * ScottK hasn't got it yet. | 15:30 | |
| hanska | ScottK: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-January/006617.html | 15:31 |
| hanska | ;) | 15:31 |
| ScottK | Got it now. | 15:32 |
| ScottK | hanska: If you can verify that all the Ubuntu changes are in the current Debian package, you can file a sync request. | 15:33 |
| hanska | ScottK: it's not just a sync request | 15:33 |
| hanska | ScottK: it's about joining forces. | 15:33 |
| ScottK | hanska: I agree that you have a broader agenda, but the narrower purpose is useful too. | 15:34 |
| hanska | in what ways? | 15:34 |
| ScottK | I don't know how much reply you're going to get since no one person is minding the package. | 15:34 |
| ScottK | Getting Ubuntu to use the same as Debian instead of the old one. | 15:34 |
| hanska | ScottK: It's not about *Debian*, did you see who's in the team? | 15:35 |
| ScottK | Once it's updated, then it's easier to see the use in working with Debian. | 15:35 |
| hanska | we're Debian, Fedora/RH, Gentoo | 15:35 |
| ScottK | hanska: Yes, but from my perspective as an Ubuntu developer, Debian is upstream. | 15:35 |
| hanska | ScottK: better!. Let me explain | 15:36 |
| hanska | You ("generic" you) receive a bug about bashcomp in LP. What are you going to do? | 15:36 |
| hanska | if the package has been synced from Debian, "fork" an *-ubuntu? version from it, and do the changes there | 15:36 |
| ScottK | Look at it, if I can fix it, upload the fix to Ubuntu and send a patch to Debian in the BTS. | 15:36 |
| hanska | ScottK: no one has ever done that. | 15:37 |
| ScottK | That's because it's so forked at the moment. | 15:37 |
| hanska | ScottK: I keep receiving Ubuntu Merge-o-matic mails about new uploads, and just keep merging changes from you | 15:37 |
| hanska | it's *annoying*. | 15:37 |
| ScottK | Understand. | 15:37 |
| hanska | best would be if an Ubuntu core-dev/MOTU/$with_uploads_power was part of upstream | 15:38 |
| ScottK | What I'm describing is the 'normal' maintenance approach for packages we get from Debian. | 15:38 |
| ScottK | hanska: Except that that would be everyone. That's a bit much. | 15:38 |
| hanska | ScottK: we need just *one*! | 15:38 |
| hanska | btw, that was just a suggestion | 15:39 |
| ScottK | Right, and looking at the history in debian/changelog, except for maybe bryce, I don't know who that would be. | 15:39 |
| hanska | we're being a cross-distribution group now, and having someone from you guys would be great. | 15:39 |
| ScottK | The question is who. In the meantime if it were sync'ed then the odds of people working at least with Debian would go way up. | 15:40 |
| * DktrKranz could have a look at our bash-completion package to see if it can be synced | 15:40 | |
| hanska | DktrKranz: thank you. | 15:40 |
| DktrKranz | and eventually follow its maintenance | 15:40 |
| ScottK | Excellent. | 15:40 |
| hanska | ScottK: I understand Ubuntu's dev model is kinda different from ours | 15:40 |
| DktrKranz | it's in main, so it's quite important because almost everyone uses it | 15:41 |
| hanska | after all, we needed just one volunteer (which seems to have shown up :)) | 15:41 |
| ScottK | DktrKranz: Agreed. | 15:41 |
| hanska | DktrKranz: if you see Debian's changelog, you can see we did quite a lot of improvements. | 15:41 |
| DktrKranz | hanska: I see :) I use it every day, so I can beta-test it before Feature Freeze | 15:41 |
| hanska | DktrKranz: http://bash-completion.alioth.debian.org/ | 15:42 |
| hanska | instructions for bzr ;) | 15:42 |
| hanska | and -- really -- we would have chosen git, but chose bzr for you *lol* | 15:42 |
| DktrKranz | :) | 15:43 |
| * DktrKranz likes git... | 15:43 | |
| hanska | DktrKranz: sure, but I didn't know "the Ubuntu guy" would have been some git-fanboy :P | 15:43 |
| mok0 | Anyone has time to help me debug an FTBFS? Here: https://edge.launchpad.net/ubuntu/+source/illuminator/0.11.0-1/+build/752609 | 15:43 |
| * ScottK looks over at NCommander. | 15:44 | |
| hanska | mok0: petsc-dev: Depends: libpetsc2.3.3-dev but it is not installable | 15:44 |
| mok0 | hanska: right | 15:44 |
| mok0 | uh, wait, I goofed | 15:44 |
| NCommander | ScottK, its just a misidentified depwait | 15:45 |
| ScottK | Oh. | 15:45 |
| * ScottK should have looked before calling in the expert. | 15:45 | |
| NCommander | find what package libpetsc belongs do, and fix it :-) | 15:45 |
| ubottu | package is not a valid distribution ['dapper', 'gutsy', 'gutsy-backports', 'hardy', 'hardy-backports', 'intrepid', 'intrepid-backports', 'jaunty', 'jaunty-backports', 'kde4-ppa', 'kubuntu-members-kde4', 'medibuntu', 'partner'] | 15:45 |
| soc | hi, i packaged the fonts of the android mobile platform, could someone review them? http://revu.ubuntuwire.com/details.py?package=ttf-droid | 15:45 |
| soc | it's a small, uncomplicated package, nothing big | 15:46 |
| hanska | MOTU-related question: is it possible to review packages not being a MOTU? | 15:46 |
| mok0 | hanska, yes | 15:46 |
| ScottK | hanska: What you can't do is advocate them as ready for upload. People who know about packaging, but aren't MOTU are encouraged to help out with reviews. | 15:47 |
| hanska | soc: since you repackaged the tarball, in these days I suggested you to provide a get-orig-source target | 15:47 |
| hanska | but, well... "This package has no debian/watch file or get-orig-source rule.". | 15:47 |
| ScottK | hanska: "Oh, this should really go into Debian and I can help you get it sponsored there" is a really good comment we like to see. | 15:47 |
| ScottK | hanska: That's a good comment as most MOTU would reject a package that didn't have one or the other. | 15:48 |
| hanska | ScottK: IANADD, still in NM, so I can't really sponsor anything ;) | 15:48 |
| soc | hanska: imo it is not possible to get an original tarball by an automated script | 15:48 |
| hanska | soc: why not? | 15:48 |
| ScottK | Right, but if you're on a team in Debian that has willing DD's ... | 15:48 |
| soc | i wrote the url to download the latest version into the control file | 15:48 |
| soc | hanska: i can't download it via wget | 15:49 |
| soc | uscan doesn't work | 15:49 |
| soc | no possibility to get the right version | 15:49 |
| soc | etc. | 15:49 |
| hanska | soc: there are other ways too. Let me give a look at the package | 15:49 |
| soc | ok, one problem after another: | 15:49 |
| soc | a) android uses some weird webgit system, you can download the files, but only via a real browser ... some wierd redirect i guess | 15:50 |
| hanska | uh? | 15:50 |
| hanska | is ./debian/bug/ an Ubuntu-specific layout? | 15:50 |
| ScottK | soc: Can you check it out using git? | 15:50 |
| soc | it is made for reportbug | 15:50 |
| hanska | soc: ACK. That could be useful for us too, I believe. | 15:51 |
| soc | b) to get the version of the fonts, you have to open them in fontforge and read the version, no way to handle this automatically | 15:51 |
| hanska | us == Debian | 15:51 |
| ScottK | hanska: No. I've seen that in other font packages. | 15:51 |
| soc | ScottK: that might be possible, but doesn't solve the whole problem | 15:51 |
| hanska | ScottK: never saw that in any Debian package | 15:51 |
| ScottK | soc: Sure it does. You can use git in your get-orig-source rule. | 15:51 |
| hanska | Debian-proper | 15:51 |
| soc | the biggest problem is the version info, which is only inside the font file itself | 15:52 |
| ScottK | hanska: I think I have, but I wouldn't swear to it. | 15:52 |
| hanska | k | 15:52 |
| hanska | however soc, reviewing your package ;) | 15:52 |
| soc | ScottK: how can i download single files via git? | 15:52 |
| ScottK | soc: Right, then you toss in some awk and sed magic, stir, and presto, new package. | 15:52 |
| soc | or do i have to clone the whole repo for it? | 15:53 |
| * ScottK is almost completely git ignorant. | 15:53 | |
| soc | ScottK: so should i just hardcode the version myself? | 15:53 |
| broonie | You have to clone the whole repository. | 15:53 |
| soc | ouch ... ok | 15:53 |
| soc | and after that i have to clean up the whole mess again? | 15:53 |
| ScottK | soc: Hard coding is almost always the wrong answer. | 15:54 |
| soc | ScottK: so how should i get the version number? | 15:54 |
| soc | really, the version is only available inside the font file ... | 15:54 |
| * ScottK would have to look at the file and is actually trying to do $WORK currently. | 15:54 | |
| broonie | strings or some font-specific utility that can parse the metadata both spring to mind. | 15:55 |
| soc | get-orig-source is a normal bash-file? | 15:55 |
| soc | broonie: do you know a utility that can do that? | 15:55 |
| ScottK | soc: See plasmoid-kbstate for a package with an svn oriented get-orig-source that works. | 15:56 |
| ScottK | That'll at least point you in the right direction. | 15:56 |
| ScottK | You might even be able to convince JontheEchidna to help you. | 15:56 |
| ScottK | Since he's like trying to get approved to be a MOTU and all right now. | 15:56 |
| ScottK | hanska: Look at ttf-sil-scheherazade for a package in Debian that has the bug dir. | 15:59 |
| soc | btw, what's the idea of that get-orig-source? | 16:00 |
| hanska | ScottK: I'll do, thank you | 16:00 |
| hanska | soc: almost completed the review :) | 16:00 |
| ScottK | soc: It exports the head of the svn trunk and makes a tarball out of it. | 16:00 |
| soc | in general i mean | 16:01 |
| soc | afaik, even if the developer uses that script to get exactly the same files again, his tarball won't have the original hash, because of the gzip timestamps | 16:01 |
| ScottK | In general it's to automate fetching a new upstream when you can't just download the tarball. | 16:01 |
| ScottK | Right, you don't do it every time. Just for new upstream version/snapshot/etc. | 16:02 |
| soc | mhh, but it won't fetch a new upstream version, i thought it should get the original source used to package these files? | 16:02 |
| ScottK | Now get the upstream source for the next version. The idea is to make package updates easier. | 16:03 |
| ScottK | It's just make -f path/to/debian/rules get-orig-source. | 16:03 |
| mok0 | soc: reviewed! | 16:03 |
| broonie | ./debian/rules get-orig-source even | 16:04 |
| hanska | mok0: argh :P | 16:04 |
| hanska | beaten on time | 16:04 |
| soc | ok, i guess i just write a script which fetches the latest version of the files and name the package ttf-droid_LOOK-IN-THE-FONTS-METADATA-FOR-VERSION-NUMBER.orig.tar.gz | 16:04 |
| mok0 | hanska: you probably have some stuff I missed :-) | 16:04 |
| pmjdebruijn | soc: I don't think that the plan | 16:04 |
| pmjdebruijn | soc: there's a watch file for that | 16:04 |
| pmjdebruijn | soc: packages are not ment to be built dynamically | 16:04 |
| soc | can i use git in that watchfile? | 16:05 |
| pmjdebruijn | not sure | 16:05 |
| mok0 | soc: don't they distribute a tarball? | 16:05 |
| pmjdebruijn | soc: packages are always built on a concrete upstream release | 16:05 |
| soc | no | 16:05 |
| mok0 | soc: at some point in the future, packages will be created directly using the git repo | 16:06 |
| pmjdebruijn | soc: ttf-droid_1.2+git20090107.orig.tar.gz ? | 16:06 |
| soc | these are the fonts used in the android phone, i guess they will never do a font-release | 16:06 |
| soc | pmjdebruijn: the "1.2" part is the problem.. | 16:07 |
| pmjdebruijn | soc: isn't there a version number in the metadata | 16:07 |
| soc | pmjdebruijn: yes, that's the version from the font's metadata | 16:07 |
| pmjdebruijn | good | 16:07 |
| pmjdebruijn | use that | 16:07 |
| soc | i don't know if there is a command line application to extract that metadata | 16:07 |
| pmjdebruijn | that should correspond to a release number if any... | 16:07 |
| pmjdebruijn | soc: why would you need a command line application for that? | 16:07 |
| mok0 | soc: see my comments @ REVU | 16:08 |
| soc | pmjdebruijn: how should i get the version then? | 16:08 |
| mok0 | soc: I think that makes up for the watch file | 16:08 |
| pmjdebruijn | soc: use fontforge? | 16:08 |
| pmjdebruijn | soc: you only need to look it up onc | 16:09 |
| pmjdebruijn | once* | 16:09 |
| pmjdebruijn | soc: check git, lookup the version, tarball it, call it ttf-droid_FONTVER+gitREVISION.orig.tar.gz | 16:11 |
| pmjdebruijn | does git have revisions? or just dates? | 16:11 |
| maxb | it has revisions, but they have no ordering, so are not suitable for version numbers | 16:11 |
| pmjdebruijn | then i'd stick with checkout date I guess | 16:12 |
| mok0 | soc: also please note that defoma is going away soon | 16:12 |
| hanska | mok0: eh ehm. | 16:13 |
| hanska | mok0: "- Homepage: field should be changed to Vcs-Git: (because it is actually a VCS browser page) " -- this is WRONG | 16:13 |
| mok0 | hanska: I know, see next comment :-) | 16:14 |
| hanska | mok0: Vcs-* fields are meant for *packaging* VCS's, not upstream code's! ;) | 16:14 |
| mok0 | hanska: uhh | 16:14 |
| hanska | mok0: no, lol :D | 16:14 |
| hanska | also Vcs-Browser is for packaging repo | 16:14 |
| ScottK | mok0: He's right. | 16:14 |
| mok0 | Ydrrk | 16:15 |
| hanska | mok0: :) | 16:15 |
| mok0 | I need to read up on policy | 16:15 |
| hanska | soc: I reviewed your package too. | 16:15 |
| soc | pmjdebruijn: afaiu, everytime i download the fonts, i have to look up the version in fontforge, not only once | 16:16 |
| soc | hanska, mok0, pmjdebruijn: thanks! | 16:16 |
| hanska | soc: I'm trying to write a get-orig-source for you, if you don't mind. | 16:16 |
| soc | sure, i would be absolutely happy about that | 16:19 |
| soc | the git line is most probably git clone git://android.git.kernel.org/platform/frameworks/base.git | 16:19 |
| soc | who is dpaleino? is that you, hanska? | 16:20 |
| ScottK | soc: It is. | 16:20 |
| hanska | soc: yes | 16:20 |
| mok0 | hanska: just to add to the existing confusion... :-) | 16:20 |
| soc | :-) | 16:20 |
| hanska | mok0: I'm a picky Debian guy, lol :P | 16:21 |
| soc | ah ok, regarding: "- the long description seems taken from some kind of online journal -- are you allowed to do it? If no, please rephrase it properly, or do it yourself; " | 16:21 |
| * liw wonders about the choice of "hanska" as a nick | 16:21 | |
| soc | it's from the press release, i assumed that would be the right way | 16:21 |
| hanska | liw: just "invented" it somehow (who remembers!) about 15 years ago, or so | 16:21 |
| soc | at least that text has printed "PRESS RELEASE" on the top... | 16:21 |
| liw | hanska, are you aware that it's a word in Finnish, meaning glove? | 16:21 |
| hanska | liw: no, really :) | 16:22 |
| mok0 | I think you are allowed to use press releases freely | 16:22 |
| soc | mok0: you said that defoma is going away, what will happen to that? | 16:22 |
| soc | a, good | 16:22 |
| hanska | mok0: I suppose that too -- but you might never know. | 16:22 |
| ScottK | mok0: Depends on what the license of the press release is. | 16:22 |
| hanska | exactly. | 16:23 |
| mok0 | soc: I don't know, but it seems that way from d-d | 16:23 |
| soc | d-d? | 16:23 |
| mok0 | soc: debian-devel mailing list | 16:23 |
| hanska | mok0: I can confirm that. defoma is outdated, undermaintained, $bad_adjective_here | 16:23 |
| soc | but how will font configuration work then? | 16:23 |
| mok0 | may no fonts in lenny+1? :-P | 16:24 |
| hanska | mok0, soc: there was some ongoing project on replacing it (I admit I hacked it a bit too), but nothing concrete yet | 16:24 |
| hanska | mok0: that's called squeeze! :P | 16:24 |
| mok0 | hanska: oh yes. | 16:24 |
| soc | i don't understand "- the long description seems taken from some kind of online journal -- are you allowed to do it? If no, please rephrase it properly, or do it yourself; " | 16:24 |
| mok0 | hanska: what Toy Story animal is that? | 16:24 |
| soc | oopps, wrong line sorry | 16:24 |
| hanska | mok0: wikipedia --> | 16:25 |
| hanska | ;) | 16:25 |
| soc | i don't understand " - you forgot the boilerplate (s) -- it’s just ONE upstream author! ;) " | 16:25 |
| hanska | soc: minor issue ;) | 16:25 |
| hanska | soc: "Upstream Author:" instead of "Upstream Author(s):" :) | 16:25 |
| soc | ah ok | 16:25 |
| soc | " - you state that Droid is a trademark of Google Corp. Are you allowed to use it in the package name, the descriptions and so on? " | 16:26 |
| soc | that's a very good question ... | 16:26 |
| mok0 | hanska: a 1970's English New Wave band?? | 16:26 |
| hanska | soc: we in Debian had many problems with trademarks *cough* firefox *cough* | 16:26 |
| ScottK | hanska: That's because of restrictions in mozilla's code license. | 16:27 |
| mok0 | hanska: ah, those little cute aliens | 16:27 |
| hanska | mok0: yep | 16:27 |
| hanska | ScottK: the MPL doesn't talk about "Firefox" or "Thunderbird" or "The world with the fox around it"... that's a general-purpose license | 16:28 |
| hanska | ScottK: the fact is, Mozilla Corp. has trademark over those things -- thus can enforce it / prohibit anyone at will to use those. | 16:29 |
| hanska | -- and same could do Google. | 16:30 |
| soc | hanska: mhh, so should i rename the package to something stupid? | 16:30 |
| hanska | soc: no, just ensure you can | 16:31 |
| hanska | soc: example, mail the author and ask him :) | 16:31 |
| soc | which author? | 16:31 |
| hanska | upstream. | 16:31 |
| soc | google bought the whole copyright from Steve Matteson ... | 16:31 |
| hanska | soc: then contact Google! :) | 16:32 |
| soc | mhh, is there a email address where i get an answer in the next few years? | 16:32 |
| hanska | soc: eheh, good question. | 16:32 |
| soc | i always thought, that a trademark is no problem as long as it doesn't restrict your rights? | 16:32 |
| soc | because then debian couldn't use Linux for instance | 16:33 |
| hanska | soc: yes, as long as the holder does not enforce you not to use it | 16:33 |
| hanska | soc: but then neither Ubuntu, Slackware, Gentoo, ... | 16:33 |
| hanska | ;) | 16:33 |
| soc | but that debian problem was that to use the trademark, mozilla wanted specific conditions to be met | 16:34 |
| soc | this isn't the case here, afaiu | 16:34 |
| hanska | soc: however, I'm probably being too picky. Ask an ubuntu dev, maybe in Ubuntu this are different | 16:34 |
| hanska | soc: did you read any condition anywhere? | 16:34 |
| soc | hanska: no, no conditions | 16:34 |
| hanska | soc: wait, I'll try to look in upstream's homepage | 16:35 |
| soc | and normally, poeple are allowed to use trademarks, as long as they don't dilute that brand's image | 16:35 |
| hanska | soc: you can't suppose things. | 16:35 |
| soc | but i want to make sure, that the package can be used in ubuntu _and_ debian | 16:35 |
| hanska | soc: that's great :) | 16:36 |
| ScottK | AFAIK, trademark isn't a problem unless it's known to actually be a problem. | 16:36 |
| soc | so solving that problem is necessary | 16:36 |
| mok0 | soc, btw, you should include the files NOTICE, MODULE_LICENSE_APACHE2 and README.txt | 16:36 |
| soc | ScottK: ah ok, thanks | 16:36 |
| soc | only in the source build? | 16:37 |
| hanska | soc: http://www.android.com/branding.html | 16:38 |
| hanska | 03/ Android Custom Typeface | 16:38 |
| hanska | The custom typeface may not be used. | 16:38 |
| hanska | I suppose that's a problem. | 16:38 |
| hanska | but then again: | 16:39 |
| hanska | For applications, you can use 'Droid' as part of the name if the application adheres to the Developer Content Policy. | 16:39 |
| hanska | Policy being http://www.android.com/market/terms/developer-content-policy.html | 16:39 |
| mok0 | hanska, it says nothing about "droid" | 16:39 |
| hanska | mok0: right, sorry, the fonts are under APL-2 nevertheless | 16:40 |
| hanska | however, that's the link we looked for | 16:40 |
| ScottK | There is also http://www.google.com/permissions/index.html | 16:40 |
| ScottK | Which says to me that you may need a new name. | 16:40 |
| mok0 | "Android" can be used as a descriptor | 16:40 |
| hanska | ScottK: the link I gave before says the contrary | 16:41 |
| hanska | The word 'Android' may be used only as a descriptor, 'for Android'. If used with your logo, 'for Android' needs to be smaller in size than your logo. First instance of this use should be followed by a TM symbol, 'for Android™'. | 16:41 |
| hanska | For applications, you can use 'Droid' as part of the name if the application adheres to the Developer Content Policy. | 16:41 |
| ScottK | OK. | 16:41 |
| ScottK | Dunno. | 16:41 |
| * ScottK goes back to $WORK. | 16:41 | |
| soc | so is it now ok to use "droid" or not? | 16:41 |
| mok0 | apt-cache search google|grep google | 16:41 |
| mok0 | A whole bunch of packages have the word "google" in them | 16:42 |
| hanska | soc: who knows :/ | 16:42 |
| soc | so should we invent some stupid packagename now? | 16:42 |
| hanska | mok0: http://www.google.com/permissions/guidelines.html | 16:42 |
| soc | fedora is packaging it as droid | 16:42 |
| hanska | that says you must fill in a form for permission, blablabla... not suitable for Debian :/ | 16:43 |
| hanska | soc: I suggest you to go with ttf-droid | 16:43 |
| soc | is that ok for debian? | 16:43 |
| hanska | uhm.. | 16:43 |
| * hanska dubious | 16:43 | |
| hanska | the fact is, there are two links/documents saying opposite things | 16:43 |
| hanska | and both are kinda "official" | 16:44 |
| soc | imo opinion the more specific one counts | 16:44 |
| mok0 | hanska: for example, libgoogle-perftools-dev comes from Debian | 16:44 |
| soc | and that is the one in the font directory ... | 16:44 |
| hanska | mok0: I did your same apt-cache line, and there are packages with "google" inside | 16:44 |
| mok0 | hanska: /me thinks you're being paranoid here | 16:44 |
| soc | ok, then i'll package it as ttf-droid | 16:45 |
| hanska | mok0: probably, but you don't know debian-legal guys :D | 16:45 |
| hanska | soc: go :) | 16:45 |
| soc | and if someone complains, we need a stupid name | 16:45 |
| soc | or should i choose ttf-android-fonts? | 16:45 |
| hanska | mok0: I could ask debian-legal, or search there | 16:45 |
| mok0 | hanska: I'm sure they could have a 100-thread flamewar about it :-P | 16:45 |
| hanska | ;) | 16:45 |
| soc | would that be safer? | 16:45 |
| hanska | soc: neither | 16:45 |
| hanska | soc: ttf-android-fonts would have the same problems ttf-droid has. | 16:46 |
| hanska | so, just go ttf-droid :) | 16:46 |
| mok0 | soc: go for ttf-droid | 16:46 |
| mok0 | :-) | 16:46 |
| soc | ok | 16:47 |
| soc | thanks for the advice | 16:47 |
| soc | i'll upload a new package in a few minutes | 16:47 |
| mok0 | In any case, droid is not a trademark they own | 16:47 |
| mok0 | soc, but be sure to include _all_ files from the git repo in your tarball | 16:48 |
| hyperair | mok0: got time for a review? http://revu.ubuntuwire.com/details.py?package=codelite <-- you've reviewed it before, and i've fixed a lot of stuff since then | 16:49 |
| mok0 | hyperair: ok | 16:49 |
| hyperair | mok0: thanks | 16:49 |
| soc | mok0: i thought it was ok to copy them into the right files in debian ... | 16:49 |
| mok0 | soc: no, they have to remain in the tarball as well, because that is distributed as part of the source package | 16:50 |
| soc | ah ok | 16:50 |
| mok0 | soc: people could go to packages.ubuntu.com and download only the tarball | 16:50 |
| soc | ah ok | 16:51 |
| soc | is it allowed at least to clean up these files a bit? | 16:51 |
| soc | do i have to put the ahem.ttf, android.mk, fonts.xml in there too? | 16:51 |
| mok0 | soc: yes, just do that to make things transparent | 16:52 |
| mok0 | soc: then the tarball is an exact copy of the git repo | 16:53 |
| soc | but the ahem.ttf is missing an license | 16:54 |
| soc | that is just some file to test the platform's hinting | 16:54 |
| mok0 | soc: hmm | 16:55 |
| hanska | soc: do a repackaged tarball | 16:55 |
| soc | mhhh, i guess i just take README, NOTICE and MODULE_LICENSE_APACHE2 to be safe | 16:55 |
| hanska | soc: yes, but you have to specify what you removed | 16:55 |
| soc | hanska: what is a repackaged tarball? | 16:55 |
| soc | or what do i have to do for it | 16:56 |
| hanska | what's the version number now? | 16:56 |
| soc | Version 1.00 build 112 | 16:56 |
| hanska | 1.00~b112, right? | 16:56 |
| soc | yes | 16:56 |
| hanska | then, make it 1.00~b112+dfsg-1 | 16:56 |
| soc | what's dfsg? | 16:57 |
| hanska | "dfsg" meaning Debian Free Software Guidelines | 16:57 |
| mok0 | hanska: that's a tilde right? | 16:57 |
| soc | debian free software guidelines? | 16:57 |
| hanska | mok0: yes | 16:57 |
| soc | what does that mean? | 16:57 |
| soc | that it has been verified to confirm? | 16:57 |
| hanska | soc: yes. It's a common practice in Debian to mean that the package had something non-free, which has been removed | 16:57 |
| soc | ah ok | 16:57 |
| hanska | soc: so, you're removing ahem.ttf -- say that in debian/README.source | 16:58 |
| mok0 | hanska, soc, except the version should be -0ubuntu1 and not -1 | 16:58 |
| hanska | (or README.Debian, or whatever) | 16:58 |
| hanska | mok0: right, I'm a Debian guy, remember :) | 16:58 |
| mok0 | s/version/release | 16:58 |
| hanska | soc: you'll end up with 1.00~b112+dfsg-0ubuntu1 | 16:58 |
| hanska | how ugly :) | 16:58 |
| soc | lol :-) | 16:58 |
| mok0 | hanska: it's so it will be superceeded when the package comes to Debian | 16:58 |
| mok0 | hanska: the ubuntu* part means there are ubuntu changes | 16:59 |
| hanska | mok0: yep | 16:59 |
| hanska | I know how dpkg --compare-versions works ;) | 16:59 |
| hanska | (or was it just --compare? Bah!) | 17:00 |
| mok0 | hanska: sorry | 17:00 |
| hanska | mok0: for what? | 17:00 |
| mok0 | hanska: didn't mean to lecture you | 17:00 |
| hanska | mok0: are you kidding?! | 17:01 |
| hanska | mok0: I'm fine! :) | 17:01 |
| mok0 | hanska: ok cool | 17:01 |
| mok0 | hyperair: I have to go -> dinner, not finished reviewing, but I will just submit the 1 comment I have so far | 17:12 |
| hyperair | mok0: okay thanks | 17:12 |
| LucidFox | Wow. Looks like I have been using Intrepid with the Hardy kernel all along, and only realized it today when an update introduced version mismatch to the NVIDIA drivers | 17:13 |
| mok0 | hyperair: looks almost ready though | 17:13 |
| mok0 | hyperair: I see nhandler is ready to advocate too | 17:13 |
| soc | ok, new try | 17:14 |
| hyperair | mok0: yeah. | 17:14 |
| mok0 | later, guys! | 17:14 |
| soc | ok, that will take some hours i guess ... 11k/2091k ... | 17:15 |
| ScottK | hanska: In Intrepid and Jaunty we have a apparmor profile for clamav that prevented (until today) signature updates in user directories. | 17:16 |
| ScottK | hanska: So with your clamtk maintainer hat on I wanted to let you know it's fixed in Jaunty so it should work now. | 17:16 |
| hanska | ScottK: I was just upgrading clamtk to 4.08! :) | 17:19 |
| hanska | ScottK: thank you, though. | 17:19 |
| ScottK | hanska: The clamtk upstream contacted me and wanted to know why it worked everywhere except on Ubuntu. | 17:20 |
| hanska | Ah. Yeah, we had some issues too on Debian, and hopefully we fixed those | 17:20 |
| hanska | (wrong perms on signatures database) | 17:21 |
| ScottK | I tested with your 4.07-1 package and it seemed fine. | 17:21 |
| hanska | ScottK: I'm preparing 4.08-1 now, I'll ping you when it's ready | 17:23 |
| ScottK | OK. | 17:23 |
| ScottK | I've put in to get 4.07-1 backported to Intrepid, so that should get some more real world use. | 17:23 |
| hanska | Thank you Scott. | 17:24 |
| hanska | ScottK: is it ok to you if I switch to dh7-debian/rules ? | 17:25 |
| soc | ScottK, hanska: i uploaded a new one | 17:25 |
| soc | should appear soon | 17:26 |
| hanska | soc: busy right now, will have a look later :) | 17:26 |
| ScottK | hanska: That would cause me some complications for backports, but I'll manage. | 17:26 |
| hanska | ScottK: I can just stay with dh6, it's not a problem. | 17:26 |
| ScottK | hanska: Actually 6/7 are equally problematic for me. | 17:27 |
| hanska | 5? :) | 17:27 |
| ScottK | I want to, eventually, get all the way back to Dapper. | 17:27 |
| ScottK | Yes. | 17:27 |
| ScottK | Don't worry about it though. | 17:27 |
| hanska | uhm, ok... also because in Debian I have dh6 since 3.03 | 17:27 |
| hanska | s/3.03/4.04/ | 17:27 |
| hanska | :) | 17:27 |
| hanska | ok, going dh7 then, sorry. | 17:28 |
| ScottK | Yes and you've got dh7 in b.p.o too. | 17:28 |
| maxb | but: debhelper | 7.0.13ubuntu1~hardy1 | hardy-backports | source, all <--- doesn't that make it ok? | 17:28 |
| maxb | oops | 17:28 |
| * ScottK looks at jdong to go ahead and backport dh7 to Gutsy and Dapper. | 17:28 | |
| maxb | evidently I can't tell the difference between hardy and dapper | 17:28 |
| ScottK | ;-) | 17:28 |
| soc | http://revu.ubuntuwire.com/revu1-incoming/ttf-droid-0901071830/lintian | 17:33 |
| soc | should i name my original package ttf-droid_1.00~b112+dfsg.orig.tar.gz now? | 17:34 |
| === ember_ is now known as ember | ||
| pmjdebruijn | lo | 17:54 |
| pmjdebruijn | in the past I requested a sync request for ufraw for jaunty, which was passed... | 17:55 |
| pmjdebruijn | however there a new version again, which I'd like to have synced again... should I file a new bug report? or just comment on the old one? | 17:55 |
| Laney | make a new one please | 17:55 |
| ScottK | pmjdebruijn: If the sync for the existing bug has already been done, you have to make a new one. If it were still pending, you could edit the existing bug. | 17:55 |
| pmjdebruijn | ok | 17:57 |
| soc | ok, new upload: http://revu.ubuntuwire.com/details.py?package=ttf-droid | 17:59 |
| pmjdebruijn | ScottK: are Please sync ... request periodically checked? | 18:01 |
| ScottK | pmjdebruijn: You need to subscribe ubuntu-universe-sponsors to get a MOTU to review. | 18:02 |
| ScottK | Yes. | 18:02 |
| pmjdebruijn | ScottK: I didn't previously do that? | 18:06 |
| sebner | !sponsorship | pmjdebruijn | 18:06 |
| ubottu | Sorry, I don't know anything about sponsorship | 18:06 |
| sebner | grrr | 18:06 |
| ScottK | pmjdebruijn: Dunno. You should have if you didn't | 18:06 |
| pmjdebruijn | ok, subscribing now | 18:06 |
| pmjdebruijn | thanks for your help | 18:07 |
| slytherin | what does it take to join u-u-s team if I am already a motu? | 18:07 |
| ScottK | slytherin: Asking. | 18:08 |
| slytherin | oh. I thought there was some procedure. | 18:08 |
| ScottK | There is. That's it. | 18:10 |
| persia | slytherin, You want to be UUS? I'll do it now if you do. | 18:15 |
| slytherin | persia: I have been thinking for some time. But it doesn't make sense to do it now as I have many things in TODO list. | 18:16 |
| persia | OK. Just let any of the admins know, and they'll add you when you want to join. | 18:16 |
| slytherin | persia: sure. | 18:16 |
| persia | Also, you might want to merge https://launchpad.net/~onkarshinde-ubuntu :) | 18:17 |
| slytherin | persia: Seeing that page first time. :-) | 18:17 |
| slytherin | calc: did you see my reply about jaxme build failure? | 18:26 |
| ScottK | slytherin: It doesn't hurt to go ahead and join. It doesn't get you any extra bugmail. | 18:27 |
| soc | pmjdebruijn, hanska, ScottK: i tried to fix all comments, is this ok now? http://revu.ubuntuwire.com/details.py?package=ttf-droid | 18:27 |
| slytherin | ScottK: Right. But then I may get distracted. :-D | 18:27 |
| oojah | Hi, I've got some queries on handling man pages when packaging. First off, I'm not really sure about how the make install rules of a package to install a man page and the dh_installman complement one another. If I've got a package that installs example.1 to /usr/share/man/man1/example.1 then how does dh_installman come into things? | 18:28 |
| broonie | oojah: dh_installman is a more specialised version for man pages - you should use it in preference to manual dh_install of man pages. | 18:31 |
| ScottK | oojah: Did you try "man dh_installman" - Somewhat ironically, that's where you should probably look. | 18:31 |
| oojah | Yeah, man dh_installman all makes sense, but what if the man page installation is already handled in the debian/rules install target like "$(MAKE) install DESTDIR=$(CURDIR)/debian/trafshow | 18:35 |
| oojah | " | 18:35 |
| calc | slytherin: here? | 18:36 |
| slytherin | calc: yes | 18:36 |
| calc | slytherin: you said something about finding out why jaxme ftbfs? | 18:36 |
| slytherin | calc: yes, I had added comment on the cat-all MIR bug. | 18:36 |
| slytherin | catch-all | 18:37 |
| calc | heh iirc rt.jar causes build failures on OOo as well unless you use a patch | 18:38 |
| calc | slytherin: did you see anything about why xom randomly ftbfs? | 18:38 |
| slytherin | calc: No. The error says stack overflow. And it is failing on i386 machine as well. So nothing arch specific. | 18:39 |
| slytherin | calc: jaxme and xom are the only packages remaining to be fixed. | 18:39 |
| calc | i managed to build xom most of the time on my machine, it occassionally ftbfs, but i have no idea why it only happens sometimes | 18:41 |
| calc | would that be a bug in it or the jdk? | 18:41 |
| slytherin | hmm | 18:41 |
| slytherin | can't really say | 18:42 |
| calc | but it seems to ftbfs every time on the buildd | 18:42 |
| calc | ok | 18:42 |
| calc | if i could manage to make it fail often i could test it on debian to see if it is something wrong with or jdk, but it works for me most of the time so it would be hard to verify | 18:43 |
| calc | s/or/our/ | 18:43 |
| calc | i'm preparing OOo 3.0.1-2ubuntu1 packaging atm, but will try to beat on those two after i am done | 18:46 |
| calc | the current debs are broken and users are filing lots of bugs about them so it would be helpful to get them at least in the ppa asap | 18:47 |
| slytherin | calc: Let me know which solution do you prefer for jaxme so that I can fix and upload it. | 18:47 |
| calc | slytherin: option 2 sounds like it might be easier for you to do? | 18:47 |
| slytherin | yes | 18:48 |
| calc | slytherin: option 2 won't actually break anything will it? | 18:48 |
| slytherin | calc: not really. | 18:48 |
| calc | ok | 18:48 |
| calc | yea that would probably be best then | 18:48 |
| slytherin | Ok. It will be done in an hour or so. | 18:49 |
| calc | thanks :) | 18:49 |
| calc | then i just need to determine whats up with xom, heh :) | 18:50 |
| calc | but its better if we don't fix them both before the new OOo is uploaded anyway | 18:51 |
| calc | that way i won't kill the buildds with two builds in a row | 18:51 |
| slytherin | but will OOo build without those two? As the build seem to have failed because of jaxme and xom. | 18:52 |
| slytherin | Oh. I understood. You mean if we fix the packages right now, OOo will get built and then it will be rebuilt after you upload new version. | 18:53 |
| calc | yea | 18:53 |
| calc | better to be stuck in depwait until i upload the new version | 18:53 |
| calc | the new one will be stuck at depwait but then i can determine what is wrong with xom | 18:54 |
| slytherin | fine. let me know when you upload new version. | 18:54 |
| calc | so it will only tie up the buildds for one day instead of two :) | 18:54 |
| slytherin | I will keep jaxme ready. | 18:54 |
| calc | you can go ahead and upload jaxme when you are done with it, xom is broken too so will keep it at depwait | 18:54 |
| slytherin | ok | 18:57 |
| slytherin | calc: there is no patch system. should I patch the sources inline? | 18:59 |
| calc | slytherin: is it cdbs? | 19:00 |
| slytherin | calc: no, debhelper | 19:00 |
| calc | slytherin: i guess patching inline is ok then, but make sure to document what you did in the changelog :) | 19:01 |
| slytherin | yup | 19:01 |
| khashayar | I'm still trying to get a hang of how to proceed when I create packages for new upstream releases. Is this good it: https://wiki.ubuntu.com/SponsorshipProcess? | 19:09 |
| khashayar | In this case, qtractor-0.3 was recently released, but only 0.2.1 is in jaunty (and debian, fwiw). | 19:10 |
| slytherin | khashayar: you need to file a bug, attach the .diff.gz to the bug and subscribe appropriate sponsors team. | 19:11 |
| calc | actually debdiff would probably be better | 19:11 |
| calc | but agreed for the rest of the process :) | 19:11 |
| khashayar | thanks! | 19:11 |
| calc | khashayar: debdiff is a program that takes two diff.gz and makes a diff of them | 19:12 |
| calc | that way the sponsor can more easily tell what you have changed in the packaging | 19:12 |
| khashayar | I thought debdiff was only used when one updated a package with the same orig.tar.gz. No? | 19:12 |
| james_w | DktrKranz: I filed a sync request for bash-completion, did you get to look at it yet? | 19:13 |
| calc | khashayar: i might be wrong but i think it works across orig.tar.gz as well, if the output looks wrong then just go with the diff.gz :) | 19:13 |
| calc | its been a while since i have used debdiff | 19:14 |
| DktrKranz | james_w, not yet. I was planning to dig through ubuntu bug reports to triage them a bit and try to reproduce them with current Debian version, but please go ahead :) | 19:14 |
| khashayar | Alright, thanks a lot. I'll see where it gets me. | 19:14 |
| james_w | DktrKranz: I was doing some of that now, but I'm about to break for today, so there's plenty more | 19:15 |
| james_w | there's also a bunch of fixes sat in bzr as well | 19:15 |
| calc | khashayar: the process is the same except if debdiff works (can't recall) then you just run that at the end after you get your new diff.gz | 19:15 |
| DktrKranz | james_w, cool. I'll do some in the next days (likely on weekend) | 19:15 |
| khashayar | calc: Alright, I'll try that. | 19:16 |
| slytherin | calc: khashayar: I think we stopped using debdiff for new upstream versions long time. | 19:18 |
| khashayar | slytherin: alright, so I'll attach the diff.gz. It looked much better anyway :-) | 19:19 |
| calc | slytherin: ah ok | 19:19 |
| calc | khashayar: its usually really obvious if debdiff blew up on a diff :) | 19:20 |
| calc | thinking back i probably tried to use debdiff in the manner i was stating above when it blew up ;-) | 19:20 |
| slytherin | khashayar: previously you also needed to install interdiff when you were submitting diff between two upstream versions. But as I said we do not use that process anymore. | 19:20 |
| calc | but its been a long time since i've updated a new upstream release of a package that way | 19:20 |
| calc | i mainly stick to beating on OOo | 19:20 |
| directhex | wheeee, openjdk for a mere 30 meg on disk | 19:22 |
| slytherin | directhex: what? | 19:24 |
| directhex | slytherin, IKVM.OpenJDK.dll! | 19:25 |
| slytherin | ah. :-) | 19:26 |
| slytherin | does it work well? | 19:26 |
| directhex | slytherin, i suspect this release (0.38) is a big step up from the release in the archive (0.34) which was based on classpath | 19:26 |
| slytherin | hmm | 19:27 |
| soc | i treid to fix all problems which were mentioned in the comments and reuploaded it. someone interested in reviewing it? http://revu.ubuntuwire.com/details.py?package=ttf-droid | 19:27 |
| directhex | slytherin, in real terms? no idea. ought to be reasonably functional for command-line apps. the AWT implementation is apparently only PoC | 19:27 |
| persia | directhex, You got it to work? Nice! | 19:28 |
| === bluesmoke is now known as Amaranth | ||
| directhex | persia, not only work......... lintian-clean! | 19:28 |
| slytherin | directhex: Is it getting included on CD? Or is that a jaunty +1 plan? | 19:28 |
| directhex | slytherin, nah, not my place to dictate what goes on the cd. i just thought it was an interesting project | 19:28 |
| persia | I doubt ikvm will end up as the default JDK | 19:28 |
| directhex | slytherin, it's certainly a bit slimmer than a regular openjdk install | 19:28 |
| persia | Supposedly, Java will get refactoring with Java 7, but that's not for a bit yet. | 19:29 |
| directhex | i'll have a little play in a sec, just gotta add README.source to the docdir | 19:29 |
| directhex | persia, what kind of refactoring possible whilst maintaining backward compatibility? java's much less segmented than CLI | 19:30 |
| directhex | stick an "is" in the middle of that somewhere if you like | 19:30 |
| persia | directhex, I'm fuzzy on the plan, but my loose understanding is that much of what is now the "JDK" will instead become "modules" that are essentially libraries, so you'd have a dependency map, and only pull the parts you need. | 19:31 |
| persia | I imagine one could define a "legacy" module that pulled all the old default APIs. | 19:31 |
| directhex | persia, so learning from mono, then? excellent. | 19:31 |
| directhex | persia, AFAIK IKVM 0.40 was doing something like that by itself - http://weblog.ikvm.net/CommentView.aspx?guid=f5cd40bc-d6ff-4fa1-8c0b-33a07f7ef967 | 19:33 |
| persia | directhex, ikvm is the forefront of experimentation :) | 19:33 |
| Amaranth | IKVM is our one hope for a single VM for all this stuff :P | 19:34 |
| directhex | Amaranth, i thought that was Parrot! | 19:35 |
| Amaranth | Everyone is targeting the CLR these days | 19:35 |
| directhex | Amaranth, i think CIL is better designed for multi-language use than java bytecode. it's easier to inject weird languages into it | 19:36 |
| * slytherin plans of creating a meta-package ubuntu-mono-desktop that pulls in as many mono apps as possible. :-D | 19:36 | |
| directhex | slytherin, wait a sec, are you trying to beat my score for attacks-on-boycottnovell? :o :( | 19:37 |
| Amaranth | We're soon going to have Javascript, Python, Mono, Java, and Ruby in our desktop | 19:37 |
| Amaranth | It's going to suck | 19:37 |
| directhex | Amaranth, i'll package ironruby once it's got a tarball release | 19:37 |
| Amaranth | directhex: Different API | 19:38 |
| slytherin | directhex: nope. that honour is yours. :-P | 19:38 |
| Amaranth | directhex: It's not a drop-in replacement for ruby, is it? | 19:38 |
| Amaranth | I know IronPython isn't a drop-in replacement for Python | 19:38 |
| directhex | Amaranth, i think it is. it's being used to run tests | 19:38 |
| directhex | ipy can drop-in for simple things, but nontrivial stuff you're right | 19:39 |
| Amaranth | That's because Python is "batteries included" | 19:39 |
| Amaranth | Even then, GTK# is not a compatible replacement for pygtk or the ruby binding | 19:39 |
| directhex | how about php-gtk2? :o | 19:40 |
| superm1 | jdong, ping. Any ideas on the VLC, patches for vdpau, how they're looking? | 19:42 |
| superm1 | jdong, nvm, i dont see it in normal git trees at all, so probably not ready yet | 19:45 |
| directhex | dpkg-source: info: building ikvm in ikvm_0.38.0.2+dfsg-1.diff.gz | 19:45 |
| directhex | i do wish this build didn't need >1 gig of ram | 19:47 |
| directhex | does openjdk do that? | 19:47 |
| slytherin | directhex: you mean build of openjdk? or builds using openjdk? | 19:53 |
| directhex | slytherin, building openjdk | 19:54 |
| slytherin | directhex: never tried. :-( | 19:54 |
| directhex | slytherin, ikvm calls javac, with a seemingly required 1.5 gig reserved, to build its openjdk dir | 19:54 |
| Amaranth | ooh zero punctuation got a new video player | 19:54 |
| Amaranth | it's widescreen, even though the video isn't | 19:54 |
| directhex | i.e. -J-Xmx1536M | 19:54 |
| directhex | Amaranth, probably escapist-wide | 19:55 |
| slytherin | directhex: is that much ram really needed? | 19:56 |
| directhex | slytherin, "free" says yes :( | 19:56 |
| directhex | slytherin, i'm 11% into swap, and i have 2 gig | 19:56 |
| directhex | slytherin, and i tried slashing the number, with no success | 19:57 |
| * directhex watches his gnome-system-monitor graph climb again | 19:57 | |
| directhex | slytherin, it peaks at 1020 meg used on my system, but better safe than sorry when settnig limits - just look at freecol | 19:59 |
| slytherin | how do I make uscan do the repacking of upstream source as well if I have get-orig-source target in debian/rules. What will be the option to be passed to uscan? | 20:01 |
| Amaranth | ooh i said that in the wrong channel | 20:01 |
| Amaranth | ooh i feel stupid now but it was funny and you should all watch it so... | 20:01 |
| directhex | slytherin, the trivial example: http://paste.debian.net/25480/ | 20:07 |
| directhex | slytherin, can you suggest a command-line java app in the archive to test? | 20:07 |
| slytherin | directhex: how about bsh? It is shell for java based scripts. | 20:08 |
| slytherin | persia: any help about that uscan problem? | 20:09 |
| directhex | slytherin, you've found a bug for me. how helpful! | 20:10 |
| slytherin | directhex: What bug? | 20:10 |
| directhex | slytherin, more problems with signed assemblies. not the first i've had with ikvm. | 20:11 |
| slytherin | :-) | 20:11 |
| directhex | ikvm-0.38.0.2+dfsg/ikvm-0.38.0.2/openjdk/Configuration.java: String default_awt_peer_toolkit = "ikvm.awt.NetToolkit, IKVM.AWT.WinForms, Version=0.38.0.2, Culture=neutral, PublicKeyToken=13235d27fcbfff58"; | 20:11 |
| directhex | GAH! | 20:11 |
| directhex | bloody jeroen | 20:12 |
| directhex | slytherin, sure bsh is X-less? the stack trace is full of java.awt | 20:14 |
| slytherin | directhex: must be some non-essential functionality. | 20:15 |
| slytherin | let me find some other application. | 20:15 |
| slytherin | directhex: how about ant. :-D | 20:17 |
| directhex | root@mortos:/usr/share/java# ikvm -jar ant-launcher.jar -version | 20:18 |
| directhex | Unable to locate tools.jar. Expected to find it in /.virtual-ikvm-home/lib/tools.jar | 20:18 |
| directhex | Apache Ant version 1.7.1 compiled on November 10 2008 | 20:18 |
| persia | slytherin, which problem again? | 20:19 |
| persia | Oh, I see. | 20:20 |
| persia | Just put uscan --repack in the get-orig-source rule. Works for .zip, .bzip, .tbz, .tbz2, .tar.bz2 | 20:20 |
| slytherin | persia: When I do uscan I want the upstream tarball to be modified and repacked. I have get-orig-source target in rules file but don't know how uscan will use it | 20:20 |
| persia | The problem with that it that it's not the same checksum that way: you probably want to do it manually with gzip -9nf | 20:21 |
| directhex | hm. who feels like filing a bug against quilt? i'm enormously busy | 20:21 |
| slytherin | persia: it is a different case here. upstream provides a .jar and I have to also remove some .class files while repacking. | 20:21 |
| persia | uscan doesn't use the get-orig-source target: it needs to be called by `debian/rules get-orig-source` | 20:21 |
| persia | Often the get-orig-source target includes a call to uscan. | 20:21 |
| directhex | Usage: quilt [--trace[=verbose]] [--quiltrc=XX] command [-h] ... | 20:22 |
| directhex | quilt --version | 20:22 |
| directhex | Commands are: | 20:22 |
| directhex | /usr/bin/quilt: line 42: column: command not found | 20:22 |
| soc | hi, i wouldn't be so annoying normally but my holidays are almost over and i want to get that package finally in, so that i can sleep well again ... http://revu.ubuntuwire.com/details.py?package=ttf-droid might be worth a look :-P | 20:22 |
| slytherin | persia: but even after that it will not retrieve new upstream version, will it? | 20:22 |
| persia | slytherin, You should construct the get-orig-source rule so that it does get the new upstream, edit as needed, and produce the orig.tar.gz. | 20:24 |
| directhex | persia, sounds like ikvm! | 20:24 |
| slytherin | persia: currently it extracts upstream version from latest changelog entry. How to I modify it to get new upstream version? | 20:24 |
| persia | slytherin, OK. Construct a watch file such that uscan --force-download grabs the latest .jar. | 20:26 |
| persia | Then call uscan in your get-orig-source rule, and use the downloaded .jar as the basis for your .orig.tar.gz creation | 20:26 |
| slytherin | hmm, will have to take a look. | 20:27 |
| slytherin | persia: looks like the solution is to move the repack code to orig-tar.sh which gets called when get-orig-source is called. | 20:31 |
| persia | I suppose. I'm not a big fan of having get-orig-source call shell scripts: I prefer to just do it in make, but that could work. | 20:31 |
| slytherin | anyway, I am too tired to try any of that. | 20:33 |
| persia | Understandably: it's rather late :) | 20:35 |
| slytherin | yes, I am I am trying to fix jaxme for last 1 hours. | 20:37 |
| Laney | siretart: Hey, have any insight on the transcode ftbfs? bug #311102 | 20:48 |
| ubottu | Bug 311102 on http://launchpad.net/bugs/311102 is private | 20:48 |
| Laney | bug #311202 sorry | 20:48 |
| ubottu | Launchpad bug 311202 in transcode "FTBFS with new ffmpeg in jaunty" [Medium,Confirmed] https://launchpad.net/bugs/311202 | 20:48 |
| * siretart looks | 20:49 | |
| siretart | Laney: looks like transcode needs to be updated for the new version ffmpeg. have you checked if there is a new upstream available? | 20:50 |
| Laney | there is | 20:51 |
| siretart | it seems the version of transcode we ship is pretty old. try updating it to 1.0.7 and see if that helps | 20:51 |
| hanska | ScottK: 21:36 <BTS> clamtk 4.08-1 uploaded by David Paleino <d.paleino@gmail.com> http://packages.qa.debian.org/clamtk | 20:54 |
| slytherin | calc: jaxme is taking too much time to fix. :-( I will look into it tomorrow. | 21:03 |
| calc | ok no problem :) | 21:03 |
| LaserJock | hi all | 21:29 |
| LaserJock | anybody feel like a little packaging fun? | 21:29 |
| quadrispro | anyone on bug #311023? | 21:42 |
| ubottu | Launchpad bug 311023 in idjc "FTBFS with new ffmpeg in jaunty" [Medium,Confirmed] https://launchpad.net/bugs/311023 | 21:42 |
| quadrispro1 | bobbo: are you around? | 21:45 |
| bobbo | quadrispro1: yep | 21:45 |
| quadrispro1 | bobbo: great! I have a bug for you :) | 21:45 |
| quadrispro1 | bobbo: bug #311023 (we have some issues with quadr-o-matic, it doesnt want build anything for jaunty...) | 21:46 |
| ubottu | Launchpad bug 311023 in idjc "FTBFS with new ffmpeg in jaunty" [Medium,Confirmed] https://launchpad.net/bugs/311023 | 21:46 |
| Laney | muhahaha ffmpeg | 21:47 |
| bobbo | quadrispro1: I'll have a look | 21:48 |
| quadrispro1 | thank you! | 21:49 |
| bobbo | quadrispro1: mind if I msg you? | 21:51 |
| quadrispro1 | bobbo: no problem :) | 21:52 |
| * persia likes to see discussions about packages in-channel, so others can learn or comment: of course, if it's not package-related, ignore this :) | 21:53 | |
| Laney | yay for transcode building | 21:58 |
| Laney | siretart: Would you mind reviewing/tweaking/uploading if I provide the .diff.gz on a bug? I'm not totally confident with this package... | 21:59 |
| bobbo | persia: hehe, not packaging related, don't worry | 21:59 |
| Laney | or anyone else? | 21:59 |
| Laney | oh, rats, it failed anyway | 21:59 |
| bobbo | If we rebuild a package with no Ubuntu changes (*-1build1) then want to make changes to it in Ubuntu, should the version number be *-1ubuntu1, or do we need to mention the old rebuild? | 22:00 |
| Laney | why can't you do both? | 22:01 |
| sebner | bobbo: -1ubuntu1 | 22:01 |
| bobbo | sebner: ok, thanks :) | 22:01 |
| Laney | I don't see why that version cannot contain the last changelog entry | 22:02 |
| * Laney suspects he misunderstands the question | 22:02 | |
| sebner | Laney: | 22:02 |
| sebner | 1) you have a debian package | 22:02 |
| maxb | -1ubuntu1 rather than -1build1ubuntu1, I expect | 22:02 |
| vorian | in your case, since the last version was debian 7.7-1, then yes, it should be 07.7-1ubuntu1 | 22:02 |
| sebner | well | 22:03 |
| sebner | first | 22:03 |
| sebner | 1) -1 | 22:03 |
| sebner | 2) -1build1 | 22:03 |
| sebner | 3) -1ubuntu1 | 22:03 |
| Laney | but 3) contains changelog entries from 2) and 1) | 22:03 |
| sebner | Laney: sure | 22:03 |
| quadrispro1 | bobbo: it's ready | 22:05 |
| quadrispro1 | hi sebner | 22:05 |
| maxb | Whilst we're on the topic of versions - the PPA guide says to increment the revision and append ~ppaN - but what does that mean for a synced debian package without ubuntu changes? Would 1.0-1 become 1.0-2~ppa1 is wrong if a -1ubuntu1 is made. So, would the hypothetical best ppa version be 1.0-1ubuntu0~ppa1 ? | 22:05 |
| * sebner winks quadrispro1 | 22:05 | |
| maxb | erm, sorry for the grammar failure above :-) | 22:06 |
| persia | maxb, Personally, I'd recommend using -0~ppaX where X increases for PPA versions of unpackaged code. | 22:07 |
| LaserJock | only if there isn't a -1 though, right? | 22:07 |
| persia | For PPA versions of packaged code, I'd think using ${existing-version}+ppaX would be safest. | 22:07 |
| persia | LaserJock, For unpackaged code. | 22:07 |
| LaserJock | if 1.0-1 already exists you'd want 1.0-1~ppaX I'd think | 22:07 |
| persia | No, I'd want 1.0-1+ppaX, to sort above 1.0-1 | 22:08 |
| maxb | But, you want the ppa version to be greater than the existing version but less than any future one | 22:08 |
| === quadrispro1 is now known as quadrispro | ||
| persia | maxb, Right. It's a gamble, but since + has a very low sort value, there's a good chance that you're safe using +ppaX to an existing package. | 22:08 |
| maxb | persia: interesting... and probably saner than what https://help.launchpad.net/Packaging/PPA#Versioning recommends | 22:09 |
| persia | maxb, Perhaps you'd like to update that page? It's just a wiki. | 22:09 |
| LaserJock | persia: your right about ~ vs +, my bad | 22:09 |
| LaserJock | *you're | 22:09 |
| Laney | deja vu? | 22:09 |
| Laney | I swear we had a similar conversation before (r.e. ppa versioning) | 22:10 |
| persia | Actually, I don't like + so much anymore. | 22:10 |
| persia | `dpkg --compare-versions 1.0-0ubuntu1 gt 1.0-0+ppa1 && echo true` doesn't give the result I want. | 22:10 |
| persia | I'm not sure why though. 'u' should be higher than '+'. | 22:11 |
| LaserJock | odd | 22:11 |
| maxb | argh, I was following the same misconception as you. But actually, the sort order is ~ digit alpha other | 22:12 |
| persia | Indeed. | 22:12 |
| persia | Oh, bother. | 22:12 |
| persia | In that case, I suppose -00ppaX might be safer. | 22:13 |
| persia | and dpkg --compare-versions agrees with that. | 22:13 |
| maxb | I'm fairly sure that 00 will behave identically to 0 | 22:13 |
| persia | Oh well. -0ppaX then. Still sorts lower than -0ubuntuX or -1, and I'm not interested in non-Ubuntu non-Debian upgrade path conflicts right now. | 22:14 |
| persia | (and yes, 0ppa1 and 00ppa1 are considered identical) | 22:15 |
| ScottK | hanska: Did you file a sync request? | 22:29 |
| directhex | persia, i got a swing hello world app running in ikvm, but i can see why they call the awt implementation proof-of-concept | 22:31 |
| directhex | persia, it's not particularly usable | 22:32 |
| persia | heh. | 22:32 |
| persia | ikvm is *all* proof-of-concept. | 22:32 |
| ScottK | hanska: If so, what's the bug number? | 22:34 |
| directhex | persia, how many of the 20k or so source packages in the archive aren't? | 22:46 |
| directhex | persia, isn't linux just a filler kernel until hurd is ready? ;p | 22:46 |
| sebner | hurd \o/ | 22:46 |
| LaserJock | directhex: I thought it was until the python kernel was ready? ;p | 22:47 |
| directhex | LaserJock, never used perl-linux? | 22:47 |
| persia | directhex, Umm... But ikvm is *even-more-so* | 22:49 |
| KIAaze | hi, I'm trying to package an application using an unpackaged library | 22:54 |
| KIAaze | to do this, I tried creating a local apt repo as indicated here: https://wiki.ubuntu.com/PbuilderHowto#Building%20With%20Local%20Packages | 22:55 |
| KIAaze | but I get this error when running dput: | 22:55 |
| KIAaze | Successfully uploaded packages. | 22:55 |
| KIAaze | Not running dinstall. | 22:55 |
| KIAaze | mini-dinstall [-1215132784] ERROR: Unable to install "/var/cache/archive/mini-dinstall/incoming/hello_1.0_source.changes"; adding to screwed list | 22:55 |
| directhex | persia, it's still worth having, IMHO. it's an interesting package | 23:00 |
| directhex | persia, and it enables you to use java libs (albeit with an unpleasantly large dep on IKVM.OpenJDK.dll) in CLI apps, which is neato | 23:01 |
| LaserJock | quick sanity check, are the nvidia drivers shipped on the CD? | 23:04 |
| oojah | I don't suppose anybody would consider reviewing the package I just uploaded, ralcalc? It's a quick to use command line calculator. I would leave it to get processed in due course, but I'm sure I've commited every packaging sin under the sun so thought I should give myself more time to fix it. http://revu.ubuntuwire.com/details.py?package=ralcalc | 23:05 |
| soc | someone interested in reviewing http://revu.ubuntuwire.com/details.py?package=ttf-droid ? it's a small package, with all fixes from the comments | 23:08 |
| superm1 | LaserJock, on the DVD | 23:09 |
| LaserJock | oojah: the packaging looks pretty good on quick inspection | 23:09 |
| superm1 | they're not installed, but the packages are there | 23:09 |
| LaserJock | superm1: but they aren't on the CD? | 23:09 |
| superm1 | LaserJock, no they're not | 23:09 |
| superm1 | you have to use jockey to turn them on | 23:10 |
| LaserJock | dang | 23:10 |
| superm1 | CD is quite filled | 23:10 |
| LaserJock | a friend of mine is trying out Ubuntu for the first time and I told him they were on the CD | 23:10 |
| LaserJock | he's got no internet | 23:10 |
| superm1 | well that makes it more difficult | 23:10 |
| LaserJock | he's also using gutsy | 23:11 |
| LaserJock | I think I'll tell him to maybe get the Intrepid DVD or something | 23:11 |
| superm1 | in gutsy the kernel module is on the CD, but the driver isn't | 23:11 |
| oojah | LaserJock: I guess that's a good start :) | 23:11 |
| Laney | oojah: Remove the boilerplate from rules | 23:11 |
| Laney | oojah: Do readme.txt and ChangeLog get installed in /usr/share/doc/ralcalc? | 23:12 |
| oojah | Laney: ChangeLog I remember for certain, readme.txt I can't remember. readme.txt is all covered in the man page though tbh. | 23:13 |
| Laney | It might be nice - I know I sometimes go to http://localhost/doc/<package> to see what's what | 23:13 |
| oojah | ok | 23:13 |
| Laney | you should just be able to put it in debian/docs | 23:15 |
| oojah | Do I need to worry about http://revu.ubuntuwire.com/report.py/legal?upid=4445 ? | 23:16 |
| Laney | not if that's listed in copyright | 23:17 |
| oojah | Right. | 23:18 |
| Laney | oojah: Run lintian over your binaries too and see if anything comes up | 23:20 |
| Laney | (I don't know if it will, it's just a good check to do) | 23:20 |
| oojah | Good point, I only ran it on the sources. | 23:21 |
| Laney | I always forget | 23:21 |
| pochu | pbuilder runs it for me | 23:22 |
| pochu | on every build | 23:22 |
| jmarsden|work | oojah: It's not a packaging issue, but... wouldn't something like function = () { echo "scale=8; $@" |bc -lq ; } # get you more power than ralcalc and the same "easy" UI, using bc underneath? What is the intended user base for ralcalc on Ubuntu? | 23:24 |
| oojah | jmarsden|work: A valid question :) | 23:26 |
| jmarsden|work | So... you're packaing it just to learn packaging, basically, not because ralcalc is actually useful? | 23:27 |
| oojah | I find it most useful because I always do calculations with a variety of SI prefixes. | 23:27 |
| oojah | I use it all the time and others have found it useful enough from my ppa to blog about it and do translations. | 23:28 |
| oojah | I doubt it'll ever have a huge user base, but there you go. | 23:28 |
| jmarsden|work | Fair enough; I think I'll stick to bc, and use units when I am dealing with stuff than needs units (so I can ask what 8 megafurlongs per fortnight is in meters/second ;) | 23:29 |
| * LaserJock <3 units | 23:30 | |
| oojah | It's a common conversion that one. | 23:31 |
| directhex | my car gets 80 rods to the hogshead, and that's the way i like it! | 23:38 |
| Laney | dpkg-deb: building package `transcode' in `../transcode_1.0.7-0ubuntu1_amd64.deb'. | 23:51 |
| Laney | \o/ | 23:51 |
| oojah | I've done a new upload to fix what you suggested (and the lintian run on the binary!) and am now off to bed. Thanks very much for your comments everyone. | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!