Re: Libraries with "extra" priority?
Hello Tim, When Debian had less than 1000 packages it meant something to talk about "specialised requirements", and divide packages between extra and optional based on that, but that division has broken down now we have 50,000 packages. As I understand it, the current consensus is that the difference between extra and optional is only whether there are any file conflicts with other packages. It would be acceptable, therefore, to change your package to extra or libpeas to optional. I agree with your reasoning for leaning towards the latter. -- Sean Whitton
Libraries with "extra" priority?
Dear mentors, I was looking at debcheck[0] and saw that my package (with "optional" priority) depends on a package with "extra" priority (libpeas-1.0-0), which is not allowed by policy. After re-reading the policy chapter about priorities[1] it seems that my package is really better off in "extra" since it's "only likely to be useful if you already know what [it is] or have specialized requirements". But my real question is: Does it even make sense to have a library with "extra" priority that does not conflict with another library? The wording of the policy seems to relate more to applications than libraries, since users usually don't manually install libraries. I did not find anything about priorities that is specific to libraries. One other case where an "optional" package depends on an "extra" library is gedit, which also depends on libpeas-1.0-0, and I think gedit fits the criteria for an "optional" priority. So should I maybe file a bug against libpeas-1.0-0? I also looked at its changelog[2] and found both "Bump Priority to optional" and "Set priority to extra" in the same changelog entry (1.2.0-1). So maybe it was a mistake? [0] https://qa.debian.org/debcheck.php?dist=unstable&package=gnome-twitch [1] https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities [2] http://metadata.ftp-master.debian.org/changelogs//main/libp/libpeas/libpeas_1.20.0-1_changelog
Bug#838870: RFS: nbsphinx/0.2.9+ds-1 [ITP] -- Jupyter Notebook Tools for Sphinx
Package: sponsorship-requests Severity: wishlist Dear Sponsors, I am looking for sponsorship for the Debian package nbsphinx [0,1]. This package brings nbsphinx to Debian on behalf of the Debian Python Modules Team. This is my second Debian Python Module package, so it might certainly be subject to some mistakes. Thanks in advance, Jerome [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838806 [1] https://anonscm.debian.org/git/python-modules/packages/nbsphinx.git -- System Information: Debian Release: Jessie* APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#838859: RFS: clipf/0.4-2 [QA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "clipf" * Package name: clipf Version : 0.4-2 Upstream Author : Galtsev Denis * URL : http://code.google.com/p/clipf/ * License : GPL-2+ Section : misc It builds those binary packages: clipf - command line minimalistic personal finance manager To access further information about this package, please visit the following URL: https://mentors.debian.net/package/clipf Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/clipf/clipf_0.4-2.dsc Regards, Gustavo Soares de Lima
Bug#838845: RFS: puppet-module-puppetlabs-motd/1.4.0-1
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "puppet-module-puppetlabs-motd" * Package name: puppet-module-puppetlabs-motd Version : 1.4.0-1 Upstream Author : Puppet Labs Inc * URL : https://github.com/puppetlabs/puppetlabs-motd * License : Apache-2.0 Section : admin It builds those binary packages: puppet-module-puppetlabs-motd - configures a system message of the day with puppet module To access further information about this package, please visit the following URL: https://mentors.debian.net/package/puppet-module-puppetlabs-motd Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/puppet-module-puppetlabs-motd/puppet-module-puppetlabs-motd_1.4.0-1.dsc Regards, Gustavo Soares de Lima
Re: NFS_SUPER_MAGIC portability
Christian Seiler writes: > Therefore, it might be a good idea to know _why_ you want to check for > NFS here? What's the use case? Perhaps there's a better and more > portable way to check for that specific thing. That was the key question ;-) Scanning the code showed me that the function is actually completely unused and may be just removed. It is probably just a remnant from some earlier universe (the code contains a huge legacy codebase). Thank you! Best regards Ole
Re: NFS_SUPER_MAGIC portability
On 09/25/2016 03:12 PM, Ole Streicher wrote:
> I have the problem that in a package (casacore) there is basically the
> following code:
>
> -8<
> #include
> #include
>
> Bool Directory::isNFSMounted() const
> {
>struct statfs buf;
>if (statfs (itsFile.path().expandedName().chars(), &buf) < 0) {
> throw (AipsError ("Directory::isNFSMounted error on " +
> itsFile.path().expandedName() +
> ": " + strerror(errno)));
>}
>return buf.f_type == NFS_SUPER_MAGIC;
> }
> -8<
>
> The linux include subdir is obviously only available on Linux archs, not
> on kfreebsd or hurd. From the "statfs" manpage, I had the impression
> that the second include is just not needed; however then NFS_SUPER_MAGIC
> is not available.
>
> So how do I do this portable (so that I could forward it to upstream as
> well)?
There's no easy way to make that portable. NFS_SUPER_MAGIC is Linux-
specific. statfs() is actually non-portable, and on e.g. FreeBSD
kernels the structure is slightly different (and you need to include
sys/param.h and sys/mount.h instead). Also, at least in a FreeBSD
10.3 VM of mine, the f_type field on an NFS mount is 0x3a - but I
have no idea whether that's guaranteed to be stable or is just some
number assigned dynamically. OTOH, struct statfs on FreeBSD has
f_fstypename, which is "nfs" for NFS mounts. Also, f_flags on
FreeBSD has MNT_LOCAL if it's a local mount, so you might want to
check that instead. On Hurd I have no idea, I've never tried NFS
there (but support exists).
So the only thing you can actually do realistically is to use lots
of #ifdefs, because file system detection is inherently unportable.
Basically, you'd need to do something like (untested, written down
in this email client):
--
static int is_on_nfs (const char *file);
#ifdef __linux__
#include
#include
int is_on_nfs (const char *file)
{
struct statfs buf;
if (statfs (file, &buf) < 0)
return -1;
return buf.f_type == NFS_SUPER_MAGIC;
}
#elif defined(__FreeBSD_kernel__)
#include
#include
#include
int is_on_nfs (const char *file)
{
struct statfs buf;
if (statfs (file, &buf) < 0)
return -1;
return strcmp (buf.f_fstypename, "nfs") == 0;
}
#elif defined(__hurd__)
/* something else on Hurd */
#else
/* no idea how to detect NFS on this OS */
int is_on_nfs (const char *file)
{
(void) file;
return 0;
}
#endif
Bool Directory::isNFSMounted() const
{
int result = is_on_nfs(itsFile.path().expandedName().chars());
if (result < 0)
throw (AipsError ("Directory::isNFSMounted error on " +
itsFile.path().expandedName() +
": " + strerror(errno)));
}
return result != 0;
}
--
The much more important question is: why do need this detection? Because
typically you want to detect NFS for one of the following reasons:
- network filesystem -> slow -> don't do too much I/O there
- lacks specific guarantees / features
In either case, NFS is not the only contender for this though. On Linux
there are lots of other possibilities here: there are other network
filesystems in the kernel, there are local filesystems that don't follow
POSIX guarantees (think e.g. vfat), there are a ton of FUSE filesystems
out there that support a varying number of features required by POSIX.
Plus, FUSE filesystems exist for both network (e.g. sshfs) or local
(think ntfs-3g). On Hurd, you can have arbitrary translators provide
the backing of a specific directory, and different translators support
a different degree of POSIX features.
Therefore, it might be a good idea to know _why_ you want to check for
NFS here? What's the use case? Perhaps there's a better and more
portable way to check for that specific thing.
Regards,
Christian
Re: NFS_SUPER_MAGIC portability
On Sun, Sep 25, 2016 at 9:50 PM, Paul Wise wrote: > A bit of web searching A bit of codesearching finds this interesting function in coreutils: https://sources.debian.net/src/coreutils/8.25-2/src/stat.c#L212 -- bye, pabs https://wiki.debian.org/PaulWise
Re: NFS_SUPER_MAGIC portability
On Sun, Sep 25, 2016 at 9:12 PM, Ole Streicher wrote: > The linux include subdir is obviously only available on Linux archs, not > on kfreebsd or hurd. From the "statfs" manpage, I had the impression > that the second include is just not needed; however then NFS_SUPER_MAGIC > is not available. A bit of web searching leads me to believe there is no equivalent on FreeBSD: https://forums.freebsd.org/threads/38820/ https://svnweb.freebsd.org/base/release/10.0.0/sys/sys/disklabel.h?view=markup Looking on exodar.d.n (Hurd porterbox), it appears st_fstype in struct stat and fsys_stb_type in fsys_statfsbuf can be FSTYPE_NFS. I didn't get any further than that. -- bye, pabs https://wiki.debian.org/PaulWise
NFS_SUPER_MAGIC portability
Hi,
I have the problem that in a package (casacore) there is basically the
following code:
-8<
#include
#include
Bool Directory::isNFSMounted() const
{
struct statfs buf;
if (statfs (itsFile.path().expandedName().chars(), &buf) < 0) {
throw (AipsError ("Directory::isNFSMounted error on " +
itsFile.path().expandedName() +
": " + strerror(errno)));
}
return buf.f_type == NFS_SUPER_MAGIC;
}
-8<
The linux include subdir is obviously only available on Linux archs, not
on kfreebsd or hurd. From the "statfs" manpage, I had the impression
that the second include is just not needed; however then NFS_SUPER_MAGIC
is not available.
So how do I do this portable (so that I could forward it to upstream as
well)?
Best regards
Ole
Bug#838824: RFS: moka-icon-theme/5.3.2-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "moka-icon-theme" * Package name: moka-icon-theme Version : 5.3.2-2 Upstream Author : Sam Hewitt * URL : github.com/moka-project/moka-icon-theme * License : GPL-3+/CC-BY-SA-4.0 Section : misc It builds those binary packages: moka-icon-theme - Tango-esque desktop icon set called Moka To access further information about this package, please visit the following URL: https://mentors.debian.net/package/moka-icon-theme Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/moka-icon-theme/moka-icon-theme_5.3.2-2.dsc Notes: Since Debian Sid has moved to GTK+3.22 there are several icons that no longer display correctly - those projects have changed the icon-name for their projects. The fixes are available upstream in the moka-icon-theme project so I have cherry-picked these - obviously pending a next release of moka-icon-theme (date unknown). Changes since the last upload: * cherry-pick upstream patches - fix GTK+3.22 and GTK+3.20 based apps not displaying correctly due to upstream changing their .desktop exec=icon names - fix ubuntu-software, ImageMagik and Guake icon display * Packaging Changes: - update maintainer email address Regards, David Mohammed
