Re: Linux Future

2013-01-23 Thread Josselin Mouette 
Le mardi 22 janvier 2013 à 16:32 -0500, Theodore Ts'o a écrit : 
> One of the big things which is incredibly frustrating with the D-Bus
> interfaces is that they aren't documented; and if they are documented,
> it's not obvious where.

I can only agree completely. It is very frustrating for some plumbing
interfaces to have full API documentation for a library you don’t need,
and no API documentation for the D-Bus interface.

> I finally figured out the magic file that I needed to edit to so that
> PolicyKit would return "Yes, damn you, get the f*ck out of my way",
> but it was not at all well documented, nor in a place that would be
> easy to find.  And what I chose may have not been secure, but I got
> tired of figuring out what was the right way to fix the damned thing,
> and I chose the simplest way so that I would be asked for a password
> whenever I tried to add a new printer, or a new wifi network.

You might find this useful:
http://np237.livejournal.com/33449.html

I made this presentation in the hope to make such things easier to
understand for the sysadmin.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1358934393.588.705.camel@pi0307572

Re: Linux Future

2013-01-23 Thread Timo Juhani Lindfors 
Josselin Mouette  writes:
> You might find this useful:
> http://np237.livejournal.com/33449.html
>
> I made this presentation in the hope to make such things easier to
> understand for the sysadmin.

I read that back then when you originally posted it and I still think
it's one of the most useful presentations on the topic :) More material
is needed of course. I personally often use systemtap to observe how the
system actually works under the hood:

http://lindi.iki.fi/lindi/screencast/what-happens-when-you-mount-usb-stick1.ogv


-- 
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/84ip6o448r@sauna.l.org

Re: Linux Future

2013-01-23 Thread Jon Dowland 
On Wed, Jan 23, 2013 at 10:46:33AM +0100, Josselin Mouette wrote:
> You might find this useful:
> http://np237.livejournal.com/33449.html
> 
> I made this presentation in the hope to make such things easier to
> understand for the sysadmin.

Just for the record I found it a good read, and mentally have it bookmarked
for the next time I need it.


-- 
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/20130123131603.GA30151@debian

Bug#698792: ITP: libbusiness-br-ids-perl -- Modules for dealing with Brazilian identification codes (CPF, CNPJ, ...)

2013-01-23 Thread Joenio Costa 
Package: wnpp
Severity: wishlist
Owner: Joenio Costa 

* Package name: libbusiness-br-ids-perl
  Version : 0.0022
  Upstream Author : A. R. Ferreira 
* URL : http://search.cpan.org/dist/Business-BR-Ids/
* License : Perl
  Programming Lang: Perl
  Description : Modules for dealing with Brazilian identification codes 
(CPF, CNPJ, ...)

Business::BR::Ids is meant to provide a root for the namespace
Business::BR.  It is meant as a placeholder to reserve and explain how
the namespace can be used.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130123180317.2406.41899.reportbug@molly.neuromancer

Re: Linux Future

2013-01-23 Thread Philipp Kern 
On Tue, Jan 22, 2013 at 02:57:58PM +0100, Svante Signell wrote:
> On Tue, 2013-01-22 at 14:41 +0100, Adam Borowski wrote:
> > On Tue, Jan 22, 2013 at 12:06:16PM +0100, Pau Garcia i Quiles wrote:
> > > This blogpost is months old but it makes some interesting reflections:
> > > http://www.pappp.net/?p=969
> > It appears to be the most insightful thing about systemd vs the rest of the
> > world I've ever read.  READ IT, FOLKS!
> Worthwhile to read, definitely.

Confirmation bias?

SCNR
Philipp Kern 


signature.asc
Description: Digital signature

Bug#698799: ITP: libxml-compile-tester-perl -- Perl module to support regression testing of "XML::Compile" modules

2013-01-23 Thread Joenio Costa 
Package: wnpp
Severity: wishlist
Owner: Joenio Costa 

* Package name: libxml-compile-tester-perl
  Version : 0.90
  Upstream Author : Mark Overmeer 
* URL : http://search.cpan.org/dist/XML-Compile-Tester/
* License : Perl
  Programming Lang: Perl
  Description : Perl module to support regression testing of "XML::Compile" 
modules

XML::Compile::Tester provide functions which simplify writing tests for
XML::Compile related distributions.


-- 
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/20130123192505.18022.88457.reportbug@molly.neuromancer

Re: Linux Future

2013-01-23 Thread Florian Weimer 
* Jon Dowland:

