Re: new pkg-monitoring team, Debian in the Ganglia book
On 19/01/13 22:07, Mathieu Parent wrote: > Hi, > > 2013/1/19 Daniel Pocock : > >> > > >> A few weeks back, the pkg-monitoring team was created >> >> Although we currently look after Ganglia related stuff, it is not >> exclusively for Ganglia, and could be a good way to collaborate on any >> package related to metric collection, storage and analysis >> >> Anybody wishing to collaborate or migrate packages into the team git >> repo can join here: >> >> http://alioth.debian.org/projects/pkg-monitoring/ >> > We also recently created the pkg-graphite team (Graphite is a tool for > real-time visualization and storage of numeric time-series data). > Graphite is mainly used with collectd. > > I have updated http://wiki.debian.org/SystemMonitoring, about what I > am aware of. > > Hi Mathieu, Thanks for alerting me about this - there are definitely people keen on using Ganglia and Graphite together I'm putting this out on the ganglia-developers upstream list as well as there are people using Ganglia, Graphite or both on Debian and/or Ubuntu, and these teams provide a good place for upstream developers to interact with packaging even if they don't get involved in other parts of Debian Regards, Daniel -- 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/50fcfa70.8070...@pocock.com.au
Re: Differing behaviour of shells regarding simple commands with parameter assignments
Sorry for replying so late, but I disagree...
On 2012-12-26 03:03:57 +0100, Timo Weingärtner wrote:
> 2012-12-26, 02:22:45 Cyril Brulebois wrote:
> > Timo Weingärtner (26/12/2012):
> > > bash, zsh, posh output 121
> > >
> > > busybox sh, dash, (m)ksh output 122
> > >
> > > checkbashisms doesn't complain.
> > >
> > > Which of the three is wrong? Where shall I file bugs?
> > >
> > > When bar is not a function but an external script the output is 121
> > > with all the shells.
> >
> > you may want to check something like that:
> >
> > http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#t
> > ag_02_09_05
This is not the latest version, but anyway... this isn't even the
right section for this problem.
> Thanks. If I read that correctly bash, zsh, posh are wrong, but I see that
> changing that might cause trouble.
I disagree. This may be more clear with the following example:
bar() { /bin/true; }
baz() { foo=4; /bin/true; }
foo=1
echo -n $foo
foo=2 bar
echo -n $foo
foo=3 baz
echo -n $foo
baz
echo $foo
printenv foo || true
One gets 1114 with bash, posh and zsh, and 1244 with busybox sh, dash,
ksh93 and mksh. Moreover mksh also outputs "4" (i.e. it exports foo).
The behavior is described by:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01
[2.9.1 Simple Commands]. This text says in particular:
If no command name results, variable assignments shall affect the
current execution environment. Otherwise, the variable assignments
shall be exported for the execution environment of the command and
shall not affect the current execution environment (except for
special built-ins).
We are in the "Otherwise" case, but there seems to be a contradiction
between "shall be exported for the execution environment of the command"
(which is, in the case of a function execution, the current environment)
and "shall not affect the current execution environment". But I think
that it should be interpreted that way: The second part means that the
value of foo is expected to be restored after the execution of the
function. So, the correct output is 1114. This behavior is more
intuitive IMHO: the behavior is the same (the environment is changed
locally), whether the command is a function or some other command found
in $PATH.
That said, I find the text very ambiguous...
Note also that zsh is not expected to be POSIX compliant (even with
"emulate sh", though it should try to behave as POSIX says). But I
think (as explained above) that here it is correct, like bash and
posh.
--
Vincent Lefèvre - Web:
Getting rid of an obsolete library package or let's say byebye to libsox-fmt-ffmpeg
Hi guys, I'm still learning how to do things properly when it comes to packaging shared libraries, please bare with me. To make a long story short, ffmpeg support in SoX has been mostly broken (upstream) for a while now and no one seems to care anymore [1]. The issue has been often time discussed upstream and thus it's scheduled for deprication. Answering to bug #693642 [2], I've uploaded sox (14.4.0-4) with disabled ffmpeg support to experimental. In what seems to be in retrospect a misstep, I've uploaded a version of sox (14.4.0-5) to fix #676167 [3] but that also has disabled ffmpeg. I moved ahead as looking at the reverse dependencies, I did not see any package that explicitely depended on libsox-fmt-ffmpeg. I also think that if any package indirectly depends on libsox-fmt-ffmpeg via libsox-fmt-all, it must already be broken as, again, the ffmpeg support in SoX is oh so very broken. Now, looking at the excuses [4] it seems I should have done something special to get rid of libsox-fmt-ffmpeg. How do I properly get rid of libsox-fmt-ffmpeg ? Thanks, -Pascal -- [1] Most recent discussion starts there: http://www.mail-archive.com/sox-devel@lists.sourceforge.net/msg00082.html [2] http://bugs.debian.org/693642 [3] http://bugs.debian.org/676167 [4] http://qa.debian.org/excuses.php?package=sox -- 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/CAJNNDmkikGuSdNBgsovb_j8=Z97wjm4AkVBh3=eykxjyryn...@mail.gmail.com
Re: Getting rid of an obsolete library package or let's say byebye to libsox-fmt-ffmpeg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 21/01/2013 16:06, Pascal Giard a écrit : > In what seems to be in retrospect a misstep, I've uploaded a > version of sox (14.4.0-5) to fix #676167 [3] but that also has > disabled ffmpeg. I moved ahead as looking at the reverse > dependencies, I did not see any package that explicitely depended > on libsox-fmt-ffmpeg. I also think that if any package indirectly > depends on libsox-fmt-ffmpeg via libsox-fmt-all, it must already be > broken as, again, the ffmpeg support in SoX is oh so very broken. > > Now, looking at the excuses [4] it seems I should have done > something special to get rid of libsox-fmt-ffmpeg. How do I > properly get rid of libsox-fmt-ffmpeg ? Hi, Nothing to do, you're fine (for unstable). libsox-fmt-ffmpeg will eventually be removed by the routine cruft removal procedure. On the other hand, if you want libsox-fmt-ffmpeg removed from testing (which may be the right thing to do if it's that broken), you should contact the release team. Please read: http://wiki.debian.org/ftpmaster_Removals Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQ/V/8AAoJEJOUU0jg3ChAW8YP/0m7jVuYkVVRM60Po3d/BueK sM5mv2eS3P22Ja4l94O+l7mnDCThqZYR45BpZOs1S8MATbzw1a3TgmaQDxiT+Hcn Ove/Ch7iDct0BWtlbsL+hL+6LrTVOYbU2LQhklNP8yomyomMY3ytv6S3Wg+ns67i 3bineMoRKzZklkHFLIpGU29YEDtasMcmY6oiZSRE963t+pJrgrE24Zx3LoAv+woV SLTjId7qUJyeKJoAE3pkP8xcQgIOrnvLpEO3U8zW4Kn7aEabgv4FJzWIJlbLlBZw uz+q5Mx+otGLt99YD2qvC1EKkx6iufGm8pMvmflA02h33KjRi6yQNj3q17TMlhRH JJi6e2Wf+ssYDEDBS1BUfPQk/+fRggKGDKTEOqydU+PZNkL1os5f7H0VgLtwVbmg hhz1jKx2Hfh0ibaS49RSFc6seciuVrqXRimEwTZouRvKghjjQEu88ogxrZ4NUOgg lg5ME+JhIpPbEfaZBmz1MZpdsSgIsXS/Rsw5wLYcuivP9cFAxbzRYHjPHZn3gsmE msu2aA/bCo1UtG/Dix+jKuZSGAG/u8QqJXbjo58lj+dYzi2F66XI0vo9LojTYw+g bSxecj9+YA+zwf5wm0bgpQ4rVhAZ6Jql2U1Y3u1ZPAoLNK2G7dx0G8fXZGyf+EBW aFUVRQTmgQceHfVgrXs+ =85pk -END PGP SIGNATURE- -- 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/50fd6006.6090...@debian.org
Re: Getting rid of an obsolete library package or let's say byebye to libsox-fmt-ffmpeg
On Mon, Jan 21, 2013 at 10:34 AM, Thibaut Paumard wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Le 21/01/2013 16:06, Pascal Giard a écrit : > >> In what seems to be in retrospect a misstep, I've uploaded a >> version of sox (14.4.0-5) to fix #676167 [3] but that also has >> disabled ffmpeg. I moved ahead as looking at the reverse >> dependencies, I did not see any package that explicitely depended >> on libsox-fmt-ffmpeg. I also think that if any package indirectly >> depends on libsox-fmt-ffmpeg via libsox-fmt-all, it must already be >> broken as, again, the ffmpeg support in SoX is oh so very broken. >> >> Now, looking at the excuses [4] it seems I should have done >> something special to get rid of libsox-fmt-ffmpeg. How do I >> properly get rid of libsox-fmt-ffmpeg ? > > Hi, > > Nothing to do, you're fine (for unstable). libsox-fmt-ffmpeg will > eventually be removed by the routine cruft removal procedure. > > On the other hand, if you want libsox-fmt-ffmpeg removed from testing > (which may be the right thing to do if it's that broken), you should > contact the release team. > > Please read: > http://wiki.debian.org/ftpmaster_Removals Hi Thibaut, Will do, thanks for the tip! Cheers, -Pascal -- 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/CAJNNDm=0he_qc1VCsSrzX-c0UBDVL_TBDTCe=5+z4asoiwe...@mail.gmail.com
Bug#698639: ITP: noblenote -- nobleNote is a note taking program based on Qt
Package: wnpp Severity: wishlist Owner: Christian Metscher * Package name: noblenote Version : 1.0.7 Upstream Author : Christian Metscher , Fabian Deuchler * URL : https://launchpad.net/~hakaishi/+archive/noblenote * License : MIT Programming Lang: C++ (Qt) Description : nobleNote is a note taking program based on Qt NobleNote is a program using the Qt libraries. It saves notes in the html format and is able to import xml based notes like those from Tomboy. -- 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/20130121170126.4120.64671.reportbug@hakaishi-Desktop
Bug#698656: ITP: adequate -- Debian package quality testing tool
Package: wnpp Severity: wishlist Owner: Jakub Wilk * Package name: adequate Version : 0.3 Upstream Author : Jakub Wilk * URL : http://jwilk.net/software/adequate * License : Expat Programming Lang: Perl Description : Debian package quality testing tool adequate checks quality of installed packages. The following checks are currently implemented: * broken symlinks; * missing copyright file; * obsolete conffiles; * Python modules not byte-compiled; * /bin and /sbin binaries requiring /usr/lib libraries; * underlinked binaries or libraries. [Patches to improve this description are very welcome.] -- Jakub Wilk -- 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/20130121200741.ga3...@jwilk.net
Re: Bug#698656: ITP: adequate -- Debian package quality testing tool
Am Montag, den 21.01.2013, 21:07 +0100 schrieb Jakub Wilk: > Package: wnpp > Severity: wishlist > Owner: Jakub Wilk > > * Package name: adequate >Version : 0.3 >Upstream Author : Jakub Wilk > * URL : http://jwilk.net/software/adequate > * License : Expat >Programming Lang: Perl >Description : Debian package quality testing tool > > adequate checks quality of installed packages. > > The following checks are currently implemented: >* broken symlinks; >* missing copyright file; >* obsolete conffiles; >* Python modules not byte-compiled; >* /bin and /sbin binaries requiring /usr/lib libraries; >* underlinked binaries or libraries. What's the advantage of adequate over lintian? -- Benjamin Drung Debian & Ubuntu Developer -- 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/1358799385.3447.1.camel@deep-thought
Re: Bug#698656: ITP: adequate -- Debian package quality testing tool
On 2013-01-21 21:07, Jakub Wilk wrote: > adequate checks quality of installed packages. can it be used on chroots without being installed in the chroot? like adequate --root=/some/chroot mypkg > The following checks are currently implemented: > * broken symlinks; > * missing copyright file; > * obsolete conffiles; > * Python modules not byte-compiled; ahh, a patch for #635139 :-) > * /bin and /sbin binaries requiring /usr/lib libraries; > * underlinked binaries or libraries. Sounds intersting. A few of them are already reported by piuparts, but I could consider replacing them by an adequate test run there, too (with a --root option, like we do with debsums). Having a "lightweight" tool (compared to running piuparts locally) to check for these issues sounds like a good idea. Andreas -- 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/50fda7f7.3070...@abeckmann.de
Re: Bug#698656: ITP: adequate -- Debian package quality testing tool
* Andreas Beckmann , 2013-01-21, 21:41: adequate checks quality of installed packages. can it be used on chroots without being installed in the chroot? like adequate --root=/some/chroot mypkg You can't do that currently, and I'm afraid it won't be easy to implement. You could do this, though: cat /usr/bin/adequate | chroot /some/chroot perl - mypkg -- Jakub Wilk -- 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/20130121211718.ga5...@jwilk.net
Re: Bug#698656: ITP: adequate -- Debian package quality testing tool
* Benjamin Drung , 2013-01-21, 21:16: * Package name: adequate Version : 0.3 Upstream Author : Jakub Wilk * URL : http://jwilk.net/software/adequate * License : Expat Programming Lang: Perl Description : Debian package quality testing tool adequate checks quality of installed packages. The following checks are currently implemented: What's the advantage of adequate over lintian? They have different scopes: - Lintian is a static analysis tool; - adequate examines the system on which the tested package has been already installed to see if everything is in order. That said, many of the Lintian checks could be re-implemented in adequate. However, I specifically avoided implementing anything that could be adequately (no pun intended) done by Lintian. Let me go through the list of the checks: * broken symlinks; Lintian's package-contains-broken-symlink implementation is prone to tons of false positive; this is unfixable because Lintian lacks information about foreign packages. * missing copyright file; no-copyright-file is emitted by Lintian only if the copyright file is shipped in the binary package. But Lintian can't possibly know that /usr/share/doc/$pkg/ will disappear on upgrade. * obsolete conffiles; Lintian can't possibly catch this. * Python modules not byte-compiled; lintian4python has a check for this, which works reasonably well, but only under assumptions that 1) the packages use helpers for byte-compilation and 2) the helpers actually do their job correctly. * /bin and /sbin binaries requiring /usr/lib libraries; * underlinked binaries or libraries. Lintian lacks information about foreign packages to perform these checks. I hope this answers your question. :) -- Jakub Wilk -- 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/20130121214039.ga6...@jwilk.net
Re: Bug#698656: ITP: adequate -- Debian package quality testing tool
Am Montag, den 21.01.2013, 22:40 +0100 schrieb Jakub Wilk: > * Benjamin Drung , 2013-01-21, 21:16: > >>* Package name: adequate > >> Version : 0.3 > >> Upstream Author : Jakub Wilk > >>* URL : http://jwilk.net/software/adequate > >>* License : Expat > >> Programming Lang: Perl > >> Description : Debian package quality testing tool > >> > >>adequate checks quality of installed packages. > >> > >>The following checks are currently implemented: > > > >What's the advantage of adequate over lintian? > > They have different scopes: > - Lintian is a static analysis tool; > - adequate examines the system on which the tested package has been > already installed to see if everything is in order. > > That said, many of the Lintian checks could be re-implemented in > adequate. However, I specifically avoided implementing anything that > could be adequately (no pun intended) done by Lintian. > > Let me go through the list of the checks: > > >> * broken symlinks; > > Lintian's package-contains-broken-symlink implementation is prone to > tons of false positive; this is unfixable because Lintian lacks > information about foreign packages. > > >> * missing copyright file; > > no-copyright-file is emitted by Lintian only if the copyright file is > shipped in the binary package. But Lintian can't possibly know that > /usr/share/doc/$pkg/ will disappear on upgrade. > > >> * obsolete conffiles; > > Lintian can't possibly catch this. > > >> * Python modules not byte-compiled; > > lintian4python has a check for this, which works reasonably well, but > only under assumptions that 1) the packages use helpers for > byte-compilation and 2) the helpers actually do their job correctly. > > >> * /bin and /sbin binaries requiring /usr/lib libraries; > >> * underlinked binaries or libraries. > > Lintian lacks information about foreign packages to perform these > checks. > > > I hope this answers your question. :) Yes. Thanks for the details. -- Benjamin Drung Debian & Ubuntu Developer -- 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/1358807195.3447.5.camel@deep-thought
Re: Bug#698656: ITP: adequate -- Debian package quality testing tool
On Tue, Jan 22, 2013 at 4:07 AM, Jakub Wilk wrote: > adequate checks quality of installed packages. Please add the commands needed for running adequate to this list of checking tools: http://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6f3sasf-puwxwc7ybphmgky8_afrsafe15nake97vs...@mail.gmail.com
