Re: RFS: gflags
On Thu, Apr 29, 2010 at 1:44 PM, Ehren Kret ehren.k...@gmail.com wrote: I am looking for a sponsor for my package gflags. I'm not sponsoring, but here is a review: You can remove the boilerplate from debian/rules. The upstream README doesn't add any useful information, no need to ship it. The upstream NEWS file is empty, no need to ship it. The upstream ChangeLog looks like it should be named NEWS instead: http://www.gnu.org/prep/standards/standards.html#NEWS-File http://www.gnu.org/prep/standards/standards.html#Change-Logs The library package will almost always be automatically installed so it doesn't need as detailed a description as the -dev package. Some gcc warnings to send upstream: g++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -g -O2 -c -o gflags_unittest.o `test -f 'src/gflags_unittest.cc' || echo './'`src/gflags_unittest.cc src/gflags_unittest.cc:95: warning: dereferencing type-punned pointer will break strict-aliasing rules src/gflags_unittest.cc:100: warning: dereferencing type-punned pointer will break strict-aliasing rules src/gflags_unittest.cc:109: warning: dereferencing type-punned pointer will break strict-aliasing rules src/gflags_unittest.cc:119: warning: dereferencing type-punned pointer will break strict-aliasing rules src/gflags_unittest.cc:120: warning: dereferencing type-punned pointer will break strict-aliasing rules src/gflags_unittest.cc:121: warning: dereferencing type-punned pointer will break strict-aliasing rules src/gflags_unittest.cc:124: warning: dereferencing type-punned pointer will break strict-aliasing rules src/gflags_unittest.cc:138: warning: dereferencing type-punned pointer will break strict-aliasing rules src/gflags_unittest.cc:149: warning: dereferencing type-punned pointer will break strict-aliasing rules lintian complaints to fix: I: gflags source: binary-control-field-duplicates-source field section in package libgflags0 I: libgflags-dev: possible-documentation-but-no-doc-base-registration I: libgflags0: spelling-error-in-binary ./usr/lib/libgflags.so.0.0.0 helpfull helpful I: libgflags0: spelling-error-in-binary ./usr/lib/libgflags_nothreads.so.0.0.0 helpfull helpful X: libgflags0: shlib-calls-exit usr/lib/libgflags.so.0.0.0 X: libgflags0: shlib-calls-exit usr/lib/libgflags_nothreads.so.0.0.0 I: libgflags0: no-symbols-control-file usr/lib/libgflags_nothreads.so.0.0.0 I: libgflags0: no-symbols-control-file usr/lib/libgflags.so.0.0.0 -- bye, pabs http://wiki.debian.org/PaulWise -- 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/v2je13a36b31004300135gc3508c52ib6049f662c900...@mail.gmail.com
Re: Specifying %{variable} in control file for use in post inst?
Ignacio Valdes wrote:
On Thu, Apr 29, 2010 at 9:03 PM, Thomas Goirand tho...@goirand.fr wrote:
Ignacio Valdes wrote:
It is a very complex, large package.
Does anyone know the mechanics of doing introspection in postinst for
the control file defined variables?
Exactly why the postinst generation method that has been given as a
(pretty good) solution would not work?
Required to produce versions for both rpm and deb. No introspection
means not easy to convert this from rpm to deb which is where this
started. This would make it much easier to produce both deb and rpm
versions if it has the ability to introspect those variables.
-- IV
Here's what you could do:
DEBVERS=head -n 1 debian/changelog | cut -d'(' -f2 | cut -d')' -f1 |
cut -d'-' -f1
sed -i "s/__VERSION__/${DEBVERS}/" mypackage.spec
sed "s/__VERSION__/${DEBVERS}/" debian/master.postinst
debian/postinst
This way, you are controlling the version variables of both your RPM
and your
Debian package using what's in the debian/changelog.
Then, if you have some of your postinst script that is the same in both
OS,
then you might want to have an OS independent script in a place like
/usr/share/PKGNAME/myscript, then just source it from spec file /
postinst.
I don't see this as being so hard...
To my experience, it's a lot more easy to be able to maintain BOTH the
rpm
and the Debian package rather than just porting from one to another. If
you
want to avoid redundancy and want to factor things a bit. Maybe you
could
suggest some modifications to the maintainer of the RPM package so you
can share changes with him later on.
Just my 2 cents, hoping it helped.
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/4bdabf89.8080...@goirand.fr
Re: Specifying %{variable} in control file for use in post inst?
On Fri, Apr 30, 2010 at 6:45 AM, Thomas Goirand tho...@goirand.fr
To my experience, it's a lot more easy to be able to maintain BOTH the
rpm
and the Debian package rather than just porting from one to another. If you
want to avoid redundancy and want to factor things a bit. Maybe you could
suggest some modifications to the maintainer of the RPM package so you
can share changes with him later on.
That is pretty much what I have been doing. But how about something as
simple as accomplishing this in postinst using the control file
variables?
echo The package: %{Package}-%{Version} is now installed.
How would one accomplish this in deb?
-- IV
--
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/r2t311679a81004300548z2176038ey4ccff3dad8d52...@mail.gmail.com
Re: Specifying %{variable} in control file for use in post inst?
On Friday 30 April 2010 07:48:59 Ignacio Valdes wrote:
That is pretty much what I have been doing. But how about something as
simple as accomplishing this in postinst using the control file
variables?
echo The package: %{Package}-%{Version} is now installed.
How would one accomplish this in deb?
You wouldn't. It's a useless message. Drop it.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
signature.asc
Description: This is a digitally signed message part.
Re: Specifying %{variable} in control file for use in post inst?
Ignacio Valdes ival...@hal-pc.org writes:
On Fri, Apr 30, 2010 at 6:45 AM, Thomas Goirand tho...@goirand.fr
To my experience, it's a lot more easy to be able to maintain BOTH the
rpm
and the Debian package rather than just porting from one to another. If you
want to avoid redundancy and want to factor things a bit. Maybe you could
suggest some modifications to the maintainer of the RPM package so you
can share changes with him later on.
That is pretty much what I have been doing. But how about something as
simple as accomplishing this in postinst using the control file
variables?
echo The package: %{Package}-%{Version} is now installed.
How would one accomplish this in deb?
Dpkg already does that. It would be wastefull to repeat it.
MfG
Goswin
--
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/87y6g5dm32@frosties.localdomain
Re: RFS: gflags
Thanks for the review. Uploaded 1.3-2 to mentors: * Removed the rules boilerplate, and empty doc files. (will check with upstream on NEWS v ChangeLog... does look like the ChangeLog should be NEWS instead) * Fixed a couple of the lintian complaints. strict-aliasing problems are already reported upstream: http://code.google.com/p/google-gflags/issues/detail?id=33 unaddressed lintian compliants: I: libgflags0: spelling-error-in-binary ./usr/lib/libgflags.so.0.0.0 helpfull helpful I: libgflags0: spelling-error-in-binary ./usr/lib/libgflags_nothreads.so.0.0.0 helpfull helpful This is actually one of the command-line flags (--helpfull) and not a misspelling of helpful. X: libgflags0: shlib-calls-exit usr/lib/libgflags.so.0.0.0 X: libgflags0: shlib-calls-exit usr/lib/libgflags_nothreads.so.0.0.0 These are part of the documented behavior of the library when certain command-line flags are sent in (like --help) or when flags have validation errors. (exit is aliased to commandlineflags_exitfunc in the source code) I: libgflags0: no-symbols-control-file usr/lib/libgflags_nothreads.so.0.0.0 I: libgflags0: no-symbols-control-file usr/lib/libgflags.so.0.0.0 Unfortunately the library exports some symbols which are not supposed to be public. Already informed upstream, but the wiki on the symbols control file says not to use symbols versioning in this case. signature.asc Description: Digital signature
Re: Specifying %{variable} in control file for use in post inst?
Ignacio Valdes wrote: Required to produce versions for both rpm and deb. No introspection means not easy to convert this from rpm to deb which is where this started. This would make it much easier to produce both deb and rpm versions if it has the ability to introspect those variables. If all you're looking to do is produce .rpm and .deb package files for distribution from your own site, you might want to see if a script I wrote will meet your needs: http://deepnet.cx/debbuild/ It takes a .spec and creates a .deb package file. Please note: it does **NOT** create a Debian package, it creates a .deb package that should install reasonably sanely on Debian and derivative systems. Someday I'd like to expand it to write Debian packaging metadata that regular Debian packaging tools can use, but that's not happening any time soon. -kgd -- 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/4bdaf91b.2090...@vianet.ca
Re: Specifying %{variable} in control file for use in post inst?
rpm doesn't. I am going through the joy of trying to reconcile the two
systems so as to not have two divergent code bases as much as
possible.
-- IV
On Fri, Apr 30, 2010 at 9:57 AM, Goswin von Brederlow goswin-...@web.de wrote:
echo The package: %{Package}-%{Version} is now installed.
How would one accomplish this in deb?
Dpkg already does that. It would be wastefull to repeat it.
MfG
Goswin
--
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/x2u311679a81004300903h2ce33eeey35ce5a30ae4cf...@mail.gmail.com
Re: Specifying %{variable} in control file for use in postinst?
So I am gathering that whereas it is repugnant to the dpkg design scheme to do it, but for the sake of rpm reconciliation the thread subject question: accessing control file values in postinst is not simple to do other than with major changes like sed pre-processing and such? Is that the situation? I need to decide this soon and move on. -- IV On Fri, Apr 30, 2010 at 11:03 AM, Kris Deugau kdeu...@vianet.ca wrote: Ignacio Valdes wrote: Required to produce versions for both rpm and deb. No introspection means not easy to convert this from rpm to deb which is where this started. This would make it much easier to produce both deb and rpm versions if it has the ability to introspect those variables. If all you're looking to do is produce .rpm and .deb package files for distribution from your own site, you might want to see if a script I wrote will meet your needs: http://deepnet.cx/debbuild/ It takes a .spec and creates a .deb package file. Please note: it does **NOT** create a Debian package, it creates a .deb package that should install reasonably sanely on Debian and derivative systems. Someday I'd like to expand it to write Debian packaging metadata that regular Debian packaging tools can use, but that's not happening any time soon. -kgd -- 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/n2p311679a81004300912p4c1c91b0j83fa9f0258a5b...@mail.gmail.com
Re: Specifying %{variable} in control file for use in post inst?
* Ignacio Valdes ival...@hal-pc.org [100430 18:04]: rpm doesn't. I am going through the joy of trying to reconcile the two systems so as to not have two divergent code bases as much as possible. Sorry to say it that harsh: I doubt anyone here will be able to help you. We are focused on doing high-quality Debian packages. As you have another goal, most people here will not even understand what your problems are. If you make Debian packages other people are supposed to use, please consider doing proper postinst scripts that are targeted at Debian. Even for different versions of Debian, postinst scripts may need to differ a lot. I see no hope at all that anything that also works elsewhere has any chance to be a proper postinst script. (If you have some package specific tasks, consider creating some common helper scripts to be called from the package scripts. That has the additional advantage that users can also run them manually if needed). Hochachtungsvoll, Bernhard R. Link -- 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/20100430161512.ga15...@pcpool00.mathematik.uni-freiburg.de
Re: Specifying %{variable} in control file for use in post inst?
Ignacio Valdes wrote: rpm doesn't. I am going through the joy of trying to reconcile the two systems so as to not have two divergent code bases as much as possible. -- IV And I can't believe that any policy for any RPM based distro is advising to print such useless information. IMHO, this echo should be removed from the RPM version as well. 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/4bdb06cd.7050...@goirand.fr
Re: Specifying %{variable} in control file for use in postinst?
On Friday 30 April 2010 11:12:57 Ignacio Valdes wrote:
So I am gathering that whereas it is repugnant to the dpkg design
scheme to do it, but for the sake of rpm reconciliation the thread
subject question: accessing control file values in postinst is not
simple to do other than with major changes like sed pre-processing and
such?
I wouldn't say it is repugnant, but the postinst scripts should generally be
able to be run independently of even having the control fields available.
I also wouldn't say that sed pre-processing at .deb build time is a major
change.
Is that the situation?
Yes, dpkg does not (currently) expose the control fields in the environment
that the {pre,post}{inst,rm} scripts are run.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
signature.asc
Description: This is a digitally signed message part.
Re: Specifying %{variable} in control file for use in postinst?
So here is the use case, one that to my knowledge rpm or deb do not
provide much guidance for and deb does not provide control fields for:
Package is a vehicle for installing software that can create multiple
instances. Further, those instances can be very long lived (decades)
and almost certainly will be updated and migrated in the future to new
hardware and software. Finally that in the case of a catastrophic
failure, the metadata of the rpm/deb file such as name of the rpm/deb
file and versions that created it are barcoded redundantly with the
instance in an a instance env file that rides within the instance
directory tree in a known location in order to facilitate recovery and
maintenance (this last part is already worked out).
rpm because it can access the spec file header information this is
pretty easy to do. For deb this looks like I am going to have to parse
the control file to get this information out. Is there any bash
control file parsers out there?
-- IV
On Fri, Apr 30, 2010 at 12:58 PM, Boyd Stephen Smith Jr.
b...@iguanasuicide.net wrote:
On Friday 30 April 2010 11:12:57 Ignacio Valdes wrote:
So I am gathering that whereas it is repugnant to the dpkg design
scheme to do it, but for the sake of rpm reconciliation the thread
subject question: accessing control file values in postinst is not
simple to do other than with major changes like sed pre-processing and
such?
I wouldn't say it is repugnant, but the postinst scripts should generally be
able to be run independently of even having the control fields available.
I also wouldn't say that sed pre-processing at .deb build time is a major
change.
Is that the situation?
Yes, dpkg does not (currently) expose the control fields in the environment
that the {pre,post}{inst,rm} scripts are run.
--
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/s2q311679a81004301119yd69e5908qdacb45a20cbff...@mail.gmail.com
RFS: libdbusmenu-qt
Dear mentors, I am looking for a sponsor for my package libdbusmenu-qt. * Package name: libdbusmenu-qt Version : 0.3.2-1 Upstream Author : Aurelien Gateau aurelien.gat...@canonical.com * URL : http://people.canonical.com/~agateau/dbusmenu/ * License : LGPL 2 or later Section : libdevel It builds these binary packages: libdbusmenu-qt-dev - Qt implementation of DBusMenu protocol (development) libdbusmenu-qt2 - Qt implementation of DBusMenu protocol The package appears to be lintian clean. The upload would fix these bugs: 579677 My motivation for maintaining this package is: This is a required dependency for kdelibs 4.5 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libdbusmenu-qt - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libdbusmenu-qt/libdbusmenu-qt_0.3.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Praveen Arimbrathodiyil -- പ്രവീണ് അരിമ്പ്രത്തൊടിയില് GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) -- 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/m2l3f2beab61004301452qbe5efcf8k82ba06ad7b424...@mail.gmail.com
Re: Subject: RFS: nall
On 27 April 2010 07:23, ben brou...@gmail.com wrote: [...] The package appears to be lintian clean, but is missing a manpage and may have useless generated deps provided by dh tools. Hi, thanks for packaging nall. However, the package does not build in a clean chroot: It needs at least intltool as a build dependency, and then some GTK stuff. And it needs a manpage. Oh, and if you are not reading debian-mentors@lists.debian.org, please state that in your post so we know that we should reply directly. Cheers, -- Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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/s2ic4f47b5b1004301614pef54d98cvc906246991676...@mail.gmail.com
RFS: libspring-security-2.0-java
Hi mentors, I am looking for a sponsor for my package libspring-security-2.0-java. * Package name: libspring-security-2.0-java Version : 2.0.5.RELEASE-1 Upstream Author : Acegi Technology Pty Limited, SpringSource Inc. * URL : http://static.springsource.org/spring-security/site/index.html * License : Apache-2.0 Section : java It builds these binary packages: libspring-security-2.0-java-doc - documentation for Spring Security 2.0 libspring-security-acl-2.0-java - modular Java/J2EE application security framework - ACL libspring-security-core-2.0-java - modular Java/J2EE application security framework - Core libspring-security-ntlm-2.0-java - modular Java/J2EE application security framework - NTLM libspring-security-portlet-2.0-java - modular Java/J2EE application security framework - Portlet libspring-security-taglibs-2.0-java - modular Java/J2EE application security framework - Taglibs The package is lintian clean. The upload would fix these bugs: #577469. My motivation for maintaining this package is: I develop software using those libraries and I need them to deploy software in Debian servers. I plan to maintain this package under Debian Java Team. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libspring-security-2.0-java - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libspring-security-2.0-java/libspring-security-2.0-java_2.0.5.RELEASE-1.dsc - Vcs-Git: git://git.debian.org/pkg-java/libspring-security-2.0-java.git I would be glad if someone uploaded this package for me. Regards, -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x7D8967E9 available at http://keyserver.pgp.com/ Faith means not wanting to know what is true. -- Nietzsche -- 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/20100501023353.ga12...@miguel.cc
RFS: amispammer
Dear mentors, I am looking for a sponsor for my package amispammer. * Package name: amispammer Version : 3.1-1 Upstream Author : Lorenzo Martínez Rodríguez * URL : http://www.lorenzomartinez.es/projs/amispammer/ * License : GPL-3 Section : net It builds these binary packages: amispammer - Powerful Mail Server checker on blacklists The package appears to be lintian clean. The upload would fix these bugs: 579499 My motivation for maintaining this package is: Because is excelent tool to check my Mail Servers. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/amispammer - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/amispammer/amispammer_3.1-1.dsc I would be glad if someone uploaded this package for me. Kind Regards, -- Julián Moreno Patiño Registered GNU Linux User ID 488513 PGP KEY ID 6168BF60
