[00:31] 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:33] Are there any MOTU in the house? [00:39] Are there any MOTUs here? [00:41] Yes. Some might be a bit busy :) [00:41] Did any of them see my question, or is it fair to suppose I should ask in an hour's time? [00:42] 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] Not before precise's feature freeze closes [00:43] 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] i used @bar.com in debian/changelog [00:43] achiang: Then you're signing as @bar.com [00:43] Reason being that last patent it's subject to is a US patent that expires on 4/4/2012 [00:44] Hm. Debian's patent policy is roughly the same as Ubuntu's - has it been rejected from Debian before? [00:44] About 3 years ago [00:44] RAOF: hm, but... http://pastebin.ubuntu.com/809232/ [00:44] The final patent is rather dubious, but it's US only, anyway [00:44] mvdk: if it's still protected by a patent, that seems like it would be a problem for Ubuntu as well [00:45] So all the patents have expired in the UK, which is where Canonical is [00:45] achiang, debbuild signs with whatever key has the id listed in the changelog [00:46] 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] psusi: maybe i don't actually have a key for '@bar.com'... perhaps i only added @bar.com as a uid? [00:46] psusi: there's a pastebin above with my error [00:47] achiang, does gpg -K show that address? [00:48] psusi: ah, i figured out my issue... i used a debian/changelog line of: -- Alex Chiang Thu, 19 Jan 2012 00:33:45 +0000 [00:48] mvdk: Ubuntu is also distributed from US servers [00:48] psusi: but in reality, what is in my key is Alexander Chiang [00:48] psusi: i didn't realize it was going to match on the entire string, not just the actual email address [00:48] achiang, ahh, yea [00:48] It matches on full string *and* comment. [00:49] * psusi finally started using his @ubuntu.com email recently [00:49] So if you've got, for example, a comment of RAOF then you need to sign as Christopher James Halse Rogers (RAOF) . [00:49] RAOF: yep, got it now. [00:49] is that a gpg thing or a debuild thing (the matching) [00:49] Which is why my GPG keys no longer have a comment of RAOF :) [00:50] 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] 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:51] 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] mvdk: To what extent is this patent enforced? Have you read https://wiki.ubuntu.com/PatentPolicy ? [00:51] Yes, software patents generally suck. [00:52] Practically not enforced any more [00:52] Mitsubishi is the owner of the patent in question [00:53] And about to expire… [00:53] Yep [00:53] And it's the last one of about 25 [00:54] 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:55] See http://www.cl.cam.ac.uk/~mgk25/jbigkit/patents/ [00:55] OK, I'll google for REVU [00:55] Thanks [00:58] 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] 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:59] Ah, so I need to speak to "the" MOTU [00:59] I'm guessing there is in fact more than one... [01:01] broder: libtiff isn't universe, and I would submit a one-liner in the control for it [01:01] Add a depends for libjbig-dev [01:02] Build-depends, rather [01:02] OK, so I should attempt debian first, no probs [01:04] 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:07] RAOF: broder states that exceptions are sometimes given. Is it likely that an exception would be given for a Build-Depends on libtiff? [01:08] mvdk: are you saying that your thing needs to build-dep on libtiff? [01:08] 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] In order for libtiff to use libjbig, there needs to be a build-dep on libtiff, yes [01:09] 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] Ah [01:09] Ouch [01:10] 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] Sorry, is a provides for all the main package parts [01:11] That would potentially be one way to have jbig support in libtiff without getting jbig in main, yes. [01:11] 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:12] Yuck [01:12] RAOF, glib timeouts are called without gdk lock, so you need to call gdk_threads_enter() before doing any gtk stuff right? [01:12] So it's more like "Sit in the corner and cry" :( [01:13] psusi: That sounds right. [01:13] damn... [01:13] 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:14] Several printers are useless without it [01:14] In particular, a heap of Samsung & Lexmark printers are useless - all the ones with splix support [01:14] That sounds like something we want to have, then. [01:15] They don't depend on libtiff support, though [01:15] hylafax depends on libtiff support [01:15] 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:16] Is there a bug for the fact that we lack support for those printers? [01:16] 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] hehe... [01:16] Yeah, with wontfix, I think [01:17] Is it only the fax functionality that's broken? [01:17] you would think that gtk would have its own timeout wrapper that made sure to grab the lock [01:18] hylafax won't be able to use JBIG if libtiff doesn't get built without libjbig [01:18] splix (the printers) won't work if libjbig doesn't get built [01:18] splix is a universe package, though [01:19] splix is not a universe package, I didn't realise, sorry [01:20] 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] But the ubuntu maintainer has decided to add the libjbig as a statically linked bit of source in his own package :P [01:20] As of about 2 weeks ago [01:21] Urgh, really? [01:21] Yep, nasty hey? [01:21] Hm, so he has. [01:22] 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:23] 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] OK, no probs. Do you have the PPA I set up? [01:24] That's the package I actually intend to attempt to submit [01:24] I don't, no. Is the package lintian-clean? [01:25] 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:26] 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] Huh. [01:27] I think libjbig.so.0 ought to be a symlink to libjbig.so.0.0 [01:27] It doesn't actually cause it to fail, but it seems silly [01:28] That's the way it generally should be. [01:28] Does libjbig do ABI stability? An SONAME of .0 is sometimes suspicious. :) [01:29] libjbig has been stable for the last 4 years [01:29] 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:30] +3 headers [01:31] And the author has never released them as so's [01:31] His build script made .a's... [01:31] So the part about making it into a .so was my part [01:32] Ah. Joy! [01:33] Yeah, hence my looking into what I need to do to make libtool work... [01:34] I found http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id292165 an excellent reference for general library packaging things. [01:36] I think I found what my issue is [01:36] I said install -s -m ... [01:36] But I should only have said that for the main file [01:37] So I need install -s -m ... *.*.* but just install -m ... .so .so.[^.]* [01:40] I generally use the magic of autofoo, which tends to get it right. [02:17] 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] Hm. Why does the package have binaries at all? Are they demos or something? [02:19] 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] And vice-versa [02:20] That doesn't sound awesomely useful. Feel free to simply not ship those. [02:21] I put them in jbigkit-bin, which wouldn't need to be a main package [02:21] So I have 3 packages from the source at the moment: libjbig, libjbig-dev & jbigkit-bin [02:22] The libjbig & libjbig-dev would need to be in main [02:22] That sounds roughly right (I presume it's actually libjbig0) [02:22] Yes, it is, sorry [02:24] It wants me to fill in minimum versions for libc-dev & gcc. Is there a good minimum to use? [02:24] The build worked on lucid, I'm thinking I should use its version numbers [02:30] Any idea what a reasonable minimum for libc-dev is? I put >= 4.4 for gcc... [02:33] I think the actual problem is that you don't actually _need_ a Depends on libc-dev and gcc. [02:34] 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] Oh, very classy. I wonder why the new-package scripts gave me it for free? [02:35] Dunno. [02:46] RAOF: I just packaged a jbigkit-2.0-6 for precise that has everything but the manpages fixed [06:45] RAOF: Thanks for all your help. I've posted the package on mentors.debian.net. Hopefully I can find someone to sponsor it... [07:18] siretart, hello, could you get libaacs 0.3.0-3 synced? [07:50] good morning [07:58] hi dholbach, morning ricotz [07:58] ricotz: yes, let me testbuild it [07:59] siretart, hi, thanks [08:02] hey siretart [08:04] ricotz: that the first time I'm using this newfangled syncpackage script. let's see if the sync really gets attributed to you :-) [08:06] siretart, hoping the best ;P [08:14] Changed-By: Debian Multimedia Maintainers [08:14] doesn't look like it, but it got accepted :-) [08:23] siretart, i see, dont worry === Quintasan_ is now known as Quintasan === almaisan-away is now known as al-maisan === menesis1 is now known as menesis [09:17] sure it did https://launchpad.net/~ricotz/+synchronised-packages [09:25] Laney, oh nice, havent seen this new categories there yet [09:25] https://lists.ubuntu.com/archives/precise-changes/2012-January/007584.html even says your name :-) [09:27] i see :), formerly the name would have appeared here too https://launchpad.net/ubuntu/+source/libaacs/0.3.0-3 [09:27] ye that bit is missing [09:27] hopefully be back soon [09:27] ok, it isnt important === 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 [11:36] 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] 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:37] in a dog-walking break I came up with these ideas already http://paste.ubuntu.com/809547/ [11:38] 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:45] dholbach: a security session would be good Ithink [11:46] ah yes [11:46] I'll see if I can find someone to do it :) [11:46] * dholbach hugs micahg [11:47] Laney: looks like nobody has volunteered for the second debian slot yet [11:48] it's hard work getting the schedule filled this time [11:48] those slackers [11:48] 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:49] 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:50] sure - explaining where we list our task lists and what they all mean would be super helpful [11:53] or maybe a "here's how reviews are done, let's pick 5 items from the queue" session [11:53] would have the nice side-benefit of getting the queue shorter ;-) [11:58] not really the best time of day for me to help out with that [12:00] ajmitch, I know :-/ [12:00] * dholbach hugs ajmitch [13:33] maybe we can groups of 2 or more to copresent sessions, like Laney and tumbleweed do? [13:35] well actually we might split that up [13:35] give one half of the debian stuff each [13:36] ah, so that'd be "working with debian" and "working in debian" like you mentioned some days ago? [13:36] yeah [13:36] but I'll re-ping [13:36] sweet [13:36] great [13:36] * dholbach hugs Laney and tumbleweed [13:36] rock stars :) === udienz_ is now known as udienz [14:40] 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? [15:30] scott-work: revue is for brand new packages that want to get into universe, and is obsolete === al-maisan is now known as almaisan-away [15:43] scott-work: did you upload a _source.changes or a _i386.changes file? === JanC_ is now known as JanC [16:02] psusi: It's not obsolete. [16:03] Little used, I would agree with, but not obsolete. [16:05] psusi: the lowlatency kernel is a new package that needs to be into universe [16:05] siretart: i believe i uploaded a _source.changes, but i can check when i get home tonight [16:05] siretart: i used 'debuild -S -sa' to generate the .changes files if that helps any [16:06] 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:07] ScottK: there was some discussion yesterday about it and there was a new proceedure that didn't involve revu iirc [16:07] kernel-team removed it that is [16:07] iirc, because the generic one is pretty much just as good now [16:09] The kernel team is not everybody. [16:09] there is an intent to replace it with mentors.debian.net, but it's not there yet. [16:41] 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] psusi: the kernel team is very accepting of a community maintained kernel based on the ubuntu kernel [16:42] psusi: but it would need to be in universe therefore and a separate package [16:42] scott-work: you can't have a main source build a universe binary? [16:42] psusi: per a uds-p blueprint i we are to build, package the lowlatency kernel and then submit to REVU [16:43] 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] no disrepect to UKT intended as i completely understand and agree with their motivations and concerns [16:43] by low latency, do you just mean switching the config option from desktop to preempt? or are there actual source changes? [16:44] psusi: i am not a kernel expert, but my understanding is that the only changes are flags during build === arand_ is now known as arand [16:45] psusi: this is the blueprint if you are interested: https://blueprints.launchpad.net/ubuntu/+spec/other-p-lowlatency [16:46] seems silly to upload a near duplicate source package just for a config change... how much difference does it actually make anyhow? [16:48] 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] psusi: and it also practically eliminated _all_ xruns at most of those latencies [16:49] 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] how much latency are we talking about here? microseconds? [16:51] psusi: yes, microseconds === scott-work is now known as scott-work-afk [16:52] wow... so you want to work with only a few microseconds of audio buffer? damn... [17:04] Ehh... that can't be right. Gotta be milliseconds. === scott-work-afk is now known as scott-work [17:13] psusi: sorry, astraljava is correct, it's milliseconds....i mispoke preparing to go to a meeting [17:14] but the point is per an approved bluepring from uds-p i was to submit to the lowlatency kernel to REVU [17:14] 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:17] 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:22] scott-work: what's wrong with REVU now? [17:22] micahg: hi, it started like this.... [17:22] [08:40] 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:24] 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] scott-work: it should show up fairly quickly, I assume you did dput revu foo_source.changes? [17:24] 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:25] psusi: So even when we're only talking miniscule amounts of diffs codeline-wise, there are other differences. [17:25] micahg: aye [17:33] gcompris fails to build with the latest librsvg "error: 'RsvgSizeFunc' is deprecated [-Werror=deprecated-declarations]" [17:33] is there an easy fix for that? [17:34] why wasn't this caught before the upload? [17:34] * micahg would have assumed 2 devs test built this in this case [17:35] because new librsvg was just uploaded a few hours ago, it didn't fail earlier [17:35] ah, ok :() [17:35] :) [17:36] the big hammer would be to use the no-error equivalent when building, ideally, patch it to use whatever replaced it [17:39] interestingly nothing since 02 jan 2012 is showing up on the revu website :/ === yofel_ is now known as yofel [17:45] It was down for awhile before it got rebooted yesterday [18:37] do you think it normal that a package in universe depends on a non-free package ? [18:37] so why is using pkexec better than gksu? [18:38] l3on: No. It's a bug. What package? [18:38] boinc-amd-opencl [18:39] 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] in precise [18:39] l3on: It's in multiverse: boinc-amd-opencl | 7.0.7+dfsg-1 | precise/multiverse | amd64, i386 [18:39] right right... well, in this case ? [18:39] is still a bug ? [18:40] No, that's where non-free stuff goes. [18:40] ah ok, thanks :) [18:40] in anycase, it has a bronken dep on amd-libopencl1 [18:42] Different sort of bug. [18:42] It's not strictly required that multiverse packages be installable just from packages in the archive. [18:47] thanks for the info :) [18:59] scott-work: gpg: Can't check signature: public key not found [18:59] scott-work: seems you're not added to the keyring yet [19:00] hmmm, i did this for the zynjacku, strange [19:01] do you know where can I find information about what happened to package libcassad1 ? [19:01] maybe i'm using a different key than i did back then [19:01] but 9E2AC7F4 is your key, which is registered in launchpad, right? [19:01] siretart: i'm guessing then i need to verify my key is in the ubuntu keyring? [19:02] siretart: "9E2AC7F4", i'll check, but it shoudl be [19:02] you need to join the revu-uploaders team [19:02] revu has a cronjob that collects keys from launchpad [19:02] siretart: aye, that is my key [19:02] siretart: okay, i'll join now then [19:03] and then dput again? or will i need to dput -f this time? [19:04] scott-work: dputting again should work, or some revu admin can move back the .changes file [19:09] siretart: okay, maybe i'm flusttered, but i simply can't find 'revu-uploaders' in launchpad [19:09] oh [19:09] right, that was removed at some point.. [19:10] RainCT: around? see above [19:16] scott-work: sorry, I was wrong [19:16] scott-work: 2012-01-19 20:16:43 - linux-lowlatency_3.2.0-9.16_source.changes: Incorrect signature, moving to rejected. [19:17] or wait. no [19:19] Hey [19:19] siretart: i would like to point out that no matter the outcome, i really do appreciate your efforts to help me :) [19:19] siretart: the cronjob is long gone [19:20] keys are pulled individually from Launchpad every time you log in on the REVU website [19:20] scott-work: ^ [19:20] RainCT: i _think_ i might have dput'ed before logging in (at least in a year) [19:20] RainCT: aah, that explains [19:20] RainCT: now that i have logged into the website do you think dput will work [19:20] ? [19:20] scott-work: http://revu.ubuntuwire.com/p/linux-lowlatency [19:21] scott-work: I've reprocessed your upload manually. [19:21] 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] :-) [19:39] hi guys, how a package can be updated with bzr ? [19:39] I looking at "condor" [19:40] well, maybe it's too much complex for me :/ [19:44] 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:45] scott-work, well but I'm going to "upgrade" package, in meaning of new upstream release.. is there something like --pristine ? [19:45] there should be an merge-upstream command [19:46] found, thanks jtaylor [19:47] l3on: http://developer.ubuntu.com/packaging/html/udd-merging.html#merging-a-new-upstream-version [19:52] well, seems to not work... [19:52] bzr merge-upsream $HOME/condor-7.6.6.tar.gz [19:52] returns an exception... [20:17] l3on: you need to specify the version number as well. don't remember exactly how - might be --version or -v or something [20:54] slangasek: hi there === chrisccoulson_ is now known as chrisccoulson