detecting cutomized conffiles and debconf
Hello Mentors, to make the long story short this is an "how to deal existing conffiles and a new set of debconf questions to setup the package?" question. Now, the package is cpufrequtils and what I'd like to achieve is providing some nice debconf templates to configure /etc/default/cpufrequtils which will allow the user to set a boottime policy. At the same time I'd like to avoid annoying users who already customized their configuration (I assume they don't need to be questioned again) and obviously avoid overwriting their customized file. Which is the way to go? AFAICT debsums could help or maybe should I not make /etc/default/cpufrequtils a conffile and manually manage it? Thanks in advance -- mattia :wq! signature.asc Description: Digital signature
Re: libcpufreq and the small libsysfs transition
On Sun, Feb 12, 2006 at 02:19:08PM -0800, Steve Langasek wrote:
> On Sun, Feb 12, 2006 at 07:06:00PM +0100, Mattia Dongili wrote:
>
> > I need a quick suggestion how to handle libcpufreq{0,-dev} within the
> > libsysfs transition.
> > Facts:
> > - current cpufrequtils is compatible with both libsysfs1 and libsysfs2
> > - the source package depends on libsysfs-dev >= 1.0.0
> > - libcpufreq0 uses ${shlibs:Depends} to build dependencies
>
> > Now, my understanding is that a binNMU is sufficient to rebuild binaries
> > and fill the correct dependencies?
>
> Looks like it to me.
>
> > If so, is pinging about it [EMAIL PROTECTED] usually sufficient to
> > ask request the binNMU?
>
> Yes.
Ooops :)
My mail was indended as just a "suggestion" on how to proceed, I was
waiting the availability of libsysfs2 in sid before actually pinging
debian-release@ for the binNMU.
I did see that the package was rebuilt on 02/12 actually :)
Apologies for not being clear enough...
--
mattia
:wq!
signature.asc
Description: Digital signature
libcpufreq and the small libsysfs transition
Hello,
I need a quick suggestion how to handle libcpufreq{0,-dev} within the
libsysfs transition.
Facts:
- current cpufrequtils is compatible with both libsysfs1 and libsysfs2
- the source package depends on libsysfs-dev >= 1.0.0
- libcpufreq0 uses ${shlibs:Depends} to build dependencies
Now, my understanding is that a binNMU is sufficient to rebuild binaries
and fill the correct dependencies?
If so, is pinging about it [EMAIL PROTECTED] usually sufficient to
ask request the binNMU?
Thanks
--
mattia
:wq!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with libraries and soname and python
On Sat, Aug 06, 2005 at 09:34:37AM -0700, Steve Langasek wrote: > On Sat, Aug 06, 2005 at 02:28:32PM +0200, Mattia Dongili wrote: > > On Sat, Aug 06, 2005 at 01:01:12PM +0200, Ghe Rivero wrote: > > [...] > > > Apart of this, i also hve python bindings: > > > python2.3-libsome: > > > /usr/lib/python2.3/site-packages/libsomemodule.la > > > /usr/lib/python2.3/site-packages/libsome.so > > > > And i have this on lintian: > > > > W: python2.3-libsome: package-name-doesnt-match-sonames libsomemodule.so > > > I have the same with cpufreqd, I think the warning in this cases > > (/usr/lib/ with "architecture-dependent data exclusively > > used by the application" -FHS 4.4-) should be suppressed. > > Such modules shouldn't actually have SONAMEs at all; perhaps fixing the > build to not include an SONAME for something that isn't a shared library > would make this warning go away. Ok, I've been reading docs for a while now... can anybody help on how to avoid SONAME using libtool and friends? (I'm already giving it the -module and -avoid-version flags but it still links with -Wl,-soname -Wl,cpufreqd_blabla.so) thanks -- mattia :wq! signature.asc Description: Digital signature
Re: Problems with libraries and soname and python
On Sat, Aug 06, 2005 at 01:01:12PM +0200, Ghe Rivero wrote: [...] > Apart of this, i also hve python bindings: > python2.3-libsome: > /usr/lib/python2.3/site-packages/libsomemodule.la > /usr/lib/python2.3/site-packages/libsome.so > > And i have this on lintian: > > W: python2.3-libsome: package-name-doesnt-match-sonames libsomemodule.so I have the same with cpufreqd, I think the warning in this cases (/usr/lib/ with "architecture-dependent data exclusively used by the application" -FHS 4.4-) should be suppressed. So I submitted #321564 :) -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: library files are not included in the .deb files
On Sat, Jul 09, 2005 at 02:13:58PM -0400, kamaraju kusumanchi wrote:
> I am trying to package a library whose upstream is located at
> http://sourceforge.net/projects/fortranposix
>
>
> I already read the libpkg-guide, maint-guide. This problem was not
> discussed in any of them. I googled and also asked in the irc about this
> problem.
>
> There were no errors/warnings when I checked the final packages with
> linda -i and lintian -i. But when I did dpkg -c, there are no libraries
> in the packages.
maybe it's just something wrong within your
debian/.{install,dirs,whatever} files (if you're using
debhelper scripts
[...]
> $dpkg -c libfortranposix0-dev_0.1-1_i386.deb
> drwxr-xr-x root/root 0 2005-07-09 13:46:00 ./
> drwxr-xr-x root/root 0 2005-07-09 13:46:00 ./usr/
> drwxr-xr-x root/root 0 2005-07-09 13:45:59 ./usr/bin/
> drwxr-xr-x root/root 0 2005-07-09 13:45:59 ./usr/sbin/
/usr/sbin and /usr/sbin are useless, don't create them. They look like
the default entries for the dirs file created by dh_make :)
[...]
> make[1]: Leaving directory `/home/rajulocal/practice/fortranposix-0.1'
> dh_testdir
> dh_testroot
> dh_installchangelogs CHANGES
> dh_installdocs
> dh_installexamples
> dh_installman
> dh_link
> dh_strip
> dh_compress
> dh_fixperms
> dh_installdeb
> dh_shlibdeps
> dh_gencontrol
> dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> dh_md5sums
> dh_builddeb
> dpkg-deb: building package `libfortranposix0-dev' in
> `../libfortranposix0-dev_0.1-1_i386.deb'.
> dpkg-deb: building package `libfortranposix0' in
> `../libfortranposix0_0.1-1_i386.deb'.
> signfile fortranposix_0.1-1.dsc
can't see dh_install in the above list, might be the problem?
Could you eventually put your debian/* scrips somewhere to give them a
look?
--
mattia
:wq!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: need some uploads :))
On Sun, Apr 24, 2005 at 09:01:23PM +0200, Mattia Dongili wrote:
> On Sun, Apr 24, 2005 at 08:48:41PM +0200, Mattia Dongili wrote:
> > On Mon, Apr 18, 2005 at 10:32:31PM +0200, giskard wrote:
> > [...]
> > > - nvu (www.autistici.org/giskard/file/frankie/)
h...
#binary
mkdir -p /tmp/buildd/nvu-1.0pre/debian/nvu/usr/{lib,bin}
cp -r /tmp/buildd/nvu-1.0pre/debian/install/usr/bin
/tmp/buildd/nvu-1.0pre/debian/nvu/usr/
mkdir -p /tmp/buildd/nvu-1.0pre/debian/nvu/usr/share/pixmaps/
cp debian/nvu.xpm /tmp/buildd/nvu-1.0pre/debian/nvu/usr/share/pixmaps/
mkdir -p /tmp/buildd/nvu-1.0pre/debian/usr/share/applications/
cp debian/*.desktop /tmp/buildd/nvu-1.0pre/debian/nvu/usr/share/applications/
cp: cannot create regular file
`/tmp/buildd/nvu-1.0pre/debian/nvu/usr/share/applications/nvu.desktop':
No such file or directory
make: *** [install] Error 1
--
mattia
:wq!
signature.asc
Description: Digital signature
Re: need some uploads :))
On Sun, Apr 24, 2005 at 08:48:41PM +0200, Mattia Dongili wrote: > On Mon, Apr 18, 2005 at 10:32:31PM +0200, giskard wrote: > [...] > > - nvu (www.autistici.org/giskard/file/frankie/) uh, and last but not least, from the nvu qa page: ,--- | There were override disparities found in suite unstable: |* nvu-dev: Override says devel - optional, .deb says web - optional `--- bye -- mattia :wq! signature.asc Description: Digital signature
Re: need some uploads :))
On Mon, Apr 18, 2005 at 10:32:31PM +0200, giskard wrote: [...] > - nvu (www.autistici.org/giskard/file/frankie/) some notes: - be careful with the version you chose: # dpkg --compare-versions 1.0pre '>' 1.0 && echo $? 0 so you could have problems when later packaging 1.0 A known strategy for those kind of versions is using a name like '0.99+1.0pre' - you are closing #304913 which is not nvu's bug. :) You probably meant 304912 but nvu-dev conflicts against libsprd-dev which does not exists :) typo? Also why not using diversions if only a single file is the problem (just an m4 macros file...)? - remember your sponsor to build with '-v0.80-4' to catch all closed bugs - why not removing the obsoleted xlibs-dev build-dep favouring single lib packages from xfree? - you should probably close also #304522 nvu is building right now, will be back later with more if necessary. ciao -- mattia :wq! signature.asc Description: Digital signature
Re: CDBS and DESTDIR
On Tue, Mar 22, 2005 at 05:13:38PM -0300, Nelson A. de Oliveira wrote: > Hi > > Mattia Dongili wrote: > >some (hopefully) usefull notes: > >- why are you trying to install 'bin/ali2gff' instead of 'ali2gff' only? > > Because all binary files are on bin/ directory. yes but you're already mentioning the 'bin' directory in the last part of your install invocation. Quoting your diff: /usr/bin/install -s -m 755 bin/ali2gff $(DESTDIR)/bin/ ^^^ > >- why not using /usr/bin/install for everything when copying files, it has > > useful features, eg: > > -D create all leading components of DEST except the last, then > > copy SOURCE to DEST; useful in the 1st format > > (please see the full manpage for the install command, this is just a > > hint for the nonexisting /tmp/bin/ above) > > Because there is only one binary file. The other files are perl scripts. > Install says something about not possible to strip the perl files. of course it isn't, read the install manpage and look for the -s option... simply avoid it -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CDBS and DESTDIR
On Tue, Mar 22, 2005 at 01:45:25PM -0300, Nelson A. de Oliveira wrote: > Hi > > Arjan Oosting wrote: > >Op di, 22-03-2005 te 12:04 -0300, schreef Nelson A. de Oliveira: [...] > Since it doesn't have DESTDIR, I have created a patch (available here: > http://biolinux.df.ibilce.unesp.br/naoliv/cdbs/01-makefile.diff) > > The patch is being applied OK. Using dpkg-buildpackage gives: > > /usr/bin/install -s -m 755 bin/ali2gff /bin/ > /usr/bin/install: cannot create regular file `/bin/ali2gff': Permission > denied > > But with "make install DESTDIR=/tmp", the DESTDIR variable is OK: > > /usr/bin/install -s -m 755 bin/ali2gff /tmp/bin/ > /usr/bin/install: cannot create regular file `/tmp/bin/': Is a directory > > It gaves an error, since there was no directory bin on /tmp, but the > DESTDIR was passed OK! some (hopefully) usefull notes: - why are you trying to install 'bin/ali2gff' instead of 'ali2gff' only? - why not using /usr/bin/install for everything when copying files, it has useful features, eg: -D create all leading components of DEST except the last, then copy SOURCE to DEST; useful in the 1st format (please see the full manpage for the install command, this is just a hint for the nonexisting /tmp/bin/ above) last but not least you could set up DESTDIR this way: INSTALLDIR = $(DESTDIR)$(LBIN) at the beginning of the Makefile, then you can forget it :) then either use /usr/bin/install as said above or leave the original $(CP) and create the $(INSTALLDIR) yourself with mkdir in the installbin target. Change LBIN to fit your needs and you're done (maybe you want to install under /usr/bin actually, not /bin) hth -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS[2]: cpufrequtils (comments on packaging also welcome)
On Wed, Jan 12, 2005 at 12:59:38AM +0100, Achim Bohnet wrote:
> On Friday 07 January 2005 22:03, Mattia Dongili wrote:
[...]
> > Hopefully many of the existing cpufreq related daemons will soon use
> > the provided library (cpufreqd is migrating at least).
>
> Any comment from the cpudyn upstream yet?
No, I've seen a patch to migrate cpuspeed but that tool is not in Debian
(yet?)
[...]
> > Last but not least comments on packaging are welcome. :)
>
> o why not libcpufreq0-dev as suggested at
> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
> At least with libcpufreq1 you will need something like libcpufreq1-dev
> otherwise one can't build pkg depending on libcpufreq0 interface anymore
Actually reading one ot the latest topics on d-devel[1] I'm pretty
convinced that having only one -dev package is better. Also, I'm
upstream for cpufreqd so I can keep it up-to-date and I like coding:
patches for outdated pkgs will flw :)
[1]: http://lists.debian.org/debian-devel/2005/01/msg00623.html
or better
http://lists.debian.org/debian-devel/2005/01/msg00695.html
> o AUTHOR, NEWS file isn't included. Btw. AUTHOR file and upstream in
> debian/copyright do not match. You are too humble ;)
uh :) right (/me turning red)
> o -dev pkg should depend on the libcpufreq0 (= ${Source-Version})
>
> o just wondering: tarball comes precompiled .mo files. Are they
> cpu architecture independent?
Hummm, I documented myself a (very) little and I'd say they are... but I
may be plainly wrong, so I'll continue my self documentation on the
subject
> o cpufreq.h is GPL 'V2 or later' no only GPL V2. Is just
> 'Licensed under the terms of the GNU GPL License version 2' in .c
> files enough?
I'll ping upstream on this issue.
Thanks for your comments, I'll keep your suggestion for the next pkg
revision
> --
> To me vi is Zen. To use vi is to practice zen. Every command is
> a koan. Profound to the user, unintelligible to the uninitiated.
> You discover truth everytime you use it.
:)
--
mattia
:wq!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS[2]: cpufrequtils (comments on packaging also welcome)
On Fri, Jan 07, 2005 at 10:58:00PM +0100, Erik Schanze wrote: > Hi Mattia! > > Mattia Dongili <[EMAIL PROTECTED]>: > > i386 bins and sources available here: > > deb http://oioio.altervista.org/debian binary/ > > deb-src http://oioio.altervista.org/debian source/ > > > There is cpufrequtils_0.1-1.diff.gz? yes, it's there[1]. If you browsed the pages you probably missed it because files are not arranged alphabetically (it's a fake directory browsing written in PHP... sorry... going to fix it). [1]: http://oioio.altervista.org/debian/source/cpufrequtils_0.1-1.diff.gz PS: pyro already answered privately my RFS. -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS[2]: cpufrequtils (comments on packaging also welcome)
Hello, this is the second call for sponsors for cpufrequtils, a useful (hint, sponsor me - sponsor me :)) package with utilities to deal with cpufreq interface (it contains command line utilities and a shared library). Hopefully many of the existing cpufreq related daemons will soon use the provided library (cpufreqd is migrating at least). i386 bins and sources available here: deb http://oioio.altervista.org/debian binary/ deb-src http://oioio.altervista.org/debian source/ The original ITP is 278767. Last but not least comments on packaging are welcome. :) Thanks -- mattia :wq! signature.asc Description: Digital signature
Temporary sponsor for cpufreqd
Hello, as my usual sponsor is on vacation I'm looking for a temporary sponsor for my current cpufreqd package revision (1.2.2-2). The new revision closes two bugs: * Renamed debian/po/cz.po into debian/po/cs.po (closes: #285570) * Now conflicts with cpudyn and powernowd (closes: #281065) source and i386 binaries can be found using the following repository: deb http://oioio.altervista.org/debian binary/ deb-src http://oioio.altervista.org/debian source/ thanks -- mattia :wq! signature.asc Description: Digital signature
RFS: cpufrequtils -- Shared library and utilities to deal with the CPUFreq Linux kernel feature
Hello, I'm looking for a sponsor[1] for the package cpufrequtils[2], source packages are available here: deb-src http://oioio.altervista.org/debian source/ and i386 binaries here: deb http://oioio.altervista.org/debian binary/ Both are built in a sid environment and lintian clean. thanks a lot to anybody wishing to sponsor this package (cpufreqd will also depend on libcpufreq0 soon). [1]: I've been in the NM queue for so long that I'll hopefully need a sponsor for a short time only :) [2]: some info stolen (and corrected) from my previous ITP: * Package name: cpufrequtils Version : 0.1 Upstream Author : Dominik Brodowski <[EMAIL PROTECTED]> * URL : http://kernel.org/pub/linux/utils/kernel/cpufreq/ * License : GPL v2 Description : Shared library and utilities to deal with the cpufreq linux kernel feature This package will generate 3 packages: * Package name: cpufrequtils This package contains two utilities for inspecting and setting the cpu frequency through both the sysfs and procfs CPUFreq kernel interfaces. * Package name: libcpufreq0 This library provide an unified method to access the CPUFreq kernel interface. * Package name: libcpufreq-dev This package provides everything that is needed for developing own programs using libcpufreq. -- mattia :wq! signature.asc Description: Digital signature
Re: Temporary sponsor for cpufreqd_1.1.2-3 (fixes an RC bug)
On Sat, Aug 07, 2004 at 08:07:38PM +0200, David Weinehall wrote: > On Sat, Aug 07, 2004 at 07:31:47PM +0200, Mattia Dongili wrote: [...] > > Can somebody help? the package is here: > > http://oioio.altervista.org/debian/ [1] > > I'll sponsor you. I still feel sort of guilty for slowing down your > NM application, and I'm using cpufreqd anyway... lol :) thanks, and don't worry about that. bye -- mattia :wq!
Temporary sponsor for cpufreqd_1.1.2-3 (fixes an RC bug)
Hi, the guy who usually uploads cpufreqd for me is not answering my mails (in the last 2 weeks, maybe he's on vacation). I have a new revision of the package that fixes an RC bug and I'd like the package to be in the right place at the right time (as in Freeze time!). Can somebody help? the package is here: http://oioio.altervista.org/debian/ [1] thanks in advance [1] full URLs: http://oioio.altervista.org/debian/cpufreqd_1.1.2-3.diff.gz http://oioio.altervista.org/debian/cpufreqd_1.1.2-3.dsc http://oioio.altervista.org/debian/cpufreqd_1.1.2-3_i386.changes http://oioio.altervista.org/debian/cpufreqd_1.1.2-3_i386.deb http://oioio.altervista.org/debian/cpufreqd_1.1.2.orig.tar.gz -- mattia :wq!
Re: Temporary sponsor for cpufreqd_1.1.2-3 (fixes an RC bug)
On Sat, Aug 07, 2004 at 08:07:38PM +0200, David Weinehall wrote: > On Sat, Aug 07, 2004 at 07:31:47PM +0200, Mattia Dongili wrote: [...] > > Can somebody help? the package is here: > > http://oioio.altervista.org/debian/ [1] > > I'll sponsor you. I still feel sort of guilty for slowing down your > NM application, and I'm using cpufreqd anyway... lol :) thanks, and don't worry about that. bye -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Temporary sponsor for cpufreqd_1.1.2-3 (fixes an RC bug)
Hi, the guy who usually uploads cpufreqd for me is not answering my mails (in the last 2 weeks, maybe he's on vacation). I have a new revision of the package that fixes an RC bug and I'd like the package to be in the right place at the right time (as in Freeze time!). Can somebody help? the package is here: http://oioio.altervista.org/debian/ [1] thanks in advance [1] full URLs: http://oioio.altervista.org/debian/cpufreqd_1.1.2-3.diff.gz http://oioio.altervista.org/debian/cpufreqd_1.1.2-3.dsc http://oioio.altervista.org/debian/cpufreqd_1.1.2-3_i386.changes http://oioio.altervista.org/debian/cpufreqd_1.1.2-3_i386.deb http://oioio.altervista.org/debian/cpufreqd_1.1.2.orig.tar.gz -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[REPOST] RFS: libmqueue - POSIX message queues library for Linux
Hi all, I'm looking for a sponsor for libmqueue, POSIX message queues userspace library (see also [1] for a little discussion about the package). The package is ready at [2]. It is lintian/linda clean and builds correctly in a sid chroot (pbuilder). Is anybody interested? [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=260222 [2]: http://oioio.altervista.org/debian/ Here's the control file of the shared library package: Package: libmqueue4 Version: 4.41-1 Section: libs Priority: optional Architecture: i386 Depends: libc6 (>= 2.3.2.ds1-4) Installed-Size: 32 Maintainer: Mattia Dongili (ma.d.) <[EMAIL PROTECTED]> Source: libmqueue Description: POSIX message queues library for Linux POSIX message queues are part of IPC used to exchange messages between processes. Since 2.6.6-rc1 it has been included into Linux kernel. Message queues are implemented as a filesystem called mqueue. Library adds appropriate interface to a mqueue filesystem which is compliant with POSIX standard (IEEE Std 1003.1-2001). thanks in advance -- mattia :wq! signature.asc Description: Digital signature
[REPOST] RFS: libmqueue - POSIX message queues library for Linux
Hi all, I'm looking for a sponsor for libmqueue, POSIX message queues userspace library (see also [1] for a little discussion about the package). The package is ready at [2]. It is lintian/linda clean and builds correctly in a sid chroot (pbuilder). Is anybody interested? [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=260222 [2]: http://oioio.altervista.org/debian/ Here's the control file of the shared library package: Package: libmqueue4 Version: 4.41-1 Section: libs Priority: optional Architecture: i386 Depends: libc6 (>= 2.3.2.ds1-4) Installed-Size: 32 Maintainer: Mattia Dongili (ma.d.) <[EMAIL PROTECTED]> Source: libmqueue Description: POSIX message queues library for Linux POSIX message queues are part of IPC used to exchange messages between processes. Since 2.6.6-rc1 it has been included into Linux kernel. Message queues are implemented as a filesystem called mqueue. Library adds appropriate interface to a mqueue filesystem which is compliant with POSIX standard (IEEE Std 1003.1-2001). thanks in advance -- mattia :wq! signature.asc Description: Digital signature
RFS: libmqueue - POSIX message queues library for Linux
Hi all, I'm looking for a sponsor for libmqueue, POSIX message queues userspace library (see also [1] for a little discussion about the package). The package is ready at [2]. It is lintian/linda clean and builds correctly in a sid chroot (pbuilder). [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=260222 [2]: http://oioio.altervista.org/debian/ Here's the control file of the shared library package: Package: libmqueue4 Version: 4.41-1 Section: libs Priority: optional Architecture: i386 Depends: libc6 (>= 2.3.2.ds1-4) Installed-Size: 32 Maintainer: Mattia Dongili (ma.d.) <[EMAIL PROTECTED]> Source: libmqueue Description: POSIX message queues library for Linux POSIX message queues are part of IPC used to exchange messages between processes. Since 2.6.6-rc1 it has been included into Linux kernel. Message queues are implemented as a filesystem called mqueue. Library adds appropriate interface to a mqueue filesystem which is compliant with POSIX standard (IEEE Std 1003.1-2001). thanks in advance -- mattia :wq! signature.asc Description: Digital signature
RFS: libmqueue - POSIX message queues library for Linux
Hi all, I'm looking for a sponsor for libmqueue, POSIX message queues userspace library (see also [1] for a little discussion about the package). The package is ready at [2]. It is lintian/linda clean and builds correctly in a sid chroot (pbuilder). [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=260222 [2]: http://oioio.altervista.org/debian/ Here's the control file of the shared library package: Package: libmqueue4 Version: 4.41-1 Section: libs Priority: optional Architecture: i386 Depends: libc6 (>= 2.3.2.ds1-4) Installed-Size: 32 Maintainer: Mattia Dongili (ma.d.) <[EMAIL PROTECTED]> Source: libmqueue Description: POSIX message queues library for Linux POSIX message queues are part of IPC used to exchange messages between processes. Since 2.6.6-rc1 it has been included into Linux kernel. Message queues are implemented as a filesystem called mqueue. Library adds appropriate interface to a mqueue filesystem which is compliant with POSIX standard (IEEE Std 1003.1-2001). thanks in advance -- mattia :wq! signature.asc Description: Digital signature
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Mon, Jun 21, 2004 at 04:14:07PM +0200, Andreas Metzler wrote: > On Mon, Jun 21, 2004 at 11:51:03AM +0100, Colin Watson wrote: [...] > > It doesn't matter what the source package says anyway. In order to get > > s390 to stop building it, you need to get it added to > > Packages-arch-specific. > > That is not completely correct. > > Using 'Architecture: [!s390]' accomplishes some things: > > * no accidental (manual?) build on s390. > * the autobuilders will not *successfully* build it. (The buildlog > will say something like 's390 not in list of supported archs') > * it serves for documentation. > > An (additional) entry in Packages-Arch-Specific is just cleaner and > nicer, because the buildd will not even /try/ to build the package. I based my assumption on the fact that xserver-xfree86 has 'Architecture: any' and an entry in Packages-arch-specific. I'm a little confused now. > And all this is orthogonal to the requirement that the existing s390 > binaries in archive need to *also* be removed, using a bug-report > against ftp.debian.org. fine, I'll submit the bug asap -- mattia :wq!
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Mon, Jun 21, 2004 at 04:14:07PM +0200, Andreas Metzler wrote: > On Mon, Jun 21, 2004 at 11:51:03AM +0100, Colin Watson wrote: [...] > > It doesn't matter what the source package says anyway. In order to get > > s390 to stop building it, you need to get it added to > > Packages-arch-specific. > > That is not completely correct. > > Using 'Architecture: [!s390]' accomplishes some things: > > * no accidental (manual?) build on s390. > * the autobuilders will not *successfully* build it. (The buildlog > will say something like 's390 not in list of supported archs') > * it serves for documentation. > > An (additional) entry in Packages-Arch-Specific is just cleaner and > nicer, because the buildd will not even /try/ to build the package. I based my assumption on the fact that xserver-xfree86 has 'Architecture: any' and an entry in Packages-arch-specific. I'm a little confused now. > And all this is orthogonal to the requirement that the existing s390 > binaries in archive need to *also* be removed, using a bug-report > against ftp.debian.org. fine, I'll submit the bug asap -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Mon, Jun 21, 2004 at 12:22:22PM +0100, Colin Watson wrote: > On Mon, Jun 21, 2004 at 01:05:18PM +0200, Mattia Dongili wrote: > > I'm trying to contact ftpmaters asking them to add > > xfree86-driver-synaptics to Packages-arch-specific with an '!s390' entry > > (as xsever-xfree86 has the same entry there) and to remove the s390 > > binary. > > > > I haven't submitted a bug since this is not a 'complete' removal (as > > read on devel-ref 5.9.2) but I wrote to them directly ([EMAIL PROTECTED]). > > Am I wrong wrt to this procedure? > > The file itself > (http://buildd.debian.org/quinn-diff/Packages-arch-specific) lists a > contact procedure at the top. doh! I realized it too late... In the first place I thought ftpmasters were responsible for it. I have to stop thinking :) -- mattia :wq!
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Mon, Jun 21, 2004 at 12:32:05PM +0200, Andreas Metzler wrote: > On 2004-06-07 Mattia Dongili <[EMAIL PROTECTED]> wrote: > > On Tue, May 11, 2004 at 10:03:04AM +0200, Andreas Metzler wrote: > > > On 2004-05-11 Mattia Dongili <[EMAIL PROTECTED]> wrote: > > > [...] > > > > Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 > [...] > > > Personally I'd immediately change the architecture field and change it > > > back once there is a xserver for s390. - You'll probably have to > > > pester ftp-master to remove the old s390 binary, otherwise > > > xfree86-driver-synaptics will be blocked by "out of date on s390". > > > I finally opted for this solution. > [...] > > Hello, > May I ask for status update? herm... sorry, after the suggestion from Steve Lagasek[1] I changed my mind a little (I understood the usefullness of Packages-arch-specific), see below > You have uploaded 0.13.3-1 yesterday with still "Architecture: any" > and it has therefore built and been uploaed by s390 *again*. > Futhermore there is still no request for removing the s390 binaries > from the archive on http://bugs.debian.org/ftp.debian.org I'm trying to contact ftpmaters asking them to add xfree86-driver-synaptics to Packages-arch-specific with an '!s390' entry (as xsever-xfree86 has the same entry there) and to remove the s390 binary. I haven't submitted a bug since this is not a 'complete' removal (as read on devel-ref 5.9.2) but I wrote to them directly ([EMAIL PROTECTED]). Am I wrong wrt to this procedure? thanks [1]: http://lists.debian.org/debian-mentors/2004/06/msg00147.html -- mattia :wq!
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Mon, Jun 21, 2004 at 12:22:22PM +0100, Colin Watson wrote: > On Mon, Jun 21, 2004 at 01:05:18PM +0200, Mattia Dongili wrote: > > I'm trying to contact ftpmaters asking them to add > > xfree86-driver-synaptics to Packages-arch-specific with an '!s390' entry > > (as xsever-xfree86 has the same entry there) and to remove the s390 > > binary. > > > > I haven't submitted a bug since this is not a 'complete' removal (as > > read on devel-ref 5.9.2) but I wrote to them directly ([EMAIL PROTECTED]). > > Am I wrong wrt to this procedure? > > The file itself > (http://buildd.debian.org/quinn-diff/Packages-arch-specific) lists a > contact procedure at the top. doh! I realized it too late... In the first place I thought ftpmasters were responsible for it. I have to stop thinking :) -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Mon, Jun 21, 2004 at 12:32:05PM +0200, Andreas Metzler wrote: > On 2004-06-07 Mattia Dongili <[EMAIL PROTECTED]> wrote: > > On Tue, May 11, 2004 at 10:03:04AM +0200, Andreas Metzler wrote: > > > On 2004-05-11 Mattia Dongili <[EMAIL PROTECTED]> wrote: > > > [...] > > > > Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 > [...] > > > Personally I'd immediately change the architecture field and change it > > > back once there is a xserver for s390. - You'll probably have to > > > pester ftp-master to remove the old s390 binary, otherwise > > > xfree86-driver-synaptics will be blocked by "out of date on s390". > > > I finally opted for this solution. > [...] > > Hello, > May I ask for status update? herm... sorry, after the suggestion from Steve Lagasek[1] I changed my mind a little (I understood the usefullness of Packages-arch-specific), see below > You have uploaded 0.13.3-1 yesterday with still "Architecture: any" > and it has therefore built and been uploaed by s390 *again*. > Futhermore there is still no request for removing the s390 binaries > from the archive on http://bugs.debian.org/ftp.debian.org I'm trying to contact ftpmaters asking them to add xfree86-driver-synaptics to Packages-arch-specific with an '!s390' entry (as xsever-xfree86 has the same entry there) and to remove the s390 binary. I haven't submitted a bug since this is not a 'complete' removal (as read on devel-ref 5.9.2) but I wrote to them directly ([EMAIL PROTECTED]). Am I wrong wrt to this procedure? thanks [1]: http://lists.debian.org/debian-mentors/2004/06/msg00147.html -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Thu, Jun 10, 2004 at 10:20:58AM -0500, Steve Langasek wrote: > On Thu, Jun 10, 2004 at 05:09:53PM +0200, Mattia Dongili wrote: [...] > > sorry for being so pedantic. Today a bug has been submitted (#253616) > > regarding this issue. The submitter states that the control file for > > xfree86 states xserver-xfree86 is > > Architecture: alpha amd64 arm hppa hurd-i386 i386 ia64 m68k mips mipsel > >netbsd-i386 powerpc sh3 sh4 sparc > > > but xserver-xfree86 is only available on alpha arm hppa i386 ia64 m68k > > mips mipsel powerpc sparc [1] > > > so removing only s390 from the Architecture field of > > xfree86-driver-synaptics may not be enough, right? So the correct > > solution would be to only Suggest: xserver-xfree86 (>> 4.1.0) > > No, the correct solution is to ensure the xfree86-driver-synaptics > package isn't built on architectures where it's known to be useless. I understand this. [...] > The other architectures in the xfree86 control file can be ignored -- > they don't have autobuilders that are uploading to the archive. ok. My question was mainly due to the fact that I wasn't aware of the fact that some architectures are ignored. I was worried by the fact a missing xserver-xfree86 on let's say amd64 would raise the same problem I'm having here with s390. I hope I've been clearer, thanks :) -- mattia :wq! signature.asc Description: Digital signature
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Thu, Jun 10, 2004 at 10:20:58AM -0500, Steve Langasek wrote: > On Thu, Jun 10, 2004 at 05:09:53PM +0200, Mattia Dongili wrote: [...] > > sorry for being so pedantic. Today a bug has been submitted (#253616) > > regarding this issue. The submitter states that the control file for > > xfree86 states xserver-xfree86 is > > Architecture: alpha amd64 arm hppa hurd-i386 i386 ia64 m68k mips mipsel > >netbsd-i386 powerpc sh3 sh4 sparc > > > but xserver-xfree86 is only available on alpha arm hppa i386 ia64 m68k > > mips mipsel powerpc sparc [1] > > > so removing only s390 from the Architecture field of > > xfree86-driver-synaptics may not be enough, right? So the correct > > solution would be to only Suggest: xserver-xfree86 (>> 4.1.0) > > No, the correct solution is to ensure the xfree86-driver-synaptics > package isn't built on architectures where it's known to be useless. I understand this. [...] > The other architectures in the xfree86 control file can be ignored -- > they don't have autobuilders that are uploading to the archive. ok. My question was mainly due to the fact that I wasn't aware of the fact that some architectures are ignored. I was worried by the fact a missing xserver-xfree86 on let's say amd64 would raise the same problem I'm having here with s390. I hope I've been clearer, thanks :) -- mattia :wq! signature.asc Description: Digital signature
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Mon, Jun 07, 2004 at 12:56:50PM +0200, Andreas Metzler wrote: > On 2004-06-07 Mattia Dongili <[EMAIL PROTECTED]> wrote: > > On Tue, May 11, 2004 at 10:03:04AM +0200, Andreas Metzler wrote: > [...] > > > Personally I'd immediately change the architecture field and change it > > > back once there is a xserver for s390. - You'll probably have to > > > pester ftp-master to remove the old s390 binary, otherwise > > > xfree86-driver-synaptics will be blocked by "out of date on s390". > > > I finally opted for this solution. The package is ready to be uploaded, > > but how am I supposed to proceed now? ask for removal first and then > > upload or the opposite? > > Do both instead of waiting. There is no problem if the s390 buildd > tries to build xfree86-driver-synaptics before the binary has been > removed (and xfree86-driver-synaptics has been added to > http://buildd.debian.org/quinn-diff/Packages-arch-specific), the build > will simply fail because dpkg-buildpackage (or is it sbuild?) checks > the architecture field. sorry for being so pedantic. Today a bug has been submitted (#253616) regarding this issue. The submitter states that the control file for xfree86 states xserver-xfree86 is Architecture: alpha amd64 arm hppa hurd-i386 i386 ia64 m68k mips mipsel netbsd-i386 powerpc sh3 sh4 sparc but xserver-xfree86 is only available on alpha arm hppa i386 ia64 m68k mips mipsel powerpc sparc [1] so removing only s390 from the Architecture field of xfree86-driver-synaptics may not be enough, right? So the correct solution would be to only Suggest: xserver-xfree86 (>> 4.1.0) [1]: http://packages.debian.org/unstable/x11/xserver-xfree86 -- mattia :wq!
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Mon, Jun 07, 2004 at 12:56:50PM +0200, Andreas Metzler wrote: > On 2004-06-07 Mattia Dongili <[EMAIL PROTECTED]> wrote: > > On Tue, May 11, 2004 at 10:03:04AM +0200, Andreas Metzler wrote: > [...] > > > Personally I'd immediately change the architecture field and change it > > > back once there is a xserver for s390. - You'll probably have to > > > pester ftp-master to remove the old s390 binary, otherwise > > > xfree86-driver-synaptics will be blocked by "out of date on s390". > > > I finally opted for this solution. The package is ready to be uploaded, > > but how am I supposed to proceed now? ask for removal first and then > > upload or the opposite? > > Do both instead of waiting. There is no problem if the s390 buildd > tries to build xfree86-driver-synaptics before the binary has been > removed (and xfree86-driver-synaptics has been added to > http://buildd.debian.org/quinn-diff/Packages-arch-specific), the build > will simply fail because dpkg-buildpackage (or is it sbuild?) checks > the architecture field. sorry for being so pedantic. Today a bug has been submitted (#253616) regarding this issue. The submitter states that the control file for xfree86 states xserver-xfree86 is Architecture: alpha amd64 arm hppa hurd-i386 i386 ia64 m68k mips mipsel netbsd-i386 powerpc sh3 sh4 sparc but xserver-xfree86 is only available on alpha arm hppa i386 ia64 m68k mips mipsel powerpc sparc [1] so removing only s390 from the Architecture field of xfree86-driver-synaptics may not be enough, right? So the correct solution would be to only Suggest: xserver-xfree86 (>> 4.1.0) [1]: http://packages.debian.org/unstable/x11/xserver-xfree86 -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 10:03:04AM +0200, Andreas Metzler wrote: > On 2004-05-11 Mattia Dongili <[EMAIL PROTECTED]> wrote: > [...] > > Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 > [...] > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > > otherwise I'd better chance my package's Architecture field before sarge > > > Since xfree86 is Architecture: any, I've been suggested to have the > > same on xfree86-driver-synaptics (during a discussion on #debian-mentors) > [...] > > Personally I'd immediately change the architecture field and change it > back once there is a xserver for s390. - You'll probably have to > pester ftp-master to remove the old s390 binary, otherwise > xfree86-driver-synaptics will be blocked by "out of date on s390". I finally opted for this solution. The package is ready to be uploaded, but how am I supposed to proceed now? ask for removal first and then upload or the opposite? also, is [EMAIL PROTECTED] the correct address to contact ftp-master? thanks -- mattia :wq!
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 10:03:04AM +0200, Andreas Metzler wrote: > On 2004-05-11 Mattia Dongili <[EMAIL PROTECTED]> wrote: > [...] > > Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 > [...] > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > > otherwise I'd better chance my package's Architecture field before sarge > > > Since xfree86 is Architecture: any, I've been suggested to have the > > same on xfree86-driver-synaptics (during a discussion on #debian-mentors) > [...] > > Personally I'd immediately change the architecture field and change it > back once there is a xserver for s390. - You'll probably have to > pester ftp-master to remove the old s390 binary, otherwise > xfree86-driver-synaptics will be blocked by "out of date on s390". I finally opted for this solution. The package is ready to be uploaded, but how am I supposed to proceed now? ask for removal first and then upload or the opposite? also, is [EMAIL PROTECTED] the correct address to contact ftp-master? thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 12:03:38PM +0200, Jeroen van Wolffelaar wrote: > On Tue, May 11, 2004 at 09:50:09AM +0200, Mattia Dongili wrote: > > Hi all, > > > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > > otherwise I'd better chance my package's Architecture field before sarge > > There is, today. Notice that xfree86 itself was also stalled by it... ok, thanks. Better than a swiss timer (as we say in Italy) :) > Expect your package to go in tomorrow. Do not simply change the > architecture field because one or two architectures are behind, rather, > try to research *why* your package doesn't go to testing. In this case, > Bjorn's page shows wrong information (Cc'ing him). It said: > > Adding xfree86-driver-synaptics makes 1 non-depending packages > uninstallable on s390: xfree86-driver-synaptics I was actually referring to QA pages excuse: xfree86-driver-synaptics/s390 unsatisfiable Depends: xserver-xfree86 (>= 4.3.0) This actually hides a bug in my package (mea culpa), the correct Depends fields should be since this driver works with XFree86-4.2 too: Depends: xserver-xfree86 (>> 4.1.0) Moreover some considerations could be done about the usefulness of a Synaptics Touchpad driver on S390, I strongly doubt we will ever see it :) Anyway thanks a lot for the explanation and help -- mattia :wq!
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 12:03:38PM +0200, Jeroen van Wolffelaar wrote: > On Tue, May 11, 2004 at 09:50:09AM +0200, Mattia Dongili wrote: > > Hi all, > > > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > > otherwise I'd better chance my package's Architecture field before sarge > > There is, today. Notice that xfree86 itself was also stalled by it... ok, thanks. Better than a swiss timer (as we say in Italy) :) > Expect your package to go in tomorrow. Do not simply change the > architecture field because one or two architectures are behind, rather, > try to research *why* your package doesn't go to testing. In this case, > Bjorn's page shows wrong information (Cc'ing him). It said: > > Adding xfree86-driver-synaptics makes 1 non-depending packages > uninstallable on s390: xfree86-driver-synaptics I was actually referring to QA pages excuse: xfree86-driver-synaptics/s390 unsatisfiable Depends: xserver-xfree86 (>= 4.3.0) This actually hides a bug in my package (mea culpa), the correct Depends fields should be since this driver works with XFree86-4.2 too: Depends: xserver-xfree86 (>> 4.1.0) Moreover some considerations could be done about the usefulness of a Synaptics Touchpad driver on S390, I strongly doubt we will ever see it :) Anyway thanks a lot for the explanation and help -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
xfree86-driver-synaptics blocked by xserver-xfree86 on s390
Hi, I'm forwarding this message to -mentors, is there anybody who can help? thanks (the same post on debian-x didn't have any answer). - Forwarded message from Mattia Dongili <[EMAIL PROTECTED]> - Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 From: Mattia Dongili <[EMAIL PROTECTED]> Date: Mon, 3 May 2004 17:51:56 +0200 To: Debian X Mailing List X-Operating-System: Linux 2.6.5-1 i686 User-Agent: Mutt/1.5.5.1+cvs20040105i X-Disclaimer: Buh! Hi all, the subject[1] says it all, will it ever be an xserver-xfree86 for s390? otherwise I'd better chance my package's Architecture field before sarge Since xfree86 is Architecture: any, I've been suggested to have the same on xfree86-driver-synaptics (during a discussion on #debian-mentors) [1] http://qa.debian.org/developer.php?excuse=xfree86-driver-synaptics thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] - End forwarded message - -- mattia :wq!
xfree86-driver-synaptics blocked by xserver-xfree86 on s390
Hi, I'm forwarding this message to -mentors, is there anybody who can help? thanks (the same post on debian-x didn't have any answer). - Forwarded message from Mattia Dongili <[EMAIL PROTECTED]> - Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 From: Mattia Dongili <[EMAIL PROTECTED]> Date: Mon, 3 May 2004 17:51:56 +0200 To: Debian X Mailing List <[EMAIL PROTECTED]> X-Operating-System: Linux 2.6.5-1 i686 User-Agent: Mutt/1.5.5.1+cvs20040105i X-Disclaimer: Buh! Hi all, the subject[1] says it all, will it ever be an xserver-xfree86 for s390? otherwise I'd better chance my package's Architecture field before sarge Since xfree86 is Architecture: any, I've been suggested to have the same on xfree86-driver-synaptics (during a discussion on #debian-mentors) [1] http://qa.debian.org/developer.php?excuse=xfree86-driver-synaptics thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] - End forwarded message - -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help packaging Synaptics TouchPad driver
p.d. Non. Feb. MMDCCLVII AUC Andreas Metzler scripsit: > On Wed, Feb 04, 2004 at 03:19:04PM +0100, Mattia Dongili wrote: > > [I'm sending this message here as it seems that debian-x wasn't the most > > appropriate place] > > > > xfree86-driver-synaptics is an xserver-xfree86 driver that supports > > special features of synaptics touchpad devices (a pointing device). > [...] > > W: xfree86-driver-synaptics; Shared binary object > > /usr/X11R6/lib/modules/input/synaptics_drv.o has no dependancy information. > > The binary object listed above is a shared object, but does not report > > that it depends on any other shared libraries. > [...] > > I think that is a false positive, as this is not a shared library, but > a plugin, i.e. it is subject to this part of policy: > > | Shared object files (often .so files) that are not public libraries, > | that is, they are not meant to be linked to by third party executables > | (binaries of other packages), should be installed in subdirectories of > | the /usr/lib directory. Such files are exempt from the rules that > | govern ordinary shared libraries, except that they must not be > | installed executable and should be stripped.[51] > > Checking the other files I have in my /usr/X11R6/lib/modules/input/ I > think the other warning is a false positive, too, as the other driver > modules are not stripped either. Fine, I was worried about the linda Error (lintian doesn't report it). I also checked other X plugins and found the same, but as they are packages along with xserver-common it's not exactly the same situation as mine. So, may I go on and forget about those W: and E:? I'm going to write a manpage for the utilities and I'll be done ;) thanks -- mattia :wq!
Re: Help packaging Synaptics TouchPad driver
p.d. Non. Feb. MMDCCLVII AUC Andreas Metzler scripsit: > On Wed, Feb 04, 2004 at 03:19:04PM +0100, Mattia Dongili wrote: > > [I'm sending this message here as it seems that debian-x wasn't the most > > appropriate place] > > > > xfree86-driver-synaptics is an xserver-xfree86 driver that supports > > special features of synaptics touchpad devices (a pointing device). > [...] > > W: xfree86-driver-synaptics; Shared binary object > > /usr/X11R6/lib/modules/input/synaptics_drv.o has no dependancy information. > > The binary object listed above is a shared object, but does not report > > that it depends on any other shared libraries. > [...] > > I think that is a false positive, as this is not a shared library, but > a plugin, i.e. it is subject to this part of policy: > > | Shared object files (often .so files) that are not public libraries, > | that is, they are not meant to be linked to by third party executables > | (binaries of other packages), should be installed in subdirectories of > | the /usr/lib directory. Such files are exempt from the rules that > | govern ordinary shared libraries, except that they must not be > | installed executable and should be stripped.[51] > > Checking the other files I have in my /usr/X11R6/lib/modules/input/ I > think the other warning is a false positive, too, as the other driver > modules are not stripped either. Fine, I was worried about the linda Error (lintian doesn't report it). I also checked other X plugins and found the same, but as they are packages along with xserver-common it's not exactly the same situation as mine. So, may I go on and forget about those W: and E:? I'm going to write a manpage for the utilities and I'll be done ;) thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Help packaging Synaptics TouchPad driver
Hi all,
[I'm sending this message here as it seems that debian-x wasn't the most
appropriate place]
xfree86-driver-synaptics is an xserver-xfree86 driver that supports
special features of synaptics touchpad devices (a pointing device).
I know I'm a bit late in packaging that module but I've been able to
make it work (again) on my hardware only a few weeks ago.
Now comes the problem: linda complains about
E: xfree86-driver-synaptics; Binary
/usr/X11R6/lib/modules/input/synaptics_drv.o is not stripped.
The binary shown is not stripped, and is included in a standard
package, while Policy shows that it should be stripped
actually stripping (`install -s` or `dh_strip`) removes also the
XF86ModuleData synapticsModuleData = {&VersionRec, &SetupProc, NULL };
symbol, needed for the driver to load correctly in XFree.
It also complains (a warning now) about
W: xfree86-driver-synaptics; Shared binary object
/usr/X11R6/lib/modules/input/synaptics_drv.o has no dependancy information.
The binary object listed above is a shared object, but does not report
that it depends on any other shared libraries.
Package: xfree86-driver-synaptics
Version: 0.12.3-1
[...]
Depends: xserver-common (>= 4.2.1)
Suggests: xfree86-driver-synaptics-utils (>= 0.12.3)
So I suppose I'm doing something wrong here...
Any suggestion?
preliminary and unstripped packages can be found here:
http://members.xoom.virgilio.it/mattia_san/debian
thanks in advance
--
mattia
:wq!
signature.asc
Description: Digital signature
Help packaging Synaptics TouchPad driver
Hi all,
[I'm sending this message here as it seems that debian-x wasn't the most
appropriate place]
xfree86-driver-synaptics is an xserver-xfree86 driver that supports
special features of synaptics touchpad devices (a pointing device).
I know I'm a bit late in packaging that module but I've been able to
make it work (again) on my hardware only a few weeks ago.
Now comes the problem: linda complains about
E: xfree86-driver-synaptics; Binary /usr/X11R6/lib/modules/input/synaptics_drv.o is
not stripped.
The binary shown is not stripped, and is included in a standard
package, while Policy shows that it should be stripped
actually stripping (`install -s` or `dh_strip`) removes also the
XF86ModuleData synapticsModuleData = {&VersionRec, &SetupProc, NULL };
symbol, needed for the driver to load correctly in XFree.
It also complains (a warning now) about
W: xfree86-driver-synaptics; Shared binary object
/usr/X11R6/lib/modules/input/synaptics_drv.o has no dependancy information.
The binary object listed above is a shared object, but does not report
that it depends on any other shared libraries.
Package: xfree86-driver-synaptics
Version: 0.12.3-1
[...]
Depends: xserver-common (>= 4.2.1)
Suggests: xfree86-driver-synaptics-utils (>= 0.12.3)
So I suppose I'm doing something wrong here...
Any suggestion?
preliminary and unstripped packages can be found here:
http://members.xoom.virgilio.it/mattia_san/debian
thanks in advance
--
mattia
:wq!
signature.asc
Description: Digital signature
Re: cpufreqd braindamaged versions
On Sun, Jan 04, 2004 at 10:41:11PM -0500, Nathaniel W. Turner wrote: > On Sunday 04 January 2004 19:41, Mattia Dongili wrote: [...] > What about simply 1.1.0-1? I'll go with that then. > Either one is certainly better than an epoch. This way, when 1.2 is > released, > you can go back to simply using 1.2-1. > > For your next set of RC packages, you might use a scheme such as > 1.1.90+1.2rc1 or something that will evaulate as less than 1.2, but I'm sure > you've already figured that out. =) # grep -c 'dpkg --compare-versions' ~/.bash_history 66 :) thanks to everybody -- mattia :wq!
Re: cpufreqd braindamaged versions
On Sun, Jan 04, 2004 at 10:41:11PM -0500, Nathaniel W. Turner wrote: > On Sunday 04 January 2004 19:41, Mattia Dongili wrote: [...] > What about simply 1.1.0-1? I'll go with that then. > Either one is certainly better than an epoch. This way, when 1.2 is released, > you can go back to simply using 1.2-1. > > For your next set of RC packages, you might use a scheme such as > 1.1.90+1.2rc1 or something that will evaulate as less than 1.2, but I'm sure > you've already figured that out. =) # grep -c 'dpkg --compare-versions' ~/.bash_history 66 :) thanks to everybody -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cpufreqd braindamaged versions
On Mon, Jan 05, 2004 at 12:09:12PM +1100, Craig Small wrote: > On Mon, Jan 05, 2004 at 01:41:48AM +0100, Mattia Dongili wrote: > > actually it's me who did the Stupid Thing(TM). :) [...] > > the less ugly debian version name I found is *1.1.final-1*. Is it ok or > > has anybody a better suggestion? > > You have to decide if you are going to do this sort of thing all the > time or not. If it this is a once-off, I'd use an epoch. If packaging > rc versions is going to be a regular thing, then you need to decide how > to put your versions so the rc one appear older than the releases. I'd like to continue to package also -rc versions, but since I'm also upstream of this package I could ask myself to use a more decent version numbering :) So I'd go for an epoch, but I'm still puzzled here: is 20040104:1.1-1 ok or should I go with 1.1.20040104-1 as I see that # if `dpkg --compare-versions 20040104:1.1-1 lt 1.2-1` ; then echo "1" ; fi # thanks again -- mattia :wq!
Re: cpufreqd braindamaged versions
On Mon, Jan 05, 2004 at 02:05:25AM +0100, Marc 'HE' Brockschmidt wrote: > Mattia Dongili <[EMAIL PROTECTED]> writes: > > I packaged cpufreqd version 1.1-rc1 and called it 1.1-rc-1, now 1.1 is > > out... > [...] > > the less ugly debian version name I found is *1.1.final-1*. Is it ok or > > has anybody a better suggestion? > > Read the fu^Wfine policy and use an epoch. 5.6.11 Version [...] Note that the purpose of epochs is to allow us to leave behind mistakes in version numbering(1) , and to cope with situations where the version numbering scheme changes. It is not intended to cope with version numbers containing strings of letters which the package management system cannot interpret (such as ALPHA or pre-)(2) [...] DP is a bit misleading here (IMO or is it me not being a native english speaker), is it the case of (1) or (2)? I thought it was (2) or do you mean I should use something like 1.1.20040104-1 (which other packages use) thanks -- mattia :wq!
Re: cpufreqd braindamaged versions
On Mon, Jan 05, 2004 at 12:09:12PM +1100, Craig Small wrote: > On Mon, Jan 05, 2004 at 01:41:48AM +0100, Mattia Dongili wrote: > > actually it's me who did the Stupid Thing(TM). :) [...] > > the less ugly debian version name I found is *1.1.final-1*. Is it ok or > > has anybody a better suggestion? > > You have to decide if you are going to do this sort of thing all the > time or not. If it this is a once-off, I'd use an epoch. If packaging > rc versions is going to be a regular thing, then you need to decide how > to put your versions so the rc one appear older than the releases. I'd like to continue to package also -rc versions, but since I'm also upstream of this package I could ask myself to use a more decent version numbering :) So I'd go for an epoch, but I'm still puzzled here: is 20040104:1.1-1 ok or should I go with 1.1.20040104-1 as I see that # if `dpkg --compare-versions 20040104:1.1-1 lt 1.2-1` ; then echo "1" ; fi # thanks again -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cpufreqd braindamaged versions
On Mon, Jan 05, 2004 at 02:05:25AM +0100, Marc 'HE' Brockschmidt wrote: > Mattia Dongili <[EMAIL PROTECTED]> writes: > > I packaged cpufreqd version 1.1-rc1 and called it 1.1-rc-1, now 1.1 is > > out... > [...] > > the less ugly debian version name I found is *1.1.final-1*. Is it ok or > > has anybody a better suggestion? > > Read the fu^Wfine policy and use an epoch. 5.6.11 Version [...] Note that the purpose of epochs is to allow us to leave behind mistakes in version numbering(1) , and to cope with situations where the version numbering scheme changes. It is not intended to cope with version numbers containing strings of letters which the package management system cannot interpret (such as ALPHA or pre-)(2) [...] DP is a bit misleading here (IMO or is it me not being a native english speaker), is it the case of (1) or (2)? I thought it was (2) or do you mean I should use something like 1.1.20040104-1 (which other packages use) thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cpufreqd braindamaged versions
Hi all, actually it's me who did the Stupid Thing(TM). :) I packaged cpufreqd version 1.1-rc1 and called it 1.1-rc-1, now 1.1 is out... but # if `dpkg --compare-versions 1.1-rc-1 lt 1.1-1` ; then echo "1" ; fi # ouch! I'm looking around for similar problems (I _can't_ be the first :)) but still haven't found anything. the less ugly debian version name I found is *1.1.final-1*. Is it ok or has anybody a better suggestion? thanks -- mattia :wq!
cpufreqd braindamaged versions
Hi all, actually it's me who did the Stupid Thing(TM). :) I packaged cpufreqd version 1.1-rc1 and called it 1.1-rc-1, now 1.1 is out... but # if `dpkg --compare-versions 1.1-rc-1 lt 1.1-1` ; then echo "1" ; fi # ouch! I'm looking around for similar problems (I _can't_ be the first :)) but still haven't found anything. the less ugly debian version name I found is *1.1.final-1*. Is it ok or has anybody a better suggestion? thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packaging xfree86-driver-synaptics: a couple of questions
On Thu, Dec 04, 2003 at 01:06:02PM -0500, Branden Robinson wrote: > On Thu, Dec 04, 2003 at 02:10:42PM +0100, Mattia Dongili wrote: [...] > > Any suggestion about the name? > > xfree86-driver-synaptics-utils, maybe? Kind of long and ugly, but > highly consistent with its counterpart. I agree, it was my first candidate too. > > 2- the source package needs some X headers not included in xlibs-dev [...] > > headers for the remaining ones. > > I don't understand. You seem to be saying that the headers you need are > not in the package, but also are in the package. > > "the source package needs some X headers not included in xlibs-dev" > and > "I'd set build dependency on xlibs-dev and compile against its headers" sorry for my english... I mean that some headers needed to compile the synaptics driver are not included in xlibs-dev, while other headers (also needed to compile) are. In my previous mail I included a treeview of the headers needed to compile. As you can see there are some files packaged in xlibs-dev (I snipped the full list) and some not. I'd include in the deb source only the missing headers (as provided by mainstream), but still compile against what's available in xlibs-dev. > Also, what do you mean by "mainstream package"? the original tar.gz, sorry again > > Another option could be to create another xfree86-driver-dev to let > > external drivers compile. Which solution? > > I think the headers in question will probably end up in the > xfree86-driver-ddk package, which is slated for development after > 4.3.0-1 is released. In the meantime is my approach ok? thanks -- mattia :wq! pgp2T3LKBpRTJ.pgp Description: PGP signature
Re: packaging xfree86-driver-synaptics: a couple of questions
On Thu, Dec 04, 2003 at 01:06:02PM -0500, Branden Robinson wrote: > On Thu, Dec 04, 2003 at 02:10:42PM +0100, Mattia Dongili wrote: [...] > > Any suggestion about the name? > > xfree86-driver-synaptics-utils, maybe? Kind of long and ugly, but > highly consistent with its counterpart. I agree, it was my first candidate too. > > 2- the source package needs some X headers not included in xlibs-dev [...] > > headers for the remaining ones. > > I don't understand. You seem to be saying that the headers you need are > not in the package, but also are in the package. > > "the source package needs some X headers not included in xlibs-dev" > and > "I'd set build dependency on xlibs-dev and compile against its headers" sorry for my english... I mean that some headers needed to compile the synaptics driver are not included in xlibs-dev, while other headers (also needed to compile) are. In my previous mail I included a treeview of the headers needed to compile. As you can see there are some files packaged in xlibs-dev (I snipped the full list) and some not. I'd include in the deb source only the missing headers (as provided by mainstream), but still compile against what's available in xlibs-dev. > Also, what do you mean by "mainstream package"? the original tar.gz, sorry again > > Another option could be to create another xfree86-driver-dev to let > > external drivers compile. Which solution? > > I think the headers in question will probably end up in the > xfree86-driver-ddk package, which is slated for development after > 4.3.0-1 is released. In the meantime is my approach ok? thanks -- mattia :wq! pgp0.pgp Description: PGP signature
packaging xfree86-driver-synaptics: a couple of questions
Hi all, I started packaging the synaptics touchpad driver[1] and I have a couple of issues: 1- the upstream package contains also 2 extra utilities to enable runtime configuration of the driver (synclient and syndaemon). I'd package them separately and Recommend the utilities from the driver package. Is it the correct approach? Any suggestion about the name? 2- the source package needs some X headers not included in xlibs-dev [2]. Such headers are included in mainstream package, they are X4.2 headers but mainstream says they are ok for X4.3 also. I'd set build dependency on xlibs-dev and compile against its headers, instead of the included ones. I'll still compile against the mainstream included headers for the remaining ones. Another option could be to create another xfree86-driver-dev to let external drivers compile. Which solution? thanks in advance -- mattia :wq! [1] http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00190.html http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=219163 [2] /home/mattia/devel/debian/synaptics-0.12.1/Xincludes/ |-- README.xincludes `-- xc |-- exports | `-- include | `-- X11 | |-- X.h ... more X headers in xlibs-dev `-- programs `-- Xserver |-- hw | `-- xfree86 | |-- common | | |-- xf86.h | | |-- xf86Module.h | | |-- xf86Opt.h | | |-- xf86Version.h | | |-- xf86Xinput.h | | |-- xf86str.h | | `-- xisb.h | `-- os-support | |-- xf86_OSproc.h | `-- xf86_ansic.h |-- include | |-- XIstubs.h | |-- bstore.h | |-- bstorestr.h | |-- colormap.h | |-- cursor.h | |-- dix.h | |-- dixstruct.h | |-- exevents.h | |-- gc.h | |-- globals.h | |-- input.h | |-- inputstr.h | |-- misc.h | |-- miscstruct.h | |-- opaque.h | |-- os.h | |-- pixmap.h | |-- pixmapstr.h | |-- property.h | |-- propertyst.h | |-- region.h | |-- regionstr.h | |-- resource.h | |-- screenint.h | |-- scrnintstr.h | |-- validate.h | |-- window.h | |-- xf86_ansic.h | `-- xf86_libc.h `-- mi `-- mipointer.h
packaging xfree86-driver-synaptics: a couple of questions
Hi all, I started packaging the synaptics touchpad driver[1] and I have a couple of issues: 1- the upstream package contains also 2 extra utilities to enable runtime configuration of the driver (synclient and syndaemon). I'd package them separately and Recommend the utilities from the driver package. Is it the correct approach? Any suggestion about the name? 2- the source package needs some X headers not included in xlibs-dev [2]. Such headers are included in mainstream package, they are X4.2 headers but mainstream says they are ok for X4.3 also. I'd set build dependency on xlibs-dev and compile against its headers, instead of the included ones. I'll still compile against the mainstream included headers for the remaining ones. Another option could be to create another xfree86-driver-dev to let external drivers compile. Which solution? thanks in advance -- mattia :wq! [1] http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00190.html http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=219163 [2] /home/mattia/devel/debian/synaptics-0.12.1/Xincludes/ |-- README.xincludes `-- xc |-- exports | `-- include | `-- X11 | |-- X.h ... more X headers in xlibs-dev `-- programs `-- Xserver |-- hw | `-- xfree86 | |-- common | | |-- xf86.h | | |-- xf86Module.h | | |-- xf86Opt.h | | |-- xf86Version.h | | |-- xf86Xinput.h | | |-- xf86str.h | | `-- xisb.h | `-- os-support | |-- xf86_OSproc.h | `-- xf86_ansic.h |-- include | |-- XIstubs.h | |-- bstore.h | |-- bstorestr.h | |-- colormap.h | |-- cursor.h | |-- dix.h | |-- dixstruct.h | |-- exevents.h | |-- gc.h | |-- globals.h | |-- input.h | |-- inputstr.h | |-- misc.h | |-- miscstruct.h | |-- opaque.h | |-- os.h | |-- pixmap.h | |-- pixmapstr.h | |-- property.h | |-- propertyst.h | |-- region.h | |-- regionstr.h | |-- resource.h | |-- screenint.h | |-- scrnintstr.h | |-- validate.h | |-- window.h | |-- xf86_ansic.h | `-- xf86_libc.h `-- mi `-- mipointer.h -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: selecting gcc version
On Mon, Jul 07, 2003 at 04:19:01PM +0200, Ottavio Campana wrote: > I'm making a deb of a program I'm developing on my own for my > university. I would like to make the deb for it is full of binaries and > libraries and it would be easier to upgrade/add/remove the software. > > I'm running woody but I've got the gcc-3.3 for I need C99 support. > > The problem I'm having is that the script I get running dh_make calls > gcc-2.95 and it doesn't compile. > > How can I select the correct gcc? you could just add export CC=gcc-3.3 on the top of your rules file. hth -- mattia :wq!
Re: selecting gcc version
On Mon, Jul 07, 2003 at 04:19:01PM +0200, Ottavio Campana wrote: > I'm making a deb of a program I'm developing on my own for my > university. I would like to make the deb for it is full of binaries and > libraries and it would be easier to upgrade/add/remove the software. > > I'm running woody but I've got the gcc-3.3 for I need C99 support. > > The problem I'm having is that the script I get running dh_make calls > gcc-2.95 and it doesn't compile. > > How can I select the correct gcc? you could just add export CC=gcc-3.3 on the top of your rules file. hth -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
package author and maintainer
Hello, I'm a wannabe Debian maintainer (already applied the NM program). I packaged a small daemon (cpufreqd) of which I'm also the author. I was wondering If I need to package the sources with or without the .diff.gz archive. The Developer Reference says: If a package is developed specially for Debian and is not distributed outside of Debian, there is just one .tar.gz... I did not developed it specifically for Debian but it's not a problem to distribute the upstream version with the Debian modifications included since I'm also the upstream author. any suggestion? thanks -- mattia
package author and maintainer
Hello, I'm a wannabe Debian maintainer (already applied the NM program). I packaged a small daemon (cpufreqd) of which I'm also the author. I was wondering If I need to package the sources with or without the .diff.gz archive. The Developer Reference says: If a package is developed specially for Debian and is not distributed outside of Debian, there is just one .tar.gz... I did not developed it specifically for Debian but it's not a problem to distribute the upstream version with the Debian modifications included since I'm also the upstream author. any suggestion? thanks -- mattia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
