Re: Towards d-i wheezy beta 3

[Daniel Hartwig]

On 10 September 2012 06:07, Cyril Brulebois  wrote:
> If anybody wants to see something land into this release, it would be
> nice to mention it now instead of after the end of the merge window.

Is there potential to see pkgsel use apt-get instead of aptitude
(following the same change in tasksel)?  There is already a patch
committed.  I'll give this more of a test this week with some induced
errors during the installation.

Can also add --fix-missing to make apt-get more robust, but I
personally don't think that is a good idea.

Regards


-- 
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/CAN3veRejAOyCvyZ72aDtESJ3a47RcTjYyoWtsvQ15_m=u9q...@mail.gmail.com

Re: Feedback on Debian 7.0

[Daniel Hartwig]

On 2 June 2013 03:10, Russ Allbery  wrote:
> It would probably be a good idea for the installer to add commented-out
> sources.list lines for the main archive, even if the installation is done
> off-line.  (Assuming that it doesn't, but Nikolas's experience seems to
> indicate that it doesn't.)
>

It doesn't, see .  As no mirror was
chosen during the install, none is placed in sources.  A default can
of course be selected and commented out, provided that such default
agrees with the increase in load.


-- 
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/CAN3veReyOT5-9r8=8sihqv4muvsto9ezfyh1nsqfpc8fver...@mail.gmail.com

Detect if root login is disabled?

[Daniel Hartwig]

Hello

I am looking at Bug#516854 and wondering:

Is there a robust way for a *user* to detect if root login is
disabled?  Would like to perform such a check from an instance of
aptitude running as a user account.

I am aware of the following method which detects the `passwd -l' style
lock, however, it requires read access to /etc/shadow:

io:~# passwd -S root | grep " L " > /dev/null; echo $?
1
io:~# passwd -l root
passwd: password expiry information changed.
io:~# passwd -S root | grep " L " > /dev/null; echo $?
0

Thanks


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

Re: Detect if root login is disabled?

[Daniel Hartwig]

Igor Pashev  wrote:
> su?

su doesn't distinguish between a locked password and an incorrectly entered one.

Would like to know the locked status before trying su so that the
program can either fall back to sudo or give an error message more
informative than just "incorrect password".


-- 
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/can3vercmhm2p83frdtckw3rz1rbki7ocvtv_fcr+q+masw7...@mail.gmail.com

dpkg, aptitude and use of state files (was: Re: Important information regarding upcoming dpkg 1.16.2 upload)

[Daniel Hartwig]

TL;DR: aptitude does keep dpkg/status and apt/extended_states
up-to-date with the *current* state of a package, just like other
software.  Please do not grok pkgstates to determine if something is
installed, etc.

On 18 March 2012 23:16, John D. Hendrickson and Sara Darnell
 wrote:
> Hi,  I like dselect, dpkg, and aptitude.  I have a request.  aptitude should
> import and export
>
>/var/lib/dpkg/status
>
> At least when asked.  Right now aptitude takes awkwardly and but doesn't
> give back.
>
> It's not just private selections.  Private methods and worse pivate status
> make other programs impossible.
>
> "aptitude : attempts to detect status of  dpkg or dselect"  That's is far
> short of par - noting how sipmle the task of using human readable status as
> save format is.
>
>/var/lib/aptitude/pkgstatus
>
>(also it uses pieced avail lists/ instead of unified avail in dpkg/ )
>
> pkgstatus contains incorrect information!  and it codes states "1 3 3 4"
> while using wide text for everything but that.
>

The developer explains (vaguely) why there is not a one-to-one
corelation between dpkg status, aptitude pkgstates, and apt
extended_states:[1]

>> Currently, aptitude stores the held status of packages in some
>> internal database. I am guessing this may be
>> /var/lib/aptitude/pkgstates. Would it not be best if it behaved like
>> apt-get, ie. reading information from /var/lib/dpkg/status?
>
>   No, it wouldn't.  dselect's states are not in general equivalent to
> aptitude's, although they're similar.

Not sure what that means?  Me either, initially.

Aptitude allows the user to mark package changes but leave them for
another session.  So, interactively you can mark several installs,
removals, etc. and then quit, when you start again those changes will
still be remembered and ready to perform.

This is what it tries to store in pkgstates, the user's "intended"
state for the package, not it's actual state.

Except for "hold" (which is a whole bag of fish), the actual, current
state of packages is kept in dpkg and apt files, just like other
programs use.


> My main concern is the these "states" for aptitude are private data -
> excluding other software - and covering up why things are wrong.  (takeover
> issues)
>
> Lastly, an end user (me) can make install errors by using aptitude, dpkg,
> apt-get, dselect not realizing that aptitude uses privatized unshared
> current system disk status that isn't what dpkg uses (and how would you know
> if it's not in a status file to see?)
>

As above, most of pkgstates is actually private to aptitude.  Some of
it is duplicated for convenience, however, aptitude does take measures
to keep in sync. with dpkg/apt when it is started.  Admitedly, this
process fails quite often.

For example, removing a package with apt-get can lead to aptitude
trying to reinstall that package.  Note that aptitude is aware that
the package has been removed, it just mistakenly believes the user has
requested it be installed again.


> There's a way to get aptitude states maybe by relying on dump software.
>  Though relying on anyone keeping dumpers efficient and up to date simply
> isn't a great idea.
>

I don't think it would be useful for an other program to grok
pkgstates to determine if something is installed, etc.  Please use the
normal dpkg and apt means for that.

In theory, the only unique information in pkgstates is whether the
user has pending actions marked in aptitude.


Any problem in this situation is due entirely to aptitude's unique
requirements.  IMO the current dpkg and apt status files are quite
adequate for those systems.

Please be aware that it is my next priority to resolve the issues in this area.


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=137771#23


Regards


-- 
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/CAN3veReMaYNHWsBfuLO9brNuQ56xoR1uTPkddg=y5lzvzev...@mail.gmail.com

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

[Daniel Hartwig]

On 19 October 2012 09:19, Christoph Anton Mitterer
 wrote:
> 1) Programs (I usually mean apt or aptitude here don't give exit
> statuses != 0 in all cases when something critical has happened.

The apt-utils are mostly ok at aborting with non-zero for critical
errors.  Aptitude is not.

> e.g. apt-get update returns 0 even if the update failed.

This is only for transient errors (such as connection problems)
printed with a “W:” label.  If a Release file is expired or otherwise
invalid the exit status is reliably non-zero.

After Wheezy it may be useful to look at using $? = 1 (or 2) to
indicate these transient errors (or just consider them the same as the
other errors).  Calling programs could then retry the update, or
switch to a different mirror, which may resolve the issue.  If the
calling program doesn't care it can test for $? != 0 to catch *all*
errors, or $? = 100 for only serious errors.

>
> E.g. a cluster operator may have done the following:
> Added a cron job that calls apt-get update daily and reports an error if
> $? != 0.
>
> Run check_apt via Nagios/Icinga to be notified on updates.
>
>
> An attacker simply blocking the update as described above may now easily
> prevent updates from being installed.

For a short time.  Eventually “update” will (or should!) complain
about the expired Release files, $? != 0.

> 2) downgrade attacks
> These have the same idea as blocking attacks (prevent the user to get
> updates) but are a bit smarter.
> You don't simply block any update requests, but rather you sent the user
> old repository data. These are correctly signed by Debian... just...
> they are old and do not yet know about the updates.
>
> The only way of preventing this was, if apt/aptitude would utterly bail
> out/print error messages/give non-zero exit statuses if the repo-data
> they are working on are older than 
> (typically that would be something around the mirror update interval).
>
> Of course the time of a Release file would have to be signed ;)
> And of course it would be the duty of a user to make sure he has a
> correct time source.
> But at least now he'd have a chance to have a fully secured chain.

Security and -updates Release files use Valid-Until which partially
addresses this.  I think this will only trigger an error on “apt-get
update”, not “install” or “upgrade”.  Presumably update scripts use
“update” before “upgrade” and check the status of the former.


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

Re: New virtual packages: lv2-plugin and lv2-host

[Daniel Hartwig]

On 21 November 2012 22:51, Alessio Treglia  wrote:
> Actually I receive lots of mails from users asking me questions like "How 
> could
> I find an exhaustive list of LV2 toys currently provided by Debian?", "Does 
> the
> X sequencer support LV2 plugins?". So, I think we'd do a good service to our
> users by grouping audio hosts and plugins by features they do provide. [1]

Debtags are very suitable for answering such questions.  There does
not appear to be any tag currently for “uses lv2 interface” but that
is easily fixed, and many plugins are otherwise tagged appropriately
already.


--
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/CAN3veRe2KPW+g-oWHjnrH0VCT=qrdxsddd5as-cb_+udz9u...@mail.gmail.com

Re: Adoption of Nix?

[Daniel Hartwig]

Hello

Just some quick notes related to this, without jumping in to the
discussion (yet?).


On 24 February 2013 01:28, John Moser  wrote:
>
> Daniel Burrows  debian.org> writes:
>
>>
>
> Note:  I'm not subscribed to the list, and pulling this old thread through
> Gmane; please CC directly to me.
>
> The purpose of this is to cross-examine Daniel's thoughts and bring new
> thoughts to the surface.

Daniel Burrows is not active in Debian for some time, and should perhaps
not be expected to partake in the resumed discussion.

> I'll put the main proposal up front:
>
> I feel that being able to install multiple system profiles with dependency
> resolution is a good feature--i.e. the feature of Nix that lets one program
> see /usr/lib (or what is effectively its /usr/lib) as something entirely
> different from what another program sees.
>
> It shouldn't be a core, absolute feature.
>
> Instead, I think it's best to find the least-effort way to modify dpkg so that
> it:
>
> 1)  Can handle running on a system managed like this; and
> 2)  Provides an API to extend dpkg/apt to function this way
>
> In other words, add the capability for a plug-in that changes the way packaged
> files are stored and managed, and let somebody else hook up to the glue code
> and make it happen.  Don't break Debian for the rest of us.

Nix operates fairly indepently of the underlying system.  There is no
pressing need for dpkg–nix integration at this point, indeed, that is
a can of worms.  To briefly illustrate:

Debian packages are each built with specific configurations (enabled
features, etc.), call this a build profile.  When one Debian package
declares a dependency on an other, it is with the implicit knowledge
that a particular build profile or feature set is provided.

Nix allows multiple builds of the same package–version to be installed
with different, and arbitrary build profiles, and allows other
packages to depend on exactly the features they require in the
profile.

Without a map from Debian package–version to build profiles, there is
no way to reliably know whether a particular Nix build either
satisfies a Debian package dependency, or has one of its dependencies
satisfied by an installed Debian package.  For this reason, I believe
it is not viable to integration Nix and dpkg, and the two should be
thought of as independent systems: dpkg has installed your main (or
base) system, and a user is free to layer any Nix packages on top.
Nix packages installed in per-user profiles will not generally
interfere with Debian packages.

Unfortunately, there will be some waste as Nix duplicates a small set
of base dependencies (gcc, etc.).  Though you could avoid this with a
nix-base package that depends on the equivalent Debian packages and
provides Nix the information that certain
package–version–build-profiles are installed.

>
> That would appropriately increase aji and leave open many possibilities for
> the future.

aji?

>
> (For what it's worth, I don't like the direction Nix went in.  Stick to
> managing packages and system layout; Nix goes all the way out to managing your
> configuration file CONTENTS, which among other things makes it completely
> useless in serious production cases--Nix wants to live in its own, rigid 
> little
> world and not play well with others at all).
>

Right.  A good reason to keep it separate.

>
>>   Hi there.  As I'm sure everyone knows, I'm not exactly unbiased here
>> since I've done a lot of work on the apt system (although nix looks more
>> like a replacement for dpkg).

Since this old discussion there is now also Guix
 constructed on top of Nix that
provides some nicer interfaces.  Think of it as operating at the apt
level, I suppose.

Thats all for now.


--
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/can3verdqjuemc7c87dzechrv9az7t+kwupa4b+59q0cjyh3...@mail.gmail.com

Re: Adoption of Nix?

[Daniel Hartwig]

On 24 February 2013 08:56, John Moser  wrote:
> Right, and that's why I proposed manipulating Apt and Dpkg such that they
> can understand and behave within a system with multiple installed versions
> managed in various places.

Thanks for clarifying so promptly.


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

Re: needing sponsor for blt: am I at that stage?

[Daniel Hartwig]

On 2 March 2013 00:12, Paul Johnson  wrote:
> Hello,
>
> Its me again.  Once again, I'm throwing myself on your mercy because
> although I like programming and packaging, I am having a horrible time
> finding my way through your web pages to adopt a package and keep it
> up to date.
>
> So far I have succeeded in declaring the ITP on the blt packages and
> built the package.  In the changelog I inserted the declarations that
> close the wnpp bug and the other blt-related bugs, like so:

You properly want debian-ment...@lists.debian.org, redirecting there.

>
>
> blt (2.4z-6) unstable; urgency=normal
>
>   * Closes: #664092
>   * Closes: #524149
>   * Closes: #636629

Normally your changelog should present each of these in the same entry
as some information on how each is closed.  For example, if the first
one is the ITA:

  * New maintainer.  Closes: #664092

> I don't see the package yet on http://mentors.debian.net/,

That can take up to half an hour.

Regards


-- 
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/CAN3veReYmftBE0aVJ7q8vvbtxX=np+hkp1be7_aig1d1gz8...@mail.gmail.com