Re: Speeding up dpkg, a proposal

[Marius Vollmer]

ext Chow Loong Jin  writes:

> I remember seeing there being some list of files to be fsynced in one of the
> older dpkgs. It's probably that which led to the ext4 slowdown [...]

Hmm, performance is the ultimate reason for doing all this, but right
now, I am mostly interested in whether my changes are correct.  I know
that they improve performance, but I am not totally convinced that they
are actually correct in the way that they change the status of packages,
etc.

I am only proposing to add this as an option to dpkg, not to make it the
default.

We might enable it in Harmattan, if I have the balls and it does in fact
speed things up enough, but nothing of that is certain right now.  We
might get the improvement we need just from reducing our number of
packages to something reasonable.

>> But then again, I would argue that the sync() is actually necessary
>> always, for correct semantics: You also want to sync everything that the
>> postinst script has done before recording that a package is fully
>> installed.
>
> Yes, you're right. I completely forgot about that. I don't think most postinst
> scripts sync when done. I suppose the best that can be done is to batch the
> stuff as best as can be done to reduce the number of sync()s needed.

On the other hand, it _is_ the job of the maintainerscripts to sync if
that s necessary for correctness, and maybe we don't want to take that
reponsibility away from them.

And in the big picture, all we need is some guarantee that renames are
comitted in order, and after the content of the file that is being
renamed.  I have the impression that all reasonable filesystems give
that guarantee now, no?


-- 
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/87r5ao8xqi@big.research.nokia.com

Re: Possible sane approach? (was: Re: enable/disable flags in /etc/default)

[Gerfried Fuchs]

 ...

 Before someone starts to nitpick it and distract from the real content:

* Gerfried Fuchs  [2011-03-03 07:58:59 CET]:
> #v+
> 
> # only on new install
> if [ "$1" = "configure" ] && [ "x$2" = "x" ]; then
> update-rc.d foo defaults >/dev/null
> update-rc.d foo disable
> fi
> 
> #v-

 Of course foo disable, not disable foo.
Rhonda
-- 
"What are the differences between Mark Zuckerberg and me? I give private
 information on corporations to you for free, and I'm a villain.
 Zuckerberg gives your private information to corporations for money and
 he's Man of the Year." -- Julian Assange


-- 
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/20110303070250.ga25...@anguilla.debian.or.at

Possible sane approach? (was: Re: enable/disable flags in /etc/default)

[Gerfried Fuchs]

Hi!

 Some things usually spin in my head for days and I come up with an idea
that looks sane at first sight. This might be such a moment, and I
wonder wether there might be something that I overlooked here:

* Gerfried Fuchs  [2011-03-02 14:47:22 CET]:
>  Actually I explicitly chose to not go down that path for
> wesnoth-server. I settled for this approach:
> 
> dh_installinit -u 'stop 20 0 1 2 3 4 5 6 .'

 While this might look good at first sight, it has several deficits,
like the rc.d links aren't set for the regular runlevels (for whatever
reason) and update-rc.d foo enable doesn't work because that looks at
the LSB headers.

 So I came up with this thought for a postinst snippet:

#v+

# only on new install
if [ "$1" = "configure" ] && [ "x$2" = "x" ]; then
update-rc.d foo defaults >/dev/null
update-rc.d disable foo
fi

#v-

 Shouldn't that be a sensible approach with what options we currently
have? If there is some fault in my thinking, please point it out.

 Thanks,
Rhonda
-- 
"What are the differences between Mark Zuckerberg and me? I give private
 information on corporations to you for free, and I'm a villain.
 Zuckerberg gives your private information to corporations for money and
 he's Man of the Year." -- Julian Assange


-- 
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/20110303065859.ga20...@anguilla.debian.or.at

Re: Speeding up dpkg, a proposal

[Chow Loong Jin]

On Thursday 03,March,2011 02:45 PM, Marius Vollmer wrote:
> ext Chow Loong Jin  writes:
> 
>> Could we somehow avoid using sync()? sync() syncs all mounted filesystems, 
>> which
>> isn't exactly very friendly when you have a few slow-syncing filesystems like
>> btrfs (or even NFS) mounted.
> 
> Hmm, right.  We could keep a list of all files that need fsyncing, and
> then fsync them all just before writing the checkpoint.

I remember seeing there being some list of files to be fsynced in one of the
older dpkgs. It's probably that which led to the ext4 slowdown -- you'd get the
same effect of one sync() per file on systems with an ext4 root. If you had a
process doing heavy I/O in the background, each of those fsync()s will take a
considerable amount of time.

> Half of that is already done (for the content of the packages), we would
> need to add it for the files in /var/lib/dpkg/, or we could just fsync
> the whole directory.
> 
> But then again, I would argue that the sync() is actually necessary
> always, for correct semantics: You also want to sync everything that the
> postinst script has done before recording that a package is fully
> installed.

Yes, you're right. I completely forgot about that. I don't think most postinst
scripts sync when done. I suppose the best that can be done is to batch the
stuff as best as can be done to reduce the number of sync()s needed.

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Re: Speeding up dpkg, a proposal

[Adrian von Bidder]

Yodel again!
On Wednesday 02 March 2011 17.02:11 Marius Vollmer wrote:
> It shows a speed up between factor six and two in our environment (ext4
> on a slowish flash drive) .  I am not sure whether messing with the
> fundamentals of dpkg is worth a factor of two in performance

To not be all negative: read the recent discussion about fsync() and other 
stuff in dpkg (I'm not sure where the discussion happened exactly; it was 
about dpkg becoming extremely slow in some use cases on modern filesystems 
like btrfs and was a short time before the release. Since then, there is an 
option for dpkg:

  unsafe-io:  Do  not  perform  safe  I/O  operations  when
  unpacking.  Currently  this  implies  not performing file
  system syncs before file renames, which is known to cause
  substantial performance degradation on some file systems,
  unfortunately the ones that require the safe I/O  on  the
  first  place  due  to  their unreliable behaviour causing
  zero-length files on abrupt system crashes.

  Note: For ext4, the main offender, consider using instead
  the mount option nodelalloc, which will fix both the per‐
  formance degradation and the data safety issues, the lat‐
  ter  by  making  the  file system not produce zero-length
  files on abrupt system  crashes  with  any  software  not
  doing syncs before atomic renames.

  Warning:  Using  this option might improve performance at
  the cost of losing data, use with care.

So you should compare against dpkg with unsafe-io. Very slightly pre-dating 
this: I often (on btrfs, and when I'm inside development chroots that don't 
matter much) end up wrapping aptitude/apt-get/dpkg with eatmydata and get 
the same benefits. But the tool really deserves its name: a hard reboot 
directly after a package installation will leave a mess behind... (I could 
so far avoid this; I recently had a zero-length initrd after a kernel 
upgrade that *might* have been related. OTOH I did a clean shutdown there so 
it shouldn't have happened...)

Yet another point, for the future: I *think* that btrfs is building an 
interface so applications can directly access btrfs transactions. Which 
would allow to do package upgrades in a btrfs transaction, and since (again, 
I *think* so, I'm not sure) can even be ended without forcing an immediate 
sync (the result is more like a barrier than a sync), this would be a fine 
way to deal with the situation.  At the cost that it's btrfs specific.

cheers
-- vbi

-- 
BOFH excuse #233:

TCP/IP UDP alarm threshold is set too low.


signature.asc
Description: This is a digitally signed message part.

Re: Speeding up dpkg, a proposal

[Adrian von Bidder]

On Wednesday 02 March 2011 17.02:11 Marius Vollmer wrote:
> - Instead, we move all packages that are to be unpacked into
>   half-installed / reinstreq before touching the first one, and put a
>   big sync() right before carefully writing /var/lib/dpkg/status.

You don't want to do this. While production systems usually are upgraded in 
downtime windows (with less load), it is sometimes necessary to install some 
package (tcpdump or whatever to diagnose problems...) while the system is 
under high load. Especially when you're trying to find out why the machine 
has a load of 20 and you can't afford to kill it...

On a machine with lots of RAM (== disk cache...) and high I/O load, you 
don't want to do a (global!) sync().  This can totally kill the machine for 
20min or more and is a big no go.

-- vbi

-- 
featured link: http://www.pool.ntp.org


signature.asc
Description: This is a digitally signed message part.

Re: enable/disable flags in /etc/default

[Tollef Fog Heen]

]] Drake Wilson 

| (Sorry for the duplicate, Bob; forgot to send to list first time.)
| 
| Quoth Bob Proulx , on 2011-03-02 17:00:19 -0700:
| > Having daemons started automatically at installation time is a very
| > nice feature of Debian IMNHO.
| 
| Is there any harder data on which behavior various proportions or
| segments of the Debian user populace expect here?

I don't have hard data, but I see a fair amount of ops people complain
about this feature in Debian.  I believe it's impossible to write a
policy-rc.d implementation that denies running the daemon on initial
installation (but not on upgrades).

The use case for this is:

- install daemon
- install configuration using puppet/chef/cfengine/etc
- start daemon or hook daemon into tool that keeps it running (monit,
  god, etc)

(FWIW, I like starting daemons on installation too, but I can see why
people want the option not to).

-- 
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/87ei6o4t6h@qurzaw.varnish-software.com

Re: Disable ZeroConf: how to ?

[Norbert Preining]

On Do, 03 Mär 2011, Adam Borowski wrote:
> On Wed, Mar 02, 2011 at 10:24:36PM +0100, Josselin Mouette wrote:
> > As Philipp pointed out, only gnome depends on it, and that’s not
> > gnome-desktop-environment. You can use the latter if you want only the
> > official GNOME desktop.
> 
> gnome-desktop-environment
>   Depends: gnome-user-share
> Depends: libapache2-mod-dnssd
>   Depends: avahi-daemon
>   Recommends: telepathy-salut
> Depends: avahi-daemon 

Any words of the GNOME maintainers according to that?

I don't need not want avahi, it actually two or three times broke 
my network by doing changes to config file I don't want (don't remember
the details) and at that time I could purge it away, but it came back
again.

