Re: Speeding up dpkg, a proposal

[Marius Vollmer]

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.

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.


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

Re: Speeding up dpkg, a proposal

[Raphael Hertzog]

Hi Marius,

no need to CC Guillem privately, the dpkg maintainers are reachable at
debian-d...@lists.debian.org. :)

On Wed, 02 Mar 2011, 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.

The big sync() doesn't work. It means dpkg never finishes its work on
systems with lots of unrelated I/O.

We have used that in the past and we had to revert, see
commit 5ee4e4e0458088cde1625ddb5a3d736f31a335d3 and the associated bug
reports:
http://bugs.debian.org/588339
http://bugs.debian.org/595927
http://bugs.debian.org/600075

Later we completely removed the codepath USE_SYNC_SYNC due to this. Even
if you're not using the sync() in the same way that we did, its mere usage
makes the whole solution a no-go.

Other people have already mentioned --force-unsafe-io as a way to recover
some of the performance lost. It does still sync the updates to the
internal database (but not the files installed by the packages).

We've seen reports of poor performance with btrfs (and that's what you use
for Meego IIRC) so you might want to investigate why btrfs is coping so
badly with a few fsync() just on the status files.

That's my 2cents on this discussion.

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/20110303080011.gg6...@rivendell.home.ouaza.com

Re: Disable ZeroConf: how to ?

[Gerfried Fuchs]

Hi!

* Bastien ROUCARIES  [2011-03-02 18:25:30 CET]:
> Does avahi could be disable (using kernel level firewalling is not
> from my point of view a solution) ?

 A nice hack that I was informed just recently about:

echo exit 0 >> /etc/default/avahi-daemon

 That will disable the daemon quite effectively.
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/20110303081651.ga18...@anguilla.debian.or.at

Lintian check for missing desktop files?

[Andreas Tille]

Hi,

as I explained on Debian Med list[1] the existence of a desktop file is
nearly as relevant as a manpage for a good user experience for users who
are not that addicted to the command line as most of us are.  I have not
made any stats how many packages with applications which deserve a
desktop file to show up in UIs implementing the freedesktop.org
specification but I think I'm not wrong if I roughly estimate it with
"below 50%".  In cases like this a lintian check has leaded to
interesting results (see "missing manpage").  While I'm not a lintian
expert I'd consider the following criterion as reasonable for a check

  * package has a file in /usr/bin
  * package name does not match '^lib' or '-doc$'
  * package has dependencies from "typical" libraries for
