Re: DEP-14: renaming master to main?

[Daniele Nicolodi]

On 24-06-2020 12:56, Gunnar Wolf wrote:
> Colin Watson dijo [Mon, Jun 22, 2020 at 10:13:31PM +0100]:
>> I think my ranked preferences are:
>>
>>  1. devel (for the sorts of reasons smcv@ gave; also, debian/devel is a
>> nice allusion to this list)
>>  2. trunk (historical familiarity from other VCSes)
>>  3. main or maybe mainline (some tab-completion similarity to master,
>> though the confusion with components in a Debian context is
>> unfortunate)
> 
> I never really understood the word "trunk" when I used older
> VCSes... Because, as a non-native English speaker, I always understood
> "trunk" as the part of the car you store stuff in.
> 
> The "right" meaning is quite obvious, and it makes much more sense
> when expressed together with "branches": What in Spanish we call
> "tronco" (should be a giveaway! How come I never understood it
> before?), the core part of a tree. Thing is, in English I always used
> the word "stem" for it.
> 
> I'm only sending this message to help explain the term to other people
> who might find it odd. So, a DVCS is a tree, and you can follow the
> _trunk_ to find its "core" or "main" development direction.
> 
> There are many _branches_ splitting, first from the trunk itself, then
> from other branches.
> 
> So, trunk makes quite a bit of sense for me in that light.

Just a though inspired by Gunnar email.

I am not a native English speaker and I should admit that I always felt
cold about the discomfort people reported in the use of loaded terms
such as slave/master. I am a physicist and those terms are used a lot in
the literature and they always felt "normal". So normal that it is
common practice to use these English words in technical communication
also in my native language.

Recently I started translating them in my head into my native language
every time I read them. I felt immediately different and I felt ashamed
I contributed to support their used in many articles I wrote.

These English words are used so often in a metaphoric sense that my
brain registers the neologism as the main meaning rather than the other
way around. I feel think kind of normalization of the terms worrisome.

I am trying to understand if a similar mechanism exists for the
perception of gender pronouns (another issue I feel I am not completely
understanding, despite wrongly identifying my gender from my name is a
fairly common occurrence) for persons whose native language has gender
for all pronouns (usually assigned in what may seem a random way) and
thus the fact that there is a gender associated with personal pronouns
is somehow diluted I haven't come to a conclusion yet.

Cheers,
Dan

Re: Rethinking tensorflow build (taking shortcuts)

[Daniele Nicolodi]

On 04-10-2019 10:04, Mo Zhou wrote:
> The only officially supported build system for Tensorflow is
> bazel[1], which is not present in our archive due to some reasons.

For those not following closely, can you please point to the reasons why
bazel (cannot?) is (yet?) packaged for Debian?  I recently pumped into
another software that proposes to use bazel as its build system, thus I
would like to be aware of any problems with it.

Thanks!

Cheers,
Dan

Re: @debian.org mail

[Daniele Nicolodi]

On 03/06/2019 09:37, Sam Hartman wrote:
> I'd much rather pay money and allow members who do want to use their own
> infrastructure to do so rather than set up an SPF record and force
> everyone to go through the debian mxes.

Pay money for which service exactly? I am not aware of any widely
deployed whitelist that filters on source address, which I think would
be the only solution that would allow members to use their own
infrastructure.

Cheers,
Dan

Re: usrmerge -- plan B?

[Daniele Nicolodi]

Hello Adam,

On 23/11/2018 08:19, Adam Borowski wrote:
> On Fri, Nov 23, 2018 at 03:14:44PM +0100, Matthias Klumpp wrote:
>> Am Fr., 23. Nov. 2018 um 14:47 Uhr schrieb Stephan Seitz
>> :
>>>
>>> On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote:
 If there are actual issues encountered, we can always revert a change
>>>
>>> And how do you revert this change? As far as I have understand you can’t
>>> remove the usrmerge package and have your system in the old state again.
>>
>> You don't - it's unstable, for testing these things. If it breaks, you
>> file a bug and fix the system.
> 
> Fix -- not completely restore from backups.  This is not an option with
> usrmerge; we have severity:critical for bugs with such a fallout.