Best wishes

Norbert

Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

HIGH OFFLEY (n.)
Gossnargh (q.v.) three weeks later.
--- Douglas Adams, The Meaning of Liff


-- 
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/20110303030642.gi6...@gamma.logic.tuwien.ac.at

Bug#616189: ITP: raspell -- A Ruby interface binding for the Aspell spelling checker.

[Alex Pennace]

Package: wnpp
Severity: wishlist
Owner: Alex Pennace 


* Package name: raspell
  Version : 1.2
  Upstream Author : Evan Weaver 
* URL : https://github.com/fauna/raspell
* License : GPL
  Programming Lang: Ruby
  Description : A Ruby interface binding for the Aspell spelling checker.

Raspell lets you check words and suggest corrections from Ruby
programs via aspell.



-- 
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/20110303024521.ga21...@buick.pennace.org

Re: Disable ZeroConf: how to ?

[Chow Loong Jin]

On Thursday 03,March,2011 06:56 AM, Klaus Ethgen wrote:
> Am Mi den  2. Mär 2011 um 23:09 schrieb Julien BLACHE:
>>> Because I work in a untrusted work place and home network (public
>>> networks, wifi...) I whish to purge zeroconf functionnality.
> 
>> Looks like you want a firewall. Just sayin'.
> 
> Ehem, no.
> 
> A system has not to listen for any unused and unneeded services ever. A
> firewall is to control services you _need_.
> 
> All that zeroconf stuff is absolutely not needed and wanted. (By the
> most users, I suppose.)
> 
> Regards
>Klaus


Actually I absolutely love the .local resolution functionality on a
network (it works much better than the NetBIOS crap that can never find another
machine on a network when you want it). That, and Pidgin's Bonjour support
interfaces with iChat over zeroconf, allowing you to chat with users (and
exchange files, perhaps?) across a network without needing to set up a
centralized chatting system.

I think those two functionalities are pretty useful to the end-user.

Rather than blabbering about potential security issues stemming from
avahi-daemon being installed and enabled on a system, how about actually finding
one and reporting it?

gnome-user-share does not share stuff by default as far as I can tell, and
padevchooser only uses avahi-daemon for discovering extra Pulseaudio sinks on
the network (it doesn't advertise its own sinks by default).

An avahi-enabled system that advertises no services is pretty much as secure as
the avahi-disabled system.

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Re: Call for projects for Google Summer of Code 2011

[Jonathan Nieder]

Paul Wise wrote:

> That is unlikely to be useful, upstream has explicitly said they are
> targeting Linux only.

More precisely[1]:

"Will this run on [insert non-Linux OS here]?

 Unlikely. As pointed out, systemd uses many Linux specific
 APIs […] That said, git supports branches and rebasing quite
 well, in case people really want to do a port.

 […]

 If folks want to implement something similar for other
 operating systems, the preferred mode of cooperation is
 probably that we help you identify which interfaces can be
 shared with your system, to make life easier for daemon
 writers to support both systemd and your systemd counterpart.
 Probably, the focus should be to share interfaces, not code."

So upstream does seem to be interested in cooperating with developers
for other platforms, though not in maintaining the resulting code.

For what it's worth.
Jonathan

[1] http://0pointer.de/blog/projects/systemd.html


--
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/20110303020301.GA22891@elie

Re: enable/disable flags in /etc/default

[Drake Wilson]

(Sorry for the duplicate, Bob; forgot to send to list first time.)

Quoth Bob Proulx , on 2011-03-02 17:00:19 -0700:
> Having daemons started automatically at installation time is a very
> nice feature of Debian IMNHO.

Is there any harder data on which behavior various proportions or
segments of the Debian user populace expect here?  I gather this is a
common opinion, but it's not mine.  I find the current Debian behavior
annoying (albeit within reason).  Whenever I install a new daemon I
often have to remember to pounce on [/etc/init.d/$foo_daemon stop]
immediately afterwards so that my machine isn't exposing some random
default configuration of foo_daemon for more than a few seconds before
I have a chance to change it.

> I rarely install something I don't want installed.

I mainly only install things that I want running, but I only want them
running once I've verified the configuration.  The default is often
not useful to me.

Examples where I insisted on manually configuring the daemon before
starting it again: Apache, ejabberd, Privoxy, sshd (slightly unusual
configuration), Exim (but it has Debconf questions which handle most
of it), Postfix (I don't remember how that went), dnsmasq, Postgrey,
Pound, radvd, I think LPRng.  (Some of these may have actually started
out disabled.)

Counterexamples: at, cron, Chrony, syslog, DenyHosts (sort of---I
reconfigured it but it wasn't in a critical way), HAL, udev, DBus,
MySQL, maybe smartd, portmap.  (Many of these are local system
services rather than major applications on their own.)

   ---> Drake Wilson


-- 
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/20110303015038.ga11...@drache.begriffli.ch

Re: Call for projects for Google Summer of Code 2011

[Paul Wise]

On Thu, Mar 3, 2011 at 1:37 AM, Josselin Mouette  wrote:

> What about a project to port systemd to kfreebsd ? :)

That is unlikely to be useful, upstream has explicitly said they are
targeting Linux only.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTin72PBPEff1=nEsE0VboWd64=pcma-iebspr...@mail.gmail.com

Re: enable/disable flags in /etc/default

[Bob Proulx]

Stig Sandbeck Mathisen wrote:
> Currently, our packaged services start automatically, unless explicitly
> disabled in /etc/default/, or by missing configuration. 

Having daemons started automatically at installation time is a very
nice feature of Debian IMNHO.  And by comparison it really annoys me
when I install a daemon expecting it to be running afterward and find
that I have to jump through a lot of hoops in order to get it to
start.  I rarely install something I don't want installed.

> Compare this to the policy of RHEL, which does not enable or start its
> services on package install.
> 
> A RHEL service can be started manually, but will not be started at
> system boot unless explicitly configured to do so with "chkconfig".

Red Hat is a different environment and has different issues and
therefore they have produced a different solution.  I don't think this
should translate directly to Debian because Debian is quite different
(and better) than Red Hat in this area.

On Red Hat systems it is long standing practice to install everything
possible at initial system installation time.  This leads to a unique
problem on RH that doesn't exist for Debian and therefore a different
solution for RH that may not apply to Debian.

For example this means that on RHEL both Postfix and Sendmail are both
installed at the same time out of the box.  This leads to three (at
least) cases.  1) Admin wants Postfix running.  2) Admin wants
Sendmail running.  3) Admin wants neither running.

To address this issue neither daemon is started by default and
'chkconfig' is used to enable the desired one, after having configured
the desired one using 'update-alternatives mta' first.

Example for setting up Postfix on RHEL:

  ... No need to install postfix since it is already installed. ...
  # service sendmail stop
  # chkconfig --del sendmail
  # alternatives --set mta /usr/sbin/sendmail.postfix
  # checkconfig postfix on
  # service postfix start

