[00:04] <jtaylor> zooko, davidsarah: pycryptopp upgrade bug 811721
[00:33] <stlsaint> is it safe to go ahead and set debian/compat level to 8 over 7? my package has no real depends on it but a build on launchpad just failed due to the debhelper on the virtual machine only supporting 7
[00:35] <Laney> sounds like you answered your own question - you won't be able to build the package if debhelper 8 isn't available
[00:37] <broder> debhelper(7) documents what changed between different debhelper compat levels
[00:37] <broder> but as i recall the differences are fairly minimal and specialized
[00:38] <Laney> shared libraries get symbols as well as shlibs
[00:38] <Laney> and some other stuff
[01:15] <philipballew> can someone help me with what file to download to build a deb from sorceforge?
[01:16] <philipballew> http://sourceforge.net/projects/carnival/files/carnival/carnival-1.03/
[01:16] <philipballew> ubuntu doesnt come have a gui for their festival text to speech program. so i figuired id build a deb for it
[01:17]  * philipballew is not in a make make install mood
[02:42] <zooko> jtaylor: thanks for pycryptopp upgrade bug 811721!
[04:40] <kaushal> Hi
[04:41] <kaushal> If JAVA6 U26 is not made available in hardy, does it mean because Ubuntu Desktop 8.04 has gone EOL,why is it not made available on Server edition since its supported till Apr 2013 can someone please explain
[04:41] <kaushal> as per https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/797718
[04:48] <micahg> kaushal: it's not a package with 5yr support
[04:48] <kaushal> ok
[04:48] <kaushal> micahg: still not covinced with the answer
[04:49] <kaushal> convinced*
[04:50] <micahg> kaushal: here was the list from dapper, the list should be similar for hardy, http://people.canonical.com/~ubuntu-security/dapper-lts-server-supported.txt
[04:51] <kaushal> micahg: i dont see hardy list
[04:51] <micahg> I don't know where it is ATM
[04:51] <kaushal> ok
[04:58] <dtchen> kaushal: note also that for hardy, it's in multiverse
[04:58] <dtchen> kaushal: thus, the onus is not necessarily on the Ubuntu Security Team to support it.
[10:47] <oier> question:  I get a lintian warning of "latest-debian-changelog-entry-without-new-version", this is because the package is built on a PPA and has the revno in it's name, so it's newer than the revision specified in the changelog
[10:48] <oier> do I have to sync the bzr commits with debian/changelog?
[10:49] <oier> for example now in the debian changelog read 0.1 version but the latest built package is 0.1-0~40~oneiric1
[10:50] <oier> or can I ignore the lintian warning?
[10:57] <Ampelbein> oier: can you paste the changelog on paste.ubuntu.com?
[10:58] <oier> http://paste.ubuntu.com/645784/
[10:59] <Ampelbein> oier: ok, and you used a override to change the version when building?
[11:00] <oier> I am using a daily PPA which attaches the revno in the name
[11:00] <oier> like 0.1-0~40~oneiric1
[11:01] <oier> I am trying to get the oackage in shape to upload it to universe
[11:02] <Ampelbein> ah, ok. you see: 0.1 is greater than 0.1-0~40~oneiric1.
[11:03] <oier> would I have to change the name of the package when uploading to revu to match 0.1~oneiric1?
[11:03] <Ampelbein> (dpkg --compare-versions 0.1 gt 0.1-0~40~oneiric1 && echo 0.1 is greater)
[11:03] <oier> or do I have to change the debian changelog for each commit to match the version number of the revno?
[11:04] <Ampelbein> no, you should use a non-native version for your debian package. (0.1-0ubuntu1 for example, <upstreamversion>-<debianrevision>ubuntu<ubunturevision>
[11:04] <oier> I mean how should I proceed to get rid of the warning?
[11:05] <Ampelbein> a version like 0.1 indicates a debian native package, meaning that there is no upstream.
[11:06] <oier> so, I don't have to change neither the ppa building recipe nor the changelog, just rename 0.1-0~40~oneiric1 to 0.1~oneiric1 when uploading to revu?
[11:06] <Ampelbein> no
[11:07] <Ampelbein> you have to change the changelog to the correct version
[11:07] <Ampelbein> so if you have upstream version 0.1 it would be 0.1-0ubuntu1
[11:07] <Ampelbein> (0=The package is not in debian, ubuntu1=This is the first ubuntu revision)
[11:08] <oier> and that would work for natty and oneiric versions?
[11:08] <Ampelbein> oier: new packages won't be accepted in natty anymore.
[11:08] <oier> ok
[11:09] <oier> ok I think I got it, http://paste.ubuntu.com/645788/
[11:10] <Ampelbein> the ~ should be a -
[11:10] <Ampelbein> ~ indicates a "less than" relation ship, so 0.1~1 is smaller than 0.1
[11:10] <oier> ok thanks a lot
[11:11] <oier> BTW the last lintian warning I get is binary-without-manpage usr/bin/indicator-bug
[11:12] <oier> does each application which installs a binary have to provide a manpage? I mean the app is a indicator
[11:20] <Ampelbein> usually yes
[11:21] <Ampelbein> Debian policy, chapter 12.1, http://www.debian.org/doc/debian-policy/ch-docs.html
[11:40] <jtaylor> what happens when a -proposed verificaton fails?
[11:42] <jtaylor> does it get removed from -proposed?
[11:53] <Ampelbein> jtaylor: From https://wiki.ubuntu.com/StableReleaseUpdates: "Removal will happen immediately if a package update in -proposed is found to introduce a nontrivial regression."
[11:53] <Ampelbein> so I guess that means yes
[11:54] <zooko> Good morning, folks! (UTC-6)
[12:54] <zooko> lifeless, jtaylor: I realized that there *is* a packaging issue in the upgrade of Tahoe-LAFS from 1.8.2 to 1.9.0: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1200
[12:54] <zooko> tahoe-lafs now comes with a bundled copy of protovis and jquery.
[12:55] <zooko> lifeless, jtaylor: would it be possible to get Tahoe-LAFS v1.9 into Oneiric, if it is in feature-freeze status, where we don't accept any non-bugfix patches, at Oneiric Feature Freeze, but it isn't in final released status until later?
[12:56] <zooko> We like to have a period of user testing after we've stopped making changes to the code base and before we call the thing a final release that people can entrust their data to.
[12:56] <zooko> But, it is likely that this period will overlap the Oneiric Feature Freeze date this time.
[12:57] <jtaylor> you can get feature freeze exceptions if the new functionality is worth it
[13:04] <zooko> Well, I think we won't worry too much about the Oneiric Feature Freeze deadline. We definitely want to finish integrating the new features that are already almost ready -- notably more scalable mutable files and directories -- and we definitely want to have a good thorough cycle of having our users test the resulting code before we bless it as v1.9.0.
[13:04] <zooko> Hopefully that blessing step -- the official Tahoe-LAFS v1.9.0 release -- will be either just before Oneiric Feature Freeze or soon after, and I'll do whatever I can to get Tahoe-LAFS v1.9 into Oneiric.
[13:05] <zooko> What do we need to do to package the new dependency on jquery and protovis in an Ubuntu-correct manner?
[13:05] <zooko> Also, jtaylor, would you be interested in packaging up Tahoe-LAFS trunk, perhaps as a PPA or something, before it is blessed as v1.9.0?
[13:07] <jtaylor> I don't use tahoe, so I can't support it, I can merely give packaging advice
[13:07] <zooko> Okay.
[13:07] <zooko> I'll ask rockstar if he'll do it.
[13:08] <zooko> So, give me some packaging advice. My Python project now depends on Javascript libraries.
[13:08] <zooko> After a long and agonizing design process, we concluded that there is no good way to do this, and so we're doing the same bad way that everyone else does: including a copy of the Javascript libraries in our app.
[13:10] <jtaylor> are you able to use the version packaged in ubuntu/debian/
[13:12] <zooko> I assume so.
[13:12]  * zooko checks version numbers
[13:14] <jtaylor> is the tahoe packaging in some Vcs?
[13:17] <jtaylor> found it
[13:18] <zooko> http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1200#comment:14
[13:25] <jtaylor> is protovis packaged?
[13:25] <jtaylor> can't find it
[13:26] <zooko> Darn.
[13:28] <zooko> Does that mean we need to get protovis packaged for Ubuntu before we can upgrade Tahoe-LAFS in Ubuntu to 1.9
[13:28] <zooko> I guess so.
[13:29] <jtaylor> that would be preferable, but not required
[13:56] <zooko> Should I open a request for packaging for protovis?
[14:00] <zooko> Well, I am off for an all-day car trip to my mom's farmhouse in New Mexico. :-)
[14:00] <zooko> Chat later!
[15:52] <bdrung> hi, someone here with a maverick i386 system who can testbuild a package?
[15:57] <jtaylor> won't a chroot do?
[15:59] <bdrung> a chroot would be sufficient. i failed to setup a i386 one
[16:00] <jtaylor> I have one, which package?
[16:00] <bdrung> jtaylor: lintian - git clone git://anonscm.debian.org/lintian/lintian.git
[16:02] <bdrung> jtaylor: running 'debian/rules runtests onlyrun=binaries-general' should be enough for testing - it fails on oneiric, but does it fail on maverick (it probably fails on natty too)
[16:05]  * jtaylor downloading
[16:06] <jtaylor> I really need faster internet :/ don't have all b-d cached
[16:06] <bdrung> jtaylor: mine is fast enough :)
[16:06] <bdrung> jtaylor: how fast is yours?
[16:07] <jtaylor> 1024k
[16:07] <bdrung> that was fast years ago ;)
[16:07] <jtaylor> why does lintian need java
[16:07] <bdrung> jtaylor: probably for some test cases
[16:20] <jtaylor> running
[16:20] <jtaylor> failed
[16:20] <jtaylor> http://paste.ubuntu.com/645914/
[16:21] <jtaylor> bdrung: ^
[16:31] <bdrung> jtaylor: that was on maverick? thanks.
[16:31] <jtaylor> yes i386
[16:32] <bdrung> thanks
[16:32] <bdrung> jtaylor: do you have a lucid i386 where you can retry this command?
[16:32] <jtaylor> but only a chroot on a amd6
[16:33] <bdrung> i have enough amd64 systems :)
[16:33] <jtaylor> I only have amd64 lucid cached
[16:33] <jtaylor> would have to download it all
[16:38] <oier> hi, I have uploaded a new package to REVU  called indicator-bug 3 hours ago but eventhough dput tells that everything went fine, I can't find the uploaded package on REVU
[16:39] <oier> it's my first time uploading to REVU so maybe I made some mistake
[16:40] <oier> if I try uploading again dput tells "Package has already been uploaded to revu on revu.ubuntuwire.com"
[16:40] <oier> does anybody know what's going on?
[16:41] <azeem> oier: that's from the .upload file I think
[16:41] <azeem> you need to remove it/move it away (or possibly use some dput --force option) to reupload
[16:42] <oier> but the first time I uploaded with dput it told me taht everything went fine, so I assume that it should be on revu
[16:43] <oier> the upload file says that it uploaded everything succesfully
[16:44] <azeem> oier: so why do you want to reupload?
[16:44] <oier> i don't find the package on the revu site
[16:45] <azeem> hrm, can't help you with that
[16:45] <azeem> but just reuploading will probably not help
[16:46] <oier> but is it normal that dput tells the upload was succesfull and then revu to not show the package?
[16:46] <oier> I've never used revu before so I am not familiar with it
[16:46] <azeem> well, dput uploads to somewhere on revu
[16:47] <azeem> I guess that upload has to be processed by revu somehow to make it appear on the webpage
[16:47] <azeem> possibly you have to get an account or something; I'm not using revu
[16:47] <geser> the upload is successful, but the part which processes the upload is probably not happy about something, contact an REVU admin who can check why
[16:47] <oier> I am logged in revu with my launchpad account
[16:48] <oier> who is an revu admin?
[16:50] <geser> oier: see https://wiki.ubuntu.com/MOTU/Packages/REVU, just above the "How to log in" section
[16:51] <oier> thanks
[17:02] <jtaylor> bdrung: lucid i386 chroot fails to
[17:19] <sladen> oier: dput --force
[17:20] <gilbert> hi, i would like  to suggest pulling in the latest xpdf package 3.02-17 from debian unstable.   this fixes a segfault issue lp:#788343, and may address the longstanding segfault lp:#669211.  anyway, the oneiric xpdf package is just in bad shape  right now...
[17:20] <micahg> gilbert: so, if Debian has all the changes of the ubuntu diff, you can request a sync with requestsync from ubuntu-dev-tools, otherwise, you can ask the last uploader if he's interested in doing the merge or if you could do it
[17:23] <gilbert> michag: i've applied all of the ubuntu changes to the debian package, so it can be used directly now
[17:24] <bdrung> jtaylor: thanks
[17:24] <micahg> gilbert: great!, so just request a sync with requestsync and it'll end up in the sponsorship queue, someone will look at it and ACK it
[17:26] <gilbert> micahg: ok, doing that now.  thanks for your help!
[17:27] <micahg> gilbert: you're welcome
[17:30] <gilbert> micahg: i keep getting timeouts to fiordland.ubuntu.com when running requestsync...
[17:30] <micahg> gilbert: if you have an lp account you can use --lp
[17:32] <micahg> I don't think anyone's around that can look at the timeout issue ATM
[17:33] <geser> gilbert: you might be using an out-dated version of ubuntu-dev-tools. fiordland.u.c was hardcoded in older versions but isn't a SMTP server anymore
[17:34] <gilbert> geser: yes, i'm using the version in debian squeeze
[17:34] <gilbert> i'll just move to my unstable box
[17:35] <jtaylor> you can also just copy paste the text into the web interface
[17:36] <micahg> jtaylor: yeah, but requestsync should do the subscribe as well for ubuntu-sponsors
[17:36] <jtaylor> well thats just a few more clicks
[17:36] <micahg> indeed
[17:38] <jtaylor> did that before I learned of the --lp flag as it did not support startls
[17:39] <geser> bdrung, tumbleweed: could something be done about the ubuntu-dev-tools package in Debian stable as requestsync from that version still has the old MX hardcoded? backport or would it warrant a SRU?
[17:41] <bdrung> geser: backporting is harder, because then you have to backport devscripts and distro-info too
[17:41] <bdrung> geser: i think SRU is the way to go asuming that the old MX does not work any more
[17:42] <geser> bdrung: it was bug 710925 (fixed in u-d-t 0.115)
[17:45] <geser> broder: http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/revision/996
[17:46] <geser> broder: sorry, that was meant for bdrung
[17:46] <bdrung> geser: yeah, that change is SRUable
[19:31] <micahg> gilbert: did that end up working for you?
[19:31] <micahg> gilbert: ah, nevermind, I see it in the queue
[19:46] <gilbert> micahg: yep, sent it in :)
[19:47] <micahg> gilbert: hi, do you have a minute for a PM about webkit?
[20:30] <gilbert> micahg: sure
[20:42] <micahg> gilir: you know that gecko-mediaplayer is available for adoption in Debian, right?
[20:48] <gilir> micahg, I didn't know it was officially orpĥaned, but I'll happy if someone else take it for now :)
[20:48] <micahg> gilir: yeah, officially orphaned
[22:13] <micahg> gilir: so, I'm looking at libdesktop-agnostic which you uploaded to Debian and the only diff we have is in the symbols file, Ubuntu has 0.3.91 for some symbols and Debian has 0.3.92, is this diff worth keeping?
[22:18] <RenatoSilva> Hi. Emerald 0.8.8 *must* get into natty, please
[22:18] <micahg> RenatoSilva: entering a channel and demanding things is not likely to be successful
[22:19] <micahg> RenatoSilva: you can request a backport to natty, instructions are here: https://help.ubuntu.com/community/UbuntuBackports
[22:21] <RenatoSilva> it's a new version maybe with new features (actually none I've noted) which could disturb users, ok somewhat a rule you guys follow. That is, it will be in Oneiric. BUT... the problem is that current emerald for natty DOESN'T WORK.
[22:21] <RenatoSilva> Hence a good reason to update to 0.8.8 or if you wish, find out what's wrong and patch it (which I find the hard way because I just can confirm 0.8.8 works in Natty, apparently "as is": https://launchpad.net/~malteworld/+archive/compiz)
[22:21] <micahg> RenatoSilva: there's an SRU in natty-proposed, have you tried it?
[22:23] <RenatoSilva> micahg: iirc I tried but can't recall if it even worked. Even so, the problem is that the system will keep pulling updates to ALL packages when I want updates from proposed only for that *specific* package. This is the main reason this approach doesn't work for me.
[22:24] <micahg> RenatoSilva: add something like http://paste.ubuntu.com/646075/ to /etc/apt/preferences.d/proposed
[22:25] <micahg> then you'll only pull in what you explicitly select from -proposed and any necessary dependencies
[22:28] <micahg> RenatoSilva: it'll go into -updates once it's been verified and has passed the 7 day waiting period
[22:30] <RenatoSilva> sorry micahg I don't get what that text lines mean and they'll be hard to manage (if later I want to change it, I'll have to remember file names and specific lines, which is more easy/intuitive with gui steps). So I'm afraid to blindly doing that...
[22:31] <micahg> RenatoSilva: the gui way would be enable, -proposed, update the one package you want to update, disable -proposed
[22:32] <RenatoSilva> it would help if update manager had nodes separating each section
[22:33] <RenatoSilva> sorry I don't recall if it has, iirc it's all mixed...
[22:33] <RenatoSilva> your suggestion seems ok, maybe I tried it but didn't work. Maybe I'll try again
[22:34] <micahg> RenatoSilva: when you enable proposed, you'll have to uncheck everything in update-manager you don't want I guess
[22:34] <RenatoSilva> micahg: yeah, possibly, I think I'll test right now...
[22:34] <RenatoSilva> anyway, the only way to know when it went to update is by regularly watching the versions with apt-cache policy emerald?
[22:35] <micahg> RenatoSilva: or subscribe to the bug
[22:35] <jtaylor> can this bug be nominated for natty? I'll preparing a branch
[22:35] <jtaylor> bug 779340
[22:36] <micahg> jtaylor: sure
[22:36] <micahg> jtaylor: done
[22:36] <RenatoSilva> micahg: yeah, already subscribed
[22:36] <pindonga> when is the deadline for package inclusion for oneiric? I'm planning to update some packages, so I want to know if I should push for it asap, or if I have time to do some more changes to them
[22:37] <micahg> pindonga: I think feature freeze is aug 11
[22:37] <pindonga> micahg, so any package updates should happen before then, right?
[22:37] <pindonga> thanks
[22:37] <pindonga> I think I'll be able to do so then
[22:38] <micahg> pindonga: non-bug fix updates after that need an FFe
[22:38]  * pindonga is pushing hard for a 1.0 release :)
[22:39] <micahg> pindonga: yeah, you want to shoot for 1.0 before that, you can do bug fix point releases after that though
[22:39] <pindonga> cool
[22:40] <micahg> RenatoSilva: the other option is to verify the SRU in a virtual environment like virtualbox
[22:47] <gilir> micahg, I'll do the sync myself, another package need to be update before
[22:48] <micahg> gilir: ok, thanks
[22:53] <jtaylor> bug 779340 merge proposal: https://code.launchpad.net/~jtaylor/ubuntu/natty/pyfltk/fix-779340/+merge/68194
[23:20] <jtaylor> another merge for to keep sponsors busy :) https://code.launchpad.net/~jtaylor/ubuntu/oneiric/soya/fix-780305/+merge/68196