[00:00] <Laney> (once I started a whole Haskell transition by uploading to the archive instead of my PPA)
[00:00] <sistpoty> heh
[04:16] <GhostOnline> Anyone here familiar with the upload process for new packages?
[04:17] <ScottK> GhostOnline: Yes.
[04:18] <GhostOnline> SkottK: Cool, I was wondering what I have to do now. I have uploaded a package for review to REVU
[04:18] <GhostOnline> SkottK: Do I have to link this back to the original bug report?
[04:19] <ScottK> GhostOnline: Once it's on REVU, if there is someone available, they will look it over, make suggestions, and then once you've resolved the issues if two MOTU advocate for it, it gets uploaded.
[04:19] <ScottK> Not really.
[04:19] <ScottK> We are near the end of a development cycle so no one will be looking at new packages until after Lucid is realeased at the end of the month.
[04:20] <GhostOnline> Ah, pity, but understandable
[04:20] <GhostOnline> Is that also the case for bugfixes (I have just submitted a debdiff for a Revelation bug)?
[04:23] <nigelb> GhostOnline, we're in beta 2 freeze, so it will take a week
[04:23] <nigelb> and you need a release team ack for it too I think.. ScottK ?
[04:24] <sistpoty> for universe, bug fix only versions don't need an ack from the release team
[04:26] <GhostOnline> nigelb, sistpoty: AFAIK my previous patches were only reviewed by a MOTU, is this because of the imminent Lucid release?
[04:36] <ScottK> GhostOnline: Yes.
[04:36] <ScottK> It would take a very good reason to get a new package into Lucid now.
[04:37] <ScottK> sistpoty: We have a fortran transition going on?
[04:38] <alastairp> sistpoty: hi, are you around?
[04:38] <sistpoty> ScottK: looks like it, or rather very limited bits remain (https://lists.ubuntu.com/archives/ubuntu-devel/2010-March/030521.html)
[04:38] <sistpoty> alastairp: hi, yes
[04:38] <ScottK> sistpoty: OK.  I hadn't noticed.  Thanks.
[04:39] <alastairp> hi, you asked for some more information on one of my bugs - https://bugs.launchpad.net/ubuntu/+source/python-musicbrainz2/+bug/552391
[04:39] <alastairp> I'm chasing down the rdepends now,
[04:39] <sistpoty> thanks alastairp
[04:40] <alastairp> but one of them doesn't seem to work in karmic anyway - what's should I be checking in lucid if that's the case?
[04:40] <sistpoty> ScottK: it's libgfortran2 -> libgfortran3 to be precise
[04:40] <ScottK> Right.
[04:41] <ScottK> My bug claim to fame today is getting samba4 to build so it's off the removals list.
[04:41] <ScottK> bug/big
[04:41] <sistpoty> alastairp: the upload will need to go to lucid, that's why I'd like to see the packages tested on lucid (testing on karmic might not prove that the package also works in lucid)
[04:42] <alastairp> yeah, I'm installing lucid atm to test, but if it appears to be broken with the current libs, will that affect getting the newer version in?
[04:44] <sistpoty> alastairp: I guess if it's broken anyways, it wouldn't too much matter wrt the new version. but please mention what is broken in the bug report, so that we have it on our radar
[04:45] <alastairp> OK, cool
[05:00] <alastairp> sistpoty: a query about the buildlog - if I upload a ppa package with distroseries lucid and link to the buildlog on launchpad, is that enough?
[05:00] <sistpoty> alastairp: yep
[06:35]  * sistpoty needs sleep, gn8
[15:24] <mhall119> Hi all, I'm making packages for Ubuntu, should my .orig.tar.gz files contain the debian directory and files?
[15:24] <mhall119> and also, I've been told the original packages should be available online somewhere, how do I specify that in the package?
[15:25] <stgraber> if your package has an upstream (so, it's not a native package like a meta-package or ubuntu-specific package), it must have a .orig.tar.gz that doesn't contain debian/
[15:25] <mhall119> stgraber: I'm changing my qimo packages to be upstream instead of native
[15:25] <stgraber> the .orig.tar.gz should just be a renammed tarball from upstream
[15:25] <mhall119> doesn't contain it, ok
[15:26] <stgraber> so you release qimo-something-1.0.tar.gz upstream, it becomes qimo-something_1.0.orig.tar.gz but the md5 stays the same
[15:26] <stgraber> then you uncompress it, put your debian/ directory in there and run debuild -S -sa
[15:26] <stgraber> that way you'll keep the .tar.gz intact and the debian/ will be entirely in the .diff.gz
[15:26] <mhall119> ok
[15:27] <stgraber> with nothing else than debian/ in the .diff.gz (as you aren't supposed to patch the upstream tarball without using a patch system like dpatch, quilt, ...)
[15:27] <mhall119> and I'm supposed to give a url pattern for finding the upstream package, right?
[15:28] <mhall119> next question, qimo-games is a meta package, so it _only_ has the debian directory
[15:28] <stgraber> ok, that one should be kept as a native package as you really can't have an upstream tarball for that
[15:28] <mhall119> (for now anyway)
[15:29] <stgraber> ideally it should be uploaded in debian and synced in Ubuntu unless it's really Ubuntu specific
[15:29] <mhall119> it's not, but right now I'm only familiar with the Ubuntu processes
[15:30] <mhall119> I'll work on debian after I get Qimo 2.0 released
[15:34] <stgraber> sounds like a good plan
[15:35] <stgraber> pushing new packages in Debian and just requesting syncs in Ubuntu is usually the best way to maintain your packages on the long term, unless they are too tied to Ubuntu
[15:38] <mhall119> stgraber: okay, I'm actually going to include some tuxpaint stamps and starters in qimo-games, so it won't be empty
[15:38] <mhall119> where do I put the url patter for upstream packages?
[15:40] <stgraber> mhall119: get-orig-src or something similar in debian/rules which should be a call to uscan, then you'll need a debian/watch file containing a regexp to match the URL of your upstream tarball + you should mention it in debian/copyright
[15:40] <stgraber> I guess that's all documented somewhere :) I unfortunately don't remember the URL to that documentation.
[15:42] <stgraber> you probably could grab the packaging of ltsp-cluster as it's how highvoltage did that (watch file + get-orig-source target using uscan)
[15:42] <stgraber> pull-lp-source ltsp-cluster-accountmanager lucid
[15:42] <stgraber> will get you a package that was done that way (using launchpad as the upstream website where we have our tarballs)
[15:44] <mhall119> pull-lp-source seems to need some configuration, can I just do a bzr branch?
[15:46] <stgraber> bzr get lp:~ltsp-cluster-team/ltsp-cluster/packaging.lucid/
[15:47] <stgraber> inside that one, look in ltsp-cluster-accountmanager/debian/
[15:48] <mhall119> https://launchpad.net/ltsp-cluster/+download http://launchpad.net/ltsp-cluster/.*/ltsp-cluster-accountmanager-(.*)\.tar\.gz
[15:48] <mhall119> what does the first url, with the +download do?
[15:50] <stgraber> it basically says: go to https://launchpad.net/ltsp-cluster/+download and look in the html code for http://launchpad.net/ltsp-cluster/.*/ltsp-cluster-accountmanager-(.*)\.tar\.gz
[15:50] <stgraber> it'll then take the biggest value of (.*) and download it
[15:50] <mhall119> ah, ok, so I need a download page as well?
[15:50] <stgraber> uscan can basically check if you release a new upstream version and download it for you
[15:51] <stgraber> well, that's an example for launchpad. If you have a regular web server with file listing allowed, it's probably even easier
[15:51] <mhall119> what if I don't have file listing allowed?
[15:51] <stgraber> then you'll need some kind of download page as it won't be able to guess what would be your next upstream version
[15:51] <stgraber> a download page is simply a list of link pointing to your tarballs
[15:57] <mhall119> ok
[16:07] <mhall119> stgraber: http://revu.ubuntuwire.com/p/qimo-session
[16:07] <mhall119> and also qimo-games and qimo-wallpaper
[16:07] <mhall119> can you check them out and see if they look alright
[16:08] <mhall119> highvoltage: ^^^
[16:15] <mhall119> uploading a new copy of qimo-wallpaper, I was missing the GPL and CC-BY-SA license files
[16:22] <xteejx> Hey guys
[16:24] <xteejx> I *think* it's MOTU that deals with adobe-flashplugin? Regarding bug 508799...is this correct? Proof seems to be at https://launchpad.net/ubuntu/+source/adobe-flashplugin where Karmic has 10.0.45.2-1karmic1 and Lucid for some reason has version 10.0.32.18-1karmic2, which doesn't seem to make any sense. Won't this cause confusion and possibly upgrade problems?
[16:27] <geser> xteejx: nope, as adobe-flashplugin is in the partner archive it's out of MOTU scope
[16:27] <geser> and yes for the upgrade problems
[16:27] <geser> I assume it's still the same version when lucid was created based on karmic
[16:28] <xteejx> geser: It is yeah, and Karmic/Jaunty were updated, Lucid wasn't
[16:29] <mhall119> stgraber: highvoltage: uploading new packages for all 3, because I was missing version=3 in my watch files
[16:29] <xteejx> Not too sure who to grab for this one... i.e. partner upload
[16:29] <geser> xteejx: try contacting https://edge.launchpad.net/~brian-thomason as he sponsored/did the uploads. So he is either the right person to contact or know who is.
[16:30] <xteejx> geser: Thanks geser
[16:30] <sebner> huhu geser :)
[16:30] <geser> Hi sebner
[17:06] <ScottK> It would be good if someone who knows something about Tex packages could sort out the *tex related NBS: http://people.canonical.com/~ubuntu-archive/NBS/
[18:18] <nigelb> query ubottu
[19:18] <randomaction> ScottK: some my patches seem to have reached Debian, so I'll request syncs
[19:19] <randomaction> ScottK: also, some of these are false (e.g. dependencies on tetex-* | texlive-*)
[19:19] <ScottK> randomaction: Great.  Sounds good.
[20:10] <kobrien> hey guys, not sure where to ask. I'm patching a bug in lighttpd. I'm wondering if I'm to update the debian/control file as described here. https://wiki.ubuntu.com/Bugs/HowToFix I don't wish to become the maintainer but it seems i'm instructed to edit this.
[20:11] <crimsun> kobrien: why you instead of Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> ?
[20:12] <kobrien> is that the appropriate thing to do?
[20:12] <ScottK> Almost certainly.
[20:12] <kobrien> oh ok. thanks for clearing that up. *new to this*
[20:15] <RoAkSoAx> kobrien, are you trying to patch a bug for lucid?
[20:15] <ScottK> kobrien: Welcome.  We're glad to have you.
[20:17] <kobrien> RoAkSoAx: yes, lighttpd won't bind to port 80 at the moment cause of an ipv6 issue.
[20:17] <RoAkSoAx> kobrien, you have to comment a line in lighttpd.conf
[20:17] <RoAkSoAx> so that It won't load the ipv6 script
[20:19] <kobrien> RoAkSoAx: it works if you bind ipv6 to localhost instead of it being randomlu assigned.
[20:20] <RoAkSoAx> kobrien, if you comment: include_shell "/usr/share/lighttpd/use-ipv6.pl" in lighttpd.conf it will bind the port
[20:20] <RoAkSoAx> kobrien, and you might want to check http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560837
[20:21] <kobrien> RoAkSoAx: will do
[20:25] <RoAkSoAx> kobrien, What I was actually planing to do is to comment that line by default in the config file for now
[20:27] <kobrien> RoAkSoAx: binding it to locahost in ipv6 seems like a better plan, no?
[20:30] <RoAkSoAx> kobrien, well this bug was supposed to be fixed in debian but it seems it is not
[20:30] <kobrien> indeed
[20:30] <jpds> Killing IPv6 by default sounds like a Bad Idea.
[20:31] <kobrien> agreed
[20:31] <RoAkSoAx> kobrien, oh ok, now I see what went wrong. Debian maintainer *forgot* to comment the line in lighttpd.conf
[20:34] <RoAkSoAx> kobrien, take a look to what upstream recommends: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560837#38
[20:35]  * kobrien reads
[20:36] <cnd> nhandler: paultag sent me a note you were asking about alt+drag in rinputd/remotux
[20:36] <cnd> are you referring to just a normal drag event?
[20:37] <RoAkSoAx> kobrien, im going to follow their suggestion and comment the line in the lighttpd.conf and upload it :)
[20:37]  * ScottK notes that the buildds are almost caught up, so people should get busy fixing stuff and uploading ...
[20:37] <kobrien> RoAkSoAx, way ahead of you
[20:52] <RoAkSoAx> ScottK, do I need to contact someone to push my recent upload?
[20:53] <ScottK> RoAkSoAx: No.  I'll push it in a moment.
[20:53] <RoAkSoAx> ScottK, awesome. Thank you :)
[20:55] <ScottK> RoAkSoAx: Is http://bugs.debian.org#48 going to be a problem?
[20:56] <RoAkSoAx> ScottK, which one?
[20:56] <ScottK> Comment 48
[20:56] <ScottK> About running on ports other than port 80
[20:57]  * RoAkSoAx checking
[20:59] <RoAkSoAx> ScottK, it is not supposed to, I personally check it when I uploaded 1.4.26-1.1ubuntu1 and the upgrade didn't fail
[20:59] <ScottK> As it happens, I'm working on a project where lighttpd gets run on !port 80 and I'm trying to get them to switch to Ubuntu.  Breaking that wouldn't help.
[21:00] <RoAkSoAx> ScottK, let me recheck
[21:00] <ScottK> RoAkSoAx: So you could listen on !port80 when something like Apache owned port 80?
[21:01] <RoAkSoAx> ScottK, yes
[21:01] <ScottK> OK.
[21:01] <RoAkSoAx> ScottK, im gonna recheck just in case
[21:02] <RoAkSoAx> though this last change only makes not load ipv6 by default
[21:02] <ScottK> RoAkSoAx: OK.  I'll hold off.  Let m eknow.
[21:08] <RoAkSoAx> ScottK, ok, first step, I installed lighttpd while running nginx bindin port 80, it will fail to start because by default lighttpd also uses port 80, but changing the port lighttpd works. Now Im  going to try the upgrade
[21:09] <ScottK> Cool
[21:17] <ScottK> RoAkSoAx: I'm heading out for a bit.  Let me know how it turns out and I'll accept it when I get back.  If you need to change something, just reupload (with the same version), I can reject the wrong one).
[21:18] <RoAkSoAx> ScottK, ok will do :)
[21:49] <mhall119> nixternal: hey
[21:53] <RoAkSoAx> ScottK, Ok. If I upgrade and choose not to replace "/etc/lighttpd.conf", it will upgrade successfully.
[21:55] <RoAkSoAx> ScottK, if I upgrade and choose to replace "/etc/lighttpd.conf" with new package maintainers version, then the upgrade will not fail, however lighttpd will fail to start "invoke-rc.d: initscript lighttpd, action "start" failed.". This is because by replacing it defaults to port 80 which is bind by nginx already. So it is just matter to change the port number again in the config and will start successfully.
[21:58] <RoAkSoAx> ScottK, However, If we keep 1.4.26-1.1ubuntu1 and not upload 1.4.26-1.1ubuntu2, whenever we upgrade, it will fail to start even if we change the default port for lighttpd.conf, because ipv6 will try to bind port 80, which si already bind by nginx. So, this upload actually fixes this by disabling by default ipv6
[22:02] <kobrien> hi, I've generated a patch. what do I need to upload? the debdiff?
[22:05] <RoAkSoAx> kobrien, yes
[22:06] <kobrien> and only yhr debdiff?
[22:06] <kobrien> the*
[22:08] <ScottK> RoAkSoAx: Sounds like what you have is good.
[22:08] <ScottK> RoAkSoAx: Should I go ahead and accept it then?
[22:09] <kobrien> having patched this lighttpd thing, will I only upload a debdiff file, or do I send one of these archives generated?
[22:09] <RoAkSoAx> ScottK, yes :)
[22:11] <ScottK> RoAkSoAx: Accepted.
[22:11] <RoAkSoAx> ScottK, thank you :)
[22:12] <kobrien> launchpad doesn't seem to think my debdiff is a patch
[22:13] <AnAnt> kobrien: that happened with me recently too
[22:13] <AnAnt> Hello, is it late to request a sync from Debian ?
[22:14] <kobrien> pff, my fix for lighttpd doesn't break ipv6
[22:14] <AnAnt> pyfribidi 0.10.0-2 has been in testing since 3/3, someone just notified me that it isn't in lucid
[22:14] <kobrien> and the bug was assigned to me, way to go around me
[22:17] <kobrien> waste of an hour
[22:17] <ScottK> AnAnt: It's not too late.
[22:19] <AnAnt> but I still need to provide all info about it ?
[22:19] <AnAnt> actually, when was the last rebuild of packages done ?
[22:44] <RoAkSoAx> kobrien, your patch is a good idea, however, the purpose of enabling IPv6 by default is to make ipv6 listen to any instead of binding only to localhost
[22:44] <RoAkSoAx> so it should listen on *any* address and not only *localhost*