Bug#345900: [dpatch-maintainers] Bug#345900: dpatch: make 00list optional
On Wed, 2006-01-04 at 10:06 -0500, Charles Fry wrote:
It would be most helpful if 00list was optional in dpatch.
It is, you can use the PATCHLIST variable to specify files if you use
dpatch.make, or just supply the list to dpatch apply if you're using it
directly. This is even documented in dpatch.make(7).
That works for dpatch.make, but is not supported by dpatch-edit-patch.
That's a bug in dpatch-edit-patch then, not dpatch itself ;)
A valid concern, though.
It is already standard to prefix patches with a number corresponding to
the order in
which they should be applied. All of dpatch's functionality could be
supplied by automatically generating the patch list by sorting the
patch filenames numerically and then alphabetically.
PATCHLIST=`find debian/patches -type f | sort -n`
Or something like that.
I still think there is a reasonable argument for allowing a simple
default like this without custom configuration. That is currently one of
the strong points of cdbs' simple-patchsys; it is very simple. Sure more
flexibility is nice for some people, but having good simple standard
default behavior can go a long ways in maximizing the utility of dpatch.
Default always has been to use 00list or PATCHLIST, that cannot be
changed without possibly breaking every package out there relying on any
of these. Unless, this 00list-less thing happens when there really is no
00list. That might work, but I fear it would complicate
dpatch-edit-patch a wee-bit too much.
What I would do, is to add PATCHLIST support for dpep
(dpatch-edit-patch). If it finds no 00list, it would run something like
this: (cat debian/rules; printf DPEP_PATCHLIST:[EMAIL PROTECTED]
${PATCHLIST}\n) | make -f -, and use the result. Only problem with this
is, to update $PATCHLIST, if it is not automatically generated.. So dpep
would have to warn about that.
This latter one is pretty straightforward, in my opinion, and would do
roughly what you want. With the added requirement of the maintainer
having to add the auto-patchlist line to debian/rules. Not much of an
issue, I'd say.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345900: [dpatch-maintainers] Bug#345900: dpatch: make 00list optional
It would be most helpful if 00list was optional in dpatch. It is, you can use the PATCHLIST variable to specify files if you use dpatch.make, or just supply the list to dpatch apply if you're using it directly. This is even documented in dpatch.make(7). It is already standard to prefix patches with a number corresponding to the order in which they should be applied. All of dpatch's functionality could be supplied by automatically generating the patch list by sorting the patch filenames numerically and then alphabetically. PATCHLIST=`find debian/patches -type f | sort -n` Or something like that. Cheers, -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347103: intent to upload sponsored NMU to fix xlibs-dev bug
Please note that maintainer uploads are preferred to NMUs! If you are able to upload, then please do so. At the moment, I am not able to - please NMU. It's much appreciated! Cheers, -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496795: php5: Segfaults on infinite recursion
Package: php5
Version: 5.2.6-2
Severity: normal
While fiddling around with one project, I accidentally made an infinite
recursion, and PHP went away with a segmentation fault.
A few minutes later, I could reduce the problem to the following snippet:
?php
function foo () { foo (); }
foo ();
?
This makes php segfault somewhere in the zend engine. The backtrace here
is rather long, and shares a strong resemblance to the backtrace posted
in #405067.
It should be very easy to reproduce anyway.
Even though infinite recursions are bad, and should be avoided, I
believe that php should handle it a wee-bit better. Perl for example
just eats up all resources it can, until killed, which would be the
expected behaviour, I think.
--
Gergely Nagy [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294771: thy: does not run as 'nobody', by default
On Fri, 2005-02-11 at 16:49 +, Richard Cohen wrote: Package: thy Version: 0.9.4-1 Severity: normal The man page says: -uid (-U) UID UID is the user (either numerical id or user name) thy should run as. Default is 65534. but # thy # ps -u nobody PID TTY TIME CMD # killall thy # thy --uid nobody # ps -u nobody PID TTY TIME CMD 18771 ?00:00:00 thy Of course, starting via /etc/init.d/thy, the uid is explicitly set (probably to www-data) Whops, thy's behaviour was changed during the 0.8 releases, to run as the user who started it, instead of 65534 (the uid of nobody is different between GNU/Linux distributions, not to mention the BSDs), but the manual page was not updated. I'll correct that in the next release. Thanks for catching this! -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#264567: RFA: dpatch -- patch maintenance system for Debian source packages
retitle 264567 RFA: dpatch -- patch maintenance system for Debian source packages thanks I don't have time to properly maintain dpatch, nor do I use it anymore, so a new maintainer is probably justified, to say the least. You might consider this an O:, even. It is only RFA, because I do not want to upload a new, probably half-broken dpatch just to orphan it. -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#264567: RFA: dpatch -- patch maintenance system for Debian source packages
* Gergely Nagy [EMAIL PROTECTED] [2005-03-16 09:50]: I don't have time to properly maintain dpatch, nor do I use it anymore, Out of interest, what are you using now? Most of the time, nothing, as I'm upstream for pretty much everything I have in Debian. For packages crated for $WORK, I have the thing in an Arch archive, and use branches, lots of them. -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299331: thy: eats all CPU or spits out garbage
(Package was locally compiled. The only difference between custom version and Debian version is that the custom version was compiled with --disable-fork, so that I could run it under a process supervisor.) You can achive the same thing without recompiling, just pass a -o nodaemon option to Thy. When a CGI script fails to run (e.g. syntax error in a Perl script), thy will either - just close the connection to the browser - go into an (infinite?) loop, eating the CPI or - spit out some garbage to the browser Behaviour seems to be unpredictable. Ideally, I think that thy should give a status code of 500 (Internal Server Error) if the CGI script dies. I think at least that is what Apache does. Indeed, it should. What happens is a nasty race: the CGI goes down and gets cleaned up before Thy fills in the CGI's PID associated with the appropriate session in its tables. Thus, the session remains in a stale state. That will either result in getting into an infinite loop, or timing out, and closing the connection. I couldn't reproduce the garbage splitting, though... Anyways, a fix is in the works, and will be in the next upstream release. (A workaround is ready already, but I want to fix this properly). Cheers, -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290146: [RFC] dpatch should use OOo's patch algorithm
Package: dpatch Severity: wishlist [21:43:03] Mithrandir algernon: dpatch should use the same patch algorithm as OOo's patch system does. [21:43:18] Mithrandir algernon: save the patch which worked and use then when unapplying. Should look into OOo's algorithm, whether it is adaptable to dpatch or not, and whether it would break existing users. -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328288: [dpatch-maintainers] Bug#328288: dpatch: man pages reference inexistant README
The man pages for dpatch-convert-diffgz, dpatch-edit-patch, and dpatch-list-patch all contain references to /usr/share/doc/dpatch/README which does not exist. Hmm... I thought there original was a tutorial document of some sort somewhere, and now I look I can't find it. Most of it were folded into the various manpages and other documents, as far as I remember. I'd suggest, the reference be removed from the mentioned manual pages. -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318282: Specifing FileName encoding feature (Patch appended)
Greetings! as I store my file names as UTF-8, I need thy to add the appropirate meta header to the directory indexes. Attached is a script that does that in a configurable way. Info-Documentation updated. Woha! Great patch there, thank you! -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291665: /usr/bin/dpatch-edit-patch: unusual command line parsing
Hi! the command line parsing code for --debianonly is strange. Its parameter is optional, but the following token is always taken as the original tar gz name unless --debianonly= forces the code to accept the parameter as empty. This is _very_ strange and unintuitive. I would like to suggest converting to getopt, probably along the example code given in /usr/share/doc/util-linux/examples/getopt-parse.bash.gz. (without having had a look on getopt-parse) Will that support long options? And is it possible to use getopt, and still preserve most of the dpatch-edit-patch syntax? (except the --debianonly thing, which I agree is unintuitive; sorry about that, it's my fault in trying to make it work like all other dpep options, and not noticing the argument is optional). If the answer to both questions is yes, I'm more than happy to accept a patch that converts dpep to getopt :) -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291668: /usr/bin/dpatch-edit-patch: autodetect debianonly situations
A less magic approach would be checking for a file
debian/dpep-debianonly or debian/patches/dpep-debianonly, which could
optionally contain instructions on how to find the origtargz.
This sounds best to me, for the following reasons:
- One has to explicitly mark the tree as debian-only, so it can't be
misdetected (unless one deliberately breaks the thing)
- The file containing instructions can be a good idea.. I'm not 100%
sure about that though. (more on this later)
- It's VCS-agnostic
The only concern I have is the file to flag debian-only status. It might
be more useful if it would be debian/patches/00dpep-options (or
something similar), where one could tweak a selected set of
dpatch-edit-patch options. Not instructions on how to find the
orig.tar.gz though - that's a job of the origtargz finder script, and
debian/watch should be good enough for that. If not, then I think that
whoever is building the package should know how to get ahold of the
tarball and place it in a place where it can be found. That is, if
there's an easy way to automatically fetch the tarball, we should use
that. If there is not, we should rely on the user setting it up for us,
instead of performing BlackMagic(tm).
So, for now, I'd suggest a patch that checks
debian/patches/00dpep-options, and wether it sets a variable called
DEBIANONLY, and makes dpep act accordingly. And does nothing more.
(I'd imagine the function would look something like:
dpep_load_options ()
{
DEBIANONLY=
if [ -e debian/patches/00dpep-options ]; then
. debian/patches/00dpep-options
fi
if [ ! -z ${DEBIANONLY} ]; then
DPEP_DEBIANONLY=${DEBIANONLY}
fi
}
(Thus, it does not allow setting all dpep options, only a selected set)
--
Gergely Nagy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291666: have dpatch-find-origtargz seperately callable
When working on my build system with svn-buildpackage, I have found that an svn-buildpackage hook being invoked before package build (#291626) would need to obtain the upstream tarball just as dpatch-edit-patch 2.0.11 does. Thus, it is useful to have dpatch-find-origtargz in its own script. Nice one, thanks! (patch will be applied sometime this weekend, when I have time to work o dpatch) -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291665: /usr/bin/dpatch-edit-patch: unusual command line parsing
On Sat, 2005-01-22 at 15:05 +0100, Marc Haber wrote: On Sat, Jan 22, 2005 at 12:28:04PM +0100, Gergely Nagy wrote: Will that support long options? And is it possible to use getopt, and still preserve most of the dpatch-edit-patch syntax? Yes, and probably yes. There will be _minor_ changes though, but none I could name right now. Minor changes are acceptable, methinks. -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291668: /usr/bin/dpatch-edit-patch: autodetect debianonly situations
On Sat, 2005-01-22 at 15:12 +0100, Marc Haber wrote: On Sat, Jan 22, 2005 at 12:43:45PM +0100, Gergely Nagy wrote: The only concern I have is the file to flag debian-only status. It might be more useful if it would be debian/patches/00dpep-options (or something similar), where one could tweak a selected set of dpatch-edit-patch options. If the presence of that file doesn't confuse other programs from the dpatch suite, it is of course the best option. It shouldn't. If it does, the tool which got confused needs to be fixed. Not instructions on how to find the orig.tar.gz though - that's a job of the origtargz finder script, and debian/watch should be good enough for that. If not, then I think that whoever is building the package should know how to get ahold of the tarball and place it in a place where it can be found. When we have a config file, that file should have an option to directly point the origtargz finder to the direct path. I am currently debating with the svn-buildpackage maintainer to have a user-specific config file in the home directory containing a list of package names and locations for .orig.tar.gz files. Maybe dpep could support that file as well. I do NOT want to have direct, local paths in the file. That will break dpatch-edit-patch the first time someone has a different directory setup. Say, the file has ORIGTARGZ_LOCATION=/home/jrandomdeveloper/origs/foo_1.0.orig.tar.gz; this will break as soon as someone else than jrandomdeveloper wants to use dpatch-edit-patch. If it is only a hint, and other locations are searched as well, then I do not thing it is worth the effort at all. For the same reason I do not want dpep to support svn-buildpackage's configfile (if there will be such a thing): that is not our territory. Instead of parsing that file, a hook that copies or symlinks the orig.tar.gz to a location where dpep can find it would be MUCH better (a hook in svn-buildpackage, that is). With cvs-buildpackage, one can do that, works fine, and does not need hacks in dpep. (And that is why I consider backuping out the .svn/deb-layout thing too, now that I thought some more about the issue) -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291668: /usr/bin/dpatch-edit-patch: autodetect debianonly situations
On Sat, 2005-01-22 at 16:13 +0100, Marc Haber wrote: On Sat, Jan 22, 2005 at 04:05:26PM +0100, Gergely Nagy wrote: On Sat, 2005-01-22 at 15:54 +0100, Marc Haber wrote: cvs-buildpackage reads ~/.cvsdeb.conf, which can have conf_get_orig point to a script that is called to get the orig.tar.gz. Would you accept that setup? Sorry, but I'm still not convinced I'd like to see dpep handle the config files of *-buildpackage and the like. I am not suggesting to have dpep read cvs-buildpackage's config file, but to have its own, ~/dpatch.conf. Hrm. So it would be per-user, not per-package? That sounds much better. (so, autodetect debian-only setup from per-package debian/patches/00dpep-options, and get a list of possible locations from ~/.dpatch.conf... sounds fine!) -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292011: gst-plugins0.8: please enable shout2send
Package: gst-plugins0.8 Severity: wishlist It would be very handy to have the shout2send plugin enabled (build-dep on libshout3-dev does the trick), so that one could construct a nice pipeline that automatically sends the songs he is listening to to an icecast server. -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355852: ftp.debian.org: please remove thy and thy-auth
Package: ftp.debian.org Severity: wishlist Please remove the thy and thy-auth packages from unstable, as they are unmaintained upstream, and do not compile at all with the current GnuTLS. There are alternatives that are maintained, and are intended for the same user base thy was (lighttpd comes to mind). -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#608491: Problem Fix (was: Bug#608491: syslog-ng: log file permissions dangerous on kfreebsd-i386)
The problem is that chwon(fn, -1) works differently on Linux than on FreeBSD. Linux doesn't change the permissions if mode is -1, FreeBSD does. The workaround would be to test for -1 in syslog-ng and not call chmod in those cases. For the record, affile_open_file gets the same arguments even on Linux, yet, permissions are eventually set right there. Thus, the problem is entirely doe to chmod(fn, -1) behaving differently on the two systems. A patch should be easy to cook up, one should be incoming soon, just need to test it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608491: A little more info
The problem - at a first guess - will be somewhere in the config file parsing code or thereabouts. By the time syslog-ng gets to call fchown(), the file mode is set to a horribly wrong value: #1 0x00434d66 in affile_open_file (name=0x68e030 /var/log/syslog, flags=33285, uid=0, gid=4, mode=65535, dir_uid=0, dir_gid=0, dir_mode=65535, create_dirs=0, privileged=0, is_pipe=0, fd=0x7fffddbc) at affile.c:101 101 fchmod(*fd, (mode_t) mode); Current language: auto The current source language is auto; currently c. If one looks at the parameters passed to affile_open_file, one can notice that both mode and dir_mode are wrong. They're actually (int16_t)-1. This is on kfreebsd-amd64, so it looks like it's kfreebsd specific, and the arch doesn't matter. I will know more once I dived deeper in. With a bit of luck, I'll have a fix sometime tomorrow, unless someone beats me to it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608491: Fixed in upstream git
The issue is fixed in upstream git, differently than how Steven proposed: http://git.balabit.hu/?p=bazsi/syslog-ng-3.1.git;a=commitdiff;h=cbcea8c95c3f07ed9eaa4d12f124db8f8ca2f74b;hp=61181dca938d2cdd8233df2a07d6e0c76f049e6f Bazsi's solution is to use gint instead of mode_t, so that syslog-ng can continue using -1 as a special value. The actual chmod calls will only be made if the permissions are correct, though. I tested his patch on both Linux and kFreeBSD, and both behave after the patch as expected. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608791: syslog-ng: dir_group not effective
In my opinion, this is a release critical issue, because systems that
relied in dir_group() working (because it does work as expected in
Lenny), and built scripts or other infrastructure around that feature,
will break when upgrading to Squeeze.
I run syslog-ng with root:root, but the group of some of my log files
(and the subdirectories they reside in) are NOT root, because the
scripts built over the years to monitor and work with these log files
are not to be run as root.
Now, if I upgrade to Squeeze, and dir_group() stops working, the whole
system built upon the assumption that directories will have a non-root
group will break horribly, and there won't even be an easy, reliable
workaround either.
If I have something like this:
destination d_something {
file (/var/log/something/${YEAR}/${MONTH}/${DAY}.log
create_dirs(yes)
dir_group(something-adm)
dir_perm(0750)
);
};
The scripts that run with something-adm group will suddenly not be able
to search directories, because dir_group() will not work after an
upgrade, and directories will not have appropriate permissions.
Breaking a system in such a way during an upgrade is a release critical
bug in my opinion.
Luckily, the fix for the issue is trivial, and will not do any harm.
Thus, I'd really, really love if this issue could be escalated to RC,
and fixed before the release.
--
|8]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612373: With kernel 2.6.38-rc3, syslog-ng refuses to start.
It's a known issue, the kernel people have been notified, and the general consensus is that breaking userspace this way is not bad, and the change is either going to be reverted, or reworked in such a way that maintains backwards compatibility. It's pointless to try and work with the current -rc3 (and -rc4), as CAP_SYSLOG in its current form will not last. For the time being, disabling capability support is a reasonable workaround. In the future, once the reworked CAP_SYSLOG lands in Linus' tree, syslog-ng will be updated to support it. At the moment, however, the bug is on kernel-side, as it broke userspace. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630651: update-notifier: Tooltip error when an apt preferences file is unreadable.
Package: update-notifier Version: 0.99.3debian8 Severity: minor I have a file in /etc/apt/preferences.d/, pinning a certain package to -1 to prevent installation. This file is owned by root:root, and has 0600 as its permissions. I noticed today, that the toolip for the update-notifier is far longer than it usually is. This is how it reads: , | An error occurred, please run Package Manager from the right-click | menu or apt-get in a terminal to see what is wrong. | | The error message was: 'Error: Opening the cache (E:Could not open | file /etc/apt/preferences.d/ign-Vsk0V3 - open (13: Permission | denied))'This usually means that your installed packages have unmet | dependencies. ` There's a few problems with this tooltip: First of all, the formatting is a bit off: there's no newline after the quoted error message. Second, the cache has nothing to do with my preferences file, I believe. Nor does it have anything to do with unmet dependencies. I'm not quite sure where the error message in the tooltip comes from, whether it is apt or a script that update-notifier uses - nevertheless, the tooltip could be formatted and worded better. I'd remove the last sentence, to be honest, but that might be just me. -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages update-notifier depends on: ii gconf2 2.28.1-6 GNOME configuration database syste ii gksu2.0.2-5 graphical frontend to su ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libdbus-glib-1-20.88-2.1 simple interprocess messaging syst ii libgconf2-4 2.28.1-6 GNOME configuration database syste ii libgdu0 2.30.1-2 GObject based Disk Utility Library ii libglib2.0-02.24.2-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii libgudev-1.0-0 164-3GObject-based wrapper library for ii libnotify1 [libnotify1- 0.5.0-2 sends desktop notifications to a n ii libx11-62:1.3.3-4X11 client-side library ii notification-daemon 0.5.0-2 daemon to displays passive pop-up ii python 2.6.6-3+squeeze6 interactive high-level object-orie ii update-manager-gnome0.200.5-1GNOME application that manages sof ii update-notifier-common 0.99.3debian8Files shared between update-notifi Versions of packages update-notifier recommends: ii anacron2.3-14cron-like program that doesn't go pn apport-gtk none(no description available) ii software-properties-gtk0.60.debian-3 manage the repositories that you i ii synaptic 0.70~pre1+b1 Graphical package manager Versions of packages update-notifier suggests: pn ubuntu-system-service none (no description available) -- no debconf information -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630761: RFP: libczmq -- High-level C binding for ZeroMQ
Package: wnpp Severity: wishlist * Package name: libczmq Version : 1.0.0 Upstream Author : Pieter Hintjens p...@imatix.com and others * URL : http://czmq.zeromq.org/ * License : LGPL3+ Programming Lang: C Description : High-level C binding for ZeroMQ czmq (previously known as libzapi) provides a high-level C binding for 0MQ, a lightweight messaging library. . This library provides higher level abstractions on top of the base library, with features such as: . * Work with messages as strings, individual frames, or multipart messages. * Automatic closure of any open sockets at context termination. * Automatic LINGER configuration of all sockets for context termination. * Portable API for creating child threads and ØMQ pipes to talk to them. * Simple reactor with one-off and repeated timers, and socket readers. * System clock functions for sleeping and calculating timers. * Easy API to get/set all socket options. * Includes generic hash and list containers. There are a few issues with the library: upstream makes no attempt at versioning it yet, so the packager will either need to convince upstream to at least use the package version in the SONAME, or find another workaround - or in the worst case, keep it out of Debian until upstream starts to version it properly. I plan to package this library at some point in the not too distant future, unless someone beats me to it (hence the RFP and not ITP). -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630761: RFP: libczmq -- High-level C binding for ZeroMQ
Alessandro Ghedini al3x...@gmail.com writes: Hi, On Fri, Jun 17, 2011 at 08:12:15AM +0200, Gergely Nagy wrote: There are a few issues with the library: upstream makes no attempt at versioning it yet, so the packager will either need to convince upstream to at least use the package version in the SONAME, or find another workaround - or in the worst case, keep it out of Debian until upstream starts to version it properly. Uhm, really? There seem to be nothing wrong. Given that this is the first version is normal to have 0.0.0 as interface numbers, it's just how libtool is supposed to work [0]: Never try to set the interface numbers so that they correspond to the release number of your package. The upstream README states that they do not attempt to version the library at all: , | Library versioning: we don't make any attempt to version the library at | this stage. Classes are in our experience highly stable once they are | built and tested, the only changes typically being added methods. ` Indeed, there is nothing wrong with 0.0.0, as long as that's intentional, and future releases will have a different version, which to my understanding, is not the case in czmq's case. Anyway, why not call the source package czmq instead of libczmq? That seems the name used by upstream. Yeah, czmq should be the source name. I'm not quite sure why I wrote libczmq - I guess I was thinking too much ahead :) I plan to package this library at some point in the not too distant future, unless someone beats me to it (hence the RFP and not ITP). I would like to help if you need so (e.g. co-maintaining the package). Sounds like a good idea, thank you! I've done a quick and dirty initial try to package this, and it doesn't seem that hard. Please let me know. I'd love to have a look at your packaging. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631010: libzorp3.9-0: typo in package description
Davide Prina davide.pr...@gmail.com writes: Package: libzorp3.9-0 Severity: minor In DDTSS I see: Share librarioes of the Zorp system. ^ _| I think it must be: Share libraries of the Zorp system. It's actually two typos: 'Share' should be 'Shared' aswell. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631069: google-chrome-beta: Google Chrome Beta unsetting itself as default browser
Zhehao Mao zhehao@gmail.com writes: I know this is a somewhat sticky issue because Google Chrome is not maintained by Debian and it is not really a big problem, but I thought it would send this report anyway. Since Google Chrome is - as you wrote - not in Debian, your report ended up being filed against the unknown package, which probably doesn't help neither you, nor Debian. I would suggest you reassign it to the xfce4-settings package, as that is in Debian, and it is part of the trouble. The XFCE maintainers can then decide what to do with the report. You can do the reassign by sending a mail to cont...@bugs.debian.org with the following lines: reassign 631069 xfce4-settings thanks Alternatively, I can reassign it for you, if you agree with it. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600467: can someone end this finally?
Roman Vasiyarov rvasiya...@gmail.com writes: Notes: - debian/rules: ./autogen.sh may require build-depend on automake (or w/e beast). i don't know if running ./autogen.sh is appropriate (changing source one-way?), but that seemed way better than autoreconf/libtoolize manual patching every time You could build-depend on dh-autoreconf, and use something like this in debian/rules: override_dh_autoreconf: dh_autoreconf ./autogen.sh %: dh $@ --with autoreconf (Assuming debhelper v8+ compatibility level) dh-autoreconf will reconstruct the original autotools stuff upon clean, and it depends on the autotools suite (autoconf, automake, libtool) aswell. Note: I did not look at the actual diff, it's just the note that caught my eye. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631189: openssh-server: sshd_config should support include directive
Алексей Малов scukon...@gmail.com writes: I think, openssh-server should support include directive. I have a lot of sshd_config files that are mostly the same, except for some small differences. For example, ListenAddress could be different because a host has a bunch of virtual interfaces that ssh should not listen on. Also, it is very useful, when configure with systems like puppet. I wished for an include directive quite a lot of times in the past, but since then, ended up liking my workaround better: I use cpp to preprocess my sshd configs before deployment, thus I automatically get #include and a bunch of other stuff. While it's not as convenient as sshd supporting Include by itself, it works. And doesn't need any changes to openssh (implementing include properly is not all that trivial, imo). -- |8], a random user who just happened to stumble upon this wishlist report. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631518: tigervnc-server: areas replaced by grey rectangles
Christophe Lohr christophe.l...@telecom-bretagne.eu writes: Package: tigervnc-server Version: 1.0.90-r4387 Severity: normal Tags: upstream Hi, When I use applications such as iceweasel (3.5.16-5) icedove (3.1.10-2) or galeon (2.0.7-2.1+b1) within tigervnc-server (1.0.90-r4387), large areas are displayed as grey rectangles. This seems to be independant of the vnc-viewer. This does not append within vnc4server, vino-server, or other vnc servers. Since tigervnc is not part of Debian as far as I can see, wouldn't it be better to report this problem directly to upstream? It seems to me they're the providers of the tigervnc-server Debian package[0], and therefore, the issue should be taken to them, instead of Debian. Since there is no tigervnc-server package in Debian, your report most probably did not reach its intended audience, either. If you agree, I'd like to close this bug, as there's not much Debian can (or should, for that matter) do about it. 0: http://winswitch.org/dists/sid/main/binary-amd64/ -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618913: eventlog: New upstream version available
Package: libevtlog0 Severity: wishlist There's a new upstream version available (since a little while), which is required by the alpha releases of syslog-ng 3.3, and will be required by the final version aswell. Version 0.2.12 would be very nice to have. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626946: zsh-static fails to start at all
Richard Hartmann richih.mailingl...@gmail.com writes:
Package: zsh
Version: 4.3.11-5
Severity: grave
Justification: renders package unusable
Rationale: zsh-static is a shell used for root and in fall-back
scenarios. As it does not work at all, this can make system maintenance
or repairing this hard to impossible.
% zsh-static -f
zsh-static: ../sysdeps/unix/sysv/linux/getpagesize.c:32: __getpagesize:
Assertion `_rtld_global_ro._dl_pagesize != 0' failed.
[1]8747 abort zsh-static -f
% echo $?
134
%
I have seen similar problems with other statically linked programs
aswell. If the program uses nss or any other thing that glibc dlopens()
at run-time, then this problem has a very high chance of happening.
I've seen it with the following program aswell (compiled with gcc -O2
-static):
#include iconv.h
#include stdio.h
#include errno.h
int main () {
iconv_t x;
x = iconv_open (UTF-8, UTF-32LE);
printf (%d\n, errno == EINVAL);
return 0;
}
Though, it doesn't happen on current unstable, it did happen about 2
weeks ago. I didn't bother debugging it further unfortunately.
I don't think this issue is limited to zsh-static alone.
--
|8]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626969: ITP: libmongo-client -- Alternate C driver for the MongoDB document-oriented datastore
Package: wnpp Severity: wishlist Owner: Gergely Nagy alger...@madhouse-project.org * Package name: libmongo-client Version : 0.1.0 Upstream Author : Gergely Nagy alger...@balabit.hu * URL : https://github.com/algernon/libmongo-client/ * License : Apache 2.0 Programming Lang: C Description : Alternate C driver for the MongoDB document-oriented datastore This library provides an alternative C language driver for the MongoDB document-oriented datastore, focusing more on ease of use. Among its features are: * Support for asynchronous operation. * C-like error handling. * ReplicaSet support. The package is a dependency of syslog-ng 3.3 (currently about to enter beta, and hopefully hitting experimental reasonably soon after). Preliminary debian packaging is already available on the debian branch in the git repository. The package will be sponsored by Tamas Szerb t...@debian.org, once 0.1.0 is released (May 25th, if all goes well). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617467: [Pkg-haskell-maintainers] Bug#617467: Debian’s cabal-install should not recomment updating cabal-install
Marco Túlio Gontijo e Silva mar...@debian.org writes: cabal-install currently suggests: Note: there is a new version of cabal-install available. To upgrade, run: cabal install cabal-install which makes perfect sense for user-installed cabal-install instances. But I think the version packaged by Debian should not recommend this, as Debian users more likely prefer updating cabal-install via apt-get. Do you think it should: 1) Be removed? 2) Check if this is the newer debian version (probably in the sources.list from the user) and suggest updating using apt-get? I tend to prefer 1, but I'd like to hear your, and others, point of view on this. Personally, I'd prefer the first option too. The second sounds way too error prone, and it's a job better left to other mechanisms that were designed to remind the user about possible Debian upgrades. I don't think cabal should know anything about debian packages at all - it's not its job. Therefore, checking if it's debian package is up-to-date is none of its business, either. -- |8], a random haskell user -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629207: metacity: Missing window control buttons
Carlos Alberto Lopez Perez clo...@igalia.com writes: I have the same problem here. After the last upgrade for Debian sid I lost the window buttons on gnome2/compiz. I mean all window buttons (the left one and the tree ones at right side of the window) The solution for me was to downgrade the metacity package to the prior version. # Add wheezy repo to sources.list apt-get install libmetacity-private0=1:2.30.1-3 metacity=1:2.30.1-3 metacity-common=1:2.30.1-3 So I guess something is wrong with the metacity package because downgrading it fixes the issue. Same here. Upgrading metacity makes all buttons disappear, downgrading it brings them back. I tried to look in ~/.xsession-errors to see if there's any error message, but there doesn't seem to be any difference between sid's and wheezy's messages. I'll try to test it further during the weekend, to see if I can spot anything more useful. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629239: compiz: Missing window control buttons
For trying to solve this issue, I'm upgraded compiz* packages using the the experimental version (0.9.2.1+git20110226.f059fae9-4) but the problem still remain. The only solution, actually, is to disable compiz. As this is related to #629207, I'd echo what was discovered there: downgrading metacity to testing's version solved the problem. There's something fishy going on between compiz and metacity, it seems. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629207: metacity: Missing window control buttons
Daniel Huhardeaux de...@tootai.net writes: FYI I already opened a bug about this problem against compiz-gtk in march. See bug 617763 What I saw is a bit different: I can start gtk-window-decorator, just fine, and it does not segfault. Window controls are missing nevertheless. (Though, it might be the same underlying problem, just a different manifestation of it in my case) -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630172: syslog-ng does not work with 2.6.38-5 kernel on squeeze -related to CAP_SYSLOG or CAP_SYS_ADMIN ?
m...@u.washington.edu m...@uw.edu writes: Package: syslog-ng Version: 3.1.3-3 Severity: normal [...] This web page may help - same bug? : https://bugzilla.balabit.com/show_bug.cgi?id=108 Yep, same issue. It's fixed in upstream's 3.3 branch. As a workaround, one can run syslog-ng with --no-caps, and then it will stop triggering the kernel's message, at the cost of running as root with full capabilities. (Which was the default until 3.1.2-1, iirc) -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631678: BUG: soft lockup - CPU#2 stuck for 67s!
reassign 631678 linux-image-2.6-amd64 thanks Hi! Андрей Василишин a.vasilis...@kpi.ua writes: Package: linux-image-2.6.37-2-amd64 Version: 2.6.37-2 Since 2.6.37-2 was removed from unstable on March 28, can you try upgrading to a newer kernel, and test if the problem persists? Meanwhile, I'm reassigning the bug to linux-image-2.6-amd64. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631910: DKMS error when upgrading kernel or virtualbox
Erwan David eda...@nds.com writes: Package: virtualbox-4.0 Version: 4.0.10-72479~Debian~squeeze Severity: normal Tags: wheezy Does this also happen with the VirtualBox in Debian (4.0.8-dfsg-2 is the latest as far as I see)? If so, I'd suggest reassigning this bug to virtualbox-dkms, as no virtualbox-4.0 package exists in Debian. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632215: artifacts on screen
Vitaliyi img...@gmail.com writes: Package: linux-image-2.6.39-1-686-pae Version: 2.6.39-1 2.6.39-1 was removed from unstable on the 9th of June, and therefore the bug report did not reach its intended audience. Can you retry with linux-image-2.6.39-2-686-pae? If the problem is still present, can you reassign the bug to linux-image-2.6.39-2-686-pae? (Alternatively, I can reassign it too, if you tell me to). -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632215: artifacts on screen
reassign 632215 linux-image-2.6.39-2-686-pae 2.6.39-2 thanks Vitaliyi img...@gmail.com writes: On Thu, Jun 30, 2011 at 6:59 PM, Gergely Nagy alger...@balabit.hu wrote: Vitaliyi img...@gmail.com writes: Package: linux-image-2.6.39-1-686-pae Version: 2.6.39-1 2.6.39-1 was removed from unstable on the 9th of June, and therefore the bug report did not reach its intended audience. Can you retry with linux-image-2.6.39-2-686-pae? I just tried 2.6.39-2-686-pae and the issue is stil lthere. In attachment even brighter screenshot. If the problem is still present, can you reassign the bug to linux-image-2.6.39-2-686-pae? (Alternatively, I can reassign it too, if you tell me to). Yes, please. Done! -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632640: RFP: git-flow -- Git extensions to provide high-level repository operations for Vincent Driessen's branching model
retitle 632640 ITP: git-flow -- Git extension to provide a high-level branching model thanks Since I use git-flow both at work, and at home for every project I touch, and was contemplating on packaging it up so that I can stop checking it out on every machine I work on, I'll be preparing a package in the next day or two, as time permits. Upstream's develop branch has a contrib/debian directory, but I plan to ignore that, since it's not much more than a dh-make template with only the bare minimum needed to make a deb package. (Its debian/copyright is also wrong, among other things) Once the packaging is ready, I'll post again. I'll also contact upstream if and when the package gets uploaded, so that he can drop the contrib/debian dir, and suggest using apt-get instead. ;) -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632640: RFP: git-flow -- Git extensions to provide high-level repository operations for Vincent Driessen's branching model
Hi! Sam Morris s...@robots.org.uk writes: Package: wnpp Severity: wishlist * Package name: git-flow Version : 0.4.1 Upstream Author : Vincent Driessen * URL : https://github.com/nvie/gitflow * License : 2-clause BSD Programming Lang: Shell Description : Git extensions for Vincent Driessen's branching model A set of scripts that provide high-level repository operations for managing feature/release/hotfix branches in a Git repository. This implements the workflow described at http://nvie.com/posts/a-successful-git-branching-model/. I prepared preliminary packages, which are available from http://madhouse-project.org/algernon/git-flow/. Haven't tested it much yet, and there's probably a few things to tweak to make it better (I'm planning to include the bash zsh completions aswell), but it's in a good enough shape for basic testing. If you're up for it, I'd be very interested in hearing your opinion about the package. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637066: [wnpp] removal of gramofile has been requested!
Dale Amon a...@vnl.com writes: Is there a functional replacement for splitting tracks from cassette tapes and vinyl records? If not I think it fills the kind of important niche that isn't needed until... it is *REALLY* needed! FYI, if there is no suitable alternative, I can offer to help cleaning up the currently open bugs against gramofile (they seem reasonably straightforward to me), and see about porting it to ALSA. However, since I have nearly no use for it, I wouldn't want to step up as a maintainer in the long run. But a one-time cleanup get into shape sprint I can probably do. No promises at this time, though. Especially about the ALSA porting, the rest isn't a big deal, imo. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637500: logwatch: hidden/spurious service scripts present in the package
reassign 637500 logwatch 7.3.6.cvs20090906-1squeeze1 severity 637500 minor thanks Package: minor Version: 7.3.6.cvs20090906-1squeeze1 Severity: normal Based on the subject line (and the version, and the system info), I assume the package is logwatch, and the severity is 'minor'. Reassigned adjusted severity accordingly. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637530: gdm3/gnome2: Failure of remote X server using ssh X11 forwarding function
reassign 637530 gnome thanks Hughe Chung maildeliverag...@gmail.com writes: Package: gnome2 No such package exists in Debian. When filing a bug report against something, please try to file it against something that does exist, so your report gets forwarded to people who can do something about it (even if that something is reassigning it to the correct package). I'm reassigning it to the gnome metapackage for now, in hopes that the Gnome maintainers can process it further. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#358019: dpatch needs a dryrun-all option
tag 358019 + wontfix thanks It is not possible to safely merge dpatch patches, as they are not guaranteed to be patches at all (nor is the number of prefixes to remove with -p set in stone). Therefore, what is outlined in the original report, is not possible to do with dpatch. Changing one's workflow, as suggested by Junichi Uekawa is the way to go. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#400092: dpatch: [dpatch.lib.sh] DPATCH_LIB_NO_DEFAULT is not documented in dpatch(1)
Thanks for catching this! Actually, none of the dpatch-run stuff (dpatch.lib.sh being part of that stuff) is documented anywhere. I'll write a section about dpatch-run friends to the manual page, probably based on the debian/NEWS entry that mentions dpatch-run and DPATCH_LIB_NO_DEFAULT. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#466364: Please set the timestamp of patched files to guard against timestamp skews
The problem is that dpatch patches are not guaranteed to be patchfiles at all (even if the vast majority of them are). Therefore, it's not currently possible to automatically figure out which files it touched. However, it is possible to modify dpatch.lib.sh to do the timestamp fixing, so it will at least work for dpatches that use that library. I'll see what I can do about that. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#342768: [patch] dpatch: allow -p0 format patches
This would introduce functionality I'd have to document, a couple of new options, and so on and so forth. Not really looking forward to it. Furthermore, dpatch.lib.sh doesn't even need to be changed, one can simply use DPATCH_LIB_NO_DEFAULT and implement a dpatch_patch/dpatch_unpatch function, that calls patch -p0. One can also use debian/patches/00template to prepare such a header, and dpatch-edit-patch will use it. Then the only thing left is to tweak dpatch-edit-patch to generate the appropriate diffs. I'll see how much work that would be, and perhaps implement that in the next upload, if it can be done sanely. If it can't be, I'll tag this bug wontfix. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#345900: 00list is here to stay
tag 345900 + wontfix thanks After re-reading the bug log, and five years later, I don't think supporting a 00list-less dpep is worth the trouble. It would be quite a challenge to do it appropriately, therefore I'm marking it as wontfix for now. If someone sends a patch doing all this properly, before the last package depending on dpatch leaves unstable, I'll consider applying it. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#386492: Add an entry to shared MIME info database
tag 386492 + wontfix thanks For the same reasons as #408826 was tagged wontfix, so shall this be: dpatch files can be anything, not just patches. I used to maintain a package which had a dpatch that was half a patch, half a shell script (patch did some ed magic, unpatch called patch). -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573567: pending
tag 573567 + pending thanks Thanks for the patch, I cleaned it up a bit and applied to my git tree. It will be in the next upload (along with an example rules file that uses it). -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562697: progress
owner 562697 ! thanks I started to clean up the bug reports, closed a few, tagged others, applied fixes from another bunch. The current state is available from my git repo at http://git.madhouse-project.org/debian/dpatch/ There's still a dozen more bugs I need to wade through, but there's progress already! -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#403903: dpatch-edit-patch ignores DPATCH_WORKDIR and REFPDIR + patch
Rémi Debay debay.r...@gmail.com writes: In fact it uses /tmp with both.The value is hardcoded. Here is a diff fixing it : = 45d44 echo $DPEP_TMPDIR 176c175 WORKDIR=$(TMPDIR=$DPEP_TMPDIR mktemp -d -p $DPEP_TMPDIR dpep-work.XX) --- WORKDIR=$(TMPDIR=$DPEP_TMPDIR mktemp -d -p /tmp dpep-work.XX) 187c186 REFPDIR=$(TMPDIR=$DPEP_TMPDIR mktemp -d -p $DPEP_TMPDIR dpep-ref.XX) --- REFPDIR=$(TMPDIR=$DPEP_TMPDIR mktemp -d -p /tmp dpep-ref.XX) = Could you send an unified diff (diff -u), please? Or even better, a git diff output? Though I can figure out what the above diff does, there's a ton of dpatch bugs I need to review, and since your patch is reasonably recent, there's a chance you can respond before I finish with the rest, and make my life easier :) Thanks in advance! -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#342768: [patch] dpatch: allow -p0 format patches
Gergely Nagy alger...@madhouse-project.org writes: This would introduce functionality I'd have to document, a couple of new options, and so on and so forth. Not really looking forward to it. Furthermore, dpatch.lib.sh doesn't even need to be changed, one can simply use DPATCH_LIB_NO_DEFAULT and implement a dpatch_patch/dpatch_unpatch function, that calls patch -p0. One can also use debian/patches/00template to prepare such a header, and dpatch-edit-patch will use it. Even better, dpatch.lib.sh supports debian/patches/00patch-opts, where one can override the default patch options, and add -p0. Assuming that patch -p1 -p0 does the rigth thing and uses -p0, this will work. I'm still not done investigatin the dpatch-edit-patch side, but with a bit of tweaking and post-processing of dpep output, this is already possible to do, just not all that obvious, and certainly not documented. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#466364: Please set the timestamp of patched files to guard against timestamp skews
tag 466364 + pending thanks My current git tree has a patch that will reset all timestamps after patching, provided that patchutils is installed (for lsdiff), and when dpatch.lib.sh's default patching mechanism is being used. Patches generated by dpatch-edit-patch fulfill that requirement. If you need this functionality, you need to build-depend on patchutils aswell as dpatch, though. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#355278: dpatch dose not work in CPP mode correctly on non-linux archs
retitle 355278 dpatch does not work in CPP mode correctly on non-linux archs
tag 355278 + pending
thanks
Retitling, because adding features to dpatch is not really on my agenda,
and since the bug report is very old, packages that still use dpatch,
are probably already fixed, and new packages should not use it.
On the other hand, the CPP mode would be a viable alternative to the
00list.${DEB_BUILD_ARCH_CPU}, if it only worked.
Therefore, in my git repo, I changed the CPP mode to replace - with
underscores when setting the appropriate CPP macro. That should cover
all currently supported Debian ports to the best of my knowledge.
--
|8]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#372787: dpatch: [manual] Patch handling commands - apply/deapply command syntax
tag 372787 + pending thanks Actually, the (patch) and (unpatch) stuff are aliases, not parameters. I do agree however, that this is not exactly clear, and it will be fixed in the next upload. It will read something like: COMMANDS Patch handling commands apply [options] patch [options] -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#391776: dpatch-get-origtargz silently renames .bz2 to .gz
tag 391776 + wontfix thanks I considered rewriting dpatch-get-origtargz to support most compressions (gz, bz2 and xz), but it turned out to be more difficult than first estimated. Nowadays there's debian/rules get-orig-source and uupdate, which are superior solutions. Therefore, the next upload will remove the dpatch-get-origtargz script, and the dpatch-edit-patch feature that depended on it too. If anyone still uses this feature, they're well advised to switch to debian/rules get-orig-source instead. It's far more reliable. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#328391: dpatch: could default to -b when only debian
tag 328391 + wontfix thanks For -b to work by default, dpatch-get-origtargz must work reliably. However, it doesn't. So much so, that it is scheduled for removal in the next dpatch upload. Instead, debian/rules get-orig-source should be provided by the packaging, and an appropriate hook script set up. But with the removal of dpatch-get-origtargz, -b cannot be made default unless there is a debian/rules get-orig-source.. and while I can do a test for that, dpep is already too clever, so I'd rather not make it even more so, lest it gains conciousness. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#449190: dpatch-edit-patch: support packages using svn-bp and mergeWithUpstream
tag 449190 + pending thanks Added Daniel's HOWTO (with minor modifications) to my git repo, it will be part of the next upload. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#397290: Bug #397290: [patch] dpatch: prerequisites for dpep?
tag 397290 + wontfix thanks The supplied patch does not apply cleanly to 2.0.31, and I'm not feeling comfortable enough to modify dpatch-edit-patch myself, however trivial a feature would be. If this feature is still needed (which I highly doubt), please send an updated patch against my git tree[1], preferably with an update to the man page aswell, and a command-line option too. Until then, I'm marking it as wontfix, as I will not be fixing it. 1: http://git.madhouse-project.org/debian/dpatch/ -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#342768: [patch] dpatch: allow -p0 format patches
tag 342768 + wontfix thanks I investigated how hard it would be to support this use-case in dpep, and I don't feel it would be worth the effort. Marking it wontfix, but patches can change my mind. And by patch, I mean something that only touches dpatch-edit-patch, and adds documentation that explains how to use the new feature together with debian/patches/00patch-opts. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#328397: dpatch-convert-diffgz should work without dpkg-buildpackage
tag 328397 + wontfix thanks In 2011, one shouldn't convert to dpatch, quite the contrary: one should convert away from it. Therefore, I do not feel the need to implement this feature, unless a working patch is provided against my git tree[1]. Marking the bug wontfix meanwhile. 1: http://git.madhouse-project.org/debian/dpatch/ -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531607: dpatch: Support multiple patch phases
tag 531607 + wontfix thanks This would be quite a big feature for something that should be moved away from (like eclipse did ;). Therefore I'm marking it wontfix. Patches can convince me otherwise, but without a patch, I'll stand by my opinion that the use-effort ratio would be imbalanced in the wrong direction. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#407306: pending
tag 407306 + pending thanks Took the easy route, and updated the documentation to say that the author's name is taken from $DEBFULLNAME. This will be part of the next upload. This seemed to be a lot easier than trying to figure out a reasonable way to get the logged in user's full name. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#403903: dpatch-edit-patch ignores DPATCH_WORKDIR and REFPDIR + patch
tags 403903 + pending thanks Actually, I went ahead and fixed it myself, though, slightly differently, but it works, nevertheless. The fix will appear in the next upload. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#400897: /usr/share/doc/dpatch/examples/dpatch/01_config.dpatch.gz fails with non-default workdir
tags 400897 + wontfix thanks Marking this wontfix, because there were no other reports of failures due to using a non-standard --workdir. Therefore, there's nothing to fix, but aesthetics: the examples - unless noted otherwise - were made with the default workdir in mind. Patches will be considered, but otherwise I do not consider this a bug. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481237: View current patch
tags 481237 + pending thanks I opted to make this possible a bit differently: instead of a separate dpatch-edit-patch-diff or similar command (althouth debian-diff could've worked with some PATH munglig), dpatch-edit-patch now exports two environment variables to the subshell: DPEP_SHELL_REFDIR and DPEP_SHELL_WORKDIR. The former is the full path to the reference directory, the latter is the full path to the working directory. One can then use diff -Nur $DPEP_SHELL_REFDIR $DPEP_SHELL_WORKDIR to see the current changes without exiting the subshell. This will be documented on the dpatch-edit-patch manual page aswell, and will be part of the next dpatch upload. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#400092: dpatch: [dpatch.lib.sh] DPATCH_LIB_NO_DEFAULT is not documented in dpatch(1)
tags 400092 + wontfix thanks After thinking about this overnight, I wonder: what's the use? Yes, the documentation could be better, but would anyone read it? I doubt so, as new packages use 3.0 source formats, and don't touch dpatch. Old ones probably don't care about these details anymore. I do not think writing a manual page for dpatch.lib.sh would worth the effort, therefore I am marking this bug as wontfix. Documentation patches can convince me otherwise, however. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#342774: [patch] dpatch: new DPEP_OMIT_TIMESTAMPS
tags 342774 + pending thanks I applied the patch, and modified dpep to accept a -n|--notimestamp option aswell. Also documented it on the manual page. It will be part of the next upload. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#117436: testing on squeeze
I just tried to reproduce this on my squeeze system, with a freshly built gramofile, and in all terminal emulators I tried (xterm, gnome-terminal konsole), it behaved correctly: I started gramofile, it's menu appeared, I pressed Q, it exited, and cleared the screen, giving me a clean prompt back. However, I could reproduce the problem on the console, where it left a few things on the screen afterwards. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#117436: testing on squeeze
tags 117436 + patch
thanks
Actually, I could reproduce this on the console, to some extent: the
gramofile screen remained there, but above my prompt.
Nevertheless, the attached patch (to be applied on top of the one in
#636885) modifies gramofile to clear the screen anyway. Tested the
result on the text console, in various terminal emulators, and it
behaved as it should have: cleared the screen when exiting.
--
|8]
From 4a5fbe7e77e30437865f608fdc0df8bb231488ad Mon Sep 17 00:00:00 2001
From: Gergely Nagy alger...@madhouse-project.org
Date: Sun, 14 Aug 2011 14:34:12 +0200
Subject: [PATCH] debian: Add a new patch to clear the screen.
---
debian/changelog|5 -
debian/patches/92-clearscreen.patch | 17 +
debian/patches/series |1 +
3 files changed, 22 insertions(+), 1 deletions(-)
create mode 100644 debian/patches/92-clearscreen.patch
diff --git a/debian/changelog b/debian/changelog
index 1181fe7..b06c561 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,8 +5,11 @@ gramofile (1.6-8.1) unstable; urgency=low
+ This resulted in converting to Format: 3.0 (quilt).
+ Standards-Version bumped to 3.9.2.
+ All patches quilt refreshed to apply cleanly.
+ * New patches:
+ + 92-clearscreen.patch: Explicitly clear the screen after exiting
+gramofile (Closes: #117436).
- -- Gergely Nagy alger...@madhouse-project.org Sun, 14 Aug 2011 13:18:37 +0200
+ -- Gergely Nagy alger...@madhouse-project.org Sun, 14 Aug 2011 14:31:21 +0200
gramofile (1.6-8) unstable; urgency=medium
diff --git a/debian/patches/92-clearscreen.patch b/debian/patches/92-clearscreen.patch
new file mode 100644
index 000..02427ca
--- /dev/null
+++ b/debian/patches/92-clearscreen.patch
@@ -0,0 +1,17 @@
+Description: Explicitly clear the screen after exiting gramofile.
+ Explicitly call clear() and refresh() in finishmenu(), so that the
+ screen gets properly cleared.
+Author: Gergely Nagy alger...@madhouse-project.org
+Bug-Debian: http://bugs.debian.org/117436
+
+--- gramofile-1.6.orig/gramofile.c
gramofile-1.6/gramofile.c
+@@ -38,6 +38,8 @@ init_curses (void)
+ static void
+ finishmenu (int sig)
+ {
++ clear ();
++ refresh ();
+ endwin ();
+ exit (0);
+ }
diff --git a/debian/patches/series b/debian/patches/series
index 6ddf9c3..8312ad4 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -12,3 +12,4 @@
80_fix_wav_length.patch
90_report_recording_errors.patch
91_rename_cdrecord_wodim.patch
+92-clearscreen.patch
--
1.7.2.5
Bug#637066: [wnpp] removal of gramofile has been requested!
Gergely Nagy alger...@balabit.hu writes: Dale Amon a...@vnl.com writes: Is there a functional replacement for splitting tracks from cassette tapes and vinyl records? If not I think it fills the kind of important niche that isn't needed until... it is *REALLY* needed! FYI, if there is no suitable alternative, I can offer to help cleaning up the currently open bugs against gramofile (they seem reasonably straightforward to me), and see about porting it to ALSA. I've submitted a patch for #636885 (yada), and #117436 (clearscreen). Since there are users of the package, and there is no alternative, I'd like to suggest keeping the package in the archive. After my cleanups, it'll be good for another decade with next to no maintainance. As for the other bugs: #298672: The menu can be extended to mention that sound files need to be WAV files, everything else will be played as if it were in that format. I will submit a patch that does this soon. #138786: I'd either stick a wontfix on it, or close it. The original reporter never replied back to the bug, and noone else showed interest, thus, the effort of doing it isn't worth it, in my opinion. #421788: The hardest one of it all: this pretty much translates into Please port me to ALSA. I'll see if I can do that in an afternoon. If all goes well, I'll submit a patch for this too. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#298672: patch
tags 298672 + patch thanks Attached is a patch that updates the help text under the Play a sound file menu. It should be applied after the patch I sent to #117436. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637797: virtualbox-4.1: vboxdrv causing Kernel Panic on shutdown
Dirk Blau dirkb...@ymail.com writes: Package: virtualbox-4.1 Severity: critical Justification: breaks the whole system There is no such package in Debian (especially not in stable). Can you try it with virtualbox (4.1.0-dfsg-2) aswell? If it happens there, this bug can be reassigned to the appropriate package. Otherwise it's a problem outside of Debian, and the bug should be reported to upstream. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637797: virtualbox-4.1: vboxdrv causing Kernel Panic on shutdown
Dirk Blau dirkb...@ymail.com writes: Gergely Nagy alger...@madhouse-project.org: There is no such package in Debian (especially not in stable). Can you try it with virtualbox (4.1.0-dfsg-2) aswell? I'm not sure how to get exactly the package you mentioned installed. If you could give me a quick advise how to do that i'll give it a try. Well, to be honest, it's not going to be quick, as virtualbox 4.1 is not available for stable from Debian's repositories. So I'd suggest not even going there, after all. Synaptic shows the following version for the package i had installed: 4.1.0-73009~Debian~squeeze Let me guess, the maintainer is Oracle Corporation i...@virtualbox.org? And you have something like the following in /etc/apt/source.list: deb http://download.virtualbox.org/virtualbox/debian squeeze contrib non-free In this case, the package is from Oracle, not Debian, and the report should be filed with them: http://www.virtualbox.org/wiki/Bugtracker -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638297: O: edbrowse -- A /bin/ed-alike webbrowser
retitle 638297 ITA: edbrowse -- A /bin/ed-alike webbrowser owner 638297 alger...@madhouse-project.org thanks Mario Lang ml...@debian.org writes: I have been neglecting edbrowse for far too long. I am sorry for this. While it is a very interesting tool, I still find lynx more convenient :-). However, its really useful for scripting and generally, for command-line freaks. However, it needs a maintainer who actually uses it on a more or less regularily basis. I'm using edbrowse reasonably often, both for scripting and for actual browsing when either my terminal or the network connection doesn't permit better. (The latter happens rather often) Plus, this package is probably the closest I'll get to anything ed-like in the forseeable future. For these reasons, I'd like to adopt the package. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638297: O: edbrowse -- A /bin/ed-alike webbrowser
Mario Lang ml...@debian.org writes: Plus, this package is probably the closest I'll get to anything ed-like in the forseeable future. For these reasons, I'd like to adopt the package. I know it will be in good hands with you, have fun with it! :-) It turns out that Jean-Philippe MENGUAL wanted to maintain it too, and I kinda stepped on his toes. So he'll go ahead with it, and I'll help if so need be (otherwise just sit back and enjoy his work as a mere user ;). He already has an updated package on mentors.debian.net. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638554: ITP: news -- GTK-based highly configurable RSS Ticker
Emmanuel Thomas-Maurin manutm...@gmail.com writes: Package: wnpp Severity: wishlist Owner: Emmanuel Thomas-Maurin manutm...@gmail.com * Package name: news I do hope that the final package name will be something... far less generic. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640411: RFP: libtest-harness-archive-perl -- Create an archive of TAP test results
Package: wnpp Severity: wishlist * Package name: libtest-harness-archive-perl Version : 0.14 Upstream Author : Michael Peters mpet...@plusthree.com * URL or Web page : http://search.cpan.org/dist/TAP-Harness-Archive/ * License : Artistic Description : Create an archive of TAP test results TAP::Harness::Archive is a direct subclass of TAP::Harness and behaves in exactly the same way except for one detail. In addition to outputting a running progress of the tests and an ending summary it can also capture all of the raw TAP from the individual test files or streams into an archive file (.tar or .tar.gz). I recently wanted to use prove -a (for various reasons, including integration with my CI system), and the lack of this module was my greeting. It would be very neat, if this could be packaged. It looks like a very easy task, with dh-make-perl being able to do the vast majority of the work, with only some minor edits here and there. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640411: RFP: libtest-harness-archive-perl -- Create an archive of TAP test results
gregor herrmann gre...@debian.org writes: On Sun, 04 Sep 2011 17:58:58 -0400, Jeremy Allard wrote: Package: wnpp Severity: wishlist * Package name: libtest-harness-archive-perl Version : 0.14 This was already reported as #584077. My bad then, apologies for the duplicate. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556526: hurd - FHS violation: /libexec
Jérémie Koenig j...@jk.fr.eu.org writes: On Wed, Sep 7, 2011 at 11:07 AM, Philipp Kern pk...@debian.org wrote: On Mon, Nov 16, 2009 at 03:40:05PM +0100, Bastian Blank wrote: Hurd violates the FHS by using /libexec. This name seems to be only used by init and /etc/ttys. I'm upgrading this to serious on the grounds that this package is only useful on the non-release architecture hurd-i386 and it's clearly a policy violation that makes the package unsuitable for a release. There's a patch here: http://lists.archhurd.org/devel/msg00102.html. The patch moves /libexec/* to /etc. I guess /sbin (or maybe, /lib/hurd) would be more appropriate. What do you think? With my occassional Hurd user hat on, /lib/hurd sounds like the most appropriate place to put these stuff into, or failing that, /sbin. But definitely not /etc. Neither init, nor console-run strike me as things the user would wish to edit. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638864: dpatch-edit-patch fails if there is binary data in the patch
tag 638864 + patch found 638864 2.0.32 thanks Ben Brown edi...@ninehertz.co.uk writes: Package: dpatch Version: 2.0.31 Severity: normal This also affects 2.0.32, same patch should apply. I'll add it with the next upload, thank you. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639020: debhelper: dh_installlogcheck should support --name
Package: debhelper
Version: 8.9.3~bpo60+1
Severity: wishlist
Tags: patch
While splitting a package into smaller parts, I came accross a little
problem: the old package installed logcheck files, and I wanted to move
those to the new one, keeping the filename.
For logrotate, I could do this easily, as dh_installlogrotate supports a
--name option, so that my debian/$package.$name.logrotate gets installed
as /etc/logrotate.d/$name (instead of as $package). I wanted to do the
same with dh_installlogcheck, but unfortunately, that helper has no such
feature.
Attached below is a trivial patch that adds the option, along with
documentation (might need a little rewording, perhaps, but this is the
best I could do at the moment), against debhelper's git head.
-- System Information:
Debian Release: 6.0.2
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages debhelper depends on:
ii binutils 2.20.1-16 The GNU assembler, linker and bina
ii dpkg-dev 1.15.8.11 Debian package development tools
ii file 5.04-5Determines file type using magic
ii html2text 1.3.2a-15 advanced HTML to text converter
ii man-db 2.5.7-8 on-line manual pager
ii perl 5.10.1-17squeeze2 Larry Wall's Practical Extraction
ii perl-base 5.10.1-17squeeze2 minimal Perl system
ii po-debconf 1.0.16+nmu1 tool for managing templates file t
debhelper recommends no packages.
Versions of packages debhelper suggests:
ii dh-make 0.55 tool that converts source archives
-- no debconf information
--
|8]
From 2a580656d01355c7fcd52d3441362bc0d3daf166 Mon Sep 17 00:00:00 2001
From: Gergely Nagy alger...@madhouse-project.org
Date: Tue, 23 Aug 2011 20:36:57 +0200
Subject: [PATCH] dh_installlogcheck: Add support for --name.
This patch makes dh_installlogcheck be similar to other helpers, like
dh_installlogrotate that already support a --name option: to install
the files as if they were installed by a different package.
Signed-off-by: Gergely Nagy alger...@madhouse-project.org
---
dh_installlogcheck | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/dh_installlogcheck b/dh_installlogcheck
index b6956fa..982e75f 100755
--- a/dh_installlogcheck
+++ b/dh_installlogcheck
@@ -39,6 +39,16 @@ subdirectories of Fetc/logcheck/ in package build directories.
=back
+=head1 OPTIONS
+
+=over 4
+
+=item B--name=Iname
+
+Look for files named Fdebian/package.name.logcheck.* and install
+them into the corresponding subdirectories of Fetc/logcheck/, but
+use the specified name instead of that of the package.
+
=cut
init();
@@ -56,7 +66,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
if (! -d $tmp/etc/logcheck/$type) {
doit(install,-o,0,-g,0,-d,$tmp/etc/logcheck/$type);
}
- my $packagenodot=$package; # run-parts..
+ my $packagenodot=pkgfilename($package); # run-parts..
$packagenodot=~s/\./_/g;
doit(install,-m,0644,$logcheck,$tmp/etc/logcheck/$type/$packagenodot);
}
--
1.7.2.5
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
Yann Dirson ydir...@free.fr writes: Package: debhelper Version: 8.9.4 Severity: normal Following the last example from the dh manpage, I am trying the following rules file (compat=8). However, it seems to completely ignore the build-* overrides (install fails on manpage install): $ dh build-arch --no-act dh_testdir -a debian/rules override_dh_auto_configure dh_auto_build -a dh_auto_test -a I had a similar issue a couple of days ago. For me, putting dh's catch-all rule (%) last in my debian/rules file worked around the problem. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639341: dh: cannot override binary-arch and binary-indep selectively
Joey Hess jo...@debian.org writes: Gergely Nagy wrote: I had a similar issue a couple of days ago. For me, putting dh's catch-all rule (%) last in my debian/rules file worked around the problem. If you have a test case for this I would be happy to receive it in a separate bug report. Hrm, I tried to come up with a simple test case, but couldn't. And apparently, the package in which I did this apparently does not exhibit the problem anymore, either. So must have been something fishy in my environment. But for the record, my problem was that upstream had a build/ directory, and debian/rules build wasn't building, since it found the dir and considered it up-to-date. As a quick workaround, I wanted to add a build-stamp phony target as a dependency to build, and when I put that after the % rule, it didn't work at that time (read: it still didn't build, but considered the directory up-to-date), so I moved it before the cathc-all rule, and voila. However, when I moved the stamp-foo to the end now, it still behaves properly now. So either I fixed something in the packaging that I did not notice, or there was an issue with my environment which went away sometime during the past week. In any case, sorry for the noise. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639709: systemd: Please provide uncompressed sd-daemon.[ch]
Package: systemd Version: 29-1.1 Severity: wishlist systemd ships with /usr/share/doc/systemd/sd-daemon.[ch].gz, which is all nice, one can easily copy it to one's own project that needs it, but it would be - at least in my opinion - easier if either systemd or a systemd-dev package or similar would provide those files uncompressed, so software that wants to support systemd, and needs these files (and possibly sd-readahead.[ch], also in the same dir) could just build-depend on whatever package provides these, instead of having a number of copies in our sources. (Though, most sources would still have an embedded copy, to be able to compile on systems where these files are not provided by a package, but at least on Debian, we could use the latest and greatest upstream version.) -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641012: sample file
I tested with 5.08-1 aswell, same results as Tamas'. A sample file is attached to this email (similar content to what Tamas posted). The problem though, is that magic/Magdir/msdos contains this: # .COM formats (Daniel Quinlan, quin...@yggdrasil.com) # Uncommenting only the first two lines will cover about 2/3 of COM files, # but it isn't feasible to match all COM files since there must be at least # two dozen different one-byte magics. # test too generic ? 0 byte0xe9DOS executable (COM) Anything that starts with 0xe9 will be classified as a DOS executable, and that's about it. It's a one-byte magic, and as the comment above the line suggests, it's way too generic. I would suggest disabling this magic. -- |8] én is az interneten nézem és nem szaggat, de most rontottam a minõséget a folyamatosság reményében
Bug#642194: support for flowing debian branches
tag 642194 + upstream pending forwarded 642194 https://github.com/nvie/gitflow/issues/154 thanks Hi! The idea sounded so easy and tempting, that I went ahead and coded it. It's available from my git repo[1], on the feature/config-alias branch (also merged into the debian branch, which has been appropriately updated), if you want to take it for a test ride. I'll try to run it through upstream too, so the upload to unstable might take a little while (though, if I get no response within two weeks, I'll probably go ahead and upload it anyway). [1]: debcheckout git-flow -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642194: support for flowing debian branches
The idea sounded so easy and tempting, that I went ahead and coded it. It's available from my git repo[1], on the feature/config-alias branch (also merged into the debian branch, which has been appropriately updated), if you want to take it for a test ride. Right! I only left out how to use it! $ git config alias.dflow !GIT_FLOW_SELF=git-flow-debian git flow $ git flow init # To set up upstream workflow $ git dflow init # To set up debian workflow -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593790: any progress on clojure-1.2?
Muharem Hrnjadovic m...@foldr3.com writes: The list of enhancements added by rev. 1.2 is quite impressive: https://github.com/clojure/clojure/blob/1.2.x/changes.txt Any chance of it being packaged soon? Is there any way to help? You might be interested in the clojure1.2 package. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642452: SetUID-enabled binary doesn't run as root
reassign 642452 general thanks Jeffrey G Thomas jeffrey.tho...@nerdery.com writes: Package: setuid Severity: normal When reporting problems using the Debian BTS, the Package *must* be either a real package, or one of the acceptable virtual packages. In case of reporting problems that cannot be tied to any particular package, and a bugreport does need to be filed (ie, various support lists were already exhausted, and the bug was confirmed to be a bug in the system, basically), then it should be filed against the general pacakge. I have reassigned the bug there now. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642592: /etc/logrotate.d/rsyslog should not use 'compress' and 'delaycompress' options
Jérôme jerome.bo...@wanadoo.fr writes: I think that log files compression lowers the system performance on desktop computers which have now enough disk space for storing old logs. Desktop computers also have enough CPU power (and compared to that, negligible log volume) to do compression at log rotate time. It can still turned off when not wanted, but defaults should be conservative. As someone operating a couple of servers with low disk space, and high volume of logs, I very much like the default (even though I'm not using rsyslog - but the same settings should be applied for all syslogds present in Debian anyway). On my desktop, that ~10Mb of logs generated a day on my desktop takes negligible time and resources to compress. Compare it to updating the locate database.. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642592: /etc/logrotate.d/rsyslog should not use 'compress' and 'delaycompress' options
Jérôme Bouat jerome.bo...@wanadoo.fr writes: The question is not about cpu and memory resources but about energy consumption. Energy consumption has drawbacks whatever the primary source is (nuke, carbon based, solar, wind, ...). You're free to disable the compression then, on your own systems. Or turn off your computer. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642592: /etc/logrotate.d/rsyslog should not use 'compress' and 'delaycompress' options
Jérôme Bouat jerome.bo...@wanadoo.fr writes: Energy consumption has drawbacks whatever the primary source is (nuke, carbon based, solar, wind, ...). You're free to disable the compression then, on your own systems. Or turn off your computer. Think about the number of desktop/notebooks which have this default setting. I wouldn't be so sure of that. And since it cannot reliably determined whether something is a desktop or a server, the only sane way to set the compress/nocompress setting would be to ask the user at installation time. But then, one still needs a default setting, for unattended installations. And since the default so far has been compress, on the basis of element of least suprise, it should stay so aswell (not to mention that policy recommends[1] the compress option too). However, since this is such a tiny change, it'd cause more trouble for users to get asked, than to just installing a default, and letting them change it, if they wish to. It's a default after all, and power-conscious users can always remove the compress option. This small desktop specific setting would possibly not save the world but at least make it better. If you're so inclined, take it up with policy to not recommend[1] the compress option for log files. [1]: http://www.debian.org/doc/debian-policy/ch-files.html#s10.8 -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