> On Wed, Jan 23, 2013 at 10:46:33AM +0100, Josselin Mouette wrote:
>> You might find this useful:
>> http://np237.livejournal.com/33449.html
>> 
>> I made this presentation in the hope to make such things easier to
>> understand for the sysadmin.
>
> Just for the record I found it a good read, and mentally have it
> bookmarked for the next time I need it.

Unfortunately, a lot of this doesn't apply to the polkit version in
experimental, which replaces .plka files with Javascript (which
sort-of enforces that only system administrators can configure polkit,
and not other packages).


-- 
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/87r4lb4qgr@mid.deneb.enyo.de

Bug#698819: ITP: libxml-compile-cache-perl -- cache compiled XML translators

2013-01-23 Thread Joenio Costa 
Package: wnpp
Severity: wishlist
Owner: Joenio Costa 

* Package name: libxml-compile-cache-perl
  Version : 0.992
  Upstream Author : Mark Overmeer 
* URL : http://search.cpan.org/dist/XML-Compile-Cache/
* License : Perl
  Programming Lang: Perl
  Description : cache compiled XML translators

XML::Compile::Cache is the smart brother of XML::Compile::Schema; it
keeps track of your compiled readers and writers, and also helps you
administer the parameters to handle compilation. Besides, it lat you use
easy prefixes instead of full namespaces.


-- 
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/20130124003704.10490.72850.reportbug@molly.neuromancer

Bug#698820: ITP: libxml-compile-dumper-perl -- remember precompiled XML processors

2013-01-23 Thread Joenio Costa 
Package: wnpp
Severity: wishlist
Owner: Joenio Costa 

* Package name: libxml-compile-dumper-perl
  Version : 0.13
  Upstream Author : Mark Overmeer 
* URL : http://search.cpan.org/dist/XML-Compile-Dumper/
* License : Perl
  Programming Lang: Perl
  Description : remember precompiled XML processors

XML::Compile::Dumper simplifies the task of saving and loading
pre-compiled translators. Schema's can get huge, and when you are not
creating a daemon to do the XML communication, you may end-up compiling
and interpreting these large schemas often, just to be able to process
simple data-structures


-- 
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/20130124010216.22360.16707.reportbug@molly.neuromancer

Re: Linux Future

2013-01-23 Thread Adam Borowski 
On Wed, Jan 23, 2013 at 08:16:40PM +0100, Philipp Kern wrote:
> On Tue, Jan 22, 2013 at 02:57:58PM +0100, Svante Signell wrote:
> > On Tue, 2013-01-22 at 14:41 +0100, Adam Borowski wrote:
> > > On Tue, Jan 22, 2013 at 12:06:16PM +0100, Pau Garcia i Quiles wrote:
> > > > This blogpost is months old but it makes some interesting reflections:
> > > > http://www.pappp.net/?p=969
> > > It appears to be the most insightful thing about systemd vs the rest of 
> > > the
> > > world I've ever read.  READ IT, FOLKS!
> > Worthwhile to read, definitely.
> 
> Confirmation bias?

No, it's something in the middle.  Those who dislike systemd say it
exaggerates systemd's claimed benefits, while Joss considers it an attack
as well.  Let's no go there for now.

What makes this article worth reading is that it points out _why_ systemd
is so controversial.

There are two ways to design a system:
* a monolithic well-integrated system, granting features and efficiency at
  the cost of portability and hackability
* the traditional Unix way, with a stress on replaceable tools that do only
  one thing, granting freedom to tinker, using the system in a way not
  envisioned by its creators

Thus, it's not about whether sysvinit, upstart or systemd is better at a
particular job, it's about whether benefits are worth making it hard to
change.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130124043941.ga10...@angband.pl

Re: Linux Future

2013-01-23 Thread Russ Allbery 
Adam Borowski  writes:

> There are two ways to design a system:
> * a monolithic well-integrated system, granting features and efficiency at
>   the cost of portability and hackability
> * the traditional Unix way, with a stress on replaceable tools that do only
>   one thing, granting freedom to tinker, using the system in a way not
>   envisioned by its creators

...at the cost of occasional complex, difficult-to-debug interactions
between the separate components, and a larger total code base to support
fallbacks and alternatives to provide loose coupling between the
components.

Just to complete both sides of the picture.  (I'm more of a second camp
person myself, but they both have drawbacks.)