Example for setting up Postfix on Debian:

  # apt-get install postfix

Bob


signature.asc
Description: Digital signature

Re: Disable ZeroConf: how to ?

[Adam Borowski]

On Wed, Mar 02, 2011 at 10:24:36PM +0100, Josselin Mouette wrote:
> Le mercredi 02 mars 2011 à 18:25 +0100, Bastien ROUCARIES a écrit :
> > And more specifically from an administrator point of view does avahi
> > could library could be made purgeable and no more than suggest 
> > dependencies (I am willing to fill a mass bug report because purging
> > avahi will purge gnome and kde ...) ?
> 
> As Philipp pointed out, only gnome depends on it, and that’s not
> gnome-desktop-environment. You can use the latter if you want only the
> official GNOME desktop.

gnome-desktop-environment
  Depends: gnome-user-share
Depends: libapache2-mod-dnssd
  Depends: avahi-daemon
  Recommends: telepathy-salut
Depends: avahi-daemon 

> > And moreover could you give a clear answer about the security risk on
> > untrusted network ? 
> 
> I’d say Avahi is mostly as insecure as the services that use it for
> advertising.

A client system is not supposed to run any public network services,
especially not in the default config.  I have never in my life felt the need
to do anything provided by either gnome-user-share or telepathy-salut (or
anything that has to do with telepathy for that matter), and I doubt most
users have either.  None of them do anything good unless configured, too.

Having them installed by default might make sense, disk space is cheap and
non-technical users are not supposed to apt-get things every time they use
an optional part of Gnome -- but why the system would bear a security risk
when none of the programs involved were ever run is beyond me.

When an user actually uses that "easy file sharing" or link-local instant
messaging, avahi could be started, but there's no reason to do that before.

This goes in contrast to actual server daemons which are installed by a
conscious action by the sysadmin, and thus can be expected to be running by
default.


-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
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/20110302233326.ga9...@angband.pl

Re: Disable ZeroConf: how to ?

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Mi den  2. Mär 2011 um 18:25 schrieb Bastien ROUCARIES:
> More and more packages depend on avahi aka zeroconf. I have found some 
> information on http://wiki.debian.org/ZeroConf 
> 
> Because I work in a untrusted work place and home network (public networks, 
> wifi...) I whish to purge zeroconf functionnality.

I fighted this bunch of functionality since long ago. The whole zerconf
stuff is only useful in secure and clear defined environments. But there
you don't need it anyway.

With zeroconf there is some thinks that play together and has to be
killed:
- - avahi (-daemon) -- as you find by yourself -- and the packages
  zeroconf, libnss-mdns, avahi-autoipd, avahi-daemon.
- - The package slpd
- - The linklocal route (169.254.0.0)

> Does avahi could be disable (using kernel level firewalling is not from my 
> point of view a solution) ?

See above.

> And more specifically from an administrator point of view does avahi could 
> library could be made purgeable and no more than suggest 
> dependencies (I am willing to fill a mass bug report because purging avahi 
> will purge gnome and kde ...) ?

Well, as I do not use gnome nor kde I am not concerned from this
dependencies.

> And moreover could you give a clear answer about the security risk on 
> untrusted network ? 

That is difficult. It depends on the environment. If you have a clear
and secure environment, zeroconf is not that insecure. But in all other
environments you do not want to have it.

Regards
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.ch/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen 
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBTW7Knp+OKpjRpO3lAQqjdgf+J1Tq4eqF+bi/2bAONvCPXgwCXRswg5eA
HEAWZdsN13jTe/JGD/NTBML7AXXu+RIeJIFty+I/T+OlU2x3SbKijtXkteN0giTE
QWJf/6extnJZY97+cP2xDjfPZXP8DA7pL3qr0MLHj9Lz/s+Prvd+9MM3OKzgoDn/
pG9Lb+TVNMzWmD3KLGD1wbLMMKSnh7NLQshQPLgwkZwTysLWCeIX/hBRZ8r9Nn0G
DqW1I4sOIYB47w4DmHo5SXwnQG3O0P/MdbaVicasE0+MYLg28Ib+ZVNMzvFbP7Kw
lBQBvrqFDBsKXvK4esgSlI6xq8c/m/rUUR5S3Ar8t8AFg1OWoT+C4g==
=CXGk
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302225422.gb17...@ikki.ethgen.ch

Re: Speeding up dpkg, a proposal

[Bastian Blank]

On Wed, Mar 02, 2011 at 08:13:06PM +, Roger Leigh wrote:
> Btrfs is quite simply awful in chroots at present, and it seems
> --force-unsafe-io doesn't really seem to help massively either.
> It's dog slow--it's quicker to untar a chroot onto ext3 than to
> bother with Btrfs.

Because unsafe-io does not apply to the handling of the info directory.

Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown


-- 
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/20110302231220.ga31...@wavehammer.waldi.eu.org

Re: Disable ZeroConf: how to ?

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Mi den  2. Mär 2011 um 23:09 schrieb Julien BLACHE:
> > Because I work in a untrusted work place and home network (public
> > networks, wifi...) I whish to purge zeroconf functionnality.
> 
> Looks like you want a firewall. Just sayin'.

Ehem, no.

A system has not to listen for any unused and unneeded services ever. A
firewall is to control services you _need_.

All that zeroconf stuff is absolutely not needed and wanted. (By the
most users, I suppose.)

Regards
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.ch/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen 
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBTW7LKp+OKpjRpO3lAQpkRgf/VKrQKWxC83u3XbGK8/Q1AaHvfa4zweUj
wWyGHQjs98OLxdqfONq/7v1eHzGbFghgBzPXiEIdVBDgnCPnSU+QTNRYvUyx8O58
iSdO0GMERDnMg1nU0tunTG4NgmXfoysJttpE4zPiyy51nhUNfbe9giQmMpZ94tIb
GGTF49YUiAZde1uUk6NDXEjXlsBtoeID2WiNKnwTrQbXGBLD7fgdfeSGoEzCvkNq
9YCF/cHTQbV1x0q1RFUcbbAbd6eCin2mmhX92iIhX15KgNdaE1sZ6bCMUJAh0Rhr
Ab9jGki0AxfV4N6Y43CztskNa+EHhmKhe/mkk5NilVZ7IovJ+CXWJQ==
=Wxv3
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302225642.gc17...@ikki.ethgen.ch

Re: Disable ZeroConf: how to ?

[Ben Hutchings]

On Wed, 2011-03-02 at 23:09 +0100, Julien BLACHE wrote:
> Bastien ROUCARIES  wrote:
> 
> Hi,
> 
> > Because I work in a untrusted work place and home network (public
> > networks, wifi...) I whish to purge zeroconf functionnality.
> 
> Looks like you want a firewall. Just sayin'.

A firewall is mitigation against insecure applications and
configurations.  The availability of firewalls does not excuse us from
making applications and their default configurations secure.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: potential MBF: first alternate depends not available in main

[Vincent Danjean]

On 02/03/2011 16:13, Emilio Pozuelo Monfort wrote:
> If the user has rar-nonfree installed, that would be fine, as the dependency
> would be satisfied. If he doesn't have it, then installing a package from main
> shouldn't install packages outside main, so we should prefer packages in main
> over those outside it.

If a user choices to enable other repository (such as the non-free section
or even external repository), he can expect that these repository will be
managed equally. Moreover, as for the unrar example, the non-main package is
often better featured (but, of course, with a worst license) than the one in
main (else, the non-main package would not even exits). So, installing them
if the admin choices to use non-main repository seems the good thing to
do by the package manager in this case.

  If a user uses only main, then he will never have a package installing
a other one outside of main.

  If you want that a package from main do not install a package outside
of main, you will have to fix several other problems (packages with
a newer version in another enabled repository). But, in my opinion, this
is a bad fight against the choice of the administrator...

  If a admin wants non-free (or another repo) only for one software
(java, ...), he can use pinning to express this concern to the package
manager.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/4d6ec13c.5070...@free.fr

Re: Disable ZeroConf: how to ?

[Julien BLACHE]

Bastien ROUCARIES  wrote:

Hi,

> Because I work in a untrusted work place and home network (public
> networks, wifi...) I whish to purge zeroconf functionnality.

Looks like you want a firewall. Just sayin'.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
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/87pqq9kwd1@sonic.technologeek.org

Re: Disable ZeroConf: how to ?

[Steve Langasek]

