Re: Question about blocked package to testing
Dear Elias, Le 03/04/2020 à 02:50, Elías Alejandro a écrit : > Hello all > I have a question about a package which have a delayed transition > to testing. Gpick package has fixed under unstable a bug related with > python3 migration but it's blocked because of regression.[1] > -Do you know how to fix this regression block? How can I test > under a local environment? You can (and probably should) build your package using sbuild and configure it to run autopkgtest after build. when sbuild is set-up, you can also run autopkgtest manually in its schroot. Your test tries to open a display. This is not possible on the build and test infrastructure (the machines are headless). You have two options: - skip this test ; - run this test within a virtual X server. I do this in Yorick. See: https://salsa.debian.org/science-team/yorick/-/blob/master/debian/tests/control The test depends on package xvfb and the test command is wrapped in a call to xvfb-run. > -Should I do a new upload version to fix it? or just fix it under salsa? You need to upload it. > -Under build system it's fine [2] but with salsa-ci pipeline[3] it fails. > Do you know why? Is the test run during build ? > > [1] https://qa.debian.org/excuses.php?package=gpick > [2] https://buildd.debian.org/status/package.php?p=gpick > [3] https://salsa.debian.org/elias-guest/gpick/pipelines/120059 Regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)
Le 19/01/2017 à 12:20, James Cowgill a écrit : > On a separate note: does this interfere with the alternatives system > which openmpi currently has? If an rpath is used, it will override any > libraries in the default linker search path so even if the mpi > alternative is changed, many applications will still use libmpi from > /usr/lib/x86_64-linux-gnu/openmpi/lib. This is as it should be. The two alternative implementations (openmpi and mpich) are not binary-compatible. Regards, Thibaut.
Re: as upstream - Makes sense to run 'make clean' when running 'make all'?
Le 04/01/2017 à 19:20, Patrick Schleizer a écrit : > Hi, > > as upstream, does it make sense to run 'make clean' when running 'make all'? > > Would that be considered good or bad? Any convention on that? > > Best regards, > Patrick > Dear Patrick, This is not `good'. It makes some sort of sense if the dependency tracking is so broken that you need to run `make clean' anyway whenever you touch a source file, but even in that case, as upstream, I would not do it. What comes closest to a specification is: https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets which does not even answer your question. In any case, upstream has the last say and can do as they see fit. As a Debian maintainer, one can use a build stamp in her debian/rules file if that helps for her workflow, to keep track of whether the code has been built already, something like: build: build-stamp build-stamp: $(MAKE) touch build-stamp clean: rm -f build-stamp $(MAKE) clean Doing this in a dh-friendly manner is left as an exercise to the reader. Regards, Thibaut.
Re: Why is tk8.4 removal triggering autoremoval messages of not depending packages at this point in time (Was: staden is marked for autoremoval from testing)
Dear Andreas, Le 31/12/2016 à 08:23, Andreas Tille a écrit : > Hi, > > On Sat, Dec 31, 2016 at 04:40:32AM +, Debian testing autoremoval watch > wrote: >> staden 2.0.0+b11-2 is marked for autoremoval from testing on 2017-01-29 >> >> It (build-)depends on packages with these RC bugs: >> 734837: tk8.4: Time to remove from testing > > Staden Build-Depends: tk-dev (without any version) and the binary > package Depends: libtk8.6 (>= 8.6.0) so I do not understand this > autoremoval message in principle and I specifically wonder why this > happens at this point in time. I cannot tell you why this message appears, in particular for staden (no matter how hard I grep staden's dependencies, I cannot find tk8.4 in it). However I can tell you why it's happening now. This is due to the recent bogus run of testing migrations. 734837 is a sort of "pseudo" RC bug that was there to prevent tk8.4 from migrating again to testing. Yet a bug in the transition script let it go through. Now the auroremoval stuff rightly wants to remove it again, and for some reason misinterprets its reverse dependencies. I would believe removing tk8.4 by hand from testing could fix the lot of associated autoremovals. Dear release team, thoughts on that? Kind regards, Thibaut. > Staden is juat an example for a set of packages with the same problem. > > Kind regards > > Andreas. >
Re: Bug#843604: RFS: xerces-c/3.1.4+debian-1 [RC]
Le 08/11/2016 à 10:56, Thibaut Paumard a écrit : > > If the transition freeze is effective, uploading this to unstable will > severely hinder work on any package that build-depends on xerces-c. > Or maybe not. No SONAME bump, no problem. Sorry for the noise.
Re: Bug#843604: RFS: xerces-c/3.1.4+debian-1 [RC]
Le 08/11/2016 à 04:40, Bill Blough a écrit : > Package: sponsorship-requests > It builds those binary packages: > > libxerces-c-dev - validating XML parser library for C++ (development files) > libxerces-c-doc - validating XML parser library for C++ (documentation) > libxerces-c-samples - validating XML parser library for C++ (compiled > samples) > libxerces-c3.1 - validating XML parser library for C++ > > To access further information about this package, please visit the > following URL: > > Changes since the last upload: > > * New upstream release Aren't we supposed to be in a transition-freeze now? If the transition freeze is effective, uploading this to unstable will severely hinder work on any package that build-depends on xerces-c.
Upload new version of a package waiting in NEW
Hi, I'm sure I have seen the answer to this newbie question years ago, but google doesn't seem to be my friend anymore: I have a package waiting in NEW and I have a new version ready for upload because either: 1- I have found an issue in the version in NEW that I want to fix or 2- There is a new upstream version that I want to package (or both). What is the most efficient procedure? a) wait until the package was accepted or rejected; b) ask FTPmasters to reject the package and reupload with same version; c) upload immediately. In this case, should I: i) use a new version? ii) make a source-full upload (-sa)? iii) use -v option to put info about all skipped versions in .changes? Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/556ec3c7.9050...@debian.org
Re: Useless call to ldconfig and shared libraries issue
Le 05/02/2015 14:50, Corentin Desfarges a écrit : Le 05/02/2015 11:40, Andreas Tille a écrit : Hi, On Thu, Feb 05, 2015 at 10:50:15AM +0100, Leopold Palomo-Avellaneda wrote: By the way, we have to add wget as build-deps of the package in d/control. No, it's the lack of wget as build dependency. I'm trying to build again the package. I have made some modifications, but I would like to test it before say anything. Unfortunately you are not allowed to download anything at package build time. Each Debian package should build in a non-network environment. So either the build time tests need to be skipped or the data (perhaps xz compressed?) need to be provided either in package source or in a separate data package that can be added as Build-Depends. Kind regards Andreas. So tosummarize, I can disable tests with something like : override_auto_test: echo unit tests disable, see README in d/rules, and by adding in debian/* a script to download data and run unit tests ? In essence, yes. I tend to install such scripts, when needed, in /usr/share/doc/package/ or a sub-directory thereof, such as examples/. I *think* such a test is also suitable for the autopkgtest framework: https://packages.debian.org/sid/autopkgtest Using this framework would ensure your test is ran automatically on occasions, just not during the build. Kind regards, Thibaut. -- signature.asc Description: OpenPGP digital signature
Re: Useless call to ldconfig and shared libraries issue
Le 05/02/2015 10:24, Corentin Desfarges a écrit : Are you sure that in build time do you need to download some data? is this acceptable? Leopold Yes I need to download the data, else the unit tests can't pass... And I can't include the data into the package, because of its the size (more than 800MB). Hi Corentin, There is a general consensus that network access should be prohibited during build, so you cannot pull data from a debian/rules target that runs automatically on the autobuilders: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770016 Some consider that it's OK to do so *conditionally*, but I, for one, would not sponsor a package that does it. Not that I'm likely to sponsor your package anyway, not being competent in your field. It has already been discussed in this thread : https://lists.debian.org/debian-mentors/2014/12/msg9.html Nowhere did anyone suggest this as a possible option. The options are: - pack the data with the source package, in a separate tar.gz file; - prepare a script or instructions, that people can run interactively when they decide, to download the data and test the package. This script must not run at build-time. Kind regards, Thibaut. It is strange that the unit tests don't pass with this error (about shared library). When I build the package in a chroot environment, they pass. Have you tried to change something about rpath ? By the way, we have to add wget as build-deps of the package in d/control. Thank you, Corentin -- * Dr Thibaut Paumard | LESIA/CNRS - Table équatoriale (bât. 5) * * Tel: +33 1 45 07 78 60 | Observatoire de Paris - Section de Meudon * * Fax: +33 1 45 07 79 17 | 5, Place Jules Janssen* * thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France) * smime.p7s Description: Signature cryptographique S/MIME
Re: Useless call to ldconfig and shared libraries issue
Le 02/02/2015 14:17, Corentin Desfarges a écrit : But it doesn't work. What does doesn't work mean? I mean that I get the same error : ./debian/fw4spl/usr/bin/fwLauncher: error while loading shared libraries: libfwCore.so.0: cannot open shared object file: No such file or directory Dear Corentin, When does this error appear? Is that when running the test suite? Do you also have the same error once the package is installed? Kind regards, Thibaut. -- signature.asc Description: OpenPGP digital signature
Re: Using the same Alioth git repo for multiple source packages.
Hi, Le 19/11/2014 19:23, Maxime Chatelle a écrit : [...] The package is cakephp. Upstream maintains 3 main branches: 1.3.x, 2.x and 3.x I plan to use the following naming scheme for branches: upstream/1.3.x(fast-forward only branch feeded by upstream releases) debian/1.3.x/master (devel branch, merged into debian/1.3.x/suite branches, can be seen as experimental) debian/1.3.x/suite (wheezy, jessie, stretch, ...) And the same for other series: upstream/2.x debian/2.x/master debian/2.x/suite upstream/3.x debian/3.x/master debian/3.x/suite For tag names, as usual I will use: upstream/1.3.20 debian/1.3.20-1 That sounds entirely reasonable to me, especially if it is useful in your workflow (e.g. make a change in debian/1.3.x/master, then merge it into debian/2.x/master and debian/3.x/master...) [...] Beside of that, what is your opinion about maintaining quilt patches into distinct branches (properly named) and generate the quilt patch series into a temporary build dir/branch ? That's entirely up to you. Some helper tools require this scheme, others don't, and when working manually, you do as you see fit. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Using the same Alioth git repo for multiple source packages.
Le 19/11/2014 11:21, Raphael Hertzog a écrit : Hi, On Tue, 18 Nov 2014, Maxime Chatelle wrote: Is it a good practice to use the same Alioth packaging repository to maintain two (and later, three) source packages ? Obviously the three source package come from the same upstream git repository. The point is to maintain 2 (or 3) development branchs of the same software while avoiding repository duplication. No, few of the helper tools make it really easy to maintain multiple source packages in the same repository. It's certainly possible but it's not what I would call good practices in Debian. Hi, Focusing on the helper tools may not necessarily be the only approach. I personally only use git, quilt and pbuilder, which would all behave fine in this context. Maxime is talking of several branches of the *same* code, that he packages, apparently, in different source packages. That makes it likely that he will want to apply the same changes to all of his branches. Only marginal things like the content of debian/patches and the actual name of the packages will differ. That's also what I would do, say, to maintain one upstream version in unstable and another one in experimental. In my opinion, in this context, the best course of action is indeed to maintain the various branches in the same repo, carefully choosing explicit branch names, and avoiding any tools that may have unpredictable behaviour. Maxime, perhaps you can be more explicit about your use case? Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#762995: RFS: radiotray/0.7.3-2 [RC]
Control: tag -1 pending Control: owner -1 ! I'm on it. signature.asc Description: OpenPGP digital signature
Re: Bug#742330: RFS: gravit/0.5.1-1 ITP -- visually stunning gravity simulator
Le 30/09/2014 14:58, Tomasz Buchert a écrit : It has now a huge d/copyright file. :) That's how it's done :-) Uploaded. signature.asc Description: OpenPGP digital signature
Re: Problem Occurred while creating deb package of libreoffice
Le 29/09/2014 12:16, Ritu Panwar a écrit : Hello Joachim, Thanks for quick reply :) we have our own translations here as i need libreoffice in hindi language .our translator had translated the strings into hindi language then i compiled libreoffice with hindi langpack and --with-package-format=deb on ubuntu after compilation i got the deb packages of libreoffice with hindi langpack. its getting install successfully if i run the dpkg -i *.deb command on terminal. but now i want to create a local repository for the compiled libreoffice with hindi langpack for that i am not able to create deb package it is the actual problem even i don't know is it possible or not can u help me out. Hi, I suppose what you want is to be able to distribute your language pack? You have several possibilities: - Read https://wiki.debian.org/HowToSetupADebianRepository (I personally used reprepro) - Contribute your package directly to Debian - For the ubuntu packages, use launchpad. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#742330: RFS: gravit/0.5.1-1 ITP -- visually stunning gravity simulator
Le 25/09/2014 09:15, Tomasz Buchert a écrit : Hi Thibaut, I corrected these problems: http://mentors.debian.net/package/gravit (changes: http://anonscm.debian.org/cgit/debian-astro/packages/gravit.git/) I also added cc-by-sa-3.0.txt to gravit-data since in theory every license text should be distributed with Debian, but I couldn't find it in /usr/share/common-licenses. Tomasz Hi Tomasz, Not really important, but the purpose of sponsoring is to teach you the True Way of Debian: you should dump the WTF and the CC-BY-SA licenses directly in copyright instead of putting them somewhere else. The sentence On Debian systems, such license can be found... is only for the licenses in common-licenses. Policy says: Every package must be accompanied by a verbatim copy of its copyright information and distribution license in the file /usr/share/doc/package/copyright (see Copyright information, Section 12.5 for further details). The common licenses are an exception, where we put only a pointer to another file. So technically it's an RC bug to put the license in any other place, although I doubt that you would get a REJECT for that (the FTP master would file a bug, though, or otherwise remind you to fix this). Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#742330: RFS: gravit/0.5.1-1 ITP -- visually stunning gravity simulator
Hi Tomasz, +dfsg should be appended to the upstream part of the version number, not to the debian revision. Concerning debian/copyright, no big deal, but I don't want to let the FTP master waste their time on it: The image in data/skybox/purplenebula/* has been relicensed from WTFPL to GPL-2 to make debian/copyright simpler. Relicensed by whom? If it's by you, don't do that, simply add another paragraph. Likewise, add another paragraph for the files which are GPL2+ instead of GPL2. In other terms, don't try to be clever, just dump the information here. I'm building the package now, will let you know if there are other problems. Regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#742330: RFS: gravit/0.5.1-1 ITP -- visually stunning gravity simulator
Le 24/09/2014 17:05, Thibaut Paumard a écrit : I'm building the package now, will let you know if there are other problems While you're at it, there's a new version of Policy, you should update Standards-Version: https://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt Package looks good otherwise, I'll upload as soon as you have fixed the remaining issues: +dfsg in upstream version, nit-picking about copyright, Standards-Version should be 3.9.6 (I think lintian doesn't even know about it yet) Regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#742330: RFS: gravit/0.5.1-1 ITP -- visually stunning gravity simulator
Le 22/09/2014 20:29, Tomasz Buchert a écrit : Hi Thibaut, I' taking liberty to ping you about this RFS. Cheers, Tomasz Thanks, I'll see if I can have a look later this week. signature.asc Description: OpenPGP digital signature
Re: How to resolve circular build dependency?
Le 14/09/2014 06:32, hero...@gentoo.org a écrit :
The concern of casacore{,-data} being out of sync might be resolved with
two tarballs supported by quilt 3.0 format[2]. I am not sure how to
implement it in a clean way by git-buildpackage. Any examples
available?
Dear Benda,
If you do that, each time one of the two packages is updated, the other
will also need to be needlessly re-built (on every single arch, for
casacore), re-uploaded to the archive (and its many mirrors), and
re-upgraded by every user. That's a lot of wasted CPU, bandwidth, and
hard-drive space.
Better to just use the bootstrapping scenario and leave the circular
build-dependency.
Kind regards, Thibaut.
signature.asc
Description: OpenPGP digital signature
Bug#749096: Updated version
Le 03/09/2014 11:05, Martin Steghöfer a écrit : El 29/08/14 a les 23:33, Ghislain Vaillant ha escrit: Well, you are supposed to target what's in there in unstable if you want your package to be accepted in the archive. Afterwards, Ubuntu will automatically pick it up for its current development version (14.10 or 15.04) depending on how fast the upload to Debian goes. Regarding support for 14.04, this could be done by requesting a backport from the Ubuntu package of a newer release (14.10 or 15.04) and then adding your 14.04 specific patching to the backported package. OK, understood. So the bottom-line of your answer, if I understand you correctly (taken the fact that the little change in the patch is already too much): Helping downstream distributions happens via other channels, the Debian package is not supposed/allowed to include anything that is unnecessary for Debian unstable. Thanks! Martin Dear Martin, I think you are over-interpreting what Ghislain wrote. What he said is rather that your package will likely build unmodified on the next release of Ubuntu, if not on the current one, because Ubuntu will also upgrade there version of libav. You don't *have* to go out of your way to ease the downstream work. Likewise, you don't *have* to make any efforts to make it easier to backport your package to older versions of Debian. However, when it is practical, it is good practice to make the adjustments that will make your package compile unmodified on Debian stable and up-to-date derivative distributions. On the other hand you don't want to obfuscate your package just for the sake of backports. If the patch becomes unreadable, your sponsor will give up on checking it. In the end, it's up to you (and your sponsor) to decide the level of complexity you want to allow in your package. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: ghdl package has been removed from Mentors
Le 19/07/2014 17:00, Guido van Steen a écrit : I agree with Joris. Users are not properly informed that discussions on mentors.debian.net may be automatically lost after a package is removed from mentors.debian.net. This should be changed. I would rather see the information backed-up in some way before it is deleted. Does this require a bug report again debexpo, or is this mailing list the place for a discussion? Hi, IMHO, the right place for discussing a particular package is it's ITP bug (when the package is prospective) or the RFS bug. Kind regards, Thibaut. -- * Dr Thibaut Paumard | LESIA/CNRS - Table équatoriale (bât. 5) * * Tel: +33 1 45 07 78 60 | Observatoire de Paris - Section de Meudon * * Fax: +33 1 45 07 79 17 | 5, Place Jules Janssen* * thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France) * smime.p7s Description: Signature cryptographique S/MIME
Re: ghdl package has been removed from Mentors
Le 21/07/2014 10:37, Guido van Steen a écrit : } IMHO, the right place for discussing a particular package is it's ITP } bug (when the package is prospective) or the RFS bug. AFAIAA there is no ITP or RFS for the package debexpo (the software at issue, which is running at mentors.debian.net). Guido Hi, this is not what I mean: I don't like the comments feature of debexpo, my opinion is that comments on a to-be-sponsored package should be sent to the corresponding RFS bug. Debexpo has its own bug tracker: https://alioth.debian.org/tracker/?atid=413115group_id=100127func=browse I guess it is supposed to be used for feature requests concerning debexpo. Kind regards, Thibaut. -- * Dr Thibaut Paumard | LESIA/CNRS - Table équatoriale (bât. 5) * * Tel: +33 1 45 07 78 60 | Observatoire de Paris - Section de Meudon * * Fax: +33 1 45 07 79 17 | 5, Place Jules Janssen* * thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France) * smime.p7s Description: Signature cryptographique S/MIME
Bug#753021: RFS: cpl-plugin-muse/0.18.1+dfsg-1 [ITP] -- ESO data reduction pipeline for MUSE
Le 28/06/2014 18:22, Ole Streicher a écrit : Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: debian-as...@lists.debian.org, debian-scie...@lists.debian.org, debian-mentors@lists.debian.org Dear Mentors, I am looking for a sponsor for my package cpl-plugin-muse. Hi Ole, I'm a bit busy right now. Can you ping me around mid July, I should have more time then! Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#753021: Aw: Bug#753021: RFS: cpl-plugin-muse/0.18.1+dfsg-1 [ITP] -- ESO data reduction pipeline for MUSE
Le 01/07/2014 10:10, Steffen Möller a écrit : Heyho, I uploaded it, yesterday. At least so I thought. Cannot find it in the new queue. Will do better tonight. Thanks Steffen :-) signature.asc Description: OpenPGP digital signature
Bug#742330: RFS: gravit/0.5.1-1 ITP -- visually stunning gravity simulator
Hi Tomasz, I guess you missed my review! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742330#24 Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b17a2a.3080...@free.fr
Bug#742330: RFS: gravit/0.5.1-1 ITP -- visually stunning gravity simulator
Control: owner -1 !
Control: tag -1 + pending
Dear Tomasz,
debian/copyright is incomplete. Use licensecheck, grep and less to
find out the copyright and license of each individual file. Here are a
few copyright notices which you did not list in debian/copyright:
Copyright: 2003-2014 Gravit Development Team / 2003-2014 Gerald Kaszuba
Copyright: 2008 Matt Gallagher. All rights reserved
Copyright: 1997, 1998, 1999, 2000, 2001, 2002 Sam Lantinga
Copyright: 2006 Angelo Encelo Theodorou
Copyright (C) 1994-2008 Lua.org, PUC-Rio. All rights reserved
Some files are not GPL. For some files it's not even clear that they are
DFSG, please check it and document your findings in debian/copyright. If
in doubt (and if those files are not used in building), repack.
debian/changelog is too verbose. It should only list initial upload.
(Closes: ITPbugnr).
The package is not lintian-clean. You need to write a manpage for the
'gravit' binary. I was not able to find out how to use it as a screen
saver, which is certainly not a good idea given the resources it takes!
gravit-data should certainly Recommend gravit, and I believe gravit
should Depend on gravit-data (=${source:Version}) rather than (=
${source:Version}).
Kind regards, Thibaut.
signature.asc
Description: OpenPGP digital signature
Re: Bug#744280: RFS: cpl-plugin-xshoo/2.4.0+dfsg-1 (name change)
Dear Ole, Le 14/04/2014 07:38, Ole Streicher a écrit : So, if you want to keep up-to-date, you should at some point remove package A and install package B instead. This is what I think is the use of replaces. Well Replaces alone does not provide this feature. If you want to be sure that people do upgrade (which may not be necessary, given the low pop-con), you need to provide a new version of package A (can be built from the source of package B, is the versioning scheme is correct). This new package A is a dummy package, in section oldlibs, whose unique purpose is to pull B. The dummy package A will stay on the system for a while. Tools like deborphan will be able to prune it. It's possible that aptitude will do it automagically at some point too. If there is a problem with installing new B concurrently with old A, then you need to put the Breaks/Replaces machinery into place. In this case it must be a versioned Breaks, since you actually want the dummy package A to be co-installable with B. With a non-versioned Breaks, A would depend on B, which would conflict with A, rendering A uninstallable, which is forbidden. Note that there is no way to ensure that upgrading A will automatically end-up with B being installed and A being uninstalled. This is certainly what you are looking for, it does not exist in Debian. Now it's your package. I just wanted to be sure that you understand how this all works, but it's your call whether or not to introduce the dummy package. The Breaks/Replaces machinery looks quite unnecessary to me except for the -doc package as you said. I'll upload whatever you decide to do. Some more details: in practice, what Replaces does is, in the two situations: File conflict: Warn dpkg that pkg B may overwrite files in A, which needs to be either removed or upgraded, which the (possibly versioned) Breaks or Conflicts ensures. Without the Replaces, dpkg would complain and stop, which is quite nasty. Install only one MTA: Tell apt that B should win the Conflict over A. This really is scarcely used, I'm almost certain that the MTA example is the reason why this machinery was invented. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Renaming a source package
Le 14/04/2014 09:19, Оlе Ѕtrеісhеr a écrit : Hi, Hi Ole, I'll summarize my answers from the bug and perhaps provide some more: Question is now how to proceed: * how do I declare that the *source* package cpl-plugin-xshoo is just renamed from cpl-plugin-csh? You don't. You could keep the old name for the source package (which the users never see), or use the new name. If you use the new name, and if you build dummy packages with the old names from the new source package, then the old source package will be cruft removed automatically at some point. Else, you need to request the removal of the old source and old binaries. * ho do I create a good transition? I thought of two ways: 1. Just create a new source package cpl-plugin-xshoo that creates the new cpl-plugin-xshoo* packages; set Provides and Replaces fields for all three binary packages, and a Breaks field for the -doc (because of the manpages). When they entered testing, manually remove all old cpl-plugin-xsh* source and binary packages IF you use Conflicts/Provides/Replaces in the new packages, then the old packages will be removed from the end-user system *when they request installation of the new package*, but upgrading their system will not do it automatically. IF you provide dummy packages with the old names, then the new packages will be pulled automatically, leaving marginal cruft behind (i.e. empty packages installed). The dummy packages can be purged by tools like deborphan. You can't have both. 2. From the new source, create a soource package that is still named cpl-plugin-xsh that contains the new binary packages, and the old ones as transitional dependencies (cpl-plugin-xsh has a Depends: cpl-plugin-xshoo etc.) Once this entered testing, create a new source package cpl-plugin-xshoo that contains the cpl-plugin-xshoo packages. However, how do I declare then that the new source package just overtakes the old source package? Their is nothing in there which requires multiple uploads. Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/534b9b45@free.fr
Re: Renaming a source package
Le 14/04/2014 11:37, gregor herrmann a écrit : On Mon, 14 Apr 2014 10:24:37 +0200, Thibaut Paumard wrote: I'll summarize my answers from the bug and perhaps provide some more: There's also https://wiki.debian.org/Renaming_a_Package And I'd go so far as to say that Method 1 (only useful in very easy cases) advertised in this page is actually useless in most cases. I can't see a case where it does anything useful. Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/534bd556.7000...@free.fr
Bug#744280: RFS: cpl-plugin-xshoo/2.4.0+dfsg-1 (name change)
Le 12/04/2014 13:55, Ole Streicher a écrit : Package: sponsorship-requests Severity: normal X-Debbugs-Cc: debian-as...@lists.debian.org, debian-mentors@lists.debian.org Dear mentors, I am looking for a sponsor for my package cpl-plugin-xshoo Hi Ole, Why does the package Conflict and Replace cpl-plugin-xsh? None of the files are the same (so at least the Replace is wrong). Conflicts is a very strong type of dependency, that should be avoided if at all possible, for instance using Breaks instead. So the questions are: - are there any files in common in the two packages? - what happens when the two packages are installed together? + are the two packages still usable somehow? + is one package simply shadowed by the other? + is cpl completely broken in that case? Depending on the answers to those questions, I would think you could: - remove the Replaces line; - replace Conflicts with Breaks or remove it altogether; - keep Provides if the new package really provides the same API; - optional: build cpl-plugin-xsh* as meta-packages that will pull their cpl-plugin-xshoo counterpart. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#744280: RFS: cpl-plugin-xshoo/2.4.0+dfsg-1 (name change)
Le 13/04/2014 15:33, Ole Streicher a écrit : Hi Thibaut, my mail program seemed to eat the citations. 2nd attempt: Am 13.04.2014 14:45, schrieb Thibaut Paumard: Why does the package Conflict and Replace cpl-plugin-xsh? None of the files are the same (so at least the Replace is wrong). I mainly followed the rule of renaming a package. Replaces is correct wrt policy: 7.6 Overwriting files and replacing packages - Replaces Packages can declare in their control file that they should overwrite files in certain other packages, or completely replace other packages. The Replaces control field has these two distinct purposes. Dear Ole, I think you misunderstood the uses of Replaces. Like the other types of dependencies, Replaces is a technical tool to warrant a certain behaviour of the package manager. The fact that you are trying to replace a package by another one in the archive does not mean that Replaces is useful or even right for your purpose. The two use cases are: - file f was is package A, now it is in package B. Either package A is removed from the archive, or there is a new version of package A without file f. (Normally, Breaks+Replaces). - packages A and B provide the same functionality, but should not be installed at the same time on the system. (Only real use case for Conflicts+Replaces).* You are in neither of those two situations. Now in Policy there is also this sentence (near the end of 7.4): Neither Breaks nor Conflicts should be used unless two packages cannot be installed at the same time or installing them both causes one of them to be broken or unusable. The Provides field is really useful only if there are other packages already depending on package A. I think you should just completely remove the three fields. Conflicts is wrong, Breaks seems wrong too since nothing is broken, and Replaces is useless without either Conflicts or Breaks. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#743691: RFS: wcslib-contrib/4.20 [ITP] -- Draw and label curvilinear coordinate grids with pgplot
Control: owner -1 ! Control: tag -1 + pending I'll take care of this one -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/534ab6df.8010...@free.fr
Re: library linking, missing libB.so
Le 20/03/2014 13:22, Nico Schlömer a écrit : Hi all, I'm building a package for a library A that depends on another library, libB.so (from its dev-version). When installing library A, the package libb is installed, containing libB.so.7.2 and libB.so.7. When linking an executable against libA.so, the linker rightfully complains about a missing libB.so. What is the correct fix here? Install libA-dev, which must depend on libB-dev. Regards, Thibaut. Cheers, Nico -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/532ae4f5.1000...@free.fr
Re: library linking, missing libB.so
Le 20/03/2014 14:06, Nico Schlömer a écrit :
which must depend on libB-dev.
libB-dev is indeed not explicitly listed as a dependency of libA-dev,
mostly because I was under the impression that ${shlibs:Depends} takes
care of this, cf. https://wiki.debian.org/IntroDebianPackaging. Is
that not the case?
${shlibs:Depends} takes care of the runtime dependency, libB.so.x.y. It
cannot determine that libA-dev requires libB-dev, which contains the
libB.so link.
Kind regards, Thibaut.
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/532af32c.8000...@free.fr
Re: Question about a licensing problem
Le 17/03/2014 13:34, Albert van der Horst a écrit : one version, 2.21 is GPL, but already for reasonable sized brain image data the code crashes, and the way the code is written there is no easy way to fix this, and hence, Oscar went with version 3.0, which works. However, version 3.0 comes with a license attached that only allows use for research purposes and doesn't allow the redistribution of the source code. This seems to like a clear violation of the GPL. Just ask them to comply with the GPL. Not at all. They are upstream, they can change their own licensing terms for new releases of their code. They are simply not yielding their new work under the same terms as they did with their preceding work. The GPL is *not* viral, using it for version 2.21 of your code does not force you to use it for version 3.0. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Splitting in /usr/lib/arch and /usr/share
Le 08/03/2014 14:02, Оlе Ѕtrеісhеr a écrit : Hi, I am packaging some older software (eso-midas, [1]) that installs everything into a common directory (f.e. /usr/lib/eso-midas/). However, the FHS requires that this should be split between /usr/share/ and /usr/lib/arch/. In the majority of cases, this could be done automatically by recognizing the type with the file command: object files, libs etc. go to /usr/lib/arch/eso-midas/, all text and data files to /usr/share/eso-midas (with a link to /usr/lib/arch/eso-midas). Is there already a little helper script that does this for me? Hi Ole, Nice you are packaging MIDAS. I don't know any such script, and I doubt it would do the right job anyway. Are the indep files generated? What I would try is to compile the package on two distinct architectures (or more) and compare the result. That would work unless the build for these files is non-deterministic or includes timestamps or information on the build machine. amd64 and i386 may be sufficient and, if you have an amd64 box, it's easy enough to install a i386 chroot. Failing that, as a DM, you can request access to porter boxes (you are not a DD yet, are you?). I could also do the compilation for you since, as a DD, I have permanent access to those machines: https://db.debian.org/machines.cgi I guess you do realize that this split also implies putting the indep files in a separate arch:all package. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Splitting in /usr/lib/arch and /usr/share
Hi, Le 10/03/2014 10:45, Andrey Rahmatullin a écrit : On Mon, Mar 10, 2014 at 10:19:29AM +0100, Thibaut Paumard wrote: What I would try is to compile the package on two distinct architectures (or more) and compare the result. That would work unless the build for these files is non-deterministic or includes timestamps or information on the build machine. ... or files can be same on some different architectures and different on others (e.g. because of endianness). Thanks for clarifying that. Indeed you need to check the files at least on a 32bit arch, a 64bit arch, a little-endian arch and a big-endian arch. Actually one way to go would be to upload the package without making the split, downloading all the binaries, and comparing the files. This is easier than manually building on porterboxes and covers all the architectures on which the package compiles. I guess you do realize that this split also implies putting the indep files in a separate arch:all package. It doesn't. You are right, if the files under /usr/share/ are indeed byte-for-byte identical. However, splitting is a good idea if the indep part is large, and works also if the indep files are not byte-for-byte identical but the differences are irrelevant (such as information on the build machine encoded in a comment header, for instance). Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Splitting in /usr/lib/arch and /usr/share
Hi, Le 10/03/2014 10:50, Оlе Ѕtrеісhеr a écrit : [packaging ESO MIDAS] Let's see how far I come. BTW, Since I do not use it myself: Is it worth to split it into core, applic, stdred, and contrib packages? Is there any use for keeping the source? It's already great to package it, don't overdo it. You won't have that many installs anyway, and most users will want the full package. I don't see a need for keeping the source either. I would split like this, depending on whether it makes sense: - midas (binary arch) - midas-common (binary indep, if it is big) - midas-doc (if it is big, else with -common) If MIDAS supports plug-ins (that, I don't know), then you could put the files that are needed only for compiling extensions in midas-dev. I was looking for an automated way. I would just do the following: * put all files that are obviously system dependent to /usr/lib * put all files that are obviously system independent to /usr/share * Check all other files and put them to the right place That works, too. However, this is (as well as your proposal) manual work, and has to be repeated with each release. Therefore I was hoping to have the majority of files automatically put to the right place and deal only with the ones where the automatic way fails. I doubt the list of files for this mature piece of software will change much between releases. Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531d8f34.7080...@free.fr
Re: Maintainer scripts: execute command as another user: use sudo or su?
Le 26/02/2014 16:07, Emilien Klein a écrit : Hi Mentors, TLDR: in order to execute a command as another user, should `sudo` or `su --command` be used? I'd like to get your opinion on how to best solve this issue: I've got a package [0] that uses dbconfig-common to manage its database. The database is owned by a specific user (not root). Hi Emilien, I think you should use su. I am almost certain that sudo can be configured in such a way that would break your assumptions, whereas su can simply not be configured. Besides, as you noted yourself, using sudo would imply a completely unnecessary new dependency. su is the right using tool for assuming another personality and dropping privileges from root. Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530e0ba1.9050...@free.fr
Re: Wish to package astronomy software
Le 05/01/2014 12:42, Bamm a écrit : Hello, I'm Bamm from the Philippines. I'm new to this list and I hope to gain advice how to package for Debian. My interest is in astronomy software. Dear Bamm, I should be able to review your package once you think its ready, and sponsor it when I think its ready. Be patient, it will take some time for you to learn how Debian packaging works and for people (like me) to review it. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Upgrading the Debian Policy
Le 24/09/2013 15:58, Paul Wise a écrit : On Tue, Sep 24, 2013 at 2:48 PM, Dominik George wrote: Sorry to disapoint you, but you should read *all of* DPM before passing a package for upload to a sponsor or to mentors. I don't think we have never expected that new maintainers read policy before creating a package. Hi, I disagree with that: I expect prospective package maintainers to read and follow the Debian New Maintainers' Guide, which states: The following is the very important documentation which you should read along with this document: - debian-policy [...] - developers-reference - [...] http://www.debian.org/doc/manuals/maint-guide/start.en.html#needdocs I would say that this is what Debian as a whole requires. I mean that I expect the package maintainer to have read enough of the policy to know which parts apply to his packages, and to have read these parts in full. Regards, Thibaut. -- 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/52419e97.2090...@free.fr
Re: Path for search data files in package
Le 30/07/2013 13:28, Anton Balashov a écrit : Hello. We are creating a game and we can't find answer on question: How to set in code path where to search data files (for example sounds, images, etc). Of course we can hardcode '/usr/share/game/...' but what if game was installed with prefix? What is the best practice? Thanks for help. Hi, there is no generic answer to that question. If your build system supports --prefix, it's not too hard to include the prefix in the hard coded path. For a Debian package, that's all you need: a compile-time option. If you want your build to be relocatable (i.e. install path is not known at compile time) you can also make the path relative to the executable binary path. Finally, your program can accept a command line option or an environment variable so the user can set the path. Or even an option in a file the user directory or in /etc. If you implement several of those possibilities, you should make the priority in that order: command-line, environment, user file, /etc file, hard coded value. Kind regards, Thibaut. -- 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/51f7a62b.30...@free.fr
Re: How to handle a package triggering ice or segv during build?
Le 14/06/2013 08:50, Thomas Moulard a écrit : Dear all, the ViSP[1] software I maintain is causing GCC[2,3] and Doxygen[4] to crash on some platforms. It is difficult for me to fix or to report these issues as: 1. I am neither a DD or a DM, 2. I do not have access to these architectures by myself. Dear Thomas, Even if you are not yet a DD or DM, you are the maintainer of the package and you may (and should) request access to whatever you need to do your work. The limitations are only technical, just think of it as if you were learning how to drive with someone sitting next to you as in the French conduite accompagnée system. In particular, you can ask for SSH access to porteboxes. See: http://dsa.debian.org/doc/guest-account/ You will need a DD to support your request. Best would be to ask your usual (or last) sponsor. I was wondering if opening a bug (on the Debian BTS) for GCC and Doxygen is acceptable in this case? If you think the bug is in GCC and Doxygen rather than in your own package, definitely. If the bug is in visp, file a bug against visp instead, to keep track of the issue, request help etc. Another question is: do DM have SSH access to Debian machines to validate packages on various architectures? No, not readily. They need ta ask DSA specifically, just like you. Only they don't need a DD to support the request. Kind regards, Thibaut. -- 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/51bac94c.9030...@free.fr
Bug#710103: The mentor package URL changed as well
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Le 31/05/2013 16:22, Eriberto a écrit : You musn't initiate the description using the package name or an article[1]. This is an RFS bug: yes, the bug title must start with RFS: package name/version and since all trafic for RFS bugs is dispatched to the mentors mailing list, I argue that any answer to such bug should keep this information in its title. That being said, Łukasz, I don't know enough of evdev or python to help you with the package. Have you also tried sending your RFS to the python mailing list? Kind regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJRrYbKAAoJEJOUU0jg3ChA5fwQAJ/Asl3KltnPtXvG02GYSDyg Fs8pIFpKy1iqjQFjp9nzFzano1jWATUBAwBz8qE21QopBj4k3+3IRI872ZYVEJSf digFHLJWMqwrv16TXjuIILyFMAou+L0tiPUOAIVJW6HA07XR2R47UlXtwMhpzAmQ ghl3GE5voqDfKgmnMd3n3XO8d/vUZ7Zzds6xm+ZRo2ze/hTbBwc/WjdxymmprM/Q iHGxAup8/wLOiYXD+rrIGyerVdD4dp7iHDTpoliul3+Y+yX2XMcUinhSm5b98p0+ YImyoCTX7fvDMh2N3XQm9eMSeXfjLmJ2PEz3V1Qgg1SZY8Qu/NeprGV9QRINaG+T EvsByCYm1ZbdnVsElh7HWAD61eQSiPVFvBtToWj8wBWIe1AXROFxfQSRkCHkAEuu txtV9RmA2Cg4N3MjlU26h94KdpcXpT3bRLTYZZBqEg5q4GGn8DzmbrEXzCeuKS/q TvI9MoFDgeMynOkwOPkA9j6QF0PIf4EeXjGQ9O5Ljd8xz4c5Y1mO/AGuUg+51wWp Nv2TQU034+YVfJoT7CDSumYf5EpOd6L8W2sGcf2gmXQgiZYH0e0x2ws2EtIpGg7Q Wwn0L9CH4/Yv/XDAgPa6Z6xNDFQMm9/5BiOBR84Sv7Mxagw+0YdW0NlqBLYjPtqC AxG8Ws3I3ThZn/1WK3lu =2zii -END PGP SIGNATURE- -- 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/51ad86d6.2000...@debian.org
Bug#710248: RFS: fitsverify/4.16 [ITP] -- FITS File Format-Verification Tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Uploaded. Le 31/05/2013 12:19, Ole Streicher a écrit : Hi Thibaut, Am 29.05.2013 14:38, schrieb Thibaut Paumard: I don't think the FTP master will let the package in with just this short notice (so short that I missed it despite looking for it). Maybe they would be OK if you reproduced said e-mail in full. I have included the E-mail confirmation into the copyright file and re-uploaded it to mentor.debian.net. But the best would of course be to get upstream to just add a copyright notice at the beginning of each source file plus a copy of the applicable license and release a new tarball. It should be about 15 minutes of their time, well spent. I have asked upstream, but he refused to do this on a short term. Instead he recommended that I could inserting the License.txt myself (what I basically did by creating the debian/copyright file). So I would guess it is completely OK to insert the package into Debian. Best regards Ole -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJRrKbpAAoJEJOUU0jg3ChAPKUQAIYkdzimlsMTc9Zc2a26AJ9y HAQbr7MoeJ3MvdmAtFkCzVEMOgp/v0rauanCoNQePIFyf83NudQUEAm/uy3u3APM qOk3e2zuB8zUFzSXgsRkdz9kwL2sk41SXJnSMjMgKBxERv/6By2h/6ZY9+jdEIZN K9i7TwOXZLcqEfdPjWNrCh5jeBTrjhluHQu+W8Fb1XHLlKAcreCMp7vBDwCGb2Wi Lr2RCApck6nJKjylZrGAI7m0DD0mX3cAtOUQ+uqYR3nf2z2ULG8KZSVOr30Pi6bz zmRHHWnS171xBBN/bnPb2KEfZsU/zuBCUOksivdNAjmy5IVHUbyOfXZ5QRJahp4d W/w5+O0O3Vo2IpUzE320+yY/4rYqCCtAXzVnTpRU64GgAEGQTmJiplKngtYucXQa rfv2NzYLsOKddtoVWsR2C8I1wyCaO3ida8rTs9yndGFwJoCpIHZZlMmF/hb+zTVF KBP2GE57zaNnWVfy48hlDtqPL43Ckws2HLvxXfXBjbcX9329CsgiGs6Mq2kThAnt uOSpG3x8iPemPorrnCJKdNuJofMxcm2eSD3vVoflATwPB65ePtlUFKHn6VtqHKdQ 1RxBcGEwFVHwPtfzPPeWmWNGtSDXD/d71NodpV3NvtMnJTa9/Th2eTWR64otzGep bxiu9HGEizd5s89ItTzT =O6aT -END PGP SIGNATURE- -- 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/51aca6fb.9000...@debian.org
Bug#710248: RFS: fitsverify/4.16 [ITP] -- FITS File Format-Verification Tool
Le 29/05/2013 12:44, Ole Streicher a écrit : Package: sponsorship-requests Severity: normal X-Debbugs-Cc: debian-scie...@lists.debian.org Dear mentors, I am looking for a sponsor for my package fitsverify Hi Ole, package looks good. I couldn't find upstream's license and copyright statement though, where is it? Regards, Thibaut. -- 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/51a5ea0c.4080...@free.fr
Bug#710248: RFS: fitsverify/4.16 [ITP] -- FITS File Format-Verification Tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 29/05/2013 14:02, Ole Streicher a écrit : Hi Thibaut, Am 29.05.2013 13:44, schrieb Thibaut Paumard: Le 29/05/2013 12:44, Ole Streicher a écrit : I am looking for a sponsor for my package fitsverify package looks good. I couldn't find upstream's license and copyright statement though, where is it? Not there. I asked and got a confirmation from William Pence that the license is the same as for CFITSIO. I've put a note for that in debian/copyright. Best Ole Hi Ole, I don't think the FTP master will let the package in with just this short notice (so short that I missed it despite looking for it). Maybe they would be OK if you reproduced said e-mail in full. But the best would of course be to get upstream to just add a copyright notice at the beginning of each source file plus a copy of the applicable license and release a new tarball. It should be about 15 minutes of their time, well spent. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJRpfawAAoJEJOUU0jg3ChA/lQQAJNegk1RkQ47pb6Yoase3NES FWLoCshkfn8SnHiHF1SWLZcG001hi/y94Xo/QoR14rMSJzRjitpV52FmloLdrlUn j/QjBG5XAJpKhWm33rKmaojyQB52jzD0uuvSfbptg87ZampsmbOK+8oGhxbQp5/a noS3jN5WjV+llo6C2Wp1j6t47YZzC/Mxcxe1WZEfa+KTcAdsSKFkJdLh8Hs/eoxd 2C66t/koDj/gdB1EKTZq7pXIe+kV3VFQeYpPOZmcNdkkyzqWN0oaNRHcdEZEddRO N8IhF3PVKSvMVzOs6qBcsmxWqinDZ9csu7Q4wDSX7OuH3SB2JfpxxT6RUhsRj9k4 GpT6vMnoB0mdAraLyZg3yy8iUCze0W47LQjQAx92SYofl7HbqNzL/tGrNo2lRM2z hJQvCrEV5X57G8hRykzywgMLsunf9F6krgT/X+ufXDU7EPOTM5N3OoKQrEJc/TqO Vq+P8FDixgUcfs4qrAOp7q77UFkp9LFaY/19j8dcrij0+kycVXrsN4UMMkPIRAe0 KjsVLgpp214KFbJ8G3W1ovg0Ot5MhJEesBc0S2D/1xdOTNTorrfIxZo83N/sIt4O aVWJz4AeTEHAOl7CGzLjh4mMjzpd5xxTAxE6Ms7eQfz3Qj6dP50AFbacOMrokpEW IpQBxFhS0a7ix/YJtdGB =HGAk -END PGP SIGNATURE- -- 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/51a5f6b0.8010...@debian.org
Re: lintian: no-upstream-changelog + non-standard changelog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Le 16/05/2013 15:11, Felix Natter a écrit : hi, the package freeplane does not contain an upstream changelog but does contain a high-level change history: === 1.2.23 === Bug fix for dragging of nodes when node tool tip is shown === 1.2.22 === Bug fixes for script based conditions for filters and conditional styles [...] Yes, this _is_ a changelog. Eric (the previous packager) installed this file as /usr/share/doc/freeplane/history_en.txt.gz, which seems ok. But how should I deal with the no-upstream-changelog lintian warning? - override it - install this file as /usr/share/doc/freeplane/changelog.gz and /usr/share/doc/freeplane/history_en.txt.gz Rather install as history_en.txt.gz and make changelog.gz a symlink. - install this file only as /usr/share/doc/freeplane/changelog.gz Either of the three options look fine (reasonable, policy compliant) to me, just paint the bike shed the color you prefer... Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJRlN6dAAoJEJOUU0jg3ChA4zUP/1B72xuRdEK9VAaro7hlV7iq job/1FPtIKp6j/pSeKmkJo0B4ybqpTUkcysym0lwpdUYBMEuQAzYidxJ9zQsW0zI 4fcXDk0wGitOiOxuS59QYv3eHv1NanI7FXLt7J40faPOgHYZFRbwrJxs0Fxq2hTZ ylV1PeE8ejy3ZQsC4WLVd8Yz+e1zmPKhxhlI7NzlLVS4cvRIBYdA+CoVABFKMAuu vCZ8zDkTJnyeWkKE8h8kIlQIGy2oHgSPGTqzxSG2Td9otHDv1abBXa/x5dDiGIT7 4wchAsFyqaqjrt5l/NiLrBetQpjkFtPeU6HlqYyLlRfXlpEbeWiybjQDcuea+n6d gDIIVEEk/b5jbhsrorgWDUHU7PO7H+wuKHytBtqUbdBROQ8vbHDehT7ruEFA8W3x Z0gVbGMmruITe+9mtLMYT8CryK1NwZHf+8HH+oMT8aFrwsAjhuS9A/oHvsBjnrMi BBBWhrwHZn5nOMZw786YWEnRoYfghYhKGIcjIc+9atzOoLaE1Ssdq9yrkg5rtyWp flI2reEVOQ1Bg4uJlRiNuUFcxuJjfScXCLlyUm+RYB1fYmnNFuSB47HFpIlpmyzU mugLvpUHxVIuQAilcj0TfNbCgd3m6j987s0Y8afy4UIZvsrq6rzET3/yJEcCWgY/ zbBpW1ZlWpv3dyv43ZMr =anZZ -END PGP SIGNATURE- -- 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/5194de9d.5070...@debian.org
Bug#696385: RFS: astromenace/1.3.1+ds-1 [ITP] -- hardcore 3D space shooter with spaceship upgrade possibilities
Le 07/04/2013 23:52, Boris Pek a écrit : Hi Thibaut, I have updated packages astromenace and astromenace-data. Now all issues should be solved. Links for download: http://mentors.debian.net/debian/pool/contrib/a/astromenace/astromenace_1.3.1+ds-1.dsc http://mentors.debian.net/debian/pool/non-free/a/astromenace-data/astromenace-data_1.3.1+ds-1.dsc Git repos: http://anonscm.debian.org/gitweb/?p=pkg-games/astromenace.git http://anonscm.debian.org/gitweb/?p=pkg-games/astromenace-data.git Please have in mind that `cp AstroMenace AstroMenaceFS2VFS` in debian/rules in package astromenace is temporary. As you can see in SVN repo [1], special separate utility AstroMenaceFS2VFS will be available in next release. But new version of program will be released only at summer. [1] http://sourceforge.net/p/openastromenace/code/261/#diff-8 Best regards, Boris Hi Boris, We are almost there, but not quite. Just thinking aloud: the problem with the current scheme is that the game data file will be present twice in the user system: on real FS and in VFS. That could be avoided only by copying the fonts in astromenace-data source, so I guess we'll have to live with that. I'm wondering whether you could ship the data in a tar.xz archive to at least save some space? At least you could avoid duplicating AstroMenace as AstroMenaceFS2VFS: simply move the postinst/prerm logic in astromenace instead of astromenace-data. Note that as is, AstroMenace indirectly depends on AstroMenaceFS2VFS, so you get the two exact same executables twice on the system. Or you could make AstroMenace a link pointing to AstroMenaceFS2VFS for the time being. Typo in astromenace's control: - you can skip the line This package contains game executable file. If you keep it, you need an article in front of game: the game... - This package contains utility which generates AstroMenace date file.: date - data. Here again, you're missing an article: a utility or the utility. Thanks for you continued efforts. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#696385: RFS: astromenace/1.3.1+ds-1 [ITP] -- hardcore 3D space shooter with spaceship upgrade possibilities
Hi Boris, In the rules file for astromenace data, you list fonts in /usr/share/fonts/truetype/ttf-liberation/, but the files there are symlinks to files in /usr/share/fonts/truetype/liberation/. The symlinks are provided by a compatility package which is not listed in your build-dependencies, so building fails in a clean chroot. Can you fix that? There is a more serious problem. You copy font files which end-up (AFAIU) in gamedata.vfs. You therefore need to abide by the redistribution terms of the license of those fonts. The Debian way of insuring that in a generic manner (for DFSG-free material) would be to list the font packages in Built-Using. This ensures that the user can get the source for whatever ended-up in the binary package. The problem here is that astromenace-data is not in main but in non-free. I'm not sure that the Built-Using mechanism is sufficient to ensure that the source package for the fonts remain in the archive. Can you check that on -devel or -legal? Else I see two solutions: - copy (part of) the font source packages in astromenace-data (I didn't check: if the ttf files are their own source, you only need to copy them and amend debian/copyright); - pack gamedata.vfs on the end-user system to avoid redistribution. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#696385: RFS: astromenace/1.3.1+ds-1 [ITP] -- hardcore 3D space shooter with spaceship upgrade possibilities
Le 27/03/2013 09:21, Boris Pek a écrit : Hi Thibaut, Can you explain why you chose to split the source? This forces you to have astromenace only recommend astromenace-data, which is not good since you can't play the game without the data. I have at least three reasons for this: 1) It is more convenient in maintaining. Data files are changed rarely. There is no need to rebuild and re-upload huge package with them each time. 2) As I wrote earlier [1] package astromenace should recommend astromenace-data only at initial upload (to avoid circular dependencies). In next upload astromenace-data can be moved to dependencies. 3) IIRC buildd does not build packages in non-free area and pre-build binary packages should be uploaded into it manually. In this case binary packages will be available on less number of architectures than it should be possible. [1] http://bugs.debian.org/696385#19 Best regards, Boris Hi Boris, That makes sense. I was also thinking that the root of this was the ability to autobuild the binary. However, I have an alternative proposal which would avoid the problem and should not impose too much hassle on you: ship the entire source in astromenace-data, build the executable there, use it to package the data, but do not ship the built executable. This way, astromenace-data does not need to build-depend on astromenace, which can rightfully Depend on astromenace-data. You don't need to bootstrap by first only Recommending astromenace-data. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#696385: RFS: astromenace/1.3.1+ds-1 [ITP] -- hardcore 3D space shooter with spaceship upgrade possibilities
Le 27/03/2013 13:43, Boris Pek a écrit : If you agree with this tricky/artful solution I will prepare updated package astromenace this evening. Forget it, I will upload as is after a last round of checks and after I manage to setup a local repo for use with pbuilder. Cheers, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#696385: RFS: astromenace/1.3.1+ds-1 [ITP] -- hardcore 3D space shooter with spaceship upgrade possibilities
Dear Boris, Sorry for the delay and thanks for the ping. Can you explain why you chose to split the source? This forces you to have astromenace only recommend astromenace-data, which is not good since you can't play the game without the data. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#696385: astromenace: reviewing
Hi, I'm reviewing astromenace. Looks pretty good so far, you seem to have already tackled the license problems. Looks technically sound. Regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: debian/bug-control: report bug against unofficial debianpackages
Le 07/11/2012 15:30, bilibop project a écrit : Hi, and thanks for your replies message d'origine De: Russ Allbery r...@debian.org A: debian-mentors@lists.debian.org Sujet: Re: debian/bug-control: report bug against unofficial debianpackages Date: Mon, 05 Nov 2012 12:46:29 -0800 what can happen if a user reports a bug against one of my packages by using 'reportbug' ? Must I explicitly add 'Send-To: quid...@poivron.org' in debian/bug-control to avoid conflicts with Debian BTS ? I use Bugs: mailto:address as a source package header in debian/control instead. message d'origine De: Thibaut Paumard thib...@debian.org A: debian-mentors@lists.debian.org Sujet: Re: debian/bug-control: report bug against unofficial debianpackages Date: Mon, 05 Nov 2012 18:19:39 +0100 The .dsc and .tar.gz files in the personal repository are exactly the sames than those I have uploaded on mentors.debian.net. If the answer to the previous question is YES, must I send a different version on mentors, even if the package is not sponsored (because if it is sponsored a day, the source will be modified and the personal repository will disappear) ? Actually, I consider it a good idea for both packages to differ: the packages you provide on your personal repository can be considered pre-releases of the upcoming official Debian package and their version should perhaps be of the form: x.y.z-1~rc1 to sort strictly before x.y.z-1, which will be the first package in Debian. This way, when your package gets finally included in Debian, your users will automatically get it as a routine update. message d'origine De: Arno Tölla...@debian.org A: debian-mentors@lists.debian.org Sujet: Re: debian/bug-control: report bug against unofficial debianpackages Date: Mon, 05 Nov 2012 17:52:04 +0100 The .dsc and .tar.gz files in the personal repository are exactly the sames than those I have uploaded on mentors.debian.net. If the answer to the previous question is YES, must I send a different version on mentors, even if the package is not sponsored (because if it is sponsored a day, the source will be modified and the personal repository will disappear) ? Yes, you may need to do so. Alternatively you can just upload the package including the debian/bug-control file you mentioned to mentors and hope your future sponsor will hopefully detect it and ask you to remove it by then. So now, I'm a little bit confused... @Thibaut: Given that I'm a 'git' beginner, I don't know exactly how to deal with *parallel* versions. More exactly, how to manage the changelog entries? If I ship x.y.z~rc1 in my personal repository for each x.y.z version that I upload on mentors.debian.net, as you suggest me, does it mean that for each version, there should be TWO entries in the changelog, as: Hi, You can do like for backports.debian.org packages: keep the official package changelog, and simply add an entry for the backport. Real life example: iceweasel (10.0.10esr-1~bpo60+1) squeeze-backports; urgency=low * Rebuild for squeeze-backports. -- Mike Hommey gland...@debian.org Fri, 26 Oct 2012 13:37:26 + iceweasel (10.0.10esr-1) unstable; urgency=high * New upstream release. * Fixes for mfsa2012-90, also known as CVE-2012-4194 and CVE-2012-4196. -- Mike Hommey gland...@debian.org Fri, 26 Oct 2012 15:19:35 +0200 iceweasel (10.0.9esr-1) unstable; urgency=high * New upstream release. * Fixes for mfsa2012-89, also known as CVE-2012-4192 and CVE-2012-4193. -- Mike Hommey gland...@debian.org Sat, 13 Oct 2012 00:05:54 +0200 -- 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/509a9342.4000...@free.fr
Bug#692366: RFS: kbibtex/0.4-3 [RC][ITA]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 package sponsorship-requests owner thib...@debian.org tag 692366 + pending user sponsorship-reque...@packages.debian.org usertags 692366 for-wheezy not-fit-fot-wheezy thanks Dear Bastien, The debdiff is enormous, because you have renamed patches and added a README.source, because you have decided to use gitpkg. Please revert the unnecessary changes. Remember that you will have to send a debdiff to the release team and explain the purpose of each change. A larger debdiff means more work for the release team and less chances for your package to be accepted in Wheezy. I'll sponsor this upload when it is ready. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQmSHUAAoJEJOUU0jg3ChANe8P/R59/meAZ1CxQwlGdwS/ga4/ ILQJ6vJpF/otaOU6wADbREgJxt46nDBmDWC4FRjRcR72YkhAkCsAsxJEI8OxrifD Vv7hnx/pwHZbBm18CLFiO8pf8CqRlg4HmhURXmTRPQOp5eigt7G0LJtXEuWsNzUX 9RiX0hEcsw4R0moyqMMeL75O+uC1BZFp7BHmBLxIfwiuLODsHc7QsD2xFB/wwXfz IUw9VeM02VIlJnxbAf2XbPbj8Fo8Qa1a2LROo9zYQojvh3tLez3sAv4AIjE4cEPW BoOvPDNgn3jKzABsVnBOp1vtBYA7pVbGXlbh2GerDczRD+3y+QSBYNzJ7L/csA46 Vleb/KyM9qfr0lzBvtvR/VqfUFd8xDl2wRV90JggWvgFEYZycl1UBmZT2teJgmcz ZB9tkq5vNLvuZ8wEwgkx5AnngJFmXECPeHHDIDvGWPVO419jyYrJQBkNzyGQtIEA 8VltfYRkEqHEfZKDCiTKvZEE41j9rEEAxRRX5hW12Gl8o/lCf4OuWblrtZ8ftBcH CTTrrNxIbZIYlJgXn1SPW//FVd1vH2MQuQ7z/rLXvCSsU5i/0+JSoH3GZE6sp6lo +2m1qrxmB+9bCGV9CnUb6cg7UTp50W0CI83fyZJynLLW/H2pt76Ic5jPr+PM0T/u M8IYEFUF2nDE4kaRBHGQ =Xiho -END PGP SIGNATURE- -- 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/509921de.1050...@debian.org
Re: Bug#691780: RFS: imagemagick
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Bastien, Le 04/11/2012 17:25, roucaries bastien a écrit : I could as a mainteners open artificially a bug on the bts This would not be artificial, this would be good practice (assuming the info is not embargoed by the security team). The BTS is a central place to communicate with sponsors, with the release team, with users. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQl39zAAoJEJOUU0jg3ChAm84P/jM+2aimxKseqvclOup7XgrC x4r5zP25bIdRMkdPVJyhy7J7pcrHaEnhnINXkRGONYKmLRfUXrf944LTqx2mDkOO u+byl9GPl506NGt7oL0UryU49DUlweMpLJrPTftpz/bjyZD3+BJhgIJLFJX944qA PP3YccP+qQUHU1IwbruZOCzL+Z9MzbhYowDfPoW1FGy1kTD589jnDPa1aEE8S3e7 wUe2YDHlqHuLs9Zm0C1fqItvskwG4wfnCdQwyH8vd+SK3lIjnK4FSGyCNTUB1yWO 1vld3o1m4sPS3zGX0/gej+m9NJuZFxqnTN8GBJVZ0QGzJBYVQMqBTL3xYNr5Ab4t VTDeohItgLO9DBMHPD7JhoNvvb8GhVjSfsZ0d9+PkTYeFYTqLmjs/DSKz1gVE+cb 5J5Bh2WmhgTF3WLE12fiqIiDY8y314wJI9n4P8SDfgoF08Oy1GYPC31hdXLnU263 nbwuOpMqjB35vGmNbZ0kGaGBs4BEWBMtg5rnOkFfoQHwP4PVM3gXX199N4Wc/KMm wwSuPFUySmUzE8oeKvYxF2sErBJw4bdKrRuKXEkPhJtVkla9yMbFP8RiDNWgBP+H yrftQFtLJIpLYmk1YnNiTxdf2Yt+2H6RH0r0g0wmaANwYB8333Dktq8SfE28bp67 R8/dNYnMhnXJMknSFImQ =yt8c -END PGP SIGNATURE- -- 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/50977f84.1000...@debian.org
Bug#686070: libpam-ssh/1.92-15
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Jerome, - I would be much more comfortable if you asked the previous maintainer for comments on the ITP (even if he never answers!) - You could comment on #691988 explaining why you think the package should be accepted for Wheezy: + insist that two users already requested reintroduction; + explain why you only took action after the freeze (perhaps you used the squeeze version happily before that?); + explain that your RFS was filled in August and that you are not responsible for the 2 month delay since then. - That said, the package still contains non-minimalistic changes. You need to produce a debdiff on the source package in squeeze and your source package and comment on this debdiff. Every single change must relate to fixing a RC bug or a release goal. For instance, I don't get why you made those changes: + why introduce fix-debian-adhoc.patch, build-depend on du-autoreconf etc? This seems to be replacing this: $(MAKE) CFLAGS=$(cflags) -Wl,--version-script,debian/pam_ssh.version which I find simpler and more elegant. Perhaps some of these changes are to fix a bug, please undo whatever is unnecessary and explain (in this bug thread) what is necessary. + Why remove the VCS control field? You should use the repository instead. + the clean rule changes also seem unnecessary. - Perhaps your package will not be unblocked for wheezy. In any case you probably want to upload a new upstream soon enough. I would not upload a new upstream to unstable at this point because it would lower still the chances that the packages makes it into wheezy. However, you can prepare the best possible package with new upstream for experimental. In this package, you can do all the changes you want. I'm willing to sponsor your package (either 1.92 to unstable or 1.97 to experimental, or both) but please try contacting the previous maintainer for comments. Note: I'm subscribed to the RFS, the ITP, and the release.d.o bugs. no need to CC me. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQl4MmAAoJEJOUU0jg3ChAEaUP/iZhBeULC/yy5wGvyhTqZXn4 /YIhtTqTxOQA2rNwUMc2jyDYnAu6GpCrYjOz9wmWk2C356SehDkAAD/5rLoAbDKH /DG/ZEUjgjfTcQA2IIu01jnGdSIM3p/D3laq6xaeFXBOYeTQ1DMlmhFVAm8mc74u db+LE/teDlBJF8EQ1IBcOmOHq8xXQacLWngk08NhHwWdAPtMpoLhnuplDGEH3XFM uLH4gJSpPNhk6Py7FOKT7v5VTg90QwNgilPnoBXdOWsQUZLAxWLLnLjNHDB2m6Ed Y7CZfuL/TH3uqtWUR4jmECYbuiiNwtVoFgT537V/6fJD6DDj9K5pWxE3226vCjUL N6Ye3U50lLIdtd8c9D/0SHbPDMR2sMpOsm4Gb/Ko49rqzU9wZHbkbgGtdjXLNg3D A/f+j0cs2+Dj7uPXUXALhvhM92119ePTPPLDZ/Vnk5s3mva+pYEjgr6XT8TzLMUA XQq8/WTqwgrpFQjqcoRFSo7MHtm3eD+ZWeK3GzkDanVoxafmMN5z0GMLtSjSiE8e kjmdZkuqAf6p1Yp6gevtMx8MRUf2/IR/B1eyFdZI927O13MfdVbvZKotriy1KgR/ thVfNIlGMfw+6+tRRs5JyrGMK0grYVOPtW0++ZDiRid9mO0XreB78VU3DQVThOZh uyfjVwH1lhkNiVy8IOle =/ZWo -END PGP SIGNATURE- -- 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/50978326.10...@debian.org
Re: debian/bug-control: report bug against unofficial debian packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 05/11/2012 17:43, bilibop project a écrit : The .dsc and .tar.gz files in the personal repository are exactly the sames than those I have uploaded on mentors.debian.net. If the answer to the previous question is YES, must I send a different version on mentors, even if the package is not sponsored (because if it is sponsored a day, the source will be modified and the personal repository will disappear) ? Actually, I consider it a good idea for both packages to differ: the packages you provide on your personal repository can be considered pre-releases of the upcoming official Debian package and their version should perhaps be of the form: x.y.z-1~rc1 to sort strictly before x.y.z-1, which will be the first package in Debian. This way, when your package gets finally included in Debian, your users will automatically get it as a routine update. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQl/UrAAoJEJOUU0jg3ChA/WkP/ArdL4h2jjICSAI3gX8d2Jta ayAPbWVxR92ypaeGNUwE5t/9e6qvsuDKlDQ3+HFBSRqHv+V5kRW8xfLCXZeAli1a Dv+AuxQBQhzCroZijiTSxWSDMaWwsCM89DnoTUtP3v6WfCZIuC47ncPokGvwzuaR LHm6cDTQGy5PO83//nCpn4UDCFNcoY5f6VvZJ2Kq+xMuOp6JyLiORRvqywF4XkdN uyrWaCsOckUvYyd8nXtSsaLjNlkO8/71ack7DVjqi302mux4SFjrJ1lHpaTaM9La dtvm14cUA1TlRJ+7t75OHrh/MbkXcI2o2dyTH8k0qj/Abb+O4vwGiRyKb5b99opx 9T10IB0xbzdR9ScR/DHzOsurYBQgOYvY6g0Ng/B+psGY8kdBVllldSZyftcmNm2m DKzuLKOlANJXDIjGmAcC0Nei+n2Hx0WYU+x2VsISjKiZR9LWBfH1MxgQOEfgD+h2 HRJ4Pnx5rJWyEEg5ahlVaFpSxQnj1Ss0SauWiQLbwdG04D8MX91t/3NC5jqG1uuA 3gfyEXYEJ4hQKXXOlhrFJ8/ak55qfSkHz/vkXbYe2vyA34z//2vW5uB353ENS+SF ugRZQ/+50FXvfmB585IVhtEn9SphV5wjPWODPtEPRvGNfJTl6B/qi1usGqEbKaxT BuA2I/ai8AcTi9niKIKY =Aa/n -END PGP SIGNATURE- -- 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/5097f52b.2030...@debian.org
Bug#691780: RFS: imagemagick/8:6.7.7.10-5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 02/11/2012 16:46, Bastien ROUCARIES a écrit : Yes for wheezy and asap due to security problem that could lead to dos Bastien, have you contacted the security team? If this is a security issue, the security team should always be contacted and they can certainly sponsor the upload for you. Regards, Thibaut. Le 31 oct. 2012 15:09, Thibaut Paumard thib...@debian.org mailto:thib...@debian.org a écrit : package sponsorship-requests user sponsorship-reque...@packages.debian.org mailto:sponsorship-reque...@packages.debian.org usertags 691780 for-wheezy thanks Bastien says before end of the freeze, so I guess this is for-wheezy. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org mailto:debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org mailto:listmas...@lists.debian.org Archive: http://lists.debian.org/509130b5.4060...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQlY/wAAoJEJOUU0jg3ChAGk4QAIHVvs4hUUPovhKKXo0VsNYv nHp0c7z+DxA/UxbxTIVmIX/wjaoJzAEFzylTJ1AePHVKiuXJSypxzBqanCV5yrN/ ybNdSHFqJbL1pIqX7BsGi03HVluOV27DDkuegYTv7+yUZShPXLYq0hIlJv4AKix0 xkCNyR8++rlBddXNyAQQjE05YFDKU7SL1UvgNyNxw4GEtuPTCLhF7RvSmK5sNK6A 24JCuZsrDcLk/VocLH1rhOgfaPep66w535xt76EbdfxrfJWcSTv4zL4IN/G6sWZ7 zO59F7//0QoILDM8PqVr1LzjNZZdhyXlxUIRAOAHIRJEzvbwotekpD2QDhPgrNy6 y1D3OebP1JqGZhal46Hb+qHCBfPjPoLIL6+/80zf9ym5By8Qi+VwtmLsCFgSwUoS fHyyMHIEP65y9p46lKUklfI94erPAUOlhno3X/Rck3YtnJEQktztMTvaFjgyHYsH shqWDrKDsl1DPTHQ4RYEJow3C+4PSWZn3QVposWJEeeGCyw0yJycLR7CCTY1svhu 1fPPFIlfjQaoDQRYPDCNN3xEE5zTT6ZKHrnMGXZi9EsmD3tFok7EWzp/HEjMT2Pm B/7E97N6H98zDPeO78OFBs2eML2UhfiNGDmsAb+TVQBcGizoHKlbJ3QUTejEclH9 0piK8ySPPj9nnON+f/Em =nwMH -END PGP SIGNATURE- -- 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/50958ff0.2010...@debian.org
Bug#686070: libpam-ssh/1.92-15
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 02/11/2012 16:33, Jerome BENOIT a écrit : Hello: On 31/10/12 14:36, Thibaut Paumard wrote: package sponsorship-requests user sponsorship-reque...@packages.debian.org usertags 686070 - not-fit-for-wheezy thanks I'm removing the not-fit-for-wheezy tag since Thomas claims to have improved on that matter. It still have the tag `not-fit-for-wheezy'. Actually, you have it *again*, I don't know how set it back. I don't have time to check the package right now. Do you have the intention to sponsor it ? I plan on reviewing it in the next few days and sponsor it if it's fine. You will need an unblock in any case for Wheezy. Regards, Thibaut. Best wishes, Jerome Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQlZDeAAoJEJOUU0jg3ChAuY0QAIy+pihKHYuIB0EcZtTGASmB x0eIM1guYHscL+X+dhkJwdubVgxKZ3MFEhNq8rx3FCHLUXMXGKig7nXo6vooubaj AuqH2Afzh7bgr7yKiUWM9S4NxCKTPNJeuV9NkEM3Xhg40/IimjDHJyQTmiSSLgf9 nwXVbQhfvQdzgbKd5cUembEcXPXdf5YknnDlc9KLZDEX4muIYcegUHDZwk67lT2y vOWjSFCii3yEvUOjptWvERu+dTeGFsSio3CBSRTy9HkhfwkUfG67SiGJGDIHyY3Z X1nthS76FZqcJK9lGp0zF2ZZtkTRHt1eALHaNICXsjgHyKpbqUS6FnnI15QugmiW YIyShMlRigq+U+Xjy/ZotTptUGz4IHg9qiR04C8cqchRJPy7iaFvvqEZxpUHnWhI n2D+JULci73Ub6fGxYdI5PkbZIOfxul4380BtqWfE1jvLDlsLr0boIMcYay2ho2H V6CpllMP3ts6TQ2NVQ4177P057eXrd447S/VETiSDWNq/EagtJb14+vDWTMs0ucA WzxS+s+hrd2eFrg5sxxPrnSrWp7aY8tTjRyz5WsLgvlPdXXGZHsQiZf4KeJoSWq1 AtNSGpBSgjjdm2deC9XUjW/ag5MiOOt2WukQwDLtDA231CeQFUPcK4gKuJRqOlBV VkUrBvrfMSN8gSVzupHT =YEDk -END PGP SIGNATURE- -- 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/509590de.2050...@debian.org
Bug#686070: libpam-ssh/1.92-15
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 package sponsorship-requests user sponsorship-reque...@packages.debian.org usertags 686070 for-wheezy thanks Le 30/10/2012 21:21, Michael Gilbert a écrit : control: retitle -1 RFS: libpam-ssh/1.92-15 [ITP] [REINTRODUCTION] Unfortunately this package was removed from unstable, so it won't be considered for upload until after wheezy unfreezes. Removing RC since as a NEW package the RC categorization does not apply. Best wishes, Mike Hi, Mike, I don't agree: this package *is* a valid candidate for an unblock, as is every package already in Squeeze. Jerome, seeking pre-approval from the release team would help your case. Since Jerome explicitly said he was targeting wheezy, I'm setting the corresponding usertag. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQkSOXAAoJEJOUU0jg3ChAp6YQAKcc5IvNISt4NHr6661QNZ31 YVsRwxo1QvJeaHqnzjfjamFL/GhWybHMwGbxDYkVzr9HF4Z9XqDkEHRXV2M/I9zx 1kqxpToz8PJz4yk8V3QtHUOgWUnu5W0wZPKYdZOvBpFaO5474tBWCmhhhrgga0G/ PArnu8shH1OjOJsO5gt3PO6pqVPyP0OtCT+jnOfwkZhgf3vIeZ5iXQNZrdwUsCPH vkAlLb99tqb+pOS1shbs5D7EoZ7mJzlgqoNGVgQV+5B2go9wAvBSN/D3aghyse8H wdPVuKGDqg8VesFC3cnmHYahFwJ2QmHGqSx1alPsCQdUVHXcGMHkzyaFg+WXm/vX cMP0JGQ7IUeeUe1gYrFzw66sSjvbXWyNdKvViciJwWSAzSl2cJOBb0RRlq7xcNE3 Kn6s2RQzbdUt10/cOBXgzK/Z57IKS5Xs3UIqz89raMBlcZ5jTXg0AHcvumHK9k+3 B98z6ln1eBao4bISqE6f1/+EH3tL0QAVk51Vcqqjrsdai4EKJWp6Ro+nrfxWw+zg W3vYp59KnSNDMM8irf9tZIkCDmhAlRY2wVLya8AaG1Xf+0E0L9UGcrFwhlr3aIEz I7RxtzpJoNvthFge992yQcmW773/3ixFVCfY8BYScpK8oi7hbtcUEOGHHJOXBTsX RhPXXu/rhVZ/0kCwvhV5 =x0ZV -END PGP SIGNATURE- -- 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/509123a0.6040...@debian.org
Bug#686070: libpam-ssh/1.92-15
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 package sponsorship-requests user sponsorship-reque...@packages.debian.org usertags 686070 - not-fit-for-wheezy thanks I'm removing the not-fit-for-wheezy tag since Thomas claims to have improved on that matter. I don't have time to check the package right now. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQkSlUAAoJEJOUU0jg3ChAjuIP/jT956v97Pie/byOMly/r2q+ YhvnLzi7jwUmRTT8eC2ZWzhoNVqQia2eAmfJsx3zbnhQ4WKqq5TPwctOWkEtqBl1 D0HZxFIO3rQkxr1QktoSVfSOTnUm4SG0sPy4gG69vBfRFO74FR4b/oV6ISMVlA+D EgijLmbuJIjyLsQNBlwEcWfx/55AkUCGDT6ql1PPfzzGBctJTn+CgybPGEHrw91Q VizFUIRVyOq+pAhTGMxh4bRyzat55KXyAwjg2Ucbq/xcLKF1BKys31ZEErm4D0LA wZ1PgZbsg/REaqWMvRsB+2TA8upUFp1GIDVxNsy623cGEy60bMZPRnsn4++Wm3ov gqlG/PqWDSc+9GgltjTq/kE7xvNWh9UKagNvpNWx3R/0Zg5beVnKvUXJKzmsACwE EjQM2N2BSra4sf07OQ5UIGDphdxOl+1PCyCV6vpy4ZLgGRPvUMSvOLht3ZZBRrAH BkIR2LcHevVB25WMRWwZWULO095hKQF8lXxzUTJW6yRsWELPNYcjYN9/jx0Irl0+ ei7kkQM2ulz0ADEJjO2QGdQuwfPbzRjufWM3Mh/q5pnvY2q2j789xGIHo+fPtRjR 23Z0QnjKwAJ6N+/IqcOlfbzbY8ePxcwS+v0hR3Llmp6tpzxj59pfe/eW4iLGyAq5 H1gZR4SCVLQ1hsf7V160 =zbuq -END PGP SIGNATURE- -- 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/50912954.1070...@debian.org
Bug#691780: RFS: imagemagick/8:6.7.7.10-5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 package sponsorship-requests user sponsorship-reque...@packages.debian.org usertags 691780 for-wheezy thanks Bastien says before end of the freeze, so I guess this is for-wheezy. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQkTC0AAoJEJOUU0jg3ChAI4oP+gMT7lgSe5ZoPkpBXc91fMOP 4ZWTKqRfkOrwRXbdEVD6EX2FGH7hBPng8JgGiV/tML8DW5ATfajh8dp4Tbhr5Gcd aOH6Vg68hEFjjBPj/pTAJeZO5GBOEmG9qNTN+A+1zI7OtCFW0oHkAqe2OHK+4qY2 LiEzQf8qa0ooYWnZiMv03HyaMcwrzlmtTYiNJddlSFIoLNKd/AuzHWcieD4xDIJZ XY7DuswAkYOxmTkIvJj6xGtjS3zgZjen09/HhBFqVWKF39SozMDXXEDlRU9v+0pW gSDyWXFC+rmG+nEs1kXupCrqTqIt9Ji8JxlDq+bQHVFdEUE9XyvKFMttizBO9gwu e6qC6qs6zsuvgY5NLigSknjiP/l1gWiqLo7CYJFSOFqxx7yqwWBjLA5xwXOtL3R5 VD/YN3lz8ExTKvtTOWoOEKlhmFa4JhOldodHy83wVf7RJ+FM1tktHKkxsGKGB5jf jbIirXD8B/r23c9SYlJOD67EvGhTt+GBi8iL2o+jI5jqnGFwMaCeAio+BxnlckGo Z+Kn8jl4h7Sx1XptqGj02L20WMjI2aDHE/BApOjqhjP1vIubI0VcTlZa5ZFZM8Gu iDCEso1VH4whFFMaA/uxdUo65lDEyTCtRtdntpOc6TfquFKeVRleaTl/IjQphA5M 6ug/33GN7H3uHgzfN8MW =beCX -END PGP SIGNATURE- -- 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/509130b5.4060...@debian.org
Re: (Non-)Usefulness of the current for-wheezy and fit-for-wheezy usertags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 26/10/2012 00:55, Michael Gilbert a écrit : Hi, I feel like the current for-wheezy and fit-for-wheezy usertags actually make the sponsorship-requests bug page harder to use than it needs to be. Hi, (I tried answering on Saturday but I believe my e-mail never arrived, or perhaps I sent it only to Michaël. This is a slightly different answer). First of all, you are free to view the bug page with the ordering you prefer. Try using ordering=standard: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sponsorship-requests;ordering=standard In actuality, any bug tagged ITP and QA should not have either of those tags (since no itp or qa upload is going in until the freeze is lifted unless the qa is rc, and in that case it should be tagged rc), and any bug tagged RC or NMU should have those tags. So, why then are we using an orthogonal system? Why not just have usertags itp, rc, qa, and nmu? There are two orthogonal categorizations, and I'm not sure how that helps. Best wishes, Mike Discussion has started about here: https://lists.debian.org/debian-mentors/2012/07/threads.html#00030 and the tags are explained here: http://wiki.debian.org/Mentors/BTS http://wiki.debian.org/Mentors/UserCategories The goal of the for-wheezy and not-for-wheezy usertags is to get the maintainer to explicitly state her intent. The goal of the (not-)fit-for-wheezy usertags is mainly to allow for reviews by people who will not sponsor the package themselves (which experienced DMs and some DDs sometimes do). At that time, there was only positive feedback. You are indeed the first person to express reservations. Now that three months have passed, perhaps we can gather some more enlightened feedback on whether the four usertags are useful or whether we should simplify. On the other hand there is some overhead inherent to changing how things work: if you want to introduce the usertags itp, rc, qa, and nmu, it will take some time before people actually use them. I would tend to defer that until after the release, when we will retire (not-)(fit-)for-wheezy any way. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQjl0QAAoJEJOUU0jg3ChAXGEQAIvetWG/VcmnE1mPi/yWAH77 Ij8a+hbiVPnzrz/3zM+mxpONBUF0ViDS+4sN2TxGZpYhT1tim7u0P0wh33goERBx EI74KTjlotUNHBCYUfz5jQCE4l/zKnVpaesmh4CScoE5MAd2UwPvameQwQfEjq40 q+GOOC4wXaLwnAJvC1PHKE7gTtw+ytA+AfyJEgNDymxm42fWBpGlrUDnjPRSfBB3 kRiapalOH5HyT1zOi7ogOItMwzjBTxTulUOjFkB3zbBxRhnEPwuHV+K9MqhPMe8V H1d0u+xfJjaSJzAVk6el4joCrEuimXUXALP9KLT6ZTv0hw8yR+OLV4/M/XbymfZq fF2UZHQFgBHYpiTPHJb9PVYK3flb+MSweosmFzUmTJWV32GOskj2PVYT0KsQSNoJ G6gPFfehKS8YFQIUcyUOqH5tVFPxJ31QB3oHNV3lGHo6y65Ur3WA2PNHeQtEfRgm /ysGSG5LalFPvBbxrFrq0zmX5WeURMwr3rt1kPQ6R+HAZyXLOa3tod3fUYOftG7b 8xn/ieitMk1S9KVZbUk55CXRiOp5Rl+VUKdWOccbnbbXO/pvMcKQD9XVu72oMfDE iElsLcKKfdTwpalPsxsgffNxPnVI9Rbhv/3Krl57ski4j7qyLYDLRlHVG0WQsHYa RBU10IOCrgm9UUL9y14f =xEog -END PGP SIGNATURE- -- 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/508e5d18.9020...@debian.org
Re: Lots of problems with upstream, please help!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 23/10/2012 06:38, David Smith a écrit : Hello, I hope this is the right mailing list. I've been a Debian user for over 10 years, but due to schoolwork and work i haven't been very involved in Debian. Mostly I have submitted patches to upstream or helping upstream debug rather than helping Debian specifically. When you help upstream, you do even more than helping Debian. For a long time, I always end up with a dozen or so of my own custom packages which I derive from official debian source packages with an extra tiny bugfix patch or two I've thrown in on top and recompiled. Sounds pretty selfish, I know. Well, now you may have the skills to submit your patches :-) With Wheezy coming out, I'm trying to help any way I can but I'm having some problems. If they're release critical, please do so. Else, just prepare Wheezy+1 :-) When Wheezy is out, you can *backport* those features in wheezy-backports... As a general remark on all your problems, you have already realized something very important about how free software development (does not) work. Actually, this is not limited to free software (like, at all): nothing worth having comes easy. Very often it takes months of prodding the right person before your patch is accepted. Technically they are all problems with upstream and they're all for different software. I really don't know how to deal with them to help Debian. 1. As a big regression from Squeeze, I had to blacklist an HP platform driver from loading into the kernel in order for my wireless to work well. I filed a debian bug report about it and the debian maintainers helped me collect all the information I needed and submit it to upstream. I did all that, it's been 3 weeks, and the upstream kernel platform devs seem to have completely ignored it, although linux-wireless confirmed the platform driver is doing something very strange. So I don't know what to do. Maybe I just need to wait longer? 3 weeks is short. Is the bug release-critical? 2. About 8 months ago, an upstream developer wrote a patch to enable a feature in upstream software. Upstream didn't review the patch so it never officially made it into upstream software. Requests to review the patch by me and others are getting completely ignored upstream. The upstream dev that made the patch looks to have disappeared. Upstream seems reluctant to accept, reluctant to reject and reluctant to review, so it stays in limbo. Without upstream's proper review / approval of the patch, in addition to the fact that the patch essentially enables a feature, it's probably unlikely to ever make it into Wheezy, right? I filed a bug report saying that the feature didn't work as the feature is listed in the software as being available, but it's not actually enabled in the code. I'd imagine an NMU for enabling this feature in Wheezy would be inappropriate and the proper Debian thing to do would be to just write a different patch to remove the feature so the user doesn't see it in the software? Although, that's pretty much the exact opposite of what I'm doing on my PC so I really don't have much motivation to do that. Unless the feature is central to the software, this doesn't sound release-critical and even a patch to remove any trace of the ghost feature would be inappropriate. On the other hand, if you can convince the release team, the upstream patch could perhaps directly be included in the Debian package. Or you can fix it post Wheezy and provide a backport. 3. A couple months ago, an upstream developer wrote a patch to fix what I consider to be a serious bug that makes a lot of apps unusable under normal (aka user customized) conditions. Upstream reviewed and approved the patch but the patch is written for KDE 4.9. 1. I tried applying the patch to KDE 4.8. 4 in Wheezy which ended up as a spectacular failure during compile. I asked upstream to back port the patch to kde 4.8. 4 in Debian and they said that they do not control the release of Debian and that KDE 4.8.5 is available. I'm almost certain the patch upstream wrote isn't going to work with 4.8.5 either, but I haven't tried it as I don't want to be that far away from Debian's packages. There is a work-around that's very easy to do, but it's not obvious, and it saps performance from my PC. I'm certain some Debian users running KDE will eventually run into this very annoying problem and have to Google and enable the work around. I will likely end up backporting the patch myself for my own personal needs if the workaround annoys me enough some day, which it probably will eventually... I worry that if I backport this patch, it might be a little ugly and probably not suitable for Debian anyway, although I really haven't looked at backporting the patch yet. Bug report number please? If the conditions under which the bug bites are really normal as in statistically
Re: Renaming files, patching, renaming files, unpatching, and 3.0 (quilt)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Le 10/10/2012 09:20, Jasmine Hassan a écrit : I believe unstable should move to 0.9.x, and let me fork 0.8.8 for MATE. I have it running rock solid atm, completely integrated with marco 1.4 (metacity's replacement) as the decorator, and even emerald 0.8.8 as an additional option for decorator. You are right: forking is OK for your case. Raphaël is right: - you should try to collaborate with other distributions on a *single* fork. - your fork should not be called compiz, please pick a unique name, such as compiz-mate or matepiz or whatever In addition, but I believe you realize that already, your fork and the mainstream compiz packages should remain co-installable at all time: you need to rename/move all files, programs, libraries etc. As for unstable should move to 0.9.x, that's entirely up to the compiz maintainers and the release team. Remember we are in a freeze period, experimental has 0.9.2.1+git... Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQdSrpAAoJEJOUU0jg3ChABMgQAJtWzOKZVVr4SWHU+o1Haeg9 vUrlEQ73+rivX06d7s0pLI54jfJsosGStDLB2F3Jhur3Q02/UF3z/+8ofXnshZdT da8TTgV4KdGFabudiic2iGoVk2P1BUsb7xMQHKeQ3i+Nmv9E+QDBrZEUUhOJLGvB TY7VRGR3cYlXn8/EyO9fkZz/eUhQIFEhhJ0onIC2HnI5oU9A844uYE4tiKu9WK5r 8ZIOv8v7Qm+s+hHg4GzCgkzw2/wU/MUN6OXGnMQhH7ewloPfyK906Y+Ec7G/nrJ4 nm5yeEaaMigS4hBuy9veqRD3bZ/mrA9mU7hkVXs1LzChWx74/oGmkvxSembFYld4 Pu/d+I4jNH9Xe05Qmnha69Py8SLPOJAV55ryHyI4qgJiPuTXuuQw5wmyeva7vyuj ZugC4hxGWknyIb/zmUj7wgTNPz50E9Eqh1Tmmq9swYuZh+jmaq0VzSdsfBt45V/x lCVK53J5LYL8gBCJhoZa++f4E+KM9y9ebGL1FOV0BdVNbGwf9OYFpJEY7oeNUqmW WDNA9QK6BvgRYXbP1T2YbU8ubpPUIRlPiFHG5sZiFz4YysU86kbmtDElHPaTASlD 1/gy0e6+QLqD7a7YI6THNd622uIgJ3w0JcqU1MZsZ99/ud2rkMWTRBacER4gPJc5 R1RNxL13tkR7Lu3fnDB5 =ST8V -END PGP SIGNATURE- -- 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/50752aea.1060...@debian.org
Re: Question about debian experimental.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 (This thread is better suited for debian-mentors, setting mail-followup-to accordingly) Le 08/10/2012 18:30, Andrej N. Gritsenko a écrit : Hello! I have a question. Since maintainers of LXDE are extremely busy last few months I would like to find a way to upload latest upstream version of libfm and pcmanfm into experimental repository. Hi, Please don't feel sorry for trying to help. But also understand that the maintainers of a specific package usually work on there spare time and are concentrating on the release. I'm not sure if anyone but the LXDE maintainers would upload these packages for you, even in experimental. There are two things you can do: 1- make your packages readily available on the internet, but not in the official archive; 2- help the official maintainer integrate your changes. 1- make the packages publicly available: I would try building the binaries on at least the two most popular architectures, i386 and amd64. Choose a version number such as x.y.z-0~andrej to make it sorts before any future official version, including NMUs and backports. You would then need to upload the source and binary packages to some website. github can serve you here. Finally, just mention it in the bug reports, so users can find your updated packages. 2- Two things to do to help your work reach the official archive: a- Send your changes to the bugreport(s) as a patch and tag the bug(s) +patch (this is almost a must do) b- Prepare another source package (with version such as x.y.z-1~exp1, sorting after your personal package), make it available on the web (e.g. on http://mentors.debian.net/) and send an RFS _to_the_official_maintainers_. You can also, in addition, make this RFS a bug against the sponsorship-requests pseudo package but please explain the situation carefully there. Kind regards, Thibaut. Rest of original post: I feel sorry that I constantly bug the maintainers with the same question and I think they already hate me that I ask them despite they are still have no time for that. So I would like do not bore them anymore. I have all the required debian/* files which are files from 0.1.17 / 0.9.10 versions with some corrections needed to conform Debian Policy rules where they were not and adapted to all what was changed in upstream. Packages made with those files are proven to be created and installed smoothly on Wheezy. Those debian/* files are public available on https://github.com/LStranger/. Why I would like to upload them into experimental? That is simple - I would like to let people in Debian BTS who are struggling from bugs that prevent them from usage of old versions of pcmanfm to get current version which is free of all those bugs. So question is - may it be possible to upload them into experimental or I have still to bother maintainers? I feel sorry to do that again. Thank you very much. Andriy. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQc9/gAAoJEJOUU0jg3ChAEBAP/ihKG+yL/GR2SY6j6sNOY1ax vyIMbB9slHGv0Bq4NM1LP+SEl0JIgaYszuNIgjaBlNzZtzf72i/2tlRCXD4/RII4 H7gSfY7HP9Yd0r3SOxiwTogoMf5w7SunWzeEJktZCaeO3EGMGInDcZAULZgLScvz duUTv/nshz7aaexQofiSeBjHSbpDl4ONAUPgNVtrIC471Srjir8j8Udt5YHi8oeR xgzpVedfXakf6rmz5KKLHNUqoKu4/jrCmVHPkGMc7s6bwnxN8jrQqgnbqu1Tf9FX QtDfjD3ZWoUBKju/FBX1PghfNBG/qanf31mQYD1cI3yAhg+i5GFTo0QGQ1swHa7j 6pvNtF7G8X3uHXaEt4MQw7O3ErNqO8lr6xD9H255EuNXxBnBhi4emMbnsmxR8lhd 3hiFJkfrlmlCTH6pVeBW+2ht5Zf/zV3upMvkGbTg/gzts5X2Hz9c0aY1FZgs9qMl y9xM6vbUv1zdBe1Dp5djnBzbp1Rpw4CAzqLoZUgno8r3J3nrqTFytWe46IY2uftc ls4Kr7TjqG1SQGotRw+3AgFmuB9onIv8GBJMRzZg+IQUohEcGzSBKHVCnaZ3sp4L o+xn+HzFJ5By0rDd7oUYbR3bAR0NPVFChS1uLPDolZP6klws5Yrr8HqRkUpawQOt vcn0fltQ1sdir/NE8AWf =mvTC -END PGP SIGNATURE- -- 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/5073dff4.2050...@debian.org
Re: exclude
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 04/10/2012 23:10, Bas van den Dikkenberg a écrit : Maybe of my package burp, Hurd-i386 and s390x keeps failing. And can't find the problem Hi, This is no reason to remove those arches from the list. It's OK to fail (unless, of course, your package takes hours to build and you upload a new version every day). You should rather file wishlist bugs against your own package and ask for help on the porters' list. Kind regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQcoWCAAoJEJOUU0jg3ChACScP/jRGJLiv9O96N4Z5xHk/kM/1 nZdr00IBmw+2rdWYyZ9vscbqR1r2F6nHOHi6vlj2Tt9IjZSd8/eFEExg05h440iX wq96i0FFk3J1a9C9h44I2da/4ATUOo9KhaggkvljVpq0a1mQBDsKLH45l2vvbchV nfdcnCcDWGKaPAjoiftdGygRhtrhRsBXCZM7TA4+/w3uyql7NW2CTt0GXJ0PcrvU nnk6QlXH86nmFqREUTgsIV3AZF+F80zkNf3b7NDHWHjj2BDF4/tx1sP3LGcrvSQ5 XDiW40EMfanssIahpdu+WzUwPg+vL6uLLWdYt89i2r0IQpt5jYnS6cPj3uMAdLXB P/gh+eQhU2wU90cz9e7BdWXW8ZA2GKcPbRV5YEm/FmYn2CIiWk4XXrXOwxqgVZ8U yqkUFVh/m3tA5x/nchwxpH36zEMzWzZGGoQ4qachMhrLJdYKGiy9pK+jNrQ57XhR i+62gAQlZ9TtMWVXS8zbNG8TIZjUVAHfhNnyYoN0ix1iutHnJXgO5/TkYSIvvJzD 15oXyn3hORPqI4TliHX6knbX+/URZfnnVakxqqmp0tP7r+zObGkU0eNgqfpXD6Y/ 9K+Vkjs89Zis8HMlObD/HbVKzCzkXcKF+cHjlRxj8GTXmTU6VqkVeo5zeRXKg7Q8 wetZutgbnLp9ks5w3CeX =ELtJ -END PGP SIGNATURE- -- 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/5072858b.5030...@debian.org
Re: exclude
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 04/10/2012 16:53, Boris Pek a écrit : Hi, How can i exclude hurd-i386 from a build Architecture: linux-any kfreebsd-any Best wishes, Boris Hi, Please note that it is usually not useful to manually exclude architectures. It should be reserved for cases where it would not make sense to port your package to the Hurd. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQbadAAAoJEJOUU0jg3ChAXkkQANnuODYbT1uE5895iLrLJvgf 5IfJBqTJ2Rt8xzdJkYzP4rT0j9qhu5VnIfF0tvtjZehF3b/9+xkJvb7bSfmOiGGh qnugVvfJixrRfTqZpFMgNK0eSMtxyWI5ckPLvyiHWg3031kBV64Znb7rHUAbrPZ4 PnlmAyPao+Lr0GuK0XlPm2DNomnywAvskO6SpaIijTr3IoqvcU2gz/vjc1rrDvBw 29aOQ1DyFrHtLA+/VjVmnaMjlRM8fcWT4h3+LCIEQUGZ53Aq8Ua2dd8FO5MKMsCN SzDRkp0i3nCRolD3bIHrmRKaG4rMEvgth60otz2uvtFDUKiq4O43iXZvDDFipjvc Q9WRFv/Vpo8lP2yU8dVqOctFnDdrVdznpxyCD7cO8xuRhWA990SMOSvRvQC8n/my uvV0M2WOiKk+0O7KtecQWVZPbv1uHmGWX1XYvu65xNp55hxxEHXbN4D3Vp02bTti JYVytRcDOiiuenzp9gPCpQbngdaTEd5E2Njl/PQngBStzwjXjGXz+xANfDLPrdIk vaoleXZjllyCyUQxvkv9PaXRr8eC/B6KjVnpYUkMZNMZiifejjpnD7wVVdhDUEK3 0flBcVwDgI45jHIu6qG4+sp2MIvU3TO8oSb1TlnD+K2WJju2cOf+MaCDy0zFw/+m xS8YhcC3evBas7vY9Fmx =+eoy -END PGP SIGNATURE- -- 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/506da740.9000...@debian.org
Re: [RC bug fix] Sponsor needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 10/08/12 23:05, Noel David Torres Taño a écrit : Hi all I need a sponsor in order to upload an updated package which resolves an RC bug. I'm quite surprised nobody has stepped in before. Bug number is #681654. Package is kstars-data-extra-tycho2 - Tycho-2 star catalog for KStars To access further information about this package, please visit the following URL: http://mentors.debian.net/package/kstars-data-extra-tycho2 Regards Noel Torres er Envite Hi, I am not a DD, so I can't sponsor you. However, you don't seem to have filled an RFS bug. Although it is not mandatory, it would help you finding a sponsor. Please read: http://wiki.debian.org/Mentors/BTS Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQJX+8AAoJEJOUU0jg3ChAzckQAKnn5H/k2HBhKx7itco2PQgk hwdOgk0WWtRQ28l3RRR+i9jWJV7fwsSuX2bn7nIeJPZYE7xW/kZ8OjQB2uipevSk TMmtwzSflqOCCaYZhG7Wvf/88mBoKuxOg9IJU+UJ39BHhEZiSCSNGv9c0BIqGr89 wlScDEOJcMiVViCNRWygpAZ2pU9RLZxu0BTm1N56tfikNQ+JHMptt0VncQJDcX8a 0WOE6lyMoIU0+xXqL597rzC6Hpwd23EqSujgp4Atb6XPmja9gD14KJUzstHJtoIp 5fGsv3tuaaP71yQzOPgge5PUrYLx8yp4V35YKXTio/aKd26JntAL4l+7Cg2w0T+z oh5HMOyMIoupRTecB0GLDAiYuE2jluVef1TQV/5qwCC3H5op/hI5uNU/VVO9Jb/O ygwIUhvaem0bX6Xp48fkRxzpWrSxDldJexVRxh7QwqJVAtjaFLjiSTPxprdb/r9n PDtBvP0RlKhQ5dBkj3aqQeY+HUijf8Z2ACZPyvII7BsqB9ci5l+GCR14yOujwGes JUw1V3hxlzhuJjehVkInfrybCXg0ts1rnXPq8At4vjvq2Coj97WKTdRHKcr5XJyE +fK+skRXaTXVuGHco24OooGVrhYj3lPMKLP+3rGmx+I9WRZIqjPUt6Fkr/EXkNeH FnCrVLWNjQyEl04N7ZEP =NCqe -END PGP SIGNATURE- -- 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/50257fbc.3090...@users.sourceforge.net
Re: how to consult who has set usertag not-fit-for-wheezy
Le 21/07/12 09:26, Bart Martens a écrit : Hello, Is there a way to consult who has set the usertag not-fit-for-wheezy for a particular RFS bug ? For normal tags like patch, upstream, moreinfo and so on, there are links to the messages sent to cont...@bugs.debian.org on the bug log, but for usertags I don't see such links. Regards, Bart Martens Yep, I've seen that too and I have no answer... -- 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/500a6665.50...@free.fr
Re: how to consult who has set usertag not-fit-for-wheezy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi again, Le 21/07/12 15:32, Damien Raude-Morvan a écrit : Le 21/07/12 09:26, Bart Martens a écrit : Is there a way to consult who has set the usertag not-fit-for-wheezy for a particular RFS bug ? You can use this : http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=not-fit-for- wheezy;users=sponsorship-reque...@packages.debian.org The question is not to list the packages with the tag set, but to know _who_ has set the tag. I am under the impression that it's not possible at the moment. I don't have time to request this feature now and to follow-up. I think it's best to always comment the bug when setting a tag by sending the mail to both control _and_ the bug report (e.g. to nnn...@.bugs.debian.org or to NN-submitter@b.d.o). Kind regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQCwk+AAoJEJOUU0jg3ChAtxcP/0C2y7w6B+GduPZsVokNmMD5 WwhmH4ycm/LNVIWe3q8c5GIVE2EH9JiCnGkgEKjBSHk/AbEPBwSabGoPlhN9QQNJ wNHrkaj+7wIiO/w1l0n8B96hp0z2aGGSXJv7j86j3xNeQRARyWkfoavlKcyFeawt svgEJR6Y+RL1Eo+Nf2AItE2jOb5VPcTjm/IsT0Hw/v8TT32+BSpxDv5miawzQcti wywWCPJB/lnjvvuWrx44Bt37/BtM7tZPVCozQhGM9wzyHHPxtB7RjDqdqiEi/eV7 ZAKNdVZp4pwMsTe5GFR2cud5C9lHbAIOdK7fgSL49YVzzQUAjbXbPp8FN/a3beDd HdnYAnzKC83+d6Cbn1CTD1eyylwk2Cr14lQY3id/BLfk4wFnthHlRs/M748C9JOx r4FrCOT67buxOv6ccPJfn1aZ86MCuYok0c9gT76AqlusRLUehHkbh6nHD9CkKh7i kc+lR6ZOq31wO21Qt/LilyY2nPaVo+y8ZrvP2gTduceKGTNsXwEi5I+VxjVArpiT AwUbn+D7AXaC7g/oKz/i8K2CE9fA92d0mSlj2RcCRmuuJV4T/TPZqopoAPi5LfYQ Q1XzkW/lwbAbI1KnKh9mWw41gDFqsfaK1H3p1t+xJGN8SU3sCBeLEIFCY6oOaWTM kmMtU3BvRZflhTSQfmqN =/NwZ -END PGP SIGNATURE- -- 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/500b093f.1090...@users.sourceforge.net
Re: Bug#681968: RFS: scscp-imcce/0.6.4+ds-1 [ITP] -- IMCCE SCSCP C Library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 21/07/12 13:38, Jerome BENOIT a écrit : Hello: On 19/07/12 16:13, Jerome BENOIT wrote: On 18/07/12 11:22, Thibaut Paumard wrote: Le 18/07/12 10:40, Jerome Benoit a écrit : I am looking for a sponsor for my package scscp-imcce [...] SCSCP stands for Symbolic Computation Software Composibility Protocol. This protocol is developed by the European project SCIEnce - Symbolic Computation Infrastructure for Europe: http://www.symbolic-computing.org/ Dear Jérôme, What about putting your package under collaborative maintenance in by the Debian Science Team? I am on my way to do so. See: http://debian-science.alioth.debian.org/debian-science-policy.html It may then be easier for you to find a sponsor within the team. I can help you with that (setting up a git repository on alioth and all) I will have an attentive look before asking. I have an account at Debian-Science. But I am confused now because it is not clear what is the next step. (The document seems very terse.) Any hint to step further is welcome. (Moving the discussion to debian-science, where it belongs). You mean to set-up the git repository? Once you have an Alioth account and you are in the debian-science group, you can ssh alioth-login@vasks.debian.org cd /git/debian-science/packages mkdir package.git cd package.git git init --bare On your local machine, you should then be able to use: git checkout git+ssh://alioth-login@git.debian.org/git/debian-science/packages/package.git or git remote add alioth git+ssh://alioth-login@git.debian.org/git/debian-science/packages/package.git Make sure the package itself follows the debian-science policy. Good luck. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQCwtKAAoJEJOUU0jg3ChACiUP/AmjAnAGU3wvVV5XmdY1EV8w s7avXkqaBo6YK46xIU83PXb3O7QRQLretMyDD77cx4NIGVZ62AFs5DTqFRQqU88s J/kmz5mwlf/BU7ZVIhjRyb9niZf22NBRUxQnkVgzy5U80PPqEV9Z4z05Ms4HqwFz uHCqKsLvVS/5nVTIJgoG9VzFZlw8yzfDGkN3t64fBTIEusjKNGZrTzHg4v8Qohtp 4V8b9wm4kF4XwoP4pC62AZjmDuCDWPTLRxUS9OOqyQNY0htH9Gc4sGORQqr7zKL7 oA54VmzrxF55MJ9JqTuXsomGyTzwj96avgB9zaF6pb5KbHTjxwUoH7zRXKM3Ouzr YVGnQuQhU3yQ1qCKYZu7/QoT/lqanQgpJx/XpTaw+0iUGr4T2DiAtl/JYDMqBNVG d+uON9V5dNNc2oSJLfJJCVdKKyHtTfD9RMn6erveE8bBQVXJX3ZkqlVzX3AAl3wT 77jeZN+EtUkc5s4bHf65CT+TiexnDqar55KDsgD84C3sTwUTBy2pikgAAZdW4XDB 8gPnCSR4LlvgY2OI5ztNnPGzhpuuyBl4JLyO9OCVSdBsOSlFAZovnFFC6kEY1c5g uUVU0N5uan6V/1Nqg3JRRHMAshV8znr8QT/LQGUORrhdcCeeNee4rZMcV8r7ulQa deCPKWaNUmz0C+Ak3ZHT =Rgh8 -END PGP SIGNATURE- -- 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/500b0b4b.3030...@users.sourceforge.net
Re: freeze policy - open requests for sponsorship
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 19/07/12 21:30, Paul Tagliamonte a écrit : On Thu, Jul 19, 2012 at 07:27:01PM +, Bart Martens wrote: On Thu, Jul 19, 2012 at 04:57:44PM +0200, Thibaut Paumard wrote: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sponsorship-requests;ordering=wheezy-bilevel http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sponsorship-requests;ordering=wheezy-view http://wiki.debian.org/Mentors/BTS#Usertags If consensus is reached (or if noone reacts negatively) I'm happy with your efforts on this. Please continue. Seconded, for sure. Thanks, Thibaut! OK, since that can be easily reverted, I have proceeded (and made some little modifications). The usual default view should be available soon at: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sponsorship-requests;ordering=standard I will vanish into VAC-air in a nearing future, it case anything goes wrong and you need to revert this change, this e-mail sent to control should suffice: user sponsorship-reque...@packages.debian.org usercategory normal * status * severity * classification thanks Everything is documented in: http://wiki.debian.org/Mentors/BTS#Usertags http://wiki.debian.org/Mentors/UserCategories Cheers, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQCUQLAAoJEJOUU0jg3ChAn5AP/j+Muu7FmnhwQJuvTS1XHHxk Rffw0QdVkfXCiNnMtbYk2eHGJUzdyx3oagfUcY6+3LWzzvuWCBmwLmV9Lw8jg59i wtTdMpgY/6nT+66AZT8qGxynQKm5xaGk4NggGOBuAe9WMuXTVsncEIPIeVlpMNx1 f/p5Vm2x3KF3bHCCpxhcQTwE6DnHL1Y3ROvdQoM9Gw7S7oQ9AQ9Mabin6nDfJEo5 pGQsq5s3D5NiyFNIdq1spc2SzU66Bmt39jFu72sCSjflgIsvhoNqAfzu37bUGR0A uCO512vdHDe+JhkF3o3TiU1fF68kB8Y04Mn3LztFvxykeAQ+etDQ5JlzU9JU6vUo s/GClzBUOM0dw7nQJsUDZinANi7EJ/PZUgw1NWFuo55EfLvhc6GltDXpbr/BDz0L aTgz8mjB3QqNC1lHdJBbp8EXLnXON17DerjytP0DErFm21+flnSlJqiZlvAKi5Zi 8DMfIEdXS7O0o5lDso/rEYeHis5TZ0qwYXSRtrLYpXC5o+Ho0F+2X4s5OcQrwXiT d7mYZFzGy7iY7aJdqYvk6oEz81PuRDza2q78jfQgsYOYLMYJsCsz+Gth79FjVaBH KeZSVE9ReOt32GyeEEByxnnpdeNwy94uYSJbHNx+P//0l7SxDlgPQ0AF14Zt0YPN HC4m2+vvpk5Kh63ko3zH =/xiS -END PGP SIGNATURE- -- 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/5009440b.3080...@users.sourceforge.net
Bug#679344: RFS: bzr-email/0.0.1~bzr58-1 [ITA] is not-fit-for-wheezy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 package sponsorship-requests user sponsorship-reque...@packages.debian.org usertags 679344 not-fit-for-wheezy thanks Hi, Now that the freeze has started, this package is not fit for wheezy. During freeze, it is generally better to upload new upstream releases to experimental instead of unstable, to allow important fixes to the wheezy version to go through unstable as usual. Please state your intention (usertag for-wheezy or not-for-wheezy) and amend your package accordingly, either abiding by the [Freeze Policy] or setting the distribution to experimental. Please see: [Freeze Policy] http://release.debian.org/wheezy/freeze_policy.html http://lists.debian.org/debian-mentors/2012/07/msg00030.html http://lists.debian.org/debian-mentors/2012/07/msg00210.html http://wiki.debian.org/Mentors/BTS#Usertags Kind regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQCVIrAAoJEJOUU0jg3ChAmHsP/0iKUJ8qgkPI65DqjPoonnsQ VWtaFqTFdoP/BLiTzFFT0dMyEVBrSObZ02wH2geMm1T2+WVZJdjpFpt6L9Kzlgcv iSS9Yfm7cwuDBsfLDomBL31K0hzrXAEfNLhkXB7AU/xHOS8JjuvFFrF3fiNICwke +xnjUcKDEcRgDqei7wnb50ldT8ChDMKHh6ifUy7k3YkpVk3smk//j6ASeNhljztG KIwyFieRIZ4YXhpkJMuQxoMFJYNWsftN2A7u/2tA2I/sZgTDjyPhHkT/sTUwEK+5 +IRczrruntvOBkccQlGuQj7U1QjVnh8fwSTtv3dO5JhGT/jPDEjR/ppqUwm5elyN Z31kO9tUKKmzpYUx5GDNBu9siu0x1K5QWSKVogFnXpAkkCfo49xuZxwLkipRANXq lHOzaGafZCsNpt2ZNshjLeYpAvQxsaQBgPDwrbQaVtgF7drfKUgDgCB7fboSiTRi Ymhwz6EuCJF9ui8XZyc/oMgyjXqozvhdErcKe859svhXD+8Gxcq5N+4L90zu4P/x NvH6v8lEWLyHtxoSXeIW74NrhRH+IC6K0m2wXC5TW1SsEgEOiCy9T/uaToqfiiEW oB/u0X3n2977RmIKb2tzCVDsBwcRd7UpKpYyAWMCbz1SZAigaHGMx437uuvpwWs/ vRjZBhGcuIuVCooJTqTZ =9UMm -END PGP SIGNATURE- -- 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/5009522c.8020...@users.sourceforge.net
Bug#679344: RFS: bzr-email/0.0.1~bzr58-1 [ITA] is not-fit-for-wheezy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 20/07/12 17:14, Satoru KURASHIKI a écrit : hi, On Fri, Jul 20, 2012 at 9:42 PM, Thibaut Paumard paum...@users.sourceforge.net wrote: package sponsorship-requests user sponsorship-reque...@packages.debian.org usertags 679344 not-fit-for-wheezy Now that the freeze has started, this package is not fit for wheezy. During freeze, it is generally better to upload new upstream releases to experimental instead of unstable, to allow important fixes to the wheezy version to go through unstable as usual. Please state your intention (usertag for-wheezy or not-for-wheezy) and amend your package accordingly, either abiding by the [Freeze Policy] or setting the distribution to experimental. I've already given up this package for wheezy, so I will delete package from mentors.d.o soon. (As you've already tagged this RFS, I will untag it and re-put on mentors after releasing wheezy.) regards, As you wish. No need to remove the not-fit-for-wheezy tag, on the contrary you could do one of the following: - close the RFS; - tag it wontfix and not-for-wheezy; - re-upload with distribution set to experimental and tag it not-for-wheezy. Kind regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQCZdLAAoJEJOUU0jg3ChAW28QAIP9B/Ruj5nndVIuaGr7ffx5 kB2pKVip7BtafM/D4LN5sC0AQLiFqLHv4HvWSln97eNn5d8iHhSolAxQv9Dl+U49 dZC4UIYS+y7JPuHS+qGbMrbIxvoXe/nJW9xFGxa/wDtIwI2DHHohjLOrCEXiOoHC fJWJeB2IX78ffVTFNcrXakHLHA5ZGKy8irI9SaK8QKVHjVIMYlPMRZWBYKVvnKtC j80TqEU5aXv+FGPq+r8cGKq5nATsCplny6yHL6etqMaY167Yu4z3DNkMZZtw/2Uy lalksg0iPZpjKKBkCdOTGPe/5f9wYGGsubU1QRuofs1sfXV8YLsk6KGnz8DZmWV+ vrUpT79V2hd7DauUwhgjlCplrB/pO1m0YWzY9FX8pf992v3NkndK6C1ooxe3ls+2 aYO8IGvLgKzBYB4Q34CSi4AzWPqcnlj3TZNRXNcfDtPiK5qNsqFxIYn5KolV5QTT c0oU/kxsdmqZf8gzWAjyK6nqSWBf8M74yddGA7D8v2NK5wpymN5Pa9vSk4cZZeGU QAFtxCvGzCRJZU2WMk3wjkWDT7756MfwCE7cpD+oW+IxdI1jW+zwtg4LUkttA301 1K7rvtVC+S4KEJZzN6EAu5kZ8eHRWIyGIEkqUN6t9GvfR36e+L351YcC7tqGqusS TEJhqI96xaB4AP2n3oOD =UwIA -END PGP SIGNATURE- -- 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/5009974c.8070...@users.sourceforge.net
Re: freeze policy - open requests for sponsorship
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 19/07/12 15:15, Thibaut Paumard a écrit : user sponsorship-reque...@packages.debian.org usercategory wheezy-status * Wheezy Status [tag=] + Intended for Wheezy [for-wheezy] + Not Intended for Wheezy [not-for-wheezy] + Fit for Wheezy [fit-for-wheezy] + Not Fit for Wheezy [not-fit-for-wheezy] + Uncategorized [] usercategory wheezy-view * status * wheezy-status * severity thanks I think this is better: user sponsorship-reque...@packages.debian.org usercategory wheezy-intention * Wheezy Status [tag=] + Intended for Wheezy [for-wheezy] + Not Intended for Wheezy [not-for-wheezy] + No Intention Stated [] usercategory wheezy-fitness * Wheezy Fitness [tag=] + Fit for Wheezy [fit-for-wheezy] + Not Fit for Wheezy [not-fit-for-wheezy] + Unreviewed for Wheezy Fitness [] usercategory wheezy-bilevel * status * wheezy-intention * wheezy-fitness * severity thanks This way, bugs are sorted 1- by status (Outstanding/Resolved), as usual; 2- then by intention (for-wheezy, not-for-wheezy, unstated); 3- then by fitness for Wheezy (fit-for-wheezy, not-fit-for-wheezy, unstated) 4- then by severity. Check it out on: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sponsorship-requests;ordering=wheezy-bilevel You can also try (from my previous experiment): http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sponsorship-requests;ordering=wheezy-view I have documented that in http://wiki.debian.org/Mentors/BTS#Usertags If consensus is reached (or if noone reacts negatively), I propose to eventually have wheezy-bilevel become the default BTS view by sending to control: user sponsorship-reque...@packages.debian.org usercategory normal * status * wheezy-intention * wheezy-fitness * severity thanks Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQCCBnAAoJEJOUU0jg3ChAnHkP/34m2fYAwMkhfvrDwJKMXchs Ij/26r6ybk34XSpUg/P2bnIjuZUj4Vp1RpcyWmuwawqU6ZMTYqfMMs5XG3oOlKNj etD9DIAHnlTrWY/Par6ptBoog2YuKZk0EF1fRPoPKYeHNYd5q6WMJL0GSYX22Rmq wScfwbBU0x2MyDQI6bX0hT3uO2s25xbZX/8GEDMb0HbsJnmpNvnc1p/IYZsJoxol bjHwqr7qCe/MI0f3hibChB65hfT35uMU6rfD4vxHJuAASr4YBqJfsyvDNjeZ9JHh 89Cg/siQEKv3iTCPAR4Li4t8ImkrkJCHwP7sfN6i4pZfISUFtTQ0Iq4Y7iaaesHS gFy43UWzFEpUXwKmqb3h2cMcqQ+T/C89zJA0ElrpDq04sepX4nk9jYETanv7i+wa TSlY/yXp0SMnQPLwEq4Acoa+6BfgJrNmTOuNqva1PWfLZcSclNPaGimkO1jIe21n XheIGdCGHVJ2c8GJ+vXVk1kHz+LyyqvWM5L/xr8FyApGKMBh6+xkeKSXRm2ADE4p Wg+qr+Gbx31Bo3rXBislmNln1Jtb0VxcBgU+DY7KHP0F0StdsUPRsSvVAZrQAsM6 u/O/AJ6PAutSoIBMxO0AxVTTtriWa+RyRlCXKW3M36WJeBMiHSMA2jiQqzGEIqOA rJ/IUxzeof8w1w/sukld =Dkhc -END PGP SIGNATURE- -- 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/50082068.6080...@users.sourceforge.net
Bug#681968: RFS: scscp-imcce/0.6.4+ds-1 [ITP] -- IMCCE SCSCP C Library
Le 18/07/12 10:40, Jerome Benoit a écrit : Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package scscp-imcce [...] SCSCP stands for Symbolic Computation Software Composibility Protocol. This protocol is developed by the European project SCIEnce - Symbolic Computation Infrastructure for Europe: http://www.symbolic-computing.org/ Dear Jérôme, What about putting your package under collaborative maintenance in by the Debian Science Team? See: http://debian-science.alioth.debian.org/debian-science-policy.html It may then be easier for you to find a sponsor within the team. I can help you with that (setting up a git repository on alioth and all) but I can't sponsor you (yet). Regards, Thibaut. -- 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/50068053.1010...@free.fr
Re: freeze policy - open requests for sponsorship
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 16/07/12 11:05, Thibaut Paumard a écrit : Le 03/07/12 08:20, Thibaut Paumard a écrit : Le 03/07/12 01:41, Adam Borowski a écrit : Hi, We could agree on a usertag then, for instance: User: sponsorship-reque...@packages.debian.org Usertags: not-for-wheezy Using sponsorship-reque...@packages.debian.org as the User, we should be able to rearrange the default view of bugs.debian.org/sponsorship-requests to have the for-wheezy bugs on top (subclassified by severity) followed by the not-for-wheezy bugs. cf. http://wiki.debian.org/bugs.debian.org/usertags Hi, (For the record, IANADD... yet) I was about to triage some bugs with these two usertags (for-wheezy and not-for-wheezy), but I realized it is impossible to do without the assent from the submitter. Actually, I have read the first 10 RFSes or so, and if I could, I would not upload any of them because they are not fit for wheezy and they don't state whether they are aiming for wheezy. Hi again, I propose two _additional_ tags that could be set independently from the maintainer: fit-for-wheezy and not-fit-for wheezy. Those two would be used to show that the package has been reviewed and is/is not fit for wheezy. For instance if I review a package and it does too much modifications, I tag it not-fit-for-wheezy. The maintainer has then two basic options: - revert the useless changes, remove the not-fit-for-wheezy tag and add the for-wheezy tag; - tag the package not-for-wheezy and/or set distribution to experimental. Unless there are objections, I will start setting the (not-)fit-for-wheezy usertags tomorrow. Reminder: this is to help our sponsors, I can't sponsor myself. If you don't like the idea, please say so. Kind regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQBqyTAAoJEJOUU0jg3ChAcrQP/A6e0HjgCeX5wKo9Jic3NBJg EBm/hyYA8upempwqZj3gQGsFqWPTh67SB1WpAK7kZvVDYfDvmGsTol14V7PBDnLy RqNMMDOU1xPj92eSf3B/nXZaQp0T8r9Jq8iZz0aObraIVgTvhjAzC5u5I+Gur8v7 zpzHr6YVfuvcrLOfBQ1haE0R3+5gHDEPn57lVz6iijPihsth/WdC5acsVbu7ogjk oNPkC8B0S8/W7LLCCybW5Ffq/ApMTP//mqzbS2IClP7HGB7TF73pIkw90j33PiH/ uQsVSDsgcMJrR4HJvSbR0zXfFTnD0a3p3H4e3vROrxIQ/B0koxtGmAGQWfHJlb+5 6UgPTCGuj2UhsUfKrGqqVxmGy7JXtHmIVSzw2tUZrg11BwXXWmZnXxVJUg3foukK 1/XmQNb1sZrxpcFT4EJl7V/f9fPxBBL2r3eayZGIh4CHy7RX1NfDst4EUnZQATdD Mu9q7EJFIQTuaQ2Ml3xaiM2ftOWOWRYvllQGb47VUMH83/R/Xp0WG6gxWnzNIZTa 2REUe2n7tS/tgJIH3tBYdKv/M7peF9T6HxOLE7bwwtkAIl1t5OMgxMvwSHxFgw1t qH62AJh+5g3fGgCReBM+XGVSwKojnUSCYcUYDoEtRumbCNbIX/sdSR1Y5jTRyiJn YrMiZ5X57azs5qaapAMG =x6tG -END PGP SIGNATURE- -- 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/5006ac94.6090...@users.sourceforge.net
Re: freeze policy - open requests for sponsorship
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 18/07/12 15:42, Paul Tagliamonte a écrit : On Wed, Jul 18, 2012 at 02:31:16PM +0200, Thibaut Paumard wrote: Le 16/07/12 11:05, Thibaut Paumard a écrit : Le 03/07/12 08:20, Thibaut Paumard a écrit : Le 03/07/12 01:41, Adam Borowski a écrit : Hi, We could agree on a usertag then, for instance: User: sponsorship-reque...@packages.debian.org Usertags: not-for-wheezy Using sponsorship-reque...@packages.debian.org as the User, we should be able to rearrange the default view of bugs.debian.org/sponsorship-requests to have the for-wheezy bugs on top (subclassified by severity) followed by the not-for-wheezy bugs. Hi again, I propose two _additional_ tags that could be set independently from the maintainer: fit-for-wheezy and not-fit-for wheezy. Those two would be used to show that the package has been reviewed and is/is not fit for wheezy. This would be (to me anyway) be very useful. -- if you wouldn't mind using debian-mentors@lists.debian.org as the user, that'd be awesome. barring considered and correct objection, of course. Hi, I think sponsorship-reque...@packages.debian.org is better because, as I understand it, this would allow to show those tags by default and even to organize the bug list according to those tags. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQBwnfAAoJEJOUU0jg3ChAS1wP/1JfpXLw8f38an2hQHXagkoR lR/UFkCP/yVBqBy12z2hAjkhTMrBc1JIDaYjU4UNCtO0emGSR9v4t4CEe45cqeXe ITLtd/x3OPZxpYWNM/DXgGXyJksvoSy2I6UtP1v1a7GglFOpyHtAruXT5WqVGzor yyUSYbShb2+PD07LedW2klr+hvKe9CjCd0Is4pOONJ0KzN1yRtOXYPkvh2BiZkGj t0pQgksoIk7xLsIXKtGWfm9SVCnb73WQEbNv2F/cutv4XaeHZuOKUbU25+RYX9vq mZ3ri19hpSALMUU9JxqKI9H9Y1glMJA5nDRWyML8K9FwXfQG76Z3k5jeLcZMXSE6 L+Ch+XiE7JZlEAP/NY0+otKP51jKd64WlpOF3S0dS4vzSqeV5wLAz8YCiJMJShRv yQ+ON1d1s5rv7dOcB91W17dLRkbgU7iqefkWkohe4MXGDzohKJUgNHuwxeXVM52n Hgjzl7+OYe2IpcMzHT6VSZBgUkEWR/XUZfLvNzO/+dOsWKEG5SEJAq3F0kfXzHij Aj+AzovO2++ZGGfIGHc6EKcsXgGYUwenmJtnWIuM/Awu8HLHxvGyEPXTwsjIKQNn ebBKxS7/6sqsZ77bZ5InlXhO1OXgo96ygOXuhvXBfC730A7usmsMPXDzlSVAHeUa kwAoAnNPWrj5QeyuM0qh =7LGD -END PGP SIGNATURE- -- 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/500709e0.2070...@users.sourceforge.net
Re: freeze policy - open requests for sponsorship
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 03/07/12 08:20, Thibaut Paumard a écrit : Le 03/07/12 01:41, Adam Borowski a écrit : Hi, We could agree on a usertag then, for instance: User: sponsorship-reque...@packages.debian.org Usertags: not-for-wheezy Using sponsorship-reque...@packages.debian.org as the User, we should be able to rearrange the default view of bugs.debian.org/sponsorship-requests to have the for-wheezy bugs on top (subclassified by severity) followed by the not-for-wheezy bugs. cf. http://wiki.debian.org/bugs.debian.org/usertags Hi, (For the record, IANADD... yet) I was about to triage some bugs with these two usertags (for-wheezy and not-for-wheezy), but I realized it is impossible to do without the assent from the submitter. Actually, I have read the first 10 RFSes or so, and if I could, I would not upload any of them because they are not fit for wheezy and they don't state whether they are aiming for wheezy. So, dear prospective sponsees, although I am not yet in a position to sponsor you, I think I'm not wrong in telling you that: do yourself a favour and _tell_ in your bugreport whether or not you are targeting wheezy. One proposed way to do that is to set the usertag for-wheezy or not-for-wheezy with user sponsorship-reque...@packages.debian.org. Since no bug have yet been thus tagged, you need to also spell it out in your bugreport. Uploads targeted for Wheezy should fix bug of severity important or above, and the severity of your RFS should match the highest severity of the bugs you are fixing (so a RFS targeted at wheezy should be of severity important or more). If your RFS does NOT target wheezy: - you can do whatever changes to your package, but you should almost certainly set the distribution to experimental. This will help you get important fixes to Wheezy should this prove necessary later on. This does not apply to packages which are not in Wheezy anyway. If you DO target Wheezy: - say so in your bugreport - keep your changes minimal - fix only important bugs (RC bugs, release goals) - set the severity of the RFS accordingly - for fixes involving a library transition, get it pre-approved by the release team - it will always help if you get your upload pre-approved by the release team A few things that you should not do if you want your package to reach wheezy: - update to a new upstream release - change from dh to cdbs or other - rewrite your rules file from scratch - rewrite your copyright file from scratch or convert it to 1.0 machine readable format - ... All those things are likely to be rejected by the release team, so you will need to revert them and reupload. New upstream is the worst: it would force you to reupload to testing-proposed-updates instead of unstable, and the release team may not allow you to if they don't think your changes are worth the risk. Kind regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQA9lzAAoJEJOUU0jg3ChAxnwQANSCPgh2qUXc//RDJHOiUQ++ YUhmXfYOyNl/oTWXhZQIfv6mDudQZl41IJyCYYJRyz2wIjjwf5pdAivbPCbMK0vM WwEW7J+eGzxdKnsuzhb9rhEsav89sWRO/iom/zrhRXyLCZ46OZRINEguxAmhrhc0 n3Djx/MoISqPf3zcCjlVrUj/3FjRzt8UPkSrqkD72ZyG5T+R6QcpEq07cAPL7D0D vtSn/Oa4X2Ac6TqcI9eUMqZjK+IDqrbsKA1g0OeCfhx480+OkCbNclL6spZGWVfx jGiDq+q+aWojPzvsteAuIPv2X2qrgY4bgCKOygUm9Soj2DgaGb7K27TGdFI+wbyD InMikjSxV6PJ2SC2Kd03LmjkkatZtJFW/mz9CgOPEj+VO6uXB/wkHYeQuBRdqEaU ySoUmwQpzqVAKgRW9nfKnWvrcmFIVVDbPYcc9YpDhM6mnCpksfA3vUi02sVxHO1I 38GZbcf4Is/Pg+nkM2FZJcP6TWcZ03RvvReP/MQQnLZtZTggt0nh34wDCRgj5DL0 U0Qkm6wYLDRmYYs5ePr0kbTMDgT/1dX8eso2QgdTjmSMSj6BDnS7VdezUT6Hiuhl FJOpjURiZHw5FRVDBAKhwDlwN3V8SnV3TV8DkgAVVWZemfY5kEZUgZt76YAo3EY9 zgWDJAktqm11M5K7RuzV =RHS2 -END PGP SIGNATURE- -- 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/5003d974.4000...@users.sourceforge.net
Re: nbc package has been removed from Mentors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 16/07/12 11:17, Slavko a écrit : Dear mentors, Dňa Sun, 15 Jul 2012 09:54:17 + (UTC) mentors.debian.net supp...@mentors.debian.net napísal: Your package nbc all versions has been removed from mentors.debian.net for the following reason: Your package found no sponsor for 20 weeks I was patient with my package, but i was no success to find the sponsor. Please, what did i wrong? Or, please, what i must do better? Need i upload it again? Or something other? Or i need to suppose, that this package is not interested for Debian people and do not waste the sponsor's and my time with it, please? thanks Dear Slavko, It's not easy to get a sponsor, especially during a freeze (please read my previous message from 15min ago entitled Re: freeze policy - open requests for sponsorship). Don't give up, re-upload and try to send your RFS to maintainers (team or other) who you think should be interested (not only to debian-mentors). When I'm looking for a sponsor, I personally answer my own RFS with a [ping] message every month or so, just to show I'm still there, waiting for a sponsor. Concerning your RFS: you should perhaps explain why you think nbc is good for Debian, whether you intend on maintaining it on the longer run (think 5-10 years) and why... In the meantime you can upload your package on a personal repository (have a look at the reprepro package) and try building a userbase outside Debian. Reading the ITP, I see you already have a prospective user, contact him. Regards,Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQA986AAoJEJOUU0jg3ChA1rAP/2EWacXzO5ao0Rp4qpK++HDm 8AHFKQL/7kV96oFD5x8XrfPkijEfld4DLmm5f4ZIoKDji8H1jULL8nsIiaQEoX58 nk7oLi/J5zZq4q4PRCEWFdwOhDqGPSoxuSXdWxCe40A9YBNCt8cgrhV/HN20CIhl RHXq0dKEH0VySr9LVwND4xKdShhkHMZsyQLiEK0C8dpjtnnSQSPfHKBMxkTW0YKh 2sfF08HrQxNq1BxQLumJCAWI9HAGA312NGs8Q6rrbS01tIR2sbq3xq/Wpmx7LAFI SGvAs42tOzj6YwXB8q+3EL3HfKH1yzSX54EZlK+wL01fG9pXbg4glc2ctMO3IgvX iX6pd39Df4+wf8jRJyUS53YrQehFvIGffcamvALdUQc+ZKIxk1M+4Wl803gCSeBc WWRaJcNKqw1rTze4cEo5EXI2zJWGDMT8Y//3ExTp2j25FUjnh8ijSn39eV5vtWOA dLFJMqzeFOKy8Zu/BbW4mDnIhbYRd9mPt1X9qBr5d1H6FYd0+zpveptQAIYHV6fV BC5sRn83RXO721jf7OCP8LeC6tKgIf+RTy3pAxONtqH800ej3vJvM2eFQ2zpWqLa RbRk8Je6mW4vUMAfeMW69Gkv0Wbt4iajf771NvOaT/PuYZvs+7yZFykatYdTldlj TBZYVFPa7cYiTqc4OK6v =Tc3l -END PGP SIGNATURE- -- 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/5003df3b.2090...@users.sourceforge.net
Re: nbc package has been removed from Mentors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi again Slavko, Le 16/07/12 11:58, Slavko a écrit : Don't give up, re-upload and try to send your RFS to maintainers (team or other) who you think should be interested (not only to debian-mentors). When I'm looking for a sponsor, I personally answer my own RFS with a [ping] message every month or so, just to show I'm still there, waiting for a sponsor. I tried post to electronics team, but without any reply. I am confused with these pings now - after the sponsorship-request pseudo package was introduced (and RFS bugreports) i understand, that there are no pings needed. You're right, that why I'm not saying you should send them. It may be considered harassment by some sponsors, I don't know. I still send ~monthly pings, and each time try to rephrase why I think it's good to have the package and I try to send it to other people who may want to sponsor it. Another confusion is about the existing RFS bugreport now. It will be closed and new one must be created? Or after new upload i will only need to post reply to existing bug? Is this somewhere documented, please? There is no reason why it would be closed automatically, just answer it. IF it is closed, reopen it. IF it is retitled, retitle it back. In short, as long as your reasonable and don't spam people, it's OK to insist. Being stubborn is not a bad thing :-) Put your heart into it, document in your RFS the fact that you have been effectively maintaining the package for three years already... Also, move on: take care of other packages, find a good sponsor to whom you can then personally ask to review nbc. Enter the NM process, become a DD and then you can finally upload it yourself if everything else fails... Kind regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQBAmJAAoJEJOUU0jg3ChAxLMQANjCzhURYhylUonT8GY/FNZf jN0pj3VSpv92K5iZx5aGhdCHH4EH1tzcMN9gnOmJMK6KCZYl32CcB/0QbdcUWKhz azL+Uf43y+kanCLup5vwv3+BMZMnIQX8lxarotfazZNT9Ux0ouG5PIynQ2o36pLN JuBzPgdSNi4bFXiQocM+YFj7W77jzbCdy4Q83J2WV9JC6HhTyzspnPFQVsf46uZs ATbVSYvZv+DXzbNYtb+WLdjKymEUVbOa+Z9fTPER4KMn3Kw6f139i1nfbWlPuDMD wPVPtQzv+M0Q68YnNrgaOpJJxrOUS64cbbcX3NXWyd9vd+3uXePQdfW88m2HSh0y Xqu8PHkpgiBv72+RqQRAWq53Sr64XuQfs2jGLHTItl6VPaoXGHcbObnOSZgiWKOy pxVxYjWPwDmzHlq+IL8hKod0dHfYJk5H1h5gue1rFmC4+8y1J9ZDy7ko7X6r4IgH AstDzIYsQXHuXZhClEBj2W73+YnEsUhRlJeOtAsE6COtJqhj21P+BnjeXUVNwTMm jBPFQ48QdmEcEqEnxfuSEWgSJOsZMswxlrZ2adyrciUWMXtIYje8PGT1J4b/GgYN KNbJ0j0309o50o+UlE8hG2t9UVPFZ4McaF/uEb02mAW+aBbrTIKzgbHYKPexilM1 /sJEUnPNq5alNx4CiLEX =sqCx -END PGP SIGNATURE- -- 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/50040989.7030...@users.sourceforge.net
Re: freeze policy - open requests for sponsorship
Le 03/07/12 01:41, Adam Borowski a écrit : On Mon, Jul 02, 2012 at 09:06:25AM -0600, Paul Wise wrote: Perhaps use wheezy-ignore for stuff that shouldn't be in wheezy? Isn't that completely contrary to that tag's usual meaning? You set it for stuff that should be in wheezy despite the bug. What we'd want here, is some way to convey do not waste your time messing with this bug if you care only about the next stable release. This includes unstable-only packages like gcc-snapshot. Hi, We could agree on a usertag then, for instance: User: sponsorship-reque...@packages.debian.org Usertags: not-for-wheezy Using sponsorship-reque...@packages.debian.org as the User, we should be able to rearrange the default view of bugs.debian.org/sponsorship-requests to have the for-wheezy bugs on top (subclassified by severity) followed by the not-for-wheezy bugs. cf. http://wiki.debian.org/bugs.debian.org/usertags Regards, Thibaut. -- 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/4ff28f24.8010...@free.fr
Bug#679509: RFS: yorick-av/0.0.1-2 [Release goal: hardening]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package yorick-av. This upload fixes issues with the hardening flags, a Wheezy release goal: http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags In addition, this upload puts yorick-av in compliance with the debian-science team like the rest of the Yorick packages. * Package name: yorick-av Version : 0.0.1-2 Upstream Author : Thibaut Paumard paum...@users.sourceforge.net * URL : http://paumard.github.com/yorick-av/ * License : permissive Section : science It builds those binary packages: yorick-av - write movies from Yorick in various formats To access further information about this package, please visit the following URL: http://mentors.debian.net/package/yorick-av Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/y/yorick-av/yorick- av_0.0.1-2.dsc yorick-av is also available from Alioth: Vcs-Git: git://git.debian.org/git/debian-science/packages/yorick-av.git Vcs-Browser: http://git.debian.org/?p=debian-science/packages/yorick-av.git Changes since the last upload: * Move to maintenance to the debian-science team. Update debian/control to comply with their policy: + change Maintainer, put self in Uploaders; + DM-Upload-Allowed: yes; + fill-in Vcs-* fields; + Priority is extra. * Fix machine-readable copyright format. * Add lintian override about no fortified functions. * Fortify (don't rely on yorick to pass the right build flags) Note the lintian warning remains. Yet you will see the correct flags during build. Regards, Thibaut Paumard -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20120629093655.4117.41016.reportbug@localhost.localdomain
Bug#679512: RFS: yorick-mpeg/0.1-2 [Release goal: hardening]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package yorick-mpeg. This upload fixes issues with the hardening flags, a Wheezy release goal (in addition to complying with the debian-science policy). * Package name: yorick-mpeg Version : 0.1-2 Upstream Author : Dave Munro * URL : https://github.com/dhmunro/yorick-mpeg * License : BSD Section : science It builds those binary packages: yorick-mpeg - MPEG output support for the Yorick language To access further information about this package, please visit the following URL: http://mentors.debian.net/package/yorick-mpeg Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/y/yorick-mpeg/yorick- mpeg_0.1-2.dsc The package is also available on Alioth: Vcs-Git: git://git.debian.org/git/debian-science/packages/yorick-mpeg.git Vcs-Browser: http://git.debian.org/?p=debian-science/packages/yorick-mpeg.git To test the installed package: $ yorick Copyright (c) 2005. The Regents of the University of California. All rights reserved. Yorick 2.2.02 ready. For help type 'help' #include mpgtest.i mpgtest 200.00 frames of filled surface drumhead completed in 10.763189 sec Rate for filled mesh is 64.096504 frames/(CPU sec), 18.581681 frames(wall sec) quit $ mplayer test.mpg Changes since the last upload: * Move to maintenance to the debian-science team. Update debian/control to comply with their policy: + change Maintainer, put self in Uploaders; + DM-Upload-Allowed: yes; + fill-in Vcs-* fields; + Priority is extra. * Configure in a patch rather than running yorick -batch make.i at build time which may cause unpatch to fail because it's not a good idea to modify the same file (Makefile) both at patch-time and build-time. * Fix machine readable copyright format * Remove dh-make template header from rules * Suggest yorick-av * Simplfiy debian/rules with short dh notation * Fortify (don't rely on yorick to provide right flags) Regards, Thibaut Paumard -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20120629095341.5127.56756.reportbug@localhost.localdomain
Bug#669016: Two astronomy-related RFSes up for sponsoring (since 2 months)
Hi, I have sent these two RFS a little bit more than two months ago. I have put a lot of effort into them (for instance I've worked with upstream to fix bugs in yp-svipc and port it to Python 3) and I'd be sorry if they missed Wheezy for lack of a sponsor. yp-svipc: System V InterProcess Communication ITP: http://bugs.debian.org/668841 RFS: http://bugs.debian.org/669209 http://mentors.debian.net/package/yp-svipc This package builds plug-ins for the Python and Yorick interpreter to expose the SysV IPC to interpreted code. This permits building parallel codes and sharing memory segments between processes. The Yorick plug-in can be used by [YAO], an adaptive optics simulator, to make faster computations thanks to parallelisation. The combination of the two plug-ins allows building mixed Python/Yorick applications. [YAO] http://packages.debian.org/wheezy/yorick-yao gyoto: General relativistic geodesic integration and ray-tracing ITP: http://bugs.debian.org/640809 RFS: http://bugs.debian.org/669016 http://mentors.debian.net/package/gyoto Gyoto allows computing trajectories (e.g. of stars) and ray-tracing images in the vicinity of compact objects such as black holes. It is usable as a C++ library, a stand-alone utility executable, and a Yorick plug-in. I'd be really, really grateful if someone from the community would have a look. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Force rebuild of only 1 arch
Le 22/06/12 10:36, Bas van den Dikkenberg a écrit : Is there way to force a failed build to retry ? Yes there is: http://release.debian.org/wanna-build.txt or otherwise http://www.google.fr/search?q=debian+rebuild+request Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
[PING] Re: Bug#669209: RFS: yp-svipc/0.13-1 [ITP] -- System V InterProcess Communication for Python/Yorick
Hi guys, it's been two months since I initially posted this RFS, and the release is getting nearer... Regards, Thibaut. Le 26/05/12 11:05, Thibaut Paumard a écrit : Le 08/05/12 09:43, Thibaut Paumard a écrit : Hi guys, I'd love it if someone could have a look at this package: http://mentors.debian.net/package/yp-svipc dget -x http://mentors.debian.net/debian/pool/main/y/yp-svipc/yp-svipc_0.14-1.dsc It gives access to the system V interprocess communication mechanisms to the [1]yorick and python (2-3) interpreters. With this mechanisms, it becomes possible to do multi-process parallel scripting and to develop mixed yorick/python applications. [1] http://packages.debian.org/sid/yorick The Yorick plug-in can optionally be used for faster computations by YAO, a scientific software already in Debian: http://packages.debian.org/sid/yorick-yao Since the initial ITP, I've worked with upstream to port the software to python 3 and to fix a couple of bugs. Best regards, Thibaut. Le 18/04/12 09:32, Thibaut Paumard a écrit : Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-pyt...@lists.debian.org Dear mentors, I am looking for a sponsor for my package yp-svipc * Package name: yp-svipc Version : 0.13-1 Upstream Author : Matthieu Bec * URL : https://github.com/frigaut/yorick-svipc/ * License : GPL-3 Section : Python, Science Programming Lang: C, Yorick, Python Description : System V InterProcess Communication for Python/Yorick ITP : http://bugs.debian.org/668841 It builds those binary packages: python-svipc - interprocess communication (shared memory...) for Python yorick-svipc - interprocess communication (shared memory...) for Yorick To access further information about this package, please visit the following URL: http://mentors.debian.net/package/yp-svipc Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/y/yp-svipc/yp-svipc_0.13-1.dsc When the two packages are installed, they can be tested with: - yorick-only multiprocess computing: yorick -i /usr/share/doc/yorick-svipc/examples/timing-demo.i - yorick/python communication: yorick -i /usr/share/doc/yorick-svipc/examples/ping.i I have not been able to make it work under python3 so far (on Linux: it works on a Mac). Regards, Thibaut Paumard. signature.asc Description: OpenPGP digital signature
Re: Bug#669016: RFS: gyoto/0.0.1-1 [ITP] -- general relativistic ray-tracing and orbit computation
Hi,
Could someone have a look at this 2-month-old RFS?
Kind regards, Thibaut.
Le 19/04/12 11:35, Thibaut Paumard a écrit :
Hi,
I've updated the package which now installs the headers in a
subdirectory of /usr/include:
http://mentors.debian.net/package/gyoto
http://mentors.debian.net/debian/pool/main/g/gyoto/gyoto_0.0.2-1.dsc
Regards, Thibaut.
Le 16/04/12 17:10, Thibaut Paumard a écrit :
Package: sponsorship-requests
Severity: wishlist
Dear mentors,
I am looking for a sponsor for my package gyoto
* Package name: gyoto
Version : 0.0.1-1
Upstream Author : Frédéric Vincent myself
* URL : http://gyoto.obspm.fr
* License : GPL-3+
Section : science
Gyoto aims at providing a framework for computing orbits and ray-traced
images
in General relativity. It consists in a shared library (libgyoto0), utility
programs (in the gyoto package), and a plug-in for the Yorick programing
language (in yorick-gyoto). Gyoto can be extended with plug-ins (see
libgyoto0-dev).
The source package builds those binary packages:
gyoto - General relativistic ray-tracing
gyoto-dbg - debugging symbols for gyoto, libgyoto0 and yorick-gyoto
gyoto-doc - documentation for the Gyoto library
libgyoto0 - General relativistic geodesic integration and ray-tracing
libgyoto0-dev - development files for libgyoto
yorick-gyoto - General relativistic geodesic integration for the Yorick
language
To access further information about this package, please visit the following
URL:
http://mentors.debian.net/package/gyoto
Alternatively, one can download the package with dget using this command:
dget -x http://mentors.debian.net/debian/pool/main/g/gyoto/gyoto_0.0.1-1.dsc
Once installed, the packages can be tested as follows (a test suite is
already
ran during build):
- gyoto package:
Compute the example sceneries with
for file in /usr/share/doc/gyoto/examples/example-*.xml; do gyoto ${file}
`basename ${file%xml}fits`; done
The two *rotstar* example file won't run, they depend on the option al plug-
in lorene which is not compiled. The other files should produce FITS image
files which you can visualize using e.g. spydr from the yorick-spydr package
or
simply with the gimp :
spydr *.fits
- yorick-gyoto package:
You can first run gyotoy:
gyotoy
You should see a plot representing the orbit of a star around a black hole.
You
can play with the
projection, the initial parameters etc.
Then you can run the test suite:
ln -s /usr/share/doc/gyoto/ doc
cp -R /usr/share/doc/yorick-gyoto/examples ./
cd examples
gunzip *.gz
yorick -batch check.i
Best regards, Thibaut.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-2-686-pae (SMP w/1 CPU core)
signature.asc
Description: OpenPGP digital signature
Bug#669209: [PING] Re: Bug#669209: RFS: yp-svipc/0.13-1 [ITP] -- System V InterProcess Communication for Python/Yorick
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 08/05/12 09:43, Thibaut Paumard a écrit : Hi guys, I'd love it if someone could have a look at this package: http://mentors.debian.net/package/yp-svipc It gives access to the system V interprocess communication mechanisms to the [1]yorick and python (2-3) interpreters. With this mechanisms, it becomes possible to do multi-process parallel scripting and to develop mixed yorick/python applications. [1] http://packages.debian.org/sid/yorick The Yorick plug-in can optionally be used for faster computations by YAO, a scientific software already in Debian: http://packages.debian.org/sid/yorick-yao Since the initial ITP, I've worked with upstream to port the software to python 3 and to fix a couple of bugs. Best regards, Thibaut. Le 18/04/12 09:32, Thibaut Paumard a écrit : Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-pyt...@lists.debian.org Dear mentors, I am looking for a sponsor for my package yp-svipc * Package name: yp-svipc Version : 0.13-1 Upstream Author : Matthieu Bec * URL : https://github.com/frigaut/yorick-svipc/ * License : GPL-3 Section : Python, Science Programming Lang: C, Yorick, Python Description : System V InterProcess Communication for Python/Yorick ITP : http://bugs.debian.org/668841 It builds those binary packages: python-svipc - interprocess communication (shared memory...) for Python yorick-svipc - interprocess communication (shared memory...) for Yorick To access further information about this package, please visit the following URL: http://mentors.debian.net/package/yp-svipc Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/y/yp-svipc/yp-svipc_0.13-1.dsc When the two packages are installed, they can be tested with: - yorick-only multiprocess computing: yorick -i /usr/share/doc/yorick-svipc/examples/timing-demo.i - yorick/python communication: yorick -i /usr/share/doc/yorick-svipc/examples/ping.i I have not been able to make it work under python3 so far (on Linux: it works on a Mac). Regards, Thibaut Paumard. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/AnMkACgkQ+37NkUuUiPEUEwCeOgy3haAZrTD1hNjm93XkcjNx zzkAn1yoC/ADr3FFbuK0HaFVSoaNKobf =aA/0 -END PGP SIGNATURE- -- 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/4fc09cc9.8050...@users.sourceforge.net
Bug#674564: RFS: gimp-gap/2.6.0+dfsg-3 [RC]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package gimp-gap * Package name: gimp-gap Version : 2.6.0+dfsg-3 Upstream Author : Wolfgang Hofer h...@gimp.org Sven Neumann s...@gimp.org * URL : http://www.gimp.org/tutorials/Using_GAP/ * License : GPL-2+ Section : graphics It builds those binary packages: gimp-gap - animation package for the GIMP To access further information about this package, please visit the following URL: http://mentors.debian.net/package/gimp-gap Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/g/gimp-gap/gimp-gap_2.6.0+dfsg-3.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: * fix FTBFS: http://bugs.debian.org/674393 * add homepage control field * bump standards Regards, Thibaut Paumard signature.asc Description: OpenPGP digital signature
Re: SONAME best practice
Le 15/05/12 11:26, Daniel Pocock a écrit : I agree that this is valid and that these libs/pkgs can co-exist My preference would be for the soname libmusicbrainz.so.5, is there any outright reason to avoid the other way of doing it, or it is largely at the discretion of upstream in each case? Upstream are free to do whatever they see fit (and Debian is free to override it whenever *necessary*). As upstream, it's not easy to guess what will more manageable in the longer run and what really matters is that ABI changes end-up in SONAME changes. If those changes are funky... sort of breaks the monotony of a rainy day :-) Regards, Thibaut. -- 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/4fb225c1.6090...@free.fr
Re: Changing SONAME in library version
Le 14/05/12 11:15, Olе Streicher a écrit : Dear mentors, could someone give me a hint on how to proceed here? Dear Ole, The release team will answer your [request] soon and let you know whether it's OK to transition your packages. In the meantime you could upload them to experimental to see whether they compile and run fine. [request] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671853 As a matter of fact, the new release of CPL fails to build on most architectures! This is the reason for all the out of date excuses. In addition, the package was [reported] to be uninstallable: [reported] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671675 You have two options: - work on the current release to get a decent version of DS9 in wheezy, if not the most recent; - work on the transition, but it will be a lot of work and you are likely to miss wheezy. One option is to do both: - push the working version of your packages in sid (depending on CPL 5.3). - push the next generation (depending on CPL 6.0) in experimental. - work on the build failures and on 671675 in experimental. - explain this plan to the release team. If they are OK, all you will have to do once the next generation is really ready in experimental is ask them (the release team) to migrate the whole to unstable and, eventually, testing. To work on the build failures, you will need to: - read the build [logs]; - ask for a [guest] account on the portboxes. [logs] https://buildd.debian.org/status/package.php?p=cpl [guest] http://dsa.debian.org/doc/guest-account/ Best regards, Thibaut. -- 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/4fb0f733.3060...@free.fr
Re: Changing SONAME in library version
Le 14/05/12 15:06, Olе Streicher a écrit : To work on the build failures, you will need to: - read the build [logs]; - ask for a [guest] account on the portboxes. [logs] https://buildd.debian.org/status/package.php?p=cpl [guest] http://dsa.debian.org/doc/guest-account/ Since I am still a Newbee, I would need a sponsor to do so. Would you like, and are you already able to sponsor a guest account for me? I would like to, but I can't. Regards, Thibaut. -- 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/4fb1047f.3060...@free.fr
Re: Changing SONAME in library version
Le 14/05/12 15:06, Olе Streicher a écrit : Some of the out-of-date excuses, however, result from the SONAME change (libcplcore12 -- libcplcore20), and I don't know hoe to handle them. As part of the transition, libcpl*12 will be removed from the archive, which will suppress this excuse (so don't worry for that yet). However, I don't get the deal will libcext-dev: why is it still at 5.3.1 whereas libcext0 has been updated to 0.6? Regards, Thibaut. -- 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/4fb1154a.8070...@free.fr
Re: Changing SONAME in library version
Le 14/05/12 16:31, Olе Streicher a écrit : Hi Thibaut, Hi Ole, Thibaut Paumard mlotpot.n...@free.fr writes: Le 14/05/12 15:06, Olе Streicher a écrit : Some of the out-of-date excuses, however, result from the SONAME change (libcplcore12 -- libcplcore20), and I don't know hoe to handle them. As part of the transition, libcpl*12 will be removed from the archive, which will suppress this excuse (so don't worry for that yet). Can't I remove them myself (together with the old esorex and python-cpl versions) when they all are in unstable? Actually the removal from SID should occur automatically: http://wiki.debian.org/ftpmaster_Removals But the removal from testing is part of the transition and managed by the release team. In any case, the package won't migrate until you have resolved the FTBFS: that's the real problem at hand. However, I don't get the deal will libcext-dev: why is it still at 5.3.1 whereas libcext0 has been updated to 0.6? The cause for the RC bug is just that I accidently removed the libcext-dev section from the debian/control file. Simply re-inserting does the job (already done in the git repository; not uploaded yet because of the unresolved FTBS). You should include this information in the bug report and tag it pending. Regards, Thibaut. -- 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/4fb14b23.3040...@free.fr
Re: (un)patching patched files
Hi Ole, Le 10/05/12 13:18, Olе Streicher a écrit : Gergely Nagy alger...@balabit.hu writes: The patch in debian/patches will be large, possibly complicated and whatnot, but you can explain how it is created in debian/README.source, and live happily ever after. There are cases where a bit of ugliness is acceptable. This is one such case. I still do not see what one would gain with this compared to the debian/rules based solution. In principle, I would just need a target that is applied just before dpkg--after-build is called. If you use a patch system, you should use it to do the patching: it's just more consistent and much clearer for your fellow developers who will look after your package should a NMU ever be necessary or to help porting to other architectures for instance. Do yourself a favour and just use a patch to patch whatever has to be patched. I have the same problem in another package: here, an executable is going to be renamed, and therefore also the manpage. Additionally, the manpage needs a patch. Since the manpage is renamed, unpatching it after build fails. Also for this case I would need a place to undo the renaming just before dpkg--after-build is called. Why not copying instead of moving? That said, I really don't get why dpkg--after-build does not call debian/rules clean. It also causes breakages to my packages. I'll investigate that someday. Regards, Thibaut. -- 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/4faba94c.5070...@free.fr