I've seen this repeated multiple times in this thread, where does your
assessment that the usrmerge package can leave the system in a non
working state comes from?

In my experience, usrmerge stops the merge if it encounters some
unforeseen difficulty and hints to how to resolve the problem. Once the
problem has been resolved, usrmerge can be run again and it will pick up
from where it left.

Is your experience different? Can you be more precise on the kind of
errors or system breakage you encountered?

Thank you.

Best,
Daniele

Re: New layout of debtags.debian.org

[Daniele Nicolodi]

On 8/14/18 5:35 AM, Enrico Zini wrote:
> Hello,
> 
> I have ported debtags.debian.org to Bootstrap 4, it should now be
> easier for development, and work better on mobile devices.
> 
> Let me know if you like it, or if I broke something.

The link to the source code points to the defunct
https://anonscm.debian.org/cgit/debtags/debtagsd.git

Cheers,
Dan

Re: Should the weboob package stay in Debian?

[Daniele Nicolodi]

On 7/18/18 7:03 AM, Marc Dequènes (duck) wrote:
> It has been brought to my attention that this package, its name and the
> name of the binaries and further content was deemed offensive. This was
> already raised in the past (~2012 IIRC) but the package was reintroduced
> and has been in the archive since then.
> 
> Since this is a childish naming which was not intended at being
> insulting, I gave a hand to package this useful tool. I would have
> preferred it renamed though.
> 
> This thread is about giving your opinion and discussing with upstream
> about it, and us DD to decide the fate of this package. I hope this
> would help draft proper policy criteria about what we consider not
> acceptable.

Shouldn't liboobs be removed or renamed too, for the same reasons?

And those other packages too:

buthead
butteraugli
assimp
...

Cheers.
Dan

Re: Versioned dependencies and maintainer scripts

[Daniele Nicolodi]

Thanks Simon for the clarification.

On 6/25/18 1:04 AM, Simon McVittie wrote:
> On Sun, 24 Jun 2018 at 17:05:54 -0600, Daniele Nicolodi wrote:
>> Packages that will use dh_installsystemduser will have maintainer
>> scripts that will depend on the next relese of init-system-helpers.
>> dh_installsystemduser will then inject a versioned dependency using the
>> ${misc:Depends} substitution in debian/control.
>>
>> Is that enough to ensure that postinst and postrm maintainer scripts are
>> run with the right version of init-system-helpers available?  Should I
>> be using Pre-Depends instead?
> 
> https://www.debian.org/doc/debian-policy/#summary-of-ways-maintainer-scripts-are-called

I read that, but I was not sure if my interpretation was right. Indeed,
my conclusions were different.

> For the postinst, you can rely on the updated init-system-helpers being
> at least unpacked (which should be enough, because i-s-h is Essential,
> so it's required to provide its core functionality while merely unpacked
> and not yet configured).
> 
> The difference for Pre-Depends is that it would give you the ability to
> assume that i-s-h has been configured (fully installed) before your
> postinst runs. I don't think you need that here.
> 
> In the postrm, you can't normally rely on having your package's
> dependencies still installed, but init-system-helpers is Essential so
> it should still be there, and we don't officially support downgrades so
> i-s-h should still be at least the required version.

Only tangentially related: does that mean that we can drop the checks
for the presence of deb-systemd-helper in the postrm maintainer scripts
injected by dh_installsystemd (for example [1]) and simplify them a bit?

> Most packages do the more involved parts of their removal in the prerm.
> Is that feasible here?

I'm not sure. I'm probably not aware of all the intricacies involved in
writing robust maintainer scripts, thus I modelled dh_installsystemduser
after what dh_installsystemd does. The maintainer scripts code blocks
injected by dh_installsystemd stop services in prerm and deactivate them
in postrm, but I don't know if there is a technical reason for that.

The code blocks injected by dh_installsystemduser do not start or stop
services, and I don't see a reason why disabling the services could not
be done in prerm. The relevant maintainr script code block is here [2].