The traditional UNIX way is great if everyone can agree on a clean and
minimal API between the components that enables thorough independent
testing of the components and minimizes complex multi-component
interactions.  Were that this were always the case  Most of the places
where people reach for other strategies are places where it's not clear
those conditions hold.

Whenever you have a complex programming problem, break it into a client
and a server.  Now you have two complex programming problems, a protocol
design problem, and a security vulnerability.

-- 
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/87ham79ojm@windlord.stanford.edu

multiarch dependency hell. build amd64, can't install without also building i386

2013-01-23 Thread Paul Johnson 
This is a multiarch issue I had not considered before. Have you seen
it? I never wanted to be a "cross compiler", I really only want to
build amd64.  But I have some i386 libraries for a particular program
(acroread).

I've just learned that, if I build amd64 packages, I can't install
them for testing because I've not also built the i386 packages.

pauljohn@pols-124:cairo-1.12.10$ sudo dpkg -i
libcairo2_1.12.10-1_amd64.deb (Reading database ... 31 files and
directories currently installed.)
Preparing to replace libcairo2:amd64 1.12.10-1 (using
libcairo2_1.12.10-1_amd64.deb) ...
Unpacking replacement libcairo2:amd64 ...
dpkg: error processing libcairo2:amd64 (--install):
 package libcairo2:amd64 1.12.10-1 cannot be configured because
libcairo2:i386 is at a different version (1.12.2-2)
Errors were encountered while processing:
 libcairo2:amd64

That's really inconvenient! I don't understand why there has to be a
linkage between the shared library versions on amd64 and i386. Aren't
they separate?

You ask "why cairo?"  I am curious to know if a new libcairo2 fixes a
little bug in Evince (invisible vertical quotes). So I worked through
the packaging for cairo-1.12.10. dpkg-buildpackage -rfakeroot gives me
the goods (after fiddling some patch fuzz):

cairo-perf-utils_1.12.10-1_amd64.deb
libcairo2_1.12.10-1_amd64.deb
libcairo2-dbg_1.12.10-1_amd64.deb
libcairo2-dev_1.12.10-1_amd64.deb
libcairo2-doc_1.12.10-1_all.deb
libcairo2-udeb_1.12.10-1_amd64.udeb
libcairo-gobject2_1.12.10-1_amd64.deb
libcairo-script-interpreter2_1.12.10-1_amd64.deb


