=== asac_ is now known as asac
stochasticjames_w, if you have any more time, I've fixed the copyright file in http://revu.ubuntuwire.com/p/a2jmidid01:08
RainCTdirecthex: Got some time to review http://revu.ubuntuwire.com/p/mistelix? :)01:52
directhexRainCT, seems sound01:55
RainCTdirecthex: gonna give me an advocation today? :)02:00
directhexdon't think i have the button needed to do so02:01
RainCTdirecthex: Which means you should use REVU more! :P02:03
RainCTNow you have02:03
RainCTmok0!! :P02:05
RainCTdirecthex: thanks!02:51
=== vorian is now known as v
=== santiago-pgsql is now known as santiago-ve
happyaroncould someone have time have a review on http://revu.ubuntuwire.com/p/gmchess ?06:18
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 moon06:23
happyaronripps_: oh, thanks06:24
=== ripps_ is now known as ripps
hyperairripps: my experience is the reverse. i've gotten a few packages in through revu before, but none through debian mentors.07:24
hyperairripps: of course, it's better to use debian-mentors and get it synced over anyway, but that's a different matter.07:24
happyaronhyperair: I volunteer to maintain that tor package in ubuntu, how can I do that?07:55
hyperairhappyaron: er what?08:19
happyaronhyperair: I want maintain 'tor' in ubuntu, which deleted before08:48
hyperairhmm i'm not sure why it was deleted in the first place08:56
happyaronhyperair: https://bugs.launchpad.net/ubuntu/+source/tor/+bug/32844209:01
ubottuUbuntu bug 328442 in tor "Tor 0.1.2.x abandoned by upstream, update to" [Undecided,Fix released]09:01
hyperairhmm fix released?09:01
hyperairthat means it's back in ubutnu?09:01
happyaronhyperair: no ,the fix is abandoned in jaunty09:02
happyaronhyperair: I want it back, and seems it needs somebody to maintain it for ubuntu as it was said in that bug09:02
hyperairi see.09:02
hyperairi'm not sure how to go about reintroducing packages09:03
hyperairchances are you'll have to go through NEW again09:03
hyperairbasically package a new fix, stick it in revu, and such09:03
hyperairor debian-mentors09:03
hyperairwas it removed from debian?09:03
happyaronhyperair: no09:03
happyaronhyperair: I requested the sync, https://bugs.edge.launchpad.net/ubuntu/+bug/41365709:03
ubottuUbuntu bug 413657 in ubuntu "[needs-packaging] Please sync tor (universe) from Debian unstable (main)" [Wishlist,New]09:04
hyperairah. subscribe ubuntu-universe-sponsors09:04
happyaronbut they told me we need somebody keep maintain it for ubuntu09:04
happyaronhyperair: and send a mail there?09:04
hyperairwho is they?09:04
hyperairand got a link to the post?09:04
hyperairnono subscribe the launchpad team ubuntu-universe-sponsors to that bug09:04
happyaronsomebody in this channel09:04
hyperairis someone maintaining it in debian/09:05
hyperairor has it been orphaned?09:05
hyperairpackages.qa.debian.org is hating me currently =\09:05
hyperairhuh bugs.debian.org as well09:06
happyaronhyperair: there is somebody still maintains it09:06
happyaronI cannot access packages.qa.debian.org either09:07
hyperairin that case, it shouldn't be much of an issue and should get autosynced at the beginning of every release09:07
hyperairany archive admins here?09:07
happyaronhyperair: 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 bug09:09
hyperairthat's not a bug address09:10
happyaronthat's a search result in packages.ubuntu.com09:10
happyaronthis is the previous bug https://bugs.launchpad.net/ubuntu/+source/tor/+bug/32844209:11
ubottuUbuntu bug 328442 in tor "Tor 0.1.2.x abandoned by upstream, update to" [Undecided,Fix released]09:11
happyaronand this is my sync request https://bugs.edge.launchpad.net/ubuntu/+bug/41365709:11
ubottuUbuntu bug 413657 in ubuntu "[needs-packaging] Please sync tor (universe) from Debian unstable (main)" [Wishlist,New]09:11
hyperairhappyaron: yes yes can you stop reposting your links please.09:13
hyperairnow then.09:13
hyperairi've read through the bug, and it seems that the person who was involved mainly was pitti09:14
hyperairi say you sit around and wait for him here09:14
hyperairor #ubuntu-desktop09:14
hyperairand ask him *nicely* not annoyingly repeating yourself multiple times here.09:14
hyperairor email him09:14
happyaronsorry, I just didn't understand what you said in 'that's not a bug address', so I repeated the links09:15
logari81hi, I have a package which installs a python module using debhelper+pysupport09:51
logari81in jaunty the module is installed in09:51
logari81in karmic it is being installed in09:51
logari81instead. Why does this happen?09:51
maxblogari81: Because python-support has been redesigned to act in that way.10:50
iulianHow much time does it take for a new package to show up in the pools?10:57
logari81maxb: nice, it is normal then.... I don't have to worry10:58
thermiulian: "it depends" ;-)11:12
thermiulian: 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:13
maxbiulian: define "new"11:14
iulianmaxb: Synced from Debian.11:24
iulianIt seems that some buildds are busy.11:24
andviulian, as soon as it gets built it will be published in LP11:25
andvdon't worry11:25
andviulian, depends on buildd queue11:25
andvbut I guess in 3-4 hours will be done11:25
slytheriniulian: is that a new source?11:27
iulianThat odd.  Then why liblocale-msgfmt-perl hasn't been published?  bug#41258511:27
LLStarkscan i get a sense of progress on this? https://bugs.launchpad.net/ubuntu/+source/libass/+bug/41011211:28
ubottuUbuntu bug 410112 in libass "libass 0.9.7 released" [Undecided,Confirmed]11:28
ubottuUbuntu bug 412585 in ubuntu "please sync liblocale-msgfmt-perl from debian sid" [Wishlist,Fix released]11:28
LLStarksi know it's been ppa'd already, but what's keeping it from the build farm?11:28
LLStarksisn't 10 days enough for a fair evaluation?11:28
iulianLLStarks: It hasn't been uplaoded yet.11:29
slytherinLLStarks: evaluation where? Is it available in revu?11:29
LLStarksnot sure.11:29
slytheriniulian: your package is here - https://edge.launchpad.net/ubuntu/karmic/+queue?queue_state=0&queue_text=liblocale-msgfmt-perl11:30
iulianThat explains it.11:30
slytherinLLStarks: 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
LLStarksi'm the wrong person to  ask.11:33
LLStarksi'd like to think all outstanding issues are resolved.11:37
LLStarksartur, the sponsor, has a ppa package that would suggest so.11:37
* LLStarks sighs11:48
LLStarksi 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.11:49
rowinggolfercan anyone tell me if this howto is still current? https://wiki.ubuntu.com/PackagingGuide/Python12:07
rowinggolferit advocates the use of python-central12:07
rowinggolferpochu: I guess I am asking you ^^^12:08
rowinggolferpochu: great howto, but not working for my project. (openmolar on launchpad)12:09
maxbrowinggolfer: My impression is that community consensus favours python-support these days12:17
rowinggolfermaxb: that's the conclusion I am coming to also12:18
rowinggolferalthough I am struggling to find any documentation for it.12:19
rowinggolfermaxb: my problem is exacerbated by the fact that *.egg files (ie. using setuptools not distutils)12:29
rowinggolferseems to be the flavour of the month12:29
rowinggolferand yet I would like my project debs to be build in launchpad.12:29
rowinggolferI am REALLY confused at the moment.12:29
rowinggolferand would much rather be adding new features to the app itself12:29
rowinggolferas opposed to trawling through contradictory howtos.12:30
maxbrowinggolfer: Perhaps if you explain your current specific problem, or point to a failing buildlog or package that built wrongly, people here can help13:06
rowinggolfermaxb: http://launchpadlibrarian.net/30377369/buildlog_ubuntu-intrepid-amd64.openmolar_0.1.2-0ubuntu1_FAILEDTOBUILD.txt.gz13:07
c_kornhello, I am trying to create a sync request for scilab using requestsync but I get this error: http://pastebin.com/ddcfaf5113:07
rowinggolferwhen I tried to build this13:07
maxbdpkg-gencontrol: error: error occurred while parsing , , $(python:Depends}13:09
=== happyaron_ is now known as happyaron
maxbrowinggolfer: error is (somewhat) obvious :-)13:09
maxbhint: look carefully at those brackets :-)13:09
slytherinc_korn: read the last line in that error13:10
andvc_korn, you should set up your user informations13:11
andvc_korn, so that LP will recognize you when you submit the bug report13:11
c_kornslytherin: 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/SyncRequestProcess13:11
slytherinc_korn: Before that the requestsync needs to setup a cookie. Did you check manpage of manage-credentials?13:12
c_kornI 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:14
slytherinc_korn: Which password is it asking you?13:16
c_kornslytherin: 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:28
slytherinc_korn: sure, why not.13:29
rowinggolfermaxb - whoops.13:31
=== porthose_ is now known as porthose
c_kornok, thanks. I added it.13:46
c_korneh, why do I have to attach a build log ? is this always the case? https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/414410/comments/113:50
ubottuUbuntu bug 414410 in scilab "Sync scilab 5.1.1-7 (universe) from Debian unstable (main)." [Wishlist,New]13:50
geserc_korn: depends on your sponsor, Andrea wants to see a build log as a proof that you test-build the package before requesting the sync13:53
andvc_korn, I'm not at home so I can't test-build it on my own13:54
andvand anyway it's alwais important to test build packages before asking to sync them13:54
andv(packages coming from unstable to karmic of course)13:55
andvgeser, ty for the response13:55
* Laney always builds before sponsoring anyway13:55
andvLaney, if I'm not at home, I just ask to provide a build log13:56
c_kornok, 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
andvor ask my cousin's pc but he just left13:56
andvc_korn, yes13:57
andvc_korn, just add a note saying sometimes is preferred a build log13:57
andvattached at the sync request13:57
andv(if the sponsor requires it of course)13:57
andvgeser, the automated sync import is no more active?13:59
geserno, the automated sync stops at DIF14:01
slytherinandv: not since Debian Import Freeze14:01
andvtrue, ty for the info14:01
pochurowinggolfer: I guess it could use some love, but shouldn't be too far from reality14:10
=== ember_ is now known as ember
happyarongeser: hi14:21
logari81how 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:26
andvlogari81, usually all source files should have their own license header14:32
slytherinlogari81: 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.gz14:33
rowinggolferpochu: thanks. turns out the problem was me being as dense as concrete14:33
logari81andv, slytherin: ok I ll try to contact the upstream14:33
geserhappyaron: Hi15:39
happyarongeser: I have packed tor, but where to upload it? to revu?15:55
andvhappyaron, please ask your question to the whole channel15:59
andvand not to a specific person15:59
andv(of course if this specific person is not directly involved in what you ask)16:00
andvhappyaron, is that a NEW package?16:00
andvhappyaron, or a new upstream release? or what?16:00
happyaronandv: no, 'tor'16:00
happyaronandv: yes, but deleted in jaunty16:01
devfilhappyaron: what did happen to the sync request?16:01
andvhappyaron, deleted in jaunty??16:02
andvhappyaron, why?16:02
ubottuUbuntu bug 413657 in ubuntu "[needs-packaging] Please sync tor (universe) from Debian unstable (main)" [Wishlist,New]16:02
andvhappyaron, if it has been deleted from jaunty there should be a valid motivation16:03
happyaronthe bug which have it deleted was bug #32844216:03
ubottuLaunchpad bug 328442 in tor "Tor 0.1.2.x abandoned by upstream, update to" [Undecided,Fix released] https://launchpad.net/bugs/32844216:03
devfilhappyaron: 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 that16:03
happyaronthough it shows fix released, the solution is delete tor in jaunty16:03
andvhappyaron, you should talk to an archive admin about whether we should accept it back or not, I guess16:04
happyaronandv: archive admin, who are they?16:05
devfilhappyaron: please, ask to pitti16:05
happyaronok, still pitti16:05
andvhappyaron, pitti for istance, he replied on that bug report too16:05
happyaronI know16:05
andvso he will know what to do16:05
happyaronokay, thanks16:05
geserandv: 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 versions16:25
andvgeser, yeah, it seems happyaron wanna maintain it on Ubuntu16:26
andvlet's see what will happen after his talk with pitti then16:26
happyaronandv, geser I've sent him a mail, what to do might be wait for him16:30
hyperairgeser: what's the issue with just having it get autosynced from debian?16:47
hyperairgeser: there's a debian maintainer isn't there?16:48
geserhyperair: missing SRUs16:48
hyperairgeser: i mean in karmic. it's gone from karmic as well16:49
geserupstream contacted Ubuntu and asked us to remove tor from released versions as we were shipping versions abandoned upstream16:49
hyperairyes, i noticed.16:49
hyperairbut karmic isn't released is it16:50
geserhyperair: 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
hyperairno wait, aren't the debian packages maintained upstream?16:50
geserI don't know the situation exactly. I know that upstream has a repo with debs for Debian and Ubuntu16:51
hyperairthe issue was with a certain version of tor, but it's been picked up by another upstream was it not?16:51
hyperairyeah, i know that too16:51
hyperairbut taht's all i know16:51
geserhyperair: and how do we prevent that it doesn't happen again?16:52
hyperairupstream abandonment?16:52
hyperairdon't all projects undergo the same risk?16:52
hyperairespecially if it's maintained upstream by a person rather than a team?16:52
gesersay, 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 support16:53
hyperairi see, so you basically want someone to actively backport it?16:53
geser(don't know upstream release plans at all)16:53
hyperairsounds like a painful upstream.16:54
gesersomeone who takes care that karmic will have a version of tor which is maintained upstream16:54
hyperairi'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:55
geserI 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:56
geserhyperair: yes, other upstreams may have the same problem but they don't contact Ubuntu and simply ignore that problem16:58
hyperairin 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
hyperairthat'll screw around with our entire release cycle won't it?16:59
hyperairthough 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
geserwe 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 be17:00
hyperairperhaps there are additional reasons that aren't clear17:00
hyperairi 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
geserin 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 it17:01
hyperairthere are many users (like me) who want to use an old version of the package even if it isn't supported.17:01
hyperairsomething 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:02
hyperairif 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
geserhyperair: 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:04
hyperairgeser: i'm talking about if i reinstalled ubuntu and want to get back my packages17:05
hyperairgeser: there are many users who reinstall every release instead of just do-release-upgrade-ing or using update-manager all the way17:05
geseras 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 found17:07
hyperairgeser: what about the just-let-it-autosync-from-debian solution?17:08
geserhyperair: 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:09
hyperair...that's ridiculous =.=17:10
geserhyperair: that only works till DIF and after that nobody files sync requests and prepares SRU or backports -> upstream unhappy again17:10
hyperairi pity whoever has to deal with ion3's upstream.17:12
hyperairgeser: 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
andvhyperair, the latest17:13
andvi would say17:13
hyperairandv: what latest?17:13
andvhyperair, the latest phrase you said17:14
hyperairlatter you mean?17:14
andvyeah :)17:14
andvusually a lot of Debian maintainer works on ubuntu too17:14
geserhyperair: 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 LP17:14
andvso there aren't any problems17:14
hyperairokay, excluding those.17:14
hyperairgeser: that's precisely what i mean.17:15
hyperairgeser: 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:15
andvhyperair, the problem was not related to the fact they are auto-synced17:16
geserhyperair: we do it only when upstream asks us to and nobody steps up to look after the package17:16
hyperairandv: i meant just autosynced and not brought into ubuntu via any other method.17:16
hyperairgeser: well let's pray hard that we don't get any more fussy upstreams.17:17
andvhyperair, usually auto-synced packages are maintained correctly in Debian17:17
hyperairgeser: if there are enough of these upstreams, we'll have a significantly reduced pool and people will start jumping ship.17:17
hyperairandv: isn't tor maintained correctly in Debian?17:17
andvhyperair, dunno17:17
andvdidnt follow that package for a while17:18
hyperairthe PTS seems to show that it's actively maintained.17:18
andvbut from what geser said upstream directly contacted ubuntu to have old versions removed17:18
hyperairhe filed a bug, yes.17:18
andvthat's the main problem not the fact it's auto-synced17:18
andvlet's hope the guy who wants to maintain it here will do a good work then17:19
hyperairwhy couldn't we just file a sync request, and then let the next DI round bring the next version in again?17:19
andvhyperair, I guess that's happyaron's idea17:20
andvhyperair, he mailed pitti already who followed tor issue in the past17:20
geserand who looks at tor once karmic is released? that's the main problem as there nobody is/was to do it17:20
andvgeser, I thought happyaron wanted17:20
geserandv: yes, that's the plan17:21
andvoh ok, that's it then17:21
hyperairgeser: 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
andvhyperair, yep17:21
gesertor can be synced again if the archive admins are happy with happyaron maintained it17:21
hyperairand i think it's important that we give more consideration to our users17:21
hyperairthis is a one-off case that is resolved by getting a maintainer.17:22
hyperairi find it disturbing that something like this can happen.17:22
andvhyperair, luckily seems this issue is a bit rare17:22
hyperairyes, luckily, but i'd still like our users to be given greater priority.17:23
LaneyI think there was more to it than upstream support17:23
Laneyie the packages didn't work or had security holes17:23
Laneythere's a thread about it17:23
hyperairsecurity holes i think.17:23
hyperairbut i think they did work.17:23
hyperairat least in intrepid i used it17:23
Laney"unmaintained" is a bad excuse17:23
Laneyas the vast vast majority of *verse packages aren't maintained by us17:23
andvhyperair, 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
hyperairandv: i agree. i'm concerned about *ubuntu* users.17:24
hyperairall 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
Laneyif upstream maintain a deb repository of their own, and we updated the SRU policy with a specific exception for tor17:25
Laney....you see where I'm going17:25
hyperairupdate the policy how exactly?17:26
geserhyperair: we don't help our users either when we provide them old packages who nobody cared to update for security holes17:26
Laneythere was an agreement to allow new upstream releases of tor17:26
hyperairgeser: you don't help users, but at least you don't go out of your way to inconvenience them.17:27
Laneythe problem was the nobody did it17:27
hyperairLaney: so there was such a clause in the policy?17:27
geserhyperair: 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
LaneyI'm suggesting that if upstream maintain these debs anyway then they might as well maintain them in ubuntu17:30
hyperairi'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
geserhyperair: 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:32
hyperairagreed. but i'd suggest that popcon should be consulted before purging a package like that with "unmaintained" as the excuse.17:33
geserremoving a package from the development version should only be a last resort and should not be dismissed as an non-option how unpleasant it is17:38
geserof course we should try any other option before going this way17:39
hyperairbut 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
Laneyit's stable updates that are the problem17:42
hyperairimo it was remove-from-future-releases, wasn't it?17:42
Laneybut the reason was keeping it up to date in stable releases17:43
hyperairi see.17:43
hyperairimo upstream should have expended the effort of getting it backported =\17:43
hyperairfiling a backport request or something17:43
andvhyperair, it got backported to hardy17:44
geserI don't expect that upstream knows all the processes in all those distro out there (and they shouldn't care)17:45
andvand then nothing more17:45
hyperairi think if they care enough to request removal, they should care enough to go through all the procedures.17:45
hyperairotherwise just not care about requesting removal17:46
geserhyperair: do you expect that upstreams knows the backport process in Debian? or OpenSuse? or Fedora? I don't17:47
hyperairi 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
geserthey care about their software and in there eyes getting it removed was the easiest way to resolve the problem17:48
hyperairi 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
geserthey probably don't care about Ubuntu, they just want to stop the support requests from Ubuntu users using obsolete versions17:50
hyperairthey could ignore them =\17:50
hyperairor redirect them17:51
Laneythey clearly do care if they maintain their own packages17:51
geserthis discussion leads nowhere as we don't know the reasons and thinking from upstream which lead to that mail17:53
geserwe got that request and had to deal with it somehow17:54
Laneydid we?17:55
geserdid we not? there was a thread on ubuntu-devel ML what to do17:56
LaneyJust saying that doing nothing was an option17:57
Laneyand the interests of the distro and the interest of upstream aren't always the same thing17:57
hyperairhttps://bugs.launchpad.net/ubuntu/+source/tor/+bug/147987 <-- another bug referring to the whole tor issue17:58
ubottuUbuntu bug 147987 in tor "remove tor from gutsy" [Undecided,Invalid]17:58
hyperairthere's a link to a long ml thread there as well17:59
hyperairand a post from their project leader: https://lists.ubuntu.com/archives/ubuntu-devel/2007-September/024479.html18:01
=== dyfet` is now known as dyfet
nhandlerIt 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:14
AnAntHello, 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
AnAntwhy does this cause an error ?19:37
slytherinAnAnt: apparently you are trying to build a i386 only package on amd64 machine19:38
slytherinAnAnt: check 'Architecture' in control file19:38
AnAntslytherin: well, it's a source package that got 2 binary packages, one of them is Arch: i386 only19:38
slytherinAnAnt: right, that is the reason for failure19:39
AnAntwell, that's wierd, I don't remember that this failed before19:39
slytherinAnAnt: by the way, in case you haven't noticed already monajat source is in 'NEW' queue.19:40
AnAntslytherin: oh19:40
AnAntslytherin: there's a python re-write for it that's almost ready19:40
AnAntslytherin: I didn't notice indeed ! I didn't get any notification19:41
slytherinI 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:42
AnAntthanks anyways19:43
AnAntso, back to the arch thing19:44
AnAntare you sure  that this is right ?19:44
AnAntI remember that I built sl-modem on launchpad before, and this problem didn't happen19:44
slytherinhave you checked previous build logs?19:45
AnAntchecking now19:45
thermgood evening19:45
AnAntI just realized that this is the first time I build sl-modem for karmic19:45
AnAntit was for jaunty before !19:45
thermsomeone an idea what I did wrong:19:45
thermThe 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 packages19:46
AnAntold build logs aren't available !19:46
slytherinAnAnt: -daemon package is for both i386 and amd64, at least in jaunty.19:47
AnAntyes, it's -source that's for i386 only19:47
AnAntah, I found an old build log19:47
slytherintherm: 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:48
slytherintherm: Unfortunately I haven't found time to make eclipse use the swt-gtk package.19:49
thermslytherin: So there is no way to build it at the moment?19:50
slytherintherm: build what?19:51
thermslytherin: jameica, thats why I am packaging all the packages like swtcalendar ;-)19:51
thermslytherin: and based on jameica -> hibiscus19:52
slytherintherm: why do you need eclipse-rcp for that?19:52
thermslytherin: Because of those jar-files:19:53
slytherinwhat 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.jar19:54
thermsorry it took a moment19:54
slytherinsorry, can't help this time. time to hit bed. office tomorrow.19:56
slytherinsee you later.19:56
=== Adri2000_ is now known as Adri2000

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!