Thanks.

Cheers,
Dan


[1]
https://salsa.debian.org/debian/debhelper/blob/master/autoscripts/postrm-systemd
[2]
https://salsa.debian.org/debian/debhelper/merge_requests/5/diffs?commit_id=163d0b663f75071e6710016960db8581012f4c9c#618769df15efa903bfb94d164eacef2166af740c

Versioned dependencies and maintainer scripts

[Daniele Nicolodi]

Hello,

I'm adding dh_installsystemduser to debhelper, to support user instance
systemd units, similarly to what dh_installsystemd does for system
unists. For doing so I had to extend deb-systemd-helper from the
init-system-helper package to handle user units. User units support will
hopefully be released with the next release of init-system-helpers.

Packages that will use dh_installsystemduser will have maintainer
scripts that will depend on the next relese of init-system-helpers.
dh_installsystemduser will then inject a versioned dependency using the
${misc:Depends} substitution in debian/control.

Is that enough to ensure that postinst and postrm maintainer scripts are
run with the right version of init-system-helpers available?  Should I
be using Pre-Depends instead?

Thanks.

Cheers,
Dan

Re: [Alioth-staff-replacement] alioth deprecation - next steps

[Daniele Nicolodi]

On 26/04/2018 02:42, Andrej Shadura wrote:
> On 26 April 2018 at 10:21, Alexander Wirt  wrote:
>> On Thu, 26 Apr 2018, Andrej Shadura wrote:
>>
>>> Could the steps including taking VCS repos offline be offset by at
>>> least two months? There are too many packages not yet migrated to
>>> Salsa or to Git in general, and completing that by the end of May is
>>> putting too much pressure on the maintainers.
>>
>> Nope, we announced that months, if not years ago.
> 
> That doesn’t seem like a reasonable reply. What was announced is one
> thing, but the plans have to be adjusted to the reality, which is that
> you cannot switch off the VCS hosting by the end of May.

Can you please elaborate on what exactly is blocking those projects to
migrate right away?  I think 5 weeks is a reasonable time to do the
migration and I haven't seen any call for help from maintainers that
feel overwhelmed by the task.  I volunteer to help migrate non-Git
repositories to Git, if that can be of any help.

Cheers,
Dan

Re: Bug#895928: ITP: python-base58 -- base58 encode/decode for Python

[Daniele Nicolodi]

On 4/18/18 5:58 AM, Joel Cross wrote:
> On Tue, 17 Apr 2018, at 6:25 PM, Daniele Nicolodi wrote:
>> On 4/17/18 8:57 AM, Joel Cross wrote:
>>> Package: wnpp
>>> Severity: wishlist
>>> Owner: Joel Cross <joel+debb...@kazbak.co.uk>
>>>
>>> * Package name: python-base58
>>>   Version : 0.2.5
>>>   Upstream Author : David Keijser <keij...@gmail.com>
>>> * URL : https://github.com/keis/base58
>>> * License : MIT
>>>   Programming Lang: Python
>>>   Description : base58 encode/decode for Python
>>>
>>> This package contains the following functions, in a form compatible with 
>>> that
>>> used by the bitcoin network:
>>> - b58encode
>>> - b58decode
>>> - b58encode_check
>>> - b58decode_check
>>
>> Hi Joel,
>>
>> I had a look at this Python package a while ago, and I was very
>> surprised to find that its interface does not match the one of the
>> functions in the base64 standard library module in the use of strings vs
>> bytes.  I had to introduce some wrappers to make it sane in that regard.
>>
>> I see in the upstream repository some commits that suggest that this has
>> been fixed (breaking the API probably).  However, nothing that hints
>> that a release has been made after that.
>>
>> It would be nice to have the fixed version in Debian and to avoid API
>> breakage, at least once the Python package enters the Debian archive.
>>
>> Cheers,
>> Dan
> 
> Thanks Dan. I assume you're referring to the
> https://github.com/keis/base58/issues/15 issue? (Output is string,
> not bytes)