I expect your answer will be "yes, it really is that hard, you have to
learn how to compile for i386 too". I'm trying
(http://wiki.debian.org/Multiarch/HOWTO), but not making progress. I'm
like a collection of monkies trying to type the Bible at random, I'm
afraid.

pauljohn@pols-124:~$ sudo apt-get build-dep -a i386 libcairo2
[sudo] password for pauljohn:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Picking 'cairo' as source package instead of 'libcairo2'
The following packages have unmet dependencies:
 libfontconfig1-dev:i386 : Depends: libfreetype6-dev:i386 (>= 2.1.7)
but it is not going to be installed
E: Build-dependencies for libcairo2 could not be satisfied.


pauljohn@pols-124:~$ sudo apt-get install libfontconfig1-dev:i386
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
 libcairo2 : Breaks: libcairo2:i386 (!= 1.12.10-1) but 1.12.2-2 is to
be installed
 libcairo2:i386 : Breaks: libcairo2 (!= 1.12.2-2) but 1.12.10-1 is to
be installed
 libfontconfig1-dev : Conflicts: libfontconfig1-dev:i386 but 2.9.0-7.1
is to be installed
 libfontconfig1-dev:i386 : Depends: libexpat1-dev:i386 but it is not
going to be installed
   Depends: libfreetype6-dev:i386 (>= 2.1.7)
but it is not going to be installed
   Depends: pkg-config:i386 but it is not
going to be installed
   Conflicts: libfontconfig1-dev but 2.9.0-7.1
is to be installed
E: Unmet dependencies. Try 'apt-get -f inst

And I stop there, seeing that the failed install of the amd64 packages
has now broken everything. I need to back-track to find a way to fix
that and then hide in the safety of Wheezy.

-- 
Paul E. Johnson
Professor, Political Science  Assoc. Director
1541 Lilac Lane, Room 504  Center for Research Methods
University of Kansas University of Kansas
http://pj.freefaculty.org   http://quant.ku.edu


-- 
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/caerodj-33b-xmf3e9nyqbc3pjv75t+by5hzw1gsbmfsisob...@mail.gmail.com

Re: Linux Future

2013-01-23 Thread Adam Borowski 
On Wed, Jan 23, 2013 at 08:45:49PM -0800, Russ Allbery wrote:
> Adam Borowski  writes:
> 
> > There are two ways to design a system:
> > * a monolithic well-integrated system, granting features and efficiency at
> >   the cost of portability and hackability
> > * the traditional Unix way, with a stress on replaceable tools that do only
> >   one thing, granting freedom to tinker, using the system in a way not
> >   envisioned by its creators
> 
> ...at the cost of occasional complex, difficult-to-debug interactions
> between the separate components, and a larger total code base to support
> fallbacks and alternatives to provide loose coupling between the
> components.
> 
> Just to complete both sides of the picture.  (I'm more of a second camp
> person myself, but they both have drawbacks.)
> 
> The traditional UNIX way is great if everyone can agree on a clean and
> minimal API between the components that enables thorough independent
> testing of the components and minimizes complex multi-component
> interactions.

Putting it another way:

* the monolithic design has a huge freeness problem.  To do anything not on
  a rigid list of features you need to learn the intricaties of a large
  complex system, and you can be certain that even if you manage to do so,
  your patches will have a hard time getting accepted, and features you base
  your code on will be thrown away on a whim every couple of years or so. 

  * In Unix, on the other hand, the barrier is typically mere knowledge of
scripting, in shell or any language of your preference.  Small
components are easy to document (in man pages, etc) by the virtue of
no single part being complex.

* the Unix way almost guarantees you will do things wrong.  While writing
  something that works is easy, making it work in corner cases requires
  serious research every time.  Unlike a streamlined system, there's a
  twisty maze of little init scripts, all alike -- yet usually with small
  differences that do matter.  Managing interactions becomes hard.

  * A monolithic system has a global view of the system, instead of a
guerilla war in every corner.


-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130124050949.ga10...@angband.pl

Re: multiarch dependency hell. build amd64, can't install without also building i386

2013-01-23 Thread Chow Loong Jin 
On 24/01/2013 12:56, Paul Johnson wrote:
> [...]
> I've just learned that, if I build amd64 packages, I can't install
> them for testing because I've not also built the i386 packages.
> [...]
> That's really inconvenient! I don't understand why there has to be a
> linkage between the shared library versions on amd64 and i386. Aren't
> they separate?

Simply put, when foo:amd64 and foo:i386 are installed, all common files that are
shared between them must be bit-for-bit identical (though in practice this isn't
so, e.g. the gzipped files in /usr/share/doc/$pkg/). This is a reasonable
expectation when foo:amd64 and foo:i386 are of the same version, but it's
probably going to fail very miserably when they're of different versions, so
that's how it is.

See

for more information.

> You ask "why cairo?"  I am curious to know if a new libcairo2 fixes a
> little bug in Evince (invisible vertical quotes). So I worked through
> the packaging for cairo-1.12.10. dpkg-buildpackage -rfakeroot gives me
> the goods (after fiddling some patch fuzz):
> [...]

In your case, you could just very well install the packages, leave the
dependencies unresolved, and just run Evince as is to test.

> I expect your answer will be "yes, it really is that hard, you have to
> learn how to compile for i386 too". I'm trying
> (http://wiki.debian.org/Multiarch/HOWTO), but not making progress. I'm
> like a collection of monkies trying to type the Bible at random, I'm
> afraid.
> [...]

Just use sbuild/pbuilder, which basically compile things inside a chroot so you
don't have to deal with the cross-compilation mess. As long as the architecture
of the chroot you're compiling for is supported by the kernel you're running,
it'll work.

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Re: Linux Future

2013-01-23 Thread Chow Loong Jin 
On 24/01/2013 13:09, Adam Borowski wrote:
> [...]
> * the monolithic design has a huge freeness problem.  To do anything not on
>   a rigid list of features you need to learn the intricaties of a large
>   complex system, and you can be certain that even if you manage to do so,
>   your patches will have a hard time getting accepted, and features you base
>   your code on will be thrown away on a whim every couple of years or so. 
> 
>   * In Unix, on the other hand, the barrier is typically mere knowledge of
> scripting, in shell or any language of your preference.  Small
> components are easy to document (in man pages, etc) by the virtue of
> no single part being complex.
> 
> * the Unix way almost guarantees you will do things wrong.  While writing
>   something that works is easy, making it work in corner cases requires
>   serious research every time.  Unlike a streamlined system, there's a
>   twisty maze of little init scripts, all alike -- yet usually with small
>   differences that do matter.  Managing interactions becomes hard.
> 
>   * A monolithic system has a global view of the system, instead of a
> guerilla war in every corner.

  * But if it ever fails due to a bug within it, $DEITY help you, because
you're going to have to go through everything mentioned in your first
point here (save the issues with getting patches accepted)

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Backports upgrade policy (ButAutomaticUpdates:yes)

2013-01-23 Thread martin f krafft 
Hey folks,

For a while now, the backports archive sets "ButAutomaticUpdates:
yes" in its Release file, causing packages in the archive to be
pinned with priority 100, rather than 1 (which was previously the
case).

The effect of this is that once a backport package is installed and
a new version appears in the backport archive, APT will treat it as
an upgrade candidate. Cf. apt_preferences(5):

  100 <= P < 500
  causes a version to be installed unless there is a version
  available belonging to some other distribution or the
  installed version is more recent

While this might seem like a good idea at first — like when
a security fix reaches the backports archive — I think this actually
counters our stable policy, and backports are destined for stable
systems after all.

Our stable policy says that we don't upgrade packages with the
exception of pure security fixes or other fixes that are guaranteed
not to remove functionality or introduce big changes (and bugs).

Backports, however, may very well track a package in testing,
especially if the backporter has a vested interest in keeping up to
date with a package's releases even on a stable system, and
introduce major changes. Therefore, backports hold no guarantee that
they do not remove functionality or introduce gross new bugs.

In the past, you could always install a backport if you knew what
you wanted (apt-get install -t etch-backports …), but if you
actually wanted to get upgrades, you had to add a package pin
("release a=etch-backports"; priority:600). That is, the more you
wanted to deviate, the more explicit steps you'd have to take.

This behaviour has now been inverted: you can install a backport,
but if you do *not* want to receive upgrades automatically, you have
to install a pin. Put differently: to prevent automatic further
deviation from stable, you have to take additional steps.

I am sure we all agree that the
deny-all-but-what-is-explicitly-allowed policy is the better one. So
why did we make the switch?

Of course, once you install backports, you no longer have a stable
system, and hence our stable packages guarantee no longer holds.
However, many will agree that backports can augment a stable system
in useful and sometimes even necessary ways. A later version might
provide a required functionality, or a bug might only be fixed in
testing, forcing the admin to install a backport without really
wanting to give up the quality of the stable system.

The problem in the past was that security fixes to the package in
stable may well never reach users with backports installed. This
problem is actually not addressed, as security fixes might not
appear in testing anytime soon, nor is it guaranteed that the
backport will be upgraded.

However, unless the admin takes additional steps (= does not forget
to take additional steps), `apt-get upgrade` (no dist-upgrade
necessary) might suddenly introduce major changes.

I think we ought to revert this change and turn off
ButAutomaticUpgrades for the backports archive (and update
apt_preferences(5)).

In the long run, maybe we need a stable-backports-security
repository, which can be used to ensure that backport users don't
miss out on security fixes without having to accept major changes.
Ping me when the security team has 30 active members working 5 days
a week on Debian and I'll look into writing the dak patches. ;)

Thanks for your attention and comments!

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"without music, life would be a mistake."
 - friedrich nietzsche


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Linux Future

2013-01-23 Thread Russ Allbery 
Adam Borowski  writes:

> Putting it another way:

> * the monolithic design has a huge freeness problem.  To do anything not on
>   a rigid list of features you need to learn the intricaties of a large
>   complex system, and you can be certain that even if you manage to do so,
>   your patches will have a hard time getting accepted, and features you base
>   your code on will be thrown away on a whim every couple of years or so. 

>   * In Unix, on the other hand, the barrier is typically mere knowledge of
> scripting, in shell or any language of your preference.  Small
> components are easy to document (in man pages, etc) by the virtue of
> no single part being complex.

> * the Unix way almost guarantees you will do things wrong.  While writing
>   something that works is easy, making it work in corner cases requires
>   serious research every time.  Unlike a streamlined system, there's a
>   twisty maze of little init scripts, all alike -- yet usually with small
>   differences that do matter.  Managing interactions becomes hard.

>   * A monolithic system has a global view of the system, instead of a
> guerilla war in every corner.

Yes, that sounds pretty much right to me.

-- 
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/87622n9lp5@windlord.stanford.edu

Re: Linux Future

2013-01-23 Thread Russ Allbery 
Chow Loong Jin  writes:

>   * But if it ever fails due to a bug within it, $DEITY help you, because
> you're going to have to go through everything mentioned in your first
> point here (save the issues with getting patches accepted)

Sometimes, debugging can be easier in monolithic systems.  It depends on
how they're build.  One advantage of a monolithic system is that you can
design a tracing facility into it from the start and have all components
trace in the same way, which means that debugging is often just a matter
of enabling tracing and then seeing where things blew up.

It really depends.  I've occasionally tracked down obscure problems in
traditional UNIX environments to bugs in the shell, and problems like that
are quite difficult to find.

Sometimes, people use UNIX tools to build nice, elegant, comprehensible
systems with clear interfaces that are a pleasure to debug.  Sometimes you
get configure scripts.  :)  Nothing but bog-standard UNIX tools there!

-- 
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/871udb9lje@windlord.stanford.edu

Re: Backports upgrade policy (ButAutomaticUpdates:yes)

2013-01-23 Thread Russ Allbery 
martin f krafft  writes:

> While this might seem like a good idea at first — like when
> a security fix reaches the backports archive

Indeed.

> I am sure we all agree that the
> deny-all-but-what-is-explicitly-allowed policy is the better one. So
> why did we make the switch?

Because of security fixes.  :)

