Re: Proable multiarch related problem in finding header file (Was: Problem finding posix_types_32.h when using pbuilder on the fis-gtm package)
Andreas, Doing a quick check on packages.d.o I can see the file your are talking about. However: http://packages.debian.org/search?suite=sidarch=anymode=pathsearchon=contentskeywords=posix_types.h returns an empty list. Are you sure your pbuilder is up to date ? 2cts On Mon, Feb 13, 2012 at 1:42 PM, Andreas Tille andr...@an3as.eu wrote: Hi, just a comment on this: I suspect a multiarch issue and http://lists.debian.org/debian-devel-announce/2011/06/msg2.html Multiarch handling of header files (/usr/include) will require more per-package attention, ... so Luis is asking for some hints how to deal with this like the need to specify explicite header search path via -I options or something like this. Any more detailed hint than the above would be helpful. Kind regards Andreas. On Sun, Feb 12, 2012 at 05:14:47PM -0500, Luis Ibanez wrote: Debian-mentors, I'm working on packaging fis-gtm, The configuration files that I'm using are here: svn+ssh://svn.debian.org/svn/debian-med/trunk/packages/fis-gtm/fis-gtm/trunk/debian http://anonscm.debian.org/viewvc/debian-med/trunk/packages/fis-gtm/fis-gtm/trunk/debian/ These are setup to get the tarball by using: uscan --verbose --force-depends I manage to build the package locally by using debuild, but, when I use the pdebuild command, I get the following output: - Start the build - Linux Host 32 Linux Host linux i386 x86_regs Source Directory List: sr_linux sr_i386 sr_x86_regs sr_unix_gnp sr_unix_cm sr_unix_nsb sr_unix sr_port_cm sr_port make[2]: Entering directory `/tmp/buildd/fis-gtm-5.4-002B' mkdir -p /tmp/buildd/fis-gtm-5.4-002B/pro/map tcsh -f /tmp/buildd/fis-gtm-5.4-002B/sr_unix/gen_gtm_threadgbl_deftypes.csh /tmp/buildd/fis-gtm-5.4-002B sr_port pro/obj sr_linux sr_i386 sr_x86_regs sr_unix_gnp sr_unix_cm sr_unix_nsb sr_unix sr_port_cm sr_port Entering gen_gtm_threadgbl_deftypes.csh to build gtm_threadgbl_deftypes.h ~/fis-gtm-5.4-002B/pro/obj ~/fis-gtm-5.4-002B Replacing /tmp/buildd/fis-gtm-5.4-002B/sr_linux/gtm_threadgbl_deftypes.h ~/fis-gtm-5.4-002B Exiting gen_gtm_threadgbl_deftypes.csh make -C /tmp/buildd/fis-gtm-5.4-002B/pro/obj -I/tmp/buildd/fis-gtm-5.4-002B/pro/obj -I/tmp/buildd/fis-gtm-5.4-002B/sr_linux -I/tmp/buildd/fis-gtm-5.4-002B/sr_i386 -I/tmp/buildd/fis-gtm-5.4-002B/sr_x86_regs -I/tmp/buildd/fis-gtm-5.4-002B/sr_unix_gnp -I/tmp/buildd/fis-gtm-5.4-002B/sr_unix_cm -I/tmp/buildd/fis-gtm-5.4-002B/sr_unix_nsb -I/tmp/buildd/fis-gtm-5.4-002B/sr_unix -I/tmp/buildd/fis-gtm-5.4-002B/sr_port_cm -I/tmp/buildd/fis-gtm-5.4-002B/sr_port -f /tmp/buildd/fis-gtm-5.4-002B/sr_unix/comlist.mk CURRENT_BUILDTYPE=pro all Linux Host 32 Linux Host linux i386 x86_regs Source Directory List: sr_linux sr_i386 sr_x86_regs sr_unix_gnp sr_unix_cm sr_unix_nsb sr_unix sr_port_cm sr_port make[3]: Entering directory `/tmp/buildd/fis-gtm-5.4-002B/pro/obj' cc1: note: obsolete option -I- used, please use -iquote instead /usr/include/i386-linux-gnu/asm/posix_types.h:2:30: fatal error: posix_types_32.h: No such file or directory compilation terminated. cc1: note: obsolete option -I- used, please use -iquote instead cc1: note: obsolete option -I- used, please use -iquote instead /usr/include/i386-linux-gnu/asm/posix_types.h:2:30: fatal error: posix_types_32.h: No such file or directory compilation terminated. ... and goes on an on, repeating the error about posix_types_32.h. BTW: Please disregard the message: cc1: note: obsolete option -I- used, please use -iquote instead This is a known issue, and probably not related to the problem with posix_types_32.h. I get the same cc1 warnings when building with dbuild and yet in that case the build is successful. I'm doing this in a Virtual Machine, in which uname -a returns: Linux debian-med 2.6.32-5-686 #1 SMP Mon Jan 16 16:04:25 UTC 2012 i686 GNU/Linux The host of this VM, returns for uname -a: Linux macondo 2.6.32-38-generic #83-Ubuntu SMP Wed Jan 4 11:12:07 UTC 2012 x86_64 GNU/Linux Login into pbuilder, it was possible to verify that the header file is actually there, under: ls ./usr/include/i386-linux-gnu/asm/posix* -l -rw-r--r-- 1 root root 92 Feb 6 01:32 ./usr/include/i386-linux-gnu/asm/posix_types.h -rw-r--r-- 1 root root 1316 Feb 6 01:32 ./usr/include/i386-linux-gnu/asm/posix_types_32.h -rw-r--r-- 1 root root 1306 Feb 6 01:32 ./usr/include/i386-linux-gnu/asm/posix_types_64.h I'm having trouble understanding why is that the build process finds: ./usr/include/i386-linux-gnu/asm/posix_types.h but fails to find posix_types_32.h Any suggestions will be appreciated, Thanks Luis -- 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/cabauzprbxvinepvnkjtgcobgobf83ukuy8dvxcy8a7i4yj5...@mail.gmail.com --
Re: Proable multiarch related problem in finding header file (Was: Problem finding posix_types_32.h when using pbuilder on the fis-gtm package)
On Tue, Feb 14, 2012 at 09:47:23AM +0100, Mathieu Malaterre wrote: Andreas, Doing a quick check on packages.d.o I can see the file your are talking about. However: http://packages.debian.org/search?suite=sidarch=anymode=pathsearchon=contentskeywords=posix_types.h returns an empty list. Are you sure your pbuilder is up to date ? Hmm good point. I can only see it on testing http://packages.debian.org/search?suite=testingarch=anymode=pathsearchon=contentskeywords=posix_types_32.h I need to check this out later. Kind regards Andreas. -- http://fam-tille.de -- 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/20120214091012.gd25...@an3as.eu
Re: Bug#659518: Changes to CVS
Sorry, this mail did not kept the mailling list context: Please see this thread for the context. http://lists.debian.org/debian-mentors/2012/02/msg00325.html BR coldtobi -- 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/20120214093212.033a52833c...@sv13.net-housting.de
Bug#659854: RFS: vpnc/0.5.3r512-1 - Cisco-compatible VPN client (new upstream snapshot)
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package vpnc:
dget -x http://mentors.debian.net/debian/pool/main/v/vpnc/vpnc_0.5.3r512-1.dsc
http://mentors.debian.net/package/vpnc
Version 0.5.3r512-1 is the first new upstream version (SVN snapshot,
upstream hasn't done releases in a long time) uploaded to Debian in
almost two years. It includes mainly bugfixes, particularly for routing
issues, and I expect to be able to close a lot more bugs than those
already in the changelog after triaging with this new version:
vpnc (0.5.3r512-1) unstable; urgency=low
* Imported new upstream SVN snapshot with support for Fritz!Box routers
(closes: #629646), fixed MTU when no default route (closes: #525389).
* Refreshed patches, dropped 07_bug496718.patch, 08_bug640978.patch
(applied upstream).
* Added missing ${perl:Depends}.
* Updated debian/copyright to reflect recent work in SVN.
* Updated README.Debian, clarified security warning (closes: #442629).
* Properly remove obsolete conffile example.conf on upgrade.
-- Florian Schlichting fschl...@zedat.fu-berlin.de Mon, 09 Jan 2012
21:57:57 +0100
A previous upload of vpnc was sponsored by its former maintainer, Eric
Warmenhoven, who nevertheless indicated that he might not have the time
to do so in the future, and that I should seek additional sponsorship.
As he apparently hasn't found time to look at vpnc in over three weeks,
I'm now filing this sponsorship-request to ask for your comments and
review.
Florian
--
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/20120214100800.gi11...@zedat.fu-berlin.de
Re: RFS: themole
On Tue, Feb 14, 2012 at 12:31:44AM +0100, Jakub Wilk wrote:
* installing by just copying python files to /usr/share/themole is
far from elegant.
Uh? This is the idiomatic way to install Python applications.
are you sure?
i've made a short survey by looking at files in
/{{usr,}/{s,}bin,usr/games}/ and looking for symlinks to /usr/share to
as python scripts (found five distinct packages doing that: gdebi, gtg,
python-xlrd, and upnp-inspector), looking for things that modify
PYTHONPATH (only paraview and non-python stuff), and looking for scripts
that do sys.path.append to use usr/share (no matches, but i've just
written two bug reports after going through occurrences of path.append,
one of them security critical)
so all in all, of those 76 packages that install python scripts to the
PATH (not counting the ^python packages), only half a dozen try to load
code directly from /usr/share. the others either have very small
executables (which reside solely in the bin folder and don't have any
auxiliary code) or use pyshared or dist-packages.
a simple --with python3 after dh $@ won't do by itself either.
Yes, it would. dh_python3 does care of bytecompiling stuff in
/usr/share/$packagename/ (even though it's not documented, sigh).
sorry, i didn't know about that feature. pulling in the python3
debhelper (and adding a build dependency on python3) would solve the
biggest issue of this package i see, then.
regards
chrysn
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
signature.asc
Description: Digital signature
How to transition to a new UID?
Dear Mentors, I am currently in the process of transitioning to a new UID that I would like to use for my Debian related activities, but am unsure how to do this correctly. There also seems to be a difference between what is documented as good practice and how the actual implementation would behave and I am merely seeking advice on how to complete this transition in a smooth fashion. Additional problems might arise because I do not plan to use my primary UID. I have uploaded the current key with my new UIDs to the debian keyservers already, but the update has (presumably) not yet been folded into the maintainer keyring. I presume that I have to wait until that happened until I can upload DMUA enabled package with my new UID, but it might also be the case that the first package with my new UID has to sponsored again. In particular [1] states that Packages signed by a key in the debian-maintainers keyring will be accepted if the package […] the previous version of the package contains this maintainer's primary UID in the Maintainer. Following the discussion in [2] and most importantly [3] it seems as if the primary UID is not really important as any UID is acceptable iff the real name matches. As this holds true for my key it seems to me as if the best course of action right now would be to keep on using my old UID until the update has been incorporated into the maintainer keyring. Once that happens I can start to use the new one and can upload without problems. If that is indeed the case it would make sense to clarify this in [1] or [4], because the stated requirement that packages with new UIDs need to be sponsored is simply not true. Are there other aspects of a UID change that I am overlooking? [1] http://wiki.debian.org/DebianMaintainer [2] http://lists.debian.org/debian-devel/2011/04/msg01058.html [3] http://lists.debian.org/debian-devel/2011/04/msg01087.html [4] http://wiki.debian.org/DebianMaintainer/Tutorial -- Wolodja deb...@babilen5.org 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: RFS: themole
Hi chrysn (2012.02.14_14:17:19_+0200) * installing by just copying python files to /usr/share/themole is far from elegant. Uh? This is the idiomatic way to install Python applications. are you sure? It's a nice simple approach. Installing to dist-packages like that would be a lot uglier, (and hard to get right) but for a private module like an application, it's really pretty easy and reliable. so all in all, of those 76 packages that install python scripts to the PATH (not counting the ^python packages), only half a dozen try to load code directly from /usr/share. the others either have very small executables (which reside solely in the bin folder and don't have any auxiliary code) or use pyshared or dist-packages. It's not pyshared or dist-packages. pyshared is an implementation detail of dh_python2, used to share .py files between dist-packages of multiple python2s. (OK, it's an implementation detail suggested by the Debian Python Policy, but it's still not something we should be adding to sys.path) What you really seem to have been surveying is whether applications install their modules publicly (dist-packages) or privately (/usr/lib/$package or /usr/share/$package). We encourage an application's modules to be installed privately when they won't be of any use to other modules / applications. http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- 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/20120214140154.ge14...@bach.rivera.co.za
Re: RFS: nginx 1.1.14-1 backport to Debian Squeeze
On Mon, Feb 13, 2012 at 08:50:13PM +0100, Cyril Lavier wrote: Hi, I am looking for a sponsor for my package nginx. It's a backport of the package which is available on Debian Testing. Uploaded. Sven -- 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/20120214142754.ga9...@sho.bk.hosteurope.de
Bug#659894: RFS: minidlna-1.0.23+dfsg-1 (new upstream version)
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package minidlna.
* Package name: minidlna
Version : 1.0.23+dfsg-1
Upstream Author : Justin Maggard jmagg...@users.sourceforge.net
* URL : http://sourceforge.net/projects/minidlna/
* git : git://gitorious.org/debian-pkg/minidlna.git
git-web : https://gitorious.org/debian-pkg/minidlna
* License : GPL-2
Section : net
It builds those binary packages:
minidlna - lightweight DLNA/UPnP-AV server targeted at embedded systems
It's another new upstream version, after an unsuccessful RFS for 1.0.22+dfsg-1
(http://lists.debian.org/debian-mentors/2011/12/msg00374.html).
It fixes the following bugs:
* http://bugs.debian.org/650328
('/etc/inid.d/minidlna status' always reports minidlna is not runing)
* http://bugs.debian.org/656010
(Memory leak in current version of Debian package - fixed in main
distribution)
* http://bugs.debian.org/659871
(Please package 1.0.23)
To access further information about this package, please visit the following
URL:
http://mentors.debian.net/package/minidlna
Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/m/minidlna/minidlna_1.0.23+dfsg-1.dsc
I would be glad if someone uploaded this package for me.
Cheers,
--
Benoît Knecht
--
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/20120214160519.gb3...@marvin.lan
Re: RFS: themole
* installing by just copying python files to /usr/share/themole is
far from elegant.
Uh? This is the idiomatic way to install Python applications.
are you sure?
Well, I've been reviewing packages implemented in Python for over 2
years. You are the first person who questioned my expertise on this
subject. So while I feel now a bit embarrassed, yes, I'm sure.
i've made a short survey by looking at files in
/{{usr,}/{s,}bin,usr/games}/ and looking for symlinks to /usr/share to
as python scripts (found five distinct packages doing that: gdebi, gtg,
python-xlrd, and upnp-inspector), looking for things that modify
PYTHONPATH (only paraview and non-python stuff), and looking for
scripts that do sys.path.append to use usr/share (no matches, but i've
just written two bug reports after going through occurrences of
path.append, one of them security critical)
so all in all, of those 76 packages that install python scripts to the
PATH (not counting the ^python packages), only half a dozen try to load
code directly from /usr/share. the others either have very small
executables (which reside solely in the bin folder and don't have any
auxiliary code) or use pyshared or dist-packages.
It's a bit hard to me to comment on your numbers, as I don't know which
packages did you look at.
So instead I did my own survey. I analysed all (164) binary packages
(co-)maintained by Python Applications Packaging Team in unstable/main.
- 20 don't ship any Python module at all.
- 73 ship private modules.
- 77 ship public modules.
(By simple math: - 6 ship both private and public modules.)
Amongst those that ship only public modules:
- There are 7 python-$something packages.
- There are at least 15 packages (mercurial-*, trac-*, maybe more) that
are plugins to other software. Directory layout of such packages is
determined by layout of software they extend.
It is true that there's non-negligible amount of Python scripts that are
thin wrappers over some public Python modules. Sometimes it's
because upstream provides (more or less) well-defined and (hopefully)
stable API to be used by other software. (Please note that it's
certainly not the case for themole!) In such case, the modules should be
in sys.path and the package name should be python-$something.
Sadly, often the only reasons behind installing stuff into public
places are:
1) poor support for such arrangement in distutils;
2) Debian maintainer(s) being either too lazy to fix it, or being
ignorant of namespace pollution.
--
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/20120214170949.ga...@jwilk.net
how to install python applications (was: RFS: themole)
On Tue, Feb 14, 2012 at 04:01:54PM +0200, Stefano Rivera wrote:
We encourage an application's modules to be installed privately when
they won't be of any use to other modules / applications.
http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html
so what is the preferred way to make the programs find their modules,
then?
* put the main python file in /usr/share/my_package/ and symlink it from
/usr/bin (as it is done in themole), relying on python to resolve the
symlink and find the required modules next to the invoked file
* have a import sys; sys.path.append('/usr/share/my_program'); import
my_main; my_main.run() main wrapper in /usr/bin/
* some distutils/distribute/distutils2 magic i'm not aware of
and, unless it's the third option: is there an elegant way to integrate
that with packages that are already proper (in a python sense) packages
and have a setup.py?
thanks
chrysn
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
signature.asc
Description: Digital signature
Re: How to transition to a new UID?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14.02.2012 13:48, Wolodja Wentland wrote: Following the discussion in [2] and most importantly [3] it seems as if the primary UID is not really important as any UID is acceptable if the real name matches. I can confirm that. That's how I can upload, as keyring maintainers ignored my desired UID when importing my key into the DM keyring so I rely on the name for matching an upload with a key ID. That said, this seems a fragile setting to me, generally speaking. As this holds true for my key it seems to me as if the best course of action right now would be to keep on using my old UID until the update has been incorporated into the maintainer keyring. Once that happens I can start to use the new one and can upload without problems. Should be so. Either that, or you become DD where rules are more flexible. ;-) Are there other aspects of a UID change that I am overlooking? As long as either your name or your UID matches, you are fine. That said, I am not sure how exactly the key transition works for DMs. I could be wrong, but I think there is no automated update or a DM's keyring. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPOqQrAAoJEMcrUe6dgPNt5/IQAKaW+imkOUzTVXuwOmHOAfNu rEM4I6ZP3HRdmsBSxPWtLvy3pUA4rJnBkMJfa9KuVl9CNpdRq09T1hgixGUIKXCK SXrarxTlPeEYBz2f3/iH1YW2tUKTx9krJjWT1DUy/OA7sQx2ybh4Eh9abJT7TPJq zTkxQ2LQquRrosh6NG1Jdx1A9kRSlu1pYMfPic7ltT8hg+ajXS6Npqqz1axRjwRH M6aevwKMwBHAS7mvvrWMsTYYkYrQ4X7MJoInsQt5nZkYiE44AXvE7l5olUbFzTu5 jIirmX46npUNdDVmFRdHlZxdeIH+QTeci0FLImu7ZZHAohBeUzdr+0ozRO8w6n/V CSAyq7qpCn9oHkhgwT+U8gRU+amaIsI9tSIvBDlZITINqJf8gbkMqMrQCxxFlTej 8sRzMX8c6jpHsPXnqDPz2xmG6QvdHQ2YKutuAVEXbelMD7ZMzZXYtSrIzO5K+AmW MdYvW15+4e4LtoI74djhutS3zXPkIFpdW3FMvxiriDTq+przuf+XjHEwYStewUqy aZDelDkx8ye1bNK07NpPOXlNln8S7UQderzGBKtNdBXP8+UIhNH8SEXe/JG/Yyol iX8gZgZed5dJ8/9BSiwn6MlAYdKSoPUpoJvQxTf4W/OMsf5YFcNqy5fzKor8Ac78 ov7253vzwKVPO9u0QmN3 =vdEe -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/4f3aa42b.7090...@toell.net
Bug#659518: marked as done (RFS: tokyocabinet/1.4.37-7 [QA] -- Tokyo Cabinet Database Libraries)
Your message dated Tue, 14 Feb 2012 19:41:13 +0100 with message-id 4f3aaac9.5080...@debian.org and subject line Re: Bug#659518: Changes to CVS has caused the Debian Bug report #659518, regarding RFS: tokyocabinet/1.4.37-7 [QA] -- Tokyo Cabinet Database Libraries 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.) -- 659518: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659518 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: normal Dear mentors, Please sponsor this QA-Upload. (I do not want to adopt this package) Please note that I do not have access to collab-maint, so I cannot commit the changes to the VCS, so I ask the sponsor to do push the changes when doing the upload. * Package name: tokyocabinet Version : 1.4.37-7 * URL : http://fallabs.com/tokyocabinet/ * License : BSD Section : libs It builds those binary packages: libtokyocabinet-dbg - Tokyo Cabinet Database Libraries [debug] libtokyocabinet-dev - Tokyo Cabinet Database Libraries [development] libtokyocabinet8 - Tokyo Cabinet Database Libraries [runtime] tokyocabinet-bin - Tokyo Cabinet Database Utilities tokyocabinet-doc - Tokyo Cabinet Database Documentation To access further information about this package, please visit the following URL: http://mentors.debian.net/package/tokyocabinet Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/t/tokyocabinet/tokyocabinet_1.4.37-7.dsc I would be glad if someone uploaded this package for me. Kind regards, Tobias Frost Changes: * setting Maintainer to QA-Team (orphaned in #650830) * fixing these bugs: #659510 [tokyocabinet] tokyocabinet: FTBFS on hurd, do to missing msync syscall #638625 [tokyocabinet] tokyocabinet: FTBFS on s390x with testsuite errors #596502 [libtokyocabinet-dbg] libtokyocabinet-dbg: mistake in package description * fixes two lintian warnings tokyocabinet (1.4.37-7) unstable; urgency=low * QA upload * Orphaned for more than 14 days: Setting maintainer to QA. * Disable pthread support on s390x (Closes: #638625) * Do not use msync-syscall on hurd (Closes: #659510) * update -dbg Package description (Closes: #596502) * Fixes lintian warning manpage-section-mismatch * Fixes lintian warning debug-package-should-be-priority-extra on libtokyocabinet-dbg -- Tobias Frost t...@coldtobi.de Sat, 11 Feb 2012 19:22:42 +0100 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.4 (SMP w/3 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash ---End Message--- ---BeginMessage--- Am 14.02.2012 10:32, schrieb t...@frost.de: Sorry, this mail did not kept the mailling list context: Please see this thread for the context. http://lists.debian.org/debian-mentors/2012/02/msg00325.html BR coldtobi Uploaded. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org */ signature.asc Description: OpenPGP digital signature ---End Message---
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
On Tue, Feb 7, 2012 at 2:59 PM, Samuel Bronson naes...@gmail.com wrote: On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko yo...@debian.org wrote: In good old days when I had time and motivation to maintain gcc-doc, I've used git repos to managed entire thing. I've just created externally-available mirror for those - please check http://yoush.homelinux.org:8079/git Could you please clone these repos, and reformat your work into this format? IMO this format greatly helps to keep things consistent. I can certainly try! Okay, I've cloned your gcc-doc repository and added my changes: git clone https://github.com/SamB/debian-gcc-doc (Or open it in your browser, or ...) I'm holding off on updating the 4.4 control files and the -defaults packages for the moment: I want to streamline the new X.Y process a bit more first. Maybe this could be moved to git.debian.org. Yes, that sounds like a good idea. Then I could add the Vcs-*: fields to debian/control. Of course, there will probably be a lot to update in README.source then... As for the rest, here are several more comments: *) I don't really understand the workflow of gcc-doc-non-dfgs converted to 3.0 (quilt) format. With old format, there was debian/patches, managed by dpatch, with part of patches managed by hands, and part managed by a perl script. Running the script altered debian/patches/* files, including series file. But isn't this unsafe for 3.0 (quilt) format since it will break metadata in .pc/ directory? Hmm. Perhaps the script should simply refuse to run whenever there is a .pc directory? (It seems that dpkg-source removes this after unapplying the patches.) In any case, most of this is changed very little; the script just gets to be a bit shorter since the patches no longer have to be shell scripts. Also, if you convert to 3.0 (quilt), why still mentioning dpatch in README.source? That was an accident. I've corrected this now. *) Looks like your command line for patch convertion script is much shorter that in was in previous times. How did you check which patches to apply and which not? Well, I grepped the GCC package's debian/patches for anything that changed .texi files, and looked through the debian/rules.patch to see which of those seemed to be applied for Debian builds on any architecture (in that alternate universe where GFDL_INVARIANT_FREE=no). Actually I've looked at updating gcc-doc during new year holidays, and stopped and postponed it exactly at this point. It was unclear what patches to apply, looked like some procedure/policy was needed, and I could not think your such a policy at that time. The idea was to check what patches are applied for each of in-debian architectures, and apply doc changes for all of those. This could likey be automated, e.g. by writing a makefile that will include debian/rules2 from gcc package, and then use vars set by that to print list of applied patches; some tricks with var-setting could do this for all archs. Hmm, not a terrible idea. I still think the *very* cleanest thing would probably be to build gcc-X.Y-doc-non-dfsg like this, though: [Oops, I forgot to finish this bit:] * Take the debian/ directory from gcc-X.Y + uncomment the documentation patches if necessary + replace debian/control with one that only builds the documentation packages + arrange for GFDL_INVARIANT_FREE=no to be set * Put a pristine upstream tarball in the root of the tree in place of the stripped one that gcc-X.Y uses. (Of course, this would turn the package into little more than a script to generate the *actual* packages.) However, as I'm always low on diskspace, I'm a bit reluctant to actually *try* this. *) [minor but still] it looks a bit unfair that there is only your signature under README.source, while large part of the text was written by me :). I agree with you that this was a very rude of the README.Debian Emacs mode to do this. I can understand updating the date; removing your name, not so much. Though, it also obviously shouldn't simply update the date next to your name. So I'm not really sure what it *should* do... If you can think what it should do, maybe we should open a bug against /usr/share/emacs/site-lisp/dpkg-dev-el/readme-debian.el to request the change? 2. In contemplating putting debian/copyright in DEP-5 format, I've realized that I'm not sure of the exact copyright/licensing status of anything in the debian/ directory, except: See debian/copyright from the old packages. Everything non-autogenerated under debian/ was stated to be GPL; I don't object changing that if needed. No, there's certainly no need to change that. (Of course, I would not object if they were to be put under the Expat license. :-) P.S. I apologize for returning the slow response time! I've now actually made an attempt at putting debian/copyright in DEP5 form. There are a couple of holes in it still, but that's mostly
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
On Tue, Feb 14, 2012 at 03:02:43PM -0500, Samuel Bronson wrote: On Tue, Feb 7, 2012 at 2:59 PM, Samuel Bronson naes...@gmail.com wrote: On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko yo...@debian.org wrote: In good old days when I had time and motivation to maintain gcc-doc, I've used git repos to managed entire thing. I'm holding off on updating the 4.4 control files and the -defaults packages for the moment: I want to streamline the new X.Y process a bit more first. Good, as there's 4.7 in experimental already. Not officially released and ICEs like hell, but it's meant to release soon... -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
Re: notify command
On Tue, Feb 14, 2012 at 07:08:33AM +0330, Mohsen Pahlevanzadeh wrote: Dear all, I'm preparing matterial and need to notify command in debian.I guess it's renamed, do you know its new name? I suppose you are looking for notify-send in libnotify-bin. Cheers, Javi (Vicho) signature.asc Description: Digital signature
Bug#659915: FW: ITP: radlib -- rapid application development library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: sponsorship-requests Severity: wishlist * Package name: radlib Version : 2.11.3-1 Upstream Author : Mark Teel mteel2...@gmail.com * URL or Web page : http://radlib.teel.ws License : BSD Description :rapid application development library radlib is a C language library developed to abstract details of interprocess communications and common linux/unix system facilities so that application developers can concentrate on application solutions. It encourages developers (whether expert or novice) to use a proven paradigm of event-driven, asynchronous design. By abstracting interprocess messaging, events, timers, and any I/O device that can be represented as a file descriptor, radlib simplifies the implementation of multi-purpose processes, as well as multi- process applications. This packages is needed bye upcoming Package wview see #659620 It builds those binary packages: librad0- rapid application development library radlib-dev - rapid application development library To access further information about this package, please visit the following URL: http://mentors.debian.net/package/radlib Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/radlib/radlib_2.11.3-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Bas van den Dikkenberg -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAk86zuoACgkQInDFGMlxAyOaWQCfdR1H6LR1qklzGSvydATd/4Fb 8bAAn0TooBDWvhI6bT89BZuru9WZxfjv =VWb2 -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/9345AD5DE363814DA41482800A8D50641C8CC1B1@srv01.dikkenberg.local
Bug#659854: RFS: vpnc/0.5.3r512-1 - Cisco-compatible VPN client (new upstream snapshot)
tag 659854 + confirmed owner 659854 ! thanks On Tue, 14 Feb 2012 11:08:00 +0100, Florian Schlichting wrote: I am looking for a sponsor for my package vpnc: dget -x http://mentors.debian.net/debian/pool/main/v/vpnc/vpnc_0.5.3r512-1.dsc http://mentors.debian.net/package/vpnc This looks very good IMO. Just some remarks which you might want to look at: - I think PREFIX is only needed for the install but not for the build target in debian/rules. - uscan - debian/watch don't work. I don't know if there are releases planned but for the svn snapshots a get-orig-source target might be nice. - debian/copyright: mismatch between GPL-2+ and version 1 ... GPL-1. - debhelper 9 might (or might not, I haven't checked) pass more hardening *FLAGS down to the build system? - Similar: The package doesn't seem to honour DEB_BUILD_OPTIONS=noopt. - mk-version: 6: mk-version: Syntax error: ( unexpected looks a bit ugly (only triggered by dash, not by bash or zsh, and checkbashisms also whines), and it leads to -DVERSION=\\ in the gcc calls. (If you have the package in git somewhere reviewing future changes would be more convenient for me :)) Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Frank Zappa: MOTHERS AT KPFK signature.asc Description: Digital signature
Processed: Re: Bug#659854: RFS: vpnc/0.5.3r512-1 - Cisco-compatible VPN client (new upstream snapshot)
Processing commands for cont...@bugs.debian.org: tag 659854 + confirmed Bug #659854 [sponsorship-requests] RFS: vpnc/0.5.3r512-1 - Cisco-compatible VPN client (new upstream snapshot) Added tag(s) confirmed. owner 659854 ! Bug #659854 [sponsorship-requests] RFS: vpnc/0.5.3r512-1 - Cisco-compatible VPN client (new upstream snapshot) Owner recorded as gregor herrmann gre...@debian.org. thanks Stopping processing here. Please contact me if you need assistance. -- 659854: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659854 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13292577941822.transcr...@bugs.debian.org
Re: notify command
On Tue, 2012-02-14 at 21:07 +, Javi Merino wrote: libnotify-bin Oh no, I'm looking for notify classic command, it used by a set of old unix and distro such as nice, renice and so on. You can the following link: http://www.manpagez.com/man/1/notify/osx-10.7.php ---mohsen signature.asc Description: This is a digitally signed message part
Re: notify command
On Wed, Feb 15, 2012 at 03:16:14AM +0330, Mohsen Pahlevanzadeh wrote: On Tue, 2012-02-14 at 21:07 +, Javi Merino wrote: libnotify-bin Oh no, I'm looking for notify classic command, it used by a set of old unix and distro such as nice, renice and so on. You can the following link: http://www.manpagez.com/man/1/notify/osx-10.7.php According to the very page you linked, that command is a shell built–in that is only available in csh. Try installing csh or tcsh. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: how to install python applications
We encourage an application's modules to be installed privately when
they won't be of any use to other modules / applications.
http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html
so what is the preferred way to make the programs find their modules,
then?
* put the main python file in /usr/share/my_package/ and symlink it
from /usr/bin (as it is done in themole), relying on python to resolve
the symlink and find the required modules next to the invoked file
* have a import sys; sys.path.append('/usr/share/my_program'); import
my_main; my_main.run() main wrapper in /usr/bin/
Choosing between these two is largely a matter of taste. The first one
is usually less work, so I prefer it.
* some distutils/distribute/distutils2 magic i'm not aware of
None that I'm aware. ISTR somebody claimed that distutils2 was supposed
to have some magic for this, but I can't see anything obvious in the
documentation.
and, unless it's the third option: is there an elegant way to integrate
that with packages that are already proper (in a python sense) packages
and have a setup.py?
Two possible ways that come to mind:
1) python setup.py install --root=debian/foo --install-lib=/usr/share/foo
--install-scripts=/usr/share/foo
2) Ignore setup.py completely and use dh_install to move stuff into
appropriate places.
(In both cases things get a bit hairy if a script has the name as Python
package name...)
--
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/20120214235852.ga...@jwilk.net
Re: RFS: themole
On 02/11/2012 04:46 PM, Raúl Benencia wrote: Dear mentors, I am looking for a sponsor for my package themole. Dear mentors, Thanks for all your advices. I've uploaded a new version of my package with the corrections you were suggesting. Here are the changes: * Added VCS-Browser and VCS-git fields to debian/control. * Removed chardet/ directory from upstream source. It's not used at all. See README.source. * Added python3 as build depends and into debian/rules. About the lintian pedantic warning, P: themole source: unversioned-copyright-format-uri http://dep.debian.net/deps/dep5 I've chosen to follow what was said here[0]. If you want me to change it, please let me know. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/themole Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/t/themole/themole_0.2.6-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Raúl Benencia [0] http://lists.debian.org/debian-devel/2011/09/msg00084.html signature.asc Description: OpenPGP digital signature