Hi Joel,

I think so, but I'm not sure that is the only deviation from the base64
API. I can have a look later at the wrapper I wrote to adjust the API,
if I still have them, I may have simply rewritten the functions. But it
should not be hard to check that `b58encode` and `b58decode` behave the
same as their base64 counterparts.

Cheers,
Dan

Re: Bug#895928: ITP: python-base58 -- base58 encode/decode for Python

[Daniele Nicolodi]

On 4/17/18 8:57 AM, Joel Cross wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Joel Cross 
> 
> * Package name: python-base58
>   Version : 0.2.5
>   Upstream Author : David Keijser 
> * URL : https://github.com/keis/base58
> * License : MIT
>   Programming Lang: Python
>   Description : base58 encode/decode for Python
> 
> This package contains the following functions, in a form compatible with that
> used by the bitcoin network:
> - b58encode
> - b58decode
> - b58encode_check
> - b58decode_check

Hi Joel,

I had a look at this Python package a while ago, and I was very
surprised to find that its interface does not match the one of the
functions in the base64 standard library module in the use of strings vs
bytes.  I had to introduce some wrappers to make it sane in that regard.

I see in the upstream repository some commits that suggest that this has
been fixed (breaking the API probably).  However, nothing that hints
that a release has been made after that.

It would be nice to have the fixed version in Debian and to avoid API
breakage, at least once the Python package enters the Debian archive.

Cheers,
Dan

Re: ed25519 keys and mentors.d.n

[Daniele Nicolodi]

On 4/9/18 7:45 AM, Ian Jackson wrote:
> (dropping -mentors)
> 
> Mattia Rizzolo writes ("Re: ed25519 keys and mentors.d.n"):
>> On Sun, Apr 08, 2018 at 04:41:32PM -0600, Daniele Nicolodi wrote:
>>> I guess the infrastructure has not been upgraded to GnuPG 2.
>>
>> Yes, when we upgraded the host 1,5 months ago we tried also moving to
>> gpg2, but that wasn't as straightforward as we'd hoped…
>> So, we've installed gnupg1 and changed the binary used.
> 
> Unfortunately, moving from gpg1 to gpg2 is, in general, hard.
> 
> gpg2 has a much more complicated architecture, with pet daemons, et
> al, which makes serious complications for calling programs.  This new
> more complicated architecture is also plagued with bugs, including
> races.  Furthermore, upstream's handling of those bugs has left
> something to be desired.

At the same time gpg2 (and modern ssh implementations) can do gpg agent
forwarding, which is straight forward to setup, and I find to be a great
feature to use gpg in virtual machines, containers, remote hosts,
without having to fiddle with my private keys, and potentially to use
gpg tokens remotely (but I don't have one of those, thus I haven't tried
it yet).

Also, I have a few simple automated processes that use gpg to sign and
encrypt some messages (still using the gpg binary, without the gpgme
library), and the transition from gpg1 to gpg2 has been painless.
Although, I admit, those do not do anything fancy.

Cheers,
Dan

Re: ed25519 keys and mentors.d.n

[Daniele Nicolodi]

On 4/8/18 5:54 PM, Georg Faerber wrote:
> Hi,
> 
> On 18-04-08 17:29:17, Daniele Nicolodi wrote:
>> On 08/04/2018 17:10, Mattia Rizzolo wrote:
>>> On Sun, Apr 08, 2018 at 04:41:32PM -0600, Daniele Nicolodi wrote:
>>>> I just tried to upload a package to mentors.debian.net and it got
>>>> rejected because is is signed with an ed25519 key:
>>>>
>>>> gpg: Signature made So 08 Apr 2018 22:00:14 UTC using ? key ID C18A4F7D
>>>> gpg: Can't check signature: unknown pubkey algorithm
>>>>
>>>> I guess the infrastructure has not been upgraded to GnuPG 2.
>>>
>>> Yes, when we upgraded the host 1,5 months ago we tried also moving
>>> to gpg2, but that wasn't as straightforward as we'd hoped… So, we've
>>> installed gnupg1 and changed the binary used.
>>>
>>> Patches welcome, as usual :)
>>
>> I can look into that. What code needs to be patched?
> 
> Have a look at [1] to begin with.