On Wed, Mar 02, 2011 at 09:11:40PM +, Philipp Kern wrote:
> The other thing where it's not clear to me is padevchooser.  Not sure it's
> really desperatly needed there.

For padevchooser it probably makes sense, as network sound sink/sources are
certainly a case you may want to use pulseaudio with.

What I find unusual is that pulseaudio recommends padevchooser.  I wouldn't
expect this to be installed by default.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Disable ZeroConf: how to ?

[Josselin Mouette]

Le mercredi 02 mars 2011 à 18:25 +0100, Bastien ROUCARIES a écrit :
> And more specifically from an administrator point of view does avahi
> could library could be made purgeable and no more than suggest 
> dependencies (I am willing to fill a mass bug report because purging
> avahi will purge gnome and kde ...) ?

As Philipp pointed out, only gnome depends on it, and that’s not
gnome-desktop-environment. You can use the latter if you want only the
official GNOME desktop.

> And moreover could you give a clear answer about the security risk on
> untrusted network ? 

I’d say Avahi is mostly as insecure as the services that use it for
advertising.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling



signature.asc
Description: This is a digitally signed message part

Re: Disable ZeroConf: how to ?

[Philipp Kern]

Hi,

I won't comment on the possible insecurity of avahi-daemon, but...

On 2011-03-02, Bastien ROUCARIES  wrote:
> More and more packages depend on avahi aka zeroconf. I have found some
> information on http://wiki.debian.org/ZeroConf 
>
> Because I work in a untrusted work place and home network (public networks,
> wifi...) I whish to purge zeroconf functionnality.
>
> however a lot of package depends (or recommend) instead of suggest
> avahi-daemon and thus I could not purge this piece of software 
> that I believe insecure in my context.

| pkern@franck:~$ dak rm -n -R -b -s stable avahi-daemon
| Working... done.
| Will remove the following packages from stable:
|
| avahi-daemon |   0.6.27-2 | amd64, armel, i386, ia64, kfreebsd-amd64, 
kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
|
| Maintainer: Utopia Maintenance Team 

|
| --- Reason ---
|
| --
|
| Checking reverse dependencies...
| # Broken Depends:
| avahi: avahi-discover
|avahi-dnsconfd
|avahi-utils
| controlaula: ltsp-controlaula
| forked-daapd: forked-daapd
| gshare: gshare
| mandos: mandos
| meta-gnome2: gnome
| mod-dnssd: libapache2-mod-dnssd
| mt-daapd: mt-daapd
| nss-mdns: lib32nss-mdns [amd64]
|   libnss-mdns
| padevchooser: padevchooser
| service-discovery-applet: service-discovery-applet
| telepathy-salut: telepathy-salut
|
| Dependency problem found.

So it's mainly gnome, which you don't need to install if you don't agree with
the maintainer's decision to depend on avahi-daemon, but you could mark the
pulled-in packages as installed yourself.  (That's the maintainer's stance on
its dependency list.)

The other thing where it's not clear to me is padevchooser.  Not sure it's
really desperatly needed there.

But the "a lot of packages depend" on it is false.  It might be true that a
bunch of it recommend it, but then you could create a dummy package that just
conflicts against avahi-daemon.  That should keep it uninstalled even when you
install more packages with recommends turned on.  (I think equivs could help
you there.)  After all those are no depends.

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/slrnimtckc.o7n.tr...@kelgar.0x539.de

Re: Speeding up dpkg, a proposal

[Mike Hommey]

On Wed, Mar 02, 2011 at 08:13:06PM +, Roger Leigh wrote:
> On Thu, Mar 03, 2011 at 01:51:35AM +0800, Chow Loong Jin wrote:
> > Hi,
> > 
> > On Thursday 03,March,2011 12:02 AM, Marius Vollmer wrote:
> > > [...]
> > > - Instead, we move all packages that are to be unpacked into
> > >   half-installed / reinstreq before touching the first one, and put a
> > >   big sync() right before carefully writing /var/lib/dpkg/status.
> > 
> > Could we somehow avoid using sync()? sync() syncs all mounted filesystems,
> > which isn't exactly very friendly when you have a few slow-syncing
> > filesystems like btrfs (or even NFS) mounted. I recall my schroots that ran
> > on tmpfs unpacking exceptionally slowly due to this issue until I stuck
> > libeatmydata (or a variant of it) onto the schroots' dpkgs.
> 
> Btrfs is quite simply awful in chroots at present, and it seems
> --force-unsafe-io doesn't really seem to help massively either.
> It's dog slow--it's quicker to untar a chroot onto ext3 than to
> bother with Btrfs.
> 
> This is a shame, because Btrfs snapshots are the most fast and
> reliable out there at the moment (LVM snapshots are fast, but not
> /that/ fast, and LVM appears to have locking issues which need
> addressing to make it robust enough to handle simultaneous
> creation and removal of many snapshots.
> 
> It would be great if there was a solution to this problem; is anyone
> running Btrfs as a root filesystem who has any suggestions?

eatmydata works great for my chroots on btrfs.

Mike


-- 
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/20110302202917.ga21...@glandium.org

Re: Speeding up dpkg, a proposal

[Roger Leigh]

On Thu, Mar 03, 2011 at 01:51:35AM +0800, Chow Loong Jin wrote:
> Hi,
> 
> On Thursday 03,March,2011 12:02 AM, Marius Vollmer wrote:
> > [...]
> > - Instead, we move all packages that are to be unpacked into
> >   half-installed / reinstreq before touching the first one, and put a
> >   big sync() right before carefully writing /var/lib/dpkg/status.
> 
> Could we somehow avoid using sync()? sync() syncs all mounted filesystems,
> which isn't exactly very friendly when you have a few slow-syncing
> filesystems like btrfs (or even NFS) mounted. I recall my schroots that ran
> on tmpfs unpacking exceptionally slowly due to this issue until I stuck
> libeatmydata (or a variant of it) onto the schroots' dpkgs.

Btrfs is quite simply awful in chroots at present, and it seems
--force-unsafe-io doesn't really seem to help massively either.
It's dog slow--it's quicker to untar a chroot onto ext3 than to
bother with Btrfs.

This is a shame, because Btrfs snapshots are the most fast and
reliable out there at the moment (LVM snapshots are fast, but not
/that/ fast, and LVM appears to have locking issues which need
addressing to make it robust enough to handle simultaneous
creation and removal of many snapshots.

It would be great if there was a solution to this problem; is anyone
running Btrfs as a root filesystem who has any suggestions?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: enable/disable flags in /etc/default

[Sven Joachim]

On 2011-03-02 20:54 +0100, Steve Langasek wrote:

> On Wed, Mar 02, 2011 at 03:42:28PM +0200, Faidon Liambotis wrote:
>
>> Also, while we're at update-rc.d's documentation, that particular
>> manpage says:
>> >Example of disabling a service:
>> >   update-rc.d -f foobar remove
>> >   update-rc.d foobar stop 20 2 3 4 5 .
>> Have you tried that recently? It doesn't work in squeeze systems.
>
> Sounds like a bug; has anyone filed it?

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606505

>> On the other hand, update-rc.d has enable/disable since squeeze, but
>> this is considered an unstable interface, AFAIK.
>
> Hmm.  I don't think update-rc.d is the right place for this anyway (we
> should fix things to have proper layering so that 'update-rc.d' is
> exclusively an internal package interface, and 'service' is exclusively an
> admin interface), but where do you see that update-rc.d enable/disable is an
> unstable interface?  It's not documented as such in the manpage.

See Kel's reply in the above bug report.

Cheers,
   Sven


-- 
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/87pqq9nvfa@turtle.gmx.de

Re: enable/disable flags in /etc/default

[Steve Langasek]

On Wed, Mar 02, 2011 at 03:42:28PM +0200, Faidon Liambotis wrote:
> > That means:
> > # mv /etc/rc2.d/S??apache2 /etc/rc2.d/K00apache2
> > # insserv # this bit is not documented, it seems

> Are you serious? How's that a sysadmin interface? Yes, everything can be
> done using sh/cp/mv/vi, but this is hardly something that's either
> properly documented or a replacement for the current method of doing things.

*What* "current method"?

At present there *is* no reliable sysadmin interface for enabling/disabling
services.  update-rc.d is not it; many admins have been using 'update-rc.d
-f remove' for years, but this is /wrong/ and it is /documented/ that this
will cause the links to be readded on package upgrade.  policy-rc.d is not
it; the spec for this is bloated and I've never heard of an admin who's ever
bothered implementing anything more than a "don't start any services in a
chroot" policy using this.  And /etc/default/* isn't it; no consistent
variable naming, not implemented for all services (and shouldn't be), so
it's not scriptable, so it requires vi.

So the mv command above *is* the current method.  And we're in desperate
need of a better one.

> Also, while we're at update-rc.d's documentation, that particular
> manpage says:
> >Example of disabling a service:
> >   update-rc.d -f foobar remove
> >   update-rc.d foobar stop 20 2 3 4 5 .
> Have you tried that recently? It doesn't work in squeeze systems.

Sounds like a bug; has anyone filed it?  (Or is it just that insserv doesn't
know about the change and needs to be rerun?)

> On the other hand, update-rc.d has enable/disable since squeeze, but
> this is considered an unstable interface, AFAIK.

Hmm.  I don't think update-rc.d is the right place for this anyway (we
should fix things to have proper layering so that 'update-rc.d' is
exclusively an internal package interface, and 'service' is exclusively an
admin interface), but where do you see that update-rc.d enable/disable is an
unstable interface?  It's not documented as such in the manpage.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Speeding up dpkg, a proposal

[Thilo Six]

Chow Loong Jin wrote the following on 02.03.2011 18:51

> Hi,
> 
> On Thursday 03,March,2011 12:02 AM, Marius Vollmer wrote:
>> [...]
>> - Instead, we move all packages that are to be unpacked into
>>   half-installed / reinstreq before touching the first one, and put a
>>   big sync() right before carefully writing /var/lib/dpkg/status.
> 
> Could we somehow avoid using sync()? sync() syncs all mounted filesystems, 
> which
> isn't exactly very friendly when you have a few slow-syncing filesystems like
> btrfs (or even NFS) mounted. I recall my schroots that ran on tmpfs unpacking
> exceptionally slowly due to this issue until I stuck libeatmydata (or a 
> variant
> of it) onto the schroots' dpkgs.
> 
> I actually recall there being some things mentioned about FS_IOC_SYNCFS (lkml
> thread[1], dpkg-devel thread[2]) for faster per-filesystem syncing, but that
> seems to have died of natural causes last year.
> 
>> [...]
> 
> 
> [1] http://thread.gmane.org/gmane.linux.file-systems/44628
> [2] http://lists.debian.org/debian-dpkg/2010/11/msg00069.html

Just for reference afaik there has been a discussion about this topic last year.
If you are interested why dpkg does all those syncs read:
http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/770841

-- 
bye Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6  7C18 89A4 A2A0 C70B 1A8F



-- 
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/ikm75b$s3t$1...@dough.gmane.org

Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library

[Tollef Fog Heen]

]] Henrique de Moraes Holschuh 

