Package: wnpp
Severity: wishlist
Owner: Helmut Grohne [EMAIL PROTECTED]
* Package name: jugglemaster
Version : 0.4
Upstream Authors: Gary Briggs, Per Johan Groland, Ken Matsuoka, Greg Gilbert
* URL : http://icculus.org/jugglemaster/
* License : GPL
processing.
+
+ -- Helmut Grohne hel...@subdivi.de Thu, 21 Jun 2012 16:09:07 +0200
+
sgml-base (1.26+nmu3) unstable; urgency=low
* Non-maintainer upload.
diff -Nru sgml-base-1.26+nmu3/debian/control sgml-base-1.26+nmu4/debian/control
--- sgml-base-1.26+nmu3/debian/control 2012-05-28 13:58
Dear dpkg maintainers,
On Thu, Jun 28, 2012 at 02:05:56AM +0100, Ian Jackson wrote:
I'm not convinced that a Pre-Depends is the best answer here. I think
a better answer would be for the new dpkg to activate all file
triggers when it first starts, and for sgml-base to simply use
Depends.
On Tue, Nov 20, 2012 at 03:10:04PM +0800, Thomas Goirand wrote:
Can I also just add the above Debian repo, do --add-architecture,
and start replacing some packages? How can I for example, replace
perl, on a running server?
I would guess that using --add-architecture is a recipe for disaster at
On Mon, Nov 26, 2012 at 12:27:31AM +0400, ?? ?? wrote:
I see many note in this list like:
I'm registered to the list. So please *do not* Cc: me.
Technically this is a solved problem. The solution is called
Mail-Followup-To[1]. Due to the popularity of the Mutt, Gnus, KMail and
On Mon, Nov 26, 2012 at 08:03:54PM +0800, Thomas Goirand wrote:
The solution to this is very simple. Have the
mailing list manager to add a Reply-To: header
on each messages.
As you pointed out the solution is technically wrong.
But, probably, mailman is too stupid to have such
kind of
On Thu, Dec 06, 2012 at 02:05:13AM -0600, Peter Samuelson wrote:
In bug #695229, I noted that an Architecture: all package really should
be Multi-Arch: foreign. This led to an IRC discussion between Goswin,
Steve L. and me in which I formulated the proposal:
If a package is
On Sun, Dec 23, 2012 at 03:54:06PM +0100, Steffen Vogel wrote:
Package name: sun
Version : 0.1
Upstream Author : Steffen Vogel p...@steffenvogel.de
URL :
http://www.steffenvogel.de/2012/12/23/cron-jobs-fur-sonnenauf-untergang/
License : GPL
Since Paul Wise advertised dedup.debian.net already, I have a few more
bits.
This was an afternoon proof-of-concept thingy that kind of accidentally
got a debian.net pointer, but so be it. It seems to be somewhat useful.
The service basically records checksums of all regular files in Debian
sid
On Thu, Feb 21, 2013 at 07:05:08PM +0100, Paul Gevers wrote:
This indeed looks very useful. However, I don't think it is really
useful to trigger on common changelog and copyright files from the same
source package as they indeed usually are the same, which is fine of course.
Answering this
Package: wnpp
Severity: wishlist
Owner: Helmut Grohne hel...@subdivi.de
* Package name: python-ssdeep
Version : 2.9-0.2
Upstream Author : Philipp Seidel
* URL : https://github.com/DinoTools/python-ssdeep
* License : GPL-2
Programming Lang: Python
On Tue, Apr 16, 2013 at 03:04:20PM +0200, Goswin von Brederlow wrote:
Will that also detect files in multiarch packages that are not identical?
No, it does not do this at the moment. The main reason here is that
currently only amd64 is processed. Support for multiple architectures
would take a
On Thu, Apr 18, 2013 at 02:58:21PM +1000, Stuart Prescott wrote:
Helmut Grohne wrote:
The conclusion here is that the only way to fix this bug in sgml-base is
to have *no* dependency on dpkg at all.
Actually, removing the dependency on dpkg doesn't change the outcome at all
--
dpkg
On Fri, Apr 19, 2013 at 12:33:07AM +0200, Guillem Jover wrote:
As I pointed out on the debian-perl mailing list, after having
discussed about multiarch support for perl, I don't think a fully
multiarchified perl (nor at least python) should be uploaded to sid,
as going full multiarch on the
On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote:
It seems correct at first glance, but not enough to solve all the issues
mentioned. Currently existing package relationships lack information
that is necessary to do the right thing in all cases. Consider different
kinds of
On Sat, Apr 20, 2013 at 05:42:52PM +0300, Uoti Urpala wrote:
Helmut Grohne wrote:
On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote:
3) P runs a script using system interpreter X, and depends on the
interpreter environment supporting functionality provided by Q.
Q needs
On Sun, Apr 21, 2013 at 02:42:32AM +0300, Uoti Urpala wrote:
Should that set of running architectures be just architecture?
No. Some packages can have multiple runing architecturs. The most
obvious case is M-A:same packages where you can install the same package
for multiple architectures.
On Mon, Apr 22, 2013 at 07:31:54AM +0200, Guillem Jover wrote:
I guess a way to detect those could be piuparts runs that install
multiple instances of Multi-Arch:same packages, purge just one of
them, and compare that the packages created by the first instance
are not removed, and that other
On Fri, May 03, 2013 at 04:53:59PM +0800, Thomas Goirand wrote:
I think there's a consensus, the problem is who's going
to do the work for automating dropping of binaries and
rebuild.
Not implying that I am the one doing this work, I would like to learn
more about what needs to be touched to
On Mon, May 06, 2013 at 04:08:07PM +0200, Christoph Anton Mitterer wrote:
1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that listen per
default on the network (unless loopback only) shouldn't be started per
default, after being installed.
May I point to /usr/sbin/policy-rc.d? As has
On Wed, May 08, 2013 at 12:19:25PM +0200, Philipp Kern wrote:
Fedora updates are different. (And so are Ubuntu updates, if one considers
that it's possible to provide fixup scripts to update-manager pre-upgrade.)
As long as we're supporting upgrades through plain apt, that's going to
be hard.
On Wed, May 08, 2013 at 04:51:14PM +0100, Ian Jackson wrote:
It is good to have it released now, but I think we are all (mostly?)
agreed that wheezy took longer to release than we would have liked.
In particular, the RC bug count didn't drop quickly enough.
Thanks for bringing this up!
I
On Fri, May 10, 2013 at 11:48:37AM +0200, Marco d'Itri wrote:
[ reiterating the same arguments seen numerous times before ]
I suggest that we leave practical implications of the /usr merge aside
for a moment. The pros and cons have been discussed at lengths. If there
is value in further
On Thu, May 09, 2013 at 08:49:51PM +0100, Lars Wirzenius wrote:
* Remove RC buggy packages sooner rather than later. An RC buggy
package should be removed at soon as possible: when the bug
is identified, allow a bit of time for the bug to be verified
(was it actually an RC bug?), but
On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
This is utter bullshit and you should already know it. Systemd is much
more reliable as a whole than any other implementation. I have yet to
see a use case where it is not better.
With all due respect, this might be utter
On Mon, May 13, 2013 at 11:48:06AM +0200, Goswin von Brederlow wrote:
Both cases would need data for multiple archs.
For the second case if identical files are in all foo_arch.deb then
those should be in foo-common_all.deb. A dedup across archs instead of
across packages.
Thanks for
On Mon, May 13, 2013 at 12:05:59AM +0200, Josselin Mouette wrote:
Having a rock-stable PID 1 is nice and all, but it doesn???t help you if
something important crashes. On a production server, if apache crashes
and fails to reload properly because the scripts don???t get the ordering
right, it
On Mon, May 13, 2013 at 03:16:57PM +0200, Guillem Jover wrote:
The binNMU issue entails two ???sub-problems???. The first is the one
introduced by different entries in binNMUs on multiple architectures.
The other is the unmatched versions for possible out-of-step binNMU
versions.
I
On Tue, May 14, 2013 at 08:59:57AM +, Thorsten Glaser wrote:
Helmut Grohne helmut at subdivi.de writes:
What are the benefits of using shells other than dash for /bin/sh? (as
Why does dash get special treatment, anyway? It was ???suddenly??? in
Debian after having been used in Ubuntu
Small side note on this interesting idea:
On Tue, May 14, 2013 at 09:59:31AM +0200, Raphael Hertzog wrote:
The other points are more difficult to solve but would be useful in their
own to avoid the problem of small packages considered too heavy due to
their meta-data. It might be worth to
On Wed, May 15, 2013 at 03:39:54PM +, Thorsten Glaser wrote:
As for your requests of data: I do not provide them. As I said above,
I???m pushing for freedom of choice, not switching the default; of course
I???d be happy with the latter, even more so actually, but it must be a
thing not
On Tue, May 21, 2013 at 01:21:41AM +0200, Andreas Beckmann wrote:
That might be possible with DPAs and if upload management is changed
generally to get less broken packages into unstable. E.g.
I think that most of the ideas you presented are very useful and other
responses have (silently)
On Tue, May 21, 2013 at 10:53:43PM +0200, Lucas Nussbaum wrote:
There was a GSoC project in 2012 about generating sysvinit scripts from
systemd .service files. Was there some communication about its outcome?
I had a look at this idea and its result. From what I saw, I do not
believe a
pointed out some of that functionality as
non-essential (e.g. resource limits).
On Wed, May 22, 2013 at 10:39:06PM +0200, Helmut Grohne wrote:
* stdout/stderr to syslog redirection
This is possibly implementable, but needs more than a line of shell.
Do you know about logger(1
On Thu, May 23, 2013 at 07:16:18AM +0200, Zbigniew J??drzejewski-Szmek wrote:
Providing a conversion script which recreates all of systemd
functionality would basically mean reimplemting a big part of
systemd in shell. Providing an interpeter would man reimplementing
a big part of systemd in
On Sat, May 25, 2013 at 10:42:09PM +0800, Thomas Goirand wrote:
On 05/23/2013 03:14 PM, Helmut Grohne wrote:
I partly disagree here. A good reason to reimplement part of systemd is
to have a portable subset of its functionality. This could be part of
the answer to the question of what to do
On Sun, May 26, 2013 at 10:27:53PM +, brian m. carlson wrote:
At the risk of adding another level of indirection, we could add a
meta-init format that can generate an appropriate file for any of these.
Are you aware of http://wiki.debian.org/MetaInit (packages metainit and
dh-metainit)?
On Mon, May 27, 2013 at 09:04:53AM +0200, Ond??ej Surý wrote:
I have an idea ??? maybe we could have a pseudo-package called
please-improve (or whatever name we pick), where people can reassign
bugreports which they feel they are unable to handle. This pseudo-bug would
be monitored by some
Was there any reason for the additional CCs? I saw no Mail-Followup-To
or request for CC, so I dropped them.
On Mon, May 27, 2013 at 09:22:20AM +0200, Mathieu Malaterre wrote:
Doxygen will use SVG for graph (collaboration, inheritance), SVG is
AFAIK one of the best possible representation for
On Mon, May 27, 2013 at 10:35:48AM +0200, Mathieu Malaterre wrote:
On Mon, May 27, 2013 at 10:26 AM, Helmut Grohne hel...@subdivi.de wrote:
* Packages shipping .md5 and .map files. Even though these files are
small, there can be very many of them adding up to the installation
size
On Mon, May 27, 2013 at 09:13:44AM +0200, Ond??ej Surý wrote:
I would be quite happy to write service files for two (systemd, upstart) or
three (systemd, upstart, openrc) of those in all my packages[*], if it
stops the endless flamewar here. I would also be happy to have the
requirement to
On Fri, May 31, 2013 at 01:44:12AM +0300, Uoti Urpala wrote:
Steve Langasek wrote:
I can't speak to other distributions, but in Debian, the systemd maintainers
are in no position to decide that Debian will agree to rewrite its
Focusing on position to decide seems less than constructive.
I
Dear upstart developers,
debian-devel@l.d.o has been talking about socket activation interfaces.
The technical differences are nicely summarized:
On Fri, May 31, 2013 at 08:53:52PM +0200, Zbigniew J??drzejewski-Szmek wrote:
But chronology is less important then the technical differences between
On Sat, Jun 01, 2013 at 03:53:15AM +0200, Lennart Poettering wrote:
[...] I remember even emailing the Upstart guys about
that, but I never got any reply. This was a long long time before Upstart
added socket activation.
This appears to be the discussion starting with this mail:
On Fri, May 31, 2013 at 11:44:53PM +0200, Ond??ej Surý wrote:
cat php5-fpm.service EOF
[Unit]
Description=The PHP FastCGI Process Manager
After=syslog.target network.target
Small nitpick here: Specifying syslog.target in an After is completely
unnecessary and counterproductive. At the time
On Thu, Jun 06, 2013 at 10:23:14AM +0200, Thorsten Glaser wrote:
tglase@tglase:~ $ fgrep X32 /boot/config-3.9-1-amd64
# CONFIG_X86_X32 is not set
See http://wiki.debian.org/X32Port and
http://lists.debian.org/debian-devel/2013/05/msg00355.html
Helmut
--
To UNSUBSCRIBE, email to
Currently awe number of services assume the following setting.
A service that retries DNS lookups, does not need to declare a boot
ordering relation on a name server.
I am currently aware of two examples of this assumption:
1) When using systemd, the DNS server is a socket service, so
On Sun, Jun 09, 2013 at 07:41:34PM +0200, Daniel Pocock wrote:
My feeling is that the user should be told go and run sudo or su in a
terminal window you opened manually
Otherwise, they can't be sure they are putting their password in a
genuine Debian popup.
Please explain your threat model.
No need to CC me here, see Mail-Followup-To.
On Mon, Jun 10, 2013 at 05:36:46PM +0100, Ian Jackson wrote:
I think this is a somewhat different problem to the one you originally
state. The real problem here is that resolv.conf is changing and
programs don't have the means to cope.
Thanks for
Thanks for all the suggestions on how to implement either
On Mon, Jun 10, 2013 at 05:36:46PM +0100, Ian Jackson wrote:
A. resolv.conf is a static file which changes only very rarely.
Implications:
or
B. resolv.conf is not static and may change due to network
environment changes.
On Wed, Jun 12, 2013 at 01:42:58PM +0200, Tollef Fog Heen wrote:
I'm not sure why you think systemd changes anything here?
One of the main purposes of systemd is to eliminate dependencies and
fulfil them with socket activation. When converting init scripts to
.service files, this will likely
On Sun, Jun 23, 2013 at 09:28:07PM +0100, Philip Hands wrote:
If etckeeper were to check in the unmodified versions of the packaged
conffiles in a branch called 'dpkg-dist' (or whatever) then it would be
trivial to do a diff.
Presumably it would be possible to do this in one of the hook
On Fri, Jun 28, 2013 at 05:02:51PM +0200, Thomas Hood wrote:
Resolvconf supports both mode A and mode B and allows switching between them.
With resolvconf installed, (A) so long as a local forwarding nameserver is
running, resolv.conf points to this nameserver and thus rarely changes; but
there is no other name server. It should probably be
accompanied with a warning comment, because this case should never occur
during normal operation.
On Sun, Jun 30, 2013 at 10:40:03PM +0200, Thomas Hood wrote: (slightly
reordered)
Helmut Grohne wrote:
It is true, that ntpd can work around
fully agree.
Helmut Grohne wrote:
Usually any program reads
/etc/resolv.conf once on the first DNS lookup. So all daemons started
before the local DNS cache will either use a different server, or fail
DNS resolution in all cases. A minority of services (avahi-daemon,
fetchmail, postfix
On Wed, Jul 03, 2013 at 10:24:42AM +0200, Tollef Fog Heen wrote:
What do you do when you are on a network that blocks DNS lookups that
don't go via the DNS servers for that network? Or for networks that do
that until you visit a web page and press a button on a form?
Manually reconfigure
On Sun, Jul 07, 2013 at 02:30:33PM +0200, Thomas Hood wrote:
Executive summary: The getaddrinfo() returns different values
depending on the OS and on nsswitch.conf settings, making it
very difficult to use getaddrinfo() return values to deciding how
to handle an error.
Thanks for not giving
On Mon, Jul 15, 2013 at 11:27:22AM +0200, Ondřej Surý wrote:
Just a quick idea:
Can we (the mysterious somebody) write a drop-in simple dummy init.d script
which would take a(ny) systemd service file and run the daemon on
non-Linux-kernel systems?
I proposed[1] this earlier. The environment
On Mon, Jul 15, 2013 at 03:32:42PM +0300, Arto Jantunen wrote:
In addition to that the wrapper also needs to be able to track the
processes started by the systemd service (the admin might want to stop
or restart services in addition to starting them), which systemd does by
using cgroups.
On Mon, Jul 15, 2013 at 03:14:43PM +0100, Simon McVittie wrote:
On 15/07/13 14:38, Helmut Grohne wrote:
Indeed we are out of luck with Type=forking. In the presence of a decent
init system daemonizing is the job of the init system. It is uselessly
duplicated code. Let's rip that code out
On Tue, Jul 16, 2013 at 06:38:18PM +0100, Dmitrijs Ledkovs wrote:
Imho the overhead between having just /etc vs / encrypted is
small, if /var, /usr, /home, /opt are separate mountpoints.
Thus to me, treating /etc separately is a misfeature, considering a
mounted / assumes /etc must be present.
On Wed, Jul 17, 2013 at 01:26:34PM -0700, Steve Langasek wrote:
Though if we're going to talk about bugs, even though the kernel audio
drivers have long since adapted to meet pulseaudio's requirements, PA itself
still manages to turn up some doozies.
On Thu, Jul 18, 2013 at 07:05:16AM +0200, John Paul Adrian Glaubitz wrote:
Yeah, I see that. But my original point was that the many griefs and
complaints people about PulseAudio have originate from the fact that
many people already used it when it simply wasn't ready yet, so it's
not fair to
On Fri, Jul 19, 2013 at 10:36:06PM +0200, Philipp Kern wrote:
On 2013-07-19 11:56, Helmut Grohne wrote:
Neither are yours. PA works fine for me with Bluetooth headsets and
regular sound cards on GNOME. Leaving regular gnome-bluetooth
crashes aside (that crash the shell, yay).
I am aware
On Fri, Jul 19, 2013 at 10:49:07PM +0200, Vincent Bernat wrote:
Did you see the examples of asoundrc I posted? PulseAudio removes all
this non-sense by providing mixing in almost all situations (while Alsa
is doing it out of the box only for analog output), correct setup of
output (no need to
On Wed, Jul 31, 2013 at 06:56:40PM +0200, Stefano Zacchiroli wrote:
I'm myself guilty of having implemented, back in 2007, python-debian's
support to manipulate .deb files: the debian.debfile module. It is yet
another Python implementation of deb(5), because back in the days there
was no
Package: python-debian
Version: 0.1.21+nmu2
Severity: wishlist
Control: block -1 by 704594
On Thu, Aug 01, 2013 at 04:19:42PM +0200, Stefano Zacchiroli wrote:
Can you please file a bug report about that (ideally marking the pending
ITPs as blockers for it)? Regarding changing interfaces it
On Sun, Aug 04, 2013 at 10:24:59PM -0700, Vincent Cheng wrote:
On Sun, Aug 4, 2013 at 9:44 PM, Fabian Greffrath fab...@greffrath.com wrote:
I do occasionally check for identical files on different systems by
comparing their md5sums. So, just out of interest, could someone tell me
(how to
On Mon, Aug 05, 2013 at 01:33:24PM +0100, Ian Jackson wrote:
AIUI SHA-512 is faster than SHA-256 on many processors, and not
usually slower on the others. If the hashes are too long, they can be
truncated.
Not that, I think it matters, but this got me interested. It appears
that in practice
Thanks for your explanations!
On Thu, Aug 29, 2013 at 02:39:09PM +0200, Ansgar Burchardt wrote:
As this suite is much smaller than the full archive, updating it can be
done with much less overhead and is done with every cron.unchecked
run. Packages.gz (amd64) is just 98 kb, Sources.gz is 180
On Tue, Oct 08, 2013 at 07:36:57PM +, Bill Allombert wrote:
Did you try to run rc-alert recently ? The output is totally overwhelming
for something that is to run on several computers and several times by
month. Most of the bugs are reported against important packages that cannot
be
maybe provide an easy support path for sysvinit on non-linux
platforms for a large number of simple services.
There's a subthread about that starting at
https://lists.debian.org/debian-devel/2013/05/msg01309.html
Helmut Grohne (Cced) did most of the work on analyzing those possibilities
Hi Steve,
On Tue, Oct 29, 2013 at 09:31:37AM -0700, Steve Langasek wrote:
On Tue, Oct 29, 2013 at 10:22:54AM +0100, Helmut Grohne wrote:
Having read the parts of the ctte bug, it feels odd to preclude the
option of supporting multiple init systems from discussion or
consideration
Hi Thorsten,
On Wed, Oct 30, 2013 at 04:05:48PM +, Thorsten Glaser wrote:
* Write scripts for one system and generate the other from it
or even
* Write ???Debian init declaration??? and let something take care
of generating an initscript and whatever the other systems
use out of it
Hi Thorsten,
On Mon, Oct 28, 2013 at 05:30:03PM +, Thorsten Glaser wrote:
Stefano Zacchiroli zack at debian.org writes:
*technical* decision is stupid. We really need to stop thinking that
every single member of the Debian project, just because he/she is a DD,
has a clue on every
On Fri, Nov 01, 2013 at 01:28:59PM +, Simon McVittie wrote:
In nss-mdns/experimental, I tried this:
Package: libnss-mdns
Architecture: any
Multi-Arch: same
Package: lib32nss-mdns
Architecture: i386
Depends: libnss-mdns (= ${binary:Version})
Description:
Hi,
The tar file format supports hard links. Thus technically Debian
packages can contain hard links. A significant number of packages
including key packages such as bzip2, gzip, and ifupdown use this
technique. While same-directory hard links are an established practise,
the same is not so true
On Wed, Nov 13, 2013 at 12:11:27PM +0100, Adam Borowski wrote:
So you save a small number of inodes, and get problems if the filesystem's
layout is unconventional. Such savings don't seem to be worth the trouble
to me.
I was questioning the existence of said trouble. I still do that. If the
On Fri, Nov 15, 2013 at 01:50:05PM +, Jonathan Dowland wrote:
I'm not sure that making a general rule based on an edge-case is a
good idea. Publican is not very popular at all, it's quite likely
that none of the 70 or so people who have installed it have done
anything unusual with mounts
On Thu, Jan 09, 2014 at 07:20:40PM +, Colin Watson wrote:
If you weren't one of the people in the thinking extremely hard about
multiarch BOF at DebConf, note that Multi-Arch: foreign denotes a point
in the dependency graph where you're allowed to switch architectures,
Multi-Arch: allowed
Hi Pere,
On Wed, Feb 05, 2014 at 10:31:09PM +0100, Petter Reinholdtsen wrote:
The idea is to let init.d scripts look like this:
#!/lib/init/init-d-script
### BEGIN INIT INFO
# Provides: daemon
# Required-Start:$remote_fs $syslog
# Required-Stop: $remote_fs
Hi Ansgar,
I am sorry to tell you that you are completely missing the point.
On Thu, Feb 06, 2014 at 11:35:17AM +0100, Ansgar Burchardt wrote:
On 02/06/2014 10:56, Helmut Grohne wrote:
The relevant bits can be found in insserv, watch out for
/lib/init/upstart-job.
The current version
On Thu, Feb 06, 2014 at 11:47:24AM +0100, Petter Reinholdtsen wrote:
actions on services). Do I misunderstand how upstart-job work? If I
install a package with an upstart job and a symlink to
/lib/init/upstart-job from /etc/init.d/ on Hurd, will it work?
Testing... Nope, did not work:
On Thu, Feb 06, 2014 at 12:34:49PM +, Simon McVittie wrote:
I'm sure we've been over this, on this very list, in several previous
threads. I used to think this was a great idea, too; I've been convinced
that it isn't feasible.
Yes, I concur with the reasoning that I didn't quote here. In
On Wed, Feb 12, 2014 at 02:53:39PM +0400, Oleg wrote:
scp /var/log/syslog ...
Why do i need an unneeded layer for this - journalctl?
Heh. Maybe we can turn this into a useful question:
Assume that I have a broken system (maybe the disk is partially broken
or it got owned and I don't want to
On Thu, Feb 13, 2014 at 10:17:46PM +0100, Holger Levsen wrote:
nope, it's worse than you think: the arch specific package built on the
developers machine (in a random^wnon predicatable environment) will not be
rebuild, there are also no build logs available.
See
On Thu, Feb 06, 2014 at 11:59:11AM +, Ian Jackson wrote:
Before you go too far down this path, I'd like to suggest that you do
something which makes it possible to provide init system configuration
for other than sysvinit, at the same time. And that you use an
arrangement which uses a
On Mon, Feb 17, 2014 at 09:02:56AM +0100, John Paul Adrian Glaubitz wrote:
I don't know whether this is a good idea. What if I want to listen to
something over my headphones which I don't others want to hear and
I know about this feature. I expect the sound to be over headphones
only, yet it's
On Sun, Feb 16, 2014 at 02:18:08PM +0100, Michael Biebl wrote:
For the record: If the recovery system does run systemd, you go
journalctl -D /path/to/your/journal/copy.
Small correction here: The recovery system needs to have systemd
*installed*, not running. All you need is the journalctl
On Tue, Feb 18, 2014 at 10:17:53AM +0100, Matthias Urlichs wrote:
but it takes care of the Future part. For the past one, obviously
you'll have to ask PA to enumerate the sink's inputs and then move them
to the new default one by one.
The pavucontrol GUI doesn't do that currently, but it
On Tue, Feb 18, 2014 at 08:05:12PM +, Kevin Chadwick wrote:
It's just occurred to me that the binary format may not work with append
only logging?
That's true for the journal. When the journal opens its binary log, it
flags the file as being opened, but what is the issue with not being
On Tue, Mar 04, 2014 at 02:33:23PM -0600, Gunnar Wolf wrote:
Umh, I feel I have to answer this message, but I clearly don't have
enough information to do so in an authoritative way¹. AIUI, ECDSA has
not been shown to be *stronger* than RSA ??? RSA works based on modulus
operations, ECDSA on
On Sat, May 10, 2014 at 03:38:24PM -0700, Steve Langasek wrote:
As the maintainer of the pam package in Debian, I assure you: this is a bug
in dirmngr. System services should not (must not) call interfaces that
launch pam sessions as part of their init scripts. su is one of those
interfaces.
On Thu, May 08, 2014 at 11:45:24AM +0200, Thorsten Glaser wrote:
This is a bug in doxygen. Replacing the embedded jquery copy
in the Debian package shipping it with a link to the jquery
version in Debian should be the right thing to do. Maybe this
Your criticism is unconstructive. I agree that
On Sun, Sep 07, 2014 at 11:12:01PM +1200, Chris Bannister wrote:
Surely, it should be an OPT-IN choice, not an OPT-OUT one? I'm talking
upgrades here, not new installs.
I have no clue why we are continuing to discuss this. The ctte
resolution says that the default init system for Linux
On Sun, Sep 14, 2014 at 07:47:27AM +0100, Sébastien Villemot wrote:
The bottom line is that julia needs SSE2 (and porting it to the x87 FPU
requires changes that are beyond what I am willing/able to do, see [1]
for more details). And the presence of SSE2 is not guaranteed on the
i386
On Wed, Oct 29, 2014 at 03:59:44PM +0100, Jonas Smedegaard wrote:
IMO the proper solution is for Debian packaging of doxygen to untangle
jQuery from extensions, depend on + symlink the jQuery part, provide the
extensions as a shared package, and patch doxygen code to generate
docuementation
Hi Jonas,
On Fri, Oct 31, 2014 at 11:37:48AM +0100, Jonas Smedegaard wrote:
Please file RFP bugs for your needs (or if already filed please
reference which are the relevant ones).
I have no clue about this JavaScript stuff and little intentions to
learn it. After my inquiry, Doxygen upstream
On Tue, Nov 18, 2014 at 09:25:44AM +, Simon McVittie wrote:
There are (at least) three things that start services (i.e. init
scripts, systemd units or Upstart jobs):
* invoke-rc.d, intended to be called from maintainer scripts
* service, intended to be called by the sysadmin
* the
On Thu, Dec 11, 2014 at 08:49:55PM +, Simon McVittie wrote:
On 11/12/14 18:08, Leif Lindholm wrote:
The point is, when we add support for another architecture which
supports UEFI, there are a number of packages that you will want to
enable for that architecture.
I've occasionally
1 - 100 of 450 matches
Mail list logo
