Bug#703473: [pkg-php-pear] Bug#703473: RFS: php-cache-lite/1.7.15-1 [ITA] -- Fast and lite data cache system
On 03/20/2013 12:51 PM, Prach Pongpanich wrote: > dget -x > http://mentors.debian.net/debian/pool/main/p/php-cache-lite/php-cache-lite_1.7.15-1.dsc Uploaded. Thanks for your contribution! Do you have many more to upload? I wouldn't mind reviewing them all at once (or at least a few of them at once) if you want. Thomas -- 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/5149ccf9.9020...@debian.org
Re: Build-Depends versioning and binary Depends versioning
On Tue, 19 Mar 2013 18:51:26 +0100 Jakub Wilk wrote: > * Antonio Ospite , 2013-03-19, 16:15: > >for a package I am working on, I am setting versioned Build-Depends, to > >avoid using newer libav versions which would break compilation, e.g.: > > > > libavcodec-dev (<< 6:9) > > > >Compilation under pbuilder for Sid goes fine, but the binary packages > >are still allowed to be installed with newer libav binary packages: > > > > libavcodec53 (>= 6:0.8.3-1~) | libavcodec-extra-53 (>= 6:0.8.5) > > A well-behaved shared library package won't break binary compatibility > without changing package name. In fact, the package name has changed to > libavcodec54. So nothing wrong with the dependency as far as I can tell. > Maybe I've picked the wrong example, the actual problem was with libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1, but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so my binary ended up importing either libavcodec53 and libavcodec54 when both were installed and did not work. I think it will be enough to require libavdevice53 (<< 6:9) in my case. Thanks, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- 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/20130320155413.b8798d09e5005c0425f81...@studenti.unina.it
Re: Build-Depends versioning and binary Depends versioning
On Tue, 19 Mar 2013 10:10:51 -0700 Russ Allbery wrote: > Antonio Ospite writes: > > > Should I restrict the Depends for the binary packages by hand in > > debian/control? For example adding: > > > libavcodec53 (<< 6:9) > > > to the binary package I am interested in restricting? > > Yes. The shared library dependency information otherwise comes from > shlibs/symbols, which won't take into account restrictions on the build > dependency. > Thanks Russ. -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- 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/20130320155440.7f0611c46f2046d604dea...@studenti.unina.it
Re: Build-Depends versioning and binary Depends versioning
On Wed, Mar 20, 2013 at 03:54:13PM +0100, Antonio Ospite wrote: > Maybe I've picked the wrong example, the actual problem was with > libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1, > but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so > my binary ended up importing either libavcodec53 and libavcodec54 when > both were installed and did not work. > > I think it will be enough to require libavdevice53 (<< 6:9) in my case. Strictly speaking this restriction won't guarantee anything about libavdevice53 dependencies. -- WBR, wRAR signature.asc Description: Digital signature
Bug#691893: marked as done (RFS: roundup/1.4.20-2)
Your message dated Wed, 20 Mar 2013 16:22:31 + with message-id and subject line closing RFS: roundup/1.4.20-2 has caused the Debian Bug report #691893, regarding RFS: roundup/1.4.20-2 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 691893: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691893 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "roundup". I have a dedicated uploader (Toni Mueller), but another eye on my changes needn't hurt. It fixes 3 outstanding bugs, one of which is an RC bug. * Package name: roundup Version : 1.4.20-2 Upstream Author : roundup-de...@sourceforge.net * URL : http://www.roundup-tracker.org/ * License : Zope Public License (ZPL) Version 2.0 Section : web It builds those binary packages: roundup- Issue-tracking system in python To access further information about this package, please visit the following URL: http://mentors.debian.net/package/roundup Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/roundup/roundup_1.4.20-2.dsc Regards, Kai Storbeck signature.asc Description: OpenPGP digital signature --- End Message --- --- Begin Message --- Package roundup has been removed from mentors.--- End Message ---
Bug#693514: marked as done (RFS: xombrero/2:1.4.0-1 [TIP])
Your message dated Wed, 20 Mar 2013 16:22:33 + with message-id and subject line closing RFS: xombrero/2:1.4.0-1 [TIP] has caused the Debian Bug report #693514, regarding RFS: xombrero/2:1.4.0-1 [TIP] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 693514: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693514 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "xombrero" * Package name: xombrero Version : 2:1.3.1-1 Upstream Author : Several (Marco Peereboom ) * URL : http://opensource.conformal.com/wiki/xombrero * License : ISC, MIT, BSD-4-clause, BSD-3-clause, BSD-2-clause, CC-BY-SA Section : web It builds those binary packages: xombrero - Minimalist's web browser To access further information about this package, please visit the following URL: http://mentors.debian.net/package/xombrero Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/x/xombrero/xombrero_1.3.1-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: * New upstream release * Changed source and binary package name to xombrero in order to be consistent with upstream's new naming - New package now replace, provide and conflict with the obsolete xxxterm package * Updated debian/control file: - Description field to match the new package description - libwebkitgtk-3.0-dev dependency * Updated debian/copyright file * Renamed debian/xxxterm.upstream-changelog to debian/xombrero.upstream-changelog * Modified all other control files according to the renaming: - debian/examples - debian/install - debian/menu - debian/postinst - debian/prerm - debian/rules - debian/watch * Added NEWS file * Moved to debhelper v9, to handle hardening flags - Had to add a lintian overridden as this is experimental. Regards, Luis Henriques --- End Message --- --- Begin Message --- Package xombrero version 2:1.4.0-1 is in NEW now, and the package at mentors is not newer (2013-03-19) than the package in NEW (2013-03-19), so there is currently no package to sponsor. http://ftp-master.debian.org/new/xombrero_2:1.4.0-1.html http://mentors.debian.net/package/xombrero Please remove the package from mentors or mark it "needs sponsor = no". If for some reason you need to replace the package in NEW, then you can upload an updated package to mentors and feel free to reopen this RFS 693514 or open a new RFS.--- End Message ---
Re: Build-Depends versioning and binary Depends versioning
On 20-03-13 15:54, Antonio Ospite wrote: > Maybe I've picked the wrong example, the actual problem was with > libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1, > but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so > my binary ended up importing either libavcodec53 and libavcodec54 when > both were installed and did not work. If this is true, and I must say I may have had the same experience, isn't this hinting at a bug in libavdevice53, not being stable enough to keep the same SONAME? I think you should file a bug against libavdevice53. Paul signature.asc Description: OpenPGP digital signature
Bug#702072: RFS: tilda/1.1.4-1 [ITA] New upload
On 03/19/2013 11:26 PM, Lanoxx wrote: > dpkg-shlibdeps: warning: package could avoid a useless dependency if > debian/tilda/usr/bin/tilda was not linked against libcairo-gobject.so.2 > (it uses none of the library's symbols) > > Do you know how to fix that? You can try to add "--as-needed" parameter to LD_FLAGS. Anton signature.asc Description: OpenPGP digital signature
Bug#700410: RFS: furiusisomount/0.11.3.1~repack0-2 [ITA] -- ISO, IMG, BIN, MDF and NRG image management utility
On Tue, Feb 12, 2013 at 08:30:11PM +0700, Prach Pongpanich wrote: > I am looking for a sponsor for my package "furiusisomount" Thanks for your work on an existing package. IANADD, so all you get from me is a review. > http://mentors.debian.net/debian/pool/main/f/furiusisomount/furiusisomount_0.11.3.1~repack0-2.dsc I saw that you removed the Vcs-* headers from debian/control. Having the package in version control is a good thing and the infrastructure is already there and set up, maybe you could use it? Otherwise you should probably mention such a change in debian/changelog. There is a patch, that adds a setup.py to ease installation. This patch appears to be useful for others as well, so maybe it can be moved upstream? The patch already contains dep3 style headers to indicate the author, but does not tell whether it was forwarded upstream. Could you ask upstream to apply this patch? Also the version in setup.py appears to be outdated. For completeness I believe that debian/copyright should be mentioning the authors of the translations. You can find a hint that they were not written by Dean Harris in aboutbox.py. In the locale directory there are only mo files, but there is no source. The package is undistributable. This also applies to the one in wheezy, so I have filed a bug #703553. Please prepare both an upload to unstable just fixing this bug and nothing else and an updated upload to experimental with all the other changes as well. brasero is listed in Suggests, but nautilus is listed in Depends. Is nautilus absolutely required for using furiusisomount? If not, could it be demoted to Recommends and that way still be installed by default? Could you spare another look at the package description? Some bullet points have weired casing (uppercase in the middle). The word "automatically" appears to be a bit overused as well. Could you also add some debtags? You can edit tags at http://debtags.debian.net/edit/furiusisomount. Maybe you could try to fix https://bugs.launchpad.net/ubuntu/+source/furiusisomount/+bug/1059504? The immediate issue here is that log_object is not defined in log.py. This is most likely due to some exception from the open call. Just moving the open outside the try block should be fixing the immediate issue. Then very likely an IOError will propagate down. My guess is that the settings_directory is not created, so maybe log.write should ensure that it exists? Helmut -- 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/20130320203447.ga19...@alf.mars
Bug#696782: RFS: sequitur-g2p/0.0.r1668-1 [ITP] -- Grapheme to Phoneme conversion tool
* Jakub Wilk , 2013-02-16, 13:10:
Are the Python modules shipped by this package supposed to be
used by other software?
If not, they should be moved to a private directory.
If yes, then they need to be renamed or moved into a namespace,
because their are way to generic ("tool", "misc", etc.).
It is the former case. It was my fault because I did not read
carefully the Debian policy about Python.
I moved the modules to
/usr/lib/sequitur-g2p/python//dist-packages. After
installation I also change the main script so that it can locate
the modules.
Is this approach ok?
I'm afraid that dh_python2 doesn't support such layout.
I asked for advice on how to handle similar cases on debian-python@:
http://lists.debian.org/20130216120158.ga3...@jwilk.net
Okay. So I see the following ways to go forward:
B) Install the modules as public ones, but put them in a namespace
starting with underscore, say _sequitur_gp2.
C1) Build the modules only for the default Python version and install
them to a private directory (/usr/lib/sequitur-gp2/). But then this will
trigger #702677, so either implement a work-around for it, or wait until
it's fixed, or switch back to python-support...
I leave to your discretion which option to choose. B is my preference,
although it didn't gain recognition on debian-python.
Now some other business:
There are some tests, it would be good to run them at build time.
(Although at least some of them seem to only touch code that doesn't
even end up in binary packages...)
If I were packaging this myself, I'd use "0+r1668-1" as version number,
just in case upstream decides to make a proper release versioned
"0.0.1". But you can keep the current versioning scheme if you like it,
of course.
Did you manually edit the manpage? If yes, then "DO NOT MODIFY THIS
FILE" should be probably removed; otherwise it might be a good idea to
regenerate it at build time.
--
Jakub Wilk
--
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/20130320225350.ga4...@jwilk.net
Bug#702072: RFS: tilda/1.1.4-1 [ITA] New upload
Hi Anton, I have just uploaded the package again (I added -Wl,--as-needed, to the src/Makefile, that fixed the issue). I also changed the version to 1.1.5, which was actually the last version I had tagged in git. Are you now going to upload the package for me? Kind Regards Sebastian On 20/03/13 19:59, Anton Gladky wrote: On 03/19/2013 11:26 PM, Lanoxx wrote: dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/tilda/usr/bin/tilda was not linked against libcairo-gobject.so.2 (it uses none of the library's symbols) Do you know how to fix that? You can try to add "--as-needed" parameter to LD_FLAGS. Anton -- 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/514a3ddd.1090...@gmx.net
Bug#703473: marked as done (RFS: php-cache-lite/1.7.15-1 [ITA] -- Fast and lite data cache system)
Your message dated Thu, 21 Mar 2013 04:22:35 +
with message-id
and subject line closing RFS: php-cache-lite/1.7.15-1 [ITA] -- Fast and lite
data cache system
has caused the Debian Bug report #703473,
regarding RFS: php-cache-lite/1.7.15-1 [ITA] -- Fast and lite data cache system
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
703473: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703473
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "php-cache-lite"
* Package name: php-cache-lite
Version : 1.7.15-1
Upstream Author : Markus Tacker, Fabien Marty
* URL : http://pear.php.net/package/Cache_Lite
* License : LGPL-2.1+
Section : php
It builds those binary packages:
php-cache-lite - Fast and lite data cache system
To access further information about this package, please visit the following
URL:
http://mentors.debian.net/package/php-cache-lite
Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/p/php-cache-lite/php-cache-lite_1.7.15-1.dsc
Changes since the last upload:
php-cache-lite (1.7.15-1) experimental; urgency=low
* New upstream release (Closes: #620255)
* Now using PKG-PHP-PEAR team as maintainer and
add myself as uploader (Closes: #569465)
* Switch to pkg-php-tools and dh-sequencer
- Add pkg-php-tools to Build-Depends
- Add php-pear to Build-Depends-Indep
- Add php-pear and ${misc:Depends} to Depends
- Drop phpapi-* in Depends
- Drop debian/dirs
- Rewrite debian/rules
* Switch to section 'php' instead of 'web'
* Update copyright file to version 1.0 format
* Add Vcs-* fields in debian/control
* Add debian/gbp.conf
* Update debian/watch file
* Bump debhelper compat to level 9
* Bump Standards-Version: 3.9.4
Regards,
Prach Pongpanich
--- End Message ---
--- Begin Message ---
Package php-cache-lite version 1.7.15-1 is in experimental now.
http://packages.qa.debian.org/php-cache-lite--- End Message ---
Re: new ebtables upload
On Wed, Mar 20, 2013 at 11:28:41PM +0100, William Dauchy wrote: > ok just seen the rules modifications from today. > http://release.debian.org/wheezy/freeze_policy.html > This will unfortunately go in unstable only. > > Feel sorry not having done the work before. I couldn't resist having a quick look now. :-) I suggest to ask debian-release for a pre-approval for wheezy with a debdiff including all three changes. So I suggest to keep the flag "needs sponsor" at mentors on "no" for now. Fixing 697276 (kmod) looks like a safe change that should be fixed in wheezy. On bug 697275 I'm not sure, so you should doublecheck and doubletest that the change does not change anything that has been fine in testing during the freeze so far. Make sure that there's no regression at all. Bug 684592 should really be fixed in wheezy, so it's even worth a separate upload for wheezy in my opinion. Depending on the outcome of debian-release you can go ahead with requesting sponsorship for this package as-is (set "needs sponsor" to "yes") or do a separate upload for wheezy with reduced changes you got pre-approval for. Other changes are best uploaded to experimental, not to unstable, so that unstable remains available for additional uploads for wheezy. More questions best via debian-mentors, so other sponsors can help you faster than I can. Regards, Bart Martens -- 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/20130321061013.ge28...@master.debian.org
Re: Debian Preseeding: prevent particular package from being installed
On 3/19/13, Konrad Vrba wrote: > I am using Debian preseeding for automated installations (from PXE) > > in my preseed config file, I have the following line, to install only > the minimum number of packages: > tasksel tasksel/first multiselect > d-i base-installer/install-recommends boolean false thanks, this seems to be what I was looking for > > This however still installs some packages which I don't want. My question > is: > how does the installation script decide which packages will be installed? > how can I modify this list? > can I prevent specific package to be installed > > or, is there some other Debian mailing list, which would be more > appropriate for my question? > -- 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/caf2nc0zmmbfuwqead9sn4bhw4nswmxp1jowhffziqtxy4ue...@mail.gmail.com
Re: Build-Depends versioning and binary Depends versioning
On Wed, Mar 20, 2013 at 07:17:50PM +0100, Paul Gevers wrote: > > Maybe I've picked the wrong example, the actual problem was with > > libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1, > > but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so > > my binary ended up importing either libavcodec53 and libavcodec54 when > > both were installed and did not work. > If this is true, and I must say I may have had the same experience, > isn't this hinting at a bug in libavdevice53, not being stable enough to > keep the same SONAME? I think you should file a bug against libavdevice53. Why? The problem is caused by indirect dependency on both libavcodec53 and libavcodec54, not by ABI breakage. -- WBR, wRAR signature.asc Description: Digital signature
