Re: New project goal: Get rid of Berkeley DB (post jessie)

[Adrien CLERC]

Le 19/06/2014 11:38, Ondřej Surý a écrit :
> List of affected maintainers follows:
>
> Loic Minier 
>evolution-data-server (U)
>rpm (U)
>
I am just a simple user of rpm. Yes, I use rpm for inspecting,
debugging, and so on. I don't use it for managing packages on my Debian
box, but I guess that removing BerkeleyDB from rpm is not an option. If
I'm wrong, I'll be glad to hear it :)

Adrien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53a2bae8.2040...@antipoul.fr

Re: Can a leaf package require SSE2 on i386?

[Adrien Clerc]

Le 14/09/2014 08:47, Sébastien Villemot a écrit :
> So I have two options: either ship a i386 package that only works on
> SSE2 processors (ideally giving a meaningful error message when run on
> older CPUs); or drop support for i386, which is a disservice to our
> users (the few who have a SSE2-capable but not x86-64-capable processor
> will be left out; and those who are running the i386 arch on a
> x86-64-capable processor will have to cross-grade to amd64 or at least
> use multi-arch with a 64-bit kernel).
>
I'm in the category of people who installed their Debian 8 years ago, on
an old AMD processor, only i686. My hardware was upgraded since, but the
system remains. I've searched for cross-grade, but nothing serious comes
out, except "reinstall everything". If you have some clear documentation
(at least some steps, I'm curious enough to read some apt manuals), I
think you can go on dropping i386 architecture.
Otherwise, even if I'm not a julia user, I'll be really sad to see a
package lost only because SSE2 is needed.

Adrien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5415a8ce.1020...@antipoul.fr

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Adrien CLERC]

And SysVInit just works well and it is simply enough. It has much less 
dependencies than systemd. Do not make unneeded weight on people to learn 
systemd in addition to shell scripts, if systemd is powerful that also means 
there is a lot to learn. I really doubt non-standards task can be solved with 
systemd without shell scripts (or similar), and every serious UNIX admin must 
know shell programming anyway.

This is like saying "A horse drawn carrage works well enough, why do you
need an airplane".

You need an airplane because Earth is 40,000 km in round and because you have a 
reason to travel to a distant location. Or just you want to do some sport? But 
I know my possibilities and I wouldn't spend my money on an airplane just for 
sport, to produce an airplane you have to take raw materials out of this 
planet, you have to spend power, human time, make pollution, etc.

That's exactly how I feel when I want to create a small daemon using a 
SystemV init script. I feel like building an airplane from scratch while 
I would just use a bike.


Introducing the concept of "possibilities" is interesting: sometimes, 
you need some choices in your available tools to perform the same task, 
depending on your current need…


Adrien


--
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/527a3e75.5050...@antipoul.fr

Re: Debian Developers team in Launchpad

[Adrien CLERC]

Le 17/12/2013 12:44, Tae Wong a écrit :

You've asked Launchpad Feedback to restore seotaewong40 but the
account remains suspended.

Please remove your ban for the account in Mozilla Bugzilla
(seotaewong40) as well.



Tae Wong, how do you prefer to eat? Sitting on a chair or on the ground?
By the way, I think you forgot your sunglasses last time we met in South 
Pole. You could have them back, but only if you told me how to make 
broomsticks fly. Is it OK for you?



--
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/52b05413.1090...@antipoul.fr

Re: Bug#727708: init multiple instances of a daemon

[Adrien Clerc]

Le 23/12/2013 00:37, Zbigniew Jędrzejewski-Szmek a écrit :

It looks like both upstart and systemd don't provide direct mechanisms to
manage all instances.

That's true (I'm only speaking about systemd). There have been requests for
such functionality before, but nothing was implemented. But I think we should
revisit this topic... I recently added globbing to a bunch of systemctl verbs
for listing stuff (list-units, list-sockets, etc.), and it was actually
trivial. I felt that allowing globing for verbs that influence state (start,
stop, enable, disable, ...) was too dangerous. But this should be safe for
instance units, so I'd like to see 'systemctl stop/status/... server@*.service'
implemented.

Zbyszek

This could be controlled via a setting inside the unit file, like 
AllowGlobControl, default set to false in template unit files.


Adrien


--
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/52b7e940.2000...@antipoul.fr

Re: ca-certificates: no more cacert.org certificates?!?

[Adrien CLERC]