At a first look that code can be updated to use pgpme and do not call
out to a gpg binary.  I'll give it a try.  Just to be sure, is the code
supposed to be run with the libraries in stable?

Cheers,
Dan

Re: ed25519 keys and mentors.d.n

[Daniele Nicolodi]

On 08/04/2018 17:10, Mattia Rizzolo wrote:
> On Sun, Apr 08, 2018 at 04:41:32PM -0600, Daniele Nicolodi wrote:
>> I just tried to upload a package to mentors.debian.net and it got
>> rejected because is is signed with an ed25519 key:
>>
>> gpg: Signature made So 08 Apr 2018 22:00:14 UTC using ? key ID C18A4F7D
>> gpg: Can't check signature: unknown pubkey algorithm
>>
>> I guess the infrastructure has not been upgraded to GnuPG 2.
> 
> Yes, when we upgraded the host 1,5 months ago we tried also moving to
> gpg2, but that wasn't as straightforward as we'd hoped…
> So, we've installed gnupg1 and changed the binary used.
> 
> Patches welcome, as usual :)

I can look into that. What code needs to be patched?

Cheers,
Dan

Re: Systemd user instance equivalent of dh_systemd_enable?

[Daniele Nicolodi]

Hi Simon,

I'm dropping debian-mentors@d.o from the recipients list as I think it
the discussion is not relevant for that list anymore.

On 08/04/2018 16:20, Simon McVittie wrote:
> On Sun, 08 Apr 2018 at 08:26:13 -0600, Daniele Nicolodi wrote:
>> the package is dbus-broker, a replacement for dbus-deamon. You may have
>> heard of it: there has been a short exchange about its packaging for
>> Debian with its developers with the Debian dbus maintainers in Cc.
> 
> Sorry, I didn't see that conversation until now. Please use the role address
> @packages.debian.org if you want to reach package maintainers:

Will do, thanks. I thought I added all maintainers individual addresses
at some point in the discussion, but probably I didn't...

> If dbus-broker is uploaded to Debian as an optional dbus-daemon
> replacement, it will definitely need to be coordinated with the dbus
> source package. Having the two packages coexist is probably not going to
> be straightforward to set up, and if any diversions, alternatives etc.
> are going on, all maintainers of the dbus package will need to be aware
> of them.

I have the package ready, and it works fine without any diversion,
alternatives or other trickery.  It has been surprisingly easy, indeed.
You can get the package here:

https://salsa.debian.org/dnn-guest/dbus-broker

It works fine minus replacing dbus-deamon for the user bus, which
prompted the email at the origin of this thread.  It needs to be done
manually (see README.Debian) or installing a

/etc/systemd/user/dbus.service

symlink. I don't know what's the best strategy, yet.

I'm happy to work with the dbus maintainers to fix any issue.

Incidentally, I will be looking for a sponsor to upload the package to
unstable as soon as I figure out how to solve the above minor issue. It
would be great if someone among the dbus maintainers could act as sponsor.

> I do not expect that dbus-broker will be compatible with every D-Bus
> service in Debian. The one incompatibility that I'm reasonably sure exists
> is that if the Exec= for an activatable service points to a command that
> will fork (background itself) and exit 0, dbus-daemon tolerates this
> (at the cost of worse error behaviour because it cannot tell whether
> the service subsequently fails), while dbus-broker almost certainly does
> not. This is inadvisable behaviour even with the reference dbus-daemon,
> so I'd consider it to be a bug in the service, but unfortunately it can't
> be detected statically.

That would need to be investigated indeed.  So far the package works
well on a couple of very minimal installs I tried it on.

Thanks!  Cheers,
Dan

ed25519 keys and mentors.d.n

[Daniele Nicolodi]

Hello,

