nad_i need help getting ati propriatary drivers to work on an ubuntu 9.10 desktop00:39
persianad_: You want to ask in #ubuntu for that00:40
RAOFThen you want #ubuntu or ubuntuforums.org, most likely.00:40
hakaishiHi everyone! Anyone up to advocate qt-shutdown-p? - It is a Qt program to shutdown the system at a certain time or after x minutes. It uses qdbus to send a shutdown request to the Gnome- and KDE-SessionManager or to HAL (as a last resort 'sudo shutdown -P now' will be used). http://revu.ubuntuwire.com/p/qt-shutdown-p01:08
zookoGreetings, folks!03:21
ddecatorhey zooko03:21
suji11hi, here is my package http://revu.ubuntuwire.com/p/iok , i couldn't understand the last comment, can anyone explain to me?03:27
rhpot1991anyone have some time for a revu?03:27
EzraRpersia: any chance you will get some time to take a second look at mangler sometime? :)04:03
suji11hi, here is my package http://revu.ubuntuwire.com/p/iok , i couldn't understand the last comment, can anyone explain to me?04:32
RAOFsuji11: You mean, the “native package” comment?04:41
suji11RAOF: yes04:41
juan__hi im reading https://wiki.ubuntu.com/PackagingGuide/Basic but seems it only explain how to package/build on packages that already are on ubuntu repo,I.E. it uses apt-get source,i want a guide for packages that are not on ubuntu repo,any link???04:43
RAOFsuji11: Normally, you get the code from the upstream developers in a .tar.gz file.  The debian/ directory is then added as a patch (the .diff.gz).04:46
suji11RAOF: oh!04:46
RAOFsuji11: You've got what is called a “native package” - the code and the packaging are both in the .tar.gz.  This is wrong, because it makes it harder to update the packaging.04:46
suji11 RAOF: ok, what i should i do now?04:47
juan__im in the right place or i need to join #ubuntu ?04:48
RAOFsuji11: Generally, what this means you need to do is to copy the upstream code tarball - which is likely to be “iok-1.3.9.tar.gz” - to iok_1.3.9.orig.tar.gz, and put it in the directory above your unpacked source (the directory containing the debian/ directory).04:51
RAOFThen debuild should pick up the original tarball, and do the right thing.04:51
arandsuji11: Upstream in this case means "original author": asking if you are the creator of the program. Secondly about the debian directory. The .tar.gz archive that comes with the package should (aside from in very special circumstances) be _unmodified_. In this case the original source archive (.tar.gz) should be simply the same as the archeve at https://fedorahosted.org/releases/i/o/iok/iok-1.3.9.tar.gz, all the changes to make it into an ubun04:54
suji11RAOF: i think before i made a mistake. i named the orig tarball as iok_1.3.9_orig.tar.gz , but now i changed it as iok_1.3.9.orig.tar.gz then  build it  again and sent to  revu.ubuntuwire.com04:54
arandsuji11: ^ In response to your question in #-devel04:55
suji11arand: i'm not an upstream author.05:00
suji11arand: what should i change in iok-1.3.9.tar.gz.?05:01
RAOFsuji11: Nothing.  It should be exactly the same file you got from fedorahosted.05:04
suji11RAOF: ok. now the problem is fixed. i'm right?05:06
zooko^-- "Tahoe-LAFS v1.6 has been accepted into Ubuntu 10.04 Long-Term-Support "Lucid"! http://allmydata.org/trac/tahoe-lafs"05:07
RAOFsuji11: Yup, that looks right.05:08
suji11RAOF: ok:)05:08
zookoOkay, time for sleep.05:09
suji11RAOF: Can you review/advocate my package.05:11
RAOFsuji11: Sorry, no.  I'm busy.05:18
suji11RAOF: It's ok. Thanks for your help yet.05:19
suji11arand: Can you review/advocate my package.05:41
arandsuji11: I'm afraid not, since I'm not a reviewer, or even part of ubuntu MOTU, one thing to note, is that this time of the day seems to be very much an off-hours time for all ubuntu channels, you might have better luck at some other time .05:44
suji11arand: ok fine.05:45
suji11arand: Thanks for your help.05:45
fabrice_spis it good or bad practice to change version from 0.<date> (for example 0.20090101) to directly date (that is 20090101) if upstream version is the date?06:13
RAOFIs the upstream version ever going to be something that's not the date?06:16
crimsunif you can future-proof versioning, it's a good idea to do so. I would leave the "0." there.06:19
crimsunthen again, there's an epoch, so it really isn't that big a deal.06:20
fabrice_spthis is the versioning scheme of upstream since 3 years, so I suppose it's a kind of  'stable'. Just for keeping it simple and thanks to epoch, I think I'll sponsor the debdiff with this version (without 0.)06:34
fabrice_spthanks RAOF and crimsun !06:34
=== ttx_ is now known as ttx
kamalmostafajames_w and/or other motu's: 'squid' is not up to date in "bzr branch lp:ubuntu/squid".  It is actually two revisions stale, which caused the person who checked in the latest revision to accidentally trash the one previous to that, causing bug 519664.07:13
ubottuLaunchpad bug 519664 in squid "squid FTBFS: dh_installinit: command not found" [Undecided,Confirmed] https://launchpad.net/bugs/51966407:13
persiakamalmostafa: technically, squid isn't in the set of stuff we can upload, so this isn't the right channel (although you've highlighted the right person to investigate I think).  If you can untangle it, I suspect a bug subscribed to ubuntu-main-sponsors would be appreciated.07:37
kamalmostafapersia: Okay, its already untangled (I've attached the simple debdiff to re-apply the missing fix to that bug).  I will subscribe u-m-s.  Thanks for the redirection.07:39
kamalmostafapersia: and maybe you could unsubscribe u-u-s for me?07:40
persiakamalmostafa: Sure.  Running rmadison can help you determine the component for any package.07:43
kamalmostafapersia: I knew it was in main -- just got distracted when I realized i should notify james_w and did my usual "u-u-s" procedure without paying attention.  Thanks for the rmadison tip anyway.07:45
persiaUm, please stop posting that in various places.08:48
tolonugais there any way to get a totaly broken package in ubuntu fixed before release/freeze/etc? I have a complete patch and several independend test results of it, so you only need to get the tar.gz and diff.gz, create an changelog entry, push it out and it would be done.09:37
tolonugapackage name:openct. fixed package here: www.opensc-project.org/debian/ (upstream website).09:38
tolonugaimport from debian wont' work - debian didn't fix the package either (still using "hal" setup - which won't work on ubuntu, as hal was dropped)09:38
persiatolonuga: File a bug against the openct package in Ubuntu, describing the issue (or find one if it is already filed).  Attach the patch.09:44
persiaIf you want to wear an Ubuntu Developer hat, which might make it happen faster, add the patch and changelog entry, etc., build a new source package, and attach the debdiff.  The revision for the new entry should be -1ubuntu1.09:45
persiaSubscribe the bug with the debdiff to ubuntu-universe-sponsors.  If you have questions during the process, ask here.09:45
om26eris there a manual way of making a binary package(not using pbuilder)10:00
sistpoty|workmake -f debian/rules binary10:01
om26ersistpoty|work, thanks will try10:01
tolonugasorry, keyb broken, had to reboot.10:05
tolonugapersia:thanks for the help!10:05
tolonugadone - added my diff.gz, or an interdiff if that is preferered, and added ubuntu-universe-sponsor to cc:10:05
persiaThe orig.tar.gz differs?10:06
tolonugano, only the diff.gz10:08
tolonugawell, new version of orig.tar.gz (version 0.6.17 -> 0.6.19)10:08
tolonugakeep "unstable" in debian/changelog or replace it with "lucid"? (with "lucid" I get an error/warning form debuild -S...)10:10
slytherintolonuga: lucid is correct10:11
tolonugahmm, how does an debdiff file help? in it I see all the upstream changes 0.6.17 to 0.6.19 - guess that isn't much help.10:13
tolonugaok, everything implemented as suggested. can anyone look at bug 519713 and push the fixes into ubuntu?10:17
ubottuLaunchpad bug 519713 in openct "package outdated" [Undecided,New] https://launchpad.net/bugs/51971310:17
tolonugahmm, a better title would be "package outdated and totaly broken" ...10:19
slytherintolonuga: When working on new upstream version .diff.gz needs to be attached. But if you are working on a new Ubuntu revision then .debdiff is preferred.10:20
tolonugaok. the diff.gz is the first attachment, so that is already there. it has "-0" in it, but you can easily change that and push it out?10:21
tolonugaalso I'm looking for someone to import latest opensc package from debian into ubuntu. the ubuntu changes to the older package can be dropped (a fix that is included in the new upstream and thus no longer needed). can anyone do that too?10:21
slytherintolonuga: for requesting syncs, the easiest method is to use requestsync tool. It fetches the changelog entries and you can provide reason to drop ubuntu changes.10:23
tolonugaok,will have a look10:24
=== ogra_ is now known as ogra
tolonugaok, sync request send with that tool.10:39
om26erwhere are the .deb file created10:42
tolonugahmm. is that a regression? an important bug has been fixed in opensc 0.11.8-1ubuntu2 in karmic, but the lucid package 0.11.9-2ubuntu1 does not contain the fix.10:43
tolonugaif unchanged, lucid would be a regression compared karmic with fix.10:43
persiaThat would be a regression.  If the patch isn't in Debian already, go catch your sync bug before it gets ACKed, and change it to a merge bug.10:44
persiaFor merges, we prefer a debdiff against the revision in Debian (as we'd use the Debian orig.tar.gz)10:45
tolonugadebian testing has the new version and thus can be imported without any change - the ubuntu fix was a backport from the official 0.11.12 which fixed the issue.10:45
persiaSo a sync would make it not a regression, and the other stuff added to 11.9-2 is also in 11.12?10:47
sistpoty|workom26er: one directory above10:47
tolonugayes, the sync will remove the regression and fix other things and add the latest features from 0.11.12. a win for everyone!10:51
AnAntHello, when's the next sync ?10:58
persiawhenever the archive-admin-of-the-day happens to run the autosync script.10:58
AnAntpersia: how frequent is that ?10:59
persiaDepends on the day.  Sometimes once a day, sometimes twice, sometimes not at all.11:01
AnAntwell, swt-gtk has entered testing few days ago, yet it isn't in lucid yet11:01
AnAntswt-gtk 3.5 that is11:02
persiaMaybe it's stuck in the NEW queue.  Have you checked that?11:02
persiaNo, that's not it.  Just a matter of not having a sync run.11:03
persiaWell, there should be a sync run that happens before DIF, so I wouldn't worry.11:03
persiaIf it still isn't present by Friday, file a bug.11:03
AnAntDIF is on friday ?11:04
persiaNo, DIF is on Thursday, but there are archive admins all over the world, so to avoid getting into an argument about which day of the week is the right day, best to leave some slack.11:04
AnAntpersia: ok, regarding LP #511069, should I set this to confirmed again , since swt-gtk 3.5 should get sync'ed ?11:06
ubottuLaunchpad bug 511069 in zekr "Sync zekr 0.7.5~beta3+repack-1 (multiverse) from Debian unstable (non-free)" [Wishlist,In progress] https://launchpad.net/bugs/51106911:06
persiaAnAnt: Wait until it's actually present.11:07
persiaDIF doesn't mean we can't sync, it only means that it won't happen automatically.11:08
geserisn't FF already next week?11:14
persiaYes.  The 18th.11:16
persiaI have a deep suspicion that after the demand over the next week, the archive-admins will never again agree to such a close relation between DIF and FF.11:16
* Laney is going to be going sync crazy with the new GHC transition :)11:18
Laney(if it is oked)11:19
persiaLaney: Why do you need OK, will it not start until after DIF?11:19
persiaOtherwise I'd expect something to slip in, so that we didn't have a choice.11:19
Laneyit won't, and it will bleed over into FF11:20
persiaOh, lovely.11:20
AnAntLaney: is that haskell ?11:20
AnAntI tried to prepare a haskell package once, and failed11:20
Laneyyou should come to #debian-haskell11:21
AnAnttoo many dependancies, flavors11:21
AnAntLaney: I did11:21
AnAntLaney: and they removed debhelper support11:21
AnAntthat was sad11:21
Laneyright, cdbs is the normal way11:21
Laneyjust copy an existing library11:21
Rhondapersia: When is the final sync freeze? I think I need to request another one for ejabberd, fixing a CVE.11:23
Laneybug fix uploads are almost always OK11:23
Laneyup to final freeze, then they need to be serious and minimal (security will still be alright)11:24
RhondaLaney: … "up to the final freeze" which is when? :)11:26
Laneyhttps://wiki.ubuntu.com/LucidReleaseSchedule <- april 15th11:26
RhondaAlright, I look it up myself11:26
Laney(maybe later for universe)11:27
RhondaThought you'd know it out of the head, sorry for making you hunt for it.11:27
Laneyit's alright, the release schedule is in my history11:27
slytherinLaney: Did you see the build log I sent yesterday11:29
Laneyslytherin: yes, thank you. Unfortunately the interesting part was just after that step :)11:30
Laneybut no worries, somebody else tried it on a ppc porterbox for me11:31
geserslytherin: do you know if could/should sync jabref? from a quick look at the changelog it looks like the ubuntu delta got included in the debian package (in unstable)11:36
geserbut as the version string contains beta I'm not sure if we should sync or not (a sync would also allow to move it into universe)11:37
slytheringeser: I am not very keen on syncing beta version.11:37
geserok, so we keep then 2.511:38
\shdholbach: when do you update http://qa.ubuntu.com/reports/sponsoring/ ? every hour or once a day?12:00
dholbach\sh: every 15 minutes12:01
\shdholbach: cool. thx :)12:01
dholbachonce the list is smaller again I can update it more often ;-)12:01
\shdholbach: working on it ;)12:02
filiphi, I have a problem with debconf (db_subst). This setup: http://pastebin.com/mb1f7802 doesn't work (suggested value is "${default}")12:10
filipit seems to be done according to the debconf manual...12:10
slytherindholbach: Did you get my message in #ubuntu-kernel? My IRC client is giving weird error.12:42
slytherinnever mind found the problem12:43
dholbachslytherin: nope, didn't get it12:44
slytherinmy nick was not identified. :-)12:44
\shdholbach: could you sponsor bug #506908 for torsten spindler? (provided an updated debdiff, so it follows our standards) (it's main, as it was wrongly added to universe sponsor queue it seems)12:48
ubottuLaunchpad bug 506908 in pcsc-lite "Upstart job for pcscd" [Undecided,In progress] https://launchpad.net/bugs/50690812:48
dholbach\sh: I'd prefer if somebody would sponsor it who has actually looked at an upstart job before because I haven't :)12:49
\shdholbach: for me the upstart job looks very much ok and very clean :) but I'm not keybuk ;)12:50
\shanyways subscribe main sponsors12:50
dholbachthanks \sh12:51
\shdholbach: your expertise, should we fix those debdiffs, or just unsubscribe sponsors and waiting for bugfixer coming back with a correct debdiff ? (bug #368017)12:53
ubottuLaunchpad bug 368017 in fet "Wrong description" [Wishlist,Confirmed] https://launchpad.net/bugs/36801712:53
dholbach\sh: I'd prefer if we would just add the changelog entry, upload and be done with it - extra points for a small message saying "this is how I produced a debdiff"12:54
* persia would prefer that the sponsors queue wasn't so strongly recommended to all and sundry arbitrary patch authors, and that we had a better way to catch patches.12:55
dholbachwhy less recommended?12:55
persiaBecause I don't think there should be any expectation of any relation between people who submit patches to launchpad and people who care about uploading to Ubuntu.12:56
dholbachwhat does that mean?12:56
persiaThe "right way" to get something into Ubuntu shouldn't have to involve making a debdiff, although I think the "right way" for someone to do sponsored uploads to Ubnutu should.12:56
dholbachif we would put more work into getting all the bugs with patches closed, we wouldn't need the sponsoring process12:56
persiaI disagree vehemently with that statement.12:57
persiaTo me, the sponsoring process is a way that those who wish to become Ubuntu Developers can demonstrate their skills before being granted upload access.12:57
dholbachI don't think it really matters12:57
dholbachwe should be better at spotting fixes and making Ubuntu better12:58
persiaI see no relation between this and any activities related to processing patches that fix bugs, except insofar as I expect Ubuntu Developers (both current and prospective) to look for patches and get them uploaded.12:58
dholbachif somebody wishes to apply, they're happy to do that12:58
dholbachand I encourage them12:58
\shI do understand persia...12:58
persia\sh: Thanks.  Sometimes it seems that nobody bothers to think about what I write :)12:59
dholbachit's a distinction which doesn't make the world exactly easier - the bigger problem we have is that there's not enough people willing to get the 2000 bugs with patches reviewed12:59
\shthe problem with debdiffs from "non wanna ubuntu devs" is that they are on the merger list for the next cycle and nobody will take care until DIF and sometimes it's too late12:59
persia\sh: There's that.  There's also that patch submitters get annoyed with the frustrating processes and complain about us.13:00
dholbach... and I didn't disagree with that13:00
* persia doesn't want to bother spending effort training anyone to follow Ubuntu processes unless they have an interest in being part of Ubuntu, rather than just submitting bugfix patches13:00
dholbachpersia: and I didn't say you should13:00
persiadholbach: No, but my argument is that conflating "sponsoring" with "patch review" implicitly makes it awkward to distinguish between the two classes of patches.13:01
persiaSo I'd much rather see random folk told "attach a patch in a bug in LP", and have developers (both current and prospective) hounded to get those patches in.13:02
dholbachright, it's just that the distinction between to me is much less important than getting the 2000 bugs with patches closed or tended to :)13:02
persiaAnd I think that's separate from supporting people who can do the work but just can't upload yet.13:02
dholbachin both cases it's stuff we want to get into the distro to make it better13:03
persiadholbach: I understand.  I even agree that it's less important.  I'd just prefer that there was more focus on looking for the patches, and less focus on telling people to use the sponsoring process.13:03
dholbachok, good - I probably should have said "in an ideal world we wouldn't have 2000 bugs with patches to tend to and wouldn't have to have a process which makes getting patches looked at more complicated than it should be"13:04
dholbachin the meantime, until we can tell patch submitters apart from each other (willing to learn more about ubuntu development or not), I'd suggest attaching your debdiff to the bug, so they can take a look at it, but not block on "attaching a debdiff"13:05
persiaThat's close to my view, but if you don't consider the sponsoring process to me the process for getting patches looked at, then you don't have that issue.13:05
persiaSo, I7d rather say that the sponsoring process is *only* for prospective and current Ubuntu developers, and have the patch submisison process be as simple as ticking a checkmark on LP.13:06
persiaIf you want to get more people looking at these 2000 patches, have them look there, rather than fussing with the sponsorship process in a way that makes it harder to train new developers.13:07
dholbachwe don't even cope well with the n+1 sponsoring items we have13:08
persiaSure, but tossing those into the mass of unlooked-at patches only makes it worse, in my opinion.13:09
persiaIf the sponsoring queue only contained stuff that was written by people who are now, or are seeking to be Ubuntu Developers, the quality should rise, and that should make it less annoying to sponsor stuff.13:09
dholbachI wasn't saying "let's get rid of the sponsoring queue"13:10
dholbach... now13:10
persiaThat said, we *do* need an active team to be chasing the 2000 patches, but I don't think any of them should be subscribed to the sponsors queue: that just complicates the process for submitters and frustrates sponsors.13:10
dholbachRealistically, the sponsoring queue is where 90-95% of patches/branches from LP come from.13:12
persiaI don't think so.  Only about 10% of patches are currently shown on your list.13:12
persiaBut even were that true, I'd argue that we should be focusing on making that not true, rather than trying to push more patches through that mechanism.13:13
dholbachsorry, I was unclear13:13
dholbachI meant to say that 90-95% of the branches/patches form LP that go into Ubuntu come through the sponsorship process13:14
persiaRight.  My argument is that this represents a failure of Ubuntu Developers to dig up patches properly.13:14
dholbachyes, I'd very much like to see a solution to that problem13:14
persiaI'd much rather see strong focus on getting more developers to be proactively searching for patches than to push more patches into the sponsorship queues.13:15
dholbachDo something!13:15
persiaBecause lots of developers don't need to get sponsored, and so it is wasteful to push it in the queue.13:15
persiaSo, if we say that the process for getting a patch reviewed is to stick it in the sponsors queue we 1) make the process complicated and 2) don't tell developers to go hunt patches.13:16
persiaIf we say that the process for getting a patch reviewed is to attach it to a bug in launchpad, we 1) make the process easy, and 2) are in a stronger position to tell developers to go hunt patches.13:17
dholbachwere you in the fixing-bugs-with-patches session at uds?13:17
persiaIf some developer fixes something and can't upload, we can fall back to the sponsors queue.13:17
persiaI've tried to attend that session for the past 4 UDSs.13:17
persiaI don't know if I was in the one you mean now.13:17
dholbachthat blueprint is the best place to discuss this :)13:18
persiaWhat7s the URL?13:18
\shlast uds was usa now this time of the year is back in europe ?13:18
persia\sh: Probably.  It seems to mostly swap between those two and never come here :)13:18
dholbachand I think you were13:19
dholbachbut anyway, I need to head out now13:19
dholbachsee you later13:19
persiadholbach: I agree with just about everything on that blueprint except that I don't think it's related to sponsoring :)13:21
oojahAs an outsider looking in, from what I've read I'd expect the sponsorship queue to be for people that don't have upload rights to a particular component, mostly likely because they're a prospective developer but also possibly because they want to fix something in main and only have universe rights.13:24
persiaoojah: It's also important for people working on the edges of package-sets.13:26
Davieyoojah: yes, but also enables better peer review.13:26
persiaDaviey: Well, except we've historically rejected submissions by those who could upload :)13:27
persiaFor peer review, we tend to just ask in IRC for someone to look at a debdiff or something.13:27
Davieywhich is less than ideal IMHO13:27
persiaDaviey: Well, I think the idea was that peer-review happened post-upload :)13:28
Davieywhich is much much less than ideal :)13:29
persiaWe can generally fix each other's mistakes, and sometimes changelogs end up looking interesting (ubuntu-dev-tools for the security/deprecated schroot.conf lines, or the old nvidia-settings package were two cases I was involved with)13:29
persiaI guess, but with the package:developer ratio being as high as it is, it tends to be faster (as most of us ask if we need and don't make too many mistakes otherwise)13:30
oojahRight, ok on both counts.13:30
_stink_hey folks.  i have an upstream package that has its source split into directories named client/, server/, utils/, etc.  I want my rules files to only build what's in client/.  Manually I can cd client/; make and it works fine, but it seems that no matter what i try in the rules file, it *always* tries to make everything.  any idea how I build only one subdirectory in a source package?13:53
sistpoty|work_stink_: "make -C client" instead of calling "make" in rules?13:55
_stink_ahhh yes.  -C.  duh me13:55
_stink_sistpoty|work: thanks!13:55
persiaUsing dh(1), one can also pass --sourcedir client to dh to acheive a similar result.13:58
aboganiHi All, I have a simple question for you. I'm working on packaging of new software which depend from avr-libc. Meanwhile I'm working on my stuff I have noticed that avr-libx seems don't be FHS compliant. Is it possible?14:06
aboganiCould header files be placed into /usr/lib/avr/include ?14:08
aboganiDon't should be /usr/include/avr a better place? ?14:08
persiaChanging stuff to be FHS compliant is always good.  That said, one has to look at all the rdepends to make sure they won't break (and reverse-build-depends for libraries).14:11
persiaThis often ends up being a fairly sizable transition, and is often best coordinated also with any Debian maintainers and upstream.14:11
kmdmDon't suppose anyone has the command to hand to sign a .changes file? (Mind's gone blank on me :( .)14:24
jpdskmdm: debsign?14:25
kmdmjpds: Perfect, thanks ;)14:26
bjsnidersiretart, ping14:29
siretartplease avoid contentless pings. I don't like them14:40
bjsnidersiretart, is ffmpeg fixed upstream? when i refreshed it and installed the packages, it broke everything14:41
bjsnideri'm sure it was from the master branch14:41
siretartplease be more specific. what breaks exactly?14:41
bjsnidermplayer complains about not being able to find libavutil shared libs, and the gstreamer ffmpeg package loses track of the codecs it needs14:42
siretartmplayer: really libavutil and not libswscale? pastebin please.14:43
siretartgstreamer: no idea, please ping slomo and/or bilboed14:44
bjsnideralright, hold on aminute i'll have to reinstall the stuff14:44
bjsnidermplayer: error while loading shared libraries: libavutil.so.49: cannot open shared object...14:46
=== dholbach_ is now known as dholbach
siretartmplayer depends on libavutil49 which provides that lib. if you removed it, then your packages and/or system are broken14:47
bjsniderlibavutil-extra-49 is installed here14:47
siretartthen check why mplayer fails to find libavutil.so.4914:48
bjsniderwell, the library version is no lnger 49, it's named 5014:50
bjsniderdo i have to rebuild everything that might possibly use ffmpeg for this to realistically work?14:50
bjsnideri planned on refreshing mplayer, but not necessarily much else14:50
siretartif you are using the mplayer package from lucid, then it depends on libavutil49 and that must be installed14:50
siretartdepends declares a hard dependency. period14:51
bjsniderthis should actually be renamed to libavutil50. i can't have my cake and eat it too where both 49 and 50 are there at the same time can i?14:52
siretartthe point of the excercise of soname handling is that you can have both libavutil49 and libavutil50 installed at the same time14:52
persiaIt's much preferred not to provide eaten cake, as this requires significantly more maintenance overhead.14:52
sistpoty|workpersia: shared libraries must be made to coexist, otherwise bad things happen.14:53
bjsniderthen if i renamed all of my ffmpeg packages, so they didn't upgrade over the karmic ones, this would work14:53
sistpoty|workpersia: just assume libc7 would conflict with libc6 ;)14:53
persiasistpoty|work: I agree that foo.so.1 and foo.so.2 should be in the libfoo1 and libfoo2 packages, but I'd prefer to just have libfoo-dev, and tell everyone to rebuild the world :)14:54
siretartyou'd still have to change the SONAME of all libs (which is nontrivial) and change shlibs file to match that change (trivial)14:54
bjsnidersiretart, how do you mean change the SONAME?14:54
siretartpersia: that's what happening with ffmpeg, BTW.14:54
persiasiretart: Right.  My comment about eaten cake was an argument against providing libavutil49-dev and libavutil50-dev, but apparently insufficiently clear.14:56
siretartbjsnider: sorry, please read up on that yourself. Try levine's book Linkers and Loaders, chapter 10. I'm currently at work14:56
siretartpersia: agreed14:56
=== RoAk is now known as RoAkSoAx
bjsnideroh, i see what you mean by soname. but that's already changed int he -49 packages. they've already been bumped to 5015:03
bjsnidersiretart, thanks for the help. sorry for being a pest.15:05
siretartbjsnider: sorry for being so rude, I'm as said at work and your question are quite confusing to me TBH15:05
bjsnideri have to invent my own terminology because i don't have a programming background15:11
persiabjsnider: The encouraged alternative is to ask lots of stupid questions in appropriate fora until you are using the same terminology :)15:12
persiaErr, s/stupid/potentially apparently stupid/15:12
bjsniderpersia, yes, that's exactly it...15:13
bjsniderwhat i don't understand is, if a package is looking for a shared lib version 49 for instance, but version 50 is there instead, why doesn't it pick that up and talk to version 50?15:14
persiabjsnider: You might find running nm against your binaries to be instructive, or review any of the MOTU/School library packaging sessions documented on the wiki.15:18
=== asac_ is now known as asac
geserbjsnider: from where should the app know how to talk to version 50 if it only knows how to talk to version 49?15:33
persiaMight be clearer if we remember that the differences here aren't just arbitrary versions, but rather represent differing ABIs15:34
bjsniderpersia, but would the abi be so different that breakage would result?15:36
bjsnidergeser, why does it only know to talk to -49? why can't it look for any version to talk to?15:37
geserbjsnider: imagine the app provides a 32bit int and the lib expects a 64bit one at that location15:37
bjsnideror is it that th abi is so different that it wouldn't matter15:37
geserbjsnider: from the headers for the lib it was compiled with15:37
geserbjsnider: the difference might be small or big depending on what exactly has changed15:38
persiabjsnider: The ABI breakage is sufficient that applications compiled against the old version will experience some problems.  The nature of these problems depends on the nature of the change.15:39
persiaThere are many ways to change ABI without changing SONAME, but when SONAME changes, there's usually no going back.15:39
kreuterhowdy, #ubuntu-motu.  does upstart support running daemons under uid/gid other than root?16:40
persiakreuter: I *think* so, but it might require trickery.16:42
persiaYou might ask in #ubuntu-server: they tend to try to put stuff in chroot jails *and* use upstart.16:42
kreuterhm.  okay.  thanks!16:44
rmunnCan I get a MOTU to look at http://revu.ubuntuwire.com/p/python-nltk? I believe it's ready to go into Lucid now, it just needs advocates.16:45
persiarmunn: DEP5 calls for a separated License: stanza when using the same license in multiple Files: stanzas (PSF-2)16:47
persiaAnd I've not seen debian/clean before.  Nifty :)16:47
rmunnpersia, What do you mean by a separated License: stanza? I don't quite follow.16:50
persiahttp://dep.debian.net/deps/dep5/ : see the bit about "Standalone License Section"16:51
rmunnpersia, I wanted to do "Files: nltk/a.py, nltk/b.py, nltk/c.py \n License: PSF-2" but didn't read the spec as allowing that.16:51
\shhmm..well...the universe taggeed sponsor queue looks more empty now regarding dholbachs new page16:52
rmunnpersia, Ah, I understand now. So basically, I just need to add a single newline and a new "License: PSF-2" line that's standalone.16:52
persiarmunn: I think you can do that, for the same license and copyright, etc.16:52
persiae.g. Files: "Program Files/*", manual[english].txt16:52
rmunnpersia, Should I do that now and re-upload, or wait until you're done looking at the rest of the revu entry so there's only a single new upload?16:53
persiaBut I don't think you can do it for this source, because the Copyright lists differ16:53
rmunnpersia, Ah yes, that was the problem -- different copyrights.16:53
persiaOh, just reupload it.  I don't see anything else obvious, except that I would have used rules.tiny and debhelper 716:53
rmunnpersia, Been a week since I started working on this, so I'm forgetting some of the details of what I did at first. :-)16:54
rmunnpersia, It's my first package, I used CDBS because it seemed easier to get started with than debhelper. Never heard of rules.tiny -- where can I read about it?16:54
persia/usr/share/doc/debhelper/examples/rules.tiny and `man dh`.16:55
persiaBut actually, you need to patch it, so you'd have to do something like --with-quilt, and then reformat the patches, etc.16:55
persiaJust leave it CDBS.16:55
\shbddebian: ping mush you filed a removal request in debian for this package :)16:56
\shbddebian: dead upstream, dead maintainer, dead what?16:56
sebnerpersia: rmunn or you upgrade to debsrc3.0 so you also don't have to worry about patching ;)16:57
rmunnpersia, Uploading, should show up on REVU in 5 minutes16:57
persiasebner: Well, kinda.16:57
Laneyoh, while I remember, does anyone know of a way to specify arch-indep build rules with DH7?16:57
LaneyI don't know of a convenient way to have my docs only built when building the arch:all package16:58
persiaLaney: What are you trying to accomplish?16:58
rmunnsebner, Is debsrc3.0 available on Karmic, or should I switch to my Lucid virtual machine for building packages from now on?16:58
sebnerrmunn: debsrc3.0 is only available for lucid and newer16:58
bddebian\sh: NPOASR (Never part of a stable release) :)16:58
sebnerhuhu bddebian :=16:58
rmunnSo far the only downside I've found to building packages on Karmic is that lintian thinks "lucid" is an invalid Ubuntu version name.16:58
Laneypersia: some processing is required to generate html documentation, but it's wasteful to do it everywhere16:58
sebnerrmunn: you can upgrade to lucid lintian version16:59
persiaLaney: Compare `dh binary-arch --no-act` to `dh binary-indep --no-act` in your source package.  The sequences should differ slightly, and this may help you figure out how to make it work.16:59
RoAkSoAxhey guys anyone know if dput to PPA's is broken?17:00
persiaRoAkSoAx: Ask in #launchpad17:00
RoAkSoAxpersia, will do :)17:00
rmunnpersia, New upload is up at http://revu.ubuntuwire.com/p/python-nltk, thanks for the feedback on DEP517:01
\shbddebian: well, the whole package is horse-dung ;)17:02
rmunnlintian still warns me about "build-depends-without-arch-dep python-yaml", but python-yaml is required for the "clean" operation (because setup.py ends up importing something that imports it) so I can't get rid of that warning.17:02
Laneypersia: Actually, they differ in that -a is passed for the arch build, and -i for the indep, and that dh_strip, dh_makeshlibs, dh_shlibdeps are not invoked in the indep case17:03
Laneyso I don't see anywhere to hook in there :(17:03
persiaLaney: Do you have different targets available in the upstream build system?  You could do something with override_dh_auto_build:17:04
LaneyNo, I don't use their buildsys17:05
persiaHow do you build it?17:05
LaneyI just have to run agda on one file17:05
persiaCould you point me at your debian/rules?  That might make it easier for me to critique it :)17:06
bddebian\sh: Agreed :)17:06
Laneyyes, I'm getting to it... git.d.o is being slow17:07
Laneypersia: http://git.debian.org/?p=collab-maint/agda-stdlib.git;a=blob;f=debian/rules;h=b23dfc54e31fab28f5087290350b11bb5c556557;hb=HEAD17:07
\shrmunn: did you try Build-Depends-Indep, you don't build any arch dependend stuff in it...topic 7.7 in http://www.debian.org/doc/debian-policy/ch-relationships.html17:09
rmunnHaven't tried yet, but 7.7 says Build-Depend must be satisfied when clean is invoked. Running clean runs "python setup.py clean", and upstream's setup.py does "import nltk", which in turn does "import yaml" -- so if yaml isn't around, "setup.py clean" fails with an ImportError.17:12
\shrmunn: or you find a linitan bug...17:12
rmunnSo since python-yaml is required for the clean step, I followed policy and put it in Build-Depends.17:13
\sh"The matrix is based on rules, you can't break the rules, but you can bend them" ;)17:13
\shin the end, you found a lintian bug ;)17:13
sistpoty|workrmunn: iirc build-depends-indep aren't installed on clean, even though policy says otherwise17:17
persiaLaney: Sorry.  Got distracted.17:17
Laneyno worries17:18
\shsistpoty|work: I think lintian is right, because python-yaml (the module) is not actually seen by linitian but python is...false positive17:18
persiaLaney: If you use sbuild, you might try showing the environment variables in override_dh_auto_build with and without -A and see if you can find a useful difference.17:19
* persia suspects there's a way to do this with pbuilder, but doesn't know the details.17:19
LaneyI fear that we get into the realm of "more trouble than it's worth"17:20
LaneyI could just make a binary-indep target and do my building in there17:20
persiaLaney: Fine.  I'll get the variable :p17:20
Laneybefore "dh binary-indep"17:20
sistpoty|work\sh: sounds like it, yeah17:21
Laneypersia: Something like this — http://paste.ubuntu.com/373360/17:23
persiaLaney: I'm not convinced that works with dh: man dh17:24
persiaOh, "binary-indep" rather than "build-indep".  Right, yes.17:24
persiaI'd probably do it with an override_dh_binary_indep: rule that depended on a documentation: rule and called dh_binary_indep internally.17:25
* Laney knows not about dh_binary_indep17:25
persiaErr, except that wouldn't work, and I'd end up doing it your way :)17:25
Laneylet's fire off a test build17:28
maxbLaney: The most palatable way I've found is to put the conditional in shell:   if dh_listpackages | grep -q '^mybinaryindeppkg$$'; then .....17:28
persiaI like manually defining build-indep: better than that.17:29
* Laney too17:29
sebnerLaney: I'm wondering about your (old) --before --after stuff too17:29
Laneysebner: how would you do it?17:29
Laneybear in mind that the binary-indep target runs the whole debhelper sequence17:30
sebnerLaney: I don't know about that indep stuff but we also had this --before and --after stuff with old debhelper (e.g configure) so I'm wondering if you can just make ist like the new way17:30
LaneyI don't know how. And there are bound to be cases where defining the targets is still useful... maybe this is one of them17:31
sebnerLaney: I'll give it a try later too17:32
\shI thought dh7 should make lifes easier ;)17:32
Laneythis --before and --after stuff is really just a condensed way of writing out all of the dh_* commands in a pre-dh7 style rules file17:32
Laney\sh: I do think this is easier than the old way really17:33
\shLaney: depending on your training imho..17:34
Laneyof course, some people don't use debhelper at all :)17:34
persiaGrr.  echo ${ENV} didn't do what I wanted.17:35
\shLaney: actually cdbs is also a black hole for me...people should know what the tools are doing so they understand the whole system...without knowing the old school you don't understand the new school ;)17:36
Laney\sh: ha, when using cdbs I end up reading the source more often than not17:36
Laneytrading surface simplicity for below-the-surface complexity17:37
\shLaney: well...beginners don't and even when they do that, they wouldn't understand much ;)17:38
rmunnWell, moving python-yaml into Build-Depends-Indep: instead of Build-Depends: seemed to make no difference as far as pbuilder was concerned... should I re-upload http://revu.ubuntuwire.com/p/python-nltk with a new debian/control even though that seems to be against (my reading of) Debian policy section 7.7?17:39
sistpoty|workfor a lesson, I tried to package completely without helpers. funnily I almost got it right on the first try17:39
Laneyrmunn: pbuilder always builds arch-indep afaik17:40
\shsistpoty|work: do you remember ajmitch' lesson when we opened ubuntu-motu-school long time ago? :)17:41
persiaRight.  The make manual fails me.  If anyone has a good command that prints out the entirery of the environment from within make, I'm happy to test to see if there's an arch-indep solution.17:41
sistpoty|work\sh: right, probably I got the idea from him ;)17:41
rmunnThis is my first "real" package (as opposed to following along with the exercises during ubuntu-classroom sessions) so I've reached the limit of my knowledge so far.17:41
\shrmunn: as said, you hit a false positive..for linitian python-yaml is not existent, but setup.py which is executed during clean needs it ... for linitian only python is a needed build-dep...file a bug on linitian ;)17:42
Laneyfrom reading /usr/bin/dh, I don't think that binary-indep even does any building17:42
Laneyso I don't know if --before dh_auto_build will work17:42
rmunnIt seems like http://revu.ubuntuwire.com/p/python-nltk is almost ready, and I'd like to get it into Lucid before Feature Freeze -- but I don't know the right answer to this Build-Depends/Build-Depends-Indep problem.17:43
LaneyI could just build the docs and then dh $@17:43
slytherinis there any reason why 'dh_install --fail-missing' wouldn't report error on i386 buildd but reports problem everywhere else.17:43
rmunn\sh, Okay, so no changes needed to debian/control? Great, that means I *might* be finished with repeatedly re-uploading to REVU now... :-)17:43
rmunnUnless another MOTU comes along and points out yet another newbie mistake of mine... :-)17:44
Laneyslytherin: something to do with b-d-i?17:44
\shrmunn: please document this "behaviour" somewhere in revu and file a bug against lintian (debian + ubuntu)17:44
\shslytherin: arch indep files? which are only build on i386?17:45
rmunnAlready mentioned it in one part of one of my REVU comments, but I'll put it in a separate comment so it's easier to see.17:45
james_wthat's not a lintian bug17:45
\shjames_w: then?17:45
james_wit should be an override in the package if you care about it17:45
slytherinLaney: There are no b-d-i17:45
Laneyis there an arch:all package?17:46
slytherin\sh: The files are simply being copied.17:46
slytherinyes the problem happens with -doc package17:46
\shjames_w: that's something to override lintian false-positives...17:46
slytherin\sh: Laney: here is the relevant code - http://paste.ubuntu.com/373371/17:47
james_w\sh: and this isn't one of those?17:47
\shrmunn: but james_w is right...prepare a lintian override for this message17:47
Laney\sh: So you put the files in place and then presumably they will only get installed when doing an arch-indep build17:48
Laneyerm, slytherin. sorry \sh17:48
\shjames_w: if it is an reported lintian error, I would say it's a bug of lintian, if it's just a warning, I would say the way to go is an override17:49
slytherinI didn't do it. I am just looking at FTBFS. :-)17:49
Laneywell "the build" then17:49
LaneyI'd just copy the files from their location in the source tree instead of doing that cp at all17:49
slytherinLaney: Perhaps you are right. I guess I will change it to --list-missing17:49
\shjames_w: as this is an informational message, override is appropriate17:49
sebnerslytherin: I'm wondering about the --fail-missing option. doesn't install fail anyways when a file is missing?17:50
\shrmunn: prepare an lintian override for this warning in your package...and file a bug against revu to not declare an info as common error, ;)17:50
Laneyno, it fails the build when you forget to install a file into a binary package17:50
slytherinsebner: No --fail-missing means if the file is not included in the resulting package.17:50
sebnerah ic17:50
Laneypresumably it could be made more clever though17:51
Laneyif no _all package then ignore stuff under /usr/share17:51
* Laney -> home17:53
sebnerLaney:  bye17:53
persiajames_w: Why isn't it a lintian bug again?  Lintian is suggesting to do something that doesn't match policy.17:54
james_wlintian explains that if the package isn't used in clean it shouldn't be there, so it's suggesting to you two options17:55
james_wit has a global list of ignores, but is it right for every package to have python-yaml in Build-Depends? no.17:55
rmunnIn this case, the package *is* used in clean, but it's about two dependency levels deep via Python imports, and lintian doesn't have a good way of knowing that it's necessary...17:55
persiaWell, lintian could run debian/rules clean as part of the check :)  But yeah, I can see how it's annoying and/or awkward to fix.17:56
james_wyou could file a wishlist bug asking for them to execute python code to work out if that module will be loaded from a site directory during a setup.py clean17:56
james_wbut if the package is deviating from the norm then you should override lintian where you know better. That's exactly the advised policy.17:56
rmunnjames_w, that seems dangerous to me -- what if someone uploaded a malicious package to REVU with a setup.py that did all kinds of nasty stuff when imported?17:57
* persia completely agrees that an override is appropriate17:57
james_wif lintian is wrong in (nearly) every case or can easily be made to spot your case then file a bug on it, otherwise if you know better then override it if you care about lintian cleanliness17:57
rmunnOverride created and new version uploaded to http://revu.ubuntuwire.com/p/python-nltk, should show up in a minute or two17:57
james_wrmunn: exactly17:57
kamalmostafajames_w: hello -- "bzr branch lp:ubuntu/squid" yields a (quite) stale branch -- give it a poke?17:58
rmunnOkay, my override didn't work. Anyone want to look at http://revu.ubuntuwire.com/p/python-nltk (check the debdiff against previous version, that's easiest) and tell me what I did wrong in creating the debian/source/lintian-overrides file?17:59
james_whi kamalmostafa17:59
james_wyou know about http://package-import.ubuntu.com/status/17:59
james_wrmunn: debian/source.lintian-overrides17:59
rmunnI thought I followed the syntax in http://lintian.debian.org/manual/ch2.html precisely... there's probably *something* obvious I'm missing, but I just don't see it17:59
rmunn"If the override is for a source package, you have to place it at debian/source/lintian-overrides or debian/source.lintian-overrides (the former path is preferred)." I used the former path.18:00
rmunnNow *that* is a lintian bug, if debian/source/lintian-overrides doesn't work despite the manual saying it does. :-)18:00
persiaIt does work, at least I've seen it work.  I don't remember the syntax perfectly though.18:02
kamalmostafajames_w: no, I didn't know about import-status.  It's quite bewildering.  :-)18:02
\shrmunn: source.lintian-overrides did work in the past...;)18:03
james_wkamalmostafa: indeed, it needs some ui love :-)18:03
james_wrmunn: not sure why that's not working18:05
kamalmostafajames_w: So I see that it does reference 'squid', but I don't know what to make of its error detail (python error stack).  And I note that its squid error log is dated 6 days ago.   What's your interpretation of it?18:07
rmunnWhich version of lintian is running on REVU? Even on my lucid box, lintian --display-info isn't complaining about this. Only when I upload to REVU do I get the warning. Makes it kind of hard to fix without a dozen re-uploads, when I can't seem to reproduce the problem locally...18:07
james_wkamalmostafa: error in james_w I believe18:07
rmunnI'll try source.lintian-overrides, see if that makes REVU happier.18:08
james_wrmunn: don't bother18:08
james_wit's probably hardy or something, if it works fine on later versions that's good enough18:08
kamalmostafajames_w: Okay then, I'll consider the issue "reported" (unless you can tell me what package to report james_w bugs against?  ;-).18:09
james_wkamalmostafa: two ticks18:10
sistpoty|workrmunn: lintian on revu is from hardy, as spooky (revu's host) is still running hardy. just ignore it's output as james_w suggested18:11
sistpoty|work(and nobody dares to update spooky to post hardy, since it's a sparc box and sparc status in anything past hardy is suboptimal)18:12
persiaUm, lintian on REVU is 2.2.17ubuntu1.1, which is the same as karmic-updates: there's been some backporting (but it's still out of date)18:12
persia(hardy-backports is only 2.1.2ubuntu1~hardy1)18:13
rmunnWell, I'd already kicked off an upload with a debian/source.lintian-overrides, and that worked.18:13
jdong*seems to recall a backport request to at least some Ubuntu release*18:13
jdongmaybe not Hardy.18:13
sebnerbddebian: did you already have time to take a look at http://paste.ubuntu.com/373384/ ?18:13
jdongif not, that would be a good idea (tm) :)18:13
rmunnBut REVU still says "At least one common error: check the lintian file." Said lintian file contains nothing but "N: 1 tag overridden (1 info)". :-)18:13
persiajdong: I seem to recall there being some issue with getting current lintian on spooky other than just procedural, although backporting to at least karmic may have value.18:14
sistpoty|workpersia: oh, cool, so someone did backport it in the meantime :)18:14
persiasistpoty|work: Yep.  Might have even been you :p18:15
sistpoty|workpersia: no, I recall that my try failed due to some perl errors, and I reinstalled the old version ;)18:15
jdongpersia: right; I was thinking more the usecase of contributors that are still on Hardy themselves18:15
james_wkamalmostafa: queued18:15
persiajdong: Hrm.  We do have some of those, but not so many (or they work in chroots).18:16
jdongyeah I'd expect the latter to be common :)18:16
sistpoty|workjdong: while you're at it, you could also do dpkg so that revu can handle v3 packages :P18:16
jdongI've definitely seen people request backports of lintian but usually just to the n-1 releases18:16
jdongsistpoty|work: hehe that sounds like something I'd be a bit more scared to touch :)18:17
jdongI don't want the trophy for most broken update ever ;-)18:17
persiaWhat we need is someone to make sure the SPARC kernels work.18:17
rmunnOkay, so the only changes I've had to make recently to http://revu.ubuntuwire.com/p/python-nltk have been cosmetic. Does that mean it's ready for some MOTU advocates?18:17
sistpoty|workor a different box for revu :P18:18
Laneyyeah, setting a binary-indep target doesn't work18:35
Laneyat least pbuilder doesn't call it during the build18:35
james_wkamalmostafa: squid up to date, thanks for the reminder18:36
persiaLaney: Are you doing arch-dependent or arch-independent builds?  I know sbuild has the -A option which, on the buildds, is only enabled for i386.18:39
Laneypersia: pbuilder has no such option18:39
LaneyAFAIK, at least. And anyway it tried to build the indep package without running the corresponding binary-indep target18:39
persiaWell, try in sbuild then, is all I can say.  If you're running lucid, you can pull the latest ubuntu-dev-tools from trunk, and use mk-sbuild to create tarball schroots which only take up as much space as pbuilder (no more need for LVM)18:41
james_wkamalmostafa: it produced https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/squid/lucid-201002101821/+merge/1903818:42
james_wkamalmostafa: is that the dropped upload you were talking about?18:42
Laneypersia: will do, thanks18:46
persiaLaney: Note that despite constantly talking about sbuild, I do approve of using pbuilder, because I suspect that otherwise we'd have a hard time distinguishing bugs in policy from bugs in sbuild.18:47
james_wkamalmostafa: ah, it's ok, I see what happened18:48
LaneyI know, but I also know that sbuild supports selective arch/arch+indep builds, which pbuilder does not, and that I would like to test in this case.18:48
persiaLaney: Indeed.  I don't know if I'll finish by FF, but I'm hoping to find a way to get sbuild to reuse pbuilder tarballs soon.18:49
persia(although if I miss FF, I'll get distracted and may not get back to it any time soon)18:49
kamalmostafajames_w: back now ... can I answer any questions about the squid issue, or do you have matters in hand?18:52
james_wkamalmostafa: it's all good thanks18:52
=== Myrtti is now known as Guest75564
oojahCould someone please review http://revu.ubuntuwire.com/p/sqlite3-pcre ? It's had a few suggestions already so should hopefully be pretty sane. It's a very simple package, the only slightly unusual bit being that it gets the source from git.19:10
RoAkSoAxjames_w, ping19:11
james_whey RoAkSoAx19:11
RoAkSoAxjames_w, heya!! I just merged my first package using bzr... would you mind reviewing / uploading it please? https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/51994019:12
ubottuUbuntu bug 519940 in keepalived "Please merge keepalived 1.1.17-2 from debian testing" [Low,Confirmed]19:12
=== Myrtti_ is now known as Guest8777
james_wRoAkSoAx: looking19:16
=== Guest8777 is now known as Myrtti
DktrKranzcould a revu admin help me to track what happened to ubuntuwintv_0.7.1-0ubuntu1 upload? TIA19:27
james_wRoAkSoAx: uploaded19:35
RoAkSoAxjames_w, thanks :)19:36
persiaDktrKranz: I don't see it in any of incoming, uploads, or rejected.  I'm guessing either the upload didn't happen correctly, or it worked.19:37
=== EagleScreen is now known as Guest67076
DktrKranzpersia: thanks, I'll ask to reupload again19:40
persiaDktrKranz: I can't find it in the archived list either.  A new upload is probably best.19:40
RoAkSoAxjames_w, btw.. starting from when do we have to use bzr as mandatory?19:41
james_wRoAkSoAx: 5 minutes time19:43
james_wRoAkSoAx: nope, it's not mandatory, just really good19:43
RoAkSoAxjames_w, oh ok, thought it's going to become mandatory to use bzr over time19:44
james_wRoAkSoAx: maybe one day19:45
james_wbut there are currently no plans19:45
RoAkSoAxoh I see, well I guess i can use both methods while mastering the use of bzr :)19:46
=== EagleSn is now known as EagleScreen
=== yofel_ is now known as yofel
bddebiansebner: No, was I supposed to?20:19
sebnerbddebian: Well, I showed it some days ago to you. Maybe you missed it. Currently discussing in debian-games on oftc20:21
=== MrKanister1 is now known as MrKanister
Laneyhm, so it looks like sbuild uses binary-arch when doing an arch-dep build, and binary when doing arch+indep20:42
Laneybut binary doesn't depend on binary-indep20:42
imihttps://bugs.launchpad.net/bugs/519013 -- I was suggested to try backports as kdevelop may have a newes version in backports. actually, it doesn't have. Since I used to contribute packages to an other dpkg based distribution, I'm considering to build one on my own20:42
ubottuUbuntu bug 519013 in kdevelop "upgrade kdevelop please" [Undecided,Invalid]20:42
JontheEchidnahmm, I thought somebody had backported a never version than what was in karmic20:43
JontheEchidnaguess not though. I'll open up a karmic-backports task20:44
imiit does not have a backport package, I've just checked it at packages.ubuntu.com20:47
Laneyyeah, something is wrong with building sid chroots (at least with mk-sbuild)21:38
Laneyit installed half the world and then didn't even work for building :)21:38
DktrKranz(it probably needed the other half)21:38
Laneyno, part of the world it installed made it die21:39
=== EagleScreen is now known as Guest94638
franciscohow can I register in a channel?22:30
franciscoin an irc-channel22:30
persiafrancisco: /query nickserv22:31
franciscopersia: thanks a lot!22:31
kamalmostafajames_w: I'm trying to work on yet another package ('gcin') with a stale bzr tree.  I see it in the list of "905 outstanding jobs" at http://package-import.ubuntu.com/status/ --  Does this mean that I should ask you to manually provoke it to import, or that I should wait patiently?22:32
paissadhi all, i've packaged a software, i did 1st for debian, but i would like the package to be available in ubuntu repositories ... what do you suggest me to do ? ...22:33
sebnerpaissad: is it already in Debian?22:33
paissadi've alreaady uploaded the package in mentors-debian repositories & i'm waiting for a sponsor to upload it definitely22:33
james_wkamalmostafa: running22:33
paissadsebner, no for the moment, .... it's just in mentors-debian repositories waiting for a sponsor to upload it !22:34
paissadsebner, but i do have it in my personal repository22:34
paissadwait 1 min please22:34
sebnerpaissad: well, if you are not sure to get it uploaded to Debian the next day you should upload it to REVU as Final Freeze is in 8 days22:35
Laneyfinal freeze?!?!?!?!22:35
persiaNo reason we can't review a package on mentors.22:35
paissadsebner, REVU, let me google that !22:35
paissadi did not know22:35
persiaFeature Freeze.22:35
sebnerwrong word!22:35
kamalmostafajames_w: Thanks -- I see it running on the status page, and will watch for its completion.22:35
sebner!revu | paissad22:36
LaneyI'm not sure how likely it is that we will get to review a package on REVU now for Lucid anyway22:36
ubottupaissad: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU22:36
persiasebner: Just go review the package on mentors.  If it looks good, get a peer review, and get it uploaded.22:36
persiaREVU is a good tool, but REVU isn't the only way to do two-developers-looked-at-this22:36
sebnerpersia: we need to pull a DD out of under a rock too though :P22:36
franciscoalquien me puede ayudar?22:36
franciscocomo me puedo registrar en debian-es22:37
francisconecesito un registrarme para poder chatear22:37
ubottuEn la mayoría de canales de Ubuntu se habla sólo en inglés. Si busca ayuda en español o charlar entra en el canal #ubuntu-es. Escribe "/join #ubuntu-es" (sin comillas) y dale a enter.22:37
franciscoubottu: thanks22:37
ubottuYou're welcome! But keep in mind I'm just a bot ;-)22:37
* sebner hugs ubottu :D22:38
paissadfor people speaking french, they can read here http://doc.ubuntu-fr.org/pms-linux ... others might be able to understand too .. ^^22:38
ajmitchsebner: you should join the NM queue22:39
sebnerajmitch: to be honest I intend to become DM the next month (ehm, at least applying)22:40
ajmitch& then DD?22:40
sebnerajmitch: maye in 1-2 years ;)22:41
ajmitchhow disappointing :)22:42
kamalmostafajames_w: alas, the gcin import has failed http://package-import.ubuntu.com/status/gcin.html#2010-02-10%2022:36:53.69515622:42
james_wis it bz2?22:42
sebnerajmitch: lack of time, skill, ...22:42
ajmitchsebner: lack of time, I can accept...22:43
kamalmostafajames_w: yup, sure is.22:43
DktrKranzsebner: too humble22:43
* sebner hides22:43
james_wkamalmostafa: I'm writing the tests for that tomorrow22:43
james_wif you can wait a day it should be there22:44
kamalmostafajames_w: no problem -- I'll just apt-get source in the meantime.  thanks!22:44
* ajmitch should upgrade his sid VM more often22:45
sebnerajmitch: lack of time? ;-P22:46
ajmitchsebner: it's just been a couple of weeks since I last did a dist-upgrade22:46
ajmitchI need to remember to do it22:46
sebnerajmitch: when I'm actively doing some -dev stuff I upgrade my pbuilders every day. And my lucid machine too ^^22:48
ajmitchI've ketp my lucid install mostly up to date22:49
=== EagleScreen is now known as Guest17512
=== EagleSn is now known as EagleScreen

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