| binarymutant | learn something new everyday | 00:00 |
|---|---|---|
| === heHATEme is now known as Vorian | ||
| porthose | Shouldn't the archive admin's be subscribed to bug #368505? it's been ACKed | 00:15 |
| ubottu | Launchpad bug 368505 in ampache "Please sync Ampache-3.4.4-1 from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/368505 | 00:16 |
| ajmitch | porthose: james_w may have removed ubuntu-archive from the subscribers if he thought it needed a fakesync (not sure why) | 00:17 |
| james_w | I did | 00:18 |
| james_w | it does need a fakesync | 00:18 |
| porthose | ok just checking :) | 00:18 |
| james_w | ubuntu-archive admin aren't better placed to do that than any random developer | 00:18 |
| ajmitch | different orig.tar.gz in that case? | 00:18 |
| james_w | yeah | 00:18 |
| james_w | so I unsubscribed the archive and subscribed the sponsors, so a larger pool of people where aware of it | 00:19 |
| ajmitch | james_w: I think it could have been useful to have that in the bug comment - I can see you doing that from the +activity page though | 00:20 |
| james_w | yes, it would have been | 00:21 |
| james_w | however, I had a bunch of things to do | 00:21 |
| james_w | and if someone didn't understand what a fakesync was they could ask | 00:21 |
| micahg | has there been any interest in have the Doctrine ORM Framework as a package? | 00:23 |
| === ShadowChild is now known as lukjad007 | ||
| lukjad007 | Hi, is there a channel for the Multiverse Repos, or is this it here? | 00:40 |
| maxb | here | 00:40 |
| lukjad007 | maxb Ah. | 00:40 |
| lukjad007 | Well, I've noticed something for the last couple of releases. The "Funguloids" game has unresolved dependencies. | 00:41 |
| maxb | what a weird name | 00:41 |
| lukjad007 | maxb I wouldn't know, I've never been able to play it. ;) | 00:42 |
| maxb | hmm, so it does. File a bug? | 00:42 |
| maxb | (If there isn't already one) | 00:42 |
| lukjad007 | I think there must be. I only heard of the game because of it. | 00:42 |
| lukjad007 | But, I will look for it. | 00:43 |
| * maxb wonders when it last build... | 00:43 | |
| lukjad007 | Here it is: https://bugs.launchpad.net/ubuntu/+source/funguloids/+bug/194686 | 00:43 |
| ubottu | Ubuntu bug 194686 in ogre-contrib "Error installing Funguloids: ogre-plugins-cgprogrammanager doesnt exist" [Medium,Confirmed] | 00:43 |
| maxb | jm, intrepid/jaunty, not that old | 00:44 |
| maxb | *hm | 00:44 |
| maxb | What's ogre, do you know? | 00:44 |
| lukjad007 | maxb Sorry, No. | 00:45 |
| * maxb initializes a karmic cowbuilder | 00:46 | |
| lukjad007 | maxb I am only an advanced user. | 00:47 |
| lukjad007 | Anyway, I've confirmed the conformation. | 00:47 |
| xnox` | !fakesync | 00:48 |
| ubottu | Sorry, I don't know anything about fakesync | 00:48 |
| xnox` | what is a fakesync? | 00:48 |
| maxb | IIUC, it's a upload to Ubuntu that has a version number and content as if it was a sync | 00:49 |
| maxb | usually done because Debian and Ubuntu have ended up with bytewise different .orig.tar.gz files for the same version, so the normal sync process is invalid | 00:49 |
| xnox` | Aha. And how do you fix "fakesyncs" from both sides (Ubuntu/Debian) so that regular syncs can procede? | 00:50 |
| xnox` | by using same tarball in the next upload in both? | 00:50 |
| maxb | If the reason is .orig.tar.gz mismatch, I think the problem fixes itself automatically once a new upstream version is uploaded to Debian | 00:51 |
| * maxb notes that funguloids is now FTBFS in karmic | 00:52 | |
| xnox` | ok cool. Another question - Distro specific patches. For example I'm patching upstream docs to instead of saying "report bugs to upstream@mailing list" to say "report bugs to BTS" but I would also would like to include an ubuntu specific patch which will then instead say "report bugs to launchpad". | 00:53 |
| xnox` | Is there a was to create such smart patches. I'm thinking some extra metadata in the patch such that the ubuntu builders will pick it up. | 00:53 |
| xnox` | The idea is to have the debian-syncs to still work. On the other hand it brings a security risk in a way that a patch which isn't applied in Debian ends up breaking Ubuntu (although the intend was different) | 00:55 |
| directhex | xnox`, possible but annoying | 00:55 |
| === popey_ is now known as popey | ||
| xnox` | As a kind debian maintainer I would still include debian/patches/ubuntu_fix_ftbs_new_python.patch but not add it to series file just to keep the diff smaller. | 00:57 |
| * xnox` loves quilt & latest dh7 way better than cdbs | 00:58 | |
| directhex | we do things like this a little bit in pkg-cli-apps | 01:01 |
| directhex | and pkg-mono | 01:01 |
| cjwatson | it's about to get somewhat easier in karmic, I hope | 01:10 |
| cjwatson | dpkg 1.15.1 will have a 'dpkg-vendor' script, so you can test the exit code of 'dpkg-vendor --derived-from Ubuntu' | 01:10 |
| cjwatson | (or 'dpkg-vendor --is Ubuntu') | 01:11 |
| directhex | cjwatson, that would be nicer than lsb_release | 01:19 |
| directhex | cjwatson, i'm pretty sure i'm breaking things on distros like mint | 01:19 |
| xnox` | these are some of the issues even though in our ecosystem we all use dpkg we do have our own little things which gives as advantages but on the other hand create barriers for fixes and security issues, resulting in delays between the members in the DAG of Debian-like systems. (think all types*architectures*variant) | 01:23 |
| qiyong | hi, is zippo popular in your area? | 02:24 |
| ScottK | LucidFox: I'm not real happy about it. I am happy it wasn't imposed on Kubuntu for Jaunty. | 02:27 |
| LucidFox | ah | 02:27 |
| === ApOgEE__ is now known as ApOgEE- | ||
| mib_x96owjor | hello room | 02:51 |
| mib_x96owjor | how do you install java? | 02:51 |
| Pici | mib_x96owjor: This isn't a support channel, please ask in #ubuntu | 02:52 |
| mib_x96owjor | ok, thanks | 02:56 |
| mib_x96owjor | bye | 02:56 |
| jacob | how might I add a comment to merge-o-matic? would like to link twitux to a bug/sync | 03:00 |
| nhandler | jacob: There is a column on the far right that has a hidden text box. Just click on it to add a comment | 03:16 |
| nhandler | jacob: If you can't find the text box, tell me the name of the package and the comment you want to add, and I can add it for you | 03:19 |
| jacob | ^ was about to respond! d'oh. found it, someone tell him I said thanks if he returns tonight. :P | 03:35 |
| === fabrice_sp__ is now known as fabrice_sp | ||
| === hggdh_ is now known as hggdh | ||
| === savvas_ is now known as savvas | ||
| === rawang is now known as rawang|lunch | ||
| === hanska is now known as Guest67703 | ||
| lifeless | ScottK: btw, you can use it with ubuntuone; its the generic Ubuntu they mean. | 05:28 |
| nixternal | someone asked me today, "What do you know about Ubuntu One?" I responded, "You mean Canonical One, Mark's jet, it's an airplane, it flys." :) | 05:32 |
| nixternal | had no clue about Ubuntu One until today, well I knew about it, just didn't know what it was going to be called | 05:33 |
| kklimonda | is it something like dropbox? with similar features? | 05:34 |
| nixternal | looks like it...I think Mark hinted on going for more of a "Mobile Me" type system | 05:34 |
| kklimonda | a bit expensive.. | 05:36 |
| kklimonda | but i shouldn't complain as I probably won't use 2GB ;) | 05:36 |
| nixternal | I haven't even used a 1gb on dropbox yet | 05:36 |
| e-jat | nixternal: so u use dropbox n ubuntuone? | 05:40 |
| nixternal | just dropbox | 05:40 |
| e-jat | just try the ubuntuone .. already file a bugs .. :( | 05:40 |
| nixternal | don't you need an invite to try it? | 05:40 |
| e-jat | yeah .. u can request the invitation .. | 05:41 |
| e-jat | im just lucky to see invitation in my inbox .. | 05:41 |
| superm1 | how did they decide who to invite then? | 05:41 |
| nixternal | hrmm, speaking of that, I just noticed that my dropbox isn't working on this machine | 05:41 |
| e-jat | thats why i give a try | 05:41 |
| kklimonda | e-jat: lucky you :) | 05:41 |
| nixternal | heh, after I said that about the invite, I got one sitting in my inbox...didn't even see that | 05:41 |
| e-jat | thanks kklimonda | 05:41 |
| e-jat | superm1: maybe ubuntu members got it .. | 05:41 |
| superm1 | e-jat, oh i was gonna say if that's it then nixternal should have one, and then i saw he did :) | 05:42 |
| kklimonda | "but we are not releasing the source code to the servers at this time." heh ;) | 05:43 |
| e-jat | superm1: :) | 05:43 |
| e-jat | wb RoAkSoAx | 05:45 |
| RoAkSoAx | hello e-jat | 05:45 |
| e-jat | bug 375249 | 05:46 |
| ubottu | Launchpad bug 375249 in ubuntuone-client "Segmentation fault" [Undecided,New] https://launchpad.net/bugs/375249 | 05:46 |
| e-jat | kklimonda: me unlucky .. cant get the applet work | 05:47 |
| kklimonda | ehehehe, welcome to the hell of beta testing ;} | 05:48 |
| kklimonda | e-jat: at least you can play with web interface :) | 05:48 |
| kklimonda | all i can see is some not so bad front page :) | 05:48 |
| kklimonda | i like the fact that canonical is using openid for all pages.. | 05:49 |
| kklimonda | I don't have to remember another set of l/p.. | 05:49 |
| ajmitch | greetings | 05:50 |
| kklimonda | hey | 05:50 |
| e-jat | kklimonda: :) | 06:00 |
| e-jat | kklimonda: openid is c00l | 06:00 |
| e-jat | brb .. going to take my launch .. | 06:00 |
| ajmitch | hi siretart | 07:11 |
| siretart | hey ajmitch! | 07:11 |
| siretart | how are you? | 07:12 |
| ajmitch | good, how are you? | 07:13 |
| siretart | fine, thanks | 07:32 |
| siretart | rather busy this week, have to finish a conference paper and stuff.. | 07:32 |
| * ajmitch is still finishing off a project at work this week | 07:33 | |
| ajmitch | and then it's onto the next one in the pile :) | 07:33 |
| dholbach | good morning | 07:35 |
| ajmitch | good morning dholbach | 07:35 |
| dholbach | hiya ajmitch | 07:36 |
| === Lure_ is now known as Lure | ||
| didrocks | morning everybody o/ | 07:41 |
| didrocks | DktrKranz: do you have some minutes for a python transition related question? | 07:42 |
| DktrKranz | didrocks: fire it | 07:43 |
| DktrKranz | (and good morning, btw) | 07:43 |
| didrocks | DktrKranz: so, I updated some days again vte to 0.20.1-0ubuntu1. All was well, sun was shining... :) | 07:44 |
| didrocks | then, I merged with the debian version producing 0.20.1-1ubuntu1 and troubles come around :) it FTBFS: | 07:44 |
| didrocks | https://launchpad.net/ubuntu/+source/vte/1:0.20.1-1ubuntu1/+build/992606/+files/buildlog_ubuntu-karmic-i386.vte_1:0.20.1-1ubuntu1_FAILEDTOBUILD.txt.gz | 07:44 |
| didrocks | the issue is that it's still using site-packages | 07:45 |
| didrocks | I found no clue why the behavior changes (no explicit setup.py call) | 07:45 |
| * DktrKranz looks | 07:45 | |
| didrocks | the bzr branch is there : ~ubuntu-desktop/vte/ubuntu | 07:46 |
| didrocks | The only thing which worked out was to pass -d to dh_pysupport as in the old package | 07:46 |
| didrocks | but it copies files in usr/lib/pyshared/python2.6/ instead of usr/lib/python-support/python-vte/python2.6 | 07:47 |
| didrocks | (I don't know the difference between pyshared, which seems to be used in debian and python-support/package-name) | 07:47 |
| DktrKranz | new pysupport places files in new locations | 07:48 |
| didrocks | ok, so python-support/package-name is the new location? | 07:48 |
| didrocks | what I tried too in this package is to add again debian/pyversions and set XS-Python-Version to 2.4... but nothing worked. I'm really stucked :( | 07:49 |
| dholbach | didrocks: I just got the same problem with a human-theme upload | 07:49 |
| didrocks | dholbach: did you achieve to fix it? :) | 07:50 |
| dholbach | https://bugs.edge.launchpad.net/ubuntu/+source/cdbs/+bug/374892 | 07:50 |
| ubottu | Ubuntu bug 374892 in cdbs "Use correct root path when converting dist- to site- in arch packages" [Undecided,New] | 07:50 |
| dholbach | that could be it | 07:50 |
| didrocks | let me check | 07:50 |
| dholbach | let's move to #ubuntu-devel | 07:50 |
| DktrKranz | didrocks: could you please grep upstream code to see if they hardcode site-packages somewhere? | 07:52 |
| didrocks | DktrKranz: I did and it's the case in configure.ac file. But it was already the case in the previous revision with no patch | 07:52 |
| DktrKranz | I see, I'll have a testbuild | 07:52 |
| didrocks | DktrKranz: look at the link that dholbach provided. I may be related | 07:53 |
| DktrKranz | didrocks: probably | 07:55 |
| didrocks | DktrKranz: that's really strange. If you bzr diff last revision and -r -3 | 07:56 |
| didrocks | you will see that changes aren't huge :/ | 07:56 |
| LordKow | q: http://launchpadlibrarian.net/26622104/buildlog_ubuntu-karmic-powerpc.hotkeys_0.5.7.4-0.2_FAILEDTOBUILD.txt.gz i believe this happened because the build happened during a libxmu upgrade | 07:58 |
| LordKow | will this automatically be rebuilt or will i need to bug report it? | 07:58 |
| maxb | When a file is moved between binary packages, what is the correct incantation to avoid a dpkg file overwrite error? | 07:59 |
| maxb | Should a versioned Replaces be used, or a versioned Conflicts+Replaces ? | 08:00 |
| maxb | binary packages built by the same source, if that matters | 08:00 |
| LordKow | maxb: the source in which a file was moved between a package should deal with conflicts/replaces itself i would think | 08:01 |
| LordKow | at least, the conflict portion | 08:01 |
| LordKow | hmm | 08:02 |
| maxb | yes that's my point, the maintainer has moved a file between packages without being aware they need to provide the necessary extra hinting to allow clean upgrades | 08:03 |
| DktrKranz | didrocks: "checking for python script directory... ${prefix}/lib/python2.6/site-packages | 08:12 |
| DktrKranz | it hardcodes it somewhere, so it has to be adjusted, I'll have a look | 08:12 |
| LordKow | so how should we feel about syncing a debian package that does not use patches for it's changes to the source (they're shown within the diff.gz)? either that or we fork with the same changes but reflected as patches | 08:29 |
| cody-somerville | We sync | 08:29 |
| LordKow | k | 08:29 |
| didrocks | DktrKranz: it was already the case with the previous version | 08:32 |
| didrocks | DktrKranz: I think this is a cdbs issue. Because compiling today the old revision have the same behavior | 08:34 |
| DktrKranz | didrocks: indeed, just noticed that. I prefer debhelper over cdbs, so I need to look at how it handles Python stuff, the patch you mentioned is for distutils, so it should not impact vte, though. | 08:37 |
| didrocks | DktrKranz: ok. If you have any idea about this, you're really welcome :) | 08:38 |
| DktrKranz | didrocks: are other packages FTBFS? dholbach said somethinh about human-theme | 08:41 |
| didrocks | DktrKranz: this is related to his bug report | 08:41 |
| LordKow | what is the ubuntu policy on various sections in .desktop files? i am working on a package in which section = video want to know if that is fine or if it should be AudioVideo | 08:49 |
| LordKow | doh, bad changelog entry got me. it was referring to debian's video repository ;) | 08:52 |
| DktrKranz | didrocks: did you try to give-back it? I see different results here | 08:53 |
| DktrKranz | and it could probably be OK | 08:53 |
| didrocks | DktrKranz: the layout is different? | 08:54 |
| DktrKranz | yes | 08:54 |
| didrocks | you don't have a pyshared but a python-support ? | 08:54 |
| DktrKranz | didrocks: oh, I didn't look at -dbg package, it was that which has the offending path | 08:55 |
| didrocks | yes | 08:55 |
| DktrKranz | so a give-back would FTBFS again | 08:55 |
| didrocks | ok... so that's not where it failed | 08:55 |
| didrocks | DktrKranz: I really think that's an exterior element which makes it fail (as the previous version has now the same issue) | 08:56 |
| DktrKranz | yeah | 08:57 |
| didrocks | maybe doko is aware of that. I will try to ping him | 08:58 |
| directhex | dholbach, do i have a comment sat in moderation/spam on behind motu? | 08:59 |
| dholbach | directhex: at least I didn't get an email about it | 09:04 |
| directhex | dholbach, no mail usually means akismet | 09:04 |
| dholbach | directhex: you're right | 09:05 |
| dholbach | approved | 09:05 |
| directhex | ;) | 09:05 |
| DktrKranz | didrocks: what .PRECIOUS does exactly? | 09:19 |
| didrocks | DktrKranz: it's telling what files must not be cleaned in the clean rules for makefile. Debian dropped it | 09:24 |
| LordKow | should i be doing anything if a package i had synced FTBFS. the failure has nothing to do with the package itself. the sync bug was marked as 'fix released' | 09:27 |
| jpds | LordKow: If it has nothing to do with it, no, other than fix the other package. | 09:28 |
| jpds | LordKow: Sync is done => fix released. | 09:28 |
| LordKow | jpds: the problem was/is that one of the deps was partially upgraded when it tried building | 09:29 |
| LordKow | libxmu to be precise | 09:29 |
| LordKow | so i dont think there is anything i can do except maybe feed the build farm some energy ;) | 09:30 |
| jpds | Oh, they get plenty of power. | 09:30 |
| jpds | LordKow: Link to build log? | 09:30 |
| LordKow | jpds: https://launchpad.net/ubuntu/+source/hotkeys/0.5.7.4-0.2/+build/997649/+files/buildlog_ubuntu-karmic-powerpc.hotkeys_0.5.7.4-0.2_FAILEDTOBUILD.txt.gz | 09:30 |
| jpds | LordKow: Oh, ppc and the other arches are usually slow to catch up | 09:35 |
| LordKow | yea, so will it be automatically rebuilt or is some sort of user intervention required to make that happen when the time is right? | 09:36 |
| jpds | It should automatically build later. | 09:36 |
| LordKow | jpds: ty | 09:37 |
| === rawang|lunch is now known as rawang | ||
| DktrKranz | didrocks: maybe I found something... | 09:52 |
| === azeem_ is now known as azeem | ||
| didrocks | DktrKranz: really ? :) | 10:03 |
| === \sh_ is now known as \sh | ||
| === Nicke_ is now known as Nicke | ||
| DktrKranz | didrocks: uploading to my PPA to be sure | 10:07 |
| didrocks | DktrKranz: ok, keep me in touch :) | 10:12 |
| loic-m | Ive got an mplayer karmic failure to build because of missing liblzo-dev dependency in my ppa. I checked http://packages.ubuntu.com/karmic/mplayer and the dependency is in the control file (see the diff.gz) but not listed on the web page | 10:15 |
| loic-m | Is there a reason it builds in ubuntu's repos but not my ppa? | 10:15 |
| loic-m | (I'm using the same source package) | 10:16 |
| loic-m | I could remove the dependency myself, but i'm test building the rdepends of xvidcore, and need to use the same source pkg as in the repos | 10:17 |
| didrocks | loic-m: I don't know if ppa have pkgbinarymangler installed | 10:17 |
| maxb | loic-m: rmadison says there is no liblzo-dev in karmic | 10:19 |
| maxb | PPAs deliberately don't binarymangle | 10:19 |
| loic-m | There's no man page for pkgbinarymangler on manpages.ubuntu.com and I'm a bit lost atm | 10:20 |
| maxb | pkgbinarymangler is not the issue | 10:21 |
| maxb | loic-m: liblzo-dev doesn't exist in karmic | 10:22 |
| loic-m | maxb: yes, but then how comes mplayer builds in karmic? | 10:22 |
| maxb | It probably doesn't any more | 10:23 |
| AnAnt | Hello, can someone review sabily-keyring (http://revu.ubuntuwire.com/details.py?upid=5729) ? | 10:23 |
| loic-m | Which mean if something is attempting a rebuild of mplayer for karmic in Ubuntu's repositories, it will fail? | 10:23 |
| maxb | Likely | 10:23 |
| maxb | launchpad says it last built in jaunty | 10:24 |
| maxb | https://launchpad.net/ubuntu/+source/mplayer/2:1.0~rc2-0ubuntu19 | 10:24 |
| loic-m | maxb: I thought they were rebuild at each new cycle | 10:24 |
| siretart | loic-m: if you catch someone who actually work on mplayer in ubuntu, please report him to me | 10:25 |
| loic-m | maxb: do you have any idea how I can test build it in the meantime (for bug #306399)? | 10:25 |
| ubottu | Launchpad bug 306399 in xvidcore "New upstream version available (1.2.1)" [Wishlist,In progress] https://launchpad.net/bugs/306399 | 10:25 |
| loic-m | siretart: no clue at all | 10:25 |
| siretart | loic-m: best thing we can do about mplayer (IMO) is to take the debian package as basis, and enhance it to build mencoder in addition to mplayer | 10:26 |
| siretart | I tried, but don't think i'll manage to finish that this or next week | 10:26 |
| maxb | loic-m: Why do you need to rebuild it? | 10:27 |
| maxb | (Sorry, that's a long bug to read quickly) | 10:27 |
| loic-m | maxb: to test if it still builds using latest xvidcore | 10:27 |
| maxb | oh, right. Well, you'll need to either fix it to not require lzo, or build it in jaunty, I guess | 10:28 |
| DktrKranz | didrocks: it builds (waiting for i386 to finish, but it should be ok): https://edge.launchpad.net/~dktrkranz/+archive/ppa/+files/vte_1:0.20.1-1ubuntu1_1:0.20.1-1ubuntu2.diff.gz | 10:28 |
| loic-m | siretart: If you work on mplayer, can you try with xvidcore-1.2.1 instead of 1.1.2? | 10:28 |
| siretart | in 2-3 weeks, remind me again :) | 10:28 |
| loic-m | siretart: packages are at https://launchpad.net/~loic-martin3/+archive/xvid and the diff.gz on the bug report | 10:29 |
| loic-m | siretart: thanks | 10:29 |
| siretart | sorry | 10:29 |
| siretart | bbl, sigfood caught. | 10:29 |
| loic-m | maxb: I guess atm I'll try on Jaunty | 10:29 |
| didrocks | DktrKranz: I have to look at the package layout, first :) | 10:30 |
| loic-m | siretart: no pb for the delay. mine is one cycle late ;) | 10:30 |
| lezedepeze_ | please go on that link: | 10:40 |
| lezedepeze_ | http://www.schwimmbadspiel.de/?refId=99828434 | 10:40 |
| lezedepeze_ | http://www.schwimmbadspiel.de/?refId=99828434 | 10:40 |
| lezedepeze_ | http://www.schwimmbadspiel.de/?refId=99828434 | 10:40 |
| lezedepeze_ | http://www.schwimmbadspiel.de/?refId=99828434 | 10:40 |
| lezedepeze_ | http://www.schwimmbadspiel.de/?refId=99828434 | 10:40 |
| lezedepeze_ | http://www.schwimmbadspiel.de/?refId=99828434 | 10:40 |
| iulian | Stop that. | 10:40 |
| iulian | !ops | 10:40 |
| ubottu | Help! Hobbsee, Riddell, sladen, fbond, mneptok, gnomefreak, Seveas, dholbach, elkbuntu, PriceChild, or jpatrick! | 10:40 |
| mok0 | iulian: it's a spammer | 10:40 |
| popey | Pointy stick of DOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOM! | 10:41 |
| iulian | Hobbsee! | 10:41 |
| * Hobbsee MUHAHAHAHAHAHAHA | 10:41 | |
| Hobbsee | iulian: heya! | 10:41 |
| mok0 | Hobbsee: he was here with another name yesterday | 10:41 |
| Hobbsee | mok0: same IP? | 10:41 |
| Hobbsee | @btlogin | 10:41 |
| mok0 | Hobbsee: I don't knw | 10:42 |
| Hobbsee | got him, and got him again. | 10:42 |
| mok0 | Hobbsee: great, thx | 10:42 |
| ajmitch | and he's not even restricting activities to ubuntu channels | 10:42 |
| wgrant | Sounds like a K-line to me. | 10:42 |
| ajmitch | one would hope so | 10:43 |
| ajmitch | Hobbsee: you joined #plone about 3 seconds too late | 10:43 |
| Hobbsee | ajmitch: yeah, i suspected so | 10:43 |
| Hobbsee | nothing i can do there | 10:43 |
| ajmitch | and now he hits the world of warcraft channels on freenode :) | 10:44 |
| ajmitch | ah well | 10:44 |
| didrocks | DktrKranz: it's still in usr/lib/psyhared/python2.x and not python-support/package-name. So, the issue still remains | 10:44 |
| * ajmitch goes back to hunting stuff | 10:44 | |
| ajmitch | or fixing up the merge which still had jaunty in the changelog... | 10:45 |
| StevenK | There's WoW channels? | 10:45 |
| ajmitch | StevenK: mostly addon development channels | 10:45 |
| * ajmitch uploads again, this time with karmic | 10:46 | |
| * StevenK mourns for maintaince | 10:51 | |
| ajmitch | StevenK: 12 hour maintenance for your usual realm? | 10:51 |
| StevenK | Yup | 10:52 |
| ajmitch | fun | 10:52 |
| StevenK | I suspect they have teams all over the Blizzard datacentres swapping out machines | 10:52 |
| lifeless | I suspect db reindexing | 10:53 |
| StevenK | They specifically said hardware, too | 10:53 |
| lifeless | oh, interesting | 10:53 |
| lifeless | its a shame they don't get clustering and HA | 10:53 |
| StevenK | I suspect each realm really is a cluster of 6-8 machines | 10:54 |
| StevenK | But I guess I'll never know | 10:54 |
| ajmitch | it supposedly is, from what we've heard | 10:54 |
| lifeless | StevenK: there are services per map region; instance servers, battlegroup servers, common db for storage | 10:55 |
| lifeless | StevenK: counts unknown | 10:55 |
| lifeless | clustering tech may be known, but I haven't gone looking | 10:55 |
| ajmitch | sigh, I've passed my package upload count for jaunty already, I think | 10:55 |
| azeem | ajmitch: good thing karmic is there! | 10:56 |
| ajmitch | azeem: yes, I was unclear - with the packages I uploaded to karmic alrady, it's more than I uploaded to jaunty :) | 10:56 |
| POX | didrocks, DktrKranz: don't depend on python-support's internals (usr/lib/psyhared/python2.x vs. python-support/package-name issue) | 10:57 |
| POX | do all you have to do *before* invoking dh_pysupport | 10:57 |
| POX | (same with dh_pycentral, btw) | 10:58 |
| mok0 | StevenK: what's the status of the poulsbo drivers for jaunty? | 10:58 |
| didrocks | POX: I don't really get you. The previous upload (two weeks ago), was working well, with the same dh_pysupport call | 10:59 |
| StevenK | mok0: Underway | 10:59 |
| mok0 | StevenK: Cool ;-) | 11:00 |
| POX | didn't you sync python-support ~2 weeks ago? | 11:00 |
| POX | if yes, its internals changed | 11:00 |
| POX | and since apparently this package depends on it, it fails | 11:00 |
| === dpm_ is now known as dpm | ||
| POX | ergo: don't depend on pysupport's internals | 11:00 |
| didrocks | POX: Debian depends on it. The idea is to merge as close as possible to Debian | 11:01 |
| didrocks | POX: let me check python-support upload | 11:01 |
| POX | (and everything that contains "pyshared" or "python-support/package-name" is using py{support,central} internals | 11:01 |
| POX | didrocks: pysupport 1.0 was in Debian experimental for a while (so that packages that use its internals could be fixed before it hit unstable) | 11:02 |
| POX | so if this package still uses these internals, just sync it with Debian | 11:03 |
| mok0 | Hm, gcalctool is so amazingly buggy that we should remove it from the distro | 11:03 |
| didrocks | POX: We still have ubuntu changes in it, that's why we can't sync it | 11:03 |
| didrocks | POX: I will check the python-support version used to build it | 11:05 |
| didrocks | afk for lunch :) | 11:05 |
| POX | didrocks: anyway, solution will be to sync with Debian or at least merge debian/rules | 11:06 |
| mok0 | What's ubuntuone? Is is a scam? | 11:06 |
| POX | (even if I don't know what package is it, only few are still not fixed in Debian) | 11:06 |
| ajmitch | mok0: it's a canonical service, at least | 11:07 |
| mok0 | ajmitch: I got an "invitation" by email to join | 11:07 |
| ajmitch | mok0: yes, all ubuntu members got that. | 11:07 |
| mok0 | ajmitch: ... amazingly simple way to get access to peoples files :-) | 11:07 |
| ajmitch | the intentions were good, not so sure if they did the mass-invite the right way :) | 11:08 |
| DktrKranz | POX: I didn't look at it well, one of Ubuntu deltas is a -dbg package, but it doesn't seem it relies on pysupport internals (hardcoded path or so) | 11:08 |
| === mcasadevall is now known as NCommander | ||
| VK7HSE | just been having a fiddle with squid for possible merge, I've got it down to only one warning being, W: squid source: patch-system-but-direct-changes-in-diff cfgaux/config.guess and 1 more any suggestions ??? | 11:32 |
| * VK7HSE has just been called out of the room! (Gahh!) | 11:33 | |
| directhex | VK7HSE, config.guess should be deleted in the "clean" rule. | 11:36 |
| cjwatson | VK7HSE: is the same warning emitted for the Debian package? | 11:38 |
| directhex | cjwatson, i can't imagine why it wouldn't | 11:40 |
| directhex | or i can begin to imagine, then my brain blocks it out | 11:40 |
| cjwatson | if it is, then there's no need to worry about it at merge time | 11:40 |
| ajmitch | VK7HSE: squid was uploaded a few hours ago | 11:41 |
| didrocks | POX: I merged it with Debian :) | 11:45 |
| didrocks | POX: and they have pyshared and not python-support | 11:45 |
| didrocks | as a path | 11:45 |
| POX | didrocks: then it's still not fixed in Debian as well | 11:48 |
| POX | file a bug (or reopen the old one) | 11:49 |
| didrocks | POX: I think Debian install in /usr/lib/pyshared and don't bother about /usr/lib/python-support/package_name | 11:49 |
| didrocks | POX: ok, the previous version (with the right path) was installed with previous python-support version. I have to figure out how to test it in my pbuilder | 11:50 |
| POX | no, package shoudl install to standard Python paths, dh_pysupport will move it to /usr/{share,lib}/pyshared | 11:50 |
| POX | but package shold not depend on it | 11:50 |
| POX | /usr/lib/python-support/package_name is old path, new python-support uses pyshared (to be compatible with python-central) | 11:51 |
| didrocks | POX: really? I found no documentation on that | 11:51 |
| POX | but python-central doesn't use /usr/lib/pyshared (one of the reasons we use python-support now in Debian) | 11:52 |
| POX | didrocks: /usr/share/doc/python-support/README.gz | 11:52 |
| didrocks | POX: thanks, reading it now :) | 11:52 |
| didrocks | POX: ok "Public extensions (.so files) are handled just like public modules [...] will be located in /usr/lib/pyshared/pythonX.Y/" | 11:56 |
| didrocks | so, pyshared is the right location for .so | 11:56 |
| POX | it is, but dh_pysupport will handle moving the files | 11:57 |
| POX | you can install to /usr/{,local/}lib/python2.X/site-packages - dh_pysupport will detect it and move the files | 11:58 |
| didrocks | POX: that is what it is doing. So everything's right now. Thanks to DktrKranz, -dbg package is also fixed :) | 11:58 |
| didrocks | (thanks DktrKranz and POX for the clarification, btw :D) | 12:00 |
| \sh | hmm...do i miss something or is the "request team membership" button on LP missing? (especially for universe sponsors) | 12:11 |
| james_w | \sh: it's a restricted team, you have to be added | 12:17 |
| james_w | congratulations btw | 12:17 |
| \sh | james_w: thx :) | 12:17 |
| \sh | james_w: sure..I know...but somehow there needs to be an "apply for membership" link or something ... to make it easier then to write an email to the team owner... | 12:18 |
| \sh | afaik there was in the past... | 12:18 |
| james_w | you can just ping Emmet or Luke here | 12:19 |
| * persia goes to add \sh to the team | 12:20 | |
| directhex | congratulations? i'm congratulating \sh for something? | 12:20 |
| \sh | persia: readd ;) | 12:20 |
| \sh | directhex: I became daddy of a wonderful boy:) | 12:20 |
| persia | \sh, Indeed, for the fourth time or so, if I remember correctly. | 12:20 |
| directhex | \sh, oh, yes, i remember now. i'm still of a maturity level where i see infants as something to run in fear from... congrats though! | 12:21 |
| \sh | directhex: hehe..I know that feeling..but now everything is different :) | 12:22 |
| ajmitch | \sh: let me add my congratulations to the pile :) | 12:22 |
| \sh | ajmitch: thx :) | 12:23 |
| persia | \sh, Your gold star has been restored. | 12:26 |
| \sh | persia: thx a lot | 12:27 |
| loic-m | What's the procedure in launchpad to request an upgrade from upstream on a multiverse package (in karmic)? Attach the diff.gz then subscribe motu-release? | 12:38 |
| persia | loic-m, subscribe the sponsors, not the release team. | 12:41 |
| persia | (or just upload, if you have another way to do that) | 12:41 |
| loic-m | persia: thanks | 12:42 |
| papo | hello | 12:45 |
| papo | I've been dealing with bugs 221332 and 373767 and I've been wondering whether the maintainers are interested in one or both patches | 12:46 |
| ubottu | Launchpad bug 221332 in tiemu "The tiemu package is heavily outdated" [Wishlist,Confirmed] https://launchpad.net/bugs/221332 | 12:46 |
| ubottu | Launchpad bug 373767 in tiemu "Incorrect keyboard mapping" [Undecided,New] https://launchpad.net/bugs/373767 | 12:46 |
| === jcfp is now known as Guest13093 | ||
| === Guest13093 is now known as jcfp | ||
| persia | papo, You've exposed a documentation failure :) Thanks. | 12:55 |
| persia | !sponsoring | 12:55 |
| ubottu | Sorry, I don't know anything about sponsoring | 12:55 |
| persia | Bother. Two of them. | 12:55 |
| === santiago-pgsql is now known as santiago-ve | ||
| persia | papo, I think you want https://wiki.ubuntu.com/DeveloperGuide/Sponsorship : this documents the best way to get visibility for your patches, and get them applied. | 12:56 |
| papo | well | 12:59 |
| papo | persia: to be honest, I'm very lazy. The point is that the "patch" (I'm not even using dpatch in the PPA) should be broken into two parts and some ubuntu guys should decide which one (or both) should go into the package. Now it would be quite annoying if I would have done that work for nothing. That's why I'd prefer it if someone actually would make the decision before I continue with any work. After that, I'd really love to clean it up | 13:02 |
| papo | persia: Oh and there's also a couple of fixes I applied because lintian was complaining | 13:02 |
| papo | and what do you mean by documentation failure? | 13:03 |
| persia | In that we didn't document that the best way to request patch review was in that manner so that you came here. | 13:03 |
| papo | ah I see :) | 13:03 |
| persia | The issue is mostly that there aren't any "maintainers" of any specific packages in Ubuntu: it's all rather team-oriented. | 13:03 |
| persia | If you need a decision, that needs someone specifically familiar with tiemu, which makes it extra complicaed. | 13:04 |
| persia | On the other hand, if you care about tiemu, and want to keep it going well, there's no reason you can't be the person who takes care of it. | 13:05 |
| persia | (looks like nobody has given it much thought for the past year or so) | 13:05 |
| papo | persia: I mean the patch is not trivial in some sense. I'm changing something which is done the wrong way in my opinion and the implement this properly needs quite some testing. tiemu can implement several calculators and I'm just using one etc. | 13:05 |
| papo | yep indeed | 13:05 |
| VK7HSE | cjwatson: sorry I got called away from the PC!... just read the result about it already being done so I'll pick another one to have a try at!... | 13:06 |
| persia | papo, With a bit more looking, it appears there is no tiemu maintainer, either in Debian or Ubuntu. | 13:08 |
| papo | aw | 13:08 |
| persia | And nobody who made significant changes in a while. It may as well be you, if you're up for it. | 13:08 |
| papo | well I could do it. I've been Debian maintainer some years ago and started the developer process thing but I had to give it away because if time issues | 13:09 |
| papo | now things look better again | 13:09 |
| cjwatson | if you're looking for a tiemu expert, I suspect the best person to talk to would be the upstream maintainer ... | 13:10 |
| persia | papo, Given that it's orphaned in Debian, I'd recommend reviewing the bugs (in both LP and the BTS), and pushing the new version there. If that takes too long, please come back, and we'll help you get it here first. | 13:10 |
| cjwatson | (assuming they're still active) | 13:10 |
| papo | cjwatson: yes they are active | 13:11 |
| papo | cjwatson: I'm about to hand in my patch there too, of course | 13:11 |
| Toadstool | good afternoon everybody | 13:11 |
| papo | persia: Ok, I'll check with my favorite debian sponsor then | 13:13 |
| DktrKranz | didrocks: I tried to import modules (debug ones too) and they work. If you have a test case to run, I could launch it | 13:14 |
| persia | papo, Thanks a lot! It's always great to see someone take over one of these orphaned packaged. | 13:14 |
| persia | hey Toadstool | 13:14 |
| papo | yw | 13:15 |
| Toadstool | hi persia | 13:15 |
| didrocks | DktrKranz: it seems to be ok. I tested it too and it's working. I ask pitti and he sponsored it before Alpha-1 | 13:16 |
| didrocks | DktrKranz: thanks a lot for your help. I'm a little more confident with python packages now :) | 13:16 |
| DktrKranz | didrocks: has it been uploaded already? | 13:17 |
| didrocks | DktrKranz: It seems that pitti did. I pushed it into bzr | 13:23 |
| DktrKranz | cool :) | 13:23 |
| didrocks | DktrKranz: thanks again for your help :) | 13:23 |
| DktrKranz | you're welcome ;) | 13:24 |
| VK7HSE | I need a mentor! I've just uploaded to my LP PPA "libhtml-parser-perl" ( https://launchpad.net/~vk7hse/+archive/ppa ) could some one please take a look once this has build please.. | 13:24 |
| quadrispro | ouch | 14:03 |
| jmehdi | I need help with this package: http://revu.ubuntuwire.com/details.py?package=webstrict, I've uploaded several versions but they don't appear (and I think they should be removed so I could upload a good new version) | 14:28 |
| ScottK | cemc: Did you look into merging qpsmtpd? | 14:28 |
| mok0 | jmehdi: just upload the last good version | 14:29 |
| mok0 | jmehdi: last upload was 22. Feb 2009 18:27 | 14:29 |
| jmehdi | mok0: I've uploaded yesterday... | 14:30 |
| mok0 | jmehdi: ah :-) | 14:30 |
| jmehdi | mok0: are there errors with them? (that I could fix before uploading the good one) | 14:31 |
| cemc | ScottK: not yet, but I will | 14:31 |
| ScottK | OK. | 14:31 |
| mok0 | jmehdi: uhm, if you have a better upload, it's not worth wasting MOTU time by reviewing an outdated version | 14:32 |
| jmehdi | mok0: no I want Motu to review my 1.4 version | 14:33 |
| jmehdi | mok0: do you see my yesterday uploads? | 14:34 |
| mok0 | jmehdi: hang on | 14:34 |
| === asac_ is now known as asac | ||
| mok0 | jmehdi: yes I see them | 14:35 |
| mok0 | jmehdi: looks like they're in the wrong place for some reason | 14:36 |
| jmehdi | mok0: did I do something wrong? | 14:38 |
| mok0 | jmehdi: no | 14:38 |
| mok0 | RainCT: you have time to help with revu? | 14:38 |
| mok0 | RainCT: some uploads are stuck and don't appear | 14:38 |
| RainCT | Hey mok0 | 14:39 |
| RainCT | sure | 14:39 |
| mok0 | RainCT: looks like they're stuck in /srv/uploads | 14:40 |
| mok0 | RainCT: guessing process_uploads.sh should run but not sure | 14:42 |
| RainCT | mok0: "sudo /srv/move_uploads.sh" is the command, but there's nothing for it to process right now | 14:43 |
| mok0 | RainCT: in /srv/uploads? | 14:43 |
| RainCT | mok0: OK, I see. The stuff in uploads/ are binary uploads | 14:46 |
| RainCT | So REVU doesn't want them | 14:46 |
| RainCT | it's all _i386.changes (and one _amd64.changes) containing a .deb, instead of _source.changes uploads | 14:47 |
| mok0 | RainCT: ah | 14:48 |
| mok0 | jmehdi: you DID do something wrong :-) | 14:48 |
| jmehdi | I knew it ! :) | 14:48 |
| jmehdi | actually I've used "bzr builddeb" then dput revu | 14:49 |
| mok0 | jmehdi: you need to dput your _source.changes file | 14:49 |
| mok0 | jmehdi: ah bzr is above my level of knowledge | 14:49 |
| james_w | bzr builddeb -S | 14:49 |
| * mok0 is not friends with bzr | 14:49 | |
| mok0 | In fact bzr hates me | 14:49 |
| mok0 | Right RainCT? | 14:50 |
| RainCT | Haha | 14:50 |
| mok0 | RainCT: PS I will branch your version and try again | 14:51 |
| jmehdi | james_w: thanks! so simple :) | 14:51 |
| mok0 | bzr is a victim of freeping creaturism if you ask me | 14:52 |
| dholbach | Vorian: I just had a look at StephenStalcup/PbuilderFoo - it's a bit similar to what pbuilder-dist does, right? | 14:52 |
| jmehdi | great, my 1.4 version is displayed now :) If someone could review it (http://revu.ubuntuwire.com/details.py?upid=5737) | 14:55 |
| jmehdi | a question about versioning, the webstrict upstream app has a 1.4 version, the package is 1.4-0ubuntu1. If I have something to update in my package files, which version should I put? | 14:57 |
| persia | dholbach, Almost precisely the same thing, but targeted differently. I remember some discussion during a recent application. | 14:57 |
| persia | jmehdi, In short, 1.4-0ubuntu2 | 14:58 |
| persia | The part before the '-' is the "version", and the part after the '-' is the "revision". The version should match the version of the upstream release, and the revision be incremented as there are distribution changes. | 14:58 |
| Vorian | dholbach: yeah? | 14:58 |
| jmehdi | persia: thanks ;) | 14:59 |
| Vorian | persia doesn't like it at all irrc, but for idiots like me it's much easier to understand | 14:59 |
| persia | Vorian, Hrm? | 15:00 |
| Vorian | pbuilder-foo | 15:00 |
| Vorian | you didn't like the duplication or some such | 15:01 |
| persia | I thought it was duplicate, until you explained the target audience. I still think that integration would be good, but that doesn't mean that what you've done isn't useful. | 15:01 |
| Vorian | ah, ok | 15:01 |
| persia | Sorry for any confusion. | 15:02 |
| Vorian | :) no need to apologize | 15:03 |
| jmehdi | a question about revu: the review process could not be more "automatic"? I mean, my webstrict package has been reviewed by persia and rainct, but I don't want to bother them again and again... | 15:09 |
| jmehdi | There could be a kind of "queue" with all requests and MOTU could review them one after the other, so no request is forgotten | 15:09 |
| jmehdi | and so we wouldn't have to ask MOTUs directly... | 15:10 |
| persia | There is a queue of sorts. | 15:10 |
| persia | That's the point of the REVU interface, to provide things in a date-sorted order. | 15:10 |
| persia | Unfortunately, the reviewers were never quite able to keep up with the queue, and many reviewers prefer to review for people active here, which complicates things. | 15:11 |
| artfwo | hello! I actually came to bother the MOTU with a request to review http://revu.ubuntuwire.com/p/supercollider - a really neat software synthesizer! | 15:11 |
| artfwo | (but with a pretty hairy package) | 15:12 |
| persia | Right. I owe you that one :) | 15:12 |
| jmehdi | persia: ok I understand | 15:13 |
| artfwo | persia: I also fixed a couple of notices you gave me during your review of scantailor | 15:13 |
| jmehdi | persia: so we should be active here and bother you to make things progress ;) | 15:13 |
| === RainCT_ is now known as RainCT | ||
| persia | artfwo, Please don't use so many lintian overrides. It's better to leave warnings you aren't going to fix, unless you have some reason to believe lintian is wrong in the case of your package. | 15:13 |
| artfwo | but last year I have been told to override them all just here at #ubuntu-motu! | 15:14 |
| persia | And at least some of these have the potential to cause all sorts of issues (e.g. sharedobject-in-library-directory-missing-soname | 15:14 |
| jmehdi | btw how long does it take to review a package? | 15:14 |
| persia | Bother. | 15:14 |
| persia | jmehdi, Between 2 days and 2 years, depending on a very large number of variables. | 15:14 |
| jmehdi | persia: actually I mean just to review an upload, not for the package to be approved | 15:15 |
| RainCT | artfwo: overrides are only to hide warnings which are wrong (be it because lintian has a bug and gives a false positive, or because for some special reason the warning doesn't concern your package) | 15:15 |
| persia | artfwo, I don't suppose you remember who suggested that, do you? I'd like to debate it with them. | 15:15 |
| persia | artfwo, An example of an override you *do* want is the supercollider-emacs warning. | 15:16 |
| mok0 | jmehdi: keep asking every hour or so... :-) | 15:16 |
| persia | Um, no, that's counter-productive. | 15:17 |
| persia | Asking every day (or every couple hours during REVU day) is better. | 15:17 |
| bddebian | Heya gang | 15:18 |
| jmehdi | persia: ok | 15:18 |
| artfwo | persia: overrides have been suggested by mok0 | 15:19 |
| persia | mok0, Could you explain why it's a good idea to override everything? | 15:19 |
| artfwo | and at least sharedobject-in-library-directory-missing-soname is okay | 15:19 |
| artfwo | supercollider always had a monolithic api | 15:20 |
| mok0 | persia: I suggested that? | 15:20 |
| mok0 | artfwo: I am lost | 15:20 |
| mok0 | Ah you are talking about sc | 15:20 |
| artfwo | yes | 15:21 |
| * mok0 refreshes memory | 15:21 | |
| mok0 | artfwo: what overrides are you talking about? I am confused | 15:22 |
| artfwo | mok0: lintian overrides in http://revu.ubuntuwire.com/p/supercollider | 15:23 |
| persia | Having stuff in /usr/lib (and not /usr/lib/sc) without a soname is just worrisome to me, and rpath breaks all sorts of things far too often. | 15:23 |
| mok0 | artfwo: good news is that it builds | 15:23 |
| artfwo | persia: but it's the upstream way of doing things | 15:24 |
| artfwo | is it rightful to break the upstream way in a package? | 15:24 |
| directhex | yes | 15:24 |
| mok0 | ah | 15:24 |
| mok0 | artfwo, persia I don't recommend all of these overrides | 15:24 |
| persia | artfwo, Generally we provide a fake SONAME whilst trying to teach upstream the error of their ways. | 15:25 |
| mok0 | artfwo: you should not override things that are fixable | 15:25 |
| persia | mok0, That's what I thought :) | 15:25 |
| artfwo | but these things just don't seem fixable to me | 15:25 |
| mok0 | But, for example the "desktop-command-not-in-package" are intended to be so, so there it makes sense to override | 15:26 |
| persia | Right. That's a well-used override. | 15:26 |
| artfwo | well, what about binary-without-manpage for scvim scripts? | 15:26 |
| artfwo | they're never called by a user directly | 15:26 |
| mok0 | artfwo: that's fixable :-) | 15:26 |
| persia | (well, in this case. overriding to avoid issues with e.g. gnome-sudo is wasteful, and it's better to leave the error lying around in case someone ports it to a more sensible privilege escalation method). | 15:26 |
| persia | artfwo, The manpage should *say* they oughtn't be called, or the scripts should be placed in /usr/lib/supercollider (which won't trigger the lintian warning). | 15:27 |
| mok0 | artfwo: the rpath thing you can fix | 15:27 |
| RainCT | Why are they in /usr/bin at all (if they are there, I'm just guessing) if users won't want to call them? | 15:27 |
| RainCT | Ah nvm, guess that was a stupid question :) | 15:28 |
| artfwo | is rpath always evil? | 15:29 |
| mok0 | A rhetorical question... | 15:29 |
| persia | rpath isn't always evil, but it's almost never used correctly. | 15:29 |
| mok0 | artfwo: not if it's set right | 15:29 |
| mok0 | persia: actually, when using autotools (correctly) it gets set to /usr/bin (for example) | 15:29 |
| persia | And there's a strong argument that there's no good reason to use rpath for distro-supplied software, and that it ought be left to 3rd party stuff that needs to use e.g. /opt | 15:29 |
| RainCT | directhex: http://bugzilla.gnome.org/show_bug.cgi?id=582332 that's one for you ;) | 15:30 |
| ubottu | Gnome bug 582332 in Core "gmcs2 is not detected as a valid gmcs" [Normal,Unconfirmed] | 15:30 |
| artfwo | but if I keep two supercolliders in my system? for example in /usr and /usr/local? | 15:30 |
| artfwo | rpath will allow to pick a right library, right? | 15:30 |
| persia | Um, sorta. | 15:31 |
| persia | It depends on how your loader is configured, etc. | 15:31 |
| artfwo | hmmm | 15:31 |
| persia | But you *don't* want to do that without SONAMEs: that way lies madness. | 15:31 |
| mok0 | artfwo: if you have a supercollider in /usr/local, it would not come from a package | 15:31 |
| artfwo | okay, I will try building/running supercollider without rpath and get rid of those pesky warnings | 15:32 |
| persia | Better is to have SONAMEs, and then have the libraries installed both in the library path somewhere, and pick the right one based on the SONAME, rather than guessing based on the path. | 15:32 |
| mok0 | Yikes it's using scons ... *shudder* | 15:33 |
| artfwo | persia: does that mean to create libsclang.so.3.3 instead of libsclang.so? | 15:33 |
| directhex | RainCT, replied. | 15:33 |
| persia | artfwo, Right. | 15:33 |
| artfwo | so | 15:33 |
| RainCT | directhex: thanks | 15:33 |
| artfwo | persia: can I just move lib*.so into lib*.so.3.3 in debian/tmp after "make install"? | 15:34 |
| mok0 | artfwo: before linking the application | 15:36 |
| mok0 | artfwo: you need lib*.so as a symlink to the so.3.3 file | 15:37 |
| artfwo | but I could provide a libsclang.so symlink to libsclang.so.3.3 | 15:37 |
| mok0 | artfwo: right | 15:37 |
| artfwo | and do it even after the linking | 15:37 |
| mok0 | artfwo: hm, not sure that will work | 15:37 |
| persia | Except that the contents of the file needs to contain the SONAME as well. | 15:37 |
| persia | So, you need to declare the SONAME during the build, and have the filename match that declaration. | 15:38 |
| persia | And you want the applications to use the real library. /usr/lib/libfoo.so should be a symlink, but only in the -dev package. | 15:38 |
| artfwo | this will certainly require rewriting the entire supercollider build system from scratch | 15:39 |
| mok0 | artfwo: hurray for scons :-/ | 15:39 |
| mok0 | p.o.s. | 15:39 |
| persia | scons makes it especially fun to fix these issues. | 15:39 |
| mok0 | Problem is, most upstreams don't know squat about installing software in a distribution | 15:40 |
| persia | artfwo, In other news, you'd probably benefit from using dh_install for some stuff. | 15:40 |
| artfwo | well, okay | 15:40 |
| persia | And you don't want anything directly in /usr/share/doc, it belongs in /usr/share/doc/${package}/ | 15:41 |
| persia | (or use dh_installdocs) | 15:41 |
| artfwo | I don't have anything in /usr/share/doc | 15:41 |
| persia | artfwo, install -m 644 editors/sced/README $(DEB_DESTDIR)/usr/share/doc/README.gedit | 15:41 |
| artfwo | let me see | 15:41 |
| artfwo | persia: this is temporary | 15:42 |
| persia | OK. In that case, I'm just being confused. | 15:42 |
| artfwo | I install them with dh_installdocs later (see top of debian/rules) | 15:42 |
| persia | Right. I guess I would have done that with debian/${package}.docs, which is why I'm confused. | 15:43 |
| persia | Or for that matter, I probably would have just used the original location, rather than copying into a temporary location. | 15:43 |
| artfwo | I just decided to avoid overstuffing debian/ directory even more that it is stuffed now | 15:43 |
| persia | And I'd also probably not use so many internal CDBS targets, rather using the recommended standard overrides. | 15:45 |
| artfwo | persia: I tried that, but didn't find a convenient cdbs class for that | 15:46 |
| artfwo | so in the end I've simply written all the targets from scratch | 15:46 |
| persia | artfwo, https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml#id489203 | 15:46 |
| artfwo | omg, I should have found that earlier | 15:47 |
| persia | although I'd probably not even bother with CDBS if I needed that much customisation. CDBS is black magic, and when you have a CDBS rules file that doesn't fit in one screen (24 lines), confusion is a common result. | 15:47 |
| mok0 | Hrpm, /me thinks the .symbols file adds more problems than it solves | 15:48 |
| Riddell | savvas: https://lists.ubuntu.com/archives/ubuntu-archive/2009-May/026881.html (incase it gets trappen in gmail spam filter) | 15:48 |
| directhex | not to be confused with dh7, which is voodoo magic rather than black magic | 15:48 |
| mok0 | persia: CDBS is not black magic, it's a macro package ;-) | 15:48 |
| savvas | Riddell: hi, just talking to bddebian to review and upload the new fixed version :) | 15:49 |
| persia | mok0, See, I use either CDBS or /usr/share/doc/debhelper/exampes/rules.tiny for everything I package, and I strongly disagree. Both are best managed with grimoires, rather than actual comprehension. | 15:49 |
| Riddell | savvas: and upstream too? | 15:49 |
| mok0 | persia: I agree that a lot of customization makes CDBS incomprehensible | 15:50 |
| persia | mok0, And the huge value of .symbols is in actually reminding one to do transitions. It's rather frustrating when a change slips by and nobody notices until release (yes, this has happened). | 15:50 |
| mok0 | persia: sometimes you can make do with 2-3 lines | 15:50 |
| savvas | Riddell: it's fixed from the debian maintainer upstream, it's already on revu: http://revu.ubuntuwire.com/p/gnote diff: http://revu.ubuntuwire.com/report.py/diff?upid1=5720&upid2=5726 | 15:50 |
| persia | mok0, Indeed. My personal limit is 24 lines. More than that makes it not worth it. Much like I wouldn't use %: for dh7 unless I can fit it on the screen. | 15:51 |
| mok0 | persia: re: symbols, they seem to be arch dependent | 15:51 |
| savvas | Riddell: could you check it and note if there's anything else that should be included? | 15:51 |
| directhex | oh, excellent, copyrightformat | 15:51 |
| persia | mok0, Well, depends on the library. For well coordinated libraries, they oughtn't be so. | 15:51 |
| directhex | i like machine-readable copyright | 15:51 |
| mok0 | persia: Well. What can I say? | 15:52 |
| persia | heh :) | 15:52 |
| mok0 | persia: Looking at FTBFS's because of it | 15:52 |
| artfwo | persia: okay, I will try to cleanup the debian/rules jungle, but we have not finished with lintian warnings yet. what would you say about package-contains-empty-directory? | 15:53 |
| Riddell | savvas: it should be included by upstream and it should be called COPYING-DOCS, that's what the files say | 15:53 |
| persia | Right, but that means something ought be fixed in the library. If the symbol set changes on a per-architecture basis, then it's unclear whether one can expect to have the package actually work in a cross-architecture fashion (and moreso dependent packages). | 15:53 |
| mok0 | artfwo: that's fine, because it's intended to be empty | 15:54 |
| artfwo | okay! | 15:54 |
| savvas | Riddell: ah, got it, gnote upstream - thanks I'll forward the request :) | 15:55 |
| artfwo | the last one remain in "supercollider-vim" file | 15:55 |
| mok0 | artfwo: so having an override is saying: "I know, it's supposed to be that way" | 15:55 |
| artfwo | mok0: understood, thanks! | 15:55 |
| persia | But you have to understand the error, and understand why it *shouldn't* be fixed. | 15:55 |
| artfwo | yes, I am aware of the empty Extensions directory | 15:56 |
| persia | It's better to leave some lintian noise because it's not worth fixing some stuff than to override something that might actually need fixing. | 15:56 |
| artfwo | supercollider just won't start without it in the filesystem | 15:56 |
| mok0 | artfwo: of course, another way to get around it is to place a dummy file in the directory saying "this directory is empty" :-) | 15:56 |
| artfwo | that seems an even better fix, great idea! | 15:57 |
| mok0 | artfwo: say what it's supposed to hold (plugins?) | 15:57 |
| artfwo | nope, just the extra classes | 15:57 |
| mok0 | ok | 15:57 |
| artfwo | I'd like to ask about supercollider-vim overrides as well | 15:58 |
| artfwo | binary-without-manpage and script-with-language-extension | 15:58 |
| artfwo | and how to resolve them the best way | 15:58 |
| persia | Rather than a dummy file, how about a README file explaining the purpose of the directory, etc. | 15:59 |
| mok0 | artfwo: these are the not-user-callable scripts? | 15:59 |
| artfwo | persia: right, I intented to do just that | 15:59 |
| persia | Anything not used by users doesn't belong in /usr/bin | 15:59 |
| persia | (it's the directory for *user* *binaries*) | 15:59 |
| artfwo | mok0: not user callable, exactly | 15:59 |
| mok0 | artfwo: from _where_ are these scripts executed, do you know? | 16:00 |
| artfwo | from /usr/bin/scvim | 16:00 |
| mok0 | artfwo: because the right thing to do is to place them in /usr/lib/supercollider | 16:00 |
| mok0 | artfwo: but then you need to make sure that scvim calls them with the correct path | 16:01 |
| artfwo | scripts in /usr/lib? | 16:01 |
| artfwo | will not /usr/share suffice? | 16:01 |
| mok0 | artfwo: yes /usr/lib/progname | 16:01 |
| mok0 | artfwo: for example /usr/lib/update-manager | 16:02 |
| persia | /usr/share could work, but that sort of thing traditionally goes in /usr/lib/${package}, because you don't know that the implementation won't change over time. | 16:02 |
| persia | (e.g. python -> C) | 16:02 |
| artfwo | well, this will not get rid of script-with-language-extension warning, or will it? | 16:02 |
| mok0 | artfwo: it should get rid of that warning | 16:03 |
| artfwo | ah | 16:03 |
| mok0 | artfwo: policy is that scripts in /usr/bin must not have an extension (i.e. .py or .sh) | 16:03 |
| artfwo | it works on any script in PATH | 16:03 |
| artfwo | okay | 16:04 |
| mok0 | artfwo: what do you mean "it works"? | 16:04 |
| artfwo | the lintian warning | 16:04 |
| artfwo | is triggered by any script in PATH, that's what I meant | 16:04 |
| mok0 | artfwo: normally, the user would not have /usr/lib/supercollider in the path | 16:04 |
| persia | TO get rid of script-with-language-extension, just rename the file (and change the call). This is essential to have a clean interface in case you want to change the implementation later | 16:04 |
| persia | (yes, you can write a python program ending in .sh, or a shell program ending in .py, but that's just ugly) | 16:05 |
| mok0 | persia: I agree... .py is for modules | 16:05 |
| artfwo | persia: understood, but in my case it's better to move 'em down /usr/lib to get rid of manpage warning as well | 16:06 |
| artfwo | and of course, because of /usr/bin intended meaning | 16:06 |
| persia | artfwo, My apologies if I wasn't clear: I'm suggesting you move them *and* rename them. | 16:06 |
| artfwo | which I have learnt by now :) | 16:06 |
| artfwo | thanks for your explanations | 16:06 |
| mok0 | artfwo, persia, I think it's about hitting a balance of doing the packaging right, and not making too many changes in upstreams naming | 16:07 |
| artfwo | right | 16:07 |
| persia | mok0, In general, I agree, except for things like script-with-language-extension. I've been burnt by that a couple times, and it's *hard* to fix. | 16:07 |
| mok0 | artfwo, persia, I would keep the .rb extensions, but just place the files in /usr/lib/... | 16:07 |
| mok0 | persia: hm | 16:07 |
| persia | mok0, Imagine the case where something else integrates with supercollider, and then supercollider uses python instead of ruby. One has to grep the entirety of rdepends... | 16:08 |
| mok0 | persia, artfwo, just make sure the script is called by it's full path | 16:08 |
| persia | Doesn't help. | 16:08 |
| artfwo | I think I shall simply fix it upstream then | 16:08 |
| mok0 | artfwo: you are upstream? | 16:09 |
| artfwo | yes, I maintain a part of the upstream svn and have commit access to it | 16:09 |
| * mok0 puts foot-in-mouth for bad-mouthing upstreams :-) | 16:10 | |
| artfwo | that's why I thought it would be easier to port the entire build system to WAF or anything, but not scons | 16:10 |
| mok0 | WAF? | 16:10 |
| artfwo | yes, it's an all new scons replacement | 16:11 |
| mok0 | artfwo: oh I see | 16:11 |
| === dendrobates_ is now known as dendrobates | ||
| mok0 | FWIW, gnu autotools are my personal favourite | 16:11 |
| artfwo | but I'd like to hear more weak spots in my package | 16:11 |
| mok0 | Works on UNIX as well | 16:12 |
| artfwo | anything else, you can notice at a glance, guys? | 16:12 |
| artfwo | are copyright, control, etc. okay? | 16:12 |
| mok0 | artfwo: looks ok | 16:13 |
| mok0 | artfwo: last time I looked at the package (sometime this winter) it didn't build for me, so this is a biiiig improvement | 16:14 |
| artfwo | mok0: for every REVU upload I did a local test-build and PPA-build | 16:14 |
| persia | artfwo, I'd still like it to work on 64bit, but I know that's probably outside what packaging can manage :) | 16:14 |
| artfwo | persia: but they manage to get it working! | 16:15 |
| persia | Um, kinda. | 16:15 |
| persia | Your package still only builds for i386, powerpc, and lpia :) | 16:15 |
| mok0 | artfwo: Well. Now it builds for me too... no point in going back and debugging those problems now | 16:15 |
| persia | (you might add armel to the list, because it's 32-bit, but that depends on someone having armel with working sound to test) | 16:16 |
| artfwo | persia: the server builds for amd64 as well | 16:16 |
| persia | I know. The problem was only ever with the client. | 16:16 |
| mok0 | artfwo: but does the app work? | 16:17 |
| persia | (overloading a 64-bit data block with a 32-bit integer & a pointer) | 16:17 |
| artfwo | mok0: yes, you can even install the packages in a 32-bit chroot on an amd64 system and run supercollider with a 64-bit server running in the parent system (with 64-bit JACK and stuff) | 16:17 |
| mok0 | persia: in a union or something? | 16:17 |
| mok0 | artfwo: ok sounds good | 16:18 |
| mok0 | artfwo: you might get in touch with ubuntu-studio, they'd be interested I would think | 16:18 |
| mok0 | artfwo: seems to be an app right up their alley | 16:19 |
| persia | mok0, Yep. | 16:19 |
| artfwo | I thought persia is the right contact for ubuntustudio anyway, are you? | 16:19 |
| persia | It used to be in ubuntustudio, but it got pulled entirely from Ubuntu for failing to build, and not having supportive upstream. | 16:19 |
| persia | I am a member of the ubuntustudio-dev team, but probably one of the least active memebrs. | 16:20 |
| mok0 | ah, that obviously changed now :-) | 16:20 |
| persia | Yes. Now there is a supportive upstream, and it's *lots* less broken. | 16:20 |
| mok0 | It'll be good to get it out there so users can stress-test it | 16:20 |
| artfwo | the current semi-official way to have supercollider in Ubuntu is the supercollider-team PPA in Launchpad | 16:21 |
| persia | Which is good as far as semi-official goes. | 16:21 |
| mok0 | it is | 16:21 |
| mok0 | artfwo: did you get some response from users? | 16:22 |
| artfwo | yes, lots of | 16:22 |
| artfwo | http://artfwo.blogspot.com/2008/04/supercollider-for-hardy.html | 16:22 |
| artfwo | http://artfwo.blogspot.com/2008/05/supercollider-for-human-beings.html | 16:22 |
| persia | It's probably also worth getting it back into Debian, once it's clean. debian-multimedia would be a good point of contact for that. | 16:22 |
| artfwo | this is in fact, a second question I came to ask today | 16:23 |
| artfwo | I have another package reviewed and uploaded | 16:23 |
| artfwo | and I would like to send it to Debian as well, once it moves out of the karmic queue | 16:23 |
| persia | artfwo, Which package? | 16:24 |
| artfwo | persia: scantailor | 16:24 |
| mok0 | artfwo: that makes sense. Getting into Debian can be quite a length process | 16:24 |
| artfwo | ah | 16:24 |
| persia | Oh, right. I remember looking at that one. | 16:24 |
| artfwo | it JUST got rejected from the archives! | 16:24 |
| persia | Dunno who in Debian would be a good contact for that. | 16:25 |
| artfwo | https://lists.ubuntu.com/archives/ubuntu-archive/2009-May/026882.html | 16:25 |
| persia | (and it's *lots* easier to get a package into Debian if there is an interested DD) | 16:25 |
| mok0 | artfwo: ah that's an easy fix | 16:25 |
| artfwo | but it's wrong to reject CC-3.0! | 16:25 |
| mok0 | artfwo: just fix it and ask the sponsor to upload again | 16:25 |
| mok0 | artfwo: then write jriddell about it | 16:26 |
| persia | artfwo, If it's wrong, argue it. some cc-3.0 is GPL compatible. Depends on the type of CC license. | 16:26 |
| persia | But some of it isn't, so do triple check. The FSF website has a nice page about license compatibility. | 16:27 |
| mok0 | Indeed | 16:27 |
| artfwo | I've checked it against http://wiki.debian.org/DFSGLicenses | 16:27 |
| persia | artfwo, It's not enough that the individual licenses be DFSG free, they also have to be compatible. | 16:28 |
| mok0 | artfwo: if that's what it says about that arrow icon, your case is clear | 16:29 |
| artfwo | may I paste a 3-line excerpt from my debian/copyright about that? | 16:30 |
| artfwo | Files: resources/icons/arrow_in.png | 16:31 |
| artfwo | Copyright: Mark James, http://www.famfamfam.com/lab/icons/silk/ | 16:31 |
| artfwo | License: CC-BY-2.5 or CC-BY-3.0 | 16:31 |
| mok0 | artfwo: go ahead | 16:31 |
| mok0 | see http://www.gnu.org/licenses/license-list.html | 16:31 |
| artfwo | mok0: that page does not mention this license at all | 16:32 |
| mok0 | at the very bottom. | 16:32 |
| mok0 | oh | 16:32 |
| artfwo | at the silk icons website, the author mentions he double-licensed his work specially for debian | 16:33 |
| Riddell | you're mixing up two issues artfwo | 16:34 |
| persia | It's funny: lots of people change the license because of the DFSG, but it's against the DFSG for the license change to be specific to Debian. | 16:34 |
| Riddell | first the freedom of a licence. CC-BY-2.5 is not free according to Debian, CC-BY-3.0 is | 16:34 |
| artfwo | Riddell: but this specific icon is double-licensed, so it's okay to upload, right? | 16:34 |
| Riddell | secondly, the one we're converned with here, is the compatibility of two licences. because this app compiles all the source code and icons into one single binary they must be licenced such that they can both be copied under the same terms | 16:35 |
| artfwo | oh | 16:35 |
| mok0 | Riddell: license applies to source code, no? | 16:35 |
| persia | mok0, license applies to bits. | 16:35 |
| persia | In the case where the image is compiled into the executable, it becomes part of the source. | 16:36 |
| Riddell | CC-BY-3.0 and GPL are both free but in slightly different ways so they can't be used for different parts of a single binary | 16:36 |
| Riddell | KDE doesn't use qt resources files for just this reason | 16:36 |
| Riddell | artfwo: but it's only one icon, there must be a substitute which could be found | 16:37 |
| artfwo | I shall better contact the upstream about this | 16:37 |
| mok0 | There ought to be a set of standard icons anyway | 16:38 |
| Riddell | yes please | 16:38 |
| Riddell | mok0: Oxygen! | 16:38 |
| mok0 | artfwo: ok, so perhaps you can use the oxygen icons instead | 16:38 |
| mok0 | artfwo: makes for a more uniform GUI | 16:39 |
| artfwo | just one icon and you cannot package software with it! | 16:39 |
| artfwo | mok0 Riddell what license is best to pick, if we have to choose from? | 16:41 |
| mok0 | artfwo: same as the application itself | 16:42 |
| artfwo | GPL-3 it is then | 16:42 |
| artfwo | or GPL-2+ | 16:42 |
| Riddell | LGPL 3 or later is used by Oxygen | 16:42 |
| mok0 | Riddell: can that be compiled into a binary then? | 16:43 |
| Riddell | mok0: it can be compiled into an otherwise GPL binary yes | 16:43 |
| mok0 | oh, like libc I guess | 16:43 |
| artfwo | by the way, my other package (supercollider) has CC-BY-SA-3.0-licensed documentation - will it pass the GPL compability test? | 16:44 |
| persia | GPL icons aren't any different than GPL C code. For an extreme example, cat some .xpm file. | 16:44 |
| persia | artfwo, Yes, because they aren't being put into a combined file. That's just amalgamation (documentation and programs). | 16:45 |
| Riddell | artfwo: yes that's fine (it would be an issue if the docs get compiled into a binary file with GPL code, but docs tend not to do that) | 16:45 |
| artfwo | okay, understood | 16:45 |
| * mok0 likes the WTFPL license | 16:47 | |
| persia | Note that it's not an issue to compile the docs with a GPL tool, only to mix GPL and non-GPL sources to get a target. | 16:47 |
| mok0 | http://sam.zoy.org/wtfpl/ | 16:47 |
| persia | mok0, It's untested, and probably invalid in some places (I doubt it's valid here, for example) | 16:47 |
| mok0 | persia: yes, you probably can't take something under GPL and relicense it under WTFPL | 16:48 |
| persia | Not unless you hold copyright over it, no. | 16:48 |
| mok0 | It's not copyleft though | 16:49 |
| persia | But to me the issue is more that I'm not sure I'd be granting my users the freedom I desire, because I'm not sure that such a declaration is valid in some jurisdictions. That's why I like the ISC license, because it was drafted to match the language of the Berne Convention. | 16:49 |
| savvas | are the nvidia drivers free for redistribution? | 16:50 |
| persia | savvas, Check debian/copyright :) | 16:50 |
| artfwo | mok0, Riddell, persia is it okay to include just one license text of two in debian/copyright if an icon is dual-licensed? | 16:50 |
| persia | (or /usr/share/doc/${package}/copyright if that's easier to access) | 16:50 |
| savvas | hmm.. "Please feel free to redistribute the NVIDIA graphics driver." < I guess this answers my question :) | 16:50 |
| persia | artfwo, I prefer to include both, to extend the freedom of choice to users of my packages, but technically you only have to provide the license under which you're offering the software. | 16:51 |
| mok0 | artfwo: Riddell is the authority on this... I think you need to specify the one of the two licenses you have chosen | 16:51 |
| cjwatson | you can offer it under either | 16:51 |
| cjwatson | I mean, if you receive it under a dual-licence, you can usually pass on that dual-licensing when redistributing | 16:52 |
| persia | Or select a license, although passing the choice on is more polite to users. | 16:52 |
| mok0 | persia: I prefer GPL type licenses because they maintain the software in the free domain | 16:52 |
| mok0 | persia: ISC or BSD licenses can get ripped off by someone not wanting to give back | 16:53 |
| mok0 | s/licenses/licensed software/ | 16:53 |
| mok0 | persia: I ok with people ripping me off if I can rip them back :-) | 16:54 |
| persia | mok0, I can understand that. I suspect it depends on what you write. Most of what I write is glue (small scripts, etc.), and I'd rather give others the right to use it generally because my purpose has been served merely by it's existence. If one is driving a more complex project, I can see the argument for a freedom-enforcing license. | 16:54 |
| === mkorn is now known as thekorn | ||
| ScottK | I think a lot of it depends on your purpose. | 17:00 |
| ScottK | I've been involved in projects that were BSD licensed because we were trying to spread new technology across the internet. We wanted proprietary developers to 'rip us off' and provide the technology in their systems. | 17:01 |
| DktrKranz | persia: aolserver transition, are you interested in managing it? I think there are no just rebuilds this time | 17:02 |
| ScottK | My experience with that was that enough of them would rather have upstream maintain their patches that they give them back anyway to make it a net win for available code. | 17:02 |
| DktrKranz | if not, I can have a look after alpha1 to not drain buildds too much | 17:02 |
| persia | DktrKranz, I have absolutely no interest, but a vague sense of responsibility. | 17:03 |
| DktrKranz | ok, I think aolserver itself need love (jaunty -> karmic upgrade path seems bugged) | 17:03 |
| persia | Glah. Does anyone actually use it? | 17:03 |
| DktrKranz | don't know, but there have been some binary split and aolserver4 is no longer thereù | 17:04 |
| artfwo | okay. but how do I replace an icon in my package (to a properly licensed one) - repack the source tarball? | 17:05 |
| persia | OK. I'll take a look at it. Probably can't get to it until Thursday night. | 17:05 |
| persia | artfwo, You don't need to do that, just change the build to use the new icon. If it's only in binary format, uuencode it, and uudecode at build-time (before you link it). | 17:06 |
| * DktrKranz either | 17:06 | |
| artfwo | persia: but this requires backing up the original icon at build time as well. and restoring it on clean | 17:07 |
| persia | Only if you don't patch the build system. | 17:07 |
| persia | I'd probably apply a patch that changed where the compilation was looking for the icon, rather than trying to use the same name and location. | 17:08 |
| artfwo | yes, that is a better solution, thanks! | 17:08 |
| * james_w notes that there are 112 bugs on the sponsors' list] | 17:39 | |
| nxvl | geser: ping | 18:04 |
| === bastiao_ is now known as k0p | ||
| sharms | Bug #328020 | 18:07 |
| ubottu | Launchpad bug 328020 in ncpfs "cannot mount NetWare (ipx) server" [Undecided,Confirmed] https://launchpad.net/bugs/328020 | 18:07 |
| sharms | I have a debdiff which resolves this, can anyone take a look at it for me? It would be an SRU for Jaunty | 18:07 |
| sharms | is there a tag I can apply to the bug that will get it reviewed if not? | 18:12 |
| leonel-vaio | for bug 375513 should be public since is a security bug ??? | 18:26 |
| ubottu | Launchpad bug 375513 in squirrelmail "Multiple CVEs for Squirrelmail <1.4.17" [Undecided,New] https://launchpad.net/bugs/375513 | 18:26 |
| jdstrand | leonel-vaio: if there is a public CVE assignment, the bug should be public | 18:27 |
| leonel-vaio | jdstrand: ok | 18:27 |
| leonel-vaio | jdstrand: it's open while I send the diffs .. | 18:28 |
| jdstrand | though, the security box was not checked (I just did it) | 18:28 |
| persia | sharms, If it's in karmic already (or provably not required in karmic), just follow the SRU process (incuding appropriate team subscriptions). If not, you'll want to fix karmic first. | 18:29 |
| persia | !SRU | 18:29 |
| ubottu | Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates | 18:29 |
| leonel-vaio | jdstrand: I was looking for that .. thank you | 18:29 |
| sharms | persia: it isnt in karmic yet | 18:34 |
| sharms | persia: I attached the debdiff to the report, I need someone to look it over and put it in, I am not motu | 18:34 |
| sharms | for karmic it would just be s/jaunty/karmic/ on the debdiff, everything else should be identical | 18:35 |
| sharms | traditionally, every release we release ncpfs completely broken | 18:35 |
| sharms | then I fix it, submit debdiffs, and then eventually someone takes them and gives them to debian | 18:36 |
| persia | sharms, I know. For a while I even used it, and so was happy for your fixes :) | 18:37 |
| sharms | haha, I dont even use it thats the funny part. I just somehow got subscribed to all of them | 18:37 |
| sharms | I will setup a karmic pbuilder and create a debdiff for that one if that makes it easier | 18:39 |
| persia | It ought. | 18:40 |
| Riddell | cody-somerville, jdong: motu-sru opinion needed on bug 206280 | 18:43 |
| ubottu | Launchpad bug 206280 in xsensors "[hardy] Error opening config file: /etc/sensors.conf" [Undecided,Fix released] https://launchpad.net/bugs/206280 | 18:43 |
| Riddell | cody-somerville, jdong: motu-sru opinion needed on bug 358608 | 18:47 |
| ubottu | Launchpad bug 358608 in claws-mail-extra-plugins "claws-mail-extra-plugins don't match claws-mail version" [Medium,Fix released] https://launchpad.net/bugs/358608 | 18:47 |
| === mdomsch is now known as mdomsch_food | ||
| === ember_ is now known as ember | ||
| james_w | 99 | 18:53 |
| === mdomsch_food is now known as mdomsch | ||
| kklimonda | would someone check bug 371720 - I've managed to trace this bug to old version of tix we are shipping with Jaunty. Most recent version doesn't have this problem. | 19:00 |
| ubottu | Launchpad bug 371720 in python2.6 "python-tkinter-tix program has unknown color error" [Undecided,New] https://launchpad.net/bugs/371720 | 19:00 |
| kklimonda | Also for some reason debian isn't updating their package - probably because watch file isn't pointing in the right direction.. | 19:02 |
| RainCT | directhex: how many CPUs do you have? XD | 19:02 |
| directhex | RainCT, in which box? | 19:03 |
| RainCT | directhex: http://behindmotu.files.wordpress.com/2009/05/screenshot.png | 19:03 |
| directhex | RainCT, ah. it's an intel core i7 processor - quad core, hyperthreaded | 19:04 |
| directhex | so directhex@desire:~$ grep -c i7 /proc/cpuinfo | 19:04 |
| directhex | 8 | 19:04 |
| geser | nxvl: pong | 19:13 |
| === maco_ is now known as maco | ||
| === Adri2000_ is now known as Adri2000 | ||
| Kage[Work] | Can anyone here point me in the right direction for setting up eJabberd 2.0.1 on Hardy using PAM? | 19:36 |
| Kage[Work] | I can't find any good guides | 19:36 |
| sharms | I made a debdiff for Karmic for ncpfs bug #328020 if someone can review that please | 19:40 |
| ubottu | Launchpad bug 328020 in ncpfs "cannot mount NetWare (ipx) server" [Undecided,Confirmed] https://launchpad.net/bugs/328020 | 19:40 |
| === erhesrhsrtb54vyh is now known as Elbrus | ||
| hyperair | ugh. i'm so close to getting uswsusp working perfectly with usplash, but now i've got one problem: uswsusp hangs if usplash is running, whether usplash support is turned on or off. | 19:54 |
| * hyperair curses | 19:54 | |
| mirak | hi | 20:00 |
| mirak | I created a v4l-dvb source package installable with module assistant. do you know how I could submit it to official repositories ? | 20:00 |
| mirak | ko it's in the topic | 20:01 |
| marnold | mirak, see revu.ubuntuwire.com | 20:03 |
| mirak | marnold: I am forced to use karmic ? | 20:06 |
| marnold | if its not an SRU bugfix yes | 20:07 |
| mirak | marnold: can I just rely on chroot and pbuilder ? | 20:10 |
| mirak | I don't want to run karmic as main os | 20:10 |
| marnold | oh thats a horse of a different color | 20:10 |
| marnold | yes | 20:10 |
| marnold | you can use pbuilder | 20:10 |
| mirak | just a last stupid question, I don't see how to upload on revu ^^ | 20:11 |
| marnold | login with your openid from LP | 20:12 |
| marnold | and you should get added to the keyring automagiclly iirc | 20:12 |
| mirak | marnold: I did that of course, | 20:12 |
| mirak | I don't see any upload button | 20:13 |
| mirak | is that with dput maybe | 20:13 |
| marnold | it is | 20:13 |
| mirak | do you know a nice way to have pbuilder for differents distributions ? | 20:14 |
| marnold | just dput revu $yourpackage_source.changes | 20:14 |
| marnold | pbuilder-dist from ubuntu-dev-tools | 20:15 |
| mirak | thanks | 20:16 |
| marnold | if someone could review my patch for #375619 i would appreciate it | 20:21 |
| kklimonda | bug 375619 | 20:22 |
| ubottu | Launchpad bug 375619 in ircd-hybrid "ircd-hybrid conflicts with inspircd" [Undecided,New] https://launchpad.net/bugs/375619 | 20:22 |
| kklimonda | marnold: it would probably be better to work with debian maintainer on this: changes made in ubuntu1 and ubuntu2 were reported in debian bts as debian bug 519136 and debian bug 511611 | 20:27 |
| ubottu | Debian bug 519136 in ircd-hybrid "ircd-hybrid: should create /var/run/ircd at boot time" [Normal,Open] http://bugs.debian.org/519136 | 20:27 |
| ubottu | Debian bug 511611 in ircd-hybrid "ircd-hybrid: Conflicts with the ircd virtual package" [Normal,Open] http://bugs.debian.org/511611 | 20:27 |
| marnold | as i reported one of them i know this | 20:27 |
| kklimonda | marnold: and maintainer still isn't responding? | 20:28 |
| marnold | the maintainer hasn't responded in ~2 months | 20:29 |
| marnold | so i figured it was time for a Ubuntu upload | 20:29 |
| james_w | fair enough | 20:29 |
| kklimonda | yeah, probably | 20:29 |
| marnold | s/a/an | 20:29 |
| kklimonda | marnold: have you tried mailing maintainer? I've had more luck with mailing them directly than with filling bugs :/ | 20:31 |
| === evanrmurphy_ is now known as evanrmurphy | ||
| james_w | ver | 20:33 |
| james_w | p ircd-ircu - Undernet IRC Server daemon | 20:33 |
| james_w | p ircd-ratbox - advanced, stable and fast ircd | 20:33 |
| james_w | p oftc-hybrid - Hybrid 7 IRC daemon - OFTC branch | 20:33 |
| james_w | marnold: any idea whether it installs alongside them? | 20:33 |
| james_w | ah | 20:33 |
| * james_w slaps himself | 20:34 | |
| marnold | james_w, last i knew no but | 20:34 |
| * marnold checks | 20:34 | |
| james_w | any idea whether it installs alongside ircd-ratbox? | 20:34 |
| mirak | marnold: thanks for you help, the package is uploading | 20:34 |
| james_w | that would be the only other change | 20:34 |
| mirak | woops I forgot to build it on karmic ^^ | 20:36 |
| marnold | james_w, looks like at some point in the recent past | 20:37 |
| mirak | marnold: pbuilder dist says karmic is unkown distribution, is that normal ? | 20:38 |
| marnold | they renamed their binary from /usr/sbin/ircd to /usr/sbin/ircd-hybrid | 20:38 |
| marnold | so it should co-exist with 2.8 derived ircds | 20:39 |
| ScottK | mirak: Install the debchroot in jaunty-backports | 20:40 |
| james_w | marnold: sorry, which package did that? | 20:41 |
| marnold | ircd-hybrid | 20:41 |
| marnold | so i'll remove the conflict and if it breaks stuff well karmic is pre-alpha | 20:42 |
| marnold | i see no collisions | 20:42 |
| james_w | nope, I just checked as well | 20:43 |
| ScottK | Don't forget to rename man pages too | 20:43 |
| kmdm | Don't suppose anyone has the MOTU wiki page to hand that has the links into launchpad bug searches? I keep coming across it and promptly forgetting it... e.g. one of the searches filters for bitesize universe bugs, etc... | 20:45 |
| ivoks | is there a list of ftbs packages? | 20:47 |
| mirak | W: http://de.archive.ubuntu.com/ubuntu/dists/karmic/main/binary-amd64/Packages.bz2 | 20:47 |
| mirak | was corrupt | 20:47 |
| mirak | wierd ? | 20:47 |
| kklimonda | so, who is testing ubuntu one and has something interesting to tell about it? ;) | 20:48 |
| ivoks | kklimonda: it works :) | 20:48 |
| kklimonda | ivoks: i surely hope that it does :) | 20:49 |
| loic-m | siretart: ping | 20:49 |
| mirak | scottK oh you meant debootstrap | 20:50 |
| ScottK | It's based on spam marketing principles? <-- ubuntuone | 20:50 |
| ScottK | mirak: Yes. Sorry. I always get them backwards. | 20:50 |
| ivoks | ScottK: spam marketing? | 20:51 |
| ScottK | ivoks: I've never signed up for commercial solicitations from Canonical for their services. | 20:52 |
| kklimonda | i think it's called "Whispered Advertising" ;) | 20:52 |
| RoAkSoAx | ivoks, i'll reply you later... I gtg take care :) | 20:52 |
| ScottK | ivoks: It was unsolicited, it was commercial, and it was email. | 20:52 |
| ScottK | That's spam. | 20:53 |
| directhex | enlarge your ubuntu by 2 gigabytes! | 20:53 |
| ScottK | Exactly. | 20:53 |
| james_w | marnold: uploaded thanks. I took the liberty of expanding the changelog and adding a bug reference, you'll see it when it closes the bug. | 20:53 |
| james_w | it's an odd way to organise a set of packages | 20:54 |
| ivoks | right, it might not be the best approach to anounce it | 20:54 |
| james_w | but then it's an odd set of packages :-) | 20:54 |
| marnold | before i even finished my snack | 20:54 |
| marnold | thanks | 20:54 |
| james_w | np | 20:54 |
| ivoks | anyway, 10PM | 20:54 |
| ivoks | take care everybody | 20:54 |
| james_w | it would have been got to eventually on the sponsors list, you just got lucky ;-) | 20:55 |
| kklimonda | does somebody know why was vmmouse_detect moved from xserver-xorg-input-vmmouse to mdetect? | 20:56 |
| directhex | james_w, i got a freebiw from cjwatson earlier. i wonder if he's getting "you owe me beer" credits lined up for UDS :p | 20:56 |
| directhex | freebie | 20:56 |
| james_w | heh | 20:56 |
| kklimonda | I couldn't contact the person who did it and it's the only delta from new xserver-xorg-input-vmmouse package that is in debian.. | 20:56 |
| james_w | I tend to owe him many beers without any special effort on his part | 20:56 |
| james_w | kklimonda: I don't see any diff | 20:57 |
| maxb | ivoks: http://qa.ubuntuwire.org/ftbfs | 20:57 |
| james_w | oops | 20:57 |
| james_w | -vmmouse, not -mouse | 20:57 |
| ivoks | maxb: great, thanks | 20:58 |
| maxb | (Why do some people say FTBFS and others FTBS? The second seems oddly wrong to me) | 20:58 |
| ivoks | :) | 20:58 |
| * ScottK doesn't recall people saying FTBS. | 20:59 | |
| maxb | I've seen it a fair bit in changelog entries | 21:00 |
| kklimonda | maxb: probably just a typo.. | 21:02 |
| maxb | A bit too often for that. | 21:02 |
| maxb | So, does anyone know how X keymaps are supposed to work in the world of udev-extras? | 21:02 |
| * maxb has had to roll back the last hal update for now | 21:02 | |
| james_w | kklimonda: I don't see where the change is, do you have a pointer? | 21:24 |
| kklimonda | james_w: it was made here: | 21:25 |
| kklimonda | xserver-xorg-input-vmmouse (1:12.5.1-4ubuntu5) jaunty; urgency=low | 21:25 |
| kklimonda | * Add mdetect to dependencies (LP: #362027) | 21:25 |
| kklimonda | -- John Dong <jdong@ubuntu.com> Wed, 15 Apr 2009 18:28:04 -0400 | 21:25 |
| james_w | bug 362027 doesn't give you enough information? | 21:26 |
| ubottu | Launchpad bug 362027 in xserver-xorg-input-vmmouse "Missing dependency on mdetect" [Undecided,Fix released] https://launchpad.net/bugs/362027 | 21:26 |
| siretart | loic-m: pong | 21:27 |
| loic-m | siretart: do you know who takes care of x264, mencoder (mplayer) and xvid in Debian? | 21:27 |
| siretart | loic-m: depends on what you mean with 'taking care' | 21:27 |
| loic-m | I only see mplayer in Debian, no xvid, no x264 | 21:28 |
| siretart | x264 is packaged here: http://svn.debian.org/wsvn/pkg-multimedia/unstable/x264/#_unstable_x264_ | 21:28 |
| kklimonda | james_w: this bug is only about adding mdetect to Dependencies but there is nothing about why was vmmouse_detect moved from xserver-xorg-input-vmmouse in the first place | 21:29 |
| james_w | kklimonda: does the hal-probe-vmmouse in Debian call vmmouse_detect? Which package is that program in? | 21:29 |
| siretart | mencoder should be built from the mplayer package | 21:29 |
| loic-m | I know you're a regular uploader for mplayer, but don't know if it's as part of a team or something | 21:29 |
| james_w | kklimonda: but I don't see it being moved in the diff from Debian? | 21:29 |
| siretart | unsure about xvid | 21:29 |
| kklimonda | james_w: hmm.. maybe it was moved back in later release? | 21:30 |
| kklimonda | (in debian package) | 21:30 |
| siretart | loic-m: as part of the pkg-multimedia team, yes. see http://wiki.debian.org/DebianMultimedia/ for more information | 21:30 |
| siretart | loic-m: espc. http://wiki.debian.org/DebianMultimedia/Join | 21:30 |
| siretart | I maintain the ubuntu ffmpeg packaging branchen under that umbrella as well. git makes it very easy to maintain branches, you know | 21:31 |
| siretart | interested to contribute there? | 21:31 |
| bddebian | siretart: Hey do you happen to know if any of you multimedia types use Bristol? | 21:32 |
| loic-m | yes and no. I'd have to learn svn, and if I managed to do it then yes | 21:32 |
| siretart | loic-m: we are switching from svn to git | 21:32 |
| bddebian | Nooo | 21:32 |
| siretart | bddebian: no idea what bristol is | 21:32 |
| bddebian | siretart: You're no help! :) | 21:32 |
| siretart | brb, phone | 21:32 |
| kklimonda | james_w: hmm.. it might have been our own change made because debian haven't provided vmmouse_detect at the time.. | 21:33 |
| loic-m | siretart: oh noes | 21:34 |
| kklimonda | james_w: yeah - looks like it.. i wonder why it was added to mdetect instead to xserver-xorg-input-vmmouse.. | 21:34 |
| loic-m | siretart: as for contributing, I'd like to tackle bug #371786 | 21:35 |
| loic-m | siretart: updating the man page for both x264 and mencoder | 21:35 |
| ubottu | Launchpad bug 371786 in x264 "bime and brdo options in x264 dropped (now set with subme), x264 and mencoder man pages need to be updated" [Undecided,New] https://launchpad.net/bugs/371786 | 21:35 |
| loic-m | siretart: which is quite simple, then I can either attach a diff to the bug and you (or another Debian contributor) can put it in x264 and mencoder | 21:35 |
| james_w | kklimonda: because it is a package for detecting mice? :-) | 21:35 |
| loic-m | siretart: so there's no 2 different man pages, and we don't duplicate the efforts | 21:36 |
| james_w | kklimonda: if the input package ships it now then you can sync, but you will have to patch mdetect as well obviously | 21:36 |
| loic-m | siretart: for xvid, I can't understand why it's not in Debian. | 21:36 |
| kklimonda | james_w: well.. It would make more sense to keep all vmmouse related stuff in one package. Now we can't sync with debian, we have to add Conflicts/Replaces to handle upgrade? | 21:36 |
| kklimonda | Or maybe not? Damn, I have to read more about this particular part of .deb packages.. | 21:37 |
| siretart | ... still on the phone... | 21:37 |
| james_w | kklimonda: ah, that's true | 21:41 |
| kklimonda | james_w: btw - for how long do we have to keep changes that are made to make an upgrade possible? For example transmission has Replaces/Conflict with some old package that provided web ui.. | 21:44 |
| james_w | kklimonda: usually until after the release that anyone who may have the problem packages has to go through, if that makes sense | 21:45 |
| james_w | so if mdetect stuff was just in Jaunty, then we could drop it after Karmic | 21:45 |
| james_w | however, if it was in Hardy, then we would have to keep in until after the next LTS | 21:45 |
| james_w | because you can go LTS->LTS | 21:45 |
| kklimonda | mhm | 21:46 |
| james_w | it's really useful if you state when something like this can be dropped in the changelog | 21:46 |
| james_w | it saves everyone having to look it up :-) | 21:46 |
| kklimonda | mdetect ships vmmouse_detect since gutsy so we'll keep it for a while :) | 21:46 |
| siretart | loic-m: ok, back | 21:49 |
| siretart | loic-m: for the x264 package, AFAIUI the x264 package in ubuntu is based on marillat, while the debian package is packaged by fabian greffrath | 21:49 |
| siretart | and it is still in svn and needs to be converted to git | 21:50 |
| siretart | if that is done, I have no problem with updating it and making it ready for ubuntu to replace the marillat package | 21:50 |
| kklimonda | james_w: actually I've created .deb files to test upgrade and it worked without any Conflicts/Replaces lines.. | 21:52 |
| kklimonda | james_w: it looks like mdetect was upgraded before xserver-xorg-input-vmmouse | 21:52 |
| james_w | kklimonda: I'm not sure if that's something you can rely on though | 21:53 |
| kklimonda | exactly - that's probably because of the order I've passed .debs to dpkg.. | 21:53 |
| loic-m | siretart: x264 in Debian seem completely out of date http://svn.debian.org/wsvn/pkg-multimedia/unstable/x264/debian/changelog | 21:54 |
| jdong | kklimonda: vmmouse_detect had been in mdetect in jaunty and below for reasons beyond my control | 21:54 |
| ScottK | kklimonda: You can't rely on that. | 21:54 |
| siretart | loic-m: as for xvid, I don't know why nobody has bothered yet to prepare it for debian. | 21:54 |
| jdong | kklimonda: I put the dependency in on mdetect because for Jaunty, the vmware mouse will not work at all unless vmmouse_detect was available | 21:55 |
| siretart | loic-m: yes. the reason for that is this: | 21:55 |
| jdong | kklimonda: for karmic we do need appropriate conflict/replace on mdetect and such. | 21:55 |
| siretart | loic-m: fabian packaged that for debian-unofficial.org | 21:55 |
| kklimonda | jdong: I know - I was just wondering why vmmouse_detect was placed in mdetect and not in xserver-xorg-input-vmmouse | 21:55 |
| jdong | kklimonda: lol that you can't blame me for ;-) | 21:56 |
| kklimonda | jdong: would you mind checking bug 368855 ? I need an ACK from sru ;) | 21:56 |
| ubottu | Launchpad bug 368855 in cherrypy3 "formatwarning() definition from cherrypy3 incompatible with Python 2.6" [Undecided,In progress] https://launchpad.net/bugs/368855 | 21:56 |
| kklimonda | jdong: and I don't :) | 21:56 |
| jdong | it seems to be fixed and moot now though | 21:56 |
| jdong | and yeah lemme look | 21:56 |
| siretart | loic-m: however, at some point that project didn't "go on" and stalled. we are now waiting for the relaunch | 21:56 |
| jdong | yay launchpad fail. | 21:56 |
| loic-m | siretart: what prevents Marilat pkg to be imported instead? | 21:56 |
| loic-m | siretart: and for xvid, could pkg-multimedia use Ubuntu package? | 21:57 |
| siretart | loic-m: him being a *beeep*? | 21:57 |
| siretart | loic-m: seriously, I tried several times to work with him. and failed several times in spectacular ways. and if you look at his packages, well, better don't | 21:57 |
| * ScottK has yet to review one that didn't have debian/copyright issues. | 21:58 | |
| dtchen | jdong: got time to approve an sru request? (bug 366620) | 21:58 |
| ubottu | Launchpad bug 366620 in muine "Play Album and Play Song didn't work anymore" [Medium,Fix released] https://launchpad.net/bugs/366620 | 21:58 |
| loic-m | siretart: why use them in ubuntu though. | 21:58 |
| siretart | ScottK: exactly. he simply doesn't care about anything | 21:58 |
| siretart | loic-m: because someone decided it was a good idea? - I'd disagree here | 21:59 |
| loic-m | ScottK: that's something I could take care of if needed (I've done xvid recently) | 21:59 |
| jdong | kklimonda: acked yours, dtchen, looking. | 21:59 |
| siretart | loic-m: I therefore propose to maintain them properly in pkg-multimedia for both debian and ubuntu | 21:59 |
| loic-m | siretart: you mean you'd maintain them? | 21:59 |
| siretart | it's just that pkg-multimedia is really understaffed. I'm really busy with ffmpeg and mplayer, so additional help would be more than welcome | 22:00 |
| loic-m | siretart: what if I try to get xvid into pkg-multi as training, since I've worked on it for Ubuntu for the past few month? | 22:01 |
| jdong | dtchen: acked | 22:01 |
| siretart | loic-m: that would be excellent :-) - have a look at git-buildpackage and git-import-dsc for importing existing packages | 22:02 |
| dtchen | jdong: thanks | 22:02 |
| loic-m | siretart: and for x264/mplayer man page updates I'd send the man page to you in the mean time (since it'll probably take me a while to get the hang of x264) | 22:02 |
| siretart | ah right, what was the issue with the mplayer man page? | 22:02 |
| siretart | I thought upstream is managing them rather well, and translate them in various languages | 22:03 |
| loic-m | siretart: see bug #371786 | 22:03 |
| ubottu | Launchpad bug 371786 in x264 "bime and brdo options in x264 dropped (now set with subme), x264 and mencoder man pages need to be updated" [Undecided,New] https://launchpad.net/bugs/371786 | 22:03 |
| loic-m | siretart: thanks for the info. Probably they already updated it, but the man page in Ubuntu doesn't match the code for x264 options (changed in october 2008 AFAIR) | 22:04 |
| siretart | loic-m: mplayer in ubuntu is at rc2, read: stone-age. Have you checked if it has already been fixed in the rc3 branch? (the debian package is based on that branch currently) | 22:04 |
| loic-m | siretart: I'll have a look upstream for the man pages, and concentrate on xvid for Debian | 22:04 |
| siretart | loic-m: if the upstream manpages are still out of date, let's commit that upstream and backport it to the rc3 branch | 22:05 |
| soren | 7win 380 | 22:06 |
| soren | Whoops | 22:06 |
| soren | 7win 380 | 22:06 |
| soren | Darn it! | 22:06 |
| Laney | you have 380 windows?! | 22:06 |
| siretart | 200 of them are queries, I bet | 22:07 |
| soren | Laney: I do. | 22:07 |
| ajmitch | soren: you worry me. A lot | 22:07 |
| soren | siretart: Thereabouts, yes. | 22:07 |
| * ajmitch has managed to restrict it to about 25 windows lately | 22:08 | |
| soren | ajmitch: I was up to 450 until my IRC vm crashed, and it had been a while since i /layout save'd. | 22:08 |
| * maxb boggles | 22:08 | |
| siretart | loic-m: anything else you want to discuss with me? | 22:09 |
| maxb | How do you manage all those? Or so you simply not, and always address them by name? | 22:09 |
| loic-m | siretart: I've been checking the man page for mplayer on debian git, and it's indeed up-to-date | 22:13 |
| kklimonda | what will be the right way of creating merge request for xserver-xorg-input-vmmouse? Do I make separate bug reports - one for mdetect upgrade and another for xserver-xorg-input-vmmouse merge? | 22:14 |
| loic-m | siretart: I think I understand how it works on Debian better, and should be ok for now. Thanks a lot, I'll probably ping you in a few days/weeks if I've got trouble getting xvid in pkg-multi | 22:14 |
| loic-m | siretart: and thanks for maintaining mencoder ;) I use it almost daily (nightly actually) | 22:16 |
| siretart | loic-m: the debian package currently does not build mencoder and it is currently not being accepted in debian | 22:17 |
| siretart | loic-m: I intend to extend the package anyway to build mencoder in a seperate branch. that will be the basis for the ubuntu branch | 22:17 |
| siretart | loic-m: but don't expect results from be before in about 2 weeks. if someone else is faster, so be it | 22:17 |
| loic-m | siretart: right, I rememember those emails now | 22:18 |
| mirak | I have a version like that 0.99.5+cvs20070914-2.1~lenny2ubuntu2 , I want to rebuilt it and upload to ppa, how do I adapt the version number ? | 22:28 |
| ScottK | mirak: I'd add ~release1~ppa1 on the end, e.g ~jaunty1~ppa1 | 22:29 |
| mirak | scottK: in replacement of what ? | 22:31 |
| mirak | scottK you mean in plus ? | 22:31 |
| maxb | NB which way you put the ~jaunty1 and ~ppa1 bits depends on your intended maintenance methodology | 22:31 |
| ScottK | In addition | 22:31 |
| ScottK | yes | 22:31 |
| ScottK | maxb: I disagree. | 22:31 |
| ScottK | The other way can conflict with archive uploads and just flat out isn't a good idea. | 22:31 |
| * ScottK is off for a while, so no time to argue | 22:32 | |
| maxb | If you have a single source which you maintain, and then backport across multiple releases, ~ppaN~releaseX is better | 22:32 |
| maxb | On the other hand, if your uploads for each release have little to do with each other, ~releaseX~ppaN is better | 22:32 |
| maxb | meh | 22:33 |
| mirak | we fall again on the same problem | 22:33 |
| mirak | the binary compatibility is handled very bad | 22:33 |
| maxb | That's a scary version number. What is it? | 22:33 |
| mirak | xine-ui | 22:34 |
| mirak | because here I need to rebuild xine-ui to have a right binary compatibility to a libxine1 I rebuild with vdpau support | 22:34 |
| maxb | The fact that it's still the same cvs snapshot that was taken a year and a half ago worries me :-) | 22:34 |
| mirak | here, I don't want any xine-ui update from ubuntu, because it will break the binary compatibility I need with my libxine1 version | 22:35 |
| maxb | mirak: Have you already decided what your libxine1 version number will be? | 22:35 |
| maxb | Personally I would use 0.99.5+cvs20070914-2.1~lenny2ubuntu1+vdpau1 | 22:37 |
| maxb | Or possibly +mirak | 22:37 |
| maxb | +mirak1 rather | 22:37 |
| mirak | xine-lib_1.1.16.3.-0+ppa3 | 22:38 |
| mirak | that's my version | 22:38 |
| maxb | erm, really? | 22:38 |
| mirak | yes | 22:38 |
| maxb | with a . at the end of the upstream version? | 22:38 |
| mirak | yes, because I messed up the version earlier with two minus | 22:39 |
| maxb | Hmm. | 22:39 |
| mirak | don't bother about the dot | 22:39 |
| maxb | Are you basing the package on 1.1.16.3-0ubuntu1 ? | 22:39 |
| mirak | no | 22:39 |
| maxb | Do you need to build this for multiple Ubuntu series? | 22:40 |
| RoAkSoAx | heya guys... every time we have to modify anything in a .c file or .h file while merging, we should create a patch right?? or we have just to do the modification directly to the file? | 22:40 |
| mirak | maxb: I did a backport for intrepid | 22:40 |
| kklimonda | RoAkSoAx: create a patch | 22:40 |
| RoAkSoAx | kklimonda, so for example... in a previous ubuntu version, they seem to have modified the file by hand, so I would need to remove that modification and then create a patch that modifies what it is supposed to right? | 22:41 |
| maxb | As you seem to have already adopted a +ppaX convention, I would call the xine-ui build 0.99.5+cvs20070914-2.1~lenny2ubuntu1+ppa1 in Jaunty | 22:41 |
| maxb | And then I would append an additional ~intrepid1 to that when backporting to intrepid | 22:41 |
| kklimonda | RoAkSoAx: Yes - there shouldn't be any changes made directly to files. | 22:42 |
| RoAkSoAx | kklimonda, k thanks :) | 22:42 |
| mirak | maxb: I use dch --bpo to backport | 22:42 |
| maxb | mirak: You should NOT do that | 22:43 |
| mirak | lol | 22:43 |
| mirak | otherwise earth will colapse | 22:43 |
| mirak | on itself | 22:43 |
| maxb | It mislabels your version numbers as having something to do with backports.org, which is simply a lie | 22:43 |
| maxb | You should use dch -b -l ~intrepid | 22:43 |
| * a|wen think kklimonda should look at the mplayer source regarding that :/ | 22:43 | |
| mirak | thanks for the info, but I don't think it matters much | 22:44 |
| maxb | Why ask for advice if you don't care about taking it? | 22:44 |
| mirak | I could call my backage like ~barackobama that would work | 22:44 |
| mirak | maxb: it's just that it's a really private ppa | 22:44 |
| mirak | I took your advice | 22:44 |
| mirak | of course, I will remember it | 22:44 |
| mirak | and the command | 22:45 |
| kklimonda | a|wen: well, many maintainers don't care about it unfortunately :/ | 22:45 |
| mirak | it would be nice to have tools adapted to ubuntu conventions | 22:45 |
| a|wen | kklimonda: right ... and when you find a package from debian inline-patched to hell, it seems kind of too late | 22:46 |
| kklimonda | a|wen: xserver-xorg-input-vmmouse is awesome when it comes to patches - package depends on quilt but it uses custom quilt mk file and patches sources inline :/ | 22:47 |
| mirak | don't you think there is a flaw on the binary depencies handling in dpkg apt and stuff ? | 22:48 |
| maxb | mirak: huh? | 22:48 |
| mirak | because in fact the depencies are mostly about source depencies right ? | 22:48 |
| kklimonda | I'm not even going to check mplayer - I've heard a lot about quality of mplayer code so I can only assume that package maintainer is just following their steps ;) | 22:48 |
| a|wen | that's what you call one step forward; and two steps back | 22:48 |
| a|wen | kklimonda: don't ... and stay away from ffmpeg source as well | 22:49 |
| kklimonda | is there some automated way of checking if package upgrades cleanly? maybe piuparts can do it? | 22:49 |
| dtchen | yes, use piuparts as a starting point. | 22:50 |
| mirak | maxb: like I said, I need to rebuild xine-ui gxine so they will be binary compatible to libxine1 I recompiled. otherwise some things don't work. however nothing can prevent ubuntu to upgrade xine-ui again and break the depency I recreated. | 22:50 |
| maxb | I don't see how binary and source are relevant to that, your problem is that a sequence of version numbers doesn't express flavours | 22:51 |
| maxb | or variants or whatever you'd like to call them | 22:51 |
| a|wen | gah, dapper is a long time back ... really not fun to patch anything there with new patches | 22:52 |
| mirak | maxb: sure, so how I can I bound my set of packages toogheter ? | 22:53 |
| mirak | maxb: maybe there is a way to make stronger depencies ? | 22:53 |
| maxb | I think I would add a suffix to every binary and source package name, and conflicts against the unsuffixed names | 22:54 |
| mirak | maxb: that would be hell to maintain, | 22:59 |
| mirak | maxb: what about packages that depend of these ? | 23:00 |
| mirak | but don't need a tight binary compatibility ? | 23:00 |
| mirak | it will conflict. what I want is that my packages just substitute | 23:01 |
| maxb | Hmm. Maybe if your libxine1 did "Provides: libxine1-mirak" and all your other packages did "Depends: libxine1-mirak" | 23:02 |
| maxb | At least that would ensure that your rebuilt apps packages had your rebuilt library available | 23:03 |
| mirak | maxb: ok but in fact shouldn't there be some flag that indicates that a package have a strong binary depencies to another one, and need to be rebuilt if the other changes a bit ? | 23:05 |
| mirak | I mean generally | 23:05 |
| maxb | What, you mean depending on one specific version only? | 23:05 |
| mirak | because dpkg tells nothing about that, you can't guess it | 23:05 |
| maxb | Sure, you can do that, but it's almost never the trurth | 23:05 |
| maxb | *truth | 23:06 |
| mirak | maxb: ok but here for exemple, gxine fails badder than xine on my rebuild libxine | 23:06 |
| mirak | shouldn't there be some some field that tells that if the lib is somewhat modified, then the package using that lib should also be rebuilt ? | 23:07 |
| mirak | I mean the gxine depency seem to be laxist about the libxine version it can handle. I guess it's just something like greater than version x | 23:08 |
| maxb | If you change the ABI of a library, you're supposed to change its packagename | 23:08 |
| maxb | change in fundamentally incompatible ways, that is | 23:09 |
| mirak | what do you mean by changing the name ? | 23:09 |
| mirak | like what | 23:09 |
| mirak | maxb: ? | 23:10 |
| maxb | In your case, which is a change of variant/flavour rather than of version, adding a suffix, like I said | 23:11 |
| maxb | Call the package libxine1mirak | 23:11 |
| RoAkSoAx | which is the recommended patch system? | 23:14 |
| loic-m | RoAkSoAx: not sure, but I found quilt easy to use | 23:15 |
| binarymutant | RoAkSoAx, I like dpatch but a lot of people are moving to quilt | 23:15 |
| RoAkSoAx | and if i add quilt, do I need to make changes to debian/rules so that it can apply the patches? | 23:15 |
| loic-m | RoAkSoAx: I've seen quilt used on tuxtype, and the line is in config.status: | 23:17 |
| loic-m | QUILT_PATCHES=debian/patches quilt push -a || test $$? = 2 | 23:17 |
| loic-m | then in clean: | 23:18 |
| loic-m | QUILT_PATCHES=debian/patches quilt pop -a -R || test $$? = 2 | 23:18 |
| loic-m | (don't ask me to explain though) | 23:18 |
| mirak | maxb: I understand that with how dpkg is actually, it's the best option, however don't if just think about it generally, don't you think something is missing in dpkg to ensure binary compatibility ? because here if I don't need to change any line of code on xine-ui and touch anything exept rebuilding it. so this means that my libxinemirak package is still source compatibile to libxine, so I don't see any reason why the source depency | 23:18 |
| mirak | should change. That's why I feel something is missing in the design of dpkg. It's the second time I have this kind of questioning. it happened with vdr and it's plugins also. | 23:18 |
| loic-m | config.status: & clean: are in debian/rules of course | 23:18 |
| kklimonda | RoAkSoAx: you can also add "include /usr/share/cdbs/1/rules/patchsys-quilt.mk" at the top of debian/rules and it should take care of patching/reverting automatically | 23:19 |
| RoAkSoAx | kklimonda, ok awesome thanks guys :) | 23:19 |
| loic-m | kklimonda: that's good to know | 23:19 |
| maxb | What kklimonda says if the package already uses cdbs. Otherwise, list the contents of the quilt package itself - it ships a simple make fragment for including in non-cdbs packages | 23:19 |
| RoAkSoAx | kklimonda, isn't it: include /usr/share/quilt/quilt.make ? | 23:19 |
| maxb | that's the one | 23:20 |
| maxb | mirak: The (build-)dependency MUST change to express the desire to build against a different flavour of a library | 23:20 |
| maxb | Within a distribution, that is. PPAs being a sort of divided addon archive blur that concept a bit | 23:21 |
| maxb | But of course the tools are designed for distributions first and foremost | 23:21 |
| mirak | so let's admit we are on karmic. I decide to update libxine1 with a vdpau patch. why would I change the package name or the flavor ? I mean only the version should change, it's just an evolution of the upstream version. So how can I know I need to rebuild this or that application for the binary to still be compatible if nowhere something complains ? | 23:23 |
| mirak | I maybe miss the concept of flavor, I am new to that | 23:24 |
| maxb | If upstream change the ABI in such a way that it can no longer be used by apps compiled against the old ABI, then it becomes libxine2 | 23:25 |
| mirak | ok | 23:27 |
| mirak | that's why vdpau modifications are still on the libxine2 branch only | 23:28 |
| mirak | like vdr protocol | 23:28 |
| mirak | mirak: I understand better now | 23:28 |
| mirak | the flavor thing | 23:28 |
| maxb | The flavour thing doesn't really apply here | 23:29 |
| maxb | I thought you wanted to make an *unofficial* different patched ABI | 23:30 |
| jmehdi | needs review: http://revu.ubuntuwire.com/details.py?package=webstrict | 23:30 |
| maxb | Well, I suppose it sort of does apply, since if the libxine2 ABI isn't final, it would be somewhat erroneous to name your library libxine2 | 23:30 |
| mirak | maxb: is there a way to know all packages who depends of another one ? | 23:36 |
| maxb | Depends how widely you define the scope of "all" | 23:36 |
| maxb | But try "apt-cache rdepends packagename" for starters | 23:36 |
| mirak | maxb: ok but here there still no indication that the depency is either source or binary | 23:39 |
| mirak | right ? | 23:39 |
| maxb | I do not understand what you mean by "source or binary" | 23:39 |
| maxb | ALL binary package dependencies are on other binary packages. | 23:39 |
| mirak | yes, but if install ubuntu-desktop, it won't matter for ubuntu desktop that I change the abi of gnome | 23:40 |
| mirak | in fact I guess my point is that if there is a flavor depency relative to an abi, then there should be a field like Abi-depency: | 23:41 |
| mirak | instead of having the flavor included in the name of the package | 23:42 |
| mirak | I mean here if there is a package ahave a depency on xinelib "flavor 2", and that this depency is only happening at BUILD time, and not at source level, then this depency should be dynamically added to the control file at build time. | 23:45 |
| maxb | hah! It *is* | 23:45 |
| mirak | and be only present in the binary package | 23:45 |
| maxb | via the shlibs mechanism | 23:46 |
| mirak | maxb: ok | 23:46 |
| mirak | lol | 23:46 |
| mirak | I guess I will finally figure this out | 23:46 |
| maxb | Your depending package Build-Depends: libxine-dev | 23:46 |
| maxb | dpkg assesses the actual library dependencies of the compiled code, and substitutes the libxinewhatever into ${shlibs:Depends} | 23:47 |
| maxb | And it would be out of place for ubuntu-desktop to depend on libraries, mostly | 23:47 |
| maxb | Since it's more concerned with features | 23:47 |
| mirak | maxb: yet there is a problem i think | 23:48 |
| mirak | because here let's admit my libxine1 is now libxine1mirak | 23:49 |
| mirak | if I rebuild xine-ui | 23:49 |
| mirak | it should automatically shlib depend on libxine1mirak right ? | 23:50 |
| maxb | Should work, yes | 23:50 |
| mirak | ok | 23:50 |
| mirak | maxb: however how can xine-ui now the libxine it looks for is libxine1mirak ? | 23:51 |
| mirak | know | 23:51 |
| mirak | that's what I don't get here | 23:52 |
| mirak | and why I told I would have seen the flavor in a special field, like abi-depency field. so it would depend on the available libxine flavor 1mirak that was installed. | 23:53 |
| mirak | otherwise I am forced to modify the debian directory of xine-ui in plus of the changelog | 23:54 |
| maxb | In most cases packages would depend on libraries via an automatic substitution, however I see xine doesn't use this | 23:54 |
| maxb | I think your goal to not modify the package source is frankly unrealistic | 23:55 |
| mirak | anyway again it comes to some other idea I add, wich is that I beleive the binary should have a version number in plus of the source package, because here we can have different binaries from the same source, depending of the abi it was built against. | 23:55 |
| maxb | It would add a great deal of complexity to the dependency resolution process and simply isn't necessary | 23:57 |
| mirak | maxb: I think the solution would be that the binary package have a specific version indicator. like libxine1-0debian0.dsc for the source and libxine1-0debian0_binary1.deb for the binary package | 23:57 |
| mirak | the version number of the binary would determinated by the builder, either manually, or according to a search on the previous binary version | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