The basic problem is that we have no way of knowing whether an updated
backport is a security fix or not, and not installing security fixes is
rather problematic.

> The problem in the past was that security fixes to the package in stable
> may well never reach users with backports installed. This problem is
> actually not addressed, as security fixes might not appear in testing
> anytime soon, nor is it guaranteed that the backport will be upgraded.

I always understood that I had a responsibility as a backporter to release
security fixes as necessary, and if I wasn't going to do that, I shouldn't
upload the backport in the first place.  I handle backport security fixes
exactly the way that I handle stable security fixes.

There is not, so far as I know, a security team like there is for stable,
and that team does a ton of great work for stable.  Manpower would be
required to duplicate that work.  But while we aren't providing stable
levels of security support for backports, I don't think we're doing as
poorly as all that.

> In the long run, maybe we need a stable-backports-security repository,
> which can be used to ensure that backport users don't miss out on
> security fixes without having to accept major changes.  Ping me when the
> security team has 30 active members working 5 days a week on Debian and
> I'll look into writing the dak patches. ;)

This would immediately introduce another problem: what version of the
backport are you goint to patch for the security vulnerability?  Certainly
not every version that's ever been uploaded and that someone might
possibly be stuck at.  :)

Also, backports, as with testing, frequently get security fixes in the
form of upstream releases that include other changes.