Le 24/03/2014 14:23, Raphael Geissert a écrit :
>> Anyway, I strongly recommend that nobody waste their time on an issue
>> which in a couple of years will be much less relevant thanks to DANE.
> If only people actually used DNSSEC and DANE - Chromium/Google Chrome dropped 
> support for the latter due to the lack of use[1].
>
> [1]https://www.imperialviolet.org/2011/06/16/dnssecchrome.html
>
Lack of use? No kidding. TLSA RRs have been promoted to IETF proposed
standard in August 2012[1]. And DNS servers haven't support for them
since recently (I'd say 6 months to 1 year).
If I understood correctly, Chromium/Google Chrome only supported DNSSEC
validation. The issue with that kind of protocol is that you must trust
your resolver, or have a resolver on your machine, bypassing any
existing resolver cache of your network provider.
However, I'm using DNSSEC Validator[2] on Firefox for quite a long time,
and I'm very happy with it. I'll be glad to see it merged, so that we
can really get rid of those EV x509 certificates, and be able to provide
secure self-hosting solutions for everyone without big scary warnings.

[1]http://tools.ietf.org/html/rfc6698
[2]https://www.dnssec-validator.cz/

Have a good day,

Adrien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53303829.4020...@antipoul.fr

Re: ca-certificates: no more cacert.org certificates?!?

[Adrien Clerc]

Le 24/03/2014 22:18, Edward Allcutt a écrit :
> I believe you are mistaken. That blog post is about Google's own
> design for "DNSSEC stapled certificates" . Not DANE.
I figured it out after a more careful reading. I forgot about this trial
from Google, that was obviously not used enough to be useful. DANE is
not really used yet, but I think it is easier to setup.

Adrien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5330a4d8.7020...@antipoul.fr

Re: systemd patent fees - who pays?

[Adrien CLERC]

Le 28/03/2014 11:40, Sebastian Feld a écrit :
> Now that Redhat and Suse have been contacted by ORACLE regarding to
> licensing the SMF patents a question arises for Debian:
>
> SystemD violates a couple of patents SUN Microsystems filed for their
> SMF system used in Solaris.
>
> Now, who is going to pay the patent and license fees for each Debian
> installation which uses SystemD?
>
> Seb
No one in Europe. There's no such thing as software patent here. Yet. I
hope this will stay forever.
(And yes, maybe I'm wrong, but please enlighten me!)

Adrien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53355a3f.5040...@antipoul.fr

Re: correct use of su

[Adrien Clerc]

Le 11/05/2014 09:22, Marc Haber a écrit :
>> Systemd (as upstart) sidesteps this problem to a large degree by handling
>> uid switching as a native directive, avoiding the need to call out to a
>> separate command.
> Just out of curiosity: What do I do when I convert an init script that
> parses a mode 600 configuration file (containing passwords), does
> necessary things as root and then starts a non-root daemon to systemd?
> How do I do that with using a "native directive"?
>
In systemd, the ExecStartPre directive can be helpful. But the
documentation doesn't say if it is executed as the user defined in the
User directive, or as root. I guess the latter is done, but I'm too lazy
right now to test it :)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/536f2d21.8070...@antipoul.fr

Re: ITP: bitstring -- Python module for manipulation of binary data

[Adrien Clerc]

Le 30/03/2015 20:50, Ghislain Vaillant a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Ghislain Antony Vaillant  >
>
> * Package name: bitstring
>   Version : 3.1.3
>   Upstream Author : Scott Griffiths  >
> * URL : https://code.google.com/p/python-bitstring/
>
If it's a new package, it shouldn't be hosted on Google Code right now.
Or I'm missing something.

Adrien

Re: Bug#790399: ITP: structlog -- tructured Logging for Python

[Adrien CLERC]

Le 29/06/2015 02:51, Filippo Giunchedi a écrit :
> * Package name: structlog
Hi,

It seems to be a Python library (in the main site, I can read that it is
used as an imported module), it should be named python-structlog.

Have a nice day,

Adrien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55910046.7060...@antipoul.fr

Re: The Spirit of Free Software, or The Reality

[Adrien CLERC]

Le 17/07/2015 12:57, Mike Hommey a écrit :
> On Fri, Jul 17, 2015 at 02:38:12PM +0800, Paul Wise wrote:
>> On Thu, Jul 16, 2015 at 6:17 AM, Mike Hommey wrote:
>>
>>> I, myself, find our DFSG-freeness pickiness going too far, and I'm sick
>>> of this icon thing. So, here's what I'm going to do: unless I hear
>>> non-IANAL objection until the next upstream release due on august 11
>>> (and I'm BCCing the DPL in case he wants to have the SPI lawyer(s) look
>>> into this), I will remove the replacement of the bundled icons with
>>> urls.
>> How about just disabling the icons altogether? They seem unnessecary
>> to me. Removing them would avoid both the potential DFSG issue and the
>> privacy issue.
> Would you dare say this is useful?
> http://i.imgur.com/duKHZKF.png
>
> Mike
>
>
This seems to be the new DFSG game. Pick an icon, and get random results.

Adrien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55a8ef44.7000...@antipoul.fr

Re: The Spirit of Free Software, or The Reality

[Adrien CLERC]

Le 17/07/2015 15:09, Thorsten Glaser a écrit :
> OK, wrong place to complain about RequestPolicy, admittedly.
> It’s just that it’s the only actually effective ad blocker,
> for use by me when lynx, my default webbrowser, isn’t enough.
>
>
Maybe you should try the "I am an advanced user" of uBlock (or uBlock
Origin, it's up to you). It replaces AdblockPlus and RequestPolicy in a
much more efficient UI for me. More complex also…

Adrien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55a90c84.40...@antipoul.fr

Re: Improving your archive and package system for small package

[Adrien CLERC]

Le 03/09/2015 13:36, Bastien ROUCARIES a écrit :
> Hi,
>
> In order to improve node situation we need to improve the small
> packages problems.
>
> What are the main bottlenet ? What could be done to improve the situation ?
>
> The node small package does not change often so it could be a win to
> your archive size.
> Moreover if we could solve this problem we could think about small
> perl package or even tex package.
>
Hi,

This may have been discussed before, but could we achieve something like
this with virtual package?
For example, define virtual packages for every small package
(nodejs-myfunkyoneliner) that is only provided by a bigger package (e.g.
nodejs-libraries1, so we can split those bigger packages), containing a
compilation of those librairies.
Then, another packaged software can just depends on those virtual
packages. The real files will be installed with potentially uneeded
other ones, but it will reduce overhead.

This may be a bad idea, though. I'm not a dpkg expert.

Adrien

Re: CentOS and Debian/Ubuntu release cycles

[Adrien CLERC]

Le 10/12/2020 à 08:05, Marco d'Itri a écrit :

On Dec 10, Joel Wirāmu Pauling  wrote:


is. Binary compat is mostly a thing of the past in modern Rhel due to
containerization. Container tooling in userspace is one of the reasons RH

Cool narrative, but the reality is a bit more complex than that.
Fibre Channel users need very specific kernels or else the hardware
vendors will refuse support (and their vendor drivers will not compile).

For example, my current employee use CentOS for videosurveillance. In a 
lot of locations (100+), we still have analog cameras, that use V4L2 
grabbing cards with an out-of-tree kernel driver that I painfully 
maintain myself (it is unclear if we only have the rights to modify its 
source).


Containers are completely impossible for this use case. And because of 
our decentralized installation, we almost need one server by 
geographical location anyway, so it's a bit useless to have one server 
with two containers.


I also have to admit that I'm a bit tired of this 
containerization-mania. Container orchestration requires a lot of 
tooling, and I guess that selling tools (of support for them) is a valid 
business strategy. But we also have the right to say no to it :)


Adrien

Re: Intel CET Support?

[Adrien CLERC]

Le 05/09/2022 à 22:44, Felix Potthast a écrit :

objdump -d /usr/bin/mv | grep endbr | wc -l


I got 2 on my current Bookworm/testing with 5.18.0-4-amd64

Re: Unlock LUKS with login/password

[Adrien CLERC]

Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :

Hello!

I have an idea about how modern linux should work with encrypted LUKS 
partitions.


Hi,

I'm using LUKS for a long time on both my personal (desktop) and 
professional (laptop) computers. Since they are single user (me), I use 
autologin in the display manager, lightdm in my case. Because there is 
only one slot configured in LUKS, I'm sure this is me, so lightdm can 
autologin safely.


However, you are proposing to solve the case for multiple user 
computers. In that case, I would think about a much simpler design:


- Remember which slot was used to unlock the LUKS root partition

- Make a map with slot -> user to autologin

- Autologin that user on boot

No more passing password, no more password update headache. But only a 
root user can update the map "slot -> user".


Adrien

Re: Bug#841279: ITP: golang-github-gogits-go-gogs-client -- Gogs API client in Go.

[Adrien CLERC]

Le 19/10/2016 à 11:29, Michael Lustfield a écrit :
> * Package name: golang-github-gogits-go-gogs-client
>
Funniest package name I've ever seen. Thanks for that :)

Adrien

Re: Bug#847809: ITP: tcvt -- multicolumn virtual terminal

[Adrien CLERC]

Le 11/12/2016 à 23:39, Ferenc Wágner a écrit :
> * Package name: tcvt
>   Version : git snapshot 82c24e2
>   Upstream Author : Helmut Grohne 
> * URL : http://subdivi.de/~helmut/tcvt/
>From the main page:
Multibyte encodings such as utf8 are not supported, because Python is buggy.

Is that still an issue? I highly doubt that a terminal application that
doesn't support UTF8 is useful nowadays.

Adrien

Re: IPv6 problem for one debian mirror

[Adrien CLERC]

Le 08/02/2017 à 01:05, Vincent Danjean a écrit :
> However, the machine answers to IPv4 connections but not to IPv6
> $ time wget -4 ftp.fr.debian.org
> --2017-02-08 00:53:54--  http://ftp.fr.debian.org/
> Résolution de ftp.fr.debian.org (ftp.fr.debian.org)… 212.27.32.66
> Connexion à ftp.fr.debian.org (ftp.fr.debian.org)|212.27.32.66|:80… connecté.
> requête HTTP transmise, en attente de la réponse… 200 OK
> Taille : 1915 (1,9K) [text/html]
> [...]
> real  0m0,108s
> user  0m0,000s
> sys   0m0,000s
> $ time wget -6 ftp.fr.debian.org
> --2017-02-08 00:53:58--  http://ftp.fr.debian.org/
> Résolution de ftp.fr.debian.org (ftp.fr.debian.org)… 2a01:e0c:1:1598::2
> Connexion à ftp.fr.debian.org (ftp.fr.debian.org)|2a01:e0c:1:1598::2|:80… ^C
>
> real  1m52,272s
> user  0m0,000s
> sys   0m0,000s
> [I did a C-c in the shell to interrupt]
>
> My IPv6 connection is ok for other sites, for example:
>
> $ time wget -6 www.debian.org
> URL transformed to HTTPS due to an HSTS policy
> --2017-02-08 00:57:00--  https://www.debian.org/
> Résolution de www.debian.org (www.debian.org)… 2001:610:1908:b000::148:14, 
> 2001:41c8:1000:21::21:4
> Connexion à www.debian.org (www.debian.org)|2001:610:1908:b000::148:14|:443… 
> connecté.
> requête HTTP transmise, en attente de la réponse… 200 OK
> Taille : 14926 (15K) [text/html]
> [...]
> real  0m1,079s
> user  0m0,012s
> sys   0m0,000s
Hi,

I can only but encourages you to try lower MTU. Here is an example:
ip -6 route change default via fe80::207:cbff:feb1:7dd7 dev eth_adsl mtu
1480

You can also try with a lower value, such as 1456 or 1440.
Yes, the MTU discovery is not working on proxad network, and I don't
know why. Maybe it's my own firewall, I don't know, and I don't have the
time to investigate.

Note however that this might be a peering issue. After all, IPv6 is only
18 years old, it's a young technology preview ;)

Adrien

Re: What can Debian do to provide complex applications to its users?

[Adrien CLERC]

> What do you think? Do you have other ideas? Are there other persons
> who are annoyed by the current situation?
Yes, indeed. I am more a simple user of Debian than a real Debian
Developer, but my feeling is paradoxical.
On one hand, I'd love to see some complex application in Debian, or at
least most of its dependencies.
On the other hand, I can only be angry against people than only release
minified source. The usual answer to this is "performance" or "everyone
does this". The debate has been opened for a long time, but a
minification operation is somewhat like a compilation: it is hard to get
the human readable form from it.
So I'd vote "no" to relax, even if some application are taken out.

As an example, there is this grafana issue on
https://github.com/grafana/grafana/issues/5046. The usual answer:
>  torkelo commented on 15 May 2016
>
> Github source tar has never been 100% comprehensive, Grafana has
> always required "npm install" to build (like most web apps)

This is incredibly dangerous since the build rely on NPM repository
which is far from trusty. And it relies on minified files everywhere,
that break the social contract. I installed Grafana on my Debian/testing
when the package was available, because then I knew it could be trusted.
Now, it is more appealing than before (Grafana is a good software), but
trust has gone away.

It is true that software are harder to review nowadays, because they
rely on lots of libraries. But there is a real difference to me between
"hard" and "impossible".

For the JavaScript world, a solution would require a well-known standard
about minification and optimization. The WebAssembly is coming, and this
will worst.

Re: Bug#891211: ITP: impass -- Simple and secure password management and retrieval system

[Adrien CLERC]

> * URL : https://salsa.debian.org/impass
Is it normal that this URL requires a login? I guess not, but anyway,
this is not as open-source as it should be ;)