I just tried to upload a package to mentors.debian.net and it got
rejected because is is signed with an ed25519 key:

gpg: Signature made So 08 Apr 2018 22:00:14 UTC using ? key ID C18A4F7D
gpg: Can't check signature: unknown pubkey algorithm

I guess the infrastructure has not been upgraded to GnuPG 2.

I know that elliptic curve cryptography is a bit bleeding edge but I
thought that GnuPG had support for it for long enough to make it safe to
use it in the context of Debian.  Does this limitation apply only to
mentors.d.n or does it apply to the Debian infrastructure in general?

/me generates a new signing subkey...

Cheers,
Dan

Re: Systemd user instance equivalent of dh_systemd_enable?

[Daniele Nicolodi]

On 08/04/2018 05:28, Simon McVittie wrote:
> On Sat, 07 Apr 2018 at 18:18:11 -0600, Daniele Nicolodi wrote:
>> I'm working on a package that installs a systemd user instance unit file
>> that needs to be enabled with
>>
>> # systemctl --global enable foo.service
> 
> I believe the only way to do this is currently to make
> it be statically enabled for all users (ship a symlink in
> /usr/lib/systemd/user/${something}.wants).
> 
> What is the package?
> 
> Is it something that all users are going to want?>
> Is it something that makes sense to run every time any user logs in in
> any way (ssh, console login, graphical login) or only on entry to a
> graphical session?
> 
> Would it make sense to arrange for it to be socket-activated (like
> dbus-user-session, gpg-agent, pulseaudio) or D-Bus-activated (like
> gnome-terminal-server) or autostarted on login to a graphical session (via
> /etc/xdg/autostart), rather than being started eagerly on every login?
> 
> (The way packages like dbus-user-session, gpg-agent and pulseaudio set
> themselves up for socket activation is to have their *.socket unit be
> statically enabled in sockets.target, but not their *.service unit in
> default.target.)

Hi Simon,

the package is dbus-broker, a replacement for dbus-deamon. You may have
heard of it: there has been a short exchange about its packaging for
Debian with its developers with the Debian dbus maintainers in Cc.

dbus-broker ships an user instance unit file with this Install section:

[Install]
Alias=dbus.service

with

# systemctl --global enable foo.service

a /etc/systemd/user/dbus.service symlink is created that overrides the
unit installed by dbus-daemon obtaining that dbus-broker "takes over"
the bus activation units installed by dbus-daemon. A similar thing is
done for the system bus, but that is taken care of by dh_systemd_enable
just fine.

I can create the link manually.

Cheers,
Dan

Re: Systemd user instance equivalent of dh_systemd_enable?

[Daniele Nicolodi]

On 08/04/2018 00:59, Jochen Sprickerhof wrote:
> Hi Daniele,
> 
> * Daniele Nicolodi <dani...@grinta.net> [2018-04-07 18:18]:
>> I'm working on a package that installs a systemd user instance unit file
>> that needs to be enabled with
>>
>> # systemctl --global enable foo.service
>>
>> Using debhelper, dh_systemd_enable takes care of this automatically for
>> system unit files, but not for user unit files.  Is there some other
>> (semi)automatic way of doing it or should I take care of it manually in
>> the postinst and prerm maintainer scripts?
> 
> I use User= in the [Service] section of the service file for 
> that.

That does something radically different. I would like to operate on
units for the user systemd instance, not for the system instance.

Cheers,
Dan

Systemd user instance equivalent of dh_systemd_enable?

[Daniele Nicolodi]

Hello,

I'm working on a package that installs a systemd user instance unit file
that needs to be enabled with

# systemctl --global enable foo.service

Using debhelper, dh_systemd_enable takes care of this automatically for
system unit files, but not for user unit files.  Is there some other
(semi)automatic way of doing it or should I take care of it manually in
the postinst and prerm maintainer scripts?

Thanks! Cheers,
Dan

Re: Bug#894369: ITP: egpg -- Wrapper tool to easily manage and use keys with GPG

[Daniele Nicolodi]