-- 
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/87wqv386oz@windlord.stanford.edu

Re: scripting DBus services

2013-01-23 Thread Thomas Goirand 
On 01/22/2013 10:32 PM, Neil Williams wrote:
> On Tue, 22 Jan 2013 15:05:58 +0100
> Josselin Mouette  wrote:
>
>> Le mardi 22 janvier 2013 à 14:57 +0100, Svante Signell a écrit : 
>>> Worthwhile to read, definitely.
>> Yet full of misinformation, like the idea that using D-Bus makes a
>> service less scriptable (while the reality is a complete opposite), or
>> that configuration files are less human-readable than shell scripts.
> Hmm, scripts written in certain languages may have simple DBus
> interfaces but it's by no means trivial to do asynchronous DBus
> operations in a shell script. dbus-send does immediate calls but if
> something is going to take longer than the usual DBus timeout,
> responding to a DBus signal requires something other than shell.
>
> So, depending on what needs to be accomplished and how long it is going
> to take, DBus does make services less scriptable simply because DBus
> just won't sit there and wait (and block) for hours. Within what DBus
> is meant to do, that's expected and correct. It just means that there
> is more work involved than simply waiting for /usr/sbin/foo to return
> in a single line shell script.
>
> Even with dbus-send, what may have been a 30 character one-line call in
> shell becomes a 120 character complex call with quoting issues and
> return-type-unmangling.
>
> It depends on the meaning of "scriptable" - with the strict meaning of
> the kind of shell scripts to which sysadmins have become familiar, then
> DBus really isn't scriptable except for v.simple operations. 

Hi,

I know very few about dbus. Could you quote/show/link to examples
of what you are saying?

Cheers,

Thomas


--
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/5100d2c9.8040...@debian.org

Re: Backports upgrade policy (ButAutomaticUpdates:yes)

