Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
Stephen Kitt scrisse: > Would it be acceptable to introduce an exception to policy allowing > this? Something along the lines of > > An exception is granted for `Architecture: all' packages > containing libraries targeting platforms for which there is no Debian > architecture. Such packages may use their traditional triplet > as recognised by binutils and gcc. > > (The phrasing is certainly not perfect; this ends up being an > exception to an exception...) > > Policy also doesn't mention /usr/include/; I saw that > possibility referred to in http://bugs.debian.org/542865. > I'd appreciate your thoughts! While the wording may be refined for the final patch to policy, your proposed idea is good. Have you already opened a bug to track it? > PS. I realise some may find it odd to spend time on Windows support in > Debian, but it does come in handy, for instance for newer versions of > Wine, or for Windows versions of some tools used to install Debian > from a Windows environment. No need to feel alone in the dark, other compilers for bare-bone mcu are in the same conditions. avr and msp430 (experimental only right now) tool-chains will benefits from your proposal. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: PGP signature
limits for package name and version (MBF alert: ... .deb filenames)
Hi, In order to manage package file name length below 90 and to have sane screen for package management, may I suggest to recommend some limits (for lintian check etc.): * package name string should be less than 40 characters. * version name string should be less than 30 characters. (security updates etc. excluded) Older part of maint-guide text recommend to use 20 or less for package name for last 10 years or so. This may be too short for the modern system but it is good to have some commonly agreed limits as recommendation. I will be bumping limit numbers in maint-guide to these. See below for my rationale with the statistics. On Thu, Mar 31, 2011 at 01:48:23PM +0100, Steve McIntyre wrote: > On Wed, Mar 30, 2011 at 09:54:49AM -0300, Henrique de Moraes Holschuh wrote: ... > >Don't let it go over 250 *bytes* (not characters. UTF-8 and all that...). Why UTF-8? We should keep it within ASCII so any system can display all package file name. In ASCII range, UTF-8 and ASCII are the same byte sequence. > >We really need to curb the long name insanity in the head. And might as > >well do it in a way that does not hinder our ability to get data where it > >is needed, i.e. keep it under 100 chars. > > I'm pushing for a little less than that, then the Joliet problems go > away. We get an absolute maximum of 103 (Unicode) chars there, so I'm > going to push for a max of 90 for normal uploads. That allows for > small amounts of growth for security updates etc. > > >There really is no excuse for such long deb names. If a naming convention > >"requires" it, fix the buggy naming convention. 90 is good upper limit but how do we enforce this. Since this comes from both package name and version strings, let's see the situation. Here first number is the length of sting, the second number is number of such package, and the last number is the cumulative %. (Data: sid, kfreebsd-amd64) === stat for package name string length === 11 1947 36.9% --- mode 14 1717 54.7% --- 50% median 23 611 91.0% --- 90% 32 89 99.0%--- 99% 41 12 99.9%--- 99.9% 52 1 100.0% Clearly, 20 char is becoming too short for 17% of packages === stat for version string length === 7 8257 53.2% --- 50% median& mode 12 976 90.1% --- 90% 20 73 99.0%--- 99% 30 3 99.9% --- 99.9% 37 6 100.0% === stat for filename string length === 35 1546 43.4% --- mode 37 1363 53.0% --- 50% median 48 569 91.3% --- 90% 58 61 99.0%--- 99% 67 11 99.9%--- 99.9% 76 1 100.0% Even if we limit the package name to 40 and version string to 30, there are not much issue. There is no real impact to the archive as the following: === package name, strings longer than 41 === libbusiness-onlinepayment-authorizenet-perl libbusiness-onlinepayment-transactioncentral-perl libcgi-application-basic-plugin-bundle-perl libcgi-application-extra-plugin-bundle-perl libcgi-application-plugin-anytemplate-perl libcgi-application-plugin-authentication-perl libcgi-application-plugin-authorization-perl libdata-formvalidator-constraints-datetime-perl libdist-zilla-plugin-changelogfromgit-perl libdist-zilla-plugin-podspellingtests-perl libfusioninventory-agent-task-netdiscovery-perl libfusioninventory-agent-task-ocsdeploy-perl libfusioninventory-agent-task-snmpquery-perl libghc6-syb-with-class-instances-text-prof libglobus-gram-job-manager-callout-error-dev libglobus-gram-job-manager-callout-error-doc libjifty-plugin-authentication-bitcard-perl libjifty-plugin-authentication-facebook-perl libmoosex-emulate-class-accessor-fast-perl libmoosex-meta-typeconstraint-forcecoercion-perl libnet-nationalrail-livedepartureboards-perl libnet-rendezvous-publish-backend-avahi-perl libpentaho-reporting-flow-engine-java-openoffice.org libsyntax-highlight-engine-simple-languages-perl libtest-http-server-simple-stashwarnings-perl tryton-modules-account-invoice-line-standalone tryton-modules-purchase-invoice-line-standalone All of these are able to wrap name within 40 chars. (At least less than 50. only one package exceeds it.) === version, strings longer than 30 (unique ones) === 0.9.15+post20100705+gitb3aa806-2 0.0.0+git20091215.9ec1da8a-2+b2 1.0.0~alpha3~git20090817.r1.349dba6-2 1:2.5.0~alpha4+svn20091009-1+b2 2.1.14+2.6.32.13-201005151340-1 1:2.2cvs20100105-true-dfsg-5+b1 0.9.8+hg20101101.b35a000870cc-1 0.5.10~alpha0+git201005030944-2 1.1.1+ooo-build3.0.0.9+r14588-9 1.2.0~pre3+snap20071004+dfsg-3+b1 3.0~a2+hg1075.9a478044c65c~dfsg1-1 Clearly, all of these are able to wrap name within 30 chars. I mean there is no reason to have more than 10 uploads a day, timestamp is best to be limitted less than 11 chars. Hush can be shortened as needed. So it is very easy to keep this within 30 chars. With these for normal upload, we can meet package(40) + "_" + version(30) + "_kfreebsd-amd64.deb" => 90 characters Regards, Osamu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.o
Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
Hi, Adam Borowski wrote: > Such dirs cannot include the compiler's name, since there are multiple > compilers for the architecture. Binaries compiled with > i586-mingw32msvc-gcc, i686-w64-mingw32-gcc and MSVC share the same ABI. > > Even specific models of CPUs are no good: on i386, gcc -dumpmachine returns > i486-linux-gnu yet the arch triplet is i386-linux-gnu. IIUC then the GNU triplet includes the choice of C library because binaries (e.g., libraries) compiled against mingw32 and mingw-w64 cannot be linked (i.e., they do not share ABI). Though I could easily be wrong. IIRC according to the multiarch spec, paths in Debian use "simplified" triplets (DEB_HOST_MULTIARCH) with i[3456...]86 replaced by i386. Including so much unnecessary detail about the default instruction set in the triplet is unusual (I know of no example other than x86). As you mention, in the ix86 case it causes problems so we work around it. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110423100506.GA1500@elie
Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
Stephen Kitt writes:
> Hello,
>
> Now that multiarch is here, I've been wondering whether and how it applies to
> cross-compiler libraries for non-Debian architectures, for example Microsoft
> Windows (I'm the new maintainer of mingw-w64). As I understand it, multiarch
> wasn't intended for non-Debian architectures, and this is (indirectly)
> reflected in policy (9.1.1 point 3 for example).
>
> It seems to me though that it would be nice to follow the multiarch directory
> structure for cross-compilers to non-Debian architectures (basically,
> anything for which there is no valid "Architecture" field value for a Debian
> package). Thus for example mingw-w64-dev would install headers
> in /usr/include/{i686,x86_64}-w64-mingw32 and libraries
> in /usr/lib/{i686,x86_64}-w64-mingw32 instead of the
> current /usr/{i686,x86_64}-w64-mingw32/{include,lib} (which isn't
> FHS-compliant, and thus isn't policy compliant either since section 9.1.1
> is based on the FHS).
>
> Unfortunately this appears to go against policy 9.1.1, which forbids packages
> installing files into triplet-based directories under /usr/lib other
> than /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH). Since the files I'm
> thinking of aren't usable on any Debian architecture, they're provided as
> "Architecture: all" packages and don't have a corresponding
> DEB_HOST_MULTIARCH triplet.
>
> Would it be acceptable to introduce an exception to policy allowing this?
> Something along the lines of
>
> An exception is granted for `Architecture: all' packages containing
> libraries targeting platforms for which there is no Debian
> architecture. Such packages may use their traditional triplet as
> recognised by binutils and gcc.
>
> (The phrasing is certainly not perfect; this ends up being an exception to an
> exception...)
I would rather add a new architecture to dpkg for this. This does not
mean that debian has to create a new port or that the packages have to
stop being arch:all. But dpkg should know about it and be the one and
only place packages query for the right multiarch triplet. Then you
would use
/usr/lib/$(dpkg-architecture -aw64-mingw32 -qDEB_HOST_MULTIARCH)
when building your package. Problem solved.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874o5pfegc.fsf@frosties.localnet
Re: MBF Re: Bug#621277: ggz-grubby: Getting rid of unneeded *.la / emptying dependency_libs
On Thu, Apr 7, 2011 at 19:13:43 +0200, Andreas Metzler wrote: > On 2011-04-06 codeh...@debian.org wrote: > > Package: ggz-grubby > > Severity: normal > > User: codeh...@debian.org > > Usertags: la-file-removal > > > To finish an old release goal from Squeeze, to comply with Policy > > 10.2 and to ease the introduction of MultiArch, I'm filing bugs > > against packages which contain .la files which can be either removed > > or stripped of the dependency_libs variable. > [...] > > Hello, > > Please stop this mass bug filing. > a) There were duplicate bugs filed. > b) Bugs were filed for issues recently solved. > c) The bugs reports are unversioned. > > I can completely understand that a and b can occassionally happen due > to timing issues. However imnsho a MBF with unversioned bug-reports is > not acceptable. > Ack. Also I think this should simply be a lintian check, there's no need to have a mass bug filing about it. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110423104510.gg2...@radis.liafa.jussieu.fr
Bug#623825: ITP: libmoosex-chainedaccessors-perl -- accessor class for chained accessors with Moose
Package: wnpp Severity: wishlist Owner: Ansgar Burchardt * Package name: libmoosex-chainedaccessors-perl Version : 0.02 Upstream Author : Moritz Onken * URL : http://search.cpan.org/dist/MooseX-ChainedAccessors/ * License : Artistic or GPL-1+ (like Perl) Programming Lang: Perl Description : accessor class for chained accessors with Moose MooseX::ChainedAccessors is a Moose Trait which allows for method chaining on accessors by returning $self on write/set operations. This package is required by the new upstream release of libhtml-formfu-perl. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110423115157.11644.1157.report...@marvin.43-1.org
Re: limits for package name and version (MBF alert: ... .deb filenames)
On Sat, 2011-04-23 at 18:31 +0900, Osamu Aoki wrote: [...] > === version, strings longer than 30 (unique ones) === > 0.9.15+post20100705+gitb3aa806-2 > 0.0.0+git20091215.9ec1da8a-2+b2 > 1.0.0~alpha3~git20090817.r1.349dba6-2 > 1:2.5.0~alpha4+svn20091009-1+b2 > 2.1.14+2.6.32.13-201005151340-1 > 1:2.2cvs20100105-true-dfsg-5+b1 > 0.9.8+hg20101101.b35a000870cc-1 > 0.5.10~alpha0+git201005030944-2 > 1.1.1+ooo-build3.0.0.9+r14588-9 > 1.2.0~pre3+snap20071004+dfsg-3+b1 > 3.0~a2+hg1075.9a478044c65c~dfsg1-1 > > Clearly, all of these are able to wrap name within 30 chars. [...] I would like to see policy forbid the use of commit hashes in versions. They aren't ordered, and the information about exactly which commit the snapshot was can be included in the changelog. Mercurial revision numbers should not be used either as they are not consistent between repositories (they really were a stupid idea in a distributed VCS). Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: limits for package name and version (MBF alert: ... .deb filenames)
Ben Hutchings (23/04/2011): > I would like to see policy forbid the use of commit hashes in > versions. They aren't ordered, and the information about exactly > which commit the snapshot was can be included in the changelog. I'll be happy to second any wording you could come up with on that topic. KiBi. signature.asc Description: Digital signature
Bug#623832: ITP: libfile-type-webimages-perl -- tool for determining web image file types using magic
Package: wnpp Owner: Nicholas Bamber Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libfile-type-webimages-perl Version : 1.01 Upstream Author : Mark Stosberg * URL : http://search.cpan.org/dist/File-Type-WebImages/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : tool for determining web image file types using magic File::Type::WebImages mime_type() can use either a filename, or file contents, to determine the type of a file. The process involves looking the data at the beginning of the file, sometimes called "magic numbers". -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db2e066.7010...@periapt.co.uk
Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
On Sat, Apr 23, 2011 at 05:05:33AM -0500, Jonathan Nieder wrote: > Hi, > > Adam Borowski wrote: > > > Such dirs cannot include the compiler's name, since there are multiple > > compilers for the architecture. Binaries compiled with > > i586-mingw32msvc-gcc, i686-w64-mingw32-gcc and MSVC share the same ABI. > > > > Even specific models of CPUs are no good: on i386, gcc -dumpmachine returns > > i486-linux-gnu yet the arch triplet is i386-linux-gnu. > > IIUC then the GNU triplet includes the choice of C library because > binaries (e.g., libraries) compiled against mingw32 and mingw-w64 > cannot be linked (i.e., they do not share ABI). Though I could easily > be wrong. Note that the triplets used by mingw-w64 were carefully chosen to produce as much confusion as possible. The two architectures: win32 and win64 have both "w32" and "w64" in the name: * i686-w64-mingw32 * x86_64-w64-mingw32 The former is ABI-compatible not only with i586-mingw32msvc but also with real msvc. I just tried all combinations of these three, even including malloc()ing from an object compiled with one and free()ing from another. Everything seems to work fine [1]. This is for C. C++ between MSVC10 and mingw32 is not ABI-compatible, but even gcc breaks compatibility there completely every a few releases (remember -c102 in gcc-4.0?) and in minor points more often. So does MSVC. Our two mingw32 versions seem to be compatible with each other, though. > IIRC according to the multiarch spec, paths in Debian use "simplified" > triplets (DEB_HOST_MULTIARCH) with i[3456...]86 replaced by i386. > Including so much unnecessary detail about the default instruction set > in the triplet is unusual (I know of no example other than x86). As > you mention, in the ix86 case it causes problems so we work around it. Distinguishing between two ABI-compatible compilers would be even worse. Fortunately, nothing started using these names yet, so it's a perfect moment to discuss a common arch name. Currently, the following packages use i586-mingw32msvc: * gcc-mingw32 * mingw32 * mingw32-binutils * mingw32-ocaml * mingw32-runtime * nsis There's no need to use the same triplet for multiarch as for compiler, so the new path might use something else. I don't care what, as long as it's consistent between all of win32 in Debian. [1]. Googling around, I see there's a problem with bitfields in structures which has been fixed only in gcc-4.6, so it's "almost fine". It seems that MSVC ABI compatibility is one of goals for mingw. Anyway, it's not like Debian can ship anything compiled with real MSVC, so if you think that "almost compatible" is not good enough, the triplet can include -mingw rather than -msvc. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
On Sat, Apr 23, 2011 at 12:29:39PM +0200, Goswin von Brederlow wrote:
> Stephen Kitt writes:
> > Now that multiarch is here, I've been wondering whether and how it applies
> > to
> > cross-compiler libraries for non-Debian architectures.
[...]
> > It seems to me though that it would be nice to follow the multiarch
> > directory
> > structure for cross-compilers to non-Debian architectures
[...]
> > Thus for example mingw-w64-dev would install headers
> > in /usr/include/{i686,x86_64}-w64-mingw32 and libraries
> > in /usr/lib/{i686,x86_64}-w64-mingw32 instead of the
> > current /usr/{i686,x86_64}-w64-mingw32/{include,lib} (which isn't
> > FHS-compliant)
[...]
> > Would it be acceptable to introduce an exception to policy allowing this?
> > Something along the lines of
> >
> > An exception is granted for `Architecture: all' packages containing
> > libraries targeting platforms for which there is no Debian
> > architecture. Such packages may use their traditional triplet as
> > recognised by binutils and gcc.
> >
> > (The phrasing is certainly not perfect; this ends up being an exception to
> > an
> > exception...)
>
> I would rather add a new architecture to dpkg for this. This does not
> mean that debian has to create a new port or that the packages have to
> stop being arch:all. But dpkg should know about it and be the one and
> only place packages query for the right multiarch triplet. Then you
> would use
>/usr/lib/$(dpkg-architecture -aw64-mingw32 -qDEB_HOST_MULTIARCH)
> when building your package. Problem solved.
Sounds like a great idea to me!
It would fix the inconsistency I mentioned in another branch of this thread.
I'd use just "win32" and "win64" for short names of the architectures, since
we don't have i386-gcc, i386-clang and i386-tcc when all of them use glibc.
Once it is hidden inside dpkg's bowels, the triplet might be even
i586-i686-w32-w64-w128-but-really-w32-klaatu-verata-nikto-mingw-w42.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
signature.asc
Description: Digital signature
howto modify dependencies?
Hi all, as I have trouble with the package ppp since version 2.4.5-*, and no one cared although I filed a bugreport, I set the package to hold (version 2.4.4-rel-10.1 is working fine!) But as newer packages require higher versions of ppp, I cannot install them. besides, all packages which are using ppp in higher versions, do also not work at me. However, as the old version is working fine, I am looking for a way, to install newer packages but hold the old ppp-version. I could still not manage it, because of dependencies (which is logically). Neither with aptitude nor with apt-get I found an option. Any hints? Talking of aptitude just a simple question: "apt-get --purge remove 2.6.32-*" is removing anything with "2.6.32-" in its name. But aptitude does not offer this option, doesn't it? Is aptitude using some other syntax??? Happy eastern! Hans -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201104231801.40103.hans.ullr...@loop.de
Bug#623847: ITP: rescan-scsi-bus -- tool for reliable scsi hotplugging in linux
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: rescan-scsi-bus Version : 1.48 Upstream Author : Kurt Garloff * URL : http://www.garloff.de/kurt/linux/ * License : GPL Programming Lang: Bash Description : tool for reliable scsi hotplugging in linux Linux allows you to add and remove SCSI devices without rebooting by using the echo "scsi add-single-device H C I L" > /proc/scsi/scsi command (H = host, C = channel, I = SCSI ID, L = SCSI LUN). The remove-single-device command works similarily. .. This tool provides an easy interface to interact with the SCSI subsystem in the linux kernel to perform SCSI Hotplugging To Debian-Devel: This package is just one single shell script. But an important one. The rescan-scsi-bus.sh script helps a lot in the SAN space where there could be targets with sporadic connecitons. Is it okay to package a single shell script as a package? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110423162339.1875.90556.report...@champaran.hq.netapp.com
Re: limits for package name and version (MBF alert: ... .deb filenames)
On Sat, 23 Apr 2011, Cyril Brulebois wrote: > Ben Hutchings (23/04/2011): > > I would like to see policy forbid the use of commit hashes in > > versions. They aren't ordered, and the information about exactly > > which commit the snapshot was can be included in the changelog. > > I'll be happy to second any wording you could come up with on that > topic. Same here. While at it, I also agree with Osamu's proposal. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110423163759.ga22...@khazad-dum.debian.net
Re: Bug#623847: ITP: rescan-scsi-bus -- tool for reliable scsi hotplugging in linux
Hello, On Sat, 23 Apr 2011 21:53:39 +0530, Ritesh Raj Sarraf wrote: > This package is just one single shell script. But an important one. The > rescan-scsi-bus.sh script helps a lot in the SAN space where there could > be targets with sporadic connecitons. Is it okay to package a single > shell script as a package? This is already packaged in scsitools! Regards, Stephen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110423183544.02de7...@sk2.org
Re: howto modify dependencies?
Hi Hans! At first: This is a support question and properly better suited for debian-user@ or its local off-springs. A german one is available, too! debian-devel is for (suprise suprise) development discussions. (and i have cc'ed you in this mail, which is against CoC…) On Sat, Apr 23, 2011 at 18:01, Hans-J. Ullrich wrote: > as I have trouble with the package ppp since version 2.4.5-*, and no one cared > although I filed a bugreport, I set the package to hold (version > 2.4.4-rel-10.1 > is working fine!) Does your bugreport include as much information as possible? Maybe if you tell us (read: debian-user not debian-devel) what your problems with ppp are someone can point you into the right direction. Pinging the maintainer helps sometimes, too. > However, as the old version is working fine, I am looking for a way, to > install > newer packages but hold the old ppp-version. I could still not manage it, > because of dependencies (which is logically). Neither with aptitude nor with > apt-get I found an option. Any hints? No option as ignoring dependencies is not an option (and not a good idea). What you can do is 'apt-get build-dep' to install the build dependencies of a package and 'apt-get source' to get the source code. I would recommend to change the version in debian/changelog, after that you can build it, for the lazy people 'apt-get source -b' will work. You are out of luck if the source package depends on newer ppp than you have (obviously), so this will not work for ever - or even at all now. (in essence: you are starting your own more or less unsupportable backports) > Talking of aptitude just a simple question: "apt-get --purge remove 2.6.32-*" > is removing anything with "2.6.32-" in its name. But aptitude does not offer > this option, doesn't it? Is aptitude using some other syntax??? Note that "2.6.32-*" in apt-get is NOT a shell-like global but a regular expression! So it matches also "2.6.32", "2.6.32" and "226632"! Don't know if and how aptitude supports this or not through, not my cup of tea^Wpackage manager… Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTimxfE62wB8Zt=v2oske9coqyyf...@mail.gmail.com
MBF: packages using deprecated GnuTLS functions
Hello, I am currently trying to rebuild GnuTLS rdeps against GnuTLS 2.12, this offers the perfect opportunity for a MBF. ;-) The newer version of GnuTLS marks a couple of interfaces as deprecated, i.e. they will be removed in future versions of GnuTLS. Some of these are used in many packages. Instead of invoking a couple of functions to set connection parameters (gnutls_protocol_set_priority gnutls_cipher_set_priority gnutls_compression_set_priority gnutls_kx_set_priority gnutls_mac_set_priority etc.) a combined priority string (gnutls_priority_*) is used. The replacement functions are already available in squeeze (2.8.6). The MBF will probably touch about 60 packages, I will submit with severity normal. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/s4hb88-26e@argenau.downhill.at.eu.org
Re: Bug#623847: ITP: rescan-scsi-bus -- tool for reliable scsi hotplugging in linux
[Stephen Kitt] > This is already packaged in scsitools! Huh, I occasionally wondered whatever happened to 'scsiadd'. Guess its functionality was subsumed into scsitools. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110423185938.ga20...@p12n.org
Bug#623857: ITP: python-tracing -- Python debug tracing helper
Package: wnpp Severity: wishlist Owner: Lars Wirzenius * Package name: python-tracing Version : 0.3 Upstream Author : Lars Wirzenius * URL : http://liw.fi/tracing/ * License : GPL3+ Programming Lang: Python Description : Python debug tracing helper Provides the Python library 'tracing' to help with logging debug messages. This module provides a couple of functions for logging debug messages. It is sometimes practical to add a lot of debugging log messages to a program, but having them enabled all the time results in very large log files. Also, logging that much takes quite a bit of time. . This module provides a way to turn such debugging or tracing messages on and off, based on the filename they occur in. (Preliminary package at http://code.liw.fi/debian/pool/main/p/python-tracing/, but it needs cleaning up before an actual upload.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110423191420.5045.35149.report...@havelock.liw.fi
Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
On Sat, 23 Apr 2011 16:51:53 +0200, Adam Borowski wrote: > On Sat, Apr 23, 2011 at 12:29:39PM +0200, Goswin von Brederlow wrote: > > I would rather add a new architecture to dpkg for this. This does not > > mean that debian has to create a new port or that the packages have to > > stop being arch:all. But dpkg should know about it and be the one and > > only place packages query for the right multiarch triplet. Then you > > would use > >/usr/lib/$(dpkg-architecture -aw64-mingw32 -qDEB_HOST_MULTIARCH) > > when building your package. Problem solved. > > Sounds like a great idea to me! > > It would fix the inconsistency I mentioned in another branch of this thread. > > I'd use just "win32" and "win64" for short names of the architectures, since > we don't have i386-gcc, i386-clang and i386-tcc when all of them use glibc. > > Once it is hidden inside dpkg's bowels, the triplet might be even > i586-i686-w32-w64-w128-but-really-w32-klaatu-verata-nikto-mingw-w42. So if I understand things correctly that would mean using /usr/lib/win32 and /usr/lib/win64, regardless of the binutils/gcc triplet (which is fine as far as I'm concerned - all I'm wary of is changing the gcc triplet used upstream, see http://bugs.debian.org/622276 - obviously, Adam, you know about this, but others probably don't). Goswin, I take it you're advocating building _win32.deb packages (or something similar) - is that correct? I didn't even realise that would be possible without appropriate buildds... I know about “dpkg-buildpackage -a” or “pdebuild --architecture” for local rebuilds, but would rebuilding such a package be possible on the existing buildd network? Regards, Stephen signature.asc Description: PGP signature
Re: Bug#623847: ITP: rescan-scsi-bus -- tool for reliable scsi hotplugging in linux
On Sat, 23 Apr 2011 13:59:38 -0500, Peter Samuelson wrote: > [Stephen Kitt] > > This is already packaged in scsitools! > > Huh, I occasionally wondered whatever happened to 'scsiadd'. > Guess its functionality was subsumed into scsitools. Effectively, yes, although "subsumed" isn't quite appropriate - both scsiadd and scsitools required /proc/scsi/scsi which was removed from the default configuration in the linux-2.6 packages. scsiadd was never updated to cope with this change, and therefore ended up being removed; scsitools was (unfortunately not in time for Squeeze though). Regards, Stephen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110423230851.20dc1...@sk2.org
Buenos Días.
Buenos días, Yo soy el señor C.Y. Ling, director ejecutivo alterno de las operaciones de CITIC International Bank, de Hong Kong. Tengo una propuesta para que en la suma de cien y cinco millones de euros, después de la transferencia con éxito, vamos a compartir en la proporción de cuarenta para usted, sesenta y para mí. Vuelve a mí si los interesados para obtener más información. Atentamente, El Sr. C.Y. Ling.
Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
On Sat, 23 Apr 2011 16:38:57 +0200, Adam Borowski wrote: > On Sat, Apr 23, 2011 at 05:05:33AM -0500, Jonathan Nieder wrote: > > IIUC then the GNU triplet includes the choice of C library because > > binaries (e.g., libraries) compiled against mingw32 and mingw-w64 > > cannot be linked (i.e., they do not share ABI). Though I could easily > > be wrong. > > Note that the triplets used by mingw-w64 were carefully chosen to produce as > much confusion as possible. The two architectures: win32 and win64 have > both "w32" and "w64" in the name: > * i686-w64-mingw32 > * x86_64-w64-mingw32 “were carefully chosen” is perhaps a slight exaggeration (see http://bugs.debian.org/622276 for my understanding of how these triplets ended up being used), but I do admit it can be confusing. > The former is ABI-compatible not only with i586-mingw32msvc but also with > real msvc. I just tried all combinations of these three, even including > malloc()ing from an object compiled with one and free()ing from another. > > Everything seems to work fine [1]. I can confirm this too, as far as I've been able to determine the output of gcc-mingw32 in Debian is compatible with that of gcc-mingw-w64 when targeting Win32. > This is for C. C++ between MSVC10 and mingw32 is not ABI-compatible, but > even gcc breaks compatibility there completely every a few releases > (remember -c102 in gcc-4.0?) and in minor points more often. So does MSVC. > Our two mingw32 versions seem to be compatible with each other, though. I haven't checked this but I'll take your word for it. > > IIRC according to the multiarch spec, paths in Debian use "simplified" > > triplets (DEB_HOST_MULTIARCH) with i[3456...]86 replaced by i386. > > Including so much unnecessary detail about the default instruction set > > in the triplet is unusual (I know of no example other than x86). As > > you mention, in the ix86 case it causes problems so we work around it. > > Distinguishing between two ABI-compatible compilers would be even worse. > Fortunately, nothing started using these names yet, so it's a perfect moment > to discuss a common arch name. > > Currently, the following packages use i586-mingw32msvc: > * gcc-mingw32 > * mingw32 > * mingw32-binutils > * mingw32-ocaml > * mingw32-runtime > * nsis I'm hoping the mingw-w64 set of packages (mingw-w64, binutils-mingw-w64 and gcc-mingw-w64) will be good enough to replace gcc-mingw32, mingw32, mingw32-binutils and mingw32-runtime. I originally started working on mingw-w64 to get wine-gecko into the archive and thus allow wine packaging to resume, but it seemed to me a good time as well to work on cleaning up the whole set of mingw packages in Debian. I've sent patches to allow most of the reverse-build-dependencies of mingw32 or gcc-mingw32 to build using mingw-w64 (nsis, autorun4linuxcd, cpio, gzip, gnupg and win32-loader so far), and I'm working on the remaining two (mingw32-ocaml and libreoffice). Completing all this would mean the i586-mingw32msvc target could be forgotten entirely; no one outside Debian uses it (any more), upstream and others have switched to the -w64-mingw32 suffix. (See also http://bugs.debian.org/606825 for extensive discussion and a first patch for dpkg support.) > There's no need to use the same triplet for multiarch as for compiler, > so the new path might use something else. I don't care what, as long as > it's consistent between all of win32 in Debian. That's fine by me, regardless of whether mingw-w64 ends up being “all of win32 in Debian” or not! Regards, Stephen signature.asc Description: PGP signature
Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
Hi Stephen, On Fri, Apr 22, 2011 at 11:04:59PM +0200, Stephen Kitt wrote: > Unfortunately this appears to go against policy 9.1.1, which forbids packages > installing files into triplet-based directories under /usr/lib other > than /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH). Since the files I'm > thinking of aren't usable on any Debian architecture, they're provided as > "Architecture: all" packages and don't have a corresponding > DEB_HOST_MULTIARCH triplet. > Would it be acceptable to introduce an exception to policy allowing this? > Something along the lines of > An exception is granted for `Architecture: all' packages containing > libraries targeting platforms for which there is no Debian > architecture. Such packages may use their traditional triplet as > recognised by binutils and gcc. The current wording is quite deliberate in only allowing the use of these directories by packages of the given architecture, because one of the ideas to be explored in the future is introducing partial architectures for things like w64-mingw32 (or sparc64, or armv7+neon, or amd64+sse4) that aren't self-hosting but that it's interesting to build a subset of packages for (mostly libraries). So I would be opposed to making such a change in policy for the time being; I think cross-compilers should stick with the traditional cross-compiler directories and stay away from the multiarch directories until we have more practical experience with multiarch under our belts and can make some educated decisions about how we want this to all fit together. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110423214433.ga32...@virgil.dodds.net
Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
On Sat, Apr 23, 2011 at 11:19:24PM +0200, Stephen Kitt wrote:
> On Sat, 23 Apr 2011 16:51:53 +0200, Adam Borowski wrote:
> > On Sat, Apr 23, 2011 at 12:29:39PM +0200, Goswin von Brederlow wrote:
> > > I would rather add a new architecture to dpkg for this. This does not
> > > mean that debian has to create a new port or that the packages have to
> > > stop being arch:all. But dpkg should know about it and be the one and
> > > only place packages query for the right multiarch triplet. Then you
> > > would use
> > >/usr/lib/$(dpkg-architecture -aw64-mingw32 -qDEB_HOST_MULTIARCH)
> > > when building your package. Problem solved.
> >
> > Sounds like a great idea to me!
> >
> > It would fix the inconsistency I mentioned in another branch of this thread.
> >
> > I'd use just "win32" and "win64" for short names of the architectures, since
> > we don't have i386-gcc, i386-clang and i386-tcc when all of them use glibc.
> >
> > Once it is hidden inside dpkg's bowels, the triplet might be even
> > i586-i686-w32-w64-w128-but-really-w32-klaatu-verata-nikto-mingw-w42.
>
> So if I understand things correctly that would mean using /usr/lib/win32
> and /usr/lib/win64
I meant the short name (like "amd64" or "kfreebsd-i386"), as multiarch paths
use a longer string ("i386-linux-gnu" or "x86_64-kfreebsd-gnu").
Of course, the long name being short would be fine, too.
> regardless of the binutils/gcc triplet (which is fine as far as I'm
> concerned - all I'm wary of is changing the gcc triplet used upstream, see
> http://bugs.debian.org/622276 - obviously, Adam, you know about this, but
> others probably don't).
Sounds good.
> Goswin, I take it you're advocating building _win32.deb packages (or
> something similar) - is that correct?
An interesting idea.
Not sure if it gets us anything in the short term, though. There would be
problems with having to set up apt configuration for that arch, and arch:all
handles it adequately. Long-term, it can be good to have all binary code
labelled accordingly to architecture it belongs to.
I'd ask the dpkg guys and ftpmasters first.
> I didn't even realise that would be possible without appropriate
> buildds... I know about “dpkg-buildpackage -a” or “pdebuild
> --architecture” for local rebuilds, but would rebuilding such a package be
> possible on the existing buildd network?
Currently not but it's already in a better shape than openbios-{ppc,sparc}
which claim to be arch:all yet FTBFS on any architecture other than powerpc
or sparc.
Happy $holiday!
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
signature.asc
Description: Digital signature
Re: limits for package name and version (MBF alert: ... .deb filenames)
On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote: > I would like to see policy forbid the use of commit hashes in versions. > They aren't ordered, This seems like an odd reason to forbid them; should one also forbid strings such as 'pre', 'rc', 'lenny', 'squeeze' in version numbers also because they aren't ordered? Clearly they should only be used some way towards the right-hand end of the version number, with appropriate additional ordering hints before them, so that no false ordering is inferred, but that's a very different matter. Maybe policy should instead recommend explicitly that such ordering hints should accompany hashes. > and the information about exactly which commit the > snapshot was can be included in the changelog. True, but since git revisions can actually do much the same thing as the other typical components of a version string; that is, uniquely identify the set of changes making up a code archive, the version string does sound like the best place to put this sort of information. > Mercurial revision numbers should not be used either as they are not > consistent between repositories (they really were a stupid idea in a > distributed VCS). That does sound like a good reason to discourage use of Mercurial revision numbers. Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110423225208.gk4...@urchin.earth.li
Re: limits for package name and version (MBF alert: ... .deb filenames)
On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote: > I would like to see policy forbid the use of commit hashes in versions. > They aren't ordered, and the information about exactly which commit the > snapshot was can be included in the changelog. If you use "git describe", removing hashes is a bad idea. They are needed to identify the version. Version numbers that are not unique are worthless. A small portion of the hash is there only to disambiguate potential branches, ordering is provided by the number of commits: 0.9.0-a0-283-g1143071 means: tag "0.9.0-a0", with 283 revisions after it, from a branch whose head's hash starts with 1143071. If I take revision 282 and apply patch X, while you take the same revision but apply patch Y instead, we both would have the same version number if hash is not included. You can then checkout 0.9.0-a0-283-g1143071 in any repository that has my commits and you'll get that exact version. 0.9.0-a0-283 doesn't give you that. > Mercurial revision numbers should not be used either as they are not > consistent between repositories (they really were a stupid idea in a > distributed VCS). For Mercurial, you're probably right. Just upgrade to git :p -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
Re: limits for package name and version (MBF alert: ... .deb filenames)
On Sun, 2011-04-24 at 02:31 +0200, Adam Borowski wrote: > On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote: > > I would like to see policy forbid the use of commit hashes in versions. > > They aren't ordered, and the information about exactly which commit the > > snapshot was can be included in the changelog. > > If you use "git describe", removing hashes is a bad idea. > > They are needed to identify the version. Version numbers that are not > unique are worthless. If versions are not ordered without the inclusion of a commit hash, they are not ordered *with* it (except by chance). > A small portion of the hash is there only to disambiguate potential > branches, ordering is provided by the number of commits: > 0.9.0-a0-283-g1143071 means: tag "0.9.0-a0", with 283 revisions after it, > from a branch whose head's hash starts with 1143071. > > If I take revision 282 and apply patch X, while you take the same revision > but apply patch Y instead, we both would have the same version number if > hash is not included. But it is not possible for a branch head to be in two different positions at different times which 'git describe' will distinguish only by the hash, unless it is rebased. > You can then checkout 0.9.0-a0-283-g1143071 in any repository that has my > commits and you'll get that exact version. 0.9.0-a0-283 doesn't give you > that. [...] Last time I looked, policy required upstream source to be provided as tarballs, not VCS references. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: MBF: packages using deprecated GnuTLS functions
On 04/23/2011 08:07 PM, Andreas Metzler wrote: > Instead of invoking a couple of functions to set connection parameters > (gnutls_protocol_set_priority gnutls_cipher_set_priority > gnutls_compression_set_priority gnutls_kx_set_priority > gnutls_mac_set_priority etc.) a combined priority string > (gnutls_priority_*) is used. The replacement functions are already > available in squeeze (2.8.6). > > The MBF will probably touch about 60 packages, I will submit with > severity normal. I guess there is some documentation available which tells developers how to migrate to the new functions properly - please link to it in your bug reports. Cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db3b7b2.3000...@bzed.de