| Actually, we usually use it to *remove* bogus rpath, but hey, it would
| be a poor tool if it couldn't be used to add a proper rpath :)

It doesn't know how to add an rpath, just change or remove one.  Patches
gladly accepted. :-)

-- 
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/87tyflnx2t@qurzaw.varnish-software.com

Re: enable/disable flags in /etc/default

[Joey Hess]

Simon McVittie wrote:
> The other good option I've seen for packages where the init script isn't
> necessarily the preferred way to run the server is to split the package,
> so the server binary and supporting files are in one binary package (e.g.
> dnsmasq-base, git-daemon, mysql-server-core-5.1) and the init glue is in
> another (dnsmasq, git-daemon-run, mysql-server-5.1).

This is a good option, but git-daemon-run is a poor exemplar. See #422139

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#616130: ITP: python-mwavepy -- microwave engineering classes and functions for python

[Євгеній Мещеряков]

Package: wnpp
Severity: wishlist
Owner: "Євгеній Мещеряков" 

* Package name: python-mwavepy
  Version : 1.0
  Upstream Author : Alex Arsenovic, Lihan Chen
* URL : http://code.google.com/p/mwavepy
* License : GPL-2+
  Programming Lang: Python
  Description : functions and classes for microwave/RF engineering

mwavepy is a compilation of functions and class's for microwave/RF engineering 
written
in python. It is useful for things such as touchstone file manipulation, 
calibration, data
analysis, data acquisition, and plotting. mwavepy can be used interactively 
through the
python interpreter, or in scripts.



--
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/20110302183722.8362.74901.report...@openfonts.org

Re: Speeding up dpkg, a proposal

[Chow Loong Jin]

Hi,

On Thursday 03,March,2011 12:02 AM, Marius Vollmer wrote:
> [...]
> - Instead, we move all packages that are to be unpacked into
>   half-installed / reinstreq before touching the first one, and put a
>   big sync() right before carefully writing /var/lib/dpkg/status.

Could we somehow avoid using sync()? sync() syncs all mounted filesystems, which
isn't exactly very friendly when you have a few slow-syncing filesystems like
btrfs (or even NFS) mounted. I recall my schroots that ran on tmpfs unpacking
exceptionally slowly due to this issue until I stuck libeatmydata (or a variant
of it) onto the schroots' dpkgs.

I actually recall there being some things mentioned about FS_IOC_SYNCFS (lkml
thread[1], dpkg-devel thread[2]) for faster per-filesystem syncing, but that
seems to have died of natural causes last year.

> [...]


[1] http://thread.gmane.org/gmane.linux.file-systems/44628
[2] http://lists.debian.org/debian-dpkg/2010/11/msg00069.html

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Disable ZeroConf: how to ?

[Bastien ROUCARIES]

hi,

More and more packages depend on avahi aka zeroconf. I have found some 
information on http://wiki.debian.org/ZeroConf 

Because I work in a untrusted work place and home network (public networks, 
wifi...) I whish to purge zeroconf functionnality.

however a lot of package depends (or recommend) instead of suggest avahi-daemon 
and thus I could not purge this piece of software 
that I believe insecure in my context.

Does avahi could be disable (using kernel level firewalling is not from my 
point of view a solution) ?

And more specifically from an administrator point of view does avahi could 
library could be made purgeable and no more than suggest 
dependencies (I am willing to fill a mass bug report because purging avahi will 
purge gnome and kde ...) ?

And moreover could you give a clear answer about the security risk on untrusted 
network ? 

Thanks

Bastien


-- 
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/201103021825.32204.roucaries.bast...@gmail.com

Bug#616123: ITP: collabtive -- Simple web-based project management software

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf 

* Package name: collabtive
  Version : 0.6.5
  Upstream Author : Philipp Kiszka  et. al.
* URL : http://collabtive.o-dyn.de/about.php
* License : GPLv3+
  Programming Lang: PHP
  Description : Simple web-based project management software

A simple project management software intended for small to
medium-sized businesses and freelancers. Is structured around
projects, milestones, tasklists, and tasks, and implements
timetracking, notification and messaging between its users.

Collabtive does not aim to represent a full company's hierarchy, it is
structured in a flat way, basing its work just in project membership.



-- 
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/20110302173706.21136.40650.report...@mosca.iiec.unam.mx

Re: Call for projects for Google Summer of Code 2011

[Josselin Mouette]

Le mercredi 02 mars 2011 à 14:19 +0100, Cyril Brulebois a écrit : 
> Bernd Zeimetz  (02/03/2011):
> > What about a project which prepares a migration to
> > http://www.freedesktop.org/wiki/Software/systemd ?
> 
> yay for portability.

What about a project to port systemd to kfreebsd ? :)

-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
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/1299087475.18219.500.camel@meh

Speeding up dpkg, a proposal

[Marius Vollmer]

Hi,

I have recently been looking into where dpkg spends most of its time
when installing very many small packages, and came up with the following
idea to speed it up.

- Most of the time is spent writing files very carefully, a lot of them
  in /var/lib/dpkg/updates.

- We can avoid this by writing the files less carefully (without fsync)
  and even skipping the journal entries in /var/lib/dpkg/updates
  completely.

- Instead, we move all packages that are to be unpacked into
  half-installed / reinstreq before touching the first one, and put a
  big sync() right before carefully writing /var/lib/dpkg/status.

[ There are more details to this than this, please check the code before
  trying to find the holes in this short version of the idea.
]

This should be just as safe as writing very many small journal entries,
but if dpkg does get interrupted harshly, it leaves its database behind
in a correct but quite outdated and not so friendly state.  Many
packages that have not been touched will have to be reinstalled because
dpkg can't be sure that they have in fact not been touched.