2013-01-23 Thread Michael Gilbert 
On Thu, Jan 24, 2013 at 12:39 AM, martin f krafft wrote:
> Hey folks,
>
> For a while now, the backports archive sets "ButAutomaticUpdates:
> yes" in its Release file, causing packages in the archive to be
> pinned with priority 100, rather than 1 (which was previously the
> case).
>
> The effect of this is that once a backport package is installed and
> a new version appears in the backport archive, APT will treat it as
> an upgrade candidate. Cf. apt_preferences(5):
>
>   100 <= P < 500
>   causes a version to be installed unless there is a version
>   available belonging to some other distribution or the
>   installed version is more recent
>
> While this might seem like a good idea at first — like when
> a security fix reaches the backports archive — I think this actually
> counters our stable policy, and backports are destined for stable
> systems after all.
>
> Our stable policy says that we don't upgrade packages with the
> exception of pure security fixes or other fixes that are guaranteed
> not to remove functionality or introduce big changes (and bugs).
>
> Backports, however, may very well track a package in testing,
> especially if the backporter has a vested interest in keeping up to
> date with a package's releases even on a stable system, and
> introduce major changes. Therefore, backports hold no guarantee that
> they do not remove functionality or introduce gross new bugs.

Simple answer: backports != stable.  Users that want a system that
adheres to the stable release policy should certainly plan to avoid
backports.  Just as well, backports users should automatically receive
the updates that uploaders have decided are useful enough to put
there.  Finally, those backport users that want to stick with a
particular backported version of a package always have the option to
pin it.

Best wishes,
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/CANTw=MOcGJOy5FbeNmzxrN0qtnzPoj=s4g_peka6tcrdue9...@mail.gmail.com

Re: Backports upgrade policy (ButAutomaticUpdates:yes)

2013-01-23 Thread martin f krafft 
also sprach Russ Allbery  [2013.01.24.1856 +1300]:
> I always understood that I had a responsibility as a backporter to release
> security fixes as necessary, and if I wasn't going to do that, I shouldn't
> upload the backport in the first place.  I handle backport security fixes
> exactly the way that I handle stable security fixes.

So if a software is at 1.0 in stable and you backported 1.1~bpo60.1
from testing, and then a security flaw is found in all 1.x releases
which was fixed in 2.0, and meanwhile 2.2 is in testing, will you
backport the security fix to 1.1 and release 1.1~bpo60.2?

And say that a year later 2.3 comes out and it's the bee's knees
because it fully replaces 1.1 except that the configuration cannot
be automatically migrated, and all the power users on #debian-devel
persuade you to backport it, what do you do?

In my experience, once a software is backported, there's a much
smaller threshold to backport newer versions. In fact, I have been
exposed to software that was backported within minutes after the
parent package migrated to testing, probably just for the sake of
providing cutting-edge versions to users.

I feel that more software goes through the backports archive because
of new features and updates that wouldn't pass our stable release
policy, than security fixes to previously backported software.

And yet, setting "ButAutomaticUpdates: yes" pretends that it's the
other way around.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"what's your conceptual continuity? --
 well, it should be easy to see:
 the crux of the bisquit is the apopstrophe!"
-- frank zappa


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Backports upgrade policy (ButAutomaticUpdates:yes)

2013-01-23 Thread Joerg Jaspert 
On 13101 March 1977, martin f. krafft wrote:

>> I always understood that I had a responsibility as a backporter to release
>> security fixes as necessary, and if I wasn't going to do that, I shouldn't
>> upload the backport in the first place.  I handle backport security fixes
>> exactly the way that I handle stable security fixes.

> And say that a year later 2.3 comes out and it's the bee's knees
> because it fully replaces 1.1 except that the configuration cannot
> be automatically migrated, and all the power users on #debian-devel
> persuade you to backport it, what do you do?

Backport it. Thats one of the points backports is for. I would actually
ask wth 2.2 wasn't backported before.

> I feel that more software goes through the backports archive because
> of new features and updates that wouldn't pass our stable release
> policy, than security fixes to previously backported software.

Thats one more point of backports. You won't get it into stable (the
stable release policy does limit it to security and few other changes
for a reason, not new features).

> And yet, setting "ButAutomaticUpdates: yes" pretends that it's the
> other way around.

If you decide to install a backport - you do that. You decide to get
that most recent version. Which includes keeping it most recent.

If you really want it only when you explicitly say so, including
upgrades to (possible) security fixes, I don't think ButAutomaticUpdates
overrides local pinnings?!

-- 
bye, Joerg
Your mother seems really upset about something. I better go have a talk
with her… during the commercial.