Adrien

Re: APT 1.2 preview uploaded to experimental -- please test

[Adrien CLERC]

Le 08/01/2016 22:13, Julian Andres Klode a écrit :
> So roughly speaking, we only take 2/3 of the time now compared
> to 1.1.8 after which I started optimising the code.
>
And I wish to say to you that you made a very good job at this. On my
personal self-hosted server, the difference is huge (Intel(R) Atom(TM)
CPU D2550).

Thank you!

Adrien

Re: Bug#815893: ITP: python-jpy -- Bi-directional Python-Java bridge

[Adrien CLERC]

Le 25/02/2016 13:59, Alastair McKinstry a écrit :
>   Upstream Author : Brockmann Consult GmbH
> * URL : http://www.brockmann-consult.de
>
Hi,
I understand that the author want some credits, but unless I misread the
webpage, there is no mention of this project on it.
It should be better to have a link to https://github.com/bcdev/jpy or
https://pypi.python.org/pypi/jpy/ or http://jpy.readthedocs.org/en/latest/

Adrien

Re: Opt out style recommends

[Adrien CLERC]

Le 08/04/2016 05:49, Harlan Lieberman-Berg a écrit :
> [1]: I say default here, but really, systems which turn off installing
> things which are Recommended are almost unusuable; I know for a while
> it was the policy of #debian to just turn away people who had done
> that because the system would be in such a strange state. Sincerely, 
While I think installing recommended packages by default is a good
choice, disabling it is also a really good option on servers. Installing
every recommended packages is sometimes the best way to bloat your system.