This should only happen when the system goes down abruptly without any
chance for dpkg to write a checkpoint and without unmounting the
filesystem cleanly.  In any other case, such as a maintainer script
failing or the user interrupting dpkg with C-c, dpkg will write a
accurate checkpoint as the last thing it does.


I have experimental code for this here, based on dpkg 1.15.8.8:


http://meego.gitorious.org/~mvo/meego-platform-security/reckless-dpkg/commits/mvo/reckless

It shows a speed up between factor six and two in our environment (ext4
on a slowish flash drive) .  I am not sure whether messing with the
fundamentals of dpkg is worth a factor of two in performance, but I
still think the idea is sound and worth sharing here, if only to be shot
down.

So, opinions?


-- 
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/8762s1a4u4@big.research.nokia.com

Re: potential MBF: first alternate depends not available in main

[Adam Borowski]

On Wed, Mar 02, 2011 at 09:58:02AM -0500, Mike O'Connor wrote:
> On Wed, 2 Mar 2011 09:41:00 -0500, Scott Kitterman  
> wrote:
> > On Wednesday, March 02, 2011 04:53:46 am Emilio Pozuelo Monfort wrote:
> 
> > > If you have non-free enabled and install a package from main, it should
> > > install the dependencies from main. So you should have e.g. "rar |
> > > rar-nonfree" instead of the other way round.
> > 
> > Why?  If the user has made the choice to use non-free and the maintainer 
> > concludes that's a more technically capable solution for users that choose 
> > to 
> > use it, why should the project raise barriers to that choice?
> 
> To me, this particualar case is one where we should definitely not be
> choosing a non-free version by default, as using the non-free version
> actually puts a financial burden on the user.  Just becaause the user
> decided that he wants to enable non-free so he can install sun-java6,
> doesn't mean we should assume he is willing to buy a license for rar.

Uhm?  What choice are you talking about?

There are three packages:

rar (the compressor)
unrar
unrar-free

The compressor comes with a 40 days "test" license and request payment after
that period.  Of course, in practice no one pays -- home users just ignore
it, those for whom legality matters usually choice other compressors.
On Debian, there is hardly every any reason to use rar, so any dependencies
on it should probably be avoided.

The two decompressors:
"unrar-free" is useless for anything but unpacking some historical archives. 
You'd have to dig deep to find any it can actually handle.  Depending or
recommending it is thus pointless.

"unrar" is what you need to unpack anything you can get today.  Sadly,
thanks to people ignoring the compressor's cost this format remains pretty
popular and many tools depend/recommend/suggest unrar for a good reason.


Too bad, I'm afraid that any recommendation for unrar-free is a bug since it
does nothing good for the user and causes confusion.  For example for .cbr,
no files are compressed using rar2 as that format is newer than rar3.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
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/20110302161229.ga3...@angband.pl

Re: potential MBF: first alternate depends not available in main

[Emilio Pozuelo Monfort]

On 02/03/11 14:41, Scott Kitterman wrote:
> On Wednesday, March 02, 2011 04:53:46 am Emilio Pozuelo Monfort wrote:
>> On 02/03/11 04:24, Scott Kitterman wrote:
>>> It seems to me not worth a mass bug filing.  This doesn't seem like
>>> something that would affect user's systems.  Is there a rationale for
>>> imposing this ordering other than puiparts can't deal with it?
>>
>> If you have non-free enabled and install a package from main, it should
>> install the dependencies from main. So you should have e.g. "rar |
>> rar-nonfree" instead of the other way round.
> 
> Why?  If the user has made the choice to use non-free and the maintainer 
> concludes that's a more technically capable solution for users that choose to 
> use it, why should the project raise barriers to that choice?

If the user has rar-nonfree installed, that would be fine, as the dependency
would be satisfied. If he doesn't have it, then installing a package from main
shouldn't install packages outside main, so we should prefer packages in main
over those outside it.

Emilio


-- 
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/4d6e5e8b.2080...@debian.org

Re: potential MBF: first alternate depends not available in main