On 29/03/2018 15:54, Yago González wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Yago González 
> 
> * Package name: egpg
>   Version : 2.1
>   Upstream Author : Dashamir Hoxha 
> * URL : https://github.com/dashohoxha/egpg
> * License : GPL-3
>   Programming Lang: Shell
>   Description : Wrapper tool to easily manage and use keys with GPG
> 
> Easy GnuPG (egpg) is a wrapper script that tries to simplify the process of
> using GnuPG. In order to make things easier, it is opinionated about the
> "right" way to use GnuPG.
> 
> It helps manage (e.g. generate, revoke...) the keys as well as use them
> to verify, sign and encrypt messages.
> 

The last time Easy GnuPG has been discussed on the GnuPG mailing list:

thread starting around this message

https://lists.gnupg.org/pipermail/gnupg-users/2016-April/055835.html

and later

https://lists.gnupg.org/pipermail/gnupg-users/2016-May/056007.html

Easy GnuPG was not deemed ready for end users, and technical issues with
the code were identified.  I think including it in Debian is akin to
recommend it and somehow a statement on its technical cryptographic
validity.

It seemed that people on the GnuPG mailing list were not too
enthusiastic about reviewing it.  Has something changed since then?  Is
there an (informal) evaluation of the code or of the project in general
from a third party?

Cheers,
Daniele

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Daniele Nicolodi]

On 23/03/2018 17:04, Ole Streicher wrote:
> Why can't we have a flat name space with redirection
> 
> https://git.debian.org/
> 
> (or similar) that just redirects to the proper real location within salsa?
> Our source package names are unique, so there should be no conflicts.
> 
> That would make the discovery of a certain package *much* easier than
> the current structured approach.

Isn't this in essence the idea at the base of the Vcs- fields in
debian/control?  Namely providing an universal way to map from packages
to repositories independently of where they are hosted?

Cheers,
Daniele

Re: un pensiero sul libro di Martin Kraft

[Daniele Nicolodi]

On Wed, Jun 29, 2005 at 01:15:44PM +0200, Mauro Darida wrote:

 Tra poter scaricare il libro e tutti i diritti riservati ci sono tante vie 
 di mezzo: sicuramente saprai che è l'autore che decide se togliere tutti i 
 diritti all'utente (come ha fatto Kraft) o dargliene solo alcuni (per es. 
 permettere almeno di fotocopiare il libro per scopi non commerciali).
 Kraft ha usato la licenza più restrittiva di tutte: quella che non concede 
 nulla ( a rigore il suo libro non si potrebbe neanche prestare).

Ma non diciamo fesserie!!

Ciao
-- 
Daniele

   Physics is like sex. Sure, it may give some practical results, but
   that's not why we do it. -- Richard P. Feynman


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: un pensiero sul libro di Martin Kraft

[Daniele Nicolodi]

On Wed, Jun 29, 2005 at 02:14:07PM +0200, Marco Bertorello wrote:

   Kraft ha usato la licenza più
   restrittiva di tutte: quella che non concede  nulla ( a rigore il
   suo libro non si potrebbe neanche prestare).
  
  Ma non diciamo fesserie!!
 
 Scusa Daniele, ma non capisco cosa ci sia di sbagliato in quanto
 affermato da Mauro. Potresti spiegare?

In Italia (e credo in moltissimi altri paesi) qualsiasi pubblicazione
e` prestabile (altrimenti come esisterebbero le biblioteche ?) e
riproducibile per uso personale almeno in parte. E' anche riproducibile
in parte (piccola) a patto di citarne la fonte.

Detto questo non capisco lo scalpore. Si e` sempre detto che si puo`
vivere di software libero facendosi pagare i servizi e non il codice.
Poi quando uno scrive un libro investendo il suo tempo e cerca di
venderlo in modo da poter continuare a produrre software libero lo si
accusa di incoerenza... secondo me l'incoerenza e` da qualche altra
parte.

Ciao
-- 
Daniele

   Physics is like sex. Sure, it may give some practical results, but
   that's not why we do it. -- Richard P. Feynman


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]