It makes me think I'd love a system where Apt::Install-Recommends could
be set to "ask" and let apt ask me if I want the recommended packages
for my current request.

Adrien

Re: Opt out style recommends

[Adrien CLERC]

Le 08/04/2016 10:10, Neil Williams a écrit :
> On Fri, 8 Apr 2016 09:58:04 +0200
> Adrien CLERC  wrote:
>
>> Le 08/04/2016 05:49, Harlan Lieberman-Berg a écrit :
>>> [1]: I say default here, but really, systems which turn off
>>> installing things which are Recommended are almost unusuable; I
>>> know for a while it was the policy of #debian to just turn away
>>> people who had done that because the system would be in such a
>>> strange state. Sincerely,   
>> While I think installing recommended packages by default is a good
>> choice, disabling it is also a really good option on servers.
>> Installing every recommended packages is sometimes the best way to
>> bloat your system.
>>
>> It makes me think I'd love a system where Apt::Install-Recommends
>> could be set to "ask" and let apt ask me if I want the recommended
>> packages for my current request.
> apt already shows you which packages are to be brought in as Recommends
> on every invocation and unless you use the -y option you get the
> option to quit. You can already choose to quit and call apt with the
> --no-install-recommends option for this specific invocation of apt.
>
This involves a lot of keypresses, and I'm incredibly lazy ;)
I was just wondering if apt could be more interactive, or if it is a
design choice not to ask too many questions.

Adrien

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

[Adrien CLERC]

Le 08/06/2016 à 10:53, Christiaan de Die le Clercq a écrit :
>
> +1
>
> Though I am not involved in this discussion and didn't read a lot of
> previous emails about this. I am going to assume it would be hosted on
> Debian's servers and not with Gitlab's hosted services. We use Gogs at
> the office, a (MIT licensed) Gitlab alternative.
> https://github.com/gogits/gogs
> It might be worth checking out.
>
Let me add another one: GitBlit (http://gitblit.com/) It may not be as
active as others, but it is quite simple, and provide me a huge benefits
over Gogs, since it knows how to handle git repositories created by
third-party on disk. Using Gogs, all git repositories must have been
imported.
It's in Java, and I don't know if the "Pull request" thing is really useful.

Adrien