Bug#636443: ITP: python-ttystatus -- terminal progress bar and status output for Python
Package: wnpp Severity: wishlist Owner: Lars Wirzenius * Package name: python-ttystatus Version : 0.12 Upstream Author : Lars Wirzenius * URL : http://liw.fi/ttystatus/ * License : GPL Programming Lang: Python Description : terminal progress bar and status output for Python The ttystatus Python library provides a simple widget-based way to show progress and current status in command line programs. (Needed for Obnam.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110803065949.10794.5735.report...@havelock.liw.fi
Bug#636444: ITP: obnam -- online and disk-based backup application
Package: wnpp Severity: wishlist Owner: Lars Wirzenius * Package name: obnam Version : 0.18 Upstream Author : Lars Wirzenius * URL : http://braawi.org/obnam/ * License : GPL Programming Lang: C, Python Description : online and disk-based backup application Obnam makes backups. Backups can be stored on local hard disks, or online via the SSH SFTP protocol. The backup server, if used, does not require any special software, on top of SSH. . * Snapshot backups. Every generation looks like a complete snapshot, so you don't need to care about full versus incremental backups, or rotate real or virtual tapes. * Data de-duplication, across files, and backup generations. If the backup repository already contains a particular chunk of data, it will be re-used, even if it was in another file in an older backup generation. This way, you don't need to worry about moving around large files, or modifying them. * Encrypted backups, using GnuPG. * Push or pull operation, depending on what you need. You can run Obnam on the client, and push backups to the server, or on the server, and pull from the client over SFTP. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110803070651.11092.57033.report...@havelock.liw.fi
Bug#636445: ITP: genbackupdata -- generate test data sets for backup software
Package: wnpp Severity: wishlist Owner: Lars Wirzenius * Package name: genbackupdata Version : 1.5 Upstream Author : Lars Wirzenius * URL : http://braawi.org/genbackupdata/ * License : GPL Programming Lang: Python Description : generate test data sets for backup software genbackupdata creates or modifies directory trees in ways that simulate real filesystems sufficiently well for performance testing of backup software. For example, it can create files that are a mix of small text files and big binary files, with the binary files containing random binary junk which compresses badly. This can then be backed up, and later the directory tree can be changed by creating new files, modifying files, or deleting or renaming files. The backup can then be run again. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110803071412.12126.75599.report...@havelock.liw.fi
Re: A few observations about systemd
On 2011-08-02, Marco d'Itri wrote: > On Aug 02, Dmitry Nezhevenko wrote: >> Another example is dovecot-imapd. It's possible to use it in >> preauthenticated mode. In such case no system-wide daemon is required and >> mail client should just start imapd and talk with it using stdin/stdout. > Again something which is very uncommon. I tend to differ, but meh. I guess in an ideal world, we should ship with the firewall being pre-enabled and the inbound ports requiring activation by the sysadmin. (Apart from SSH and conntrack'ed ports.) Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnj3i2gh.2cf.tr...@kelgar.0x539.de
Re: [Pkg-xfce-devel] Bug#636108: lightdm: does not source ~/.profile
[Bcc'd all *dm maintainers and debian-x, in case they want to comment, apologize if you get this multiple times] Dear Debian Developers, Background: most common ways[1] of logging in to a Debian system involve executing or sourcing ~/.profile at some point, but not all of them. [1] tested gdm, slim, console login, from memory I recall kdm and gdm3 doing the same On Lu, 01 aug 11, 10:14:35, Yves-Alexis Perez wrote: > On lun., 2011-08-01 at 11:08 +0300, Andrei POPESCU wrote: > > I won't comment on your statement that the dm is not the right place, > > but I strongly believe ~/.profile should be sourced from somewhere by > > *default*, just as it is done on a console login. > > It's read by bash (and zsh and few other shells I guess). > > > > Do you mind if I move the discussion on -devel? > > No, go ahead. > -- > Yves-Alexis IMVHO I think it shouldn't matter how a user logs in, the environment should be as much as possible identical, but I'm not sure this belongs in the *dm. What do you think? Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Minimal init [was: A few observations about systemd]
On Tue, 2 Aug 2011 15:45:51 -0700 Steve Langasek wrote: [...] > There's also the matter that if your daemon is being run in the > foreground, other services depend on it, and you're not using socket > activation, there's ambiguity as to when the service is actually > "started". A racy startup is a bad thing. Doesn't exactly the same problem exist with "classic" daemons? I mean, as soon as a daemon being started forked once, the parent instance has no idea whether the forked instance actually managed to complete initialization, and if it did then when. Unless some sort of communication channel is used. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110803130431.19f47c10.kos...@domain007.com
Re: Minimal init
]] Konstantin Khomoutov | Doesn't exactly the same problem exist with "classic" daemons? | I mean, as soon as a daemon being started forked once, the parent | instance has no idea whether the forked instance actually managed to | complete initialization, and if it did then when. Unless some sort of | communication channel is used. A well-behaved double-forking daemon doesn't do the second fork until it's ready to serve requests. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vrakg0r@qurzaw.varnish-software.com
Re: Making daemons compatible with systemd
Tollef Fog Heen writes ("Re: Making daemons compatible with systemd"):
> I'm looking forward to your patches for the proprietary HP and Dell
> daemons that are used for monitoring the health of various hardware
> components.
Those daemons can continue to be started and managed the way they are
already, with all the unreliability that daemon(3)+pidfiles implies.
If the vendors of those programs care about this they can provide a
new interface, and if the customers care they can try to make the
vendors care.
> (Sure, they might not be packaged for Debian, but adopting an init
> system that doesn't deal with double-forking would be much, much worse
> than adopting one which is Linux-specific for our Linux ports.)
I'm not suggesting that we should do anything that makes the existing
situation worse. We should not adopt an init system that, with
double-forking daemons and init scripts, fails to work as well as that
approach currently does with sysvinit.
But I don't think it is a good idea to adopt a complicated workaround
(which is essentially what the cgroups approach is), to get proper
daemon supervision, when we can simply fix the root cause.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20025.22114.712473.868...@chiark.greenend.org.uk
Re: Minimal init [was: A few observations about systemd]
Steve Langasek writes ("Re: Minimal init [was: A few observations about
systemd]"):
> FWIW, I've gotten feedback from Samba upstream that the upstart job for smbd
> in Ubuntu, which runs the daemon foregrounded, is concerning to them because
> foreground mode hasn't been tested upstream in about a decade. No bug
> reports yet about actual breakage, but if not for the fact that smbd manages
> to bewilder upstart's daemon tracking code when allowed to daemonize (fix
> coming soon), I would switch the job to invoke smbd in the usual fashion.
If the code is in upstream already then clearly we don't have a
problem getting it into upstream. All that's needed is for it to be
fixed, and upstream will take those fixes.
> There's also the matter that if your daemon is being run in the foreground,
> other services depend on it, and you're not using socket activation, there's
> ambiguity as to when the service is actually "started". A racy startup is a
> bad thing.
I agree. But using a daemon's call to fork() as a proxy for startup
notification is IMO absurd.
Also I have no objection to socket activation (which is after all
what inetd does...).
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20025.22253.531540.625...@chiark.greenend.org.uk
Re: autopkgtest / DEP8
Stefano Zacchiroli writes ("Re: autopkgtest / DEP8"):
> Indeed, it has been approved a few hours ago:
> . But I didn't manage to
> find your account on alioth, so I guess you'll have to wait a couple of
> weeks (of vacation) before being added as an admin. (Or ask the alioth
> admin to do that, on the basis of this mail.)
Right. I think it can live in my git for a few weeks. My alioth
account name is "iwj".
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20025.22362.323529.519...@chiark.greenend.org.uk
Re: A few observations about systemd
On Mon, Aug 01, 2011 at 03:17:51PM +0600, Andrey Rahmatullin wrote: > On Sun, Jul 31, 2011 at 08:27:04PM +, Clint Adams wrote: > > On Sun, Jul 31, 2011 at 05:38:43PM +0600, Andrey Rahmatullin wrote: > > > I would be glad if all services (at least network-enabled or especially > > > insecure for other reasons) didn't start by default. > > Maybe everyone would be happy if there were a central place to set > > the administrator's preferred policy. > Making the "do not start by default" policy default for the distro should > improve out-of-box security. Our policy has always been 'do not install by default', which obviously implies 'do not start by default'. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110803152325.gg13...@grep.be
Re: Making daemons compatible with systemd
Ian Jackson chiark.greenend.org.uk> writes: > But I don't think it is a good idea to adopt a complicated workaround > (which is essentially what the cgroups approach is), to get proper > daemon supervision, when we can simply fix the root cause. This is a bit like saying that there's no need for the kernel to free allocated resources when a process exits, when we can simply fix all programs to free resources before exiting. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20110803t172938-...@post.gmane.org
Bug#636504: RFP: pcbsd-netmanager -- PC-BSD Network Manager
Package: wnpp Severity: wishlist * Package name: pcbsd-netmanager * URL : see below * License : 3-clause BSD (with some MIT/X11 parts) Programming Lang: C++ (Qt) Description : PC-BSD Network Manager Graphical (Qt) Network Configuration utility of the PC-BSD project. May be used to setup Ethernet, Wireless and 3G/PPP. Extended description and Screenshots: http://wiki.pcbsd.org/index.php/Network_Configuration Browse source code: http://trac.pcbsd.org/browser/pcbsd/current/src-qt4?order=name (note: LICENSE file is in this top-level directory; subdirs pc-netmanager and libpcbsd are also required). Subversion URL: svn://svn.pcbsd.org/pcbsd/current/src-qt4 Note: This package is only useful on Debian GNU/kFreeBSD flavor. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110803154047.1011.43739.reportbug@dimoni
Re: autopkgtest / DEP8
]] Ian Jackson | Right. I think it can live in my git for a few weeks. My alioth | account name is "iwj". I've added you to the alioth project now. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxfqifxu@qurzaw.varnish-software.com
apt MD5Sum mismatch is due to multiple DNS queries!
Gentlemen, junior programmer me has finally found the reason behind apt's MD5Sum mismatchs: multiple DNS queries! http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636292 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ei12tcgk@jidanni.org
Re: apt MD5Sum mismatch is due to multiple DNS queries!
On Thu, Aug 04, 2011 at 05:24:59AM +0800, jida...@jidanni.org wrote: > Gentlemen, junior programmer me has finally found the reason > behind apt's MD5Sum mismatchs: multiple DNS queries! > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636292 Could you please refrain from spamming this list with such reports? You have done the right thing by filing a bug; that's enough to bring it to the attention of the apt maintainers. Thanks. -- Jonathan Wiltshire (who also notes that there are not only gentlemen working in Debian) j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110803213347.gl11...@lupin.home.powdarrmonkey.net
Re: A few observations about systemd
Hi, Le 03/08/11 17:23, Wouter Verhelst a écrit : > On Mon, Aug 01, 2011 at 03:17:51PM +0600, Andrey Rahmatullin wrote: >> On Sun, Jul 31, 2011 at 08:27:04PM +, Clint Adams wrote: >>> On Sun, Jul 31, 2011 at 05:38:43PM +0600, Andrey Rahmatullin wrote: I would be glad if all services (at least network-enabled or especially insecure for other reasons) didn't start by default. >>> Maybe everyone would be happy if there were a central place to set >>> the administrator's preferred policy. >> Making the "do not start by default" policy default for the distro should >> improve out-of-box security. > > Our policy has always been 'do not install by default', which obviously > implies 'do not start by default'. > I don't agree. When I install Debian on a laptop or workstation, I only want what I need, and most of the time I don't want a SSH or FTP server. But the day I need it, I install it and I want to use it right away to connect to my personal account. I don't want to spend minutes or worse understanding how to start it reliably and safely. Regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: A few observations about systemd
* Thibaut Paumard [2011-08-04 07:43]: > I don't agree. When I install Debian on a laptop or workstation, I only > want what I need, and most of the time I don't want a SSH or FTP server. > But the day I need it, I install it and I want to use it right away to > connect to my personal account. I don't want to spend minutes or worse > understanding how to start it reliably and safely. Isn't that a case where you want to have the daemon running like now but don't bother if it is started upon boot time? Especially in such a case it seems the best option to not start the daemon at all, don't bother with setting up boot-time startup configuration but have the local admin start it by hand. your Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110804064336.ga5...@anguilla.debian.or.at