--
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/87k3r3yrr6@gkar.ganneff.de

Bug#698825: ITP: ad2openldap -- Replication tool to populate OpenLDAP with objects from AD

2013-01-23 Thread Brian Hodges 
Package: wnpp
Severity: wishlist
Owner: Brian Hodges 


* Package name: ad2openldap
  Version : 0.10
  Upstream Author : FHCRC SciComp 
* URL : 
https://github.com/FredHutch/IT/tree/master/general/ad2openldap
* License : GPLv3
  Programming Lang: Python
  Description : Replication tool to populate OpenLDAP with objects from AD

Replicates user/group information from a Microsoft AD into an OpenLDAP server.


-- 
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/20130124071609.21829.79755.report...@vosges.fhcrc.org

Re: Backports upgrade policy (ButAutomaticUpdates:yes)

2013-01-23 Thread Russ Allbery 
martin f krafft  writes:
> also sprach Russ Allbery  [2013.01.24.1856 +1300]:

>> I always understood that I had a responsibility as a backporter to
>> release security fixes as necessary, and if I wasn't going to do that,
>> I shouldn't upload the backport in the first place.  I handle backport
>> security fixes exactly the way that I handle stable security fixes.

> So if a software is at 1.0 in stable and you backported 1.1~bpo60.1 from
> testing, and then a security flaw is found in all 1.x releases which was
> fixed in 2.0, and meanwhile 2.2 is in testing, will you backport the
> security fix to 1.1 and release 1.1~bpo60.2?

Ah, yes, I should have said that I handle it the way that I handle testing
security fixes, sorry.

I view backports as a miniature version of the testing distribution for
that particular package.  When you install a package from backports, you
effectively should get the testing version of just that one package,
without having to upgrade the rest of your system.

It sounds like you instead want backports to be a repository of specific
useful versions of packages that are newer than the last stable.  The
problem with that approach is that it's much harder to maintain in a
secure fashion than tracking testing for the package.  (In fact, it's a
potentially unbounded problem; every new feature release that was uploaded
to backports could potentially need security fixes!)

> I feel that more software goes through the backports archive because of
> new features and updates that wouldn't pass our stable release policy,
> than security fixes to previously backported software.

True.  But then that software does indeed have security bugs.

> And yet, setting "ButAutomaticUpdates: yes" pretends that it's the other
> way around.

I think that's too strong.  It says that, overall, ensuring people get
software with security fixes is more important than ensuring that they get
stable software.  Some of the new packages are security-related, and some
aren't, and there's no way to tell the difference.

Also, I'll mention that back when backports wasn't configured for
automatic updates, that was *the* most frequent request and point of user
confusion on the backports list.

-- 
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/87libj81ne@windlord.stanford.edu

Re: Backports upgrade policy (ButAutomaticUpdates:yes)

2013-01-23 Thread martin f krafft 
also sprach Joerg Jaspert  [2013.01.24.2017 +1300]:
> > And say that a year later 2.3 comes out and it's the bee's knees
> > because it fully replaces 1.1 except that the configuration cannot
> > be automatically migrated, and all the power users on #debian-devel
> > persuade you to backport it, what do you do?
> 
> Backport it. Thats one of the points backports is for. I would actually
> ask wth 2.2 wasn't backported before.

Because 2.0 drops a feature you need and introduces some bugs. Also,
the configuration needs a lot of manual work to migrate.

> > And yet, setting "ButAutomaticUpdates: yes" pretends that it's the
> > other way around.
> 
> If you decide to install a backport - you do that. You decide to get
> that most recent version. Which includes keeping it most recent.

Except ever since backports became more and more popular, causing
NotAutomatic to be set at some point in time due to popular demand,
it's been such that you decided to get the backport and if you
wanted to keep it recent, you had to do an additional step.

Now you have to do the additional step to prevent that. Someone
just changed it for no good reason. Both ways have pros and cons.
Setting ButAutomaticUpdates certainly doesn't have enough pros to
warrant this change, just like that. The way it was before does have
a huge pro though: it's the way it's been for years. You know, never
change a winning team…

> If you really want it only when you explicitly say so, including
> upgrades to (possible) security fixes, I don't think
> ButAutomaticUpdates overrides local pinnings?!

No, it does not, and yes, you can just pin all backports to
1 manually. However, as I said before: this is requiring an
additional step to get the behaviour that was default for years, and
which IMHO makes more sense too.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
there's an old proverb that says just about whatever you want it to.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)