freedesktop.org implementing interfaces which are for instance
- libgnome2-0
- libkdeui5
- libxfce4ui-1-0
- libgtk-3-0
- libqtgui4
- ...
Please excuse if my choice of the libraries is not optimal - I'm
not an expert in this field but I hope you get the idea.
  * No file /usr/share/applications/*.desktop in the package

If all these criterions are fullfilled a lintian warning about a missing
desktop file could (should (!) IMHO) be issued.

What do you think?

Kind regards

 Andreas.

[1] http://lists.debian.org/debian-med/2011/03/msg00025.html

-- 
http://fam-tille.de


-- 
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/20110303082753.gb9...@an3as.eu

Re: enable/disable flags in /etc/default

[Bastian Blywis]

> 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)

Is there any reason against using a debconf script that asks if the daemon 
should be started at boot time (or on which runlevels)? That way you can 
easily modify the configuration with dpkg-reconfigure and benefit from the 
debconf frontends.

Bastian

Re: Speeding up dpkg, a proposal

[Marius Vollmer]

ext Raphael Hertzog  writes:

> On Wed, 02 Mar 2011, 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.
>
> The big sync() doesn't work. It means dpkg never finishes its work on
> systems with lots of unrelated I/O.

Ok, understood.  It's now clear to me that the big sync should be
replaced with deferred fsyncs.  (I would defer the fsync of the content
of all packages until modstatdb_checkpoint, not just until
tar_deferred_extract.)

With that change, do you think the approach is sound?

> We've seen reports of poor performance with btrfs (and that's what you use
> for Meego IIRC) so you might want to investigate why btrfs is coping so
> badly with a few fsync() just on the status files.

This is about Harmattan, which uses ext4.

To understand our troubles, you need to know that we have around 2500
packages with just a single file in it.  For those packages, dpkg spends
the largest part of its time in writing the nine journal entries to
/var/lib/dpkg/updates.

We will reduce the number of our packages, so this issue might solve
itself that way, but I had good success in reducing the per-package
overhead of dpkg, and if it is correct and works for us, why not use the
'reckless' option as well?


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

Re: Call for projects for Google Summer of Code 2011

[Bernd Zeimetz]

On 03/03/2011 03:03 AM, Jonathan Nieder wrote:
>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."

Then it might be worth to have a project to identify these interfaces
and write some code to support systemd-aware daemons on (k)freebsd. For
systemd it definitely makes sense to use all the fancy linux APIs - but
it should still be possible to write a proper replacement for freebsd.

-- 
 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/4d6f5c7b.8060...@bzed.de

Re: enable/disable flags in /etc/default

[Tollef Fog Heen]

]] Bastian Blywis 

Hi,

| > 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)
| 
| Is there any reason against using a debconf script that asks if the
| daemon should be started at boot time (or on which runlevels)? That
| way you can easily modify the configuration with dpkg-reconfigure and
| benefit from the debconf frontends.

If you use a configuration management framework you probably don't care
that much about debconf, since the debconfiscation of packages is fairly
spotty and doesn't really lend itself to more complex setup.

Imagine having a full nagios or munin configuration done through debconf
and then imagine the preseed needed for that.  Compare that with just
dumping a configuration file somewhere.  Also, consider that a
configuration file might be generated based on what hosts exist in your
infrastructure, which would mean that all debconf use would gain you is
you'd have to generate the preseed file and reconfigure packages on
changes.  At that point, you haven't really won anything.

Hooking update-rc.d into debconf is probably not the worst idea in the
world, except update-rc.d is supposed to be run non-interactively and I
think it's the wrong place in the stack to configure that functionaliy.

Regards,
-- 
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/871v2olf3s@qurzaw.varnish-software.com

Bug#616294: ITP: nagixsc -- flexible transport agent for Nagios/Icinga check results

[Sebastian Harl]

Package: wnpp
Severity: wishlist
Owner: Sebastian Harl 

* Package name: nagixsc
  Version : Git snapshot
  Upstream Author : Sven Velt 
* URL : http://oss.teamix.org/projects/nagixsc
* License : GPLv2+
  Programming Lang: Python
  Description : flexible transport agent for Nagios/Icinga check results

 Nag(ix)SC is a replacement for NRPE (Nagios Remote Plugin Executor) and NSCA
 (Nagios Service Check Acceptor) supporting multiple transport mechanisms like
 HTTP(S), SSH, rsync, or whatever you like. It may be used to execute Nagios/
 Icinga plugins on a remote host or to send service check results to a central 
 monitoring server.
 .
 Nag(ix)SC includes simple HTTP server implementations to send and receive 
 check results and execute plugins. HTTP is the preferred way to transfer the
 generated data because of the following benefits:
  * simple protocol with many existing support tools (e.g. curl) and
  * libraries
for basically any programming and scripting language
  * support for relaying/forwarding through (reverse-)proxies
  * support for authorization and authentication
  * support for encryption (HTTPS)
  * filtering possibilities
 .
 Nagios/Icinga are monitoring and management systems for hosts, services and 
 networks.

This software will be packaged in the pkg-nagios team.

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Wed, Mar 2, 2011 at 11:51 PM, Ben Hutchings  wrote:
> 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.

I perfectly agree...

Bastien

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


--
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/AANLkTi=cr_5gigbqxkoynpwkvumdfaciyp7_s5yse...@mail.gmail.com

Re: Speeding up dpkg, a proposal

[Olaf van der Spek]

On Thu, Mar 3, 2011 at 8:33 AM, Marius Vollmer  wrote:
> 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?

No, they took shortcuts in the implementation and commit the rename
before the source file.

> Hmm, right.  We could keep a list of all files that need fsyncing, and
> then fsync them all just before writing the checkpoint.

Instead of fsync you might want to use the async Linux specific sync options.
-- 
Olaf


--
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/AANLkTinW=kxn2trssg+b327prv5m66-zpdxc0s10l...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Wed, Mar 2, 2011 at 11:54 PM, Klaus Ethgen  wrote:
> -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)

Ok so this package should be marked as suggest only ? Will fill bug,
if needed as a whislist level.

>> 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.

Ok so a telnet equivalent from a security point of view...

Regards

Bastien

> Regards
>   Klaus


--
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/AANLkTimVgZuWM-btAmjJeT1+goPrqtUR2PY2yBG=4...@mail.gmail.com

Re: enable/disable flags in /etc/default

[Olaf van der Spek]

On Thu, Mar 3, 2011 at 7:25 AM, Tollef Fog Heen  wrote:
> - install daemon
> - install configuration using puppet/chef/cfengine/etc
> - start daemon or hook daemon into tool that keeps it running (monit,
>  god, etc)

Can't you either install the config before installing the daemon or
just do a daemon restart afterwards?

-- 
Olaf


--
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/aanlktimvps6izoe0uyggnv1ou1am6f2_wysy4gym1...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Am Do den  3. Mär 2011 um  3:35 schrieb Chow Loong Jin:
> > 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.)
[...]
> 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.

The thoughts of that makes me shiver! Trusting untreatable sources on a
network for configuring local stuff is worse ever. Either you have a
trustable network then it gets configured in a clean way and by intend.
Or you have a untrusted network you do not want to use ever or only such
fare that you can oversee it.

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

Well, they might be for a mac or windows user that is not care about
security at all. But it is horror for a debian user who care at least a
bit about security.

And even if you not care about, then that functionality should be
explicit configured and not per default.

And even worse, debian is often used on server platforms where you never
ever want to have any such magically configured services.

> 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?

Oh, they are not potential. Trusting on untrusted stuff for doing any on
your machine raises the vector for intrusion to hell.

Ah, and to give a example of the past. No one ever did think about that
mssql is vulnerable due to a comfort feature until in 2001/2002 the
mssql-slammer (or how the worm was called) took down mayor parts of the
net. Zeroconf and avahi plays in the same category.

> 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).

Uh, you mean, that anybody can listen to your music or your teamspeak
session or your voip session with your girlfriend due zeroconf found a
audio sink in the network and did reconfigure your system to use it?

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

That is not true. For two reasons:
1. It is one more daemon that is not needed and can have bugs. (And even
   more it lowers the sensibility about unusual processes on your
   system)
2. It even configure parts of your system from untrusted information
   from the network.

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)

iQEVAwUBTW9nR5+OKpjRpO3lAQrpqgf/UD6Vmg5rF/RhVY9VPgPpx3FdcFQXJ3b0
IJsdsPL+7MsUEblqTlabxuDPALXM/RcORDQaTX+2wzeaLO5Tu9+ZoeuvNiT9mNWy
NLoqFWIRtoDYiwlQK2KfCT0PGLU9EEa1ynk3naIhVp/QPods2bpHG3lIYMgPCY4D
A0Y+6knrWjwRLVRiWQuzRhH6T6ykbPkw08yr1/9vy45CiRXbXvIpk9vJhpOPD7nX
sxfY2bMIk5NCUKdJ6QVLKUe+HM5wJO0IsRSMNPFg+RLk99xEYUgP87MeUi7O14CC
9VfopJAak/MYttLLxW6K0X/Ltoflpqr58TWvmzDpIS0VSBEA3wkwoA==
=okFJ
-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/20110303100247.ga20...@ikki.ethgen.ch

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Wed, Mar 2, 2011 at 10:24 PM, 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.


Not true anymore see below:
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.

Yes I have just read the draft RFC and it document some pitfall in
insecure network:
http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-08
In an environment where the participants are mutually antagonistic
   and unwilling to cooperate, other mechanisms are appropriate, like
   manually administered DNS.

   In an environment where there is a group of cooperating participants,
   but there may be other antagonistic participants on the same physical
   link, the cooperating participants need to use IPSEC signatures
   and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS
   messages from trusted participants (which they process as usual) from
   mDNS messages from untrusted participants (which they silently
   discard).

   When DNS queries for *global* DNS names are sent to the mDNS
   multicast address (during network outages which disrupt communication
   with the greater Internet) it is *especially* important to use
   DNSSEC, because the user may have the impression that he or she is
   communicating with some authentic host, when in fact he or she is
   really communicating with some local host that is merely masquerading
   as that name. This is less critical for names ending with ".local.",
   because the user should be aware that those names have only local
   significance and no global authority is implied.

   Most computer users neglect to type the trailing dot at the end of a
   fully qualified domain name, making it a relative domain name (e.g.
   "www.example.com"). In the event of network outage, attempts to
   positively resolve the name as entered will fail, resulting in
   application of the search list, including ".local.", if present.
   A malicious host could masquerade as "www.example.com." by answering
   the resulting Multicast DNS query for "www.example.com.local."
   To avoid this, a host MUST NOT append the search suffix
   ".local.", if present, to any relative (partially qualified)
   host name containing two or more labels. Appending ".local." to
   single-label relative host names is acceptable, since the user
   should have no expectation that a single-label host name will
   resolve as-is.


--
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/aanlktinaxgo2-sd9fsnqhpnoi2e4lod+ebrtg+ro_...@mail.gmail.com

Re: Lintian check for missing desktop files?

[Neil Williams]

On Thu, 3 Mar 2011 09:27:53 +0100
Andreas Tille  wrote:

> as I explained on Debian Med list[1] the existence of a desktop file is
> nearly as relevant as a manpage for a good user experience for users who
> are not that addicted to the command line as most of us are.  I have not
> made any stats how many packages with applications which deserve a
> desktop file to show up in UIs implementing the freedesktop.org
> specification but I think I'm not wrong if I roughly estimate it with
> "below 50%".  In cases like this a lintian check has leaded to
> interesting results (see "missing manpage").  While I'm not a lintian
> expert I'd consider the following criterion as reasonable for a check
> 
>   * package has a file in /usr/bin
>   * package name does not match '^lib' or '-doc$'
>   * package has dependencies from "typical" libraries for
> freedesktop.org implementing interfaces which are for instance
> - libgnome2-0
> - libkdeui5
> - libxfce4ui-1-0
> - libgtk-3-0
> - libqtgui4
> - ...
> Please excuse if my choice of the libraries is not optimal - I'm
> not an expert in this field but I hope you get the idea.
>   * No file /usr/share/applications/*.desktop in the package
> 
> If all these criterions are fullfilled a lintian warning about a missing
> desktop file could (should (!) IMHO) be issued.

What happened to the idea that debian/menu files can be converted to
desktop files, maybe not during package build but as a tool for
maintainers?

Do we have any idea how many packages would trigger this new check?
(and how many of those do have debian/menu files?)

My particular concern is that debian/menu is not as easily translatable
as desktop files. The "title" displayed in whatever menu is used should
always be translatable IMHO.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpBE3kmFon7E.pgp
Description: PGP signature

Re: Disable ZeroConf: how to ?

[Tollef Fog Heen]

]] Klaus Ethgen 

Hi,

| The thoughts of that makes me shiver! Trusting untreatable sources on a
| network for configuring local stuff is worse ever.

Then just don't use it?  Nobody is forcing you to.

| > I think those two functionalities are pretty useful to the end-user.
| 
| Well, they might be for a mac or windows user that is not care about
| security at all. But it is horror for a debian user who care at least a
| bit about security.
| 
| And even if you not care about, then that functionality should be
| explicit configured and not per default.

That makes it much less useful.  On the other hand, it's not like your
system will suddenly go around connecting to random services just
because it sees them announced.

| And even worse, debian is often used on server platforms where you never
| ever want to have any such magically configured services.

Oh, I quite like services to announce themselves so I can just do ssh
foo.local.  Not everything gets set up in DNS and ssh caches the host
key so doing a mitm attack after the initial handshake is prevented.
It's not like it'll magically be pulled in on servers or anybody is
suggesting making it part of the base system.

| Ah, and to give a example of the past. No one ever did think about that
| mssql is vulnerable due to a comfort feature until in 2001/2002 the
| mssql-slammer (or how the worm was called) took down mayor parts of the
| net. Zeroconf and avahi plays in the same category.

Except zeroconf isn't routed so to be able to exploit it you need to be
on the same physical segment?

| > 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).
| 
| Uh, you mean, that anybody can listen to your music or your teamspeak
| session or your voip session with your girlfriend due zeroconf found a
| audio sink in the network and did reconfigure your system to use it?

That they are discovered does not mean they are used, just that they are
available.  If you have found any bugs where network sinks are used
automatically please file bugs about that.

Really, if you want to disable avahi, please feel free to do so on your
systems.  Or use a firewall, or both.  Debian has a fair balance of
functionality, security and convenience out of the box, if you disagree
with the current balance, feel free to invest the work into making it
possible to harden Debian further.

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

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Thu, Mar 3, 2011 at 11:02 AM, Klaus Ethgen  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
> Am Do den  3. Mär 2011 um  3:35 schrieb Chow Loong Jin:
>> > 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.)
> [...]
>> 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.
>
> The thoughts of that makes me shiver! Trusting untreatable sources on a
> network for configuring local stuff is worse ever. Either you have a
> trustable network then it gets configured in a clean way and by intend.
> Or you have a untrusted network you do not want to use ever or only such
> fare that you can oversee it.

I agree and moreover because Chow Loong Jin use .local instead of
.local. it could be resolved to whatever the hell to universe...

>> I think those two functionalities are pretty useful to the end-user.
>
> Well, they might be for a mac or windows user that is not care about
> security at all. But it is horror for a debian user who care at least a
> bit about security.
>
> And even if you not care about, then that functionality should be
> explicit configured and not per default.
>
> And even worse, debian is often used on server platforms where you never
> ever want to have any such magically configured services.

I agree, this sould be disable by default or at least asked to run at
config time with a no default, and only be authorized to resolve if
you use a fqdn and not a relative domain name...
And with mdns...

>> 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?
>
> Oh, they are not potential. Trusting on untrusted stuff for doing any on
> your machine raises the vector for intrusion to hell.
>
> Ah, and to give a example of the past. No one ever did think about that
> mssql is vulnerable due to a comfort feature until in 2001/2002 the
> mssql-slammer (or how the worm was called) took down mayor parts of the
> net. Zeroconf and avahi plays in the same category.
>
>> 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).
>
> Uh, you mean, that anybody can listen to your music or your teamspeak
> session or your voip session with your girlfriend due zeroconf found a
> audio sink in the network and did reconfigure your system to use it?
>
>> An avahi-enabled system that advertises no services is pretty much as secure 
>> as
>> the avahi-disabled system.
>
> That is not true. For two reasons:
> 1. It is one more daemon that is not needed and can have bugs. (And even
>   more it lowers the sensibility about unusual processes on your
>   system)
> 2. It even configure parts of your system from untrusted information
>   from the network.

I agree, and it is only the daemon part the depend on client part is
even more scarry...

We trust a lot untrusted source...


> --
> 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/20110303100247.ga20...@ikki.ethgen.ch
>
>


--
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/AANLkTi=FVSy4PW0=t1duvgbh5fhu71kzbnfmcro64...@mail.gmail.com

Re: What bug reports are for

[Andrei Popescu]

On Ma, 01 mar 11, 19:33:09, Neil Williams wrote:
> 
> If you want a service contract, find a GNU/Linux distribution capable
> of supplying one, it is not Debian. Debian exists to support users, not
> enter a service contract with users.

There's plenty paid support for Debian as well: 
http://www.debian.org/consultants

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: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Thu, Mar 3, 2011 at 11:25 AM, Tollef Fog Heen  wrote:
> ]] Klaus Ethgen
>
> Hi,
>
> | The thoughts of that makes me shiver! Trusting untreatable sources on a
> | network for configuring local stuff is worse ever.
>
> Then just don't use it?  Nobody is forcing you to.
>
> | > I think those two functionalities are pretty useful to the end-user.
> |
> | Well, they might be for a mac or windows user that is not care about
> | security at all. But it is horror for a debian user who care at least a
> | bit about security.
> |
> | And even if you not care about, then that functionality should be
> | explicit configured and not per default.
>
> That makes it much less useful.  On the other hand, it's not like your
> system will suddenly go around connecting to random services just
> because it sees them announced.
>
> | And even worse, debian is often used on server platforms where you never
> | ever want to have any such magically configured services.
>
> Oh, I quite like services to announce themselves so I can just do ssh
> foo.local.

The balance about using FQDN like you do and not foo.local that will
resolve to hell

> Not everything gets set up in DNS and ssh caches the host
> key so doing a mitm attack after the initial handshake is prevented.
> It's not like it'll magically be pulled in on servers or anybody is
> suggesting making it part of the base system.

It is pulled when I use gnome on my server...

> | Ah, and to give a example of the past. No one ever did think about that
> | mssql is vulnerable due to a comfort feature until in 2001/2002 the
> | mssql-slammer (or how the worm was called) took down mayor parts of the
> | net. Zeroconf and avahi plays in the same category.
>
> Except zeroconf isn't routed so to be able to exploit it you need to be
> on the same physical segment?
>
> | > 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).
> |
> | Uh, you mean, that anybody can listen to your music or your teamspeak
> | session or your voip session with your girlfriend due zeroconf found a
> | audio sink in the network and did reconfigure your system to use it?
>
> That they are discovered does not mean they are used, just that they are
> available.  If you have found any bugs where network sinks are used
> automatically please file bugs about that.
>
> Really, if you want to disable avahi, please feel free to do so on your
> systems.  Or use a firewall, or both.  Debian has a fair balance of
> functionality, security and convenience out of the box, if you disagree
> with the current balance, feel free to invest the work into making it
> possible to harden Debian further.

But how to disable was not documented and that is the problem...
Moreover current configuration that allow to use local link that are
not FQDN is a little bit insecure

Bastien

> Regards,
> --
> 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/87sjv4jybg@qurzaw.varnish-software.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/AANLkTinfcvL7j6s-KLNMHABRcQS4kO0=pQNE=ujoo...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Am Do den  3. Mär 2011 um 11:25 schrieb Tollef Fog Heen:
> Then just don't use it?  Nobody is forcing you to.
[...]
> | And even if you not care about, then that functionality should be
> | explicit configured and not per default.
> 
> That makes it much less useful.  On the other hand, it's not like your
> system will suddenly go around connecting to random services just
> because it sees them announced.

So you contradict yourself within two paragraphs. It makes it less
useful to enable it only on manual intervention (say, it should be
enabled automatic) but on the other hand you say that nobody is forcing
me (or others) to use it. How do that plays together?

> Oh, I quite like services to announce themselves so I can just do ssh
> foo.local.  Not everything gets set up in DNS and ssh caches the host
> key so doing a mitm attack after the initial handshake is prevented.

Not ever service has that security fence.

> Except zeroconf isn't routed so to be able to exploit it you need to be
> on the same physical segment?

Physical might be relative with wireless networks. But you are true,
that isn't routed (good thanks), but that hinders it only from taking
down the whole net.

> If you have found any bugs where network sinks are used automatically
> please file bugs about that.

Oh, there is no change of that as I never ever will use such stuff.

> Really, if you want to disable avahi, please feel free to do so on your
> systems.

That the discussion is about, yes. And the pressure some dependencies
bring in.

> Or use a firewall, or both.

It is told on other places that firewalling is not the solution.

> Debian has a fair balance of functionality, security and convenience
> out of the box,

Unfortunately some people on debian started to place convenience much
higher as security. I think that is a dangerous trend. Debian gives up
more and more security for convenience.

> if you disagree with the current balance, feel free to invest the work
> into making it possible to harden Debian further.

Oh, I did. I am not a DD and involved myself in some discussions about
that. But finally I found out that the force of (some) DDs is higher
than mine and that they misuse it. So I am only able to fix that issues
I have locally and share the hardened packages to others on a private
repository. That is not great but sometimes it is the only workable way.
And it is no easy way.

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)

iQEVAwUBTW9zVZ+OKpjRpO3lAQrwpAf+Nr0JUdpUpSeyyFKSRXGEbsxibvBbORWm
j6DYb4QhwftUx75Kj/7dVQtu9MrGYzykHjUxTPyM00jRfjSOgcCzMdFPt3NXEWtG
WeCXFrtsFW+1ulQQY+3p9QSGlR1PwduEhWKrhIDMwbatLdFHCl/JoQk2dRj2Tkza
33HHca1zrfeCslqbeemrsKSDo0m3WT94futvFNwpJGVBgDBhRuhBHqvgEC3HNrJj
HmdYE14nnAI4qPjRkPYe4lRFI6A1geET30ToHfY/xVOS6FuvTlJmWI/U1CDr/6YI
71OE65YEl1UzJu5U2LpcubkG1sHrdl3kNAJobNuABQPJRStPROA/Lg==
=nivA
-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/20110303105413.gb20...@ikki.ethgen.ch

Re: Disable ZeroConf: how to ?

[Mike Hommey]

On Thu, Mar 03, 2011 at 11:32:23AM +0100, Bastien ROUCARIES wrote:
> > Not everything gets set up in DNS and ssh caches the host
> > key so doing a mitm attack after the initial handshake is prevented.
> > It's not like it'll magically be pulled in on servers or anybody is
> > suggesting making it part of the base system.
> 
> It is pulled when I use gnome on my server...

Isn't using gnome on a server asking for trouble already ?

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/20110303110647.ga9...@glandium.org

Re: Disable ZeroConf: how to ?

[Julien BLACHE]

Tollef Fog Heen  wrote:

Hi,

> Except zeroconf isn't routed so to be able to exploit it you need to be
> on the same physical segment?

mDNS traffic can actually be relayed, but this requires setting up a
relay daemon on the gateway(s).

Quite useful when done properly.

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

Re: Disable ZeroConf: how to ?

[Lars Wirzenius]

On to, 2011-03-03 at 11:54 +0100, Klaus Ethgen wrote:
> Am Do den  3. Mär 2011 um 11:25 schrieb Tollef Fog Heen:
> > Then just don't use it?  Nobody is forcing you to.
> [...]
> > | And even if you not care about, then that functionality should be
> > | explicit configured and not per default.
> > 
> > That makes it much less useful.  On the other hand, it's not like your
> > system will suddenly go around connecting to random services just
> > because it sees them announced.
> 
> So you contradict yourself within two paragraphs. It makes it less
> useful to enable it only on manual intervention (say, it should be
> enabled automatic) but on the other hand you say that nobody is forcing
> me (or others) to use it. How do that plays together?

I don't see a contradiction between "nobody is forced to use zeroconf"
and "zeroconf is less useful if it has to be enabled manually". The fact
that zeroconf is enabled by default on the GNOME desktop does not make
it mandatory for everyone to use. (Yes, it would be nice if there were
an easy way to disable it.)

However, could we please end the FUDfest? This thread seems to be quite
unconstructive, with unspecific claims of security problems, unwarranted
slurs on users based on their operating system, and accusations on
Debian developer's attitudes. If there is an actual problem, explain
what it is, and suggest a solution. Be specific. Avoid hyperbole and
vague generalities. Do not insult. Write few mails, but put effort into
each one. If others don't agree with you, possibly you are unclear and
they are not stupid or evil: rephrase and expand and ask questions, and
don't get frustrated.



-- 
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/1299151335.2561.17.camel@tacticus

Re: Disable ZeroConf: how to ?

[Sujit Karatparambil]

> However, could we please end the FUDfest? This thread seems to be quite
> unconstructive, with unspecific claims of security problems, unwarranted
> slurs on users based on their operating system, and accusations on
> Debian developer's attitudes. If there is an actual problem, explain

I totally agree, it is certainly not wise to accuse/allege/propgate fud.
I also think it is much better to look for articles on the internet that
might help you better understand. As with opensource it is very difficult
to maintain a document for a long period of time. But certainly usefull
as pointer to usefull information into the manpages. Though I am not an
expert of ZeroConf but found a usefull article into zeroconf. I am much more
an Avahi fan than an ZeroConf fan.

http://www.practicallynetworked.com/sharing/configure_and_use_avahi_and_linux.htm


-- 
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/aanlktikc2z4-3c9qhbvdybvsjync6yd6kofk2opsm...@mail.gmail.com

Bug#616309: ITP: clfswm -- A(nother) Common Lisp FullScreen Window Manager

[Desmond O. Chang]

Package: wnpp
Severity: wishlist
Owner: "Desmond O. Chang" 


* Package name: clfswm
  Version : 20110227.git98bbb72
  Upstream Author : Philippe Brochard 
* URL : http://common-lisp.net/project/clfswm/
* License : GPL3
  Programming Lang: Common Lisp
  Description : A(nother) Common Lisp FullScreen Window Manager

CLFSWM is a 100% Common Lisp X11 window manager (based on Tinywm and
Stumpwm. Many thanks to them).  It can be driven only with the
keyboard or with the mouse.

A display contains a root frame and its children. A child can be a
window or another frame. The root frame or its children can be the
current root. The current root is fullscreen maximized (no
decorations, no buttons, no menus: nothing, just the application
fullscreen!).

CLFSWM is highly dynamic. By default there is only one frame (the root
frame). Other frames are created/deleted on the fly. A window can be
in more than one frame, so it can have multiple views of the same
windows.

Using CLFSWM is like walking through a tree of frames and
windows. Enter in a child to make it the current root and make it
fullscreen maximized. Leave it to make its parent the current root.



-- 
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/20110303115403.10747.83314.report...@giroro.home

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Thu, Mar 3, 2011 at 12:22 PM, Lars Wirzenius  wrote:
> On to, 2011-03-03 at 11:54 +0100, Klaus Ethgen wrote:
>> Am Do den  3. Mär 2011 um 11:25 schrieb Tollef Fog Heen:
>> > Then just don't use it?  Nobody is forcing you to.
>> [...]
>> > | And even if you not care about, then that functionality should be
>> > | explicit configured and not per default.
>> >
>> > That makes it much less useful.  On the other hand, it's not like your
>> > system will suddenly go around connecting to random services just
>> > because it sees them announced.
>>
>> So you contradict yourself within two paragraphs. It makes it less
>> useful to enable it only on manual intervention (say, it should be
>> enabled automatic) but on the other hand you say that nobody is forcing
>> me (or others) to use it. How do that plays together?
>
> I don't see a contradiction between "nobody is forced to use zeroconf"
> and "zeroconf is less useful if it has to be enabled manually". The fact
> that zeroconf is enabled by default on the GNOME desktop does not make
> it mandatory for everyone to use. (Yes, it would be nice if there were
> an easy way to disable it.)
>
> However, could we please end the FUDfest? This thread seems to be quite
> unconstructive, with unspecific claims of security problems, unwarranted
> slurs on users based on their operating system, and accusations on
> Debian developer's attitudes. If there is an actual problem, explain
> what it is, and suggest a solution.

main security problem is resolver,
$host -v www.local
www.local
www.local.mydomain.com

see security issue in draft paper also in case
http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-08

more important:
phpmyadmin package have created a link in /etc/avahi/services without
any question. Everybody know in my network that I have a phpadmin
service running on my server. I will ASAP create a bug report with a
security tag.

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/aanlktikezvy0etuvdfw0mpubagwga5dhjxvm-q2_v...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Thu, Mar 3, 2011 at 12:33 PM, Sujit Karatparambil
 wrote:
>> However, could we please end the FUDfest? This thread seems to be quite
>> unconstructive, with unspecific claims of security problems, unwarranted
>> slurs on users based on their operating system, and accusations on
>> Debian developer's attitudes. If there is an actual problem, explain
>
> I totally agree, it is certainly not wise to accuse/allege/propgate fud.
> I also think it is much better to look for articles on the internet that
> might help you better understand. As with opensource it is very difficult
> to maintain a document for a long period of time. But certainly usefull
> as pointer to usefull information into the manpages. Though I am not an
> expert of ZeroConf but found a usefull article into zeroconf. I am much more
> an Avahi fan than an ZeroConf fan.
>
> http://www.practicallynetworked.com/sharing/configure_and_use_avahi_and_linux.htm

some package announce their existance to the world without any admin decision!
It is not a fud  and a security hole!
>phpmyadmin package have created a link in /etc/avahi/services without
>any question. Everybody know in my network that I have a phpadmin
>service running on my server. I will ASAP create a bug report with a
> security tag.
>


-- 
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/AANLkTinkQ=q8wx45zbodt7wquwx2oqjx_y5w-x-aj...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Lars Wirzenius]

On to, 2011-03-03 at 12:47 +0100, Bastien ROUCARIES wrote:
> some package announce their existance to the world without any admin decision!
> It is not a fud  and a security hole!

That's a vague generality... which packages? You mentioned phpmyadmin.
What are the actual problems that results from this announcement? What
bad things happen from it? Can the fact that you have phpmyadmin become
known to an attacker via port scanning, or similar techniques? If so,
does it matter if phpmyadmin also announces things via avahi? What do
you suggest as a solution? Would a blanket policy of having all services
to default to not announce themselves? What would the problems from such
a policy be?

(I don't know much about this stuff, and I don't particularly care, but
it'd be nice if we could turn the discussion into a constructive one.)



-- 
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/1299154617.2561.23.camel@tacticus

Re: Disable ZeroConf: how to ?

[Olaf van der Spek]

On Thu, Mar 3, 2011 at 1:16 PM, Lars Wirzenius  wrote:
> On to, 2011-03-03 at 12:47 +0100, Bastien ROUCARIES wrote:
>> some package announce their existance to the world without any admin 
>> decision!
>> It is not a fud  and a security hole!
>
> That's a vague generality... which packages? You mentioned phpmyadmin.
> What are the actual problems that results from this announcement? What
> bad things happen from it? Can the fact that you have phpmyadmin become
> known to an attacker via port scanning, or similar techniques? If so,
> does it matter if phpmyadmin also announces things via avahi? What do
> you suggest as a solution? Would a blanket policy of having all services
> to default to not announce themselves? What would the problems from such
> a policy be?
>
> (I don't know much about this stuff, and I don't particularly care, but
> it'd be nice if we could turn the discussion into a constructive one.)

Windows has the concept of home / private and public networks. On
public networks, sharing gets disabled.
Such a concept would be good for this situation as well. Let the user
indicate what type of network he is on and what type of services
should be opened to that network.

Olaf


--
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/aanlktintbslqb6ertkoab3ulxsx+wwjjemxk-lxe9...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Thu, Mar 3, 2011 at 1:31 PM, Olaf van der Spek  wrote:
> On Thu, Mar 3, 2011 at 1:16 PM, Lars Wirzenius  wrote:
>> On to, 2011-03-03 at 12:47 +0100, Bastien ROUCARIES wrote:
>>> some package announce their existance to the world without any admin 
>>> decision!
>>> It is not a fud  and a security hole!
>>
>> That's a vague generality... which packages? You mentioned phpmyadmin.
>> What are the actual problems that results from this announcement? What
>> bad things happen from it? Can the fact that you have phpmyadmin become
>> known to an attacker via port scanning, or similar techniques? If so,
>> does it matter if phpmyadmin also announces things via avahi? What do
>> you suggest as a solution? Would a blanket policy of having all services
>> to default to not announce themselves? What would the problems from such
>> a policy be?
>>
>> (I don't know much about this stuff, and I don't particularly care, but
>> it'd be nice if we could turn the discussion into a constructive one.)
>
> Windows has the concept of home / private and public networks. On
> public networks, sharing gets disabled.
> Such a concept would be good for this situation as well. Let the user
> indicate what type of network he is on and what type of services
> should be opened to that network.

The last bug is not about this, it is I have a phpmyadmin running as
www user and I announce I run it.

Not really good to give the path to phpmyadmin (that is running by
admin decission)

Bastien

> Olaf
>
>
> --
> 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/aanlktintbslqb6ertkoab3ulxsx+wwjjemxk-lxe9...@mail.gmail.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/AANLkTimNDs4CcgJvYxqr_jMcDHAKrpF7DxY=cm3nl...@mail.gmail.com

Re: Help identify packages that multiarch support will break

[Carsten Hey]

* Raphael Hertzog [2011-03-02 15:06 +0100]:
>In general parsing the status file should not be done, instead you
>should use dpkg-query.

Is there any reason for this, except that the format of the status files
will evolve?

>You should use "dpkg-query --control-path  " to

Jftr, there is a lot potential for performance improvements in
dpkg-query, some queries can be done way faster even in gawk.


Regards
Carsten


-- 
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/20110303130456.ga29...@furrball.stateful.de

Re: Speeding up dpkg, a proposal

[Raphael Hertzog]

On Thu, 03 Mar 2011, Marius Vollmer wrote:
> ext Raphael Hertzog  writes:
> 
> > On Wed, 02 Mar 2011, 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.
> >
> > The big sync() doesn't work. It means dpkg never finishes its work on
> > systems with lots of unrelated I/O.
> 
> Ok, understood.  It's now clear to me that the big sync should be
> replaced with deferred fsyncs.  (I would defer the fsync of the content
> of all packages until modstatdb_checkpoint, not just until
> tar_deferred_extract.)

This is assuming you don't use --force-unsafe-io. Otherwise you don't sync
packages content at all.

> With that change, do you think the approach is sound?

It looks like it could work in principle. But it might have unexpected
complications in case of interruptions. You said it yourself:
"it leaves its database behind in a correct but quite outdated and not so
friendly state"

The "reinstreq" flag is usually present on a single package only, and we know
that this single package is (likely) broken. So we reinstall it and we can go 
ahead.

Now with your scheme, we have many packages in that state and we don't know 
which
ones are really broken. At least the one which was being processed at the time
of the interruption (as in power loss).

Are we sure there are no case where this brokenness leads to failures in preinst
of some of the other packages to be reinstalled? How is the package manager
supposed to order the reinstallations?

> To understand our troubles, you need to know that we have around 2500
> packages with just a single file in it.  For those packages, dpkg spends
> the largest part of its time in writing the nine journal entries to
> /var/lib/dpkg/updates.

nine? I haven't reviewed the code but that's quite a lot indeed. Maybe there's
room for optimization here.

A quick review indeed reveals this sequence (for an upgrade):
- half_installed + reinstreq
- unpacked + reinstreq
- half_installed + reinstreq
- unpacked + reinstreq
- unpacked
- unpacked (again at start of configure, don't know why)
- half_configured
- installed
- the final installation in the status file

Indeed, your scenario is very particular. Usually you have many files and thus
the fsync() of all the files is what takes the most time (compared to the 9
fsync() for the status information) and there --force-unsafe-io shows a sizable
improvement.

> We will reduce the number of our packages, so this issue might solve
> itself that way, but I had good success in reducing the per-package
> overhead of dpkg, and if it is correct and works for us, why not use the
> 'reckless' option as well?

I don't think we're interested in adding more options that make it even more
difficult to understand what dpkg does. Either there's a better way of doing it
and we use it all the time, or we keep it like it is.

For instance, I wonder if we could not get rid of two modstatdb_note in the 
above
list:
- the first "unpacked + reinstreq" could be directly brought back to
"half_installed + reinstreq" with minimal consequences (the only difference
comes when one of the conflictor/to-be-deconfigured package fails to be
deconfigured).
- the other one at the start of the configure process

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/20110303133441.gc11...@rivendell.home.ouaza.com

Re: Disable ZeroConf: how to ?

[Mike Hommey]

On Thu, Mar 03, 2011 at 01:43:19PM +0100, Bastien ROUCARIES wrote:
> On Thu, Mar 3, 2011 at 1:31 PM, Olaf van der Spek  
> wrote:
> > On Thu, Mar 3, 2011 at 1:16 PM, Lars Wirzenius  wrote:
> >> On to, 2011-03-03 at 12:47 +0100, Bastien ROUCARIES wrote:
> >>> some package announce their existance to the world without any admin 
> >>> decision!
> >>> It is not a fud  and a security hole!
> >>
> >> That's a vague generality... which packages? You mentioned phpmyadmin.
> >> What are the actual problems that results from this announcement? What
> >> bad things happen from it? Can the fact that you have phpmyadmin become
> >> known to an attacker via port scanning, or similar techniques? If so,
> >> does it matter if phpmyadmin also announces things via avahi? What do
> >> you suggest as a solution? Would a blanket policy of having all services
> >> to default to not announce themselves? What would the problems from such
> >> a policy be?
> >>
> >> (I don't know much about this stuff, and I don't particularly care, but
> >> it'd be nice if we could turn the discussion into a constructive one.)
> >
> > Windows has the concept of home / private and public networks. On
> > public networks, sharing gets disabled.
> > Such a concept would be good for this situation as well. Let the user
> > indicate what type of network he is on and what type of services
> > should be opened to that network.
> 
> The last bug is not about this, it is I have a phpmyadmin running as
> www user and I announce I run it.
> 
> Not really good to give the path to phpmyadmin (that is running by
> admin decission)

Zeroconf announce doesn't make it less secure, it makes it slightly more
discoverable, but not significantly so.

Conversely, believing that not announcing through zeroconf is more
secure is probably good for your self confidence but doesn't change
anything about actual security of your system.

Script kiddies will actually scan a network, find web servers, and
test a bunch of urls, in which the default phpmyadmin path most
probably appears.

And if your phpmyadmin is exploited, it won't be because of zeroconf,
it will be because of your weak password, of a security issue in
phpmyadmin, or something else.

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/20110303133534.gb12...@glandium.org

Re: Help identify packages that multiarch support will break

[Raphael Hertzog]

Hi,

On Thu, 03 Mar 2011, Carsten Hey wrote:
> * Raphael Hertzog [2011-03-02 15:06 +0100]:
> >In general parsing the status file should not be done, instead you
> >should use dpkg-query.
> 
> Is there any reason for this, except that the format of the status files
> will evolve?

dpkg-query will automatically respect DPKG_ADMINDIR if it's set (and it's
set in maintainer scripts). (this is a new feature in the upcoming version)

And the status file is not a public interface. It's a file used by dpkg.
If tomorrow dpkg supports an optional SQLite internal database through a
plugin, dpkg-query will continue to work but your access to the status
file will not. (This is unlikely to happen any time soon, but you get the
idea)

> >You should use "dpkg-query --control-path  " to
> 
> Jftr, there is a lot potential for performance improvements in
> dpkg-query, some queries can be done way faster even in gawk.

JFTR, there are also 300+ bugs in the BTS and we are two active developers
on dpkg.

dpkg-query is rarely used in performance sensitive situation, it's not
really my priority to improve it. But if you want to help, you're welcome.

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/20110303134551.gd11...@rivendell.home.ouaza.com

Re: Lintian check for missing desktop files?

[Andreas Tille]

On Thu, Mar 03, 2011 at 10:18:58AM +, Neil Williams wrote:
> 
> What happened to the idea that debian/menu files can be converted to
> desktop files, maybe not during package build but as a tool for
> maintainers?

The idea is as good as its implementation proceeds. :-)
IMHO a tool for maintainers would be appropriate for this problem.

Regarding the lintian check the criterion

  menu-file-but-no-desktop-file

could make sense as well.
 
> Do we have any idea how many packages would trigger this new check?
> (and how many of those do have debian/menu files?)

I have no idea about both numbers.  I just have noticed that several
packages in Debian Med maintenance are lacking a desktop file even if
they would deserve one.  Charles Plessy some years ago was quite active
in providing those files.  I assume that other fields might have similar
coverage of desktop files.
 
> My particular concern is that debian/menu is not as easily translatable
> as desktop files. The "title" displayed in whatever menu is used should
> always be translatable IMHO.

Yes.  I fully agree.  This is IMHO the strongest reason why I do not
believe in automatic conversion menu -> desktop.

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
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/20110303134635.gf9...@an3as.eu

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Thu, Mar 3, 2011 at 2:35 PM, Mike Hommey  wrote:
> On Thu, Mar 03, 2011 at 01:43:19PM +0100, Bastien ROUCARIES wrote:
>> On Thu, Mar 3, 2011 at 1:31 PM, Olaf van der Spek  
>> wrote:
>> > On Thu, Mar 3, 2011 at 1:16 PM, Lars Wirzenius  wrote:
>> >> On to, 2011-03-03 at 12:47 +0100, Bastien ROUCARIES wrote:
>> >>> some package announce their existance to the world without any admin 
>> >>> decision!
>> >>> It is not a fud  and a security hole!
>> >>
>> >> That's a vague generality... which packages? You mentioned phpmyadmin.
>> >> What are the actual problems that results from this announcement? What
>> >> bad things happen from it? Can the fact that you have phpmyadmin become
>> >> known to an attacker via port scanning, or similar techniques? If so,
>> >> does it matter if phpmyadmin also announces things via avahi? What do
>> >> you suggest as a solution? Would a blanket policy of having all services
>> >> to default to not announce themselves? What would the problems from such
>> >> a policy be?
>> >>
>> >> (I don't know much about this stuff, and I don't particularly care, but
>> >> it'd be nice if we could turn the discussion into a constructive one.)
>> >
>> > Windows has the concept of home / private and public networks. On
>> > public networks, sharing gets disabled.
>> > Such a concept would be good for this situation as well. Let the user
>> > indicate what type of network he is on and what type of services
>> > should be opened to that network.
>>
>> The last bug is not about this, it is I have a phpmyadmin running as
>> www user and I announce I run it.
>>
>> Not really good to give the path to phpmyadmin (that is running by
>> admin decission)
>
> Zeroconf announce doesn't make it less secure, it makes it slightly more
> discoverable, but not significantly so.

I disagree, on the second part, I allow faster discovery of attack
target, and made script kiddies less detectable...

> Conversely, believing that not announcing through zeroconf is more
> secure is probably good for your self confidence but doesn't change
> anything about actual security of your system.

It will ease the work of script kiddy.

> Script kiddies will actually scan a network, find web servers, and
> test a bunch of urls, in which the default phpmyadmin path most
> probably appears.
>
> And if your phpmyadmin is exploited, it won't be because of zeroconf,
> it will be because of your weak password, of a security issue in
> phpmyadmin, or something else.

For sure but I really dislike to help script kiddies, we do not return
full version of some software for this reason and do not announce
software available and location of administrative stuff slow down
exploit

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/aanlktimanzrpnegioqeccjtdo4qsxswpywk-s1897...@mail.gmail.com

Re: Disable ZeroConf: how to ?

[Josselin Mouette]

Le jeudi 03 mars 2011 à 00:33 +0100, Adam Borowski a écrit : 
> > 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

Ah right, this one was added more recently.

> 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.

Note that until you configure gnome-user-share, only avahi is started;
gnome-user-share itself is not.

> 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.

That might be possible using D-Bus activation. Feel free to get in touch
with the avahi developers if you want to implement it.

-- 
 .''`.
: :' : “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/1299161834.26821.92.camel@meh

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

[Carsten Hey]

* Holger Levsen [2011-02-28 16:05 +0100]:
> piuparts in master-slave mode currently cannot test packages which first
> alternate depends is not available in main, ie the secvpn package depends
> on "adduser, bc, ssh, ppp, timeout | coreutils (>= 7.5-1), sudo" and timeout
> is only available in lenny and etch, thus piuparts cannot test secvpn in
> squeeze, wheezy and sid. That's a bug in piuparts.
>
> Another popular example is a depends on "apache | apache2"...

Martin Pitt implemented a script[1] that tests for a similar package
relationship problem in Ubuntu main[2]:

| All build and binary dependencies (including Recommends:) must be
| satisfyable in main (i. e. the preferred alternative must be in main).


> But, anyway, I believe that the first depends of an alternate depends relation
> should be available in main and propose to file bugs about this.
>
> Do you agree this warrants a mass bug filing? I couldn't find this written out
> in policy ...

If the is a consensus, it could be added to the developer's reference or the 
policy.


Regards
Carsten

 [1] 
http://www.piware.de/2011/01/new-tool-to-check-support-status-of-dependencies/
 [2] https://wiki.ubuntu.com/UbuntuMainInclusionRequirements


-- 
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/20110303142813.gb29...@furrball.stateful.de

Re: Lintian check for missing desktop files?

[Ben Hutchings]

On Thu, 2011-03-03 at 14:46 +0100, Andreas Tille wrote:
> On Thu, Mar 03, 2011 at 10:18:58AM +, Neil Williams wrote:
> > 
> > What happened to the idea that debian/menu files can be converted to
> > desktop files, maybe not during package build but as a tool for
> > maintainers?
> 
> The idea is as good as its implementation proceeds. :-)
> IMHO a tool for maintainers would be appropriate for this problem.
> 
> Regarding the lintian check the criterion
> 
>   menu-file-but-no-desktop-file
> 
> could make sense as well.
[...]

I think it's crazy to expect maintainers to provide both menu and
desktop files for everything.  That information should be provided once
only, in whichever format is the more expressive (I think that would be
desktop files, possibly with some Debian-specific extensions).  Triggers
and per-WM hooks should take care of any conversion required at
installation time.  Let's make that a release goal for wheezy instead of
perpetuating these parallel menu systems.

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: Disable ZeroConf: how to ?

[Simon McVittie]

On Thu, 03 Mar 2011 at 15:17:14 +0100, Josselin Mouette wrote:
> > I have never in my life felt the need
> > to do anything provided by either gnome-user-share or telepathy-salut
> 
> Note that until you configure gnome-user-share, only avahi is started;
> gnome-user-share itself is not.

The same for telepathy-salut, FWIW. (If Empathy starts up without any IM
accounts, it'll offer to make you a link-local IM account using Salut, but you
can always say no.)

> > 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.
> 
> That might be possible using D-Bus activation. Feel free to get in touch
> with the avahi developers if you want to implement it.

Avahi also needs to be running to consume services advertised with zeroconf,
so if you use anything that browses for advertised services, it'd be activated
then too (for instance "Network -> Local Network" in Nautilus).

For instance, if you browse for others' shared files
("Network -> Local Network" in Nautilus) or printers, you're not making any
services available yourself, but you still need avahi-daemon running.

avahi-daemon also makes foo.local resolvable by others on your local network
segment, where foo is your hostname; I for one sometimes install avahi-daemon
just to have that side-effect, without any actual services advertised, because
the actual service I'm interested in is ssh on a well-known port.

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/20110303143831.ga28...@reptile.pseudorandom.co.uk

Re: Disable ZeroConf: how to ?

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Do den  3. Mär 2011 um 12:22 schrieb Lars Wirzenius:
> > So you contradict yourself within two paragraphs. It makes it less
> > useful to enable it only on manual intervention (say, it should be
> > enabled automatic) but on the other hand you say that nobody is forcing
> > me (or others) to use it. How do that plays together?
> 
> I don't see a contradiction between "nobody is forced to use zeroconf"
> and "zeroconf is less useful if it has to be enabled manually".

That is your point of view. I see that as contradiction in some sens.

> (Yes, it would be nice if there were an easy way to disable it.)

True; or even not even installed.

> However, could we please end the FUDfest?

I do agree with youe that we should not spread FUD. But I see just
little in this thread.

Is having a other meaning than others equivalent to FUD?

> This thread seems to be quite unconstructive,

Don't think so. I gave a concrete tip to the OP.

> with unspecific claims of security problems,

Oh, there was some absolute concrete claims in that discussion. (Not
only from my side.)

> unwarranted slurs on users based on their operating system,

I didn't see any insult in this particular thread.

> and accusations on Debian developer's attitudes.

Oh, sorry, I am once burnt. The disaster with changing openssh security
checks just for the convenience of a hand full users and where the
involved DDs are unconvincable even from the openssh people them self is
just tickling in my bones. And that was not the only claim I see and
was involved in the past.

> If there is an actual problem, explain what it is, and suggest a
> solution.

For zeroconf; make it optional as the OP suggested. For the openssh
disaster, listen to the openssh people they might have more knowledge
about security. ...

There is concrete solutions given. But if nobody want to listen to
them...

> Be specific.

For my person, I think I am.

> Avoid hyperbole and vague generalities. Do not insult.

I do not see how I did. However, if someone starts to insult, I might
react also rough. I'm sorry for that.

> Write few mails, but put effort into each one.

Not less than necessary.

> If others don't agree with you, possibly you are unclear and
> they are not stupid or evil: rephrase and expand and ask questions, and
> don't get frustrated.

Sorry, english is not my mother tongue. But I try my very best.

However, if the other party do even not listen to native english
speaker who have concrete arguments...

I might be wrong in some cases. But in the security part I do not see an
alternative to be a bit to paranoid. And if I am not the only one, that
shows me that I am not completely wrong.

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)

iQEVAwUBTW+oHZ+OKpjRpO3lAQpAjQgAmX13cByoj3eop+6jBj0+AGs5fBwT7BY3
kL/9kGLlCIrEZncK4nkJqLSITjv9lc9ZOpcCPO+BqoJRzTTe0LMaY3iGwFpM8CDw
+nsvXOyhFQbKVKqLGGGK/bjwSRlv4m8Ti4SwrtYqkA69FzamuEwXBOzzwpzbK3Ep
8kWBVyxv+8UXxKKhfXGIqvDZg/PAe3+LODxAcDysKKgVfEndi5BnpTUMT1RI4Ine
QFKYSpJwtMCR0BwMUQ3GLMZXtUp9tmrY/N3q75c0aD9LwqTUDCE8pm7NxcZhUt6Q
9Zu8ouHLBPY7KSSrv6UicYpVf6i726aD26f/q9SgI6oAwuhfhkQFqA==
=wl45
-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/20110303143925.gc20...@ikki.ethgen.ch

Re: Disable ZeroConf: how to ?

[Stig Sandbeck Mathisen]

Bastien ROUCARIES  writes:

> some package announce their existance to the world without any admin
> decision

It should be a site policy.

> It is not a fud and a security hole!

I disagree.

-- 
Stig Sandbeck Mathisen 


-- 
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/7xmxlcs288@fsck.linpro.no

Re: Lintian check for missing desktop files?

[Stefano Zacchiroli]

On Thu, Mar 03, 2011 at 02:36:43PM +, Ben Hutchings wrote:
> I think it's crazy to expect maintainers to provide both menu and
> desktop files for everything.  That information should be provided once
> only, in whichever format is the more expressive (I think that would be
> desktop files, possibly with some Debian-specific extensions).  Triggers
> and per-WM hooks should take care of any conversion required at
> installation time.  Let's make that a release goal for wheezy instead of
> perpetuating these parallel menu systems.

ACK on the de-duplication (although I don't know whether they are in
fact more expressive than current Debian menu files). Another argument
for desktop files are that we have seen initiatives (e.g. AppStream)
which are going to rely on desktop files to identify common cross-distro
components. Pushing for desktop files, in collaboration with our
upstream, would also be a way of being good citizens helping with their
diffusion.

It doesn't seem to me that your proposal of making it a release goal for
Wheezy is incompatible with Andreas' proposal. Bottom line: a lintian
check would be a first useful step (the heuristic is clearly more
debatable, but I'm no condition to propose one which is better than the
one proposed by Andreas).

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Lintian check for missing desktop files?

[Sune Vuorela]

On 2011-03-03, Ben Hutchings  wrote:
> I think it's crazy to expect maintainers to provide both menu and
> desktop files for everything.  That information should be provided once
> only, in whichever format is the more expressive (I think that would be
> desktop files, possibly with some Debian-specific extensions).  Triggers

my impression is that they express the same. there is a difference in
the categories (sections) that doesn't make it fully possible to
map completely in any direction.

for example in games, in debian menu system we have and Games/Action,
which contains actions and arcade games, and the FDO menu has ActionGame
and ArcadeGame
There can be found similar examples for 'the other way'

There is a desktop2menu script in
devscript that tries to do the conversion as good as possible, 

> and per-WM hooks should take care of any conversion required at
> installation time.  Let's make that a release goal for wheezy instead of
> perpetuating these parallel menu systems.

Down with the debian menu! Long live the fdo menu.

(isn't it only icewm and ratpoison and blackbox we might 'lose' by
simply killing the debian menu)

/Sune


-- 
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/slrnimvce9.rvp.nos...@sshway.ssh.pusling.com

Re: enable/disable flags in /etc/default

[Ian Jackson]

Drake Wilson writes ("Re: enable/disable flags in /etc/default"):
> 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?

Do we really need to know ?  That information seems mostly relevant
for choosing the default, and changing our default would be quite a
big cultural step (and have pretty far-reaching implications) which I
don't think we should take.

It is clear that we need to be be able to change the default for new
services systemwide, and that we need the ability to set that at
install time and have it affect all the installed software for a fresh
install.  We need to invent mechanisms for that.

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/19823.45836.935422.224...@chiark.greenend.org.uk

Re: Disable ZeroConf: how to ?

[Bastien ROUCARIES]

On Thu, Mar 3, 2011 at 3:33 PM, Stig Sandbeck Mathisen  wrote:
> Bastien ROUCARIES  writes:
>
>> some package announce their existance to the world without any admin
>> decision
>
> It should be a site policy.

And set to no by default or a least well documented

>> It is not a fud and a security hole!
>
> I disagree.

Giving information on my system without admin concent is an
information leak, and thus tag security...

Bastien

>
> --
> Stig Sandbeck Mathisen 
>
>
> --
> 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/7xmxlcs288@fsck.linpro.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/aanlktikxwcprjgx3i33hsvmbj+m9c5p8t6rybq-3w...@mail.gmail.com

Re: Help identify packages that multiarch support will break

[Guillem Jover]

Hi!

On Thu, 2011-03-03 at 14:45:51 +0100, Raphael Hertzog wrote:
> On Thu, 03 Mar 2011, Carsten Hey wrote:
> > * Raphael Hertzog [2011-03-02 15:06 +0100]:
> > >In general parsing the status file should not be done, instead you
> > >should use dpkg-query.
> > 
> > Is there any reason for this, except that the format of the status files
> > will evolve?
> 
> dpkg-query will automatically respect DPKG_ADMINDIR if it's set (and it's
> set in maintainer scripts). (this is a new feature in the upcoming version)
> 
> And the status file is not a public interface. It's a file used by dpkg.
> If tomorrow dpkg supports an optional SQLite internal database through a
> plugin, dpkg-query will continue to work but your access to the status
> file will not. (This is unlikely to happen any time soon, but you get the
> idea)

Well, the most important reason is that directly parsing the status file
does not take into account the journal files. So yes, nothing should
really be accessing anything under /var/lib/dpkg, although package
manager frontends can be considered currently grandfathered as there's
no sane interface provided by dpkg yet (read libdpkg) for their use,
and they correctly handle the journal files anyway.

> > >You should use "dpkg-query --control-path  " to
> > 
> > Jftr, there is a lot potential for performance improvements in
> > dpkg-query, some queries can be done way faster even in gawk.
> 
> JFTR, there are also 300+ bugs in the BTS and we are two active developers
> on dpkg.
> 
> dpkg-query is rarely used in performance sensitive situation, it's not
> really my priority to improve it. But if you want to help, you're welcome.

That's on my TODO list.

regards,
guillem


-- 
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/20110303160243.ga1...@gaara.hadrons.org

Re: Disable ZeroConf: how to ?

[Philipp Kern]

On 2011-03-03, Bastien ROUCARIES  wrote:
> Giving information on my system without admin concent is an
> information leak, and thus tag security...

Information leaks are leaks of *sensitive* information.  If I want to know if
you run phpmyadmin at its default location I just poll that URL and your
webserver will tell me.  If you don't run it there but in another path you'll
likely not know where to change it in the Avahi broadcast data.

And next time we get bugs about Iceweasel leaking its version number in the
User-Agent header, which I consider more sensitive (cf. Panopticlick).  But
then my mileage varies, as yours does, too.

We don't like security by obscurity, as you might know.

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

Re: Help identify packages that multiarch support will break

[Guillem Jover]

Hi!

On Wed, 2011-03-02 at 15:06:11 +0100, Raphael Hertzog wrote:
> Here's what might create troubles:

> 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.

An additional clarificaton, --control-path will not show internal
information control files (currently .list and .conffiles), for those
dpkg-query --listfiles or --status should be used instead, anything
else should be considered broken.

thanks,
guillem


-- 
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/20110303160836.gb1...@gaara.hadrons.org

Re: Disable ZeroConf: how to ?

[Tollef Fog Heen]

]] Bastien ROUCARIES 

| main security problem is resolver,
| $host -v www.local
| www.local
| www.local.mydomain.com

So the security problem you see is that if you have a domain called
«local» the entries in it might be spoofed due to how the resolver
works?

To the extent this is a bug, it's a bug in the resolver that it does not
treat names with dots in them as absolute, but relative.  I know this is
how it's been done in the past, but perhaps changing that to treating
names with as absolute would be a better solution.

Cheers,
-- 
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/871v2ojhuy@qurzaw.varnish-software.com

Re: Lintian check for missing desktop files?

[Emilio Pozuelo Monfort]

On 03/03/11 15:17, Stefano Zacchiroli wrote:
> It doesn't seem to me that your proposal of making it a release goal for
> Wheezy is incompatible with Andreas' proposal. Bottom line: a lintian
> check would be a first useful step (the heuristic is clearly more
> debatable, but I'm no condition to propose one which is better than the
> one proposed by Andreas).

Not sure if somebody has proposed it or not, but another heuristic would be
whether there is a debian menu file but not a desktop file.

Not saying it's better than Andreas' proposal... just another option.

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/4d6fbe00.3060...@debian.org

Re: Help identify packages that multiarch support will break

[Stefano Zacchiroli]

On Thu, Mar 03, 2011 at 02:45:51PM +0100, Raphael Hertzog wrote:
> And the status file is not a public interface. It's a file used by dpkg.
> If tomorrow dpkg supports an optional SQLite internal database through a
> plugin, dpkg-query will continue to work but your access to the status
> file will not. (This is unlikely to happen any time soon, but you get the
> idea)

Is there a way to ask dpkg-query to dump all the information contained
in /var/lib/dpkg/status without either having to: (1) list all fields
explicitly (using --show + --showformat) or (2) list all package names
(using --status)?

I co-maintain some utilities that parse /var/lib/dpkg/status and I'd be
glad to migrate them to dpkg-query, but both solutions above have
drawbacks. (1) is not future proof and will miss the addition of new
fields unless the utility is updated; (2) has a race condition in asking
the currently installed packages and providing them to --status (beside
being a horrible hack in requiring to list all package names as
arguments).  Am I missing something?

Having the ability to pass a package (wildcard) pattern to --show would
be enough to solve this problem.

Do you want a bug report about this?

Thanks to the mighty dpkg maintainers!
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Speeding up dpkg, a proposal

[Phillip Susi]

I have another proposal.  It looks like right now dpkg extracts all of
the files in the archive, then for each one, calls fsync() then
rename().  Because this is done serially for each file in the archive,
it forces small, out of order writes that cause extra seeking and queue
plugging.  It would be much better to use aio to queue up all of the
syncs at once, so that the elevator can coalesce and reorder them for
optimal writing.

Further, this processing is done on a per archive basis.  It would be
even better if multiple archives could be extracted at once, and all of
the fsyncs from all of the archives batched up.


-- 
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/4d6fbf93.1030...@cfl.rr.com

Re: Lintian check for missing desktop files?

[Russ Allbery]

Emilio Pozuelo Monfort  writes:

> Not sure if somebody has proposed it or not, but another heuristic would
> be whether there is a debian menu file but not a desktop file.

Lintian intentionally doesn't do this because the Debian maintainers of
the desktop systems in Debian didn't want lots of desktop entries for
applications without a GUI, which often currently have menu entries.

-- 
Russ Allbery (r...@debian.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/87k4gg5dzr@windlord.stanford.edu

Re: Lintian check for missing desktop files?

[Russ Allbery]

Stefano Zacchiroli  writes:

> ACK on the de-duplication (although I don't know whether they are in
> fact more expressive than current Debian menu files).

Desktop files are in general more expressive than menu files, and
remaining missing features could be fairly easily added, I think.

> It doesn't seem to me that your proposal of making it a release goal for
> Wheezy is incompatible with Andreas' proposal.

The main thing that has to happen to replace menu files with desktop files
is to add an implementation of generation of menus from desktop files for
those window managers and other menu clients that have Debian menu
implementations but don't natively support desktop files.  Otherwise, we
have a regression in quality of menus for those applications.

Last time we discussed this, fvwm2 was raised as a major example.

-- 
Russ Allbery (r...@debian.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/87fwr45dwz@windlord.stanford.edu

Re: Help identify packages that multiarch support will break

[Guillem Jover]

On Thu, 2011-03-03 at 17:30:42 +0100, Stefano Zacchiroli wrote:
> On Thu, Mar 03, 2011 at 02:45:51PM +0100, Raphael Hertzog wrote:
> > And the status file is not a public interface. It's a file used by dpkg.
> > If tomorrow dpkg supports an optional SQLite internal database through a
> > plugin, dpkg-query will continue to work but your access to the status
> > file will not. (This is unlikely to happen any time soon, but you get the
> > idea)
> 
> Is there a way to ask dpkg-query to dump all the information contained
> in /var/lib/dpkg/status without either having to: (1) list all fields
> explicitly (using --show + --showformat)

For each package --status will do the trick, for all packages, yeah
it does not support patterns. I guess adding that would be fine. So
one could do something like: «dpkg-query -s '*'».

> or (2) list all package names (using --status)?

Currently something like «dpkg-query -l|tr -s ' ' '\t'|cut -f2» could
do the trick, altough I could agree it sucks a bit. If --status would
accept patterns that would be nicer.

> Having the ability to pass a package (wildcard) pattern to --show would
> be enough to solve this problem.

> Do you want a bug report about this?

Yes, please.

thanks,
guillem


-- 
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/20110303172001.ga2...@gaara.hadrons.org

Re: Help identify packages that multiarch support will break

[Raphael Hertzog]

Hi,

On Thu, 03 Mar 2011, Stefano Zacchiroli wrote:
> Is there a way to ask dpkg-query to dump all the information contained
> in /var/lib/dpkg/status without either having to: (1) list all fields
> explicitly (using --show + --showformat) or (2) list all package names
> (using --status)?
> 
> I co-maintain some utilities that parse /var/lib/dpkg/status and I'd be
> glad to migrate them to dpkg-query, but both solutions above have
> drawbacks. (1) is not future proof and will miss the addition of new
> fields unless the utility is updated; (2) has a race condition in asking
> the currently installed packages and providing them to --status (beside
> being a horrible hack in requiring to list all package names as
> arguments).  Am I missing something?
> 
> Having the ability to pass a package (wildcard) pattern to --show would
> be enough to solve this problem.

If you don't pass any argument to --show you have all the installed
packages. And wildcards are already supported in --show (but not in
--status).

We can add support for wildcards in --status, in fact it will be easily
doable. Do you want to file a wishlist bug for this ?

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/20110303172306.ga13...@rivendell.home.ouaza.com

Re: Speeding up dpkg, a proposal

[Raphael Hertzog]

Hi,

On Thu, 03 Mar 2011, Phillip Susi wrote:
> I have another proposal.  It looks like right now dpkg extracts all of
> the files in the archive, then for each one, calls fsync() then
> rename().  Because this is done serially for each file in the archive,
> it forces small, out of order writes that cause extra seeking and queue
> plugging.

That's wrong. The writeback is initiated before the fsync() so the
filesystem can order the write how it wants.

And we use some linux specific ioctl to avoid that fragmentation.

> It would be much better to use aio to queue up all of the syncs at once,
> so that the elevator can coalesce and reorder them for optimal writing.

I'm not convinced it would help. You're welcome to try and provide a
patch if it works.

I'm not even convinced it's possible with the existing interfaces (but I
have no experience with AIO). aio_fsync() is only usable with aio_write()
and it's not possible to use lio_listio() to batch a bunch of aio_fsync().

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/20110303174944.gb13...@rivendell.home.ouaza.com

Bug#616342: dpkg-query: add the ability to dump the entire dpkg database

[Stefano Zacchiroli]

Package: dpkg
Version: 1.15.8.10
Severity: wishlist
User: d...@packages.debian.org
Usertags: dpkg-query

As per subject, see messages below from -devel discussion rooted at
. Reporting
bug as requested by DPKG maintainers (with best effort to find
appropriate usertags).

On Thu, Mar 03, 2011 at 05:30:42PM +0100, Stefano Zacchiroli wrote:
> Is there a way to ask dpkg-query to dump all the information contained
> in /var/lib/dpkg/status without either having to: (1) list all fields
> explicitly (using --show + --showformat) or (2) list all package names
> (using --status)?
> 
> I co-maintain some utilities that parse /var/lib/dpkg/status and I'd be
> glad to migrate them to dpkg-query, but both solutions above have
> drawbacks. (1) is not future proof and will miss the addition of new
> fields unless the utility is updated; (2) has a race condition in asking
> the currently installed packages and providing them to --status (beside
> being a horrible hack in requiring to list all package names as
> arguments).  Am I missing something?
> 
> Having the ability to pass a package (wildcard) pattern to --show would
> be enough to solve this problem.

On Thu, Mar 03, 2011 at 06:20:01PM +0100, Guillem Jover wrote:
> > Is there a way to ask dpkg-query to dump all the information contained
> > in /var/lib/dpkg/status without either having to: (1) list all fields
> > explicitly (using --show + --showformat)
> 
> For each package --status will do the trick, for all packages, yeah
> it does not support patterns. I guess adding that would be fine. So
> one could do something like: «dpkg-query -s '*'».
> 
> > or (2) list all package names (using --status)?
> 
> Currently something like «dpkg-query -l|tr -s ' ' '\t'|cut -f2» could
> do the trick, altough I could agree it sucks a bit. If --status would
> accept patterns that would be nicer.
> 
> > Having the ability to pass a package (wildcard) pattern to --show would
> > be enough to solve this problem.
> 
> > Do you want a bug report about this?
> 
> Yes, please.

On Thu, Mar 03, 2011 at 06:23:06PM +0100, Raphael Hertzog wrote:
> > Having the ability to pass a package (wildcard) pattern to --show would
> > be enough to solve this problem.
> 
> If you don't pass any argument to --show you have all the installed
> packages. And wildcards are already supported in --show (but not in
> --status).
> 
> We can add support for wildcards in --status, in fact it will be easily
> doable. Do you want to file a wishlist bug for this ?

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Help identify packages that multiarch support will break

[Guillem Jover]

On Thu, 2011-03-03 at 18:20:01 +0100, Guillem Jover wrote:
> On Thu, 2011-03-03 at 17:30:42 +0100, Stefano Zacchiroli wrote:
> > Is there a way to ask dpkg-query to dump all the information contained
> > in /var/lib/dpkg/status without either having to: (1) list all fields
> > explicitly (using --show + --showformat)
> 
> For each package --status will do the trick, for all packages, yeah
> it does not support patterns. I guess adding that would be fine. So
> one could do something like: «dpkg-query -s '*'».

Or on a second though, just supporting «dpkg-query -s» would solve
your problem too, as you don't seem to actually need pattern support,
if there's a need for that we can always add them, obviously.

> > or (2) list all package names (using --status)?
> 
> Currently something like «dpkg-query -l|tr -s ' ' '\t'|cut -f2» could
> do the trick, altough I could agree it sucks a bit. If --status would
> accept patterns that would be nicer.

Huh, disregard this, as pointed out by Raphaël, which I had forgotten
somehow, just doing «dpkg-query -f '${Package}\n' -W» would work. In
my defense (if that's possible :), I've now fixed the documentation:

  

thanks,
guillem


-- 
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/20110303180514.ga2...@gaara.hadrons.org

Re: Speeding up dpkg, a proposal

[Guillem Jover]

On Thu, 2011-03-03 at 18:49:44 +0100, Raphael Hertzog wrote:
> On Thu, 03 Mar 2011, Phillip Susi wrote:
> > It would be much better to use aio to queue up all of the syncs at once,
> > so that the elevator can coalesce and reorder them for optimal writing.
> 
> I'm not convinced it would help. You're welcome to try and provide a
> patch if it works.
> 
> I'm not even convinced it's possible with the existing interfaces (but I
> have no experience with AIO). aio_fsync() is only usable with aio_write()
> and it's not possible to use lio_listio() to batch a bunch of aio_fsync().

Actually, this was discarded early on, as Linux does not implement
aio_fsync() for any file system. Also the interface is quite cumbersome
as it requires to keep state for each aio operation, and using SA_SIGINFO
(which is not yet available everywhere).

regards,
guillem


-- 
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/20110303183039.ga4...@gaara.hadrons.org

Re: Speeding up dpkg, a proposal

[Phillip Susi]

On 3/3/2011 12:49 PM, Raphael Hertzog wrote:
> That's wrong. The writeback is initiated before the fsync() so the
> filesystem can order the write how it wants.

Don't you mean it MAY be initiated if the cache decides there is enough
memory pressure?  I don't know of any other call besides fsync and
friends to force the writeback so before that is called, it could ( and
likely is if you have plenty of memory ) still be sitting in the cache
and the disk queue idle.

> And we use some linux specific ioctl to avoid that fragmentation.

Could you be more specific?


-- 
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/4d6fdeb8.5010...@cfl.rr.com

Re: Speeding up dpkg, a proposal

[Olaf van der Spek]

On Thu, Mar 3, 2011 at 7:32 PM, Phillip Susi  wrote:
>> And we use some linux specific ioctl to avoid that fragmentation.
>
> Could you be more specific?

   sync_file_range(fd.a, 0, 0, SYNC_FILE_RANGE_WRITE);
   sync_file_range(fd.a, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE);

Olaf


-- 
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/AANLkTimBZq=piivirm+o+rhzt5d-trmcbn6kncy2m...@mail.gmail.com

Re: Speeding up dpkg, a proposal

[Phillip Susi]

On 3/3/2011 1:30 PM, Guillem Jover wrote:
> Actually, this was discarded early on, as Linux does not implement
> aio_fsync() for any file system. Also the interface is quite cumbersome
> as it requires to keep state for each aio operation, and using SA_SIGINFO
> (which is not yet available everywhere).

I was wondering why I couldn't find the fs implementation.  How
annoying.  The posix and libaio wrapper interfaces are cumbersome, but
directly calling io_submit it would be perfect to queue up all of the
writes at once and then wait for their completion.  If the kernel
actually implemented it.  Sigh.


-- 
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/4d6fe195.8030...@cfl.rr.com

Re: Speeding up dpkg, a proposal

[Phillip Susi]

On 3/3/2011 1:32 PM, Phillip Susi wrote:
> Don't you mean it MAY be initiated if the cache decides there is enough
> memory pressure?  I don't know of any other call besides fsync and
> friends to force the writeback so before that is called, it could ( and
> likely is if you have plenty of memory ) still be sitting in the cache
> and the disk queue idle.

Nevermind, I figured out what you meant.  This new
writeback_init/barrier() code that uses sync_file_range.  I hadn't seen
that before.  That should do quite well for an individual archive, so I
guess the next thing to do is try to get the calls to
tar_deferred_extract() delayed until after multiple archives are unpacked.


-- 
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/4d6fe262.3050...@cfl.rr.com

Re: enable/disable flags in /etc/default

[Sean Finney]

On Thu, 2011-03-03 at 10:37 +0100, Tollef Fog Heen wrote:
> | Is there any reason against using a debconf script that asks if the
> | daemon should be started at boot time (or on which runlevels)? That
> | way you can easily modify the configuration with dpkg-reconfigure and
> | benefit from the debconf frontends.
> 
> If you use a configuration management framework you probably don't care
> that much about debconf, since the debconfiscation of packages is fairly
> spotty and doesn't really lend itself to more complex setup.

> Imagine having a full nagios or munin configuration done through debconf
> and then imagine the preseed needed for that.  Compare that with just
> dumping a configuration file somewhere. 

yes, but a proper debconfization should respect/reflect configuration
files, so there shouldn't be need for any pre-seeding beyond having the
files in place before installing :)

> Hooking update-rc.d into debconf is probably not the worst idea in the
> world, except update-rc.d is supposed to be run non-interactively and I
> think it's the wrong place in the stack to configure that functionaliy.

i think it'd have to be a level higher, something kind of like
dbconfig-common for initscripts.


sean


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

Re: Lintian check for missing desktop files?

[Christoph Egger]

Sune Vuorela  writes:
> (isn't it only icewm and ratpoison and blackbox we might 'lose' by
> simply killing the debian menu)

Last time I checked fluxbox and awesome where both debian menu only as
well.

Regards

Christoph


pgpdyO38cMKdt.pgp
Description: PGP signature

Re: Disable ZeroConf: how to ?

[Ben Hutchings]

On Thu, Mar 03, 2011 at 05:20:37PM +0100, Tollef Fog Heen wrote:
> ]] Bastien ROUCARIES 
> 
> | main security problem is resolver,
> | $host -v www.local
> | www.local
> | www.local.mydomain.com
> 
> So the security problem you see is that if you have a domain called
> «local» the entries in it might be spoofed due to how the resolver
> works?
> 
> To the extent this is a bug, it's a bug in the resolver that it does not
> treat names with dots in them as absolute, but relative.  I know this is
> how it's been done in the past, but perhaps changing that to treating
> names with as absolute would be a better solution.

echo >>resolv.conf options ndots:15

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20110303225125.gh19...@decadent.org.uk

Re: Lintian check for missing desktop files?

[Ben Hutchings]

On Thu, Mar 03, 2011 at 09:07:52AM -0800, Russ Allbery wrote:
> Emilio Pozuelo Monfort  writes:
> 
> > Not sure if somebody has proposed it or not, but another heuristic would
> > be whether there is a debian menu file but not a desktop file.
> 
> Lintian intentionally doesn't do this because the Debian maintainers of
> the desktop systems in Debian didn't want lots of desktop entries for
> applications without a GUI, which often currently have menu entries.
 
Surely they can filter out entries with Terminal: true?

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20110303225616.gi19...@decadent.org.uk

Re: Lintian check for missing desktop files?

[Sune Vuorela]

On 2011-03-03, Christoph Egger  wrote:
> --=-=-=
>
> Sune Vuorela  writes:
>> (isn't it only icewm and ratpoison and blackbox we might 'lose' by
>> simply killing the debian menu)
>
> Last time I checked fluxbox and awesome where both debian menu only as
> well.

a quick search on google seems to tell that awesome does have xdg menu
support.

and another google search seems to tell about
http://code.google.com/p/fluxbox-xdg-menu/

/Sune


-- 
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/slrnin07bq.rvp.nos...@sshway.ssh.pusling.com

Re: Lintian check for missing desktop files?

[Sean Finney]

On Thu, 2011-03-03 at 23:01 +0100, Christoph Egger wrote:
> Sune Vuorela  writes:
> > (isn't it only icewm and ratpoison and blackbox we might 'lose' by
> > simply killing the debian menu)
> 
> Last time I checked fluxbox and awesome where both debian menu only as
> well.

instead of letting the tail wag the dog then with menu2desktop, wouldn't
it be better to cater to these WM's/DE's by providing a desktop2menu?
Still would feel like adding more layers where they should be removed
though...


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

Bug#616395: ITP: abgate -- LV2 noise gate plugin

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: abgate
  Version : 1.1.2
  Upstream Author : Antanas Bružas 
* URL : http://abgate.sourceforge.net
* License : LGPL
  Programming Lang: C++
  Description : LV2 noise gate plugin

abGate is a LV2 noise gate plugin in the LV2 format to manage
noise. A noise gate is a component which attenuates an audio
signal when it falls below a set threshold, so it can be
applied to an audio track which has one or more periods of
silence where no noise should be apparent.



--
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/20110304010102.13739.81773.reportbug@alessio-laptop

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

[Paul Wise]

On Thu, Mar 3, 2011 at 10:28 PM, Carsten Hey  wrote:

>> But, anyway, I believe that the first depends of an alternate depends 
>> relation
>> should be available in main and propose to file bugs about this.
>>
>> Do you agree this warrants a mass bug filing? I couldn't find this written 
>> out
>> in policy ...
>
> If the is a consensus, it could be added to the developer's reference or the 
> policy.

Debian Policy section 2.2.1 already covers this:

...the package must not declare a "Depends", "Recommends", or
"Build-Depends" relationship on a non-main package.

http://www.debian.org/doc/debian-policy/ch-archive.html#s-main

-- 
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/AANLkTi=zJ2+edUt+Qtp=WDfCu=eb4feinhyp_f5fs...@mail.gmail.com

Re: Lintian check for missing desktop files?

[Manoj Srivastava]

On Thu, Mar 03 2011, Sune Vuorela wrote:

> On 2011-03-03, Ben Hutchings  wrote:

>> and per-WM hooks should take care of any conversion required at
>> installation time.  Let's make that a release goal for wheezy instead of
>> perpetuating these parallel menu systems.

> Down with the debian menu! Long live the fdo menu.

> (isn't it only icewm and ratpoison and blackbox we might 'lose' by
> simply killing the debian menu)

And fvwm,

manoj

-- 
Mirrors should reflect a little before throwing back images. Jean
Cocteau
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


-- 
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/8739n3piac@anzu.internal.golden-gryphon.com

Re: Disable ZeroConf: how to ?

[Tollef Fog Heen]

]] Ben Hutchings 

Hi,

| On Thu, Mar 03, 2011 at 05:20:37PM +0100, Tollef Fog Heen wrote:
|
| > To the extent this is a bug, it's a bug in the resolver that it does not
| > treat names with dots in them as absolute, but relative.  I know this is
| > how it's been done in the past, but perhaps changing that to treating
| > names with as absolute would be a better solution.
| 
| echo >>resolv.conf options ndots:15

Thanks for the suggestion, but this does not seem to do what I want, I think?

  ndots:n
sets a threshold for the number of dots which must appear in a name
given to res_query(3) (see resolver(3)) before an initial absolute
query will be made.  The default for n is 1, meaning that if there
are any dots in a name, the name will be tried first as an absolute
name before any search list elements are appended to it.  The value
for this option is silently capped to 15.

I'd like it to not append the search list if there are dots at all.

so doing «getent hosts foo.bar» will only generate a query for
«foo.bar.», not for «foo.bar.$searchpath.»

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

Re: Help identify packages that multiarch support will break

[Stefano Zacchiroli]

[ Cc-ing the bug log ]

On Thu, Mar 03, 2011 at 07:05:14PM +0100, Guillem Jover wrote:
> > For each package --status will do the trick, for all packages, yeah
> > it does not support patterns. I guess adding that would be fine. So
> > one could do something like: «dpkg-query -s '*'».
> 
> Or on a second though, just supporting «dpkg-query -s» would solve
> your problem too, as you don't seem to actually need pattern support,
> if there's a need for that we can always add them, obviously.

Yes, absolutely: for my "dump" needs, that would be enough. I'm not sure
there are other use cases who might benefit by globbing there though.

> > Currently something like «dpkg-query -l|tr -s ' ' '\t'|cut -f2» could
> > do the trick, altough I could agree it sucks a bit. If --status would
> > accept patterns that would be nicer.
> 
> Huh, disregard this, as pointed out by Raphaël, which I had forgotten
> somehow, just doing «dpkg-query -f '${Package}\n' -W» would work. In
> my defense (if that's possible :), I've now fixed the documentation:
> 
>   

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Disable ZeroConf: how to ?

[Sujit Karatparambil]

> so doing «getent hosts foo.bar» will only generate a query for
> «foo.bar.», not for «foo.bar.$searchpath.»
Could you be more specific with what you are looking.


--
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/AANLkTiks+GNibGo0ha=dzk7n17cnuysh6syvkueg7...@mail.gmail.com