[Mike O'Connor]

On Wed, 2 Mar 2011 09:41:00 -0500, Scott Kitterman  wrote:
> On Wednesday, March 02, 2011 04:53:46 am Emilio Pozuelo Monfort wrote:

> > If you have non-free enabled and install a package from main, it should
> > install the dependencies from main. So you should have e.g. "rar |
> > rar-nonfree" instead of the other way round.
> 
> Why?  If the user has made the choice to use non-free and the maintainer 
> concludes that's a more technically capable solution for users that choose to 
> use it, why should the project raise barriers to that choice?
> 

To me, this particualar case is one where we should definitely not be
choosing a non-free version by default, as using the non-free version
actually puts a financial burden on the user.  Just becaause the user
decided that he wants to enable non-free so he can install sun-java6,
doesn't mean we should assume he is willing to buy a license for rar.


pgpvrg0NpSmH2.pgp
Description: PGP signature

Re: potential MBF: first alternate depends not available in main

[brian m. carlson]

On Wed, Mar 02, 2011 at 09:41:00AM -0500, Scott Kitterman wrote:
> Why?  If the user has made the choice to use non-free and the maintainer 
> concludes that's a more technically capable solution for users that choose to 
> use it, why should the project raise barriers to that choice?

Because packages not in Debian will be pulled in by packages in main
automatically.  And also because, for better or for worse, handling
non-initial alternate dependencies is still very much of a crapshoot in
Debian.  Thus the first alternative will be the most likely to be
installed in a variety of situations, and that should be something in
main if possible.  It avoids breakage in the situation where non-free
and contrib are *not* in use, and it prioritizes the closure of main
over the use of non-free software.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: potential MBF: first alternate depends not available in main

[Scott Kitterman]

On Wednesday, March 02, 2011 04:53:46 am Emilio Pozuelo Monfort wrote:
> On 02/03/11 04:24, Scott Kitterman wrote:
> > It seems to me not worth a mass bug filing.  This doesn't seem like
> > something that would affect user's systems.  Is there a rationale for
> > imposing this ordering other than puiparts can't deal with it?
> 
> If you have non-free enabled and install a package from main, it should
> install the dependencies from main. So you should have e.g. "rar |
> rar-nonfree" instead of the other way round.

Why?  If the user has made the choice to use non-free and the maintainer 
concludes that's a more technically capable solution for users that choose to 
use it, why should the project raise barriers to that choice?

Scott K


-- 
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/201103020941.02177.deb...@kitterman.com

Re: enable/disable flags in /etc/default

[Faidon Liambotis]

On 03/02/11 05:24, Raphael Geissert wrote:
> Interesting that everyone talks about update-rc.d but it appears that nobody 
> has read its documentation:
> 
>> A common system administration error is to delete the links with
>> the thought that this will "disable" the service, i.e., that this will
>> prevent the service from being started.  However, if all links have
>> been deleted then the next time the package is upgraded, the package's  
>> postinst script will run update-rc.d again and this will reinstall links
>> at their factory default locations.  The correctc way to disable
>> services is to configure the service as stopped in all runlevels in
>> which it is started by default.  In the System V init system this means 
>> renaming the service's symbolic links from S to K.
> 
> That means:
> # mv /etc/rc2.d/S??apache2 /etc/rc2.d/K00apache2
> # insserv # this bit is not documented, it seems

Are you serious? How's that a sysadmin interface? Yes, everything can be
done using sh/cp/mv/vi, but this is hardly something that's either
properly documented or a replacement for the current method of doing things.

Also, while we're at update-rc.d's documentation, that particular
manpage says:
>Example of disabling a service:
>   update-rc.d -f foobar remove
>   update-rc.d foobar stop 20 2 3 4 5 .
Have you tried that recently? It doesn't work in squeeze systems.

On the other hand, update-rc.d has enable/disable since squeeze, but
this is considered an unstable interface, AFAIK.

Regards,
Faidon


-- 
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/4d6e4944.90...@debian.org

Help identify packages that multiarch support will break

[Raphael Hertzog]

[ Bcc to -dpkg for info ]

Hello,

since multiarch support in dpkg is on good track, it's about time to
identify what will break when people start using multiarch packages...

I have started filing a few bugs for some packages where I knew of
the problems but I need your help to identify other possible offenders.
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=multiarch;users=debian-d...@lists.debian.org

Here's what might create troubles:

1/ Anywhere where the user might specify a package name, he should be able
   to specifiy "package:arch" to cope with Multi-Arch: same packages that
   can be co-installed (e.g. libc6:i386 and libc6:amd64 on the same
   system). Those package names can also appear in outputs of dpkg-query
   commands (dpkg -l, dpkg -S, dpkg-query -W).

2/ Any program that parses /var/lib/dpkg/status with the assumption that
   there's only one entry with "Package: foo" is wrong. Uniqueness is now
   only guaranteed on the tuple (Package, Architecture).
   
   In general parsing the status file should not be done, instead you
   should use dpkg-query.

3/ Any program that assumes the current layout of control files
   (/var/lib/dpkg/info/.) will be broken (at least for
   some packages) since the layout will change to support Multi-Arch: same
   packages that can be co-installed.

   You should use "dpkg-query --control-path  " to
   retrieve the path of the file. This has been introduced in dpkg 1.15.4
   and is thus in squeeze already.


Do you know packages that will be affected by the above problems? Please
file a bug and usertag it with this command:
$ bts user debian-d...@lists.debian.org . usertag $bug + multiarch

Thanks in advance.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110302140611.gh20...@rivendell.home.ouaza.com

Re: enable/disable flags in /etc/default

[Serafeim Zanikolas]

On Wed, Mar 02, 2011 at 12:37:25PM +, Simon McVittie wrote [edited]:
> (Cross-posting to d-d-games for discussion of the Quake III-based games)
> 
> On Tue, 01 Mar 2011 at 15:20:52 -0800, Russ Allbery wrote:
> > Speaking as someone who has a few of the DONT_NOT_DISABLE_SERVICE
> > variables in some of my packages
> 
> Speaking as another implementor of similar variables: I added them in
> openarena-server, quake3-server and tremulous-server (game dedicated servers),
> with the servers disabled by default, for these reasons:
[..]

Another reason for having a service disabled by default is security, eg.
beanstalkd as of now is meant for use in trusted networks (no authentication).

-- 
Every great idea is worthless without someone to do the work. --Neil Williams


-- 
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/20110302135135.GC4273@mobee

Re: enable/disable flags in /etc/default

[Gerfried Fuchs]

Hi!

 As someone who is also annoyed by the default file startup hack (which
is IMHO an abuse because why have a S rc link then?), let me also throw
in my 0.02 EUR.

> Stig Sandbeck Mathisen  writes:
> > The "short term" issue is figuring out if the current practice of
> > DONT_DISABLE_ENABLEMENT=false and friends in /etc/default is something
> > we want to keep doing.

 Actually I explicitly chose to not go down that path for
wesnoth-server. I settled for this approach:

dh_installinit -u 'stop 20 0 1 2 3 4 5 6 .'

 This sets the symlinks for the service to be disabled by default and
leaves it to the administrator to switch to S symlinks. Actually now
that I look at it I think I might have triggered a bug in update-rc.d
here, why does that only create K links in rc{0,1,6}.d but *not* in
rc{2,3,4,5}.d?

 Also, the update-rc.d foo enable hack seems to not work in this case,
it seems to depend heavily on the LSB information (and thus ignoring an
administrator's choise for settling for different runlevels).

 And being able to support the local admin is why I have to chose to set
the rc links to kill links by default: If they want to tweak their
runlevels they have to tweak the symlinks. If they have to touch an
*additional* default file they would get annoyed (actually, _I_ get
annoyed by that, having to tune the rc symlinks *and* the default file
to do it properly).

* Russ Allbery  [2011-03-02 00:20:52 CET]:
> > The "long term" issue is having a toolset, for the end user, for
> > starting and stopping services, enabling and disabling services when
> > booting, installing and upgrading, and setting a global policy for what
> > the initial status of an installed service should be.
> 
> Speaking as someone who has a few of the DONT_NOT_DISABLE_SERVICE
> variables in some of my packages, I think you have the order reversed
> here.  I agree that those settings are horrible, but as horrible as they
> are, they're less weird than our current user interface for disabling init
> scripts.

 From a point of view that all runlevels are the same I would agree with
you. But actually there are different runlevels for a reason, and
personally I really would like to see Debian actually move forward on
that grounds, offering more useful runlevels which actually are
different by default like suggested in the LSB instead of having them
all do the same.

>  (Users have at least a hope of finding it, which is not really
> true in my experience of the init method at present.)  I'm therefore not
> inclined to remove them until we provide a non-horrible user interface
> that can really replace them.

 file-rc actually has a saner user interface in that respect from what I
understood.

> > What I'd like to be able to do, is to set a policy after system install,
> > and have all packages _obey_ this policy. :)
> 
> Yup, I think that's the right order.  :)

 Well, I personally don't like to treat _all_ packages the same, and I
don't think that this is just me?

 So long!
Rhonda
-- 
"What are the differences between Mark Zuckerberg and me? I give private
 information on corporations to you for free, and I'm a villain.
 Zuckerberg gives your private information to corporations for money and
 he's Man of the Year." -- Julian Assange


-- 
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/20110302134722.ga20...@anguilla.debian.or.at

Re: Call for projects for Google Summer of Code 2011

[Cyril Brulebois]

Bernd Zeimetz  (02/03/2011):
> What about a project which prepares a migration to
> http://www.freedesktop.org/wiki/Software/systemd ?

yay for portability.

KiBi.


signature.asc
Description: Digital signature

Re: Call for projects for Google Summer of Code 2011

[Bernd Zeimetz]

On 03/02/2011 01:57 PM, Adrian von Bidder wrote:
> On Wednesday 02 March 2011 10.43:44 Ana Guerrero wrote:
> 
>> Debian is applying as mentoring organization to the Google Summer of Code
>> (GSoC) this year
> 
> Dealing with the init scripts / service enable / disable mess. See current 
> d-devel discussion.

What about a project which prepares a migration to
http://www.freedesktop.org/wiki/Software/systemd ?



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
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/4d6e4314.2010...@bzed.de

Re: Call for projects for Google Summer of Code 2011

[Adrian von Bidder]

On Wednesday 02 March 2011 10.43:44 Ana Guerrero wrote:

> Debian is applying as mentoring organization to the Google Summer of Code
> (GSoC) this year

Dealing with the init scripts / service enable / disable mess. See current 
d-devel discussion.

As much a discussion / social skills project as a coding project, so I'm not 
sure if GSoC is the right place.

Or do it as a pure coding project, implement a proper set of tools, but then 
it's a question if it will be adopted into Debian in the end, which would 
mean wasted effort.

(And please don't start discussion of the actual problem here, there's the 
other thread for this...)

cheers
-- vbi

-- 
Jetzt ist der Herr Bush Präsident, und weil ihm wieder langweilig ist,
will er endlich den Saddam loswerden. Der Herr Bush hat nämlich keine
Praktikantin.
-- http://bush.d0t.de/


signature.asc
Description: This is a digitally signed message part.

Re: enable/disable flags in /etc/default

[Simon McVittie]

(Cross-posting to d-d-games for discussion of the Quake III-based games)

On Tue, 01 Mar 2011 at 15:20:52 -0800, Russ Allbery wrote:
> Speaking as someone who has a few of the DONT_NOT_DISABLE_SERVICE
> variables in some of my packages

Speaking as another implementor of similar variables: I added them in
openarena-server, quake3-server and tremulous-server (game dedicated servers),
with the servers disabled by default, for these reasons:

* openarena currently Depends: openarena-server for common game logic that
  both need; in principle I could add a 5MB openarena-common and make
  openarena-server only contain scripts, or add an openarena-server-run
  only containing the init script, but I didn't really fancy another trip
  through the NEW queue...

* running a Quake III (-based) server from an init script is somewhat less
  capable than running it in screen from a cron @reboot job or something (which
  is documented as an alternative in README.Debian), since you lose the
  ability for an admin to enter console commands in the running server

* I believe it's reasonably common to run several server instances on the
  same machine (e.g. for different game types or map cycles), which isn't at
  all straightforward from an init script

The other good option I've seen for packages where the init script isn't
necessarily the preferred way to run the server is to split the package,
so the server binary and supporting files are in one binary package (e.g.
dnsmasq-base, git-daemon, mysql-server-core-5.1) and the init glue is in
another (dnsmasq, git-daemon-run, mysql-server-5.1).

In that arrangment, alternative setups (dnsmasq run internally by libvirt-bin,
a git-daemon for occasional use run from inetd, mysql run internally by KDE)
can depend on the package containing the actual server, and not the one with
the init scripts. This does lead to proliferation of tiny packages and a
larger Packages file, though...

S


-- 
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/20110302123725.gb2...@reptile.pseudorandom.co.uk

Re: potential MBF: first alternate depends not available in main

[Shachar Shemesh]

On 02/03/11 12:45, Paul Wise wrote:

On Wed, Mar 2, 2011 at 5:53 PM, Emilio Pozuelo Monfort  wrote:

   

If you have non-free enabled and install a package from main, it should install
the dependencies from main. So you should have e.g. "rar | rar-nonfree" instead
of the other way round.
 

non-free stuff shouldn't be in main depends at all IMO, even as an alternative.

   


Then please state what you think should happen in the case pointed out 
by Emilio.


Shachar


--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com


--
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/4d6e2409.20...@debian.org

Re: potential MBF: first alternate depends not available in main

[Jan Hauke Rahm]

On Wed, Mar 02, 2011 at 11:51:01AM +0100, Holger Levsen wrote:
> Hi,
> 
> On Mittwoch, 2. März 2011, Paul Wise wrote:
> > non-free stuff shouldn't be in main depends at all IMO, even as an
> > alternative.
> 
> I (somewhat) agree.
> 
> And I think non-existing stuff is worse than non-free...
> 
> But, I can see how it can be useful (users, derivatives), thus I think it 
> just 
> shouldn't be the first alternative.

+1

-- 
 .''`.   Jan Hauke Rahmwww.jhr-online.de
: :'  :  Debian Developer www.debian.org
`. `'`   Member of the Linux Foundationwww.linux.com
  `- Fellow of the Free Software Foundation Europe  www.fsfe.org


-- 
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/20110302105353.ga7...@ca.home.jhr-online.de

Re: potential MBF: first alternate depends not available in main

[Holger Levsen]

Hi,

On Mittwoch, 2. März 2011, Paul Wise wrote:
> non-free stuff shouldn't be in main depends at all IMO, even as an
> alternative.

I (somewhat) agree.

And I think non-existing stuff is worse than non-free...

But, I can see how it can be useful (users, derivatives), thus I think it just 
shouldn't be the first alternative.


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Re: potential MBF: first alternate depends not available in main

[Paul Wise]

On Wed, Mar 2, 2011 at 5:53 PM, Emilio Pozuelo Monfort  wrote:

> If you have non-free enabled and install a package from main, it should 
> install
> the dependencies from main. So you should have e.g. "rar | rar-nonfree" 
> instead
> of the other way round.

non-free stuff shouldn't be in main depends at all IMO, even as an alternative.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktime83fp_akmnfb-0rgshdt731fpl8hlk_syk...@mail.gmail.com

Bug#616071: ITP: python-oejskit -- python driven javascript unit testing

[Anders Hammarquist]

Package: wnpp
Severity: wishlist
Owner: Anders Hammarquist 

* Package name: python-oejskit
  Version : 0.9.0
  Upstream Author : Open End AB, Samuele Pedroni 
* URL : http://pypi.python.org/pypi/oejskit
* License : MIT
  Programming Lang: python
  Description : python driven javascript unit testing

jskit contains infrastructure and in particular a py.test plugin to enable
running tests for JavaScript code inside browsers directly using py.test as
the test driver. Running inside the browsers comes with some speed cost, on
the other hand it means for example the code is tested against the real-
world DOM implementations.

The approach also enables to write integration tests such that the
JavaScript code is tested against server-side Python code mocked as
necessary. Any server-sideframework that can already be exposed through
WSGI (or for which a subset of WSGI can be written to accommodate the jskit
own needs) can play along.



-- 
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/20110302095719.27916.19736.report...@fido.openend.se

Re: potential MBF: first alternate depends not available in main

[Emilio Pozuelo Monfort]

On 02/03/11 04:24, Scott Kitterman wrote:
> It seems to me not worth a mass bug filing.  This doesn't seem like something 
> that would affect user's systems.  Is there a rationale for imposing this 
> ordering other than puiparts can't deal with it?

If you have non-free enabled and install a package from main, it should install
the dependencies from main. So you should have e.g. "rar | rar-nonfree" instead
of the other way round.

Cheers,
Emilio


-- 
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/4d6e13aa.7070...@debian.org

Re: enable/disable flags in /etc/default

[sean finney]

hi zack,

On Wed, Mar 02, 2011 at 09:41:18AM +0100, Stefano Zacchiroli wrote:
> without telling which those "several tools" are. According to this
> thread, the recommended tool among them is "mv" (in the hope that the
> sysadm knows by heart that they have to run insserv afterwards).

there's a few packages that provide the same or similar kind of
functionality, like sysv-rc-conf, bum, and rcconf.  but none of
these are anything remotely "standard" in terms of what people
would be used to seeing, they'd have to find the package names
and install them and learn how to use them, etc (and it may be
that even with said utilities that they still have to run
insserv, d'oh)...


sean


-- 
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/20110302093138.gc27...@cobija.connexer.com

Re: enable/disable flags in /etc/default

[sean finney]

On Tue, Mar 01, 2011 at 08:30:24PM +0100, Olaf van der Spek wrote:
> > time the package is upgraded.  i mean, it's not even that great for
> > maintainer scripts, as evidenced by the total inconsistency for how
> > developers are managing enabling/disabling of their services.
> 
> Isn't that handled by DH for simple cases?

i don't think the simple cases are the problems here.  the problems arise
on the maintainer side when they want to do anything different from the
standard boilerplate dh stuff, like for example conditionally enable/disable
a service.  i actually attempted to do this The Right Way once with nsca,
and it was really hard and involved lots of querying of invoke-rc.d.

On Tue, Mar 01, 2011 at 11:58:44PM +0100, Stig Sandbeck Mathisen wrote:
> The "short term" issue is figuring out if the current practice of
> DONT_DISABLE_ENABLEMENT=false and friends in /etc/default is something
> we want to keep doing.

i would guess that the numbers are already overwhelmingly in favor of
abandoning this practice, if it were reasonably easy and straightforward
to do.

> The "long term" issue is having a toolset, for the end user, for
> starting and stopping services, enabling and disabling services when
> booting, installing and upgrading, and setting a global policy for what
> the initial status of an installed service should be.

i'd agree with Russ that doing this sooner rather than later would
actually accelerate the abandonment of the practice.. that is i don't
think most people are doing it because they think "this is how it should
be done", but rather "i can't find a better way to do it".

> A RHEL service can be started manually, but will not be started at
> system boot unless explicitly configured to do so with "chkconfig".

and in our case it's renaming a symlink with sysv init, but i find
it extremely irritating that we can't just provide a damn wrapper
for that on out of the box installs so debian works like every other
linux system out there with a reasonably sane chkconfig and/or service
interface.

On Tue, Mar 01, 2011 at 09:24:52PM -0600, Raphael Geissert wrote:
> Olaf van der Spek wrote:
> > So what *is* the proper UI?
> 
> Interesting that everyone talks about update-rc.d but it appears that nobody 
> has read its documentation:
> 
> > A common system administration error is to delete the links with

> 
> That means:
> # mv /etc/rc2.d/S??apache2 /etc/rc2.d/K00apache2
> # insserv # this bit is not documented, it seems
> 
> And that's it, apache2 won't be started on runlevel 2.

and that's pretty much how it works on every other linux/unix like
(sysv anyway, modulo changing some paths) system out there, at least
under the hood.

...but that's not an interface, that's an implementation detail.  a very much
nonzero number of people are very confused when coming to debian because
the tools that they've come to learn and use on other linux systems aren't
present, and when they google or ask on support channels they're given a mixture
of sometimes conflicting answers.

i spoke with steve briefly on irc this morning and he mentioned that there
were some (perhaps-unpublished?) notes from the DebConf BoF on init systems,
does anyone still have a copy of those?  is there any other central place
where this stuff is being discussed?


sean
-- 


-- 
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/20110302092127.gb27...@cobija.connexer.com

Re: Potential memory leaks reported by Valgrind against some frequently used commands

[Wouter Verhelst]

On Tue, Mar 01, 2011 at 08:38:42PM -0600, Ron Johnson wrote:
> On 03/01/2011 06:19 AM, ximalaya wrote:
> >Hi all,
> [snip]
> >
> >BTW, I ever tried on Redhat Linux 9, no such problem.
> >
> 
> This is the interesting part.  Is RH keeping their patches, or are
> upstream and other distros just not determining them worthwhile?

Not really. The interesting part is 'was this done with the same version
of valgrind?'

Note that valgrind has a feature to blacklist false positives and issues
(like this one) that don't matter at all.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
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/20110302091754.gk3...@celtic.nixsys.be