=== asac_ is now known as asac
[01:08] <stochastic> james_w, if you have any more time, I've fixed the copyright file in http://revu.ubuntuwire.com/p/a2jmidid
[01:52] <RainCT> directhex: Got some time to review http://revu.ubuntuwire.com/p/mistelix? :)
[01:55] <directhex> RainCT, seems sound
[02:00] <RainCT> directhex: gonna give me an advocation today? :)
[02:01] <directhex> don't think i have the button needed to do so
[02:03] <RainCT> directhex: Which means you should use REVU more! :P
[02:03] <RainCT> Now you have
[02:03] <directhex> :o
[02:05] <RainCT> mok0!! :P
[02:51] <RainCT> directhex: thanks!
=== vorian is now known as v
=== santiago-pgsql is now known as santiago-ve
[06:18] <happyaron> could someone have time have a review on http://revu.ubuntuwire.com/p/gmchess ?
[06:23] <ripps_> happyaron: in my experience, it seems easier to get new packages into debian through debian mentors and then to make a sync request in ubuntu. Motu's only seem to check revu once in a blue moon
[06:24] <happyaron> ripps_: oh, thanks
=== ripps_ is now known as ripps
[07:24] <hyperair> ripps: my experience is the reverse. i've gotten a few packages in through revu before, but none through debian mentors.
[07:24] <hyperair> ripps: of course, it's better to use debian-mentors and get it synced over anyway, but that's a different matter.
[07:55] <happyaron> hyperair: I volunteer to maintain that tor package in ubuntu, how can I do that?
[08:19] <hyperair> happyaron: er what?
[08:48] <happyaron> hyperair: I want maintain 'tor' in ubuntu, which deleted before
[08:56] <hyperair> hmm i'm not sure why it was deleted in the first place
[09:01] <happyaron> hyperair: https://bugs.launchpad.net/ubuntu/+source/tor/+bug/328442
[09:01] <ubottu> Ubuntu bug 328442 in tor "Tor 0.1.2.x abandoned by upstream, update to 0.2.0.34" [Undecided,Fix released]
[09:01] <hyperair> hmm fix released?
[09:01] <hyperair> that means it's back in ubutnu?
[09:02] <happyaron> hyperair: no ,the fix is abandoned in jaunty
[09:02] <happyaron> hyperair: I want it back, and seems it needs somebody to maintain it for ubuntu as it was said in that bug
[09:02] <hyperair> i see.
[09:03] <hyperair> i'm not sure how to go about reintroducing packages
[09:03] <hyperair> chances are you'll have to go through NEW again
[09:03] <hyperair> basically package a new fix, stick it in revu, and such
[09:03] <hyperair> or debian-mentors
[09:03] <hyperair> was it removed from debian?
[09:03] <happyaron> hyperair: no
[09:03] <happyaron> hyperair: I requested the sync, https://bugs.edge.launchpad.net/ubuntu/+bug/413657
[09:04] <ubottu> Ubuntu bug 413657 in ubuntu "[needs-packaging] Please sync tor 0.2.1.19-1 (universe) from Debian unstable (main)" [Wishlist,New]
[09:04] <hyperair> ah. subscribe ubuntu-universe-sponsors
[09:04] <happyaron> but they told me we need somebody keep maintain it for ubuntu
[09:04] <happyaron> hyperair: and send a mail there?
[09:04] <hyperair> who is they?
[09:04] <hyperair> and got a link to the post?
[09:04] <hyperair> nono subscribe the launchpad team ubuntu-universe-sponsors to that bug
[09:04] <happyaron> somebody in this channel
[09:05] <happyaron> oh
[09:05] <hyperair> is someone maintaining it in debian/
[09:05] <hyperair> or has it been orphaned?
[09:05] <hyperair> packages.qa.debian.org is hating me currently =\
[09:06] <hyperair> huh bugs.debian.org as well
[09:06] <happyaron> hyperair: there is somebody still maintains it
[09:07] <happyaron> I cannot access packages.qa.debian.org either
[09:07] <hyperair> in that case, it shouldn't be much of an issue and should get autosynced at the beginning of every release
[09:07] <hyperair> any archive admins here?
[09:09] <happyaron> hyperair: but it was deleted in jaunty because the 0.1.x is abandoned by upstream, but nobody maintains 0.2.x for ubuntu, as described in that bug
[09:09] <happyaron> http://packages.ubuntu.com/search?keywords=tor&searchon=names&suite=all&section=all
[09:10] <hyperair> that's not a bug address
[09:10] <happyaron> that's a search result in packages.ubuntu.com
[09:11] <happyaron> this is the previous bug https://bugs.launchpad.net/ubuntu/+source/tor/+bug/328442
[09:11] <ubottu> Ubuntu bug 328442 in tor "Tor 0.1.2.x abandoned by upstream, update to 0.2.0.34" [Undecided,Fix released]
[09:11] <happyaron> and this is my sync request https://bugs.edge.launchpad.net/ubuntu/+bug/413657
[09:11] <ubottu> Ubuntu bug 413657 in ubuntu "[needs-packaging] Please sync tor 0.2.1.19-1 (universe) from Debian unstable (main)" [Wishlist,New]
[09:13] <hyperair> happyaron: yes yes can you stop reposting your links please.
[09:13] <hyperair> now then.
[09:14] <hyperair> i've read through the bug, and it seems that the person who was involved mainly was pitti
[09:14] <hyperair> i say you sit around and wait for him here
[09:14] <hyperair> or #ubuntu-desktop
[09:14] <happyaron> oh
[09:14] <hyperair> and ask him *nicely* not annoyingly repeating yourself multiple times here.
[09:14] <hyperair> or email him
[09:15] <happyaron> sorry, I just didn't understand what you said in 'that's not a bug address', so I repeated the links
[09:51] <logari81> hi, I have a package which installs a python module using debhelper+pysupport
[09:51] <logari81> in jaunty the module is installed in
[09:51] <logari81> usr/share/python-support/packagename/pythonversion/.....
[09:51] <logari81> in karmic it is being installed in
[09:51] <logari81> usr/lib/pyshared/pythonversion/...
[09:51] <logari81> instead. Why does this happen?
[10:50] <maxb> logari81: Because python-support has been redesigned to act in that way.
[10:57] <iulian> How much time does it take for a new package to show up in the pools?
[10:58] <logari81> maxb: nice, it is normal then.... I don't have to worry
[11:12] <therm> iulian: "it depends" ;-)
[11:13] <therm> iulian: on you and your skills in packaging, on the calendar date (feature freeze), if you find someone who is reviewing your packages and so on..
[11:14] <maxb> iulian: define "new"
[11:24] <iulian> maxb: Synced from Debian.
[11:24] <iulian> It seems that some buildds are busy.
[11:25] <andv> iulian, as soon as it gets built it will be published in LP
[11:25] <andv> don't worry
[11:25] <andv> iulian, depends on buildd queue
[11:25] <iulian> Yea.
[11:25] <andv> but I guess in 3-4 hours will be done
[11:27] <slytherin> iulian: is that a new source?
[11:27] <iulian> That odd.  Then why liblocale-msgfmt-perl hasn't been published?  bug#412585
[11:27] <iulian> s/that/that's/
[11:27] <LLStarks> hi.
[11:28] <LLStarks> can i get a sense of progress on this? https://bugs.launchpad.net/ubuntu/+source/libass/+bug/410112
[11:28] <ubottu> Ubuntu bug 410112 in libass "libass 0.9.7 released" [Undecided,Confirmed]
[11:28] <iulian> https://bugs.launchpad.net/ubuntu/+bug/412585
[11:28] <ubottu> Ubuntu bug 412585 in ubuntu "please sync liblocale-msgfmt-perl from debian sid" [Wishlist,Fix released]
[11:28] <LLStarks> i know it's been ppa'd already, but what's keeping it from the build farm?
[11:28] <LLStarks> isn't 10 days enough for a fair evaluation?
[11:29] <iulian> LLStarks: It hasn't been uplaoded yet.
[11:29] <slytherin> LLStarks: evaluation where? Is it available in revu?
[11:29] <LLStarks> not sure.
[11:30] <slytherin> iulian: your package is here - https://edge.launchpad.net/ubuntu/karmic/+queue?queue_state=0&queue_text=liblocale-msgfmt-perl
[11:30] <iulian> Oh!
[11:30] <iulian> That explains it.
[11:33] <slytherin> LLStarks: As discussed on the Debian bug, has SONAME bump been taken care of? What about transition plat for packages that build-depend on it?
[11:33] <LLStarks> i'm the wrong person to  ask.
[11:37] <LLStarks> i'd like to think all outstanding issues are resolved.
[11:37] <LLStarks> artur, the sponsor, has a ppa package that would suggest so.
[11:37] <LLStarks> https://launchpad.net/%7Eari-tczew/+archive/ppa/+sourcepub/692957/+listing-archive-extra
[11:48]  * LLStarks sighs
[11:49] <LLStarks> i find the cynicism of the gstreamer and totem dev teams to be counterproductive to delivering a product that can outperform mplayer out of the box.
[12:07] <rowinggolfer> can anyone tell me if this howto is still current? https://wiki.ubuntu.com/PackagingGuide/Python
[12:07] <rowinggolfer> it advocates the use of python-central
[12:08] <rowinggolfer> pochu: I guess I am asking you ^^^
[12:09] <rowinggolfer> pochu: great howto, but not working for my project. (openmolar on launchpad)
[12:17] <maxb> rowinggolfer: My impression is that community consensus favours python-support these days
[12:18] <rowinggolfer> maxb: that's the conclusion I am coming to also
[12:19] <rowinggolfer> although I am struggling to find any documentation for it.
[12:29] <rowinggolfer> maxb: my problem is exacerbated by the fact that *.egg files (ie. using setuptools not distutils)
[12:29] <rowinggolfer> seems to be the flavour of the month
[12:29] <rowinggolfer> and yet I would like my project debs to be build in launchpad.
[12:29] <rowinggolfer> I am REALLY confused at the moment.
[12:29] <rowinggolfer> and would much rather be adding new features to the app itself
[12:30] <rowinggolfer> as opposed to trawling through contradictory howtos.
[13:06] <maxb> rowinggolfer: Perhaps if you explain your current specific problem, or point to a failing buildlog or package that built wrongly, people here can help
[13:07] <rowinggolfer> maxb: http://launchpadlibrarian.net/30377369/buildlog_ubuntu-intrepid-amd64.openmolar_0.1.2-0ubuntu1_FAILEDTOBUILD.txt.gz
[13:07] <c_korn> hello, I am trying to create a sync request for scilab using requestsync but I get this error: http://pastebin.com/ddcfaf51
[13:07] <rowinggolfer> when I tried to build this
[13:07] <rowinggolfer> https://launchpad.net/~rowinggolfer/+archive/ppa/+build/1166278
[13:09] <maxb> dpkg-gencontrol: error: error occurred while parsing , , $(python:Depends}
=== happyaron_ is now known as happyaron
[13:09] <maxb> rowinggolfer: error is (somewhat) obvious :-)
[13:09] <maxb> hint: look carefully at those brackets :-)
[13:10] <slytherin> c_korn: read the last line in that error
[13:11] <andv> c_korn, you should set up your user informations
[13:11] <andv> c_korn, so that LP will recognize you when you submit the bug report
[13:11] <c_korn> slytherin: I know. but the wiki says that I will be prompted for my GPG passphrase and not that I type my LP password in plain text somewhere: https://wiki.ubuntu.com/SyncRequestProcess
[13:12] <slytherin> c_korn: Before that the requestsync needs to setup a cookie. Did you check manpage of manage-credentials?
[13:14] <c_korn> I did. and requestsync asked me to log in in LP using firefox so it can get the cookie. I did so but now it additionaly requires my password ?
[13:16] <slytherin> c_korn: Which password is it asking you?
[13:28] <c_korn> slytherin: ok, it also only wanted me to log in into LP. I think this step should be noted in the wiki. Am I allowed to add it ?
[13:29] <slytherin> c_korn: sure, why not.
[13:31] <rowinggolfer> maxb - whoops.
[13:31] <rowinggolfer> thanks!
=== porthose_ is now known as porthose
[13:46] <c_korn> ok, thanks. I added it.
[13:50] <c_korn> eh, why do I have to attach a build log ? is this always the case? https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/414410/comments/1
[13:50] <ubottu> Ubuntu bug 414410 in scilab "Sync scilab 5.1.1-7 (universe) from Debian unstable (main)." [Wishlist,New]
[13:53] <geser> c_korn: depends on your sponsor, Andrea wants to see a build log as a proof that you test-build the package before requesting the sync
[13:54] <andv> c_korn, I'm not at home so I can't test-build it on my own
[13:54] <andv> and anyway it's alwais important to test build packages before asking to sync them
[13:55] <andv> (packages coming from unstable to karmic of course)
[13:55] <andv> geser, ty for the response
[13:55]  * Laney always builds before sponsoring anyway
[13:56] <andv> Laney, if I'm not at home, I just ask to provide a build log
[13:56] <c_korn> ok, I just followed the wiki. maybe I should also add this as a note. so dputting the debian unstable package into a PPA for karmic is enough ?
[13:56] <andv> or ask my cousin's pc but he just left
[13:57] <andv> c_korn, yes
[13:57] <andv> c_korn, just add a note saying sometimes is preferred a build log
[13:57] <andv> attached at the sync request
[13:57] <andv> (if the sponsor requires it of course)
[13:59] <andv> geser, the automated sync import is no more active?
[14:01] <geser> no, the automated sync stops at DIF
[14:01] <slytherin> andv: not since Debian Import Freeze
[14:01] <andv> true, ty for the info
[14:10] <pochu> rowinggolfer: I guess it could use some love, but shouldn't be too far from reality
=== ember_ is now known as ember
[14:21] <happyaron> geser: hi
[14:26] <logari81> how should I handle some source files without any license and copyright notes? They are mostly small test files, not really important for the package. Could I just ignore them in debian/copyright ?
[14:32] <andv> logari81, usually all source files should have their own license header
[14:33] <slytherin> logari81: No. You can not ignore any files. Either contact upstream and ask them to assign a copyright/license or remove the files while creating .orig.tar.gz
[14:33] <rowinggolfer> pochu: thanks. turns out the problem was me being as dense as concrete
[14:33] <logari81> andv, slytherin: ok I ll try to contact the upstream
[14:34] <andv> great
[15:39] <geser> happyaron: Hi
[15:55] <happyaron> geser: I have packed tor, but where to upload it? to revu?
[15:59] <andv> happyaron, please ask your question to the whole channel
[15:59] <andv> and not to a specific person
[16:00] <andv> (of course if this specific person is not directly involved in what you ask)
[16:00] <andv> happyaron, is that a NEW package?
[16:00] <andv> happyaron, or a new upstream release? or what?
[16:00] <happyaron> andv: no, 'tor'
[16:01] <happyaron> andv: yes, but deleted in jaunty
[16:01] <devfil> happyaron: what did happen to the sync request?
[16:02] <andv> happyaron, deleted in jaunty??
[16:02] <andv> happyaron, why?
[16:02] <happyaron> https://bugs.edge.launchpad.net/ubuntu/+bug/413657
[16:02] <ubottu> Ubuntu bug 413657 in ubuntu "[needs-packaging] Please sync tor 0.2.1.19-1 (universe) from Debian unstable (main)" [Wishlist,New]
[16:03] <andv> happyaron, if it has been deleted from jaunty there should be a valid motivation
[16:03] <happyaron> the bug which have it deleted was bug #328442
[16:03] <ubottu> Launchpad bug 328442 in tor "Tor 0.1.2.x abandoned by upstream, update to 0.2.0.34" [Undecided,Fix released] https://launchpad.net/bugs/328442
[16:03] <devfil> happyaron: well, I think the sync request is enough, if you work on a new package or the package is taken from debian is the same thing (but it's better to have it due to a sync), pelase ask to pitti if we can upload that
[16:03] <happyaron> though it shows fix released, the solution is delete tor in jaunty
[16:04] <andv> happyaron, you should talk to an archive admin about whether we should accept it back or not, I guess
[16:05] <happyaron> andv: archive admin, who are they?
[16:05] <devfil> happyaron: please, ask to pitti
[16:05] <happyaron> ok, still pitti
[16:05] <andv> happyaron, pitti for istance, he replied on that bug report too
[16:05] <happyaron> I know
[16:05] <andv> so he will know what to do
[16:05] <happyaron> okay, thanks
[16:06] <andv> np
[16:25] <geser> andv: from the old thread on ubuntu-devl I assume it will get accepted back iff there is a maintainer for it who also takes care about the versions in the released Ubuntu versions
[16:26] <andv> geser, yeah, it seems happyaron wanna maintain it on Ubuntu
[16:26] <andv> let's see what will happen after his talk with pitti then
[16:30] <happyaron> andv, geser I've sent him a mail, what to do might be wait for him
[16:30] <andv> yep
[16:47] <hyperair> geser: what's the issue with just having it get autosynced from debian?
[16:48] <hyperair> geser: there's a debian maintainer isn't there?
[16:48] <geser> hyperair: missing SRUs
[16:49] <hyperair> geser: i mean in karmic. it's gone from karmic as well
[16:49] <geser> upstream contacted Ubuntu and asked us to remove tor from released versions as we were shipping versions abandoned upstream
[16:49] <hyperair> yes, i noticed.
[16:50] <hyperair> but karmic isn't released is it
[16:50] <geser> hyperair: we could sync it to karmic but have to remove it before release, so why sync in the first place?
[16:50] <hyperair> ..eh what?
[16:50] <geser> (unless we find a maintainer)
[16:50] <hyperair> no wait, aren't the debian packages maintained upstream?
[16:51] <geser> I don't know the situation exactly. I know that upstream has a repo with debs for Debian and Ubuntu
[16:51] <hyperair> the issue was with a certain version of tor, but it's been picked up by another upstream was it not?
[16:51] <hyperair> yeah, i know that too
[16:51] <hyperair> but taht's all i know
[16:52] <geser> hyperair: and how do we prevent that it doesn't happen again?
[16:52] <hyperair> upstream abandonment?
[16:52] <hyperair> don't all projects undergo the same risk?
[16:52] <hyperair> especially if it's maintained upstream by a person rather than a team?
[16:53] <geser> say, we sync tor 2.1.19 (IIRC that's the current version) to karmic, release karmic with it, upstream releases 2.2.0 in a few months and doesn't support 2.1.x say 6 months later (or so) while karmic will still be in support
[16:53] <hyperair> i see, so you basically want someone to actively backport it?
[16:53] <geser> (don't know upstream release plans at all)
[16:54] <geser> yes
[16:54] <hyperair> sounds like a painful upstream.
[16:54] <geser> someone who takes care that karmic will have a version of tor which is maintained upstream
[16:55] <hyperair> i'm just speculating here, but aren't most projects obsoleting their old versions and telling you to upgrade to the latest, but incidentally the latest doesn't appear in stable versions of ubuntu because the archive's frozen?
[16:56] <geser> I can understand upstream that they don't want to support Ubuntu users with a version which is too old (e.g. once synced before DIF of a LTS version)
[16:58] <geser> hyperair: yes, other upstreams may have the same problem but they don't contact Ubuntu and simply ignore that problem
[16:59] <hyperair> in other words, as long as the upstream says "we don't support an old version any more" we're going to purge it from the archive, including from an unstable archive?
[16:59] <hyperair> that'll screw around with our entire release cycle won't it?
[17:00] <hyperair> though i think the best person to talk about this issue with is pitti, since he's the on who made the decision then.
[17:00] <geser> we aren't hostile towards upstream and try to find solutions which please all but if the only solution is that we remove it than it will be
[17:00] <hyperair> perhaps there are additional reasons that aren't clear
[17:01] <hyperair> i know we aren't hostile with upstream, in fact we should work well together with upstream if possible. but i think that purging a package from the archive just because it isn't supported is too harsh.
[17:01] <geser> in the tor case someone stepped up to updated the tor packages once (for the released versions) but as we didn't find someone to look after them in the future is was the best to remove it
[17:01] <hyperair> there are many users (like me) who want to use an old version of the package even if it isn't supported.
[17:02] <hyperair> something like "i don't care if it's supported or not. it's worked for me in the past, and will continue to work for me so just let me use my old crippled version if you're not going to give me a new one"
[17:04] <hyperair> if it's broken, i'd understand completely. purge it from the archive since it's not going to be much use in the archive anyway. but it wasn't broken beyond use (or at least not highlighted in the bug reports anyway)
[17:04] <geser> hyperair: nothing forces you to remove installed packages if you don't want and removing packages from released versions is pretty hard (never heard that Ubuntu needed to do that)
[17:05] <hyperair> geser: i'm talking about if i reinstalled ubuntu and want to get back my packages
[17:05] <hyperair> geser: there are many users who reinstall every release instead of just do-release-upgrade-ing or using update-manager all the way
[17:07] <geser> as removing from released versions it pretty hard, it won't probably happen for that reason, but it will be removed from the development versions (and therefore future release) if no solution can be found
[17:08] <hyperair> geser: what about the just-let-it-autosync-from-debian solution?
[17:09] <geser> hyperair: see the ion3 case in Debian. upstream was unhappy that Debian shipped old devel versions in stable so changed the license and force it to non-free (http://packages.debian.org/changelogs/pool/non-free/i/ion3/ion3_20090110-2/ion3-dev.copyright)
[17:10] <hyperair> ...that's ridiculous =.=
[17:10] <geser> hyperair: that only works till DIF and after that nobody files sync requests and prepares SRU or backports -> upstream unhappy again
[17:12] <hyperair> i pity whoever has to deal with ion3's upstream.
[17:13] <hyperair> geser: are all packages maintained by at least somebody in ubuntu, or is there a significant number that aren't, but just in debian?
[17:13] <andv> hyperair, the latest
[17:13] <andv> i would say
[17:13] <hyperair> andv: what latest?
[17:14] <andv> hyperair, the latest phrase you said
[17:14] <hyperair> latter you mean?
[17:14] <andv> yeah :)
[17:14] <andv> usually a lot of Debian maintainer works on ubuntu too
[17:14] <geser> hyperair: depends how you define "maintain". there are certainly packages in universe which are just auto-synced from Debian where nobody ever looked at the bugs in LP
[17:14] <andv> so there aren't any problems
[17:14] <hyperair> okay, excluding those.
[17:15] <hyperair> geser: that's precisely what i mean.
[17:15] <hyperair> geser: if we go around deleting packages just because they're just auto-synced and nobody stares at it in LP, we're going to have a significantly decreased pool.
[17:16] <andv> hyperair, the problem was not related to the fact they are auto-synced
[17:16] <geser> hyperair: we do it only when upstream asks us to and nobody steps up to look after the package
[17:16] <hyperair> andv: i meant just autosynced and not brought into ubuntu via any other method.
[17:17] <hyperair> geser: well let's pray hard that we don't get any more fussy upstreams.
[17:17] <andv> hyperair, usually auto-synced packages are maintained correctly in Debian
[17:17] <hyperair> geser: if there are enough of these upstreams, we'll have a significantly reduced pool and people will start jumping ship.
[17:17] <hyperair> andv: isn't tor maintained correctly in Debian?
[17:17] <andv> hyperair, dunno
[17:18] <andv> didnt follow that package for a while
[17:18] <hyperair> the PTS seems to show that it's actively maintained.
[17:18] <andv> but from what geser said upstream directly contacted ubuntu to have old versions removed
[17:18] <hyperair> he filed a bug, yes.
[17:18] <andv> that's the main problem not the fact it's auto-synced
[17:19] <andv> let's hope the guy who wants to maintain it here will do a good work then
[17:19] <hyperair> why couldn't we just file a sync request, and then let the next DI round bring the next version in again?
[17:20] <andv> hyperair, I guess that's happyaron's idea
[17:20] <andv> hyperair, he mailed pitti already who followed tor issue in the past
[17:20] <geser> and who looks at tor once karmic is released? that's the main problem as there nobody is/was to do it
[17:20] <andv> geser, I thought happyaron wanted
[17:21] <geser> andv: yes, that's the plan
[17:21] <andv> oh ok, that's it then
[17:21] <hyperair> geser: my main concern here is that there are presumably many other packages in a similar situation, with the exception that they don't have fussy upstreams.
[17:21] <andv> hyperair, yep
[17:21] <geser> tor can be synced again if the archive admins are happy with happyaron maintained it
[17:21] <hyperair> and i think it's important that we give more consideration to our users
[17:22] <hyperair> this is a one-off case that is resolved by getting a maintainer.
[17:22] <hyperair> i find it disturbing that something like this can happen.
[17:22] <andv> hyperair, luckily seems this issue is a bit rare
[17:23] <hyperair> yes, luckily, but i'd still like our users to be given greater priority.
[17:23] <Laney> I think there was more to it than upstream support
[17:23] <Laney> ie the packages didn't work or had security holes
[17:23] <Laney> there's a thread about it
[17:23] <hyperair> security holes i think.
[17:23] <hyperair> but i think they did work.
[17:23] <hyperair> at least in intrepid i used it
[17:23] <Laney> "unmaintained" is a bad excuse
[17:23] <Laney> as the vast vast majority of *verse packages aren't maintained by us
[17:24] <andv> hyperair, Debian usually don't have this kind of problems cause its particular way of maintaining things (e.g there is a specific person who looks up a package)
[17:24] <hyperair> andv: i agree. i'm concerned about *ubuntu* users.
[17:25] <Laney> anyway
[17:25] <hyperair> all we need is to have a set of fussy upstreams, and have a few more packages purged in a similar manner, and whee no more users.
[17:25] <Laney> if upstream maintain a deb repository of their own, and we updated the SRU policy with a specific exception for tor
[17:25] <Laney> ....you see where I'm going
[17:26] <hyperair> update the policy how exactly?
[17:26] <geser> hyperair: we don't help our users either when we provide them old packages who nobody cared to update for security holes
[17:26] <Laney> there was an agreement to allow new upstream releases of tor
[17:27] <hyperair> geser: you don't help users, but at least you don't go out of your way to inconvenience them.
[17:27] <Laney> the problem was the nobody did it
[17:27] <Laney> that*
[17:27] <hyperair> Laney: so there was such a clause in the policy?
[17:30] <geser> hyperair: true, but if we don't have ressources to do it properly then IMHO it's better to not provided a package instead of raising assumptions in the users that we can't hold (at least they know that they're on their own)
[17:30] <Laney> http://www.mailinglistarchive.com/ubuntu-devel@lists.ubuntu.com/msg24406.html
[17:30] <Laney> I'm suggesting that if upstream maintain these debs anyway then they might as well maintain them in ubuntu
[17:32] <hyperair> i'm thinking the same thing actually. happyaron: maybe you should go contact them, and establish some form of communica-oh hell he disappeared.
[17:32] <geser> hyperair: this problem might only arise for a very active upstream (releases several times a year) and popular programmes as users will contact upstream for help. It probably won't occur for software which releases once 2 years with only a few users.
[17:33] <hyperair> agreed. but i'd suggest that popcon should be consulted before purging a package like that with "unmaintained" as the excuse.
[17:38] <geser> removing a package from the development version should only be a last resort and should not be dismissed as an non-option how unpleasant it is
[17:39] <geser> of course we should try any other option before going this way
[17:41] <hyperair> mmhmm
[17:42] <hyperair> but in tor's case, it was a remove-or-update request wasn't it? if upstream cared enough to request this of ubuntu, why not expend the effort to file a sync request occasionally?
[17:42] <Laney> it's stable updates that are the problem
[17:42] <hyperair> imo it was remove-from-future-releases, wasn't it?
[17:42] <Laney> yes
[17:43] <Laney> but the reason was keeping it up to date in stable releases
[17:43] <hyperair> i see.
[17:43] <hyperair> imo upstream should have expended the effort of getting it backported =\
[17:43] <hyperair> filing a backport request or something
[17:44] <andv> hyperair, it got backported to hardy
[17:45] <geser> I don't expect that upstream knows all the processes in all those distro out there (and they shouldn't care)
[17:45] <andv> and then nothing more
[17:45] <hyperair> i think if they care enough to request removal, they should care enough to go through all the procedures.
[17:46] <hyperair> otherwise just not care about requesting removal
[17:47] <geser> hyperair: do you expect that upstreams knows the backport process in Debian? or OpenSuse? or Fedora? I don't
[17:48] <hyperair> i expect them to either not care about a distro enough to request removal, or to care about a distro enough to get it updated.
[17:48] <geser> they care about their software and in there eyes getting it removed was the easiest way to resolve the problem
[17:50] <hyperair> i can't bring myself to agree with their thinking, esp if it was released under GPL or some other DFSG-compatible permissive license. it's contradiction, nothing else.
[17:50] <geser> they probably don't care about Ubuntu, they just want to stop the support requests from Ubuntu users using obsolete versions
[17:50] <hyperair> they could ignore them =\
[17:51] <hyperair> or redirect them
[17:51] <Laney> they clearly do care if they maintain their own packages
[17:53] <hyperair> mmhmm
[17:53] <geser> this discussion leads nowhere as we don't know the reasons and thinking from upstream which lead to that mail
[17:53] <hyperair> true
[17:54] <geser> we got that request and had to deal with it somehow
[17:55] <Laney> did we?
[17:56] <geser> did we not? there was a thread on ubuntu-devel ML what to do
[17:57] <Laney> Just saying that doing nothing was an option
[17:57] <Laney> and the interests of the distro and the interest of upstream aren't always the same thing
[17:58] <hyperair> https://bugs.launchpad.net/ubuntu/+source/tor/+bug/147987 <-- another bug referring to the whole tor issue
[17:58] <ubottu> Ubuntu bug 147987 in tor "remove tor from gutsy" [Undecided,Invalid]
[17:59] <hyperair> there's a link to a long ml thread there as well
[18:01] <hyperair> and a post from their project leader: https://lists.ubuntu.com/archives/ubuntu-devel/2007-September/024479.html
=== dyfet` is now known as dyfet
[19:14] <nhandler> It looks like the new lintian will be maintaining a list of certain meta packages in order to notify people when a package depends on a meta package. Would we be interested in modifying the list in Ubuntu so that it knows about some of our Ubuntu-specific meta packages?
[19:37] <AnAnt> Hello, can someone help me with this build failure: dpkg-gencontrol: error: current host architecture 'amd64' does not appear in package's architecture list (i386)
[19:37] <AnAnt> why does this cause an error ?
[19:38] <slytherin> AnAnt: apparently you are trying to build a i386 only package on amd64 machine
[19:38] <slytherin> AnAnt: check 'Architecture' in control file
[19:38] <AnAnt> slytherin: well, it's a source package that got 2 binary packages, one of them is Arch: i386 only
[19:39] <slytherin> AnAnt: right, that is the reason for failure
[19:39] <AnAnt> well, that's wierd, I don't remember that this failed before
[19:40] <slytherin> AnAnt: by the way, in case you haven't noticed already monajat source is in 'NEW' queue.
[19:40] <AnAnt> slytherin: oh
[19:40] <AnAnt> slytherin: there's a python re-write for it that's almost ready
[19:41] <AnAnt> slytherin: I didn't notice indeed ! I didn't get any notification
[19:41] <slytherin> LOL
[19:42] <slytherin> I don't know who exactly is recipient of notification. The usual practice is to send mail to motu ML when sponsoring a package form REVU. And I forgot to do that. :-(
[19:43] <AnAnt> thanks anyways
[19:43] <slytherin> welcome
[19:44] <AnAnt> so, back to the arch thing
[19:44] <AnAnt> are you sure  that this is right ?
[19:44] <AnAnt> I remember that I built sl-modem on launchpad before, and this problem didn't happen
[19:45] <slytherin> have you checked previous build logs?
[19:45] <AnAnt> checking now
[19:45] <therm> good evening
[19:45] <AnAnt> I just realized that this is the first time I build sl-modem for karmic
[19:45] <AnAnt> it was for jaunty before !
[19:45] <therm> someone an idea what I did wrong:
[19:46] <therm> The following packages have unmet dependencies:
[19:46] <therm>   eclipse-rcp: Depends: libswt3.4-gtk-java (= 3.4.1-0ubuntu2) but it is not going to be installed  libswtcalendar-java: Depends: libswt-gtk-3.4-java but it is not going to be installed E: Broken packages
[19:46] <therm> ?
[19:46] <AnAnt> old build logs aren't available !
[19:47] <slytherin> AnAnt: -daemon package is for both i386 and amd64, at least in jaunty.
[19:47] <AnAnt> yes, it's -source that's for i386 only
[19:47] <AnAnt> ah, I found an old build log
[19:48] <slytherin> therm: there is a conflict between libswt3.4-gtk-java and libswt-gtk-3.4-java. The former package is built form eclipse source and later is from separate swt-gtk source.
[19:49] <slytherin> therm: Unfortunately I haven't found time to make eclipse use the swt-gtk package.
[19:50] <therm> slytherin: So there is no way to build it at the moment?
[19:51] <slytherin> therm: build what?
[19:51] <therm> slytherin: jameica, thats why I am packaging all the packages like swtcalendar ;-)
[19:52] <therm> slytherin: and based on jameica -> hibiscus
[19:52] <slytherin> therm: why do you need eclipse-rcp for that?
[19:53] <therm> slytherin: Because of those jar-files:
[19:54] <slytherin> what jar files can you please be clear?
[19:54] <therm> /usr/lib/eclipse/plugins/org.eclipse.core.runtime_3.4.0.v20080512.jar /usr/lib/eclipse/plugins/org.eclipse.jface_3.4.1.M20080827-2000.jar /usr/lib/eclipse/plugins/org.eclipse.osgi_3.4.2.R34x_v20080826-1230.jar /usr/lib/eclipse/plugins/org.eclipse.ui.forms_3.3.101.v20080708_34x.jar
[19:54] <therm> sorry it took a moment
[19:56] <slytherin> sorry, can't help this time. time to hit bed. office tomorrow.
[19:56] <slytherin> see you later.
=== Adri2000_ is now known as Adri2000