Re: RFS: zynaddsubfx
On 2007-12-23, Free Ekanayaka <[EMAIL PROTECTED]> wrote: > Hi, > >> Sorry, wrong terminology. It's a very useful multimedia application, >> which many people use and would expect to find in Debian. Therefore it >> is worth making the extra effort to keep it well maintained IMO. The >> point being that debian-multimedia should deal with it if group >> maintenance is needed rather than QA. >> > I can take care of uploading it, but it will probably happen after Christmas. > Hope it's fine.. As it was said earlier, it is already uploaded to delayed/something. Some days ago to delayed/7, so probably it is in delayed/2 now. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reopening an ITP or opening a new one?
On 2008-01-18, Iván Forcada Atienza <[EMAIL PROTECTED]> wrote: > > --yLVHuoLXiP9kZBkt > Content-Type: text/plain; charset=iso-8859-1 > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > Hi mentors!! > > I am interested in kgtk application [1]. After a search, I've found that > it was ITP'd time ago, but the bug was automatically closed 365 days > after [2]. > > Now, I want to start working on it (in fact, it's already packaged > because I needed it, and only missing my sponsor reviewal) but I have 2 > simple questions: > 1) Should I reopen the existing bug [2] or open a new ITP?? > 2) Should I notify the original ITP opener?? If you try notifying the ITP owner, you will get one of the best possible kde related reviews of your package - and maybe even sponsor ship. He is kind of active - but had various reasons for not packaging last I asked. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kde4-style-qtcurve
On 2008-02-04, Salvatore Ansani <[EMAIL PROTECTED]> wrote: > Dear mentors, > > I am looking for a sponsor for my package "kde4-style-qtcurve". > > * Package name: kde4-style-qtcurve > Version : 0.55.2-1 > Upstream Author : Craig Drummond <[EMAIL PROTECTED]> > * URL : > http://www.kde-look.org/content/show.php/QtCurve+%28KDE4%2C+KDE3%2C+%26+Gtk2+Theme%29?content=40492 > * License : GPL > Section : kde > > It builds these binary packages: > kde4-style-qtcurve - Widget styles for KDE4 based apps > > The package appears to be lintian clean. > > The upload would fix these bugs: 462975 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/k/kde4-style-qtcurve > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/k/kde4-style-qtcurve/kde4-style-qtcurve_0.55.2-1.dsc > > I would be glad if someone uploaded this package for me. I stopped checking this file after having read the control file. ever tried building it in - for example pbuilder? Build-Depends: debhelper (>= 5), cdbs There is also a window decoration. considered building that one as well? /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kde4-style-qtcurve
On 2008-02-05, Salvatore Ansani <[EMAIL PROTECTED]> wrote: > I need to change package_name-version-1 to package_name-version-2 before > upload on mentors ??? I don't think that is needed. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Requests for sponsors to upload NMUs
On 2008-03-04, Neil Williams <[EMAIL PROTECTED]> wrote: > Are sponsors going to start recommending changing SONAMEs in an NMU > next? Adding -dbg packages? Of course not, NMUs are different to typical > RFS activity. of course is changing SONAMEs in a NMU appropriate if it is appropriate. > Having a sponsored upload that is lintian clean is AGoodThing(tm) for an > ordinary RFS where the maintainer is the one requesting sponsoring. All > those niceties simply do not apply to an NMU - lintian errors are to be > preserved in all their ugliness unless specifically part of an existing > bug report in the BTS *or* relevant to the fix for the RC bug. (And a > mere lintian error/warning is not a good reason to file a new bug > either, that's why lintian exists.) yeah. let us not improve the package quality in debian. > Sponsors, can we please stick to the rules for NMUs so that those who > seek advice here can get clear guidance on what is required? Sponsors, keep up your good work. If the changes are big, please consider DELAYED/something though. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: NMU: orange -- extracts CAB files from self-extracting installers
On 2008-03-05, Neil Williams <[EMAIL PROTECTED]> wrote: > 1. Let orange be removed from Lenny due to the existing RC bug, or > 2. Let orange behave as it has in previous stable releases without > fixing a bug that nobody seems to care about. 3. Fixing the bugs. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Requests for sponsors to upload NMUs
On 2008-03-05, Neil Williams <[EMAIL PROTECTED]> wrote: >> of course is changing SONAMEs in a NMU appropriate if it is appropriate. > > That equates to a hostile hijacking. If the package is orphaned or if No it don't. it is just bugfixing. If it requires binary incompatible changes to fix it, of course the SONAME should be changed as well. Else you introduce new bugs. > the maintainer is MIA and the package can be orphaned beforehand, fine > (but then it's no longer an NMU, it's a QA upload). Changing a SONAME is > *not* acceptable in an NMU without permission from the maintainer. It is > an especially bad idea when doing NMU's as part of a release bug You seem to be living in perfect-world where maintainers are always reachable. MIA-process && orphaning is too slow for bugfixing. This isn't about anything else than bugfixing. > > Adding a patch system is also not acceptable in an NMU. Neither is > converting from dpkg to debhelper or CDBS or any other build system, > even if, in your opinion, it would help the package overall. That's not bugfixing, but changing packaging style. >> yeah. let us not improve the package quality in debian. > >>=20 >> Sponsors, keep up your good work. If the changes are big, please >> consider DELAYED/something though. > > That's worse! There is a day NMU bug squashing party in effect so there > is no point uploading to the delayed queue. Just don't make hostile or > intrusive changes in an NMU. Stick to the NMU rules. fix bugs. Don't make debian the distribution where bugfixing other packages is forbidden. We need better packages. don't stop people working for this. With delayed/7, you still have 7 days to react. > An NMU is not a normal upload. Everyone doing NMU's *must* work with the > current maintainer *or* the MIA process. If the current maintainer is busy with real life, that is not possible. MIA-process takes long time. > Do not delay RC fixes by adding unnecessary cleanup changes. > > Do not delay RC fixes by implementing a patch system if the package does > not use one. > > Do not delay RC fixes just to remove a few lintian errors or warnings. Please fix bugs. > Keep the NMU clean and make sure the entire patch is in the BTS before > seeking a sponsor or making the upload. Of course make it nice, clean, well-documented /Sune - who wanted to track down a rc bug before sending this. It ended up with kdetv build failure. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Requests for sponsors to upload NMUs
On 2008-03-05, Neil Williams <[EMAIL PROTECTED]> wrote: > Yes, fix known bugs but don't delay the RC bugs just to fix less > important ones. That's perverse. Do two uploads ;) - one to "now" and one to delayed. > All I'm saying here is that sponsors should not expect NMUs to fix the > full range of issues that would normally be essential to fix for an > upload to NEW or for an upload of a package already maintained by the > person requesting sponsorship. I of course agree on this. But I also think that if someone does this extra things, he should not be asked to undo them before making the NMU. When I am NMU'ing something filled with crack and awfulness, I have a hard time not fixing these as well, especially if it is easy fixable. > lintian errors and warnings are explicitly *off-topic* for an NMU, > unless directly related to the RC bug. No. changing -make clean to [ ! -f Makefile ] || make clean for example would in my opinion be fully acceptable. (This is not stylistic changes, but nice bugfixes) > Can we agree that these tasks should *not* be done in an NMU *unless* > directly related to the RC bug? : (or after communication with maintainer) > > 1. SONAME changes merely to shut up lintian - i.e. where the RC bug has > no need to change the SONAME. Yeah. > 2. removing commented out lines in debian/rules Yeah. > 3. Implementing dpatch or quilt for a package that does not use it yeah. > 4. tidying up manpages depends. > 5. Changing the build system to/from CDBS/dpkg/dbs/foo yeah. > 6. other lintian errors or warnings depends > lintian errors and comments in debian/rules are *not* bugs. I'm not > against fixing bugs that have been properly filed in the BTS and which Lintian errors are often bugs. > There is a big difference between bug-fixing and QA. NMUs are for fixing > bugs, not stylistic changes within packages or keeping up with lintian. "keeping up with lintian" - hah. /Sune - this time it was 462001 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Requests for sponsors to upload NMUs
On 2008-03-05, Richard Hecker <[EMAIL PROTECTED]> wrote: > If the maintainer is truly MIA, that is a bigger issue than any > single bug. Others have made this argument that we should Yes. but luckily, we can do both at the same time (fixing bugs and figuring out wether a maintainer is MIA) And a annoying often run into normal bug can be more annoying than a cornercase rc bug. /Sune - this time #467604 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: wordpress
On 2008-04-20, Andrea De Iacovo <[EMAIL PROTECTED]> wrote: > They're all solved in 2.5.0 (already in sid) and someone is solved > also in 2.3. However I'm waiting fort hte first package upload to > close a buch of bugs. Etch is 2.0 series /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "Fixing" source-contains-cvs-{conflict-copy,control-dir}
On 2008-06-07, David Paleino <[EMAIL PROTECTED]> wrote: > Any opinion about this? Is there a consensus on how to behave? Is that a ma= > tter > of taste? Leave it and educate upstream. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plasma-netgraph
On 2008-08-28, Salvatore Ansani <[EMAIL PROTECTED]> wrote: > > Dear mentors, > > I am looking for a sponsor for my package "plasma-netgraph". > > * Package name: plasma-netgraph >Version : 0.3-1 >Upstream Author : John Varouhakis > * URL : http://code.google.com/p/ivplasma/ > * License : GPL >Section : kde > > It builds these binary packages: > plasma-netgraph - A plasmoid to display network usage Hi! Nice that people are starting packaging plasma thingies. But. That copyright file really needs some work. CMakeLists.txt is *not* a piece of documentation Why are you requiring all those X development packages? Your plasmoid isn't including any X headers. And this is just a first glance. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Trying to understand patch management - in combination with version control
On 2008-09-02, Andreas Schildbach <[EMAIL PROTECTED]> wrote: > Now, when I (or a co-maintainer) check out the project from SVN, I get > (as expected) a nearly empty project directory, containing just the > debian directory. But, how am I supposed to actually create the patches > that go into debian/patches? My current understanding is: I > modify/delete/create a set of files and use something like > interdiff/debdiff to extract the changeset. But in the case of > mergeWithUpstream-mode there is no file to modify... Don't tell me I > have to write patches "by hand" (-: > > Also, can you point me to a document that explains workflow with a patch > management system in general, preferably in combination with a version > control system. I'm using svn - and part of the kde/qt team. Only debian-dir is kept in svn. Packages uses quilt Upstream releases tar.bz2 files. Goal: refresh patches and add a note to the upstream README file My basic workflow is as follows: bunzip2 kdeutils-4.1.1.tar.bz2 gzip --best kdeutils-4.1.1.tar mv kdeutils-4.1.1.tar.gz kdeutils_4.1.1.orig.tar.gz tar xzf kdeutils_4.1.1.orig.tar.gz cd kdeutils-4.1.1 cp -a ~/svn/pkg-kde/branches/kde4/packages/kdeutils/debian . #do changelog #refresh patches while quilt push ; do quilt refresh ; done quilt new 05_README_changes.diff quilt edit README quilt refresh dpkg-buildpackage #profit and that's (if existing patches works as is) the full list of steps to update to new upstream and do a debian specific change. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Trying to understand patch management - in combination with version control
On 2008-09-09, Michael Biebl <[EMAIL PROTECTED]> wrote: >> while quilt push ; do quilt refresh ; done >> quilt new 05_README_changes.diff >> quilt edit README >> quilt refresh > > I assume you have set QUILT_PATCHES=3Ddebian/patches in ~/.quiltrc for > this to work properly? yes. along with a lot of other options. >> and that's (if existing patches works as is) the full list of steps to >> update to new upstream and do a debian specific change. > > You forgot to commit your changes to SVN ;-) yeah. I also do that normally :-/ /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Quilt and patches directory
On 2008-09-14, Raphael Geissert <[EMAIL PROTECTED]> wrote:
> Russ Allbery wrote:
>
>> Raphael Geissert <[EMAIL PROTECTED]> writes:
>>
if [ -e ${where}debian/rules -a -d ${where}debian/patches ]; then
export QUILT_PATCHES=debian/patches
>>>
>>> Shouldn't it be
export QUILT_PATCHES=${where}debian/patches
>>> ?
>>
>> No, quilt figures that part out for itself.
>
> I don't understand the pourpose of the "for where in ..." then.
If you use quilt for patch management that isn't debian related.
/Sune
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging with CMake
On 2008-10-05, Laurent Léonard <[EMAIL PROTECTED]> wrote: > --nextPart1380824.HK0hGSmbvk > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline > > Hi,=20 > > I try to build the package kio-ftps, but the 0.2 version (for KDE 4) uses=20 > CMake. What is the procedure to build a Debian package with CMake ? Try look at automoc package. If pkg-kde-tools had left NEW, I would have recommended you to look at that, as it explains and come with examples on how to package KDE4 packages. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging with CMake
On 2008-10-06, Jose Luis Blanco <[EMAIL PROTECTED]> wrote: > If your question is how to build a Debian package... I don't know about any > "standard" procedure. I had to do such one package and I created a dummy > "configure" scripts which in turn calls "cmake" with some proper variables > set. > Apart from that configure, the rest is using the standard Debian packaging > tools. > > If anyone knows about a more elegant way than the "dummy configure file", I'd > be > also interested in it :-) Sounds like a hack. (And I have send a patch to dh_make that gives proper cmake templates. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490940 ) /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging with CMake
On 2008-10-06, Robin Cornelius <[EMAIL PROTECTED]> wrote: > cmake does not have a proper clean target in the unix makefiles in > generates, which is a pain. Or not one that cleans as you would fully > expect. It does keep its working files in the current directory so a > the way i have done this is to do something like :- > > for the main build :- > > mkdir build > cd build > cmake _DSOMEFLAGS:BOOL=true.. > > then the clean rule can just purge "build/" > > this produces working debs and keeps the orig.tar.gz clean too. > > This does seem a little dirty which makes me think i'm not quite doing > it right though so if anyone has a better way to do this?, but it does > work. It is neither dirty or a pain, but much easier to work with. Building out of source as much as possible is making cleaning up easier. And cmake is designed this way. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging with CMake
On 2008-10-06, Robin Cornelius <[EMAIL PROTECTED]> wrote: > On Mon, Oct 6, 2008 at 4:52 PM, Sune Vuorela <[EMAIL PROTECTED]> wrote: > roduces working debs and keeps the orig.tar.gz clean too. >>> >>> This does seem a little dirty which makes me think i'm not quite doing >>> it right though so if anyone has a better way to do this?, but it does >>> work. >> >> It is neither dirty or a pain, but much easier to work with. Building >> out of source as much as possible is making cleaning up easier. And >> cmake is designed this way. >> > > It didn't seem right probably because of being used to the way > autotools work and this is different. What seemed dirty was having to You can usually do out of tree builds with autotools as well. > "mkdir build" and "rm -d" etc within debian/rules. I can see > advantages having the build area completely separate from the source > as it ensures that source will not be touched during build and makes > cleaning a trivial directory delete. Any examples of an invocation of > cmake from debian/rules for build and clean? as i would be quite > interested to see if I am doing it correctly or not. Currently, I recommend automoc. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kio-ftps-kde4
On 2008-10-07, Laurent Léonard <[EMAIL PROTECTED]> wrote: > --nextPart1512095.XNzvprD9R2 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline > > Dear mentors, > > I am looking for a sponsor for my package "kio-ftps-kde4". > > * Package name: kio-ftps-kde4 > Version : 0.2-1 > Upstream Author : Magnus Kulke <[EMAIL PROTECTED]> > * URL : http://kasablanca.berlios.de/kio-ftps/ > * License : GPL > Section : kde > > It builds these binary packages: > kio-ftps-kde4 - an ftps KIO slave for KDE 4 I don't have any ftps services to test it with, but kde packaging is not new to me, so I can review the packaging at least, but don't expect a upload. What's with all those commented dh_ foo lines in the rules file ? You asked about how to use cmake. Why did you completely ignore the replies? The cmake usage is wrong. The copyright file is a joke, right ? How it the rfc file licensed? usually they are non-free. Upstream should add himself to the files. David is not upstream. But that's not something you should fix, but just forward. Why do you call your package kio-ftps-kde4 and not just kio-ftps? It won't be around for lenny release and squeeze will be kde4 only. > The package appears to be lintian clean. No it doesn't. Lintian warns about rpath. Please don't build with rpath. That's what I noticed for now. but i guess it needs at least one more iteration. And I haven't yet tried building it in a clean chroot. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kio-ftps-kde4
On 2008-10-07, Laurent Léonard <[EMAIL PROTECTED]> wrote: >> What's with all those commented dh_ foo lines in the rules file ? > > Mmm it's default dh_ commands, I suppose I have to delete what I don't need= > ? They clutter reading of the rules file, no reason to keep them around. > >> >> You asked about how to use cmake. Why did you completely ignore the >> replies? The cmake usage is wrong. > > I read the advice to build the binaries in a different subdirectory and you= >=20 > seemed to agree that. You also recommended automoc but I didn't found=20 > documentation about how to use it. What's wrong with the cmake usage ? > > I saw your patch on dh-make but it concerns the 0.46 version, I used the 0.= > 42=20 > from Lenny. I will use a Debian Sid virtual machine to build the package.=20 Looking ath this in your makefile: configure: configure-stamp configure-stamp: dh_testdir touch configure-stamp build: build-stamp build-stamp: configure-stamp dh_testdir mkdir $(CURDIR)/build cd $(CURDIR)/build && cmake -D CMAKE_INSTALL_PREFIX=/usr .. $(MAKE) -C $(CURDIR)/build you start with some empty targets that does nothing, then several commands in the build-stamp target that could need to get several targets. And it can't recover from a partially failed build. having build-stamp depending on build/Makefile and build/Makefile to do the CMake calls would be better. >> The copyright file is a joke, right ? >> >> How it the rfc file licensed? usually they are non-free. > > I will add:=20 > > Others Copyrights : > - rfc4217.txt : 2005, The Internet Society > > Do I have to include the full license applied to the document in the copyri= > ght=20 > file ? You need the full gpl header in the copyright file, you need to add the copyright holders and you need to figure out wether the rfc file is free at all. They usually aren't, so documenting it is not enough. >> Why do you call your package kio-ftps-kde4 and not just kio-ftps? It >> won't be around for lenny release and squeeze will be kde4 only. > > I will change the package name to "kio-ftps". Do I have to post a new ITP w= > ith=20 > the new package name ? No need to do that, as ITPs are soft intends, it is about making sure that they are human readable. >> Lintian warns about rpath. Please don't build with rpath. > > According to lintian 1.24.2.1 from Lenny (and I suppose the same version is= >=20 > used on the mentors.debian.net system ?) it seems to be clean. I suppose yo= > u=20 > are using lintian 2.0.0 from Sid, I just installed it.=20 > > Adding "-D CMAKE_SKIP_RPATH:boolean=3Dtrue" when calling cmake seems to fix= > the=20 > problem, is it the correct way to do that ? I just saw this option in your= >=20 Yes. Asking cmake to not build with rpath is the right thing. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kio-ftps-kde4
On 2008-10-08, Laurent Léonard <[EMAIL PROTECTED]> wrote: > --nextPart1282828.IVFam4LvNy > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline > > Can I simply update the package after the modifications or do I have to=20 > increment the revision number and add related informations in the changelog= >=20 > file ? Some people insist on increasing the revision., some people insist of the opposite (that first upload should be revision -1). But there is also a few that doesn't care much. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kio-ftps
On 2008-11-01, Sandro Tosi <[EMAIL PROTECTED]> wrote: > Hi Laurent, > > On Sat, Nov 1, 2008 at 16:04, Laurent L?onard <[EMAIL PROTECTED]> wrote: >> Dear mentors, >> >> I am looking for a sponsor for my package "kio-ftps". > ... >> kio-ftps - an ftps KIO slave for KDE 4 > > Did you consider joining KDE packaging team[1] to maintain this > package with tehm and/or ask them for sponsorship? He is at least welcome to join in and maintain it in kde-extras. I personally don't have any ways of testing a ftps program, so I can't be helpful in all the process, but I do know quite a bit of kde4 packaging. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Preferred version format for svn revisions?
On 2008-11-09, Guido Loupias <[EMAIL PROTECTED]> wrote: > Hello, > > Could someone tell me if there is a preferred version format for svn > revisions? > Right now I have something like +svn. If it is a snapshot after a release, I also do that. If it is a snapshot leading up to a release, I would do nextupstreamversion~svnREVISION. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On 2008-12-09, Paul Wise <[EMAIL PROTECTED]> wrote: >> I doubt that - merely adding a new symbol is NOT a bug, let alone >> release-critical. > > Right, but not bumping shlibs at the same time is an RC bug AFAIK. I agree. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kita2
On 2008-12-27, Hiroyuki Yamamoto wrote: > > Upstream Author: Hideki Ikemoto > * URL: http://kita.sourceforge.jp/ Looking at this page, without much japanese knowledge, it looks like a kde3 application > * License: The MIT License > Section: net > Language: Ruby > Description: Ruby based 2ch client for KDE and the kde3 ruby bindings is planned to be discontinued in debian right after lenny release. Unless I'm mistaken about what it is using, I don't think uploading this to debian will serve much purpose. /Sune > Kita2 is useful to view "2ch-style Bulletin Board System" that use > "bbs.cgi" and "read.cgi", it is like that we use RSS reader to read > blogs. It helps you to read/write articles in such BBS. > . > 2ch-style BBS include > - 2 channel (http://www.2ch.net, largest BBS in Japan) > - Pink channel (http://www.bbspink.com/) > - Machi-BBS (http://www.machi.to/) > - Shitaraba (http://rentalbbs.livedoor.com/jbbs/) and so on. > > > It builds this binary package: > kita2 - Ruby based 2ch client for KDE > > The package appears to be lintian clean. > > > The package can be found on mentors.debian.net: > - - URL: http://mentors.debian.net/debian/pool/main/k/kita2 > - - Source repository: > deb-src http://mentors.debian.net/debian unstable main > - - dget > http://mentors.debian.net/debian/pool/main/k/kita2/kita2_1.90.4-1.dsc > > Please get its source, check it and upload it. > > > Regards, > > - -- > Hiroyuki Yamamoto > yama _at_ gmail.com > yamamoto _at_ debian.or.jp > > -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: kita2
On 2008-12-28, Hiroyuki Yamamoto wrote: > Hi, > > Sune Vuorela wrote: >> On 2008-12-27, Hiroyuki Yamamoto wrote: >>> Upstream Author: Hideki Ikemoto >>> * URL: http://kita.sourceforge.jp/ >> >> Looking at this page, without much japanese knowledge, it looks like a >> kde3 application > > Approximately, no. > The upstream author says about the previous C++ version, > kita that will not correspond with kde4. > So, he introduced the new ruby version, kita2. > >>> * License: The MIT License >>> Section: net >>> Language: Ruby >>> Description: Ruby based 2ch client for KDE >> >> and the kde3 ruby bindings is planned to be discontinued in debian right >> after lenny release. >> >> Unless I'm mistaken about what it is using, I don't think uploading this >> to debian will serve much purpose. > > Hmm, kita2 can be used also with kde3 now. > The future, when the ruby binding of kde3 was lost, > the ruby binding programs will be embarrassed. If we are a bit optimistic about the release process and a bit pessimistic about time in NEW, I guess kita2 will enter debian around the same time as lenny gets released. > > How about kde4? KDE4 has nice ruby bindings, currently available in experimental. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: kita2
On 2008-12-28, Hiroyuki Yamamoto wrote: >>> How about kde4? >> >> KDE4 has nice ruby bindings, currently available in experimental. > > Oh, thanks. > When kde4 has entered in sid, kita2 should depend on korundum4 package. > http://packages.debian.org/experimental/korundum4 It needs more work than just change the dependencies to make it work with korundum4 /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: kita2
On 2008-12-29, Junichi Uekawa wrote: >> It needs more work than just change the dependencies to make it work >> with korundum4 > > Are we talking about a package which only exists in experimental > replacing the version in sid? Yes. and the replacement is planned ASAP. > Let the version which works today with a sid version, and make it work > with kde4 version when it's in unstable; does it sound reasonable? Well.. I think any work with the version that works with a sid version today is a waste of time - and if no one is planning to actually port it to kde4, someone will also have to, very soon, to ask for removal of it. So instead of adding a package to be removed soon after it is clear of NEW, I suggest not adding it at all. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net
On 2009-01-19, Ben Finney wrote: > * When fixing bugs that prevented a previous release (e.g. one made to > mentors.debian.net) from making it into Debian (e.g. because the > sponsor requires further changes), recommended practice is to > increment the release number and make a new changelog entry, to > easily distinguish from any existing release. This is afaik only recommended if you want Neil Williams to sponsor you. If someone is working with me, this is absolutely *not* recommended. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFS - kommando - ITP #336607
Hi! I have built kommando, a kde wheel menu. It gives quicker access to some programs - and it is a nice piece of showoff-eyecandy ;) http://mirror.pusling.com/kommando-rfs/ I have had people using the package for some time now - but I think it is a so cool program that it should enter debian. and of course - those picky programs, linda and lintian, do not seem to have any errors/warnings -- Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS - kommando - ITP #336607
On 2005-11-01, Christoph Haas <[EMAIL PROTECTED]> wrote: > - the debian/copyright lacks the years of copyright Fixed > - insane number of Build-Depends - are they all necessary? Maybe not. working on this - it was the 'shortcut' mentioned in new maintainers guide - maybe it was wrong to use it. It is fixed now this was my shortcut #1 > - still it doesn't build in a pbuilder so the dependencies are > probably wrong [1] Definately wrong shortcut ;) > - the debian/control refers to "Neverwinter Nights". Although I know > what you mean that may not be clear to many. And it's probably a > trademark. Suggestion: > "A wheel-menu to quickly pick menu items with the mouse" > The long description doesn't fully taste right to me but I don't have > any creative suggestion here. Took your suggestion, and edited a bit in the long description > - You have created a nice man page. Did you send it upstream so it can > be included in the orig.tar.gz at the next upstream release? No - I will do it - it is mostly help2man ;) help2man was my shortcut #2 > - debian/rules contains lines that can be removed (all the dh_* > commands that are commented out). Also you probably don't need to > call dh_installexamples or dh_link. Fixed. And no more shortcuts ,) Still same place (and same debian-revision) http://mirror.pusling.com/kommando-rfs/ /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS - kommando - ITP #336607
On 2005-11-02, Ana Guerrero <[EMAIL PROTECTED]> wrote: > it fails. You must change it to: > > Build-Depends: debhelper (>> 3.0.0), kdelibs4-dev fixed that. > -The program is a systray app, so it would be good to Recommend: kicker Quite reasonable; will add that. > > -Some files are placed in incorrect directories: > /usr/share/doc/HTML/en/kommando/* > should be at: > /usr/share/doc/kde/HTML/en/kommando/* I think I have found where this is installed and have fixed that. But the help functionality still seems to do nothing .. I had to do a little edit in the Makefile.in to make the common-symlink point to ../common and not full path ... > And: > /usr/share/applnk/Utilities/kommando.desktop > should be at: > /usr/share/applications/kde/ hmm.. this one is quite harder ... what is the appropriate way? from src/Makefile.am shelldesktopdir = $(kde_appsdir)/Utilities (and this one is of course in src/Makefile.in and src/Makefile) Should I manually correct it in src/Makefile.in before building? Should I add a line in my debian/rules that changes the Makefile after configure and before building Should I change the Makefile.am and try to re-automake the Makefile.in For now, I have manually edited Makefile.in > and then add to the kommando.desktop file the line: > Categories=Qt;KDE;Utility; okay. > -Add a Debian menu file (and don't forget convert the png icons to xpm). menufile, fine... but I isn't the only way to get a xpm icon to get upstream to include one ? Otherwise I need to build-depend on some tool to convert png to xpm, which is otherwise not needed. A tool like imagemagick could do it. Imagemagick added to build-dep. Is it true that update-menus when run in postinst/postrm does not affect my menu as a user in kde ? > *Important: > -debian/changelog: is it necesary the "Passes lintian" line? > I'm not sure if it is ok, keep the changelog of the package before > this was out from the official archive. Any one else have an opinion on this? Package changelogs from unofficial archives, should they be removed or is it okay to keep them ? > -debian/copyright: Add the copyright years. Fixed > *Not so important, but better change: > -debian/control: I don't think you need mention "Neverwinter Nights" in > the short description, most of people has never player this game and Changed. > -The man page doesn't have an author section or see also section > where puts the program webpage. And the program description is too short. > Also, You should add yourself like the manpage author. Have done a little more work in the manpage And updates are now uploaded same place. http://mirror.pusling.com/kommando-rfs/ /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: statist - terminal based statistics
On 2005-11-02, Jakson A. Aquino <[EMAIL PROTECTED]> wrote: > I think that I don't need the files below: > > dirs postinst.ex preinst.ex statist-default.ex > compat postrm.exprerm.ex > > Can I delete them? Try ;) - or at least move them to somewhere else ;) (compat are needed) /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS - kommando - ITP #336607
On 2005-11-06, Christoph Haas <[EMAIL PROTECTED]> wrote: > the package looks a lot better now. Thanks for your work. I have just > uploaded the package. Thank you. Unfortunatly, it got rejected due to no orig.tar.gz-file. > Some minor things you may want to look at for your next revision: > > You change the kommando-0.2/src/kommando.desktop file. You should either > have the upstream include this change in the next release or use "dpatch". > If the upstream comes up with a new release you will have to remember > changing that file again. I think I will mail it to upstream to have him include it. and also with the makefile. > Spend some time looking at the debhelper scripts (dh_*). Each of them has a > man page. And many tasks you do manually in your debian/rules file are > easier done through debhelper. Example: > "cp debian/kommando.xpm debian/kommando/usr/share/pixmaps/" would look > nicer if you used "dh_install" for it. Yes ofcourse ;) > I personally don't like to "make install" into debian/$PACKAGE. I rather > pick the files I need and use dh_install to copy them into place. At least > in simpler packages like these which don't contain hundreds of files it's > easy. But that's a matter of taste. I might look into it, but I don't know yet. > Thanks for your contribution so far. Thank you for your time and for sponsoring me - hope that you will reupload with orig.tar.gz > Christoph Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about skim.
On 2005-11-13, sebastien marbrier <[EMAIL PROTECTED]> wrote: > I have two solutions, the first one is to install both sarge and sid but this > is a dirty work, I am also thinking about making the packages in a chrooted > environnement but I have never done that so far. > Can you give some advice please ? A chroot is a nice solution - I use it for many things. the program 'debootstrap' can help you building a chroot. just: mkdir sid-chroot sudo debootstrap sid sid-chroot http://yournearestmirror. sudo chroot sidchroot in here, you can create a user account, install packages and whatever you like. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
repack upstream sources or overrides ?
Hi! I am working on #338554 - and I am almost there. I have one big problem, though. Upstream did not run make distclean before releasing the tarball. Of course, linda and lintian complains about this. Should I add overrides for lintian warnings and linda _errors_ to address this problems - or is the right thing to unpack sources; make distclean; pack sources and call that .orig.tar.gz ? (I have reported this upstream and upstream will fix on next release) /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: repack upstream sources or overrides ?
On 2005-11-15, Michael Biebl <[EMAIL PROTECTED]> wrote: > Maybe a bit offtopic but I looked at #338554 and noticed that there are > now several different naming schemes for kwin window decorations: I am working on this too. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: repack upstream sources or overrides ?
On 2005-11-15, Frank Küster <[EMAIL PROTECTED]> wrote: > Obviously you didn't read > > file:///usr/share/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz I have read that - and yes - I think repacking is not in normal best practice. But I sure don't override linda _errors_ either > >> What errors? Linda: E: packagename; Package contains autoconf-generated files Lintian: W: packagename source: configure-generated-file-in-source config.status W: packagename source: configure-generated-file-in-source config.lo >> - source tarball includes generated binaries >> (is this your situation?) Not binaries, but autoconf generated files that are cleaned by make distclean when run first in my clean target > I don't think that generated binaries in the tarball justify repackaging > - I think it is always possible to remove them in the clean target, > which will always be called when dpkg-buildpackage is used. It is easy to remove it, yes. The package is just not linda/lintian clean. Making lintian overrides is quite easy, but I can't make linda override work. Any advice ? /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: repack upstream sources or overrides ?
On 2005-11-15, Frank Küster <[EMAIL PROTECTED]> wrote: > "fakeroot debian/rules binary" directly won't get bitten. Other than > that, I would do nothing - it is a bug, therefore a lintian override is > inappropriate, but it is not serious enough to justify messing with the > tarball. So you suggest that I do not repack source and do not add overrides ? http://ftp-master.debian.org/REJECT-FAQ.html about lintian in the serious violations-part "Sometimes there are valid reasons, but then you should either file a bug against lintian if it's generally wrong or include an override in your package, giving a reason in the changelog for it" -- Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS - kde window decoration powder
Hi! I have now a package ready to close my ITP: #338554 It is not lintian clean - upstream did not run make distclean before releasing - so lintian complains about some files being present - but they are removed in the clean tag. Linda complains about the same thing. Only fix for this is repacking the source. Upstream will fix this on next release. THe package is renamed from the name in the ITP as recommended by the debian kde/qt team. Powder is a window decoration for kde, which gives new 'buttons' in the top bar for things minimizing/maximizing and the border of the windows. The 'buttons' have a special glow effect, which looks nice and the border is wide to make it look cool - and to make it easy to 'catch' the border when resizing. The packages should be ready at http://mirror.pusling.com/powder-rfs And it builds fine in pbuilder /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS - kde window decoration powder
On 2005-12-10, Justin Pryzby <[EMAIL PROTECTED]> wrote: > Please add the years of copyright holding in ./debian/copyright. Also Done. > consider adding, at least to ./debian/rules and ./debian/copyright, a > phrase like "Modifications are a work of Sune Vuorela during the year > 2005, and are hereby released into the public domain. It is modified dh_make templates - and nothing else ? > Uncomment unused things in ./debian/rules. The only unused thing in rules is this: #docbook-to-man debian/kwin-style-powder.sgml > kwin-decor-powder.1 But, okay, removed. > You might prefer to list the README file as an argument to > dh_installdoc rather than in ./debian/docs. I think I like it better having it in debian/docs > Best wishes to find a sponsor. Sorry, that I cannot sponsor you. Thanks for your advice. uploading new version while sending this - so it might be available in some minutes .. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS - kde window decoration powder
On 2005-12-14, Justin Pryzby <[EMAIL PROTECTED]> wrote: > The templates have a liberal license. Your modifications, if not > trivial, are copyright you, and it would be good to note that. It I will describe my modifications as really trivial. adding --disable-rpath to one line - and remove some #dh_-lines. Claiming somekind of copyright of that part of it would be a joke ;) > I've documented a request for this type of thing to be added to the > templates in BTS #336982. I saw it - I was about to report a bug for YEAR in the template ... /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS - kde window decoration powder
On 2005-12-10, I wrote: > I have now a package ready to close my ITP: #338554 > > It is not lintian clean - upstream did not run make distclean before > releasing - so lintian complains about some files being present - but > they are removed in the clean tag. Linda complains about the same thing. > Only fix for this is repacking the source. > Upstream will fix this on next release. > > > THe package is renamed from the name in the ITP as recommended by the > debian kde/qt team. > > Powder is a window decoration for kde, which gives new 'buttons' in the > top bar for things minimizing/maximizing and the border of the windows. > The 'buttons' have a special glow effect, which looks nice and the > border is wide to make it look cool - and to make it easy to 'catch' the > border when resizing. > > The packages should be ready at > http://mirror.pusling.com/powder-rfs > > And it builds fine in pbuilder No one interested in sponsoring ? /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: kde-style-comix
I have this teeny weeny package called kde-style-comix, which gives a nice widget style and window decorations to your kde. It closes a one year old itp: #286205 the package is located here: http://mirror.pusling.com/comix-rfs/ and it is almost lintian clean. upstream provides CVS-dir, which lintian rightfully complains about. Any comments welcome - and perhaps a sponsorship ;) /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing an ITP
On 2006-01-11, Bram Neijt <[EMAIL PROTECTED]> wrote: > How long is some time ago. I have the same "problem" and was wondering > when a RFS should be seen as dead? So what is the avarage time it > takes for a new package to become sponsored? My packages has taken a couple of weeks. 1) post rfs. 2) read all replyss - fix stuff 3) wait for more replies. 4) ask another time in same thread 5) fix final bits. 6) get sponsored 1-3 takes about a week and a half. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dsbltesters
On 2006-01-26, Al Nikolov <[EMAIL PROTECTED]> wrote: > I assumed though that ITP should be closed after that the package was become > ready and was appeared in the pool. I'm i wrong? It should be closed in the changelog. Then it will automagically be closed when package get build. /Sune Vice President of packaging kommando -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW queue
On 2006-03-07, Frank Küster <[EMAIL PROTECTED]> wrote: > They process NEW binary packages quite fast, within one to three days to > my impression. that _WAS_ also my impression ... but having a package stuck for more than two months without any notices have changed my impression. (look on top-8 on NEW - simple package, no controversial stuff) /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Closing #338657
On 2006-03-10, Marco Cabizza <[EMAIL PROTECTED]> wrote: > The only error i get is binary-without-manpage because the package > actually has no manpage. That task is quite easy to solve ;) Just write a man page ... perhaps help2man can help you /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS - two icon sets for kde - kde-icons-gorilla and kde-icons-korilla
Hi! I have a couple of ITPs where I finally got the two packages in shape to close http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348101 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348103 They are quite similar, it is only approx. the name that differs. And the packaging is quite easy to overview. It is both cool icon themes bringing monkey spirit to your desktop! And they are located here: http://mirror.pusling.com/kgorilla /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problems with leftovers from unregistering alternatives
Hi ! I have just recieved a bug: #364742 - and piuparts is as always right. Something fails in removing alternatives again. /usr/share/icons/default/index.theme pointing into alternatives # update-alternatives --display x-cursor-theme x-cursor-theme - status is auto. link currently points to /usr/share/icons/ComixCursors-Black-Large-Slim/index.theme I have unregistered also that link with the alternatives, but trying manually anyway: [EMAIL PROTECTED]:/# update-alternatives --remove x-cursor-theme /usr/share/icons/ComixCursors-Black-Large-Slim/index.theme [EMAIL PROTECTED]:/# update-alternatives --display x-cursor-theme x-cursor-theme - status is manual. link currently points to /usr/share/icons/ComixCursors-Black-Large-Slim/index.theme No versions available. so that changed nothing. But this did. # update-alternatives --remove-all x-cursor-theme [EMAIL PROTECTED]:/# update-alternatives --display x-cursor-theme No alternatives for x-cursor-theme. I of course cannot use --remove-all in my post-inst script, what have I done wrong - and how do I correct it ? /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with leftovers from unregistering alternatives
On 2006-04-26, Steve Langasek <[EMAIL PROTECTED]> wrote: > what does update-alternatives --list x-cursor-theme list in this case? It shows nothing. [EMAIL PROTECTED]:/# update-alternatives --list x-cursor-theme [EMAIL PROTECTED]:/# > It really looks to me like a u-a bug, not a bug in the calling maintainer > script. I have been considering the same thing, but I am asking advice here before doing anything else, as I am quite new into u-a. Except if I need to remove the alternatives links in the exact opposite order of registering them. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with leftovers from unregistering alternatives
On 2006-04-26, Steve Langasek <[EMAIL PROTECTED]> wrote:
> Ok, if update-alternatives --list shows nothing, and symlinks are left in
> place on the filesystem, that sounds like a bug in u-a to me.
But shouldn't a bug in u-a be easy to reproduce ?
I tried something minimal:
[EMAIL PROTECTED]:/# for i in 1 4 2 3 ; do touch /tmp/${i}; update-alternatives
--install /tmp/alt-test alt-test /tmp/${i} 10; done
[EMAIL PROTECTED]:/# update-alternatives display alt-test
update-alternatives: unknown argument `display'
[EMAIL PROTECTED]:/# update-alternatives --display alt-test
alt-test - status is auto.
link currently points to /tmp/1
/tmp/1 - priority 10
/tmp/4 - priority 10
/tmp/2 - priority 10
/tmp/3 - priority 10
Current `best' version is /tmp/1.
[EMAIL PROTECTED]:/# update-alternatives --list alt-test
/tmp/1
/tmp/4
/tmp/2
/tmp/3
[EMAIL PROTECTED]:/# for i in 1 2 3 4 ; do update-alternatives --remove
alt-test /tmp/${i} ; done
[EMAIL PROTECTED]:/# update-alternatives --display alt-test
No alternatives for alt-test.
[EMAIL PROTECTED]:/# update-alternatives --list alt-test
[EMAIL PROTECTED]:/#
where update-alternatives behaves like expected.
/Sune
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with leftovers from unregistering alternatives
On 2006-04-25, Sune Vuorela <[EMAIL PROTECTED]> wrote: > I have just recieved a bug: #364742 - and piuparts is as always right. > Something fails in removing alternatives again. I had a typo in my prerm script. Will fix it soon. if someone does a 's/ComixCursorss/ComixCursors-/' in the prerm, everything works again. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS - two icon sets for kde - kde-icons-gorilla and kde-icons-korilla
On 2006-04-22, Sune Vuorela <[EMAIL PROTECTED]> wrote: > Hi! > > I have a couple of ITPs where I finally got the two packages in shape to > close > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348101 and > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348103 > > They are quite similar, it is only approx. the name that differs. > And the packaging is quite easy to overview. > > It is both cool icon themes bringing monkey spirit to your desktop! > > And they are located here: > http://mirror.pusling.com/kgorilla > > /Sune No comments? Noone interested ? /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS - two icon sets for kde - kde-icons-gorilla and kde-icons-korilla
On 2006-05-01, Sune Vuorela <[EMAIL PROTECTED]> wrote: > On 2006-04-22, Sune Vuorela <[EMAIL PROTECTED]> wrote: >> Hi! >> >> I have a couple of ITPs where I finally got the two packages in shape to >> close >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348101 and >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348103 >> >> They are quite similar, it is only approx. the name that differs. >> And the packaging is quite easy to overview. >> >> It is both cool icon themes bringing monkey spirit to your desktop! >> >> And they are located here: >> http://mirror.pusling.com/kgorilla >> >> /Sune > > No comments? > Noone interested ? Still noone ? /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: kwin-style-crystal - transparant window decoration
Hi!
I have a package ready for kwin-style-crystal.
ITP:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364360
Source: kwin-style-crystal
Section: kde
Priority: optional
Maintainer: Sune Vuorela <[EMAIL PROTECTED]>
Build-Depends: debhelper (>= 4.0.0), autotools-dev, kdebase-dev
Standards-Version: 3.7.2
Package: kwin-style-crystal
Architecture: any
Conflicts: crystal
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: semi transparant window decoration for KDE
Crystal offers you pseudo transparent titlebar, buttons and borders
transparent, so you can see more of your lovely background image
Transparancy and buttons can be costumized to match your wishes.
Offers rounded corners as well
.
And it is of course nice to look at. Upstream says:
"- Don't forget to breathe, while drooling."
And package is located at http://mirror.pusling.com/crystal-rfs
(The Conflicts: crystal is upstream distributing a package without any
dependency information with this name)
/Sune
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS - kde-style-polyester
ITP:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338635
Source: polyester
Section: kde
Priority: optional
Maintainer: Sune Vuorela <[EMAIL PROTECTED]>
Build-Depends: debhelper (>= 5.0.0), automake1.9, autoconf, libtool,
kdelibs4-dev (>= 4:3.2), kdebase-dev (>= 4:3.2)
Standards-Version: 3.7.2
Package: kde-style-polyester
Section: kde
Architecture: any
Depends: ${shlibs:Depends}
Description: Polyester widget style and kwin decoration for KDE3
Widget style and kwin decoration both aim to maintain a good balance between
eyecandy and simplicity. Widget style is based on Plastik, window decoration
is based on Smoothblend.
.
Homepage: http://www.kde-look.org/content/show.php?content=27968
And the package is here:
http://mirror.pusling.com/polyester-rfs/
/Sune
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS - kde-style-polyester
On 2006-05-28, Christoph Haas <[EMAIL PROTECTED]> wrote: >> And the package is here: >> http://mirror.pusling.com/polyester-rfs/ > > Could you name the source package "kde-style-polyester", too? I find it > confusing when source and binary packages have totally different names. Sure. Reuploadet. /Sune /Sune /Sune /Sune /Sune /Sune /Sune /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS - two icon sets for kde - kde-icons-gorilla and kde-icons-korilla
On 2006-05-28, Christoph Haas <[EMAIL PROTECTED]> wrote: >> >> http://mirror.pusling.com/kgorilla > > Just checking kde-icons-korilla. Lintian is right: > > E: kde-icons-korilla; The font Gah. I just did something to the packages now. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS - kwin-style-dekorator -- window decoration for kde using png images
Hi!
I am looking for comments - and hopefully a sponsorship - for
kwin-style-dekorator.
Source: kwin-style-dekorator
Section: kde
Priority: optional
Maintainer: Sune Vuorela <[EMAIL PROTECTED]>
Build-Depends: debhelper (>= 5), autotools-dev, kdebase-dev
Standards-Version: 3.7.2
Package: kwin-style-dekorator
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: window decoration for kde using png-files
Make your own window decoration easy with deKorator.
Dekorator uses your own made images for buttons, borders
and so on, so go ahead and be creative.
Provides an example called uglyTheme
.
This is a window decoration, not a style
kwin-style-dekorator (0.3-1) unstable; urgency=low
* Initial release (Closes: #374869)
-- Sune Vuorela <[EMAIL PROTECTED]> Wed, 21 Jun 2006 20:04:02 +0200
It can be found on http://mirror.pusling.com/dekorator
Thanks in advance.
/Sune
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS - kwin-style-dekorator -- window decoration for kde using png images
On 2006-06-25, Sune Vuorela <[EMAIL PROTECTED]> wrote:
> I am looking for comments - and hopefully a sponsorship - for
> kwin-style-dekorator.
>
> Source: kwin-style-dekorator
> Section: kde
> Priority: optional
> Maintainer: Sune Vuorela <[EMAIL PROTECTED]>
> Build-Depends: debhelper (>= 5), autotools-dev, kdebase-dev
> Standards-Version: 3.7.2
>
> Package: kwin-style-dekorator
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: window decoration for kde using png-files
> Make your own window decoration easy with deKorator.
> Dekorator uses your own made images for buttons, borders
> and so on, so go ahead and be creative.
> Provides an example called uglyTheme
> .
> This is a window decoration, not a style
>
>
>
> kwin-style-dekorator (0.3-1) unstable; urgency=low
>
> * Initial release (Closes: #374869)
>
> -- Sune Vuorela <[EMAIL PROTECTED]> Wed, 21 Jun 2006 20:04:02 +0200
>
>
> It can be found on http://mirror.pusling.com/dekorator
>
> Thanks in advance.
..no comments?
A upload would be nice.
Thanks in advance.
/Sune
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS - kwin-style-dekorator -- window decoration for kde using png images
On 2006-07-01, George Danchev <[EMAIL PROTECTED]> wrote:
> Looks correct... a couple of extra things you may want to correct anyway:
> - since nothing goes to usr/{s}bin you don't need the debian/dirs file, so
> you
> can safely remove it.
Removed.
> - also remove the last two commented lines in debian/copyright after
> verifying
> what has been suggested there.
Removed - and I have checked all the files.
> KeyError thrown
> ('/usr/share/doc/kwin-style-dekorator/examples/themesStuff/The K-style').
> ).
>
> Please report a bug against linda appending the full output of
> linda --debug --traceback over your deb, and a pointer to your package
> location.
Reported.
>
>> A upload would be nice.
>> Thanks in advance.
>
> I hope you will find a sponsor.
So do I, thankyou for your time ;)
A new package is now uploaded on
http://mirror.pusling.com/dekorator
/Sune
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#284039: kdetv: existing debian packages
On Sunday 02 July 2006 21:45, Zsolt Rizsanyi wrote: > OTOH I don't really like the idea of manually trimming down the size of the > diff.gz. I have not manually trimmed down the size. I have just chosen the relevant parts of the patches to the autofoo generated files and only applied them. > Also I would prefer cleaning up the licencing issues instead of removing > the files from the source package. I have already contacted the current > kdetv maintainer, and I don't really see any problems with fixing the > issues. I will wait some time to see if this is resolved (meanwhile > working on the other things). The best thing is of course to have it licensed in a good way, but if that is not possible, removing is not hard. > So that would be the plan :) > Thanks Sune for all the work you have done, and thanks Aníbal for the offer > to sponsor the package. I plan to get it ready in a few weeks. > > Regards, > Zsolt pgp1Bw92sSuuf.pgp Description: PGP signature
Re: shc -- #335278 broken packaging -- non-DD NMU prepared
On 2006-07-13, Nigel Jones <[EMAIL PROTECTED]> wrote: >>From memory, aren't NMU's (even more so, non-DD NMU's) only meant to > fix RC bugs? Not new upstream releases? 0-day nmus are to fix RC bugs. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: File permissions
On 2006-09-11, James Healy <[EMAIL PROTECTED]> wrote: > The upstream tarball has an examples directory which I am installing > into the package using dh_installexamples. None of the examples are > shell scripts or ELF binaries, yet they seem to untar with executable > permissions. > > What is the best way to modify the permissions when I copy them over? a snippet from one of my debian/rules binary-arch: build install dh_testdir dh_testroot dh_installchangelogs dh_installdocs # fixpermissions chmod 644 debian/kde-icons-korilla/usr/share/icons/Korilla/48x48/apps/* /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: File permissions
On 2006-09-11, Adam Cécile (Le_Vert) <[EMAIL PROTECTED]> wrote: > I don't think exec bit in a tarball is right. Best way is to repack upstream > sources. No. Upstream should only be repacked in rare cases like when it contains non-free materials. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: general packaging question
On 2006-11-14, Ritesh Raj Sarraf <[EMAIL PROTECTED]> wrote: > How would I then add entry of the old changelog into the current knetstats > package i.e. 1.6.2 ? > > I hope there is a proper way to tackle such situations. apt-get install devscripts man uupdate it does exactly what you ask for. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dnshistory
On 2006-11-26, Matthias Julius <[EMAIL PROTECTED]> wrote: > Hmm, the opinion on this matter seems to be somwhat devided. Some > people suggest the revision should be increased every time an upload > is made to a public place like mentors.d.n. I have only seen "keep -2 if you uploaded somewhere that has users" - like your own well-visited repo. mentors.dn does not count here. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
On 2006-12-11, Neil Williams <[EMAIL PROTECTED]> wrote: > What are the problems with CDBS (apart from debian/control automation)? The biggest problem are the layers of obscurity added by cdbs and the fact that the best docs are diving into the source. (and the fact that there has been some cdbs revisions that had broken other packages because changes wasn't 100% well thought) People have told me that until you have read and understood the cdbs classes you use, you should not use cdbs. I do not disagree much on that. As new package maintainer, you need to know what happens and shouldn't use cdbs to hide what is really going on. CDBS does also have its advantages somewhere - the use of a common system for larger stuff instead of all people inventing their own different build-abstraction-layer. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Recurring "please do" patterns in debian-mentors
On 2007-01-01, Nico Golde <[EMAIL PROTECTED]> wrote: > I guess not since this is not defined in the policy. Maybe=20 > if Homepage becomes a real control field. with two spaces it is formatted on the web like this: http://packages.debian.org/unstable/kde/yakuake with one space like this: http://packages.debian.org/unstable/kde/kfolding frontends format it different wether it starts with one or two spaces. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reasons why downgrades are Not Supported
On 2007-01-14, Justin Pryzby <[EMAIL PROTECTED]> wrote: > maintscripts often don't support downgrades just because downgrading has > always > been advertised as "not guaranteed to work", so very few maintainers put the > additional effort and clutter into their code. It is not about 'additional effort' but more like 'not being able to predict the future' how should the (pre|post)inst of package version 1.3 be able to undo the changes made in the (pre|post)inst of package version 1.5 ? /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: extra-license-file best pratices
On 2007-01-26, Andrea Bolognani <[EMAIL PROTECTED]> wrote: > 2. Edit the Makefile only in the Debian package, commenting out the > offending > lines > > 3. Remove the file in debian/rules, *after* installing it I would go for 3) it is the easiest - and often fiddling around with upstream (auto)make system is often worth to avoid for such small changes. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to put a license (question) in preinst/debconf
On 2007-03-16, Daniel Leidert <[EMAIL PROTECTED]> wrote: > Hi, > What would you choose and why? If there is a need for a click-wrap license - look at the sun java packages. But if the license don't require click-wrap, I would just ship it in debian/copyright. People should know that non-free stuff is something that they need to study the licensing, especially for commercial use. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Native package versus orig
On 2007-03-18, Michael Rasmussen <[EMAIL PROTECTED]> wrote: > > Hi mentors, > > When packaging for Debian you have two distinct ways of doing it, > native versus orig. > > My question is, if I am in close contact with upstream and upstream > always adds my patches to upstream source is there then any reason for > not choosing a native package? My changes file is empty except for the > Debian changelog. Yes - when you just need to make debian specific changes, upstream doesn't have to do a new release just for that. And it also makes NMU'ing easier /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: quilt, cdbs, dpatch, but is there even simpler ?
On 2007-03-21, Charles Plessy <[EMAIL PROTECTED]> wrote: > The easiest way to manage patches I know is cdbs, but I was not brave > enough to study wether it is possible to separate this feature from the > others. It is possible to use cdbs patchsys in non-cdbs packages, but it is very ugly and I think your sponsor will answer many weird questions. There are some :: rules that you need to manage if you try. But first step in trying is reading and understanding the simple-patchsys.mk from cdbs. But generally, I won't recommend it. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Are (c)debootstrap broken ?
On 2007-05-09, Manoj Srivastava <[EMAIL PROTECTED]> wrote: > chrooting into the dir, the error is that base-files postinst > cannot find awk. mawk had indeed been configured earlier. So, while > /etc/alternatives/awk exists, and points to mawk, there is no symlink > /usr/bin/awk created. > > Is the latest dpkg buggy? There is a critical bug agaisnt dpkg because of this issue - #422979 /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Symbol-versioning a C++ library
On 2007-05-25, Florian Weimer <[EMAIL PROTECTED]> wrote: > * Bas Wijnen: > >> This is slightly off-topic, for which I apologise. It's just that I >> learned about symbol versioning during my NM process, and nobody outside >> Debian seems to understand what it is. :-( > > *sigh* It's a bit sad that this is still being used in the NM process. Why? I have just been thru that part about symbol versioning and -Bsymbolic. And it was indeed very hard to get right. And I did swear several times during my answering. I am - now - very glad that my AM actually took me thru those parts. I disliked it while it was going on, but I really learned a lot. I have not yet used that specific part of my knowledge about neither -Bsymbolic nor symbol versioning, but I have already ended up in using the stuff I learned on the way. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: klthemes
On 2007-05-27, Jabka Atu <[EMAIL PROTECTED]> wrote: > > * Package name: klthemes > Version : 1.003-1 > Upstream Author : [EMAIL PROTECTED] > * URL : scex.sf.net > * License : GPLv3 > Section : contrib/kde Why contrib?? > > It builds these binary packages: > klthemes - Collection of kdm themes from the kde-look.org website I don't like that package name. Have you seen the kde-kdm-themes package ? Could you try talk to the maintainer of that package? maybe you could share the effort. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ntfs-3g (updated package)
On 2007-08-08, Adam Cécile (Le_Vert) <[EMAIL PROTECTED]> wrote: > Hmm, I have something crap to ask... > > As you may have noticed, wxwidget 2.8 is not available in Debian. > However Mathias Klose maintain it in Ubuntu... > > Would you sponsor my wx2.8 ubuntu sync uploads ? Please coordinate with ron, dam and other people in #-devel who has been discussing wx2.8 over the last couple of days. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xawtv (updated package)
On 2007-08-15, Krzysztof Burghardt <[EMAIL PROTECTED]> wrote: > xawtv-plugin-qt - quicktime plugin for xawtv and motv Has this been fixed in a way that doesn't make it segfault all the time? And become buildable with newer libquicktime? (I was the one hacking the quicktime plugin out of the package before etch release - and also looked into a bit of other things in it) /Sune (Not yet a DD, so can't sponsor) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kopete-otr 0.6-1
On 2007-09-12, Raphael Geissert <[EMAIL PROTECTED]> wrote:
> On 11/09/2007, Francesco Cecconi <[EMAIL PROTECTED]> wrote:
>> On Tuesday 11 September 2007, Raphael Geissert wrote:
>> > On 10/09/2007, Francesco Cecconi <[EMAIL PROTECTED]> wrote:
>> > > Dear DD,
>> > >
>> > > I am looking for a sponsor for my package "kopete-otr".
>> > >
>> >
>> > Maybe you should send an ITP first and add a (Closes: #nn) to the
>> > debian/changelog
>>
>> done,
>
> By the way, I don't think you require ${misc:Depends} in
> debian/control, so you can remove it.
debhelper(7) encourages you to add ${misc:Depends} no matter what.
/Sune
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reason for Failed build on some arch only
On 2007-10-03, Kartik Mistry <[EMAIL PROTECTED]> wrote: > Hi, > > My package Xosview is failed to build on (atleast) two arch with same > reason. Following are links from buildd. Hi! Did you actualy read the logs? It says quite clearly: your config.guess and config.sub is outdated. Find newer versions in autotools-dev /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help needed to fix gcc 4.7 bug in jellyfish package
On 2012-05-02, Andreas Tille wrote:
> Hi,
>
> I tried to fix the problem in the jellyfish package but the general
> hints given did not helped me really. Any more precise help to fix
> this problem:
>
> parse_dna.cc:97:3: error: narrowing conversion of '-3' from 'int' to 'const
> uint_t {aka const long unsigned int}' inside { } is ill-formed in C++11
> [-Werror=narrowing]
>
> --- jellyfish.orig/jellyfish/parse_dna.cc
> +++ jellyfish/jellyfish/parse_dna.cc
> @@ -57,7 +57,7 @@
It looks like you aren't the right place. It complains about line 97 and
you have edits in line 60 ?
/Sune
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnjq1op2.p7v.nos...@sshway.ssh.pusling.com
Re: Bug#672268: RFS: kde-gtk-config/2.0-1 [ITP] -- KDE configuration module for GTK+ 2.x and GTK+ 3.x style selection
On 2012-05-09, Boris Pek wrote: > My regular sponsor is very busy now and I am looking for a sponsor for my new > package "kde-gtk-config". > Description : KDE configuration module for GTK+ 2.x and GTK+ 3.x style > selection first, kde configuration modules are packaged as kde-config-foo second, what does it do that kde-config-gtk-style doesn't do ? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjqqdhb.p7v.nos...@sshway.ssh.pusling.com
Re: Bug#672268: RFS: kde-gtk-config/2.0-1 [ITP] -- KDE configuration module for GTK+ 2.x and GTK+ 3.x style selection
On 2012-05-11, Boris Pek wrote: > kde-config-gtk-style does not allow to: > * select themes for Gtk 3.x applications > * preview available themes for Gtk 2.x and Gtk 3.x applications > * custmize toolbars and menus for Gtk applications > * select icon themes for Gtk applications > * download and apply Gtk 2.x and Gtk 3.x themes from http://opendesktop.org/ > in few mouse clicks > > All these things can be done in kde-gtk-config. what about the following plan then: talk with the kde-config-gtk-style maintainers (kde-extras team and didier raboud) wether it makes sense to just let your package take over the kde-config-gtk-style name. It doesn't look like the current utility does something "your" utility doesn't, am I right? No need to have two tools with the same dependencies, same audience and one tool just does a subset of the other. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjqqm8u.p7v.nos...@sshway.ssh.pusling.com
Re: Bug#674717: RFS: qpdfview/0.2.2-1 [ITP]
On 2012-05-26, Benjamin Eltzner wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "qpdfview" > > * Package name: qpdfview >Version : 0.2.2-1 >Upstream Author : Adam Reichold > * URL : https://launchpad.net/qpdfview > * License : GPL-3 >Section : graphics > > It builds those binary packages: > > qpdfview - tabbed PDF viewer Please note for potential sponsors that this app is licensed as gplv3 and it uses poppler still at gplv2only. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjs2skr.p7v.nos...@sshway.ssh.pusling.com
Re: Bug#669565: RFS: gammaray/1.1.0-1 [ITP] -- Tool for examining the internals of Qt application
On 2012-08-10, Felix Geyer wrote: > On 10.08.2012 16:47, Jakub Adam wrote: >>> debian/patches/gammaray-probe-versioned-soname.patch: >>> >>> Why do you set a SONAME for gammaray_probe? >>> When gammaray changes the ABI custom plugins will break anyway >>> since you can't install different versions of gammaray. >> >> When SONAME is not set, lintian produces these warnings and error: >> >> W: gammaray: dev-pkg-without-shlib-symlink usr/lib/gammaray_probe.so >> usr/lib/gammaray_probe.so >> W: gammaray: shlib-without-versioned-soname usr/lib/gammaray_probe.so >> gammaray_probe.so >> E: gammaray: postinst-must-call-ldconfig usr/lib/gammaray_probe.so >> >> So the right solution is to override the warnings and add ldconfig call into >> postinst script by hand? > > Maybe a better solution would be to set the SONAME to the upstream version > number. > That way it's explicit that plugins need to be recompiled when the upstream > version > changes. whattabout just not offer -dev stuff for gammaray until there is actually a need for it? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnk2ga51.ut3.nos...@sshway.ssh.pusling.com
Re: Maintainer address for collab-maint team maintained packages
On 2012-11-19, Arno Töll wrote: > That said, I'd be very glad to have some mailing list Debian service > different to lists.d.o for such lightweight list management purposes. wasn't there a teams.dn ? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnkal18a.me.nos...@sshway.ssh.pusling.com
Re: libv8: library without SONAME
On 2009-02-09, Antonio Radici wrote: > Hi, > as part of ITP #497701 I'm packaging libv8, a high-performance > java script library written by Google and used in Chrominum, the > open source version of the Chrome browser. > > The source code is taken directly from the SVN tags here: > http://v8.googlecode.com/ > It uses scons to build the library but the built library has no > SONAME, the only thing I get from scons is libv8.so. > > The ubuntu maintainer of libv8* packages asked the authors to add > the SONAME in november: > http://code.google.com/p/v8/issues/detail?id=151 > > So, my question is: how should I proceed? Stop packaging until the > SONAME is avaiable? Do as the ubuntu maintainer does? (libv8.so in > the libv8 package and the .h files in libv8-dev?) > > I've ready somewhere that /usr/lib should only contains libraries with > SONAME's, should I create /usr/lib/v8/ and put the library in there? (as > it was done with mozilla libraries?) you could just build it with 0d soname. (d as in debian) /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian/control
On 2009-03-15, Laurent Guignard wrote: > On dim, 15 mar 2009 13:57:40 +0100, Jaromír Mikeš wrote: >> Hello, > > Hello, > >> >> I am not sure what to fill to "Section" in control file for my new package I >> am building. >> Program is small easy CLI utility generating sound (pink and white noise) >> >> Thanks for help >> > > For me this type of software has to be set in the "contrib" section, but i am > young in Debian and more experienced could confirm or not my opinion ! eh? contrib is for free stuff that has non-free build or runtime requirements. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Sponsorship requirements and copyright files
Hi! After a discussion on #debian-mentors and other places, I will not sponsor packages using the copyright file format described on http://wiki.debian.org/Proposals/CopyrightFormat It is a too complex, overengineered solution to a very minor issue. It is not easy readables for humans It is ugly Too time consuming to write and check No real gain. Discussions about this is welcome, but I think debian-devel is a better forum for that. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: kita2
On 2009-03-21, Hideki Yamane wrote: > On Sat, 17 Jan 2009 12:42:43 +0900 > Junichi Uekawa wrote: >> > So instead of adding a package to be removed soon after it is clear of >> > NEW, I suggest not adding it at all. >> >> So, it's been two weeks, is there a working kde4? > > How's about korundum4 and kita packages' status? > Any progress? So now, when currently running mirror push is done, you have everything available in unstable. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: katimon
On 2009-04-17, Stefanos Harhalakis wrote: > Dear mentors, > > I am looking for a sponsor for my package "katimon". > > * Package name: katimon > Version : 1.0.2-2 > Upstream Author : me > * URL : http://www.v13.gr/proj/katimon/ > : also available from extragear/utils/katimon > * License : GPL > Section : kde Section: kde is for stuff that don't make sense outside the kde desktop. Currently, it is plasma widgets and the desktop itself (+ a lot of wrongly placed packages) Section: kde is not for anything that uses kde libraries. No need to add more to the wrong section. You probably want admin or utils. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: questions regarding libmimelib1 as seperate source package
On 2009-04-25, Paul Wise wrote: > On Sat, Apr 25, 2009 at 3:02 AM, Jonas Meurer wrote: > >> I intend to maintain libmimelib1 as a seperate source package now that >> kdepim 3.5.9 has been removed from debian/unstable. > > What does lurker link against on other distros that have moved to KDE4? Ubuntu removed lurker from their releases. Fedora don't ship it. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: valkyrie
On 2009-05-08, LI Daobing wrote: > there is a proposed copyright format in [2], you also can use that format. > > [2] http://dep.debian.net/deps/dep5/ Note that this is just a proposal and many people don't like it, so please don't take it too serious. And some people won't sponsor packages with that format. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: krecipes (updated package)
On 2009-05-19, Matthias Julius wrote: > I would really appreciate if someone could either help me to get my > krecipes package into Debian. > > I am just not quite sure whether it is OK to hijack a package like > that from an unresponsive packaging team. Should I ask QA to orphan > the package? KDE-Extra team has already said go ahead to at least one person being interested in taking over krecipes. (José Manuel Santamaría Lema) Most kde communication happens in irc channels. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: krecipes (updated package)
On 2009-05-19, Matthias Julius wrote: > I just noticed that he actually cross-posted his messages to > pkg-kde-talk. There seems to be a little more human presence. Next > time I'll post there. That's *NOT* a sponsering list, but sending sponsoring requests there is the straight road into getting fully ignored. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: krecipes (updated package)
On 2009-05-19, Matthias Julius wrote: > Barry deFreese writes: > >> Dmitrijs Ledkovs wrote: >>> I'm not a DD, but I think the correct way is to ping MIA team about it >>> and then after 2 weeks time you ping them again and they do a little >>> chat and come up with a solutions usally in your favor. Try that, >>> cause they record stuff in wnpp and then you can go on and adopt >>> stuff. >>> >>> i think the email was m...@debian.org but double check that >>> (Developer's Reference / New maintainer's guide one of them had a >>> chapter dealing with unresponsive developers.) >>> >>> >> The problem there is that you can't MIA a whole team. > > Especially since there are a number of active members. Unfortunately, > nobody seems to read the team's list or care to reply to mails sent > there. I don't know how close you follow debian development, but many members of the debian kde people have been quite busy over the last month trying to get kde in testing updated. We do all have a finite time, and krecipe has not been blocking anything for the work. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Updated packge on m.d.n (was: RFS: kde-plasmoid-yawp)
On 2009-05-22, John Stamp wrote: > On Friday 22 May 2009 11:12:36 am Kai Wasserbäch wrote: >> Dear mentors, >> an updated package of kde-plasmoid-yawp has been uploaded to >> mentors.debian.net, the new dgetable URL is: >> http://mentors.debian.net/debian/pool/main/k/kde-plasmoid-yawp/kde-pl >>asmoid-yawp_0.2.3-2.dsc Plasma-widgets are not packaged in kde-plasmoid packages, but in plasma-widget-something, in this case probably plasma-widget-yawp How does this weather plasma widget differ from the two other we have in debian? (the one in plasma-widget-weather and the one from plasma-widgets-addons) > I'm not a DD, but I have a few comments about the packaging... > > dpkg-shlibdeps_fix_spurious_dependencies.patch: > > Why not add pkg-kde-tools to your Build-Depends? You can set > DEB_KDE_LINK_WITH_AS_NEEDED, plus you'll be using the same cmake setup > that all of the other KDE packages use. If you can fix the issues by fixing the build system instead of using --as-needed, it is much preferred to fix the build system (and send it upstream). But depending on which libraries that is spurious, it might be better to ignore it. for example, libgcc_s is unavoidable. > top_CMakeLists.txt_remove_FindPlasma_if-else-statement.patch: > > This patch seems to fix a problem that does not exist. You probably > don't even need to restrict to kdelibs5-dev (>= 4:4.2.0). Or am I > missing something? Plasma has changed quite a bit before and after 4.2.X, so I_think this simplifies it a lot. > > README.Debian: > > I'd remove it. It just duplicates info found in the description. Ack. /Sune - kde maint. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
