mvdk | I have a packaging of JBIG-KIT on my PPA. I wish to submit it for inclusion, solving #594250. How do I do it? | 00:31 |
---|---|---|
mvdk | Are there any MOTU in the house? | 00:33 |
mvdk | Are there any MOTUs here? | 00:39 |
RAOF | Yes. Some might be a bit busy :) | 00:41 |
mvdk | Did any of them see my question, or is it fair to suppose I should ask in an hour's time? | 00:41 |
RAOF | The first question they'll likely ask is: can this be submitted to Debian? That'll get it into Ubuntu, and also be useful for a bunch of other people. | 00:42 |
mvdk | Not before precise's feature freeze closes | 00:42 |
achiang | can someone explain gpg keys to a dummy? i normally sign packages with @foo.com, but now, i want to make an upload with @bar.com. i have both @foo.com and @bar.com as uids on my private key but... not sure how to actually sign as @bar.com | 00:43 |
achiang | i used @bar.com in debian/changelog | 00:43 |
RAOF | achiang: Then you're signing as @bar.com | 00:43 |
mvdk | Reason being that last patent it's subject to is a US patent that expires on 4/4/2012 | 00:43 |
RAOF | Hm. Debian's patent policy is roughly the same as Ubuntu's - has it been rejected from Debian before? | 00:44 |
mvdk | About 3 years ago | 00:44 |
achiang | RAOF: hm, but... http://pastebin.ubuntu.com/809232/ | 00:44 |
mvdk | The final patent is rather dubious, but it's US only, anyway | 00:44 |
broder | mvdk: if it's still protected by a patent, that seems like it would be a problem for Ubuntu as well | 00:44 |
mvdk | So all the patents have expired in the UK, which is where Canonical is | 00:45 |
psusi | achiang, debbuild signs with whatever key has the id listed in the changelog | 00:45 |
psusi | achiang, so as long as the new address is listed on your key, using that address in the changelog should be all you need to do | 00:46 |
achiang | psusi: maybe i don't actually have a key for '@bar.com'... perhaps i only added @bar.com as a uid? | 00:46 |
achiang | psusi: there's a pastebin above with my error | 00:46 |
psusi | achiang, does gpg -K show that address? | 00:47 |
achiang | psusi: ah, i figured out my issue... i used a debian/changelog line of: -- Alex Chiang <alex@chizang.net> Thu, 19 Jan 2012 00:33:45 +0000 | 00:48 |
RAOF | mvdk: Ubuntu is also distributed from US servers | 00:48 |
achiang | psusi: but in reality, what is in my key is Alexander Chiang <alex@chizang.net> | 00:48 |
achiang | psusi: i didn't realize it was going to match on the entire string, not just the actual email address | 00:48 |
psusi | achiang, ahh, yea | 00:48 |
RAOF | It matches on full string *and* comment. | 00:48 |
* psusi finally started using his @ubuntu.com email recently | 00:49 | |
RAOF | So if you've got, for example, a comment of RAOF then you need to sign as Christopher James Halse Rogers (RAOF) <raof@ubuntu.com>. | 00:49 |
achiang | RAOF: yep, got it now. | 00:49 |
achiang | is that a gpg thing or a debuild thing (the matching) | 00:49 |
RAOF | Which is why my GPG keys no longer have a comment of RAOF :) | 00:49 |
mvdk | RAOF: So what I was hoping for was to include it in the pre-release so it could be included in Precise when it is released | 00:50 |
mvdk | RAOF: It's actually a pretty big thing for hylafax - yeah, including patents in things that are actually in common circulation is kind of nasty :( | 00:50 |
RAOF | mvdk: We need to care about it from the time it hits the archive - after all, we're distributing it as soon as it hits archive.ubuntu.com. | 00:51 |
RAOF | mvdk: To what extent is this patent enforced? Have you read https://wiki.ubuntu.com/PatentPolicy ? | 00:51 |
RAOF | Yes, software patents generally suck. | 00:51 |
mvdk | Practically not enforced any more | 00:52 |
mvdk | Mitsubishi is the owner of the patent in question | 00:52 |
RAOF | And about to expire… | 00:53 |
mvdk | Yep | 00:53 |
mvdk | And it's the last one of about 25 | 00:53 |
RAOF | So, I've not been following the recent discussions about new-package-uploads on the MOTU lists; I *think* the current correct procedure is still to upload to REVU. You might also want to attach your source package to the bug in question, and subscribe (not assign!) ubuntu-sponsors. That'll get it on the sponsorship queue. | 00:54 |
mvdk | See http://www.cl.cam.ac.uk/~mgk25/jbigkit/patents/ | 00:55 |
mvdk | OK, I'll google for REVU | 00:55 |
mvdk | Thanks | 00:55 |
broder | i still don't understand why uploading to debian isn't an option. it's possible to get exceptions to feature freeze, and for universe they tend to be handed out pretty liberally | 00:58 |
RAOF | Aha! http://revu.ubuntuwire.com/ says that it's deprecated, and contains a link to the current process https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages | 00:58 |
mvdk | Ah, so I need to speak to "the" MOTU | 00:59 |
mvdk | I'm guessing there is in fact more than one... | 00:59 |
mvdk | broder: libtiff isn't universe, and I would submit a one-liner in the control for it | 01:01 |
mvdk | Add a depends for libjbig-dev | 01:01 |
mvdk | Build-depends, rather | 01:02 |
mvdk | OK, so I should attempt debian first, no probs | 01:02 |
RAOF | Yeah. There are more people who can upload to Debian than who can upload to Ubuntu (as a goodly number of Ubuntu developers are also Debian developers, but not visa-versa). | 01:04 |
mvdk | RAOF: broder states that exceptions are sometimes given. Is it likely that an exception would be given for a Build-Depends on libtiff? | 01:07 |
broder | mvdk: are you saying that your thing needs to build-dep on libtiff? | 01:08 |
RAOF | broder was talking about feature-freeze exceptions; it's reasonably easy to get a new package into Universe after feature-freeze, because that's quite safe. | 01:08 |
mvdk | In order for libtiff to use libjbig, there needs to be a build-dep on libtiff, yes | 01:08 |
RAOF | But if you need to add a build-depends on this new package to libtiff, that's different. It needs libjbig to be in the archive and have a main-inclusion-report done for it (because libtiff is in main it can only build-depend on things in main). | 01:09 |
mvdk | Ah | 01:09 |
mvdk | Ouch | 01:09 |
mvdk | So I should make a tiff-jbig source package that has that one-liner, that is a virtual for all the main package parts? | 01:10 |
mvdk | Sorry, is a provides for all the main package parts | 01:10 |
RAOF | That would potentially be one way to have jbig support in libtiff without getting jbig in main, yes. | 01:11 |
RAOF | Unfortunately, due to limitations of dpkg, that'll only work if nothing has a versioned dependency relationship on libtiff. [Ie: declares Depends: libtiff (>= someversion)] | 01:11 |
mvdk | Yuck | 01:12 |
psusi | RAOF, glib timeouts are called without gdk lock, so you need to call gdk_threads_enter() before doing any gtk stuff right? | 01:12 |
mvdk | So it's more like "Sit in the corner and cry" :( | 01:12 |
RAOF | psusi: That sounds right. | 01:13 |
psusi | damn... | 01:13 |
RAOF | mvdk: It'd still be possible to get that happening, but it's tight. What is jbig support, and how much do we need it? | 01:13 |
mvdk | Several printers are useless without it | 01:14 |
mvdk | In particular, a heap of Samsung & Lexmark printers are useless - all the ones with splix support | 01:14 |
RAOF | That sounds like something we want to have, then. | 01:14 |
mvdk | They don't depend on libtiff support, though | 01:15 |
mvdk | hylafax depends on libtiff support | 01:15 |
psusi | RAOF, is there a sigc or gtkmm template somewhere you can use to wrap a sigc::mem_fun in a gdk_enter_threads so you can pass it to Glib::SignalTimeout::connect without writing your own function to do so? ;) | 01:15 |
RAOF | Is there a bug for the fact that we lack support for those printers? | 01:16 |
RAOF | psusi: Dunno; I'm not familiar with gtkmm. If I want to write something in a high-level language I'll use a high-level language :P | 01:16 |
psusi | hehe... | 01:16 |
mvdk | Yeah, with wontfix, I think | 01:16 |
RAOF | Is it only the fax functionality that's broken? | 01:17 |
psusi | you would think that gtk would have its own timeout wrapper that made sure to grab the lock | 01:17 |
mvdk | hylafax won't be able to use JBIG if libtiff doesn't get built without libjbig | 01:18 |
mvdk | splix (the printers) won't work if libjbig doesn't get built | 01:18 |
mvdk | splix is a universe package, though | 01:18 |
mvdk | splix is not a universe package, I didn't realise, sorry | 01:19 |
RAOF | mvdk: If you can hunt down that bug, this sounds like something that should be fixable now. Hardware support is generally a good reason for a MIR :) | 01:20 |
mvdk | But the ubuntu maintainer has decided to add the libjbig as a statically linked bit of source in his own package :P | 01:20 |
mvdk | As of about 2 weeks ago | 01:20 |
RAOF | Urgh, really? | 01:21 |
mvdk | Yep, nasty hey? | 01:21 |
RAOF | Hm, so he has. | 01:21 |
micahg | RAOF: mvdk: policy around REVU is if you have someone to REVU it and it's going straight into Ubuntu, that's the place, otherwise, try to get into Debian through debexpo | 01:22 |
RAOF | mvdk: So, I think that's actually a mistake on his part, and we should do the work to get your proper libjbig package into main. | 01:23 |
mvdk | OK, no probs. Do you have the PPA I set up? | 01:23 |
mvdk | That's the package I actually intend to attempt to submit | 01:24 |
RAOF | I don't, no. Is the package lintian-clean? | 01:24 |
mvdk | Yes, but the symlinks aren't properly set up. I haven't quite figured out libtool. (That is, lintian doesn't actually check that the build scripts do sensible things) | 01:25 |
mvdk | Only the libjbig-dev does symlinks (That is, libjbig-dev has libjbig.so -> libjbig.so.0, but both libjbig.so.0 and libjbig.so.0.0 are real files) | 01:26 |
RAOF | Huh. | 01:26 |
mvdk | I think libjbig.so.0 ought to be a symlink to libjbig.so.0.0 | 01:27 |
mvdk | It doesn't actually cause it to fail, but it seems silly | 01:27 |
RAOF | That's the way it generally should be. | 01:28 |
RAOF | Does libjbig do ABI stability? An SONAME of .0 is sometimes suspicious. :) | 01:28 |
mvdk | libjbig has been stable for the last 4 years | 01:29 |
mvdk | That is to say, the author hasn't made any releases - and why would he, the library is only 3 files containing about 2K lines... | 01:29 |
mvdk | +3 headers | 01:30 |
mvdk | And the author has never released them as so's | 01:31 |
mvdk | His build script made .a's... | 01:31 |
mvdk | So the part about making it into a .so was my part | 01:31 |
RAOF | Ah. Joy! | 01:32 |
mvdk | Yeah, hence my looking into what I need to do to make libtool work... | 01:33 |
RAOF | I found http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id292165 an excellent reference for general library packaging things. | 01:34 |
mvdk | I think I found what my issue is | 01:36 |
mvdk | I said install -s -m ... | 01:36 |
mvdk | But I should only have said that for the main file | 01:36 |
mvdk | So I need install -s -m ... *.*.* but just install -m ... .so .so.[^.]* | 01:37 |
RAOF | I generally use the magic of autofoo, which tends to get it right. | 01:40 |
mvdk | RAOF: I got that working. Lintian has some more output: It doesn't like some binaries not having man pages. I guess I ought to write them, right? | 02:17 |
RAOF | Hm. Why does the package have binaries at all? Are they demos or something? | 02:17 |
mvdk | It seems the author had some other file formats that were supported. The demo directories seem to have some weird stuff. In any case, they allow conversion from pbm to a raw jbig stream (if you can think of a reason to want to do that) | 02:19 |
mvdk | And vice-versa | 02:19 |
RAOF | That doesn't sound awesomely useful. Feel free to simply not ship those. | 02:20 |
mvdk | I put them in jbigkit-bin, which wouldn't need to be a main package | 02:21 |
mvdk | So I have 3 packages from the source at the moment: libjbig, libjbig-dev & jbigkit-bin | 02:21 |
mvdk | The libjbig & libjbig-dev would need to be in main | 02:22 |
RAOF | That sounds roughly right (I presume it's actually libjbig0) | 02:22 |
mvdk | Yes, it is, sorry | 02:22 |
mvdk | It wants me to fill in minimum versions for libc-dev & gcc. Is there a good minimum to use? | 02:24 |
mvdk | The build worked on lucid, I'm thinking I should use its version numbers | 02:24 |
mvdk | Any idea what a reasonable minimum for libc-dev is? I put >= 4.4 for gcc... | 02:30 |
RAOF | I think the actual problem is that you don't actually _need_ a Depends on libc-dev and gcc. | 02:33 |
RAOF | They're assumed to be provided by the build environment, so you only need to specify an explicit dependency if you need a specific version - hence the warning. | 02:34 |
mvdk | Oh, very classy. I wonder why the new-package scripts gave me it for free? | 02:34 |
RAOF | Dunno. | 02:35 |
mvdk | RAOF: I just packaged a jbigkit-2.0-6 for precise that has everything but the manpages fixed | 02:46 |
mvdk | RAOF: Thanks for all your help. I've posted the package on mentors.debian.net. Hopefully I can find someone to sponsor it... | 06:45 |
ricotz | siretart, hello, could you get libaacs 0.3.0-3 synced? | 07:18 |
dholbach | good morning | 07:50 |
siretart | hi dholbach, morning ricotz | 07:58 |
siretart | ricotz: yes, let me testbuild it | 07:58 |
ricotz | siretart, hi, thanks | 07:59 |
dholbach | hey siretart | 08:02 |
siretart | ricotz: that the first time I'm using this newfangled syncpackage script. let's see if the sync really gets attributed to you :-) | 08:04 |
ricotz | siretart, hoping the best ;P | 08:06 |
siretart | Changed-By: Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> | 08:14 |
siretart | doesn't look like it, but it got accepted :-) | 08:14 |
ricotz | siretart, i see, dont worry | 08:23 |
=== Quintasan_ is now known as Quintasan | ||
=== almaisan-away is now known as al-maisan | ||
=== menesis1 is now known as menesis | ||
Laney | sure it did https://launchpad.net/~ricotz/+synchronised-packages | 09:17 |
ricotz | Laney, oh nice, havent seen this new categories there yet | 09:25 |
Laney | https://lists.ubuntu.com/archives/precise-changes/2012-January/007584.html even says your name :-) | 09:25 |
ricotz | i see :), formerly the name would have appeared here too https://launchpad.net/ubuntu/+source/libaacs/0.3.0-3 | 09:27 |
Laney | ye that bit is missing | 09:27 |
Laney | hopefully be back soon | 09:27 |
ricotz | ok, it isnt important | 09:27 |
=== al-maisan is now known as almaisan-away | ||
=== almaisan-away is now known as al-maisan | ||
=== al-maisan is now known as almaisan-away | ||
=== almaisan-away is now known as al-maisan | ||
dholbach | hey, so I mailed a few folks about this already, but it might be worth bringing it up here as well - I need some help filling the schedule for Ubuntu Developer Week, so I can go and announce it and try to get some press attention, so we can get many new contributors :) | 11:36 |
dholbach | looking at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable what I feel we still need is a few hands-on sessions, maybe even just 30 minute ones which most of you could probably just off-the-cuff :) | 11:36 |
dholbach | in a dog-walking break I came up with these ideas already http://paste.ubuntu.com/809547/ | 11:37 |
dholbach | having reached out to new contributors in the last months, I found that demo'ing how things are done with an example generally had a huge impact on their views of how easy it is to get involved | 11:38 |
micahg | dholbach: a security session would be good Ithink | 11:45 |
dholbach | ah yes | 11:46 |
micahg | I'll see if I can find someone to do it :) | 11:46 |
* dholbach hugs micahg | 11:46 | |
tumbleweed | Laney: looks like nobody has volunteered for the second debian slot yet | 11:47 |
dholbach | it's hard work getting the schedule filled this time | 11:48 |
Laney | those slackers | 11:48 |
dholbach | which is why I suggested more hands-on sessions, where you just talk about a few examples you picked earlier - which I I supposed would come naturally to most of the ubuntu developers and contributors :) | 11:48 |
tumbleweed | people often come aind and ask what they can do to help, does a short slot on the kind of things MOTU does sound interesting? It wouldn't be particularly hands-on | 11:49 |
dholbach | sure - explaining where we list our task lists and what they all mean would be super helpful | 11:50 |
dholbach | or maybe a "here's how reviews are done, let's pick 5 items from the queue" session | 11:53 |
dholbach | would have the nice side-benefit of getting the queue shorter ;-) | 11:53 |
ajmitch | not really the best time of day for me to help out with that | 11:58 |
dholbach | ajmitch, I know :-/ | 12:00 |
* dholbach hugs ajmitch | 12:00 | |
dholbach | maybe we can groups of 2 or more to copresent sessions, like Laney and tumbleweed do? | 13:33 |
Laney | well actually we might split that up | 13:35 |
Laney | give one half of the debian stuff each | 13:35 |
dholbach | ah, so that'd be "working with debian" and "working in debian" like you mentioned some days ago? | 13:36 |
Laney | yeah | 13:36 |
Laney | but I'll re-ping | 13:36 |
dholbach | sweet | 13:36 |
dholbach | great | 13:36 |
* dholbach hugs Laney and tumbleweed | 13:36 | |
dholbach | rock stars :) | 13:36 |
=== udienz_ is now known as udienz | ||
scott-work | i uploaded a lowlatency kernel package to REVU last night i have yet to get a confirmation email or see it on the website, is this unusal and do i need to worry about it yet? | 14:40 |
psusi | scott-work: revue is for brand new packages that want to get into universe, and is obsolete | 15:30 |
=== al-maisan is now known as almaisan-away | ||
siretart | scott-work: did you upload a _source.changes or a _i386.changes file? | 15:43 |
=== JanC_ is now known as JanC | ||
ScottK | psusi: It's not obsolete. | 16:02 |
ScottK | Little used, I would agree with, but not obsolete. | 16:03 |
scott-work | psusi: the lowlatency kernel is a new package that needs to be into universe | 16:05 |
scott-work | siretart: i believe i uploaded a _source.changes, but i can check when i get home tonight | 16:05 |
scott-work | siretart: i used 'debuild -S -sa' to generate the .changes files if that helps any | 16:05 |
psusi | scott-work: linux is already packaged... if you want to add a low latency flavor, it is just another binary package that should be added to the existing suorce package.. but there used to be one and the kernel removed it a few releases ago | 16:06 |
psusi | ScottK: there was some discussion yesterday about it and there was a new proceedure that didn't involve revu iirc | 16:07 |
psusi | kernel-team removed it that is | 16:07 |
psusi | iirc, because the generic one is pretty much just as good now | 16:07 |
ScottK | The kernel team is not everybody. | 16:09 |
ScottK | there is an intent to replace it with mentors.debian.net, but it's not there yet. | 16:09 |
scott-work | psusi: there has been discussion with the kernel team and they do not want to maintain this kernel and therefore will need to be community maintained kernel | 16:41 |
scott-work | psusi: the kernel team is very accepting of a community maintained kernel based on the ubuntu kernel | 16:41 |
scott-work | psusi: but it would need to be in universe therefore and a separate package | 16:42 |
psusi | scott-work: you can't have a main source build a universe binary? | 16:42 |
scott-work | psusi: per a uds-p blueprint i we are to build, package the lowlatency kernel and then submit to REVU | 16:42 |
scott-work | psusi: it would suggest it's not a matter of ability but that the kernel team does not want to be directly involved with this kernel, including having it in their code | 16:43 |
scott-work | no disrepect to UKT intended as i completely understand and agree with their motivations and concerns | 16:43 |
psusi | by low latency, do you just mean switching the config option from desktop to preempt? or are there actual source changes? | 16:43 |
scott-work | psusi: i am not a kernel expert, but my understanding is that the only changes are flags during build | 16:44 |
=== arand_ is now known as arand | ||
scott-work | psusi: this is the blueprint if you are interested: https://blueprints.launchpad.net/ubuntu/+spec/other-p-lowlatency | 16:45 |
psusi | seems silly to upload a near duplicate source package just for a config change... how much difference does it actually make anyhow? | 16:46 |
scott-work | psusi: performance wise for recording audio it can lower the latency by at least a factor of 2, in some cases it has lowered performance by a factor of almost 8 | 16:48 |
scott-work | psusi: and it also practically eliminated _all_ xruns at most of those latencies | 16:48 |
psusi | I found the other day that glib's timer implementation is horribly incaccurate and submitted a patch for it... in my testing it got 20% off when run niced with stress -c in the background running a 50 Hz timer... simple patch to glib and that went down to like 0.0001% error | 16:49 |
psusi | how much latency are we talking about here? microseconds? | 16:49 |
scott-work | psusi: yes, microseconds | 16:51 |
=== scott-work is now known as scott-work-afk | ||
psusi | wow... so you want to work with only a few microseconds of audio buffer? damn... | 16:52 |
astraljava | Ehh... that can't be right. Gotta be milliseconds. | 17:04 |
=== scott-work-afk is now known as scott-work | ||
scott-work | psusi: sorry, astraljava is correct, it's milliseconds....i mispoke preparing to go to a meeting | 17:13 |
scott-work | but the point is per an approved bluepring from uds-p i was to submit to the lowlatency kernel to REVU | 17:14 |
scott-work | if i can being told that i cannot use REVU in this capacity i need to find another vector to get this package into the universe archive | 17:14 |
scott-work | also, i uploaded last night (approximately 16 hours) but have not yet received an email or can see it on the website, is there perhaps a problem with the dput although it said it uploaded properly? | 17:17 |
micahg | scott-work: what's wrong with REVU now? | 17:22 |
scott-work | micahg: hi, it started like this.... | 17:22 |
scott-work | [08:40] <scott-work> i uploaded a lowlatency kernel package to REVU last night i have yet to get a confirmation email or see it on the website, is this unusal and do i need to worry about it yet? | 17:22 |
astraljava | psusi: Even though we're not actually talking microseconds, the difference is drastic on some heavy audio-related tasks. People interested in such have provided test results regarding such sessions, and in several cases the latency was dropped to even smaller than one third. | 17:24 |
micahg | scott-work: it should show up fairly quickly, I assume you did dput revu foo_source.changes? | 17:24 |
scott-work | micahg: i think siretart had a good suggestion on checking which *.changes file was uploaded, which i will check in approximately 6 hours hence, but generally i was just trying to get a feel for if this is normal and i dont' need to worry | 17:24 |
astraljava | psusi: So even when we're only talking miniscule amounts of diffs codeline-wise, there are other differences. | 17:25 |
scott-work | micahg: aye | 17:25 |
jbicha | gcompris fails to build with the latest librsvg "error: 'RsvgSizeFunc' is deprecated [-Werror=deprecated-declarations]" | 17:33 |
jbicha | is there an easy fix for that? | 17:33 |
micahg | why wasn't this caught before the upload? | 17:34 |
* micahg would have assumed 2 devs test built this in this case | 17:34 | |
jbicha | because new librsvg was just uploaded a few hours ago, it didn't fail earlier | 17:35 |
micahg | ah, ok :() | 17:35 |
micahg | :) | 17:35 |
micahg | the big hammer would be to use the no-error equivalent when building, ideally, patch it to use whatever replaced it | 17:36 |
scott-work | interestingly nothing since 02 jan 2012 is showing up on the revu website :/ | 17:39 |
=== yofel_ is now known as yofel | ||
ScottK | It was down for awhile before it got rebooted yesterday | 17:45 |
l3on | do you think it normal that a package in universe depends on a non-free package ? | 18:37 |
psusi | so why is using pkexec better than gksu? | 18:37 |
ScottK | l3on: No. It's a bug. What package? | 18:38 |
l3on | boinc-amd-opencl | 18:38 |
scott-work | siretart: i called my wife and asked her to read me the filename for the .changes file, it was a _source.changes file | 18:39 |
l3on | in precise | 18:39 |
ScottK | l3on: It's in multiverse: boinc-amd-opencl | 7.0.7+dfsg-1 | precise/multiverse | amd64, i386 | 18:39 |
l3on | right right... well, in this case ? | 18:39 |
l3on | is still a bug ? | 18:39 |
ScottK | No, that's where non-free stuff goes. | 18:40 |
l3on | ah ok, thanks :) | 18:40 |
l3on | in anycase, it has a bronken dep on amd-libopencl1 | 18:40 |
ScottK | Different sort of bug. | 18:42 |
ScottK | It's not strictly required that multiverse packages be installable just from packages in the archive. | 18:42 |
l3on | thanks for the info :) | 18:47 |
siretart | scott-work: gpg: Can't check signature: public key not found | 18:59 |
siretart | scott-work: seems you're not added to the keyring yet | 18:59 |
scott-work | hmmm, i did this for the zynjacku, strange | 19:00 |
l3on | do you know where can I find information about what happened to package libcassad1 ? | 19:01 |
scott-work | maybe i'm using a different key than i did back then | 19:01 |
siretart | but 9E2AC7F4 is your key, which is registered in launchpad, right? | 19:01 |
scott-work | siretart: i'm guessing then i need to verify my key is in the ubuntu keyring? | 19:01 |
scott-work | siretart: "9E2AC7F4", i'll check, but it shoudl be | 19:02 |
siretart | you need to join the revu-uploaders team | 19:02 |
siretart | revu has a cronjob that collects keys from launchpad | 19:02 |
scott-work | siretart: aye, that is my key | 19:02 |
scott-work | siretart: okay, i'll join now then | 19:02 |
scott-work | and then dput again? or will i need to dput -f this time? | 19:03 |
siretart | scott-work: dputting again should work, or some revu admin can move back the .changes file | 19:04 |
scott-work | siretart: okay, maybe i'm flusttered, but i simply can't find 'revu-uploaders' in launchpad | 19:09 |
siretart | oh | 19:09 |
siretart | right, that was removed at some point.. | 19:09 |
siretart | RainCT: around? see above | 19:10 |
siretart | scott-work: sorry, I was wrong | 19:16 |
siretart | scott-work: 2012-01-19 20:16:43 - linux-lowlatency_3.2.0-9.16_source.changes: Incorrect signature, moving to rejected. | 19:16 |
siretart | or wait. no | 19:17 |
RainCT | Hey | 19:19 |
scott-work | siretart: i would like to point out that no matter the outcome, i really do appreciate your efforts to help me :) | 19:19 |
RainCT | siretart: the cronjob is long gone | 19:19 |
RainCT | keys are pulled individually from Launchpad every time you log in on the REVU website | 19:20 |
RainCT | scott-work: ^ | 19:20 |
scott-work | RainCT: i _think_ i might have dput'ed before logging in (at least in a year) | 19:20 |
siretart | RainCT: aah, that explains | 19:20 |
scott-work | RainCT: now that i have logged into the website do you think dput will work | 19:20 |
scott-work | ? | 19:20 |
siretart | scott-work: http://revu.ubuntuwire.com/p/linux-lowlatency | 19:20 |
siretart | scott-work: I've reprocessed your upload manually. | 19:21 |
scott-work | siretart: i simply cannot thank you enough! if i see you at a uds i will buy you several of your favourite beverages :) | 19:21 |
siretart | :-) | 19:21 |
l3on | hi guys, how a package can be updated with bzr ? | 19:39 |
l3on | I looking at "condor" | 19:39 |
l3on | well, maybe it's too much complex for me :/ | 19:40 |
scott-work | l3on: my experience is to download the bzr branch, make the changes, upload back to the branch, and then ask for a sponsor to upload the changes to the archives | 19:44 |
l3on | scott-work, well but I'm going to "upgrade" package, in meaning of new upstream release.. is there something like --pristine ? | 19:45 |
jtaylor | there should be an merge-upstream command | 19:45 |
l3on | found, thanks jtaylor | 19:46 |
micahg | l3on: http://developer.ubuntu.com/packaging/html/udd-merging.html#merging-a-new-upstream-version | 19:47 |
l3on | well, seems to not work... | 19:52 |
l3on | bzr merge-upsream $HOME/condor-7.6.6.tar.gz | 19:52 |
l3on | returns an exception... | 19:52 |
broder | l3on: you need to specify the version number as well. don't remember exactly how - might be --version or -v or something | 20:17 |
koolhead17 | slangasek: hi there | 20:54 |
=== chrisccoulson_ is now known as chrisccoulson |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!