Re: Apt feature request / suggestion

[Austin Moon]

Than you for the thoughtful reply.

Yes the apt upgrade submit ends there with no further error messages. When
moving that source list it proceeds and asks me if i want to install the
upgrades.

Please help me to understand the MITM scenario. So you're saying an
attacker could be able to redirect all sources except one? Is that even
technically likely? Has that ever happened?

I appreciate you explaining the risk, as I'm trying to understand why.
Please understand that this also prevents unattended upgrades from
proceeding, which aside from a real indication of MITM attack seems like
unnecessarily putting many systems at a security risk. (Also, shouldn't
https be used by default in the main sources list that includes security
repos? Doesn't https prevent MITM?)


Re space checking: I understand estimates are inaccurate. But it seems
better to fail on the side of caution in this instance. To be clear, I'm
not expecting to make waves for so many other users, this could be rolled
out with a flag option like (--check-space). I do think opt out should be
the default though.

I know there are separate partitions, but doesn't the estimation look at
say /boot when a kernel is queued for install? If it knows where to install
packages, it can check those exact locations for free space. (But still
imho better to fail by default)

I would take the conservative side of the estimate, as I've said the
uninstall process can be very complicated, especially when inside a VM with
no other space available. Usually means manually deleting files that upsets
dpkg and then having to reconfigure all that first before making apt happy
again.

I think 1.5GB is reasonable. Doesn't the filesystem not have to be
uncompressed to install? Wouldn't it already be uncompressed during apt
use?

I understand about rolling out in a way to see what possible problems arise
before implementing defaults.


Thank you


On Mon, Oct 10, 2022, 6:56 AM David Kalnischkies 
wrote:

> On Sun, Oct 09, 2022 at 01:21:45PM -0700, xaq xaq wrote:
> > To simplify a frequently seen halt of `apt upgrade` I have this
> example.. I
> > had to remove keepsolidinc.list
> > from /etc/apt/sources.list.d. Then apt update proceeds. Here is the
> error I
> > get with that source list in place:
> >
> > *Hit:1 http://archive.ubuntu.com/ubuntu
> > <http://archive.ubuntu.com/ubuntu> - InRelease
> > Hit:2 http://security.ubuntu.com/ubuntu
> > <http://security.ubuntu.com/ubuntu> --security InRelease
> > Hit:3 http://archive.ubuntu.com/ubuntu
> > <http://archive.ubuntu.com/ubuntu> --updates InRelease
> > Hit:4 http://archive.ubuntu.com/ubuntu
> > <http://archive.ubuntu.com/ubuntu> --backports InRelease
> > Ign:5 http://apt.keepsolid.com/ubuntu
> > <http://apt.keepsolid.com/ubuntu> - InRelease
> > Err:6 http://apt.keepsolid.com/ubuntu
> > <http://apt.keepsolid.com/ubuntu> - Release
> >   404  Not Found [IP: 144.217.71.199 80]
> > Reading package lists... Done
> > E: The repository 'http://apt.keepsolid.com/ubuntu
> > <http://apt.keepsolid.com/ubuntu> - Release' does not have a Release
> > file.
> > N: Updating from such a repository can't be done securely, and is
> > therefore disabled by default.
> > N: See apt-secure(8) manpage for repository creation and user
> > configuration details.*
>
> What do you mean with "halt of `apt upgrade`"? You have shown us output
> of 'apt update'? And that output suggests that the other archives were
> updated (just that they were already current: cache "Hit").
>
> I suppose if the old data still on disk for keepsolid is indicating
> newer versions of packages than you have installed an upgrade would try
> to download them potentially running also into 404 errors (assuming this
> repo is entirely offline). That would indeed "block" upgrades of other
> packages not from that repo, but what is apt supposed to do instead…
> It is asked to upgrade all packages and can't: Partial upgrades are
> technically supported, but hardly tested in practice as it is
> a combinatorial explosion if you tried. So in theory you upgrade from
> a perfectly supported system with updates available to a system with
> unknown support status and still more updates available. That doesn't
> look like a good default move.
>
> You can tell apt to carry on with --fix-missing if that is what you
> desire, but really, you should either remove that repository (and the
> packages coming from it) for good or work with its provider on fixing
> it/making it available again. After all, --fix-missing lets you carry
> on in a pinch, but it remains that the repository fails to serve updates
> to you, which in the worst case means public known security issues remain
> exploita

Re: Apt feature request / suggestion

[David Kalnischkies]

On Sun, Oct 09, 2022 at 01:21:45PM -0700, xaq xaq wrote:
> To simplify a frequently seen halt of `apt upgrade` I have this example.. I
> had to remove keepsolidinc.list
> from /etc/apt/sources.list.d. Then apt update proceeds. Here is the error I
> get with that source list in place:
> 
> *Hit:1 http://archive.ubuntu.com/ubuntu
> <http://archive.ubuntu.com/ubuntu> - InRelease
> Hit:2 http://security.ubuntu.com/ubuntu
> <http://security.ubuntu.com/ubuntu> --security InRelease
> Hit:3 http://archive.ubuntu.com/ubuntu
> <http://archive.ubuntu.com/ubuntu> --updates InRelease
> Hit:4 http://archive.ubuntu.com/ubuntu
> <http://archive.ubuntu.com/ubuntu> --backports InRelease
> Ign:5 http://apt.keepsolid.com/ubuntu
> <http://apt.keepsolid.com/ubuntu> - InRelease
> Err:6 http://apt.keepsolid.com/ubuntu
> <http://apt.keepsolid.com/ubuntu> - Release
>   404  Not Found [IP: 144.217.71.199 80]
> Reading package lists... Done
> E: The repository 'http://apt.keepsolid.com/ubuntu
> <http://apt.keepsolid.com/ubuntu> - Release' does not have a Release
> file.
> N: Updating from such a repository can't be done securely, and is
> therefore disabled by default.
> N: See apt-secure(8) manpage for repository creation and user
> configuration details.*

What do you mean with "halt of `apt upgrade`"? You have shown us output
of 'apt update'? And that output suggests that the other archives were
updated (just that they were already current: cache "Hit").

I suppose if the old data still on disk for keepsolid is indicating
newer versions of packages than you have installed an upgrade would try
to download them potentially running also into 404 errors (assuming this
repo is entirely offline). That would indeed "block" upgrades of other
packages not from that repo, but what is apt supposed to do instead…
It is asked to upgrade all packages and can't: Partial upgrades are
technically supported, but hardly tested in practice as it is
a combinatorial explosion if you tried. So in theory you upgrade from
a perfectly supported system with updates available to a system with
unknown support status and still more updates available. That doesn't
look like a good default move.

You can tell apt to carry on with --fix-missing if that is what you
desire, but really, you should either remove that repository (and the
packages coming from it) for good or work with its provider on fixing
it/making it available again. After all, --fix-missing lets you carry
on in a pinch, but it remains that the repository fails to serve updates
to you, which in the worst case means public known security issues remain
exploitable on your system.

(This could be part of an attack. It usually isn't, but it is
 indistinguishable from a MITM blocking access to a repository so
 that you can not get the security updates the attacker wants to
 exploit. There are better ways, hence its unlikely, but it is just
 a less good way as it shows errors grabbing attention that something
 is wrong. If apt wouldn't, this would be really easy to use.)

> For the size estimation, I understand it is an estimation, and there could
> be guesswork, but I would posit that if the estimate is even roughly
> correct, a user most likely will not want to proceed, because the
> consequences greatly outweigh the benefits of proceeding.

As I tried to explain already apt downloads itself at the expense of 1.5
MB. It will take up installed 4.5 MB. It hardly changes size from
version to version, so more space freed/used after the upgrade amounts
to more or less 0 MB. Running and using apt requires additional data
which easily takes up 200 MB. Lets assume every package is similar to
apt (they aren't, you e.g. have things like texlive which comes in a
couple hundred MBs of download already). A typical upgrade can contain
more than 1000 packages, so which value between 0 and 200 GB are we
gonna use as a rough estimate for that upgrade? And again, which
partitions are we gonna talk about if you have multiple, like e.g.
a separate /boot ?

APT in this scenario picks 1.5 GB (the size it will need to download all
the packages) on the partition housing its download location:
apt's free space check for the download is done against free blocks
available for everyone. In a default configuration root has an additional
5% of a partition as free space available for their exclusive use.

If your idea is that lets say apt should not continue if you don't have
100 MB free on /boot and 5 GB on / (should be enough, right?) that is
fine for your system and pretty easy to implement with e.g. a
dpkg::pre-invoke hook (no need for the heavier dpkg::pre-install-pkgs
hook). That wont work in the general case though… there are systems
which don't even have 5 GBs of disk space to begin with.

(Did you think apts 1.5 GB is a reasonable low bound? For some people
 that

Re: Apt feature request / suggestion

[xaq xaq]

Thanks Paul and David.

To simplify a frequently seen halt of `apt upgrade` I have this example.. I
had to remove keepsolidinc.list
from /etc/apt/sources.list.d. Then apt update proceeds. Here is the error I
get with that source list in place:

*Hit:1 http://archive.ubuntu.com/ubuntu
<http://archive.ubuntu.com/ubuntu> - InRelease
Hit:2 http://security.ubuntu.com/ubuntu
<http://security.ubuntu.com/ubuntu> --security InRelease
Hit:3 http://archive.ubuntu.com/ubuntu
<http://archive.ubuntu.com/ubuntu> --updates InRelease
Hit:4 http://archive.ubuntu.com/ubuntu
<http://archive.ubuntu.com/ubuntu> --backports InRelease
Ign:5 http://apt.keepsolid.com/ubuntu
<http://apt.keepsolid.com/ubuntu> - InRelease
Err:6 http://apt.keepsolid.com/ubuntu
<http://apt.keepsolid.com/ubuntu> - Release
  404  Not Found [IP: 144.217.71.199 80]
Reading package lists... Done
E: The repository 'http://apt.keepsolid.com/ubuntu
<http://apt.keepsolid.com/ubuntu> - Release' does not have a Release
file.
N: Updating from such a repository can't be done securely, and is
therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user
configuration details.*



For the size estimation, I understand it is an estimation, and there could
be guesswork, but I would posit that if the estimate is even roughly
correct, a user most likely will not want to proceed, because the
consequences greatly outweigh the benefits of proceeding.

This is because once a disk is filled, `apt remove` will not undo the
changes until the install is complete. This creates an impossible
situation, ie. apt cant remove without space, but install cant proceed
because there is no space.

This problem is most relevant today with users heavily relying on VMs where
shrinking a disk is often problematic, so creating an image with the least
amount of freespace is highly useful, because images are often cloned
many times for backup and progression. This means repeatedly bumping into
this "impossible situation".

It seems a simple solution to just not proceed when the estimated install
space exceeds the free space. It is already calculated. And the edge cases
will more likely than not benefit from not proceeding by default. This is
because the cost of a false positive is much, much less than getting into a
catch-22 of disk space, getting stuck, and not being able to undo what apt
just did, even following the recommended --fix-broken which wont work if
the disk is full, which is many times presented because of the disk being
full. I'm not sure I see many situations where having to use a flag to
proceed would harm the vast majority of users.

Thank you


On Sun, Oct 9, 2022 at 5:37 AM David Kalnischkies 
wrote:

> On Fri, Oct 07, 2022 at 09:33:28AM +0800, Paul Wise wrote:
> > On Thu, 2022-10-06 at 10:54 -0700, xaq xaq wrote:
> > > Hi, how do I submit a suggestion to the Apt team? I've tried to
> > > register on their website (https://salsa.debian.org/apt-team/apt).
> >
> > You can report a bug via the Debian BTS:
> >
> > https://www.debian.org/Bugs/Reporting
>
> Our¹ "website" mentions at the end of our general information blob:
> | Discussion happens mostly on
> | [the mailing list](mailto:de...@lists.debian.org)
> | ([archive](https://lists.debian.org/deity/))
> | and on [IRC](irc://irc.oftc.net/debian-apt).
> | Our bug tracker as well as a general overview can be found at
> | the [Debian Tracker page](https://tracker.debian.org/pkg/apt).
>
> (in markdown so you can see the direct pointers). It is actually our¹
> README file in the version control system, we don't have a website and
> hence none is given in the Homepage field.
>
> ¹ "our" as in: I am one of two active apt developers.
>
>
> > > - Have an option to ignore failures in any source.list file.
> > >   This will allow updates of security repos to proceed.
> >
> > This makes it sound like you need to update your apt sources for the
> > changes to the security archive that happened in Debian bullseye:
> >
> >
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive
>
> Apart from what Paul said (and is btw an other indication that "we will
> write it in the release notes and everything is smooth sailing from
> there on out" still means a lot of support questions. I stopped counting
> how often I pointed to that release note section…):
>
> Please tell us the EXACT and COMPLETE update output you are seeing.
> In the security-archive example an 'apt update' will fail with error
> messages and such about the bad archive, but all the other "working"
> archives will be updated as usual and subsequent apt calls will use
> that information. The failure is hence already "ignored&q

Re: Apt feature request / suggestion

[David Kalnischkies]

On Fri, Oct 07, 2022 at 09:33:28AM +0800, Paul Wise wrote:
> On Thu, 2022-10-06 at 10:54 -0700, xaq xaq wrote:
> > Hi, how do I submit a suggestion to the Apt team? I've tried to
> > register on their website (https://salsa.debian.org/apt-team/apt).
> 
> You can report a bug via the Debian BTS:
> 
> https://www.debian.org/Bugs/Reporting

Our¹ "website" mentions at the end of our general information blob:
| Discussion happens mostly on
| [the mailing list](mailto:de...@lists.debian.org)
| ([archive](https://lists.debian.org/deity/))
| and on [IRC](irc://irc.oftc.net/debian-apt).
| Our bug tracker as well as a general overview can be found at
| the [Debian Tracker page](https://tracker.debian.org/pkg/apt).

(in markdown so you can see the direct pointers). It is actually our¹
README file in the version control system, we don't have a website and
hence none is given in the Homepage field.

¹ "our" as in: I am one of two active apt developers.


> > - Have an option to ignore failures in any source.list file.
> >   This will allow updates of security repos to proceed.
> 
> This makes it sound like you need to update your apt sources for the
> changes to the security archive that happened in Debian bullseye:
> 
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive

Apart from what Paul said (and is btw an other indication that "we will
write it in the release notes and everything is smooth sailing from
there on out" still means a lot of support questions. I stopped counting
how often I pointed to that release note section…):

Please tell us the EXACT and COMPLETE update output you are seeing.
In the security-archive example an 'apt update' will fail with error
messages and such about the bad archive, but all the other "working"
archives will be updated as usual and subsequent apt calls will use
that information. The failure is hence already "ignored" in a sense.

So if you don't see that behaviour it might simply be a bug that should
be fixed.


> > - Have Apt not proceed with install if available space is less than
> > estimated install space. Especially since --fix-broken-install
> > usually requires more space to resolve this.
> 
> Until the apt developers implement this, it might be possible to add a
> hook script added to the DPkg::Pre-Install-Pkgs option in apt.conf.

(--fix-broken-install is not a thing, I suppose the last - is a space)

APT already makes a rough check on the available space for the download,
so in that step, you aren't going to run out of space. The installation
is another matter… apt displays a remark on what it thinks will be used/
freed after the upgrade will be complete, but that can be a pretty rough
estimate (= is completely wrong most of the time).

Take apt itself as an example: Download is ~1.5 MB, Install size
supposedly ~4.5 MB. In practice /var/lib/apt and /var/cache/apt will
grow into the hundreds of MBs on first use. apt is usually not used
inside maintainer scripts, but many other things generate lots of data
which isn't accounted for. The other thing is that e.g. we don't know
where that space will be needed: If you have a separate /boot for
example it becomes interesting if your next kernel install will fit into
it as well or not (and if it does in the middle of the upgrade, not at
the end after others were perhaps removed) – and it is usually
accompanied by a generated initrd which isn't accounted for anyhow.


So, that script would probably contain lots and lots of guesswork and
would indeed be better of being not part of apt itself (like the
mentioned listbugs or e.g. listchanges) as src:apt is usually not
granted as much leeway in terms of updates as "leaf" packages.

(Beside that this script probably has the same problem as apt itself:
 Ideally an upgrade from X to Y would use the version from Y already)


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Re: Apt feature request / suggestion

[Paul Wise]

On Thu, 2022-10-06 at 10:54 -0700, xaq xaq wrote:

> Hi, how do I submit a suggestion to the Apt team? I've tried to
> register on their website (https://salsa.debian.org/apt-team/apt).

You can report a bug via the Debian BTS:

https://www.debian.org/Bugs/Reporting

> - Have an option to ignore failures in any source.list file.
>   This will allow updates of security repos to proceed.

This makes it sound like you need to update your apt sources for the
changes to the security archive that happened in Debian bullseye:

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive

> - Have Apt not proceed with install if available space is less than
> estimated install space. Especially since --fix-broken-install
> usually requires more space to resolve this.

Until the apt developers implement this, it might be possible to add a
hook script added to the DPkg::Pre-Install-Pkgs option in apt.conf.

It might be hard to write such a script. The apt-listbugs package is
probably the best example of how to process the hook script input.

https://sources.debian.org/src/apt-listbugs/0.1.36/10apt-listbugs/
https://sources.debian.org/src/apt-listbugs/0.1.36/bin/apt-listbugs/#L455

Documentation on DPkg::Pre-Install-Pkgs is in the apt.conf manual page:

https://manpages.debian.org/bullseye/apt/apt.conf.5.en.html#HOW_APT_CALLS_DPKG(1)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Apt feature request / suggestion

[xaq xaq]

Hi, how do I submit a suggestion to the Apt team? I've tried to register on
their website (https://salsa.debian.org/apt-team/apt).

I have two suggestions/discussions to post.
- Have an option to ignore failures in any source.list file. This will
allow updates of security repos to proceed.
- Have Apt not proceed with install if available space is less than
estimated install space. Especially since --fix-broken-install usually
requires more space to resolve this.

Thank you

Re: How to Fix the apt-get install error: “Media change: please insert the disc labeled ...” in Debian 10.

[Geert Stappers]

On Thu, Nov 19, 2020 at 04:04:55PM +0800, Edgar Villanueva Jr wrote:
> I was amazed by the description that Debian is robust and reliable etc. So
> I decided to install it. But when I try to install from terminal "Fix the
> apt-get install error: “Media change: please insert the disc labeled ...”
> appears.

Look to me like a left over from installation.

Edit the file  /etc/apt/sources.list



> I can't also install software thru discover.
> 
> I really need help with these things.
> 
> Thank you!

You are welcome,
especial on more on-topic-mailing-lists.

 
Regards
Geert Stappers
-- 
Silence is hard to parse

Re: How to Fix the apt-get install error: “Media change: please insert the disc labeled ...” in Debian 10.

[Daniel Lange]

Hi Edgar,

Am 19.11.20 um 09:04 schrieb Edgar Villanueva Jr:
I was amazed by the description that Debian is robust and reliable etc. 
So I decided to install it. But when I try to install from terminal "Fix 
the apt-get install error: “Media change: please insert the disc labeled 
...” appears. I can't also install software thru discover.


The better mailing list for such requests is debian-user
(https://lists.debian.org/debian-user/) or a non-English version of it 
(https://lists.debian.org/users.html) if you prefer.


Debian-project is meant to discuss non-technical issues around the 
Debian project, e.g. organization or policy changes.


That said, you likely have a line starting with

deb cdrom: ...

in your /etc/apt/sources.list

comment that line out (as root) by prefixing it with a hash (#) mark:

# deb cdrom: ...

Save the file and that should fix things.

Kind regards,
Daniel

How to Fix the apt-get install error: “Media change: please insert the disc labeled ...” in Debian 10.

[Edgar Villanueva Jr]

I was amazed by the description that Debian is robust and reliable etc. So
I decided to install it. But when I try to install from terminal "Fix the
apt-get install error: “Media change: please insert the disc labeled ...”
appears. I can't also install software thru discover.

I really need help with these things.

Thank you!

Re: Using apt-get after Debian installation

[Paul Wise]

On Mon, Apr 13, 2020 at 7:24 PM Nathanael Skrepek wrote:

> I want to offer a suggestion, because i was a little bit puzzled by the 
> following.

Please file a report about this so the installer team can work on fixing it:

https://www.debian.org/releases/stable/amd64/ch05s04#submit-bug

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Using apt-get after Debian installation

[Nathanael Skrepek]

Hello!

I want to offer a suggestion, because i was a little bit puzzled by the 
following.
After the installation of Debian I wanted to install `texlive` by typing 
`apt-get texlive-full` in the terminal (i think the actual packages doesn't 
really matter but anyway), but then there came the message

Media change: please insert the disc labeled
 'Debian GNU/Linux 10.3.0 _Buster_ - Official amd64 DVD Binary-1 
20200208-12:08' in the drive 'media/cdrom' and press [Enter]

However, I used an USB stick to install Debian and plugging in the usb stick 
didn't help. I could find a solution on the internet, which told me to change 
the file `/etc/apt/sources.list` and comment the corresponding line.

I think this should be changed, because it is very confusing and not obvious 
how to continue. At least there should be a dialog that offers the option to 
not use the installation DVD.

Best regards
Nathanael Skrepek

Re: third-party packages adding apt sources

[Andrew McGlashan]

On 21/05/2016 8:03 AM, Hakan Peker wrote:
> You looking for a technical solution to a social problem. sources.list
> exist for the very purpose that repositories can be added to the system.
> A system where this facility don't exist or restricted is a form of
> walled garden.
> 
> Adding an update repository for the very same package the user has
> deliberately installed is a *convenience*. It is disrespectful of admin
> modification only if the program keeps reverting the admin modification
> and doesn't provide an option to disable this behavior. At that point
> you would be better contacting upstream that you are not comfortable
> with the behavior and you want such an option to disable the repository.

The fact that a deb can run arbitrary code, then it MUST be trusted and
there are limits to how much trust I can give to outside third parties;
it is too great a risk as far as I am concerned.

Cheers
A.



signature.asc
Description: OpenPGP digital signature

Re: third-party packages adding apt sources

[Hakan Peker]

On 05/20/2016 10:35 PM, Vincent Danjean wrote:

Le 19/05/2016 19:20, Hakan Peker a écrit :

On 05/19/2016 06:18 PM, Daniel Pocock wrote:

  From a technical perspective, can we do more to prevent users being
surprised by packages putting new entries in /etc/apt/sources.list.d?


Please no. The system is working as intended. I don't think anybody is 
surprised after installing a 3rd party deb package and seeing it adds its apt 
repository to the system, actually they would be pleased to know that they 
won't have to manually update it later. And anybody who is uncomfortable with 
it would either disable it or not install the deb in the first place.


   Please yes.

   I built some (local) packages to easily install the same sources.list
on several machines, so I agree the feature in useful and interesting.
I named my packages like *-sources and the description is explicit.

   But I've been very suprised when I discovered that the google-earth
package installed a sources.list on my parents' computer after I
downloaded and install an application deb with dpkg.
   And even more when I see that the source is silently reinstalled when
you remove it (no respect of admin modification)

   Would it be possible to have a package that install a trigger and
advertise (debconf/mail/...) when such a change occurs? I would install
it anywhere personally.



You looking for a technical solution to a social problem. sources.list 
exist for the very purpose that repositories can be added to the system. 
A system where this facility don't exist or restricted is a form of 
walled garden.


Adding an update repository for the very same package the user has 
deliberately installed is a *convenience*. It is disrespectful of admin 
modification only if the program keeps reverting the admin modification 
and doesn't provide an option to disable this behavior. At that point 
you would be better contacting upstream that you are not comfortable 
with the behavior and you want such an option to disable the repository.


-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

Re: third-party packages adding apt sources

[Paul Wise]

On Sat, May 21, 2016 at 8:32 PM, Adam Borowski wrote:

> This looks wrong to me: a vast majority of machines these days have a single
> user, thus pwning root gives you little additional gain.

Getting further into a system (user -> root -> GRUB -> MBR -> boot
firmware -> peripheral firmware) gives a successful attack much more
persistence. This is why the TLAs go as deep as they can.

> So, for running untrusted code you should execute it solely in a special
> environment of some kind.  And if you're not executing those binaries
> directly, what's the point in putting them into the standard paths?

No idea what anarcat's thoughts were but I can think of two reasons:

Prevents those binaries from being modified by the binaries themselves
or other programs run by the user.

Makes integration with the rest of the system easier.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: third-party packages adding apt sources

[Adam Borowski]

On Sat, May 21, 2016 at 01:47:41PM +0800, Paul Wise wrote:
> On Thu, May 19, 2016 at 11:18 PM, Daniel Pocock wrote:
> 
> > More and more frequently I'm encountering systems where third-party
> > repositories have been added into /etc/apt/sources.list or
> > /etc/apt/sources.list.d, usually put there by some .deb package that a
> > user installed from some third party site.
> 
> This discussion reminds me of this wiki page:
> 
> https://wiki.debian.org/UntrustedDebs

This looks wrong to me: a vast majority of machines these days have a single
user, thus pwning root gives you little additional gain.

So, for running untrusted code you should execute it solely in a special
environment of some kind.  And if you're not executing those binaries
directly, what's the point in putting them into the standard paths?

-- 
An imaginary friend squared is a real enemy.

Re: third-party packages adding apt sources

[Martin Steigerwald]

On Samstag, 21. Mai 2016 10:53:34 CEST Vincent Bernat wrote:
>  ❦ 21 mai 2016 10:24 +0200, Martin Steigerwald  :
> > Still, the turn around time between upstream and debian release would be
> > quite high for Debian stable users, but maybe part of such a
> > collaboration could be to also provide newer releases via backports.
> > Also… if upstream wants to release the built packages even quicker to
> > testers or adventurous people, why not allow them to put newer versions
> > of the official packages into their own repo while still integrating them
> > with the official repo? For Owncloud for example this could lead at least
> > to *compatible* packaging. Right now switching between Debian packages
> > and upstream packages basically destroys a working Owncloud installation
> > and requires quite some manual interaction to get things working again.
> > But with compatible packages people could easily switch between "I use
> > stable packages", "I use backport packages" and "I don´t care I want the
> > latest I add the upstream repo".
> 
> Owncloud upstream seems quite hostile towards Debian. But your
> proposition works with some other upstreams. For example, we are doing

Yeah, with Owncloud I still hope for changes, but I think it needs to happen 
on both sides and I saw some willingness on side of upstream, but also quite 
some concern. Also upstream project seems changing quite a bit with people 
leaving Owncloud Inc.

> all the packaging work for HAProxy, both official and unofficial
> packages (more backports, backports to Ubuntu) and upstream is quite
> happy (while in the past, upstream asked us to not ship HAProxy in
> Debian because it would be too old).
> 
>  http://mozilla.debian.net/
>  http://haproxy.debian.net/
>  http://ganeti.debian.net/
> 
> I think those packages are ideal to keep everyone happy. People can
> choose whatever they want and bear with the consequences. And the
> packages are "top" quality because they are derived from the packages in
> unstable.

Okay. I was aware of mozilla.debian.net, but not the others, well, that would 
be also a nice approach for upstream which might be nice to mention on 
upstream landing page.

I never thought this is available on a more general base.

> However, the examples above are compatible with our way of
> packaging. Would we want spend time on packaging stuff that would never
> go to the Debian archive due to excessive vendoring or unwilling from
> upstream to be in a stable release?

No. I don´t think that is a good idea and so I agree with David´s decision 
regarding Owncloud. He spend *a lot* of work which will not end up in Debian 
Stretch, at least not with the current situation.

But in some case I am not sure whether there have been any serious attempts to 
talk and find solutions that work. Maybe currently its not feasible with 
Owncloud, but I do think the current situation is a loss for both upstream and 
Debian.

> Now, I usually ask upstream if they would be interested to have their
> software in Debian and then, I propose for them to maintain it or
> comaintain it. Many are happy with that but some just say no. I don't
> keep tabs, but here is one example (not my own request):
> 
>  https://github.com/jordansissel/fpm/issues/409

*sigh*, not the first time I heard that Jordan is not fond of Debian packaging 
guidelines and more of a Fedora guy.

-- 
Martin

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

Re: third-party packages adding apt sources

[Martin Steigerwald]

On Samstag, 21. Mai 2016 11:13:41 CEST Lars Wirzenius wrote:
> On Sat, May 21, 2016 at 10:07:43AM +0200, Martin Steigerwald wrote:
> > I wonder about a landing page for upstreams interested in working with the
> > Debian project to provide packages within the official Debian repos.
> 
> Is https://wiki.debian.org/UpstreamGuide the kind of page you mean? It
> is not necessarily well known.

Oh, its all there already, *including* a mailing list.

Ok, so maybe all whats needed for now is some promo work on this? And probably 
updating here and there.

I was totally unaware of this.

Thanks,
-- 
Martin

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

Re: third-party packages adding apt sources

[Vincent Bernat]

 ❦ 21 mai 2016 09:40 +0200, Ole Streicher  :

>>> Providing a proper Debian source package is also a lot more work than
>>> writing some kind of ad-hoc build system that spits out a .deb or
>>> three.
>>
>> Totally agree. Our standards are far too high for many upstreams.
>
> which is a Good Thing.
>
> I usually put quite much effort to bring the packages to the Debian
> level, and at the end many upstreams are convinced that our standards
> help them as well on the long run.

The problem is with upstreams that (sometimes loudly) complains that our
standards are useless. Users will still install their packages and
rumble against us. Of course, I am not saying that we should lower our
standards, but it is a difficult world.
-- 
Use self-identifying input.  Allow defaults.  Echo both on output.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: third-party packages adding apt sources

[Vincent Bernat]

 ❦ 21 mai 2016 10:24 +0200, Martin Steigerwald  :

> Still, the turn around time between upstream and debian release would be 
> quite 
> high for Debian stable users, but maybe part of such a collaboration could be 
> to also provide newer releases via backports. Also… if upstream wants to 
> release the built packages even quicker to testers or adventurous people, why 
> not allow them to put newer versions of the official packages into their own 
> repo while still integrating them with the official repo? For Owncloud for 
> example this could lead at least to *compatible* packaging. Right now 
> switching between Debian packages and upstream packages basically destroys a 
> working Owncloud installation and requires quite some manual interaction to 
> get things working again. But with compatible packages people could easily 
> switch between "I use stable packages", "I use backport packages" and "I 
> don´t 
> care I want the latest I add the upstream repo".

Owncloud upstream seems quite hostile towards Debian. But your
proposition works with some other upstreams. For example, we are doing
all the packaging work for HAProxy, both official and unofficial
packages (more backports, backports to Ubuntu) and upstream is quite
happy (while in the past, upstream asked us to not ship HAProxy in
Debian because it would be too old).

 http://mozilla.debian.net/
 http://haproxy.debian.net/
 http://ganeti.debian.net/

I think those packages are ideal to keep everyone happy. People can
choose whatever they want and bear with the consequences. And the
packages are "top" quality because they are derived from the packages in
unstable.

In some cases, upstream accepts/wants to host packaging in its own git
repository as well and is happy to help (I have librdkafka/kafkacat and
ExaBGP as examples). Therefore, they can do their own releases as well.

Maybe once we have PPA, we could mainstream a bit the wizard and propose
more options.

However, the examples above are compatible with our way of
packaging. Would we want spend time on packaging stuff that would never
go to the Debian archive due to excessive vendoring or unwilling from
upstream to be in a stable release?

Now, I usually ask upstream if they would be interested to have their
software in Debian and then, I propose for them to maintain it or
comaintain it. Many are happy with that but some just say no. I don't
keep tabs, but here is one example (not my own request):

 https://github.com/jordansissel/fpm/issues/409
-- 
If you laid all of our laws end to end, there would be no end.
-- Mark Twain


signature.asc
Description: PGP signature

Re: third-party packages adding apt sources

[Lars Wirzenius]

On Sat, May 21, 2016 at 10:07:43AM +0200, Martin Steigerwald wrote:
> I wonder about a landing page for upstreams interested in working with the 
> Debian project to provide packages within the official Debian repos.

Is https://wiki.debian.org/UpstreamGuide the kind of page you mean? It
is not necessarily well known.

-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh


signature.asc
Description: PGP signature

Re: third-party packages adding apt sources

[Martin Steigerwald]

On Samstag, 21. Mai 2016 10:24:22 CEST Martin Steigerwald wrote:
> I wonder about some kind of adopt an upstream within a Debian team kind of 
> approach. A landing page and mailing list where upstream can write in for 
> getting help and advice and voicing their needs. And when there are people
> in  Debian willing to work with upstream they can build a team.
[…]
> I do think spelling out an invitation to work together officially can help
> to  attract more upstreams to work closer with Debian.

Also explaining on that page to upstream why Debian has the quality and 
stability requirements it has and what benefits this can create for upstreams 
including with offers on how to meet different upstream needs where that would 
be possible.

-- 
Martin

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

Re: third-party packages adding apt sources

[Martin Steigerwald]

On Samstag, 21. Mai 2016 10:24:06 CEST Lars Wirzenius wrote:
> Et cetera. Debian has one set of quality factors it particularly cares
> about, and some upstreams think differently.

Yes, I seen all those reasons you mentioned.

I just wonder how about if upstreams can learn easily how to work together 
with Debian developers and maintainers which basically would mean offloading 
some of the work involved?

Still, the turn around time between upstream and debian release would be quite 
high for Debian stable users, but maybe part of such a collaboration could be 
to also provide newer releases via backports. Also… if upstream wants to 
release the built packages even quicker to testers or adventurous people, why 
not allow them to put newer versions of the official packages into their own 
repo while still integrating them with the official repo? For Owncloud for 
example this could lead at least to *compatible* packaging. Right now 
switching between Debian packages and upstream packages basically destroys a 
working Owncloud installation and requires quite some manual interaction to 
get things working again. But with compatible packages people could easily 
switch between "I use stable packages", "I use backport packages" and "I don´t 
care I want the latest I add the upstream repo".


I wonder about some kind of adopt an upstream within a Debian team kind of 
approach. A landing page and mailing list where upstream can write in for 
getting help and advice and voicing their needs. And when there are people in 
Debian willing to work with upstream they can build a team.

May still not be suitable for some upstreams or some upstreams not be suitable 
for Debian, but I got the impression that Debian may be seen as elitist and 
basically unapproachable by some upstreams – and that in quite some cases like 
with the Owncloud packaging a different approach would be possible. (Actually 
that is what I thought for a long time as well, until I found sponsors for 
some package I wanted in the archive and well, until Debconf 2015 in 
Heidelberg.)

I do think spelling out an invitation to work together officially can help to 
attract more upstreams to work closer with Debian.

-- 
Martin

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

Re: third-party packages adding apt sources

[Martin Steigerwald]

Hello Paul,

On Samstag, 21. Mai 2016 14:07:53 CEST Paul Wise wrote:
> On Fri, May 20, 2016 at 1:34 PM, Vincent Bernat wrote:
> > Totally agree. Our standards are far too high for many upstreams.
> 
> I don't understand the disconnect here. Are upstreams not interested
> in software quality to the extent we are?

I know one quite popular example where some upstream people even objected 
having the software packaged in Debian:

Unfit upstream / RM: owncloud -- ROM; PHP 7.0 Transition
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816376

I think similar can be said for many web applications that are just developed 
at a very high pace. Combine that with an upstream policy not to support 
skipping updates between major versions… by supporting redoing older update 
steps and you have something that is compatible with Debian stable standards.

Now I know other web apps where this works better, like Wordpress, that now 
even has a wonderfully working backport. Still this has brought up a principal 
issue that is still unsolved.

I know of some other upstreams that provided packages themselves for… whatever 
reasons, might be a good idea to ask them.

So for example basically all log analysis and indexing software that seems to 
be so popular in the last time:

- Elasticsearch: newer versions than in unstable
- Logstash
- Kibana
- Fluentd
- Graylog

Also things like OpenNebula where I have been involved a bit failed in Debian 
due to lack of manpower combined with that some effort to work together did 
not play out probably due to lack of manpower on upstream side as well. 
Instead they just do a stuff it all in one or a few packages no matter what. 
Which is similar to how Owncloud upstream does packages. It is basically like 
a huge tarball, all just stuff in /var/html, including config files and be 
done with it. Logstash packages at least have their config files in /etc, yet 
all else in /opt/logstash or so.

I suspect one of the reasons is the perceived simplicity of just doing it 
yourself without having to abide to all the rules, to have the package lintian 
clean (I never checked those against lintian tough), and to generally get more 
work done in less time, even if that work has a lower quality than what is 
usually accepted into Debian.

> > I am always flabestered by the popularity of fpm to build Debian
> > packages (and by the increasing popularity of pleaserun by the same
> > author on the same concepts). It provides a way to easily build a Debian
> > package from a directory but produces somewhat crippled/incomplete
> > packages and is no help to us since it's completely outside of any of
> > our tools. It also handles RPM (and now other package formats), but I
> > don't think this would explain its popularity alone.
> 
> I think we probably need to get dpkg-buildpackage to automatically run
> some of these:
> 
> https://wiki.debian.org/AutomaticPackagingTools

I am very happy about Maxy´s work to automate Plasma 5 and KDE Frameworks 5 
packaging. Here there is a similar issue:

Upstream has way faster release cycles and additionally they splitted up their 
stuff into a lot more single projects. With KDE 3, a bit less with KDE SC 4 it 
was a number of larger packages that you could even still count easily enough 
with your fingers. With Plasma 5  and KDE Frameworks 5 upstream provides 
literally hundreds of tarballs and git repos to package in order to get a full 
desktop experience. According to cd /usr/share/doc/libkf I have 213 
library packages installed on my system.

Maxy went to a great extent of automating things, which in some cases can lead 
to this:

karchive (5.22.0-1) unstable; urgency=medium

  [ Automatic packaging ]
  * Update symbols files from buildds logs (5.21.0-1).
  * Update symbols files.
  * Update build-deps and deps with the info from cmake

 -- Maximiliano Curia <[…]>  Thu, 19 May 2016 00:19:49 +0200

In other cases it is a mix of manual and automatic work:

karchive (5.21.0-1) experimental; urgency=medium

  [ Maximiliano Curia ]
  * Replace the "Historical name" ddeb-migration by its "Modern, clearer" 
replacement dbgsym-migration.
  * Add upstream metadata (DEP-12)
  * debian/control: Update Vcs-Browser and Vcs-Git fields
  * Update acc test script
  * uscan no longer supports more than one main upstream tarball being listed

  [ Automatic packaging ]
  * Update build-deps and deps with the info from cmake
  * Update symbols files.
  * Bump Standards-Version to 3.9.8

 -- Maximiliano Curia <[…]>  Thu, 05 May 2016 15:04:24 +0200


I am aware of similar efforts for a lot of different things like haskell 
packages, where Joachim Breitner and other teams upload literally hundreds of 
packages in a single day. I don´t know whether someone has an overview on 
whats available and what is used in the different packaging teams. But I do 
think the wiki page you linked is not complete.


I wonder about a landing page for upstreams interested in working with the 
Debian 

Re: third-party packages adding apt sources

[Ole Streicher]

Vincent Bernat  writes:
>  ❦ 19 mai 2016 18:04 +0100, Ian Jackson  :
>>> b) many upstreams appear frustrated about getting their package
>>> officially supported in Debian.  Sometimes there is good reason their
>>> package doesn't belong in Debian but sometimes it is more about inertia
>>> in Debian or the upstream isn't aware about backports and thinks their
>>> package will be stuck at a particular version forever
>>
>> Providing a proper Debian source package is also a lot more work than
>> writing some kind of ad-hoc build system that spits out a .deb or
>> three.
>
> Totally agree. Our standards are far too high for many upstreams.

which is a Good Thing.

I usually put quite much effort to bring the packages to the Debian
level, and at the end many upstreams are convinced that our standards
help them as well on the long run.

Best

Ole

Re: third-party packages adding apt sources

[Lars Wirzenius]

On Sat, May 21, 2016 at 02:07:53PM +0800, Paul Wise wrote:
> On Fri, May 20, 2016 at 1:34 PM, Vincent Bernat wrote:
> 
> > Totally agree. Our standards are far too high for many upstreams.
> 
> I don't understand the disconnect here. Are upstreams not interested
> in software quality to the extent we are?

I don't think it's that upstreams aren't interested in quality, but
that Debian and (some) upstreams have different opinions on what
aspects of quality are more important.

* Debian: don't embed copies of libraries you use. It makes it harder
  to do security updates in the libraries, makes it harder to use the
  libraries on their own, and makes the Debian package archive
  unnecessarily larger.

  Some upstreams: we embed copies of libraries. It makes it easier to
  install our software, and guarantees us that the library doesn't
  change from underneath us, and that means we don't need to support
  many versions of the library. We're an active project, and if a
  library needs a security update, we do it quickly.

* Debian: it's important to follow Debian Policy and the Debian
  workflow of uploading to unstable and letting packages flow from
  there to testing and stable, if they don't have bad bugs. There's
  thousands of people making packages and things will break if they
  all do the same thing differently.

  Some upstreams: it's OK to cut some corners and do things simply. We
  care about getting the software into the hands of its users as soon
  as possible, and we also don't have a lot of time to spend on
  packaging. From our point of view, packaging is a necessary evil
  that is much too difficult and takes much too much time from us.
  That's effort we could spend on making the software better instead.

* Debian: it's important to have package versions that can be
  supported for many years. We produce a release every two years, and
  support it for at least three, and more if one counts the LTS
  project. Software that changes a lot, or that has an API that
  changes a lot, or that doesn't separate security updates and
  backport those to the version included in a Debian release, make
  this harder for us. We can't generally update to a new upstream
  release whenever there is a security problem, as it would negate the
  point of making Debian releases. For example, the new upstream
  version might require entirely new forests of dependencies, or newer
  versions of dependencies, all the way down to the kernel. For some
  packages that we deem sufficiently important to our users, we deal
  with that, but it is not something that generalises to all packages.

  Some upstreams: we don't support our old releases. We have only so
  much time to spend on this software, and supporting old releases
  would take a lot of effort we don't have time for. That's why we
  embed most of our dependencies into the installation packages we
  make, so that they can be installed onto the Debian releases, even
  if we decide to require more dependencies, or newer versions of
  them.

Et cetera. Debian has one set of quality factors it particularly cares
about, and some upstreams think differently.

-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh


signature.asc
Description: PGP signature

Re: third-party packages adding apt sources

[Vincent Bernat]

 ❦ 21 mai 2016 14:55 +0800, Paul Wise  :

>> For some languages, embedded copies are a pattern. Notably Go. But there
>> is also the omnibus stance: the embedded copy could not be in the
>> source, but could be in the shipped artifact. This includes Go, JS and
>> Java (when using uberjars). For some other ecosystems, the embedded copy
>> is more the exception than the rule (C, C++, Python).
>
> By shipped artifact, it sounds like you are talking about source
> packages? or do you mean binary packages?

I meant binary packages but wanted to be more general (not limited to Debian).

>> If upstream is using embedded copies, they are quite unlikely to make
>> any effort tu undo this aspect.
>
> I see upstreams doing that on debian-mentors reasonably often,
> especially when the upstream is the one doing the RFS. For upstreams
> who aren't interested in getting their software into Debian, that is
> definitely the case.

I shouldn't have made a generality. Some upstreams are more receptive
than others to this problematic.
-- 
Each module should do one thing well.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: third-party packages adding apt sources

[Paul Wise]

On Sat, May 21, 2016 at 2:46 PM, Vincent Bernat wrote:

> A meta tool "package me this" would be interesting.

There is debdry but it got orphaned.

> many of those tools are too complex for many upstreams because they
> don't want to package each dependency one by one. For example,
> dh-make-golang is fully automatic but you need to run it on each
> dependency. That's fine because those tools are for building packages
> that should be fit to go into our archive.

ISTR A recursive mode is what some automatic packaging tools do there.

> For some languages, embedded copies are a pattern. Notably Go. But there
> is also the omnibus stance: the embedded copy could not be in the
> source, but could be in the shipped artifact. This includes Go, JS and
> Java (when using uberjars). For some other ecosystems, the embedded copy
> is more the exception than the rule (C, C++, Python).

By shipped artifact, it sounds like you are talking about source
packages? or do you mean binary packages?

> If upstream is using embedded copies, they are quite unlikely to make
> any effort tu undo this aspect.

I see upstreams doing that on debian-mentors reasonably often,
especially when the upstream is the one doing the RFS. For upstreams
who aren't interested in getting their software into Debian, that is
definitely the case.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: third-party packages adding apt sources

[Vincent Bernat]

 ❦ 21 mai 2016 14:07 +0800, Paul Wise  :

>> Totally agree. Our standards are far too high for many upstreams.
>
> I don't understand the disconnect here. Are upstreams not interested
> in software quality to the extent we are?

Many of them don't consider packaging quality as important. As long as
the package does its job, they are fine. Notably, packages generated
with fpm have many downside but they mostly work and people are
happy. The main feature of fpm is being easy, not producing good quality
packages. In our cases, good quality packages are the main feature we
want. Being easy is a plus.

>> I am always flabestered by the popularity of fpm to build Debian
>> packages (and by the increasing popularity of pleaserun by the same
>> author on the same concepts). It provides a way to easily build a Debian
>> package from a directory but produces somewhat crippled/incomplete
>> packages and is no help to us since it's completely outside of any of
>> our tools. It also handles RPM (and now other package formats), but I
>> don't think this would explain its popularity alone.
>
> I think we probably need to get dpkg-buildpackage to automatically run
> some of these:
>
> https://wiki.debian.org/AutomaticPackagingTools

A meta tool "package me this" would be interesting. However note that
many of those tools are too complex for many upstreams because they
don't want to package each dependency one by one. For example,
dh-make-golang is fully automatic but you need to run it on each
dependency. That's fine because those tools are for building packages
that should be fit to go into our archive.

>> And there is also the lost cause of vendoring that gained even more
>> traction with Go but that was already a problem with the Java ecosystem.
>> I don't think there is much to do about this one.
>
> Embedded code/data copies have been a problem since as long as I've
> been a Debian user, they aren't specific to any particular language
> community.
>
> https://wiki.debian.org/EmbeddedCodeCopies

For some languages, embedded copies are a pattern. Notably Go. But there
is also the omnibus stance: the embedded copy could not be in the
source, but could be in the shipped artifact. This includes Go, JS and
Java (when using uberjars). For some other ecosystems, the embedded copy
is more the exception than the rule (C, C++, Python).

If upstream is using embedded copies, they are quite unlikely to make
any effort tu undo this aspect.
-- 
Indent to show the logical structure of a program.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: third-party packages adding apt sources

[Paul Wise]

On Fri, May 20, 2016 at 1:34 PM, Vincent Bernat wrote:

> Totally agree. Our standards are far too high for many upstreams.

I don't understand the disconnect here. Are upstreams not interested
in software quality to the extent we are?

> I am always flabestered by the popularity of fpm to build Debian
> packages (and by the increasing popularity of pleaserun by the same
> author on the same concepts). It provides a way to easily build a Debian
> package from a directory but produces somewhat crippled/incomplete
> packages and is no help to us since it's completely outside of any of
> our tools. It also handles RPM (and now other package formats), but I
> don't think this would explain its popularity alone.

I think we probably need to get dpkg-buildpackage to automatically run
some of these:

https://wiki.debian.org/AutomaticPackagingTools

> And there is also the lost cause of vendoring that gained even more
> traction with Go but that was already a problem with the Java ecosystem.
> I don't think there is much to do about this one.

Embedded code/data copies have been a problem since as long as I've
been a Debian user, they aren't specific to any particular language
community.

https://wiki.debian.org/EmbeddedCodeCopies

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: third-party packages adding apt sources

[Paul Wise]

On Fri, May 20, 2016 at 1:26 PM, Vincent Bernat wrote:

> testing is not suitable for most people because:
>
>  1. no security support

This can be mitigated by adding unstable to your sources.list and
using a wrapper around debsecan to automatically pull in packages from
unstable when
there are security fixes available:

https://bugs.debian.org/725934

>  2. packages can disappear at any time

This can be mitigated by adding unstable to your sources.list. The
same is true for unstable however and that can be mitigated by running
how-can-i-help frequently and migrating to new packages or putting in
some work when you see packages that are important to you are to be
removed.

These mitigations may not be suitable for everyone though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: third-party packages adding apt sources

[Paul Wise]

On Thu, May 19, 2016 at 11:18 PM, Daniel Pocock wrote:

> More and more frequently I'm encountering systems where third-party
> repositories have been added into /etc/apt/sources.list or
> /etc/apt/sources.list.d, usually put there by some .deb package that a
> user installed from some third party site.

This discussion reminds me of this wiki page:

https://wiki.debian.org/UntrustedDebs

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: third-party packages adding apt sources

[Charles Plessy]

Hi Daniel,

Le Thu, May 19, 2016 at 05:18:28PM +0200, Daniel Pocock a écrit :
> 
> From a technical perspective, can we do more to prevent users being
> surprised by packages putting new entries in /etc/apt/sources.list.d?

maybe you are looking for an Apt option that would only install a package if it
comes from repository signed with a key that itself is signed by a trusted key ?

This way, from inside or outside Debian, chains of trust could be used to
certify the compliance of third-party repositories with good practices, or
other rules.

As suggested in this thread, dpkg triggers or other kinds of hooks could check
that packages installed directly without Apt would not change the trust keys
without the user being aware of this.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Re: third-party packages adding apt sources

[Vincent Danjean]

Le 19/05/2016 19:20, Hakan Peker a écrit :
> On 05/19/2016 06:18 PM, Daniel Pocock wrote:
>>  From a technical perspective, can we do more to prevent users being
>> surprised by packages putting new entries in /etc/apt/sources.list.d?
>>
> Please no. The system is working as intended. I don't think anybody is 
> surprised after installing a 3rd party deb package and seeing it adds its apt 
> repository to the system, actually they would be pleased to know that they 
> won't have to manually update it later. And anybody who is uncomfortable with 
> it would either disable it or not install the deb in the first place.

  Please yes.

  I built some (local) packages to easily install the same sources.list
on several machines, so I agree the feature in useful and interesting.
I named my packages like *-sources and the description is explicit.

  But I've been very suprised when I discovered that the google-earth
package installed a sources.list on my parents' computer after I
downloaded and install an application deb with dpkg.
  And even more when I see that the source is silently reinstalled when
you remove it (no respect of admin modification)

  Would it be possible to have a package that install a trigger and
advertise (debconf/mail/...) when such a change occurs? I would install
it anywhere personally.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Re: third-party packages adding apt sources

[Vincent Bernat]

 ❦ 20 mai 2016 08:59 -0300, Antonio Terceiro  :

>> testing is not suitable for most people because:
>> 
>>  1. no security support
>
> That's not true. Proper security fixes will get into testing after 2
> days in unstable if everything goes right as long as the maintainer, or
> something that cares, does the work.

The fix could be blocked by a transition, by an unrelated RC bug, by a
failure to build on some architecture. And nobody will care that much
since testing is not that important until the freeze is near.

>>  2. packages can disappear at any time
>
> If they are broken. In my book that a feature and not a bug.

They can disappear due to any RC bug, even something that's not
noticeable by the user, like a FTBFS of a dependency. Would you postpone
the installation of a server until the package is available?
-- 
Instrument your programs.  Measure before making "efficiency" changes.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

testing is a tool for the release team (Re: third-party packages adding apt sources

[Holger Levsen]

On Fri, May 20, 2016 at 02:40:56PM +0200, Ole Streicher wrote:
> This behavious may be useful for a development platform, but for an end
> user this is just inacceptable.
 
This is why we keep saying that testing is a tool for the release team
and not a suite ment for users. 

Despite that it is suitable for many users most of the time ;-)

Unstable is another suite which is very usuable for many users most of
the time, yet we only advertise it to be used by developers who can live
with breakage.

The release team needs testing. If anybody else needs a similar suite but
slightly different, go create it. It's not that this cannot be done, it
"just" needs *someone* to *do* it.

I wouldn't want us to break the release teams tool, releasing Debian is
hard enough already. 


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: third-party packages adding apt sources

[Ole Streicher]

Antonio Terceiro  writes:
> On Fri, May 20, 2016 at 07:26:28AM +0200, Vincent Bernat wrote:
>>  2. packages can disappear at any time
>
> If they are broken. In my book that a feature and not a bug.

>From the user's perspective, they are also often *not* broken. Just take
the "pandas" package as an example. The package was removed from testing
due to some RC bugs, which are now resolved. However, now the packages
do not build on many platforms, so the migration to testing fails.

For an amd64 machine (which most of the users have), the package works
fine, and from an user's view the package is just not broken. It
disappeared and he can (as long as he has no good knowledge about the
package management) not solve this. The situation gets even more
complicated when the user is not using "python3-pandas" directly, but as
a dependency of another package.

This behavious may be useful for a development platform, but for an end
user this is just inacceptable. Just think if this happens with the only
email program or web browser the user knows about.

Best regards

Ole

Re: third-party packages adding apt sources

[Tollef Fog Heen]

]] Bas Wijnen 

> Debian stable is for users who want a rock solid system.  It is out of date by
> the nature of how it is built.  Users who want to get the newest versions of
> their software should not be running stable; testing is probably better for
> them.

This often isn't what users want, though.  They want the newer versions
of some packages: On my server, I want a new weechat (since it has
bugfixes and features I use), I want a newer grafana (ditto).  I don't
care about having a newer version of emacs, the version in stable is
fine.  Ditto for, say, postgres.

Other users are going to care about different sets of packages, but we
all have the same «I want stable, but for $list_of_packages».

Maybe backports is what we decide is the best solution for those cases,
but maybe we can do better than that.

> > We have zero procedure in place for the following:
> > 
> >   - Totally unsupported very old version of ${FOO} in stable, maintainer
> > isn't patching bugs, bugs are going to upstream, and upstream is
> > annoyed Debian has out of date, perhaps insecure thing X.
> 
> Yes, this is a different problem.  We may want to shield upstream from
> bugreports for those packages somehow.

I'm not at all convinced we can shield upstreams, since users will show
up on mailing lists and IRC upstream and go «I'm trying to do $X, but it
doesn't work, and according to the online docs, it should» and after a
bit of a back and forth, it's discovered that they're running an old
version which either lacks the feature or where it's broken.

> IMO it would be good to recommend our users to file all bugs with us,
> and leave it to the maintainer to pass them to upstream.  I have
> upstreams that follow our bug tracker, which is great.  But if they
> don't, it should be up to me to decide whether the report is worth
> their time.

A lot of user interaction isn't bug reports, but rather closer to user
support.  I don't think it's reasonable for maintainers to be asked to
do all the user support that upstream does.  Even just handling bugs
well (triaging and in some cases fixing and sending patches upstream) is
a lot of work.

> > Hell, teams packaging Mozilla-soft and PostgreSQL are DDs maintaining
> > *external archives* because it's easier.
> 
> This indicates that our procedures are too hard.  That needs to be fixed.
> Maybe people from those teams are reading this and can comment on it?

No, it doesn't merely indicate that our procedures are «too hard».  I
think apt.postgresql.org exists because PostgreSQL.org themselves want
to provide a service to our common users.  We don't want to have all the
supported postgresql versions in our distro, but it's super useful for
users who need a particular version.

> > Making it hard to install a new archive will only lead to more
> > workarounds, more FAQs telling users to dismiss warnings, and more
> > upstreams hell-bent on working against us, because we keep making their
> > lives harder.
> 
> Yes.  But I'm reluctant to throw away our stable release process.  If it's not
> for everyone (and it isn't), we should be more clear about that.

I haven't seen anybody advocating throwing away our stable release
process.  So far it's mostly pointing out problems, not yet trying to
come up with solutions.  (Which is fine, we need to find out what the
problems and the pain points are before it's useful to come up with
solutions.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: third-party packages adding apt sources

[The Wanderer]

On 2016-05-20 at 07:59, Antonio Terceiro wrote:

> On Fri, May 20, 2016 at 07:26:28AM +0200, Vincent Bernat wrote:
> 
>> ❦ 19 mai 2016 16:39 GMT, Bas Wijnen  :
>> 
>>> Debian stable is for users who want a rock solid system.  It is
>>> out of date by the nature of how it is built.  Users who want to
>>> get the newest versions of their software should not be running
>>> stable; testing is probably better for them.
>> 
>> testing is not suitable for most people because:

>> 2. packages can disappear at any time
> 
> If they are broken. In my book that a feature and not a bug.

From a user perspective, it can be a problem, e.g. in the following
scenario:

* Package is in testing, works fine. User installs it on one or more
machines.

* Package in testing gets updated to a newer version, which is broken.

* Package gets removed from testing, because it's broken.

* User, who quite possibly never saw the broken version, wants to
install package on another machine.

From the user's perspective, what should have happened at step 3 is for
the package version available in testing to be reverted back to its last
non-broken version (whether verbatim or with a version bump over the
broken one), not for the package to have been removed entirely.

This may well not be practical as a policy, and I'm not trying to
suggest it as one, but it's an example of how broken-package removal can
be a bug rather than a feature.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: third-party packages adding apt sources

[Antonio Terceiro]

On Fri, May 20, 2016 at 07:26:28AM +0200, Vincent Bernat wrote:
>  ❦ 19 mai 2016 16:39 GMT, Bas Wijnen  :
> 
> > Debian stable is for users who want a rock solid system.  It is out of date 
> > by
> > the nature of how it is built.  Users who want to get the newest versions of
> > their software should not be running stable; testing is probably better for
> > them.
> 
> testing is not suitable for most people because:
> 
>  1. no security support

That's not true. Proper security fixes will get into testing after 2
days in unstable if everything goes right as long as the maintainer, or
something that cares, does the work.

>  2. packages can disappear at any time

If they are broken. In my book that a feature and not a bug.

> There was some discussion in the past to turn testing into a rolling
> release but nothing was done. Such a project would be interesting to
> check its adoption. People complaining that stuff is too old could be
> directed to this rolling release version and we will likely get people
> complaining that stuff moves too fast, but at least, we can't be blamed
> to ship too old softwares, that would be a user choice.

If you assume that freezes take more or less the last 25% of the
development cycle, as far as I am concerned testing _is_ already a
rolling release 75% of the time. And TBH having those last 25% of the
time as a stabilization period does not hurt anyone, on the contrary.


signature.asc
Description: PGP signature

Re: third-party packages adding apt sources

[Charles Plessy]

Le Fri, May 20, 2016 at 07:34:59AM +0200, Vincent Bernat a écrit :
> 
> I am always flabestered by the popularity of fpm to build Debian
> packages (and by the increasing popularity of pleaserun by the same
> author on the same concepts). It provides a way to easily build a Debian
> package from a directory but produces somewhat crippled/incomplete
> packages and is no help to us since it's completely outside of any of
> our tools. It also handles RPM (and now other package formats), but I
> don't think this would explain its popularity alone.

For software using CMake, there are also CPackDeb and CPackRPM.

https://cmake.org/cmake/help/latest/module/CPackDeb.html

Were I an upstream developer, I would definitely be interested by tools like
this that leverage the build system to build installation packages for various
platforms.

Have a nice week-end,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: third-party packages adding apt sources

[Vincent Bernat]

 ❦ 19 mai 2016 18:04 +0100, Ian Jackson  :

>> b) many upstreams appear frustrated about getting their package
>> officially supported in Debian.  Sometimes there is good reason their
>> package doesn't belong in Debian but sometimes it is more about inertia
>> in Debian or the upstream isn't aware about backports and thinks their
>> package will be stuck at a particular version forever
>
> Providing a proper Debian source package is also a lot more work than
> writing some kind of ad-hoc build system that spits out a .deb or
> three.

Totally agree. Our standards are far too high for many upstreams.

I am always flabestered by the popularity of fpm to build Debian
packages (and by the increasing popularity of pleaserun by the same
author on the same concepts). It provides a way to easily build a Debian
package from a directory but produces somewhat crippled/incomplete
packages and is no help to us since it's completely outside of any of
our tools. It also handles RPM (and now other package formats), but I
don't think this would explain its popularity alone.

And there is also the lost cause of vendoring that gained even more
traction with Go but that was already a problem with the Java ecosystem.
I don't think there is much to do about this one.
-- 
Don't sacrifice clarity for small gains in "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: third-party packages adding apt sources

[Vincent Bernat]

 ❦ 19 mai 2016 16:39 GMT, Bas Wijnen  :

> Debian stable is for users who want a rock solid system.  It is out of date by
> the nature of how it is built.  Users who want to get the newest versions of
> their software should not be running stable; testing is probably better for
> them.

testing is not suitable for most people because:

 1. no security support
 2. packages can disappear at any time

There was some discussion in the past to turn testing into a rolling
release but nothing was done. Such a project would be interesting to
check its adoption. People complaining that stuff is too old could be
directed to this rolling release version and we will likely get people
complaining that stuff moves too fast, but at least, we can't be blamed
to ship too old softwares, that would be a user choice.
-- 
As flies to wanton boys are we to the gods; they kill us for their sport.
-- Shakespeare, "King Lear"


signature.asc
Description: PGP signature

Re: third-party packages adding apt sources

[Mike Hommey]

On Thu, May 19, 2016 at 04:39:24PM +, Bas Wijnen wrote:
> > Hell, teams packaging Mozilla-soft and PostgreSQL are DDs maintaining
> > *external archives* because it's easier.
> 
> This indicates that our procedures are too hard.  That needs to be fixed.
> Maybe people from those teams are reading this and can comment on it?

FWIW, I'm maintaining mozilla.debian.net because we still don't have no
freaking PPAs despite the announcement a few years ago that we would have
them soon. I'm not holding my breath. Also because the process for
backports doesn't allow things that are not in testing to be in
backports, which means it is not possible to have a non ESR firefox
there.

Mike

Re: third-party packages adding apt sources

[Ian Jackson]

Paul Tagliamonte writes ("Re: third-party packages adding apt sources"):
> [cc'ing devel, since this is a rant that involves technical topics, and
>  god knows I only go on so many rants a year these days]

I think you may have only BCC'd -devel, or something.

> > Sometimes there is good reason their
> > package doesn't belong in Debian but sometimes it is more about inertia
> > in Debian or the upstream isn't aware about backports and thinks their
> > package will be stuck at a particular version forever
> 
> Frankly, I have a hell of a lot of sympathy for this.

I just wanted to say that while my own messages have been addressing a
rather different set of third-party repos, I don't really disagree
with the picture you paint.

> We have zero procedure in place for the following:

And I definitely agree with this complaint.

> Go to any mature project, they have a way to bypas the archive, and get
> the latest stable from upstream. This is a huge failure. Upstreams
> aren't becoming DDs and updating packages, dispite the fact they can
> package and maintain things.
> 
> Hell, teams packaging Mozilla-soft and PostgreSQL are DDs maintaining
> *external archives* because it's easier.

Yes.

Ian.

Re: third-party packages adding apt sources

[Ian Jackson]

Bas Wijnen writes ("Re: third-party packages adding apt sources"):
> On Thu, May 19, 2016 at 07:15:01PM +0200, Daniel Pocock wrote:
> > Another thing comes to mind: making sure that even if the user
> > explicitly allows some other repository, they are protected from package
> > updates that come along and replace other things like apt itself, libc,
> > bash, gnupg, ...
> 
> I don't think we want to prevent that.  If they want to install a
> package that does that, they can.  However, I think it is reasonable
> to warn them that they should get ready for trouble when installing
> a package that isn't from Debian, and especially if they install a
> new entry into sources.list from an external source.
> 
> I don't see how to technically do such a thing though; the problem is that
> these kind of upstreams often don't care about our (or their user's) systems
> and will inject any code in their package that makes the warnings go away.

If we provided a better, more official, way, that gave the relevant
software provider some kind of semi-approval, then we could probably
persuade the upstreams to start using it.

But I agree that playing core wars against the third party repo
packages is a really really bad idea.  It won't work.  It's a recipe
for craziness.  And it's unethical because it also amounts to playing
core wars against our users - who have, after all, probably decided
that this is what they want.

Ian.

Re: third-party packages adding apt sources

[Russ Allbery]

Daniel Pocock <dan...@pocock.pro> writes:

> Another thing comes to mind: making sure that even if the user
> explicitly allows some other repository, they are protected from package
> updates that come along and replace other things like apt itself, libc,
> bash, gnupg, ...

While this would be nice to prevent accidents, it's not clear that you can
really establish any security guarantees.  You can protect against some
very obvious things, such as wholesale replacing core packages, but
postinst scripts still run as root and can do anything they want.  So you
don't get any real security benefit here that I can see.

-- 
Russ Allbery (r...@debian.org)   <http://www.eyrie.org/~eagle/>

Re: third-party packages adding apt sources

[Ian Jackson]

Daniel Pocock writes ("Re: third-party packages adding apt sources"):
> On 19/05/16 19:04, Ian Jackson wrote:
> > Debian proper has a very high bar for inclusion.  Obviously there are
> > perhaps some packages which are close to suitable for inclusion, but
> > the vast majority of things that aren't in Debian proper are outside
> > it for real, nontrivial reasons (whether of technical quality of the
> > binaries, technical quality of the source, or political/ethical
> > reasons).
> 
> Do you think that if these upstreams became involved in other ways - for
> example, if we proactively invited them to MiniDebConfs and other events
> - we might bridge the gap to help them understand our way of thinking,
> whether it is technical or otherwise?

I think you are missing my point.  You seem to have the assumption
that for many of the people providing packages in third-party repos,
they don't have what I'm calling real and nontrivial reasons.

Hell, I even have .debs I distribute myself outside Debian (although I
haven't gone to the trouble of setting up reprepro).

> Sure, some of them will never change, some of them have no capacity to
> think long-term but there are others who simply don't quite understand
> and may go the extra mile if they get to know us a little better.

The problem is not one of lack of understanding.  These out-of-Debian
repos are not going to be abolished by an outreach and education
programme.


Let me go into more detail about a few of the kinds of real,
nontrivial reasons, I'm talking about:


1. Proper source format.  I wrote:

> > Providing a proper Debian source package is also a lot more work than
> > writing some kind of ad-hoc build system that spits out a .deb or
> > three.

Packages with ad-hoc source build systems are never going to be in
Debian proper, for obvious reasons.  They wouldn't fit.  That's not
something we can fix.

But writing a proper build system for an ad-hoc Debian source package
is a fair amount of work.  I did it recently for a moderately easy
package I encountered in Raspbian, and it took /me/ most of a day.

That upstream didn't do it is quite understandable.  Doing so was not
in their `long-term' interests, as you put it: the effort for them to
learn how to do it, and then do it, and then debug it, and then deal
with the transitional pain, was simply not worth it to them.  And
probably not to their userbase, either.

We in Debian can improve this situation by making proper Debian source
packages easier to build.  For example, we can:
 * Provide build tools which require less boilerplate, are less
   fragile, and are more automatic.  Yay dh(1).
 * Provide _shorter_ intro documentation.
 * Provide better source code management systems - that are less
   prehistoric than .dsc 1.0 (non-native) and less "omg wtf bbq"
   than .dsc "3.0 (quilt)".  (non-crazy git integration, dgit)

But there are still going to be plenty of people for whom it's a
better use of their time to do something else but tart up the source
for their .deb builds.


2. ABI/API

The package I mention above didn't take the care with API/ABI, split
library packaging, and so on, that would be expected in Debian.  This
was tolerable in the original Raspbian context.

I sent the upstream patches to fix this but there are compatibility
implications with changing the packaging arrangements.  Thinking about
this stuff, and planning for it, and anticipating the needs of the
users, is nontrivial.

For quite a few packages, the levels of compatibility and
upgradeability we would expect in Debian are simply not worth the
effort.  I don't think in Debian we would want to relax this, do we ?


3. Freedom

This is the killer reason to provide a third-party apt repository.

A software provider who provides packages outside Debian does not need
our permission to do so; they do not need our help to provide new
versions; they do not need to confirm to our release rules.

Of course in Debian our focus is freedom for our users, so there are
limits to how much freedom we want to make available to upstreams and
third-party packagers: we want to avoid becoming complicit in efforts
to control users.  But users often choose (for reasons that seem good
to those users - and, often, reasons that /are/ good for those users)
to want to run non-free software.  So even when it concerns non-free
software we need to respect and support that decision, while avoiding
encouraging it.

I don't think an outreach campaign by Debian, encouraging people to do
work in Debian rather than outside, is going to significantly change
the way software providers make decisions about licensing, release
schedules, or whatever.


> Another thing comes to mind: making sure that even if the user
> explicitly allows some other repository, they are protected from package
> updates that come along and replace other things like apt itself, libc,
> bash, gnupg, ...

This has to be an optional feature.  The user might specifically want
that !

Ian.

Re: third-party packages adding apt sources

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, May 19, 2016 at 07:15:01PM +0200, Daniel Pocock wrote:
> Another thing comes to mind: making sure that even if the user
> explicitly allows some other repository, they are protected from package
> updates that come along and replace other things like apt itself, libc,
> bash, gnupg, ...

I don't think we want to prevent that.  If they want to install a package that
does that, they can.  However, I think it is reasonable to warn them that they
should get ready for trouble when installing a package that isn't from Debian,
and especially if they install a new entry into sources.list from an external
source.

I don't see how to technically do such a thing though; the problem is that
these kind of upstreams often don't care about our (or their user's) systems
and will inject any code in their package that makes the warnings go away.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXPfugAAoJEJzRfVgHwHE61mcQAKQzjwht59J73zievxLTlqoz
QNMnmorJJb5vvx1PDwJzfqqL4rqRPu5/h9wiHjYhi+O3YM2J8W4phKxyMNIDYR1R
p+BA1CwSUuGX3/4je1QWaNpHa6IpgU9HxlUtrLNnjhJvtAuRR4PXfv15tPxsGgxi
AT5770XMSuCjNSehpC5nhp2l9HFiaRnaTa8tIENf6Bj1NrXrH/Em2/3CKbZiTkTf
S5C0IHWPTJyIYGqRALub+DiVvYd/d2ZNdFAwRW3/8nyJeBLwEkQ9BO8mNOdBHZWF
Fbvi0WJ5bBo1mcIVc9vO/4QvrFGPqxXYo8Sf+dI2O/NmzKdQ6XXwcy30HL8R/DhD
gZzhOJLnJFmUTpvqUAv1ywt9mfqNE4ed7/9ccN+4nTVHNSbxqJZyEimIi6x7dZop
dYZvdjoDgHRBFG7cBaGGH0Dqb+r0fSkP05Foxxy3ShITMzYQRPDzRPmxRxaU6ojB
Y5+GLQ3wlEMmiNsK34y1pQcJYKI5B7d+LYS1B/K5/Enkv7Z+4n8CX2AHtRMDmpHt
wQYKKaHjOktGZQonE1fF0vb4WE4otoidAyyN0jnlQDlq9aTp4OHDFcx5o8u6ppgG
LmKw7YTosFwzd37kHmH7icwvXiPHwIvHwR+9Vt/0wra/juD9Xktom2TtuA02MwIY
nPAD/aVlO95tD43+9EQP
=54DY
-END PGP SIGNATURE-

Re: third-party packages adding apt sources

[Hakan Peker]

On 05/19/2016 06:18 PM, Daniel Pocock wrote:


More and more frequently I'm encountering systems where third-party
repositories have been added into /etc/apt/sources.list or
/etc/apt/sources.list.d, usually put there by some .deb package that a
user installed from some third party site.



Hey, This is a good thing™! I'm glad some upstreams care enough for 
Debian that they build deb packages of their releases and I'm even more 
delighted they are doing it properly by serving them in an apt repository.


This doesn't mean there is no benefit in discussing problematic areas or 
potential improvements in providing them also in Debian repository, but 
please don't pressure the poor upstreams too much making them feel like 
they are doing a disservice by providing a deb package to their users 
comfort.



 From a technical perspective, can we do more to prevent users being
surprised by packages putting new entries in /etc/apt/sources.list.d?

Please no. The system is working as intended. I don't think anybody is 
surprised after installing a 3rd party deb package and seeing it adds 
its apt repository to the system, actually they would be pleased to know 
that they won't have to manually update it later. And anybody who is 
uncomfortable with it would either disable it or not install the deb in 
the first place.




-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

Re: third-party packages adding apt sources

[Daniel Pocock]

On 19/05/16 19:04, Ian Jackson wrote:
> Daniel Pocock writes ("third-party packages adding apt sources"):
>> b) many upstreams appear frustrated about getting their package
>> officially supported in Debian.  Sometimes there is good reason their
>> package doesn't belong in Debian but sometimes it is more about inertia
>> in Debian or the upstream isn't aware about backports and thinks their
>> package will be stuck at a particular version forever
> 
> Providing a proper Debian source package is also a lot more work than
> writing some kind of ad-hoc build system that spits out a .deb or
> three.
> 
>> From a technical perspective, can we do more to prevent users being
>> surprised by packages putting new entries in /etc/apt/sources.list.d?
> 
> IMO we should set up a registry of such organisations, and their
> cryptographic keys, and at least document promises made by the
> organisation about its behaviour with respect to various principles
> that we might care about.
> 
> (For example, "this repo only contains packages which are dfsg-free
> and come with source code"; "this repo contains packages which do not
> themselves phone home"; ...)
> 
>> From an organizational perspective, can we do more to make contact with
>> such upstreams and try to find ways to involve them in releasing their
>> packages through official channels?  Is there any way we could gather
>> data about how many upstreams do this without compromising user privacy?
> 
> Debian proper has a very high bar for inclusion.  Obviously there are
> perhaps some packages which are close to suitable for inclusion, but
> the vast majority of things that aren't in Debian proper are outside
> it for real, nontrivial reasons (whether of technical quality of the
> binaries, technical quality of the source, or political/ethical
> reasons).
> 

Do you think that if these upstreams became involved in other ways - for
example, if we proactively invited them to MiniDebConfs and other events
- we might bridge the gap to help them understand our way of thinking,
whether it is technical or otherwise?

Sure, some of them will never change, some of them have no capacity to
think long-term but there are others who simply don't quite understand
and may go the extra mile if they get to know us a little better.

> What we need to do is provide an easier and better way for unofficial
> repositories.  That means an easy way for third party software
> providers to publish repositories which it is then easy for users to
> use, if the user chooses to do so.
> 
> Importantly, we need:
> 
> 1. A way for the user to get good, trustworthy (ie, coming in some
>sense from Debian), information about the repository.  Including
>the identity of the organisation providing it; and some
>classification of Debian's opinion about the software in it.
> 
> 2. A way for the user to reliably get the public keys on their system,
>that doesn't involve them clicking on a .deb on the public
>internet.
> 


Another thing comes to mind: making sure that even if the user
explicitly allows some other repository, they are protected from package
updates that come along and replace other things like apt itself, libc,
bash, gnupg, ...

Re: third-party packages adding apt sources

[Ian Jackson]

Daniel Pocock writes ("third-party packages adding apt sources"):
> b) many upstreams appear frustrated about getting their package
> officially supported in Debian.  Sometimes there is good reason their
> package doesn't belong in Debian but sometimes it is more about inertia
> in Debian or the upstream isn't aware about backports and thinks their
> package will be stuck at a particular version forever

Providing a proper Debian source package is also a lot more work than
writing some kind of ad-hoc build system that spits out a .deb or
three.

> From a technical perspective, can we do more to prevent users being
> surprised by packages putting new entries in /etc/apt/sources.list.d?

IMO we should set up a registry of such organisations, and their
cryptographic keys, and at least document promises made by the
organisation about its behaviour with respect to various principles
that we might care about.

(For example, "this repo only contains packages which are dfsg-free
and come with source code"; "this repo contains packages which do not
themselves phone home"; ...)

> From an organizational perspective, can we do more to make contact with
> such upstreams and try to find ways to involve them in releasing their
> packages through official channels?  Is there any way we could gather
> data about how many upstreams do this without compromising user privacy?

Debian proper has a very high bar for inclusion.  Obviously there are
perhaps some packages which are close to suitable for inclusion, but
the vast majority of things that aren't in Debian proper are outside
it for real, nontrivial reasons (whether of technical quality of the
binaries, technical quality of the source, or political/ethical
reasons).

What we need to do is provide an easier and better way for unofficial
repositories.  That means an easy way for third party software
providers to publish repositories which it is then easy for users to
use, if the user chooses to do so.

Importantly, we need:

1. A way for the user to get good, trustworthy (ie, coming in some
   sense from Debian), information about the repository.  Including
   the identity of the organisation providing it; and some
   classification of Debian's opinion about the software in it.

2. A way for the user to reliably get the public keys on their system,
   that doesn't involve them clicking on a .deb on the public
   internet.

If we had such a thing, dealing with the admin of it would be a
nontrivial task.  It would have to be distributed.

Ian.

Re: third-party packages adding apt sources

[Adam D. Barratt]

On 2016-05-19 17:39, Bas Wijnen wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, May 19, 2016 at 11:46:53AM -0400, Paul Tagliamonte wrote:
[cc'ing devel, since this is a rant that involves technical topics, 
and

 god knows I only go on so many rants a year these days]


You didn't actually do this.


https://lists.debian.org/debian-devel/2016/05/msg00277.html disagrees 
(modulo quibbles on naming).


Regards,

Adam

Re: third-party packages adding apt sources

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, May 19, 2016 at 11:46:53AM -0400, Paul Tagliamonte wrote:
> [cc'ing devel, since this is a rant that involves technical topics, and
>  god knows I only go on so many rants a year these days]

You didn't actually do this.

> > Sometimes there is good reason their
> > package doesn't belong in Debian but sometimes it is more about inertia
> > in Debian or the upstream isn't aware about backports and thinks their
> > package will be stuck at a particular version forever
> 
> Frankly, I have a hell of a lot of sympathy for this.

So do I, but I disagree with your solution.  Here's how I see it:

Debian stable is for users who want a rock solid system.  It is out of date by
the nature of how it is built.  Users who want to get the newest versions of
their software should not be running stable; testing is probably better for
them.

When programs get packaged outside of unstable, we should look at why that
happens, and try to convince the packager to do it inside Debian instead.
(This convincing may take the form of adding features to our system that solve
their problems.)

When users or upstreams complain that the version in stable isn't up to date,
we should explain to the users that they probably want to use testing.  If this
is a common problem for upstreams, our user documentation about this is not
sufficiently clear.

When users want to run stable with one or two packages cherry-picked from
backports, that is something which we may want to make easier for them.

> Backports are a whole thing. People have to be actively aware of them.
> Users have to be told to add a new thing in the sources by hand, and
> install something explicitly. It's calories, and explaining a Debian
> process to a user isn't fun. Why would upstreams want to do this?

Agreed, we should make this easier; allow DDs and the package uploader to
trigger building a backport for any package that is in testing by sending an
e-mail, perhaps?

And aside from that, I agree that it should be easier to install a system that
includes backports in the sources.list.

> My claim, as I'll outline below, is, if the upstream wants to give the
> user an up-to-date software package, and they have to teach them how to
> add a new archive, they'll give them an archive *they control*, because
> they're now on the hook for delivering through that channel. Upstream
> wants to spend as little time as they can with this, so they make it
> easy - they make a deb.

Yes.  I do this myself for some experimental packages that I don't consider
ready for the general public yet.  That is IMO a valid reason for having a
private repository.  "Doing it right is too hard" is not; that is something we
should fix.

> Backports are present when a package is in testing, and backports are a
> single channel. Backports are not for upstream's releases, whenever they
> want to ship a thing.

If we make it easy for them to become DDs or DMs and for uploaders to trigger
backports builds, backports can be what upstream wants.

> We have zero procedure in place for the following:
> 
>   - Totally unsupported very old version of ${FOO} in stable, maintainer
> isn't patching bugs, bugs are going to upstream, and upstream is
> annoyed Debian has out of date, perhaps insecure thing X.

Yes, this is a different problem.  We may want to shield upstream from
bugreports for those packages somehow.

IMO it would be good to recommend our users to file all bugs with us, and leave
it to the maintainer to pass them to upstream.  I have upstreams that follow
our bug tracker, which is great.  But if they don't, it should be up to me to
decide whether the report is worth their time.

>   - Leaf package ${BAR} has a robust upstream community, where releases
> are very well tested, with a mature stable/unstable release cycle.
> Our stable release freeze was off by a few months, so we've been
> shipping their 'oldstable' in our 'stable' for years. The
> maintainers are annoyed we don't use the latest stable in our
> stable.

If the bugreports go through us, they shouldn't have a problem with this.  It
is up to the users to choose who they trust.  If they trust upstream not to
break things (which for some upstreams is totally justified, but for others it
isn't), they can get the new package from backports (assuming that we made that
easy, so the new version is in there).  If they only trust us, they use the
older version and there is nothing wrong with that.  If upstream doesn't want
that to happen, tough luck.  It's our job to give users what they want, not to
force onto them what upstream wants.

> Largely, I think the first situation is a common one that our culture
> has forced people to group-think "Well, that's bad and the system is
> working as intended". We can't let software change on our stable
> installs, so this situation is bad, but the intent of stable.

I think it is the intent of stable, and it's good.  

Re: third-party packages adding apt sources

[Holger Levsen]

On Thu, May 19, 2016 at 08:45:09AM -0700, Russ Allbery wrote:
> I don't think we can provide that inside Debian, at least without some
> pretty significant changes to how we handle stable releases that are
> contrary to some of our goals for stable.

I think I heard someone saying "PPA" or such…

;-)

(But I don't think those would be suitable for Chrome from Google.)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: third-party packages adding apt sources

[Paul Tagliamonte]

[cc'ing devel, since this is a rant that involves technical topics, and
 god knows I only go on so many rants a year these days]

On Thu, May 19, 2016 at 05:18:28PM +0200, Daniel Pocock wrote:
> b) many upstreams appear frustrated about getting their package
> officially supported in Debian.

Yeah, I don't think that's it. "officially supported" is burrying a lot
of really important discussion we're not having.

> Sometimes there is good reason their
> package doesn't belong in Debian but sometimes it is more about inertia
> in Debian or the upstream isn't aware about backports and thinks their
> package will be stuck at a particular version forever

Frankly, I have a hell of a lot of sympathy for this.

Backports are a whole thing. People have to be actively aware of them.
Users have to be told to add a new thing in the sources by hand, and
install something explicitly. It's calories, and explaining a Debian
process to a user isn't fun. Why would upstreams want to do this?


My claim, as I'll outline below, is, if the upstream wants to give the
user an up-to-date software package, and they have to teach them how to
add a new archive, they'll give them an archive *they control*, because
they're now on the hook for delivering through that channel. Upstream
wants to spend as little time as they can with this, so they make it
easy - they make a deb.


Now, for the rant I promised.


Backports are present when a package is in testing, and backports are a
single channel. Backports are not for upstream's releases, whenever they
want to ship a thing.

We have zero procedure in place for the following:

  - Totally unsupported very old version of ${FOO} in stable, maintainer
isn't patching bugs, bugs are going to upstream, and upstream is
annoyed Debian has out of date, perhaps insecure thing X.

  - Leaf package ${BAR} has a robust upstream community, where releases
are very well tested, with a mature stable/unstable release cycle.
Our stable release freeze was off by a few months, so we've been
shipping their 'oldstable' in our 'stable' for years. The
maintainers are annoyed we don't use the latest stable in our
stable.


We can talk about what is an isn't right all day long, or about how PPAs
are going to solve all this one day, but I've become more and more
worried that we're failing to serve users in this way.

Largely, I think the first situation is a common one that our culture
has forced people to group-think "Well, that's bad and the system is
working as intended". We can't let software change on our stable
installs, so this situation is bad, but the intent of stable.

The second one is harder to say that with, since upstream is making
assertions (just as strong as us) on some things. Be it protocol
stability, API stability, or whatever.

We're mostly approximating #2 by stacking up patches from their next
stable, and applying them to our stable. We're basically shipping the
new version with the old version number, without as much testing as the
real version, and only confusing ourselves (patches are a bitch), users
(I have version 1.2), and upstreams (why doesn't Debian trust the
release process), causing tension everywhere. Look at OpenSSL, it's
nuts. (God bless the OpenSSL team for doing this, and finding a way to
keep DDs happy -- or rather -- merely quiet, as well as upstreams and
users).

So, your question, why do people try to make it easy to get the latest
stable software is answered simply with "because we're not". We are the
problem. No one wants to do this. Maintianing an archive sucks. No one
wants to maintain a Debian archive. It's just the least work to deliver
something supportable and maintainable to users.

Go to any mature project, they have a way to bypas the archive, and get
the latest stable from upstream. This is a huge failure. Upstreams
aren't becoming DDs and updating packages, dispite the fact they can
package and maintain things.

Hell, teams packaging Mozilla-soft and PostgreSQL are DDs maintaining
*external archives* because it's easier.

The issue is, we have a model of software delivery that's slowly growing
more and more distant from the realities of shipping software today. Why
is this? What can we do? What do our users want? What do our users
*expect*?

Making it hard to install a new archive will only lead to more
workarounds, more FAQs telling users to dismiss warnings, and more
upstreams hell-bent on working against us, because we keep making their
lives harder.


This is a 100% larger conversation, and it's not about a hacky deb, it's
about how our place in the software ecosystem has been evolving, and we
need to evolve with it, or we'll find ourselves part of the problem we
were trying to solve in the first place.


signature.asc
Description: PGP signature

Re: third-party packages adding apt sources

[Russ Allbery]

Daniel Pocock  writes:

> b) many upstreams appear frustrated about getting their package
> officially supported in Debian.  Sometimes there is good reason their
> package doesn't belong in Debian but sometimes it is more about inertia
> in Debian or the upstream isn't aware about backports and thinks their
> package will be stuck at a particular version forever

One of the big reasons why organizations do this is because they provide
packages for stable users and want control over exactly when they ship new
packages to those users without meeting the standards for stable update
review (which are very strict).  Consider Google Chrome's packages, for
example, which are one set that use this method.

I don't think we can provide that inside Debian, at least without some
pretty significant changes to how we handle stable releases that are
contrary to some of our goals for stable.

-- 
Russ Allbery (r...@debian.org)   

third-party packages adding apt sources

[Daniel Pocock]

More and more frequently I'm encountering systems where third-party
repositories have been added into /etc/apt/sources.list or
/etc/apt/sources.list.d, usually put there by some .deb package that a
user installed from some third party site.

There are a few things going on here:

a) the .deb format is convenient and respected so when a user sees a
.deb file, they have the impression it is easy to install and
potentially trustworthy

b) many upstreams appear frustrated about getting their package
officially supported in Debian.  Sometimes there is good reason their
package doesn't belong in Debian but sometimes it is more about inertia
in Debian or the upstream isn't aware about backports and thinks their
package will be stuck at a particular version forever

From a technical perspective, can we do more to prevent users being
surprised by packages putting new entries in /etc/apt/sources.list.d?

From an organizational perspective, can we do more to make contact with
such upstreams and try to find ways to involve them in releasing their
packages through official channels?  Is there any way we could gather
data about how many upstreams do this without compromising user privacy?

Processed: soap_use_proxy problem still exists with apt-listbugs

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

 unarchive 399706
Bug #399706 {Done: akira yamada ak...@debian.org} [project] soap4r should not 
request USE_SOAP_PROXY, or it should be standardized
Bug #396304 {Done: akira yamada ak...@debian.org} [project] soap4r should not 
request USE_SOAP_PROXY, or it should be standardized
Unarchived Bug 399706
Unarchived Bug 396304
 reassign 399706 apt-listbugs 0.1.3
Bug #399706 {Done: akira yamada ak...@debian.org} [project] soap4r should not 
request USE_SOAP_PROXY, or it should be standardized
Bug #396304 {Done: akira yamada ak...@debian.org} [project] soap4r should not 
request USE_SOAP_PROXY, or it should be standardized
Bug reassigned from package 'project' to 'apt-listbugs'.
Bug reassigned from package 'project' to 'apt-listbugs'.
Ignoring request to alter found versions of bug #399706 to the same values 
previously set
Ignoring request to alter found versions of bug #396304 to the same values 
previously set
Ignoring request to alter fixed versions of bug #399706 to the same values 
previously set
Ignoring request to alter fixed versions of bug #396304 to the same values 
previously set
Bug #399706 {Done: akira yamada ak...@debian.org} [apt-listbugs] soap4r 
should not request USE_SOAP_PROXY, or it should be standardized
Bug #396304 {Done: akira yamada ak...@debian.org} [apt-listbugs] soap4r 
should not request USE_SOAP_PROXY, or it should be standardized
Marked as found in versions apt-listbugs/0.1.3.
Marked as found in versions apt-listbugs/0.1.3.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
396304: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=396304
399706: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399706
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.133566920928182.transcr...@bugs.debian.org

Private/authenticated APT

[Stephen Paul Weber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Has there ever been any interest in supporting private/authenticaed APT
repositories (possibly by using oAuth or BasicAuth in the HTTP transport)?

I've recently become interested in being able to do this, but I'm not sure
it's possible with APT right now, though it seems it wouldn't be too hard to
add.

I do not subscribe to this list, and would appreciate replies being also
sent to my email addresss.

- -- 
Stephen Paul Weber, @singpolyma
Please see http://singpolyma.net for how I prefer to be contacted.
edition right joseph
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJMxyzHAAoJENEcKRHOUZze/6kP/0Okm7rqkDWfXFeDx2aeiWIz
noELVi8mGbPk0sXZ9UQvweYaOoyd08NIPXfCG0flMJiNm+eqXcjN234en5o+FYeO
Nd9p5gU/EMHtjLuoUjtAnaXlhk7MKuEw4hlquJlBGEZ3jo/j9AALZ0tuFatLpbLV
aF8xlABlDBHbBP0fxg+C5uoVoPr2WX+K2ejF8hMQlW4rh5oI0O0ozQK3tpwD/Ovj
rhLKKff34pfPK8rmtc791XMZKEhaqFl+FeGsG/6r3Rbvw8RDN43dOkmh97Erhwot
9NcOi7Gm3XcOifDbshHR72hHOWnWBgXKZad6pWRQqg4LelP5FxwTHqvTnKHAqNcu
CjeSX757SE/aZBoVBrk3F8UDcP8tJ5qpLbczon/TIce1RDnuq7raH4rgeIjcPJz5
uzx5Zw9eYdmf9RlO1r6zPKvlXyXOavcmksAxVIzYr2cxUd/P/6eBT06JXTx1o4jq
sI0BF4spxkjOHCElD1idq05Ry2+rKVvtLo9SPhZrlutnSEOA0ZwcxlLzYLOYcIvB
ADN9Z9FMc/sUV0IWUBlIo9+1IMkPNXDp/7QBYm84dX5GJ3ROeKpcN+E+ISAeJYYV
JTyjV3BJ+I6DeZAC8gPtqzGdQ9R3eh5tiWQsW2Z8zwTF12lNujIbF0x/jIL4EKP/
AAewjGepDiSfbTlH+dZo
=3tba
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101026193224.ga9...@mediacentre

Re: Private/authenticated APT

[David Kalnischkies]

Hi Stephen,

On Tue, Oct 26, 2010 at 21:32, Stephen Paul Weber
singpol...@singpolyma.net wrote:
 Has there ever been any interest in supporting private/authenticaed APT
 repositories (possibly by using oAuth or BasicAuth in the HTTP transport)?

 I've recently become interested in being able to do this, but I'm not sure
 it's possible with APT right now, though it seems it wouldn't be too hard to
 add.

BasicAuth is supported - either write the credentials directly into the
sources.list or use a netrc-like auth.conf file to store your credentials
(the later is only available in squeeze).

You could also use all kinds of SSL stuff for authenticate server as well
as the clients (X.509), just see
/usr/share/doc/apt/examples/apt-https-method-example.conf.gz
(some stuff was added since lenny here, but most should be available in lenny)

Still, feel free to join the de...@l.d.o mailinglist if you want to work
on oAuth or if you want to work on other stuff related to APT,
new vict…^W contributors are always welcomed. :)


 I do not subscribe to this list, and would appreciate replies being also
 sent to my email addresss.

Done.


Best regards

David Kalnischkies


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikfa9gi=r8r3b8uqeit4gyjezkts0+w4tbhl...@mail.gmail.com

Looking for SoC mentor for apt-checkpoint project

[Alexey Mikhailov]

Hello!

There's apt-checkpoint project listed at Debian Wiki:

http://wiki.debian.org/SummerOfCode2007/AptCheckpoint

But there's no mentor listed as well. I'm interested in this project
and i wrote draft version of my application. Maybe someone
can be mentor for this project and discuss this project with
me?

Thank you!

Re: APT copyright

[Alexander Schmehl]

Dear Heidi,

* Heidi Nicewander [EMAIL PROTECTED] [070309 20:04]:

 I was wondering if you have a copyright for APT.  The Department of
 Human Services for Michigan wants to use APT (Adoptive Parent
 Training) as a part of a new program.

No, we don't have a copyright on the term APT itself, so they are free
to use it.  Anyway thanks for mailing us!


Yours sincerely,
  Alexander Schmehl,
  Debian Developer and spokesman


PS:  As far as I know It would still be okay for them to use the term
APT even if we had a trademark on that term, since their field of
activity is unrelated to ours.


signature.asc
Description: Digital signature

Re: APT copyright

[Hamish Moffatt]

On Fri, Mar 09, 2007 at 02:24:22PM -0500, Roberto C. Sanchez wrote:
 On Fri, Mar 09, 2007 at 02:04:45PM -0500, Heidi Nicewander wrote:
  Hello,
  
  I was wondering if you have a copyright for APT.  The Department of
  Human Services for Michigan wants to use APT (Adoptive Parent
  Training) as a part of a new program.
  
  Thanks for your time,
  Heidi Nicewander
  
 I think that you are confusing copyright with trademark.

Maybe so, but you didn't answer her question. Regardless of whether we
have a trademark for apt, it wouldn't prevent the same term being used for
Adoptive Parent Training as it's an unrelated use.

Hamish
-- 
Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]


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

APT copyright

[Heidi Nicewander]

Hello,

I was wondering if you have a copyright for APT.  The Department of
Human Services for Michigan wants to use APT (Adoptive Parent
Training) as a part of a new program.

Thanks for your time,
Heidi Nicewander


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

Re: APT copyright

[Roberto C. Sanchez]

On Fri, Mar 09, 2007 at 02:04:45PM -0500, Heidi Nicewander wrote:
 Hello,
 
 I was wondering if you have a copyright for APT.  The Department of
 Human Services for Michigan wants to use APT (Adoptive Parent
 Training) as a part of a new program.
 
 Thanks for your time,
 Heidi Nicewander
 
I think that you are confusing copyright with trademark.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


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

apt

[Igor Bogomazov]

Hello,

I just received a mail from one friend of mine, he reported aptitude
retrieves updated package list from servers (included in
/etc/apt/sources.list) by diffs, i.e. does not download the whole
list, but only modifications (like patches). Sorry if I cannot
epxress clear.

Please approve or reject this information. And don't you intend to
make package upgrades by diffs (or deltas, but I do not know
difference) like one could use on SuSe or Gentoo?

Thank you

-- 
Igor Bogomazov (Russia, St. Petersburg)



signature.asc
Description: Digital signature

Re: apt

[Linas Žvirblis]

Igor Bogomazov wrote:

 I just received a mail from one friend of mine, he reported aptitude
 retrieves updated package list from servers (included in
 /etc/apt/sources.list) by diffs, i.e. does not download the whole
 list, but only modifications (like patches). Sorry if I cannot
 epxress clear.

Your friend was right. A shiny new feature for all of us to enjoy.

 Please approve or reject this information. And don't you intend to
 make package upgrades by diffs (or deltas, but I do not know
 difference) like one could use on SuSe or Gentoo?

Read [1] and please post similar questions to debian-user in the future.

[1] http://lists.debian.org/debian-devel/2006/04/msg01093.html


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

Thank you for apt!

[michael king kong]

First off i would like to say i love Debian greatly.  I love apt as
well.  15,000+ packages is simply amazing and its the main reason why
I used Debian.  I would like to suggest some very simple features that
i feel would greatly improve apt.

When you are setting up a new system you have to install a number of
new pieces of software.  It would be nice if you could run more than
once instance of apt.

It would also be nice if I could connect to a number of mirrors and
download from multiple sources.  Maybe running a trace route to all of
the apt mirrors at install and using the top 5 or whatever closest
mirrors.   Splitting up a file into multiple peaces would be nifty, 
but it would add a greater level of complexity.  As would a p2p model
like BitTorrent, which I would most defiantly donate my spare
bandwidth to apt.   I think if there is multiple files to be
downloaded then it should only download one file from one mirror or
something to that effect, possibly going down the list of mirrors that
is sorted by distance from the computer.  I am not sure how
synchronized the apt mirrors are,  but I assume a number of them are
pretty stable.   This would speed up the update and download process
as well as spread the bandwidth between the mirrors more evenly.

I am not sure if I download a whole new package list every time I do a
apt-get update.  But it would be nice if I notified the mirror when I
last updated and then the server only responds with the new listings. 
 This would save a few seconds and a few k,  but though seconds and k
add up.

I am not sure that everyone knows about apt-get clean,  maybe an
automated system that runs apt-get clean periodically would be in
order.

Thank you for very much Debian and apt,  i use it every day, and i am
not sure what i would do with out it.

peace

Re: Thank you for apt!

[martin f krafft]

First off, thank you for your compliments, Michael!

 When you are setting up a new system you have to install a number
 of new pieces of software.  It would be nice if you could run more
 than once instance of apt.

This is a wish often voiced by our users. So far, we have not really
found the time to conceive how to implement this as it's
non-trivial and there are many design decisions involved (and we
have been busy integrating archive signatures into APT, and getting
sarge ready).

If you would like to discuss this issue further, may I suggest
taking it to the APT development list, which is
[EMAIL PROTECTED]

 It would also be nice if I could connect to a number of mirrors
 and download from multiple sources.  Maybe running a trace route
 to all of the apt mirrors at install and using the top 5 or
 whatever closest mirrors.  

Well, apt-spy helps you find the fastest mirror. The main problem
with multiple connections, as I see it, is that mirrors may not all
be exactly the same. In fact, only the primary mirrors are
push-updated, and of these, only one of two exist per country -- if
at all. Thus, it would probably not make sense to connect to three
others, as they'd be too far away. After all, mirrors also exist to
lower the load on the individual server, and one of the best ways to
do this is using geography and to expect the users to choose the
closest mirror.

Secondary mirrors are updated once every 24 hours, so any two of
them may not be in sync. Of course you could just connect to find
out that it does not have the file yet, then use another mirror, but
then I doubt there would be a real benefit.

One thing we are working on is providing diffs between package
indices and packages, so that the downloads required for updates are
going to become less

 Splitting up a file into multiple peaces would be nifty, but it
 would add a greater level of complexity.  As would a p2p model
 like BitTorrent, which I would most defiantly donate my spare
 bandwidth to apt.   I think if there is multiple files to be
 downloaded then it should only download one file from one mirror
 or something to that effect, possibly going down the list of
 mirrors that is sorted by distance from the computer.  I am not
 sure how

Again, if you would like to discuss the technical details, please
come to the deity mailing list.

 I am not sure if I download a whole new package list every time I do a
 apt-get update.  But it would be nice if I notified the mirror when I
 last updated and then the server only responds with the new listings. 
  This would save a few seconds and a few k,  but though seconds and k
 add up.

This is being worked on. Unfortunately, I do not have the URL handy
right now. Maybe someone else has it?

 I am not sure that everyone knows about apt-get clean,  maybe an
 automated system that runs apt-get clean periodically would be in
 order.

Check out cron-apt.

Cheers,

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
the strength of women comes from the fact
 that psychology cannot explain us.
 men can be analyzed, women merely adored.
-- oscar wilde


signature.asc
Description: Digital signature

Re: dynamic partial mirror, apt-get fails

[Wouter Verhelst]

Op ma, 04-04-2005 te 19:16 +0100, schreef Cristian Barbarosie:
 Hi everybody,
 
 I am trying to implement a cgi script for mirroring a small part of a 
 large collection of files (the debian distribution). The idea is to 
 mirror only those files which are requested, by downloading them on the 
 fly when the clients request them.

That's such a great idea, that it has already been implemented ;-)

You may want to have a look at apt-cacher.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: APT 0.6: let's get started

[Martin Schulze]

Michael Banck wrote:
 On Sat, Feb 19, 2005 at 05:50:18PM +0100, martin f krafft wrote:
  I am not in the position to complain at this stage in the game, but
  I think it would have been nice for you to quickly announce the
  location of continuation of this discussion here...
 
 It's the APT development list, so it's what everybody would expect as
 location for this discussion.

Everybody?  Nope.  Counterproof above.

Regards,

Joey

-- 
Life is a lot easier when you have someone to share it with.  -- Sean Perry


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

Re: Take APT 0.6 discussion public!

[Andreas Barth]

* martin f krafft ([EMAIL PROTECTED]) [050216 16:30]:
 also sprach Anthony Towns aj@azure.humbug.org.au [2005.02.16.1541 +0100]:
  Yes. If we weren't we might wake up one day and mistakenly think
  it might be possible to have discussions on Debian lists that
  didn't involve gratuitous insults.

 I described the situation as perceived by numerous (if not most)
 developers. If it is an insult to you, maybe you are doing something
 wrong?

Actually, you didn't describe a situation, but you converted a
discussion aiming for a solution of a particular problem into (untrue)
accusations against developers who really work hard on Debian, and just
for the single reason that Joey indicated that creating a new mailing
list hosted at your site might not be the best way to get a quick and
good result.

Sorry, but that really sucks.  If you are not interested in helping
but just want to have your domainname advertised, than please say so,
but don't start throwing your sandbox moulds at others who work.


And, please accept it from me:  I am _really_ disappointed.  I brought
the issues open with apt 0.6 up in public in hope to get to a solution,
but you managed to convert it into a flamewar that steals time and
energy instead of helping.  What do you think that your behaviour will
promote - open discussions or hiding discussions from you?



Andi

PS: And, BTW, _please_ configure your MUA/MTA to not use
localhost.localdomain.
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: APT 0.6: let's get started

[Florian Weimer]

* martin f. krafft:

 Florian: what's the status? Can we get started?

There's already a discussion on the deity mailing list.  At this
stage, we have to identify potential showstoppers, then we can decide
on which things we should work first.

It's certainly necessary to check if APT frontends still work when
compiled and linked against APT 0.6, to ensure that there won't be any
regressions (even though the frontends cannot handle a compromised
archive yet).  So if you're eager to work on something...

Unfortunately, most tasks which lay ahead are rather dull work. 8-(

 Who will be working on this, and where do we coordinate?

I'm maintaining a status page.  (No, it's not yet public.)


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

Re: APT 0.6: let's get started

[Michael Banck]

On Sat, Feb 19, 2005 at 05:50:18PM +0100, martin f krafft wrote:
 I am not in the position to complain at this stage in the game, but
 I think it would have been nice for you to quickly announce the
 location of continuation of this discussion here...

It's the APT development list, so it's what everybody would expect as
location for this discussion.


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Take APT 0.6 discussion public! (was: Bits from the DAMs)

[martin f krafft]

also sprach martin f krafft [EMAIL PROTECTED] [2005.02.15.1101 +0100]:
  I'd rather have this discussion on debian-devel or debian-dpkg
  since that's a logical place where more people are able to get
  involved and find the archive much easier than a strangely named
  list on the mad duck site.
 
 Mh, as you wish... sorry for trying to be productive. I'll remove
 the list. Should Florian decide on a separate discussion forum,
 then lists.alioth.debian.org it should be.

Reflecting on this, you are (of course) right, Joey. We should
always try to remain as open as possible and not segregate into
groups and thus make it harder for people to stay on top of
development.

Obviously, for reasons unknown to the mere mortals, the above only
applies to topics of the mere mortals of Debian, not to certain
members of the cabal. Some vital components of the Debian project
are better kept away from the public, or they could be flooded with
opinions or suggestions for improvement, or even gasp help
(ftpmasters, are you listening?). Such parts of the Debian project
should be handled (if at all) in the cellar, far away from public
view. And thou shalt not ever report to the outside, so that the
broad public gets the impression that, in fact, you do not exist.

Yay for public development. Let's keep discussion about APT 0.6
visible to everyone! Sorry for creating the list in the first place.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: Take APT 0.6 discussion public!

[martin f krafft]

also sprach Anthony Towns aj@azure.humbug.org.au [2005.02.16.1541 +0100]:
 Yes. If we weren't we might wake up one day and mistakenly think
 it might be possible to have discussions on Debian lists that
 didn't involve gratuitous insults.

I described the situation as perceived by numerous (if not most)
developers. If it is an insult to you, maybe you are doing something
wrong?

Let's ignore the dozens of packages waiting in NEW for months
*without* *an* *explanation* for a moment, as well as the numerous
emails and bugs that are simply being ignored:
many issues under your responsibility have been on the table various
times over the last months (years?) and yet the only ones to never
say anything are the mysterious ftpmasters. I bet most developers
have no reason to believe you guys are even real.

If you are too busy with sarge to tend to NEW packages, package
removals, the various files controlling the archive or your inbox,
tell us! Everyone understands that sarge has priority over new
packages.

If you are not busy with sarge, tell us what you are doing for
Debian that makes you have no time for the above tasks!

If you do not have enough time for Debian, tell us so that we can
train people to assist!

We rank our users as top priority, and we promise not to hide
problems. Developers are users, and you are treating them like
secondary members of the project, prioritising your own (hidden)
agenda. And silence in combination with stagnation smells an aweful
lot like hiding problems to me. If you are now going to say that
hiding problems refers to our public BTS, don't; to many of us, it
means a whole lot more.

None of this is personal. I am bitching at a role. The stand is now
yours for the rebuttal. Or defense. Or whatever. You do not have the
right to remain silent.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: Take APT 0.6 discussion public!

[Thaddeus H. Black]

martin f krafft asks,

 Obviously, for reasons unknown to the mere mortals,
 the above only applies to topics of the mere mortals
 of Debian, not to certain members of the cabal. Some
 vital components of the Debian project are better kept
 away from the public, or they could be flooded with
 opinions or suggestions for improvement, or even
 gasp help (ftpmasters, are you listening?).

AJ Towns replies,

 Yes. If we weren't we might wake up one day and
 mistakenly think it might be possible to have
 discussions on Debian lists that didn't involve
 gratuitous insults.

AJ, having respect for and deference to your inestimable
Debian work, nevertheless I object.  When have you ever
seen Martin F. Krafft gratuitously insult anyone?  Has
he not earned the benefit of the doubt?  It is hard to
imagine someone so passionate about Debian who
habitually tries so hard to avoid insult, as Martin F.
Krafft.

Martin's valid question stands.  Someone has advised
Martin to plan his APT work in the full glare of the
lists.  Whether this is good advice to Martin, I do not
know; but all Martin wants to know is, if the advice is
good for the APT team, then why not for ftpmaster?

It is a fair question, asked by many others on this list
in various ways, and never really answered in my
opinion.  I have never asked the question but
respectfully I do so now.  Why can so many DDs
apparently not determine to their satisfaction why and
how ftpmaster works, or what they can do to help when
ftpmaster seems broken?  Are these DDs somehow
delinquent?  Do they need to RTFM?  Are they as
children, who just do not understand?  But how can they
understand what has so long been hidden?  Are they
unreasonable to expect gentle illumination, moderate
collegiality, and some ongoing public engagement?  Are
they actually getting these things, only they don't
realize it?  On the other hand, does ftpmaster feel
besieged?  Is the problem that Debian development is too
open, too undisciplined for practical collegiality?  Yet
the release team answer questions publicly: not everyone
agrees with everything they do, but few seem to wonder
what dark secrets they keep.  And when you, AJ, served
as release manager, did you ever raise a tangled hedge
to keep information in and eyes and voices out?  I do
not think that you did.  The same can be said of the
dpkg and installer teams: at least they converse.  What
is this shroud which hides ftpmaster?

It may be observed that there has recently been good
progress on the DAM front, and this is true.  However,
the question was about ftpmaster not the DAM.  Either
the two are separate roles or they are not.  The matter
can be debated under either premise, but either way,
similar questions arise.

It is doubtful whether anyone can do much useful work in
the continuous, full glare of general public scrutiny.
This is admitted.  It is also admitted that anything
ftpmaster publishes about its internal works invites
unsettling, perhaps even unwarranted criticism, costing
ftpmaster patience and time---and even opening the
possibility of a direct challenge: I can do ftpmaster's
job better.  Watch.  However, the body of DDs are not
the general public, and Martin has never asked for hot
spotlights to focus on every tiny ftpmaster move.  He
has asked: if gentle illumination and moderate
transparency matter in APT work, then how much more so
in ftpmaster work?

If the question in any of its several forms is found
insulting by some, I hope that they will pardon Martin,
me, and the several others who have asked it.
(Certainly it would be extremely easy to punish me, who
after nearly three years of Debian development am soon
to go for final DAM review.)  I intend no more insult
than Martin does.  Not a DD, I have earned no right to
demand an answer; but it were cowardice to leave Martin
standing alone today, and I would respectfully request
an answer nevertheless.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED]

(I would quietly ask that this post not be referenced in
the Weekly News.  The Weekly News is great and has the
honorable right to reference anything it sees fit.
Personally I do not mind either way.  However, if
mention in the Weekly News tempted a certain non-Debian
forum to open a clueless thread on the topic, then I am
not sure what good purpose it would serve.  Anyone who
is really interested can read about it here.  This is
all.)


pgp24Yoem6f4n.pgp
Description: PGP signature

Re: Take APT 0.6 discussion public!

[Marc 'HE' Brockschmidt]

Thaddeus H. Black [EMAIL PROTECTED] writes:
 When have you ever seen Martin F. Krafft gratuitously insult anyone?

Well, almost everytime i read one of his posts to the lists.

Marc
-- 
$_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3*
)e$(htgnel+23(rhc,u(kcapnu ,nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y
V2ajFGabus} yV2ajFGa{gwmclBHIbus}gwmclBHI{yVGa09mbbus}yVGa09mb{hBCdzVnSbus';
s/\n//g;s/bus/\nbus/g;eval scalar reverse   # mailto:[EMAIL PROTECTED]


pgpjWA1zhIigw.pgp
Description: PGP signature

Re: Take APT 0.6 discussion public!

[Joel Aelwyn]

On Thu, Feb 17, 2005 at 02:03:04AM +1000, Anthony Towns wrote:
 martin f krafft wrote:
 
  If you are not busy with sarge, tell us what you are doing for
  Debian that makes you have no time for the above tasks!
 
 My apologies, Sir, it appears I must have mislaid my employment 
 contract; I wonder if I might perchance obtain a new copy? It also seems 
 that my salary has been misplaced, I wonder if you would be so kind as 
 to inform the HR department and request they look into the matter?
 
 Or, wait, perhaps you aren't my boss, and you've got absolutely no 
 business demanding that I account for my time?

The only business anyone has desiring an accounting of your time is when
it appears to be relevant to the question of whether any of that time is
being spent on the duties of a volunteer position you hold. You may, of
course, choose not to answer, but please don't be suprised if people assume
that means no time, or possibly no willingness to fufill the expected
duties, and decide to take issue with letting you continue in the position
in question.

Nobody can demand a volunteer do anything - but likewise, nobody can demand
they be given, or keep, a position within the project (though the procedure
for recalling various positions varies depending on whether they are
delegates or elected positions, of course).

I, personally, have asked several times in the past for some indication of
just what is going on under the veil of the ftpmasters role, and I have
never received a satisfactory answer. The current execution of the duties
of that role is, in my opinion, substandard at best, and I see only three
ways to resolve that:

1) Find out, from someone with the answers (which as far as I can tell
means one or more members of the ftpmaster team), what is causing the
problems, and then try to find a useful and meaningful resolution of them.
Maybe that's train new helpers, maybe that's give everyone a rubber
duckie, but without knowing what the problem is, it is rather difficult
to make any useful suggestion. Asserting, or implying, that there is no
problem is rather disingenous.

2) Get rid of any and all people who are obstructing #1, and let someone
new have a shot at it. Maybe they'll fix the problems, or maybe they'll
expose enough about it to let others figure out a good solution. Since
this will involve unhappy feelings on many parts, as well as a great deal
of wasted time and effort (equivalent to training up at least 1-2 new
ftpmasters, and then some, for learning from scratch), it is in no fashion
to be preferred over option 1. But if option 1 is not available, this one
still is.

3) Sit on our thumbs and pray something changes. Given both history, and my
lack of belief in an omnibenevolent deity, this one doesn't seem likely to
do much good.

So, just to be exceptionally clear, I will ask again, intending no insult
and no mockery:

What is going on within the ftpmaster team to cause the observed symptoms,
and if you have any thoughts on what would be helpful in terms of
alleviating those problems, would you please share them? If this is already
documented somewhere, and I have missed it, a pointer to the discussion or
documentation would suffice, of course. I'm happy to RTFM, if there is a
TFM to R.
-- 
Joel Aelwyn [EMAIL PROTECTED]   ,''`.
 : :' :
 `. `'
   `-


signature.asc
Description: Digital signature

Re: Take APT 0.6 discussion public!

[martin f krafft]

also sprach Marc 'HE' Brockschmidt [EMAIL PROTECTED] [2005.02.16.2334 +0100]:
  When have you ever seen Martin F. Krafft gratuitously insult anyone?
 
 Well, almost everytime i read one of his posts to the lists.

I'll refrain from gratuitously insulting you.

This thread is not about me nor any particular person. It's about
developers and ftpmasters.

Could we return to anticipating the civilised conversation that aj
promised, please?

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: Take APT 0.6 discussion public!

[Anthony Towns]

martin f krafft wrote:
also sprach Marc 'HE' Brockschmidt [EMAIL PROTECTED] [2005.02.16.2334 +0100]:
When have you ever seen Martin F. Krafft gratuitously insult anyone?
Well, almost everytime i read one of his posts to the lists.
I'll refrain from gratuitously insulting you.
This thread is not about me nor any particular person. It's about
developers and ftpmasters.
It was suppposed to be about APT 0.6, which has absolutely *nothing* 
to do with ftpmasters. It's amazing how quickly discussions in Debian 
can devolve into role bashing.

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

Re: Take APT 0.6 discussion public!

[Anthony Towns]

martin f krafft wrote:
also sprach Anthony Towns aj@azure.humbug.org.au [2005.02.16.1703 +0100]:
Or, wait, perhaps you aren't my boss, and you've got absolutely no
business demanding that I account for my time?
Doesn't the position of a delegate bear a certain amount of
responsibility and duties, which you willingly accepted as part of
taking on the job?
No, it does not. You have a debian.org address; presumably you read the 
constitution as part of that. Please see 2.1.1:

1. Nothing in this constitution imposes an obligation on anyone to
   do work for the Project. A person who does not want to do a task
   which has been delegated or assigned to them does not need to do
   it. However, they must not actively work against these rules and
   decisions properly made under them.
I am not the one to define these responsibilities and duties as I do
not know enough about them,
If you don't know what you're talking about, either learn, or shut up. 
Reading the first page of the constitution to see what delegates' 
responsibilities actually is not a big ask.

I don't care a thing for what you do outside of your official
functions in Debian.
Wow, friendly.
I will apologise for every single insult I have spoken iff you
pinpoint it as being an insult and not a statement of fact.
Thanks for confirming my expectations.
Regards,
aj
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bits from the ftpmasters (was: Take APT 0.6 discussion public!)

[martin f krafft]

also sprach Anthony Towns aj@azure.humbug.org.au [2005.02.17.0025 +0100]:
 Honestly, I'd love to talk about these sorts of things more
 publically;

Why have you not done so in the past?

 but I'm not willing to do that in an environment that's actively
 hostile.

The stage is yours. The thread is another. I am calm. Please...

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

the delegate's job (was: Take APT 0.6 discussion public!)

[martin f krafft]

also sprach Anthony Towns aj@azure.humbug.org.au [2005.02.17.0036 +0100]:
 No, it does not. You have a debian.org address; presumably you read the 
 constitution as part of that. Please see 2.1.1:

shall i scream insult now?

 1. Nothing in this constitution imposes an obligation on anyone to
do work for the Project. A person who does not want to do a task
which has been delegated or assigned to them does not need to do
it. However, they must not actively work against these rules and
decisions properly made under them.

I read this as: if you do not want to do the task, don't accept the
delegation. I do not read it as: if you do not want to do the task,
just don't do anything after accepting the delegation.

Again, I am not claiming that you are not doing anything. I am
claiming that we cannot tell because you do not tell us.

The constitution does not state anything about communication,
unfortunately. However, it does say

  8.3 Procedures
  Delegates may make decisions as they see fit, but should attempt
  to implement good technical decisions and/or follow consensus
  opinion.

I think this is badly worded, since words like good and opinion
have no place in a legal document. But it's axiomatic, so we go by
it.

The above does suggest that there is a common procedure to do things
the right way, it seems to involve consensus, and delegates should
attempt to follow them.

consensus (WordNet)
   n : agreement of the majority in sentiment or belief
   [syn: {general agreement}]

agreement (WordNet)
   n 1: the statement (oral or written) of an exchange of
promises; [syn: {understanding}]

exchange (WordNet)
   n 2: a mutual expression of views

To me, a mutual expression of views involves bidirectional
communication. Please attempt harder. I'll leave it at that.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: Debian Sarge does not have either version of apt-proxy

[Chris Bell]

On Mon 11 Oct, Florian Weimer wrote:
 
 * Chris Bell:
 
  The earlier 1.3.x version may not be perfect, but it does work for
  me, and I have not found any other software that does the same job.
 
 AFAIK, apt-proxy 1.9 is only required if you have apt 0.6 somewhere on
 your site.  apt-proxy 1.3 is fine with apt 0.5, but much too often, it
 returns inconsistent Release/Release.gpg/Packages combinations.
 
 
   Thanks for the email.

   The main reason for using apt-proxy to provide a local partial mirror is
that I can configure a list of parent mirror sites that it can try in
sequence, rather than having to specify a single source. I can then ask
apt-proxy to check mirrors provided by my ISP and local universitites before
adding to the load on the Debian servers. This appears to work when
upgrading several local machines, or using jigdo to build CD ISO images,
although I have not yet succeeded in using apt-proxy during an initial
network installation to a new box. I would be happy to try any more suitable
system that may be available.

-- 
Chris Bell

Re: Debian Sarge does not have either version of apt-proxy

[Florian Weimer]

* Chris Bell:

 The earlier 1.3.x version may not be perfect, but it does work for
 me, and I have not found any other software that does the same job.

AFAIK, apt-proxy 1.9 is only required if you have apt 0.6 somewhere on
your site.  apt-proxy 1.3 is fine with apt 0.5, but much too often, it
returns inconsistent Release/Release.gpg/Packages combinations.

Debian Sarge does not have either version of apt-proxy

[Chris Bell]

Hello,
   The current Sarge has neither the stable version of apt-proxy nor the
development version 1.9.18 currently only in Sid. Is there a reason why
neither version is included in the current Sarge-testing? I feel that it
would be a mistake to omit both versions from Sarge when it is released.
   I am running apt-proxy 1.3.0 stable on a Woody box to serve all my local
boxes with updates, and another box running Sarge which is building CD ISO's
using jigdo. Both are old Pentium boxes fitted with large hard drives,
neither is overworked, and they can be left to get on with the job together.
   Apt-proxy appears to be the only system able to collect software from a
list of selected parent mirrors and then build a local partial mirror, and I
have arranged my selection so that those supplied by my ISP and local
academic sources are checked first rather than load the Debian servers. My
apt-proxy cache does not require local boxes to specify a series of parent
mirrors, just the software details.

-- 
Chris Bell

Re: Debian Sarge does not have either version of apt-proxy

[Chris Bell]

On Thu 23 Sep, Jonas Smedegaard wrote:
 
 
 On 23-09-2004 15:50, Chris Bell wrote:
 
 |The current Sarge has neither the stable version of apt-proxy nor the
 | development version 1.9.18 currently only in Sid. Is there a reason why
 | neither version is included in the current Sarge-testing?
 
 See here: http://qa.debian.org/developer.php?excuse=apt-proxy
 
 
 ~ - Jonas


   All of those reports refer to the version in Sid-testing, which is a
complete re-write. Are there any reasons why the version 1.3.0 now working
in Woody will not work, and can not be included, in Sarge?

-- 
Chris Bell

Re: Debian Sarge does not have either version of apt-proxy

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 23-09-2004 18:42, Chris Bell wrote:
| On Thu 23 Sep, Jonas Smedegaard wrote:
|
|
|On 23-09-2004 15:50, Chris Bell wrote:
|
||The current Sarge has neither the stable version of apt-proxy nor the
|| development version 1.9.18 currently only in Sid. Is there a reason why
|| neither version is included in the current Sarge-testing?
|
|See here: http://qa.debian.org/developer.php?excuse=apt-proxy
|
|
|~ - Jonas
|
|
|
|All of those reports refer to the version in Sid-testing, which is a
| complete re-write. Are there any reasons why the version 1.3.0 now working
| in Woody will not work, and can not be included, in Sarge?

Did you follow the link to the bugreports discussing this?


~ - Jonas

- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

~ - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBUwbsn7DbMsAkQLgRAplzAJ9TmVFjmrVsolP2HV1PCmcB3FbPiQCfRg8H
XzeBNcEJpul3zGGKH7l7NYk=
=Y1Yo
-END PGP SIGNATURE-

Re: Debian Sarge does not have either version of apt-proxy

[Henrique de Moraes Holschuh]

On Thu, 23 Sep 2004, Jonas Smedegaard wrote:
 On 23-09-2004 15:50, Chris Bell wrote:
 |The current Sarge has neither the stable version of apt-proxy nor the
 | development version 1.9.18 currently only in Sid. Is there a reason why
 | neither version is included in the current Sarge-testing?
 
 See here: http://qa.debian.org/developer.php?excuse=apt-proxy

This is sub-optimal.  Since the package IS in woody, we probably should have
it also in sarge, if only for security updates to be possible.

I really think the woody version should be uploaded to t-p-u.  Yes, it is
hideously buggy.  But unless we are deprecating apt-proxy completely, it
really should not disappear from stable while remaining on old-stable (and
thus being a problem for people doing upgrades) and sid.

Please consider uploading (a recompiled just to make sure) version of what
is in woody to t-p-u.  If any security fixes were made to the apt-proxy in
sid, please backport those to the old version in woody and upload it to
t-p-u.

If there is an intermediate version (someone mentioned 1.3.6?) that is
better, then please update that one instead to t-p-u.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Debian Sarge does not have either version of apt-proxy

[Chris Bell]

On Thu 23 Sep, Jonas Smedegaard wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 23-09-2004 15:50, Chris Bell wrote:
 
 |The current Sarge has neither the stable version of apt-proxy nor the
 | development version 1.9.18 currently only in Sid. Is there a reason why
 | neither version is included in the current Sarge-testing?
 
 See here: http://qa.debian.org/developer.php?excuse=apt-proxy
 
 
 ~ - Jonas
 
   All of those reports refer to the version in Sid-testing, which is a
complete re-write. Are there any reasons why the version 1.3.0 now working
in Woody will not work, and can not be included, in Sarge?


-- 
Chris Bell

Re: Debian Sarge does not have either version of apt-proxy

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 23-09-2004 15:50, Chris Bell wrote:

|The current Sarge has neither the stable version of apt-proxy nor the
| development version 1.9.18 currently only in Sid. Is there a reason why
| neither version is included in the current Sarge-testing?

See here: http://qa.debian.org/developer.php?excuse=apt-proxy


~ - Jonas

- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

~ - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBUt+Bn7DbMsAkQLgRAj5jAKCjvCIHfFplmZp5vzlwY7TnfAeMHwCgpRdX
LPd1iuoz0FuEnYbqzPcCYLk=
=oGMF
-END PGP SIGNATURE-

Re: [OT] Re: A freak (but not so freak) idea: User space apt-get install

[Josip Rodin]

On Wed, Mar 10, 2004 at 10:48:32PM -0600, Gunnar Wolf wrote:
  Neither of those two documents say that we will keep all postings on
  the archives, or that we will remove them, they just say that we will
  if we want to.
 
[...]
 seem to address your doubts...

No, they don't really. In case of someone posting a message and with a note
that they don't want it distributed, that's just stupid of them, but in the
case of a virus posting something that was never intended to be posted,
that's something that we might need to have to clean up, under the
bona fide rules.

-- 
 2. That which causes joy or happiness.

Re: [OT] Re: A freak (but not so freak) idea: User space apt-get install

[Colin Watson]

On Wed, Mar 10, 2004 at 10:48:32PM -0600, Gunnar Wolf wrote:
 I would still apply the second paragraph I just re-quoted - We are not
 under obligation to remove it. Now, if someone posted a list of valid
 WinXP license numbers to our lists, the listmasters would probably
 delete it. And if someone defamates you, publishes your personal
 information or something similar, you can _ask_ the listmasters to
 remove that from the archive. Of course, they will apply their
 personal criteria in order to do so, and they will not be able to
 remove it from external archiving sites.

You do know that the person you're replying to is a listmaster, right?
(Just checking, as it doesn't seem that way from your tone.)

-- 
Colin Watson  [EMAIL PROTECTED]

Re: [OT] Re: A freak (but not so freak) idea: User space apt-get install

[Josip Rodin]

On Thu, Mar 11, 2004 at 05:10:33PM +, Colin Watson wrote:
  Of course, they will apply their personal criteria in order to do so,
  and they will not be able to remove it from external archiving sites.
 
 You do know that the person you're replying to is a listmaster, right?
 (Just checking, as it doesn't seem that way from your tone.)

Damn, you just spoiled us the fun of watching probably half a dozen more
messages of going around in circles :)

-- 
 2. That which causes joy or happiness.

Re: [OT] Re: A freak (but not so freak) idea: User space apt-get install

[Gunnar Wolf]

Pascal Hakim dijo [Thu, Mar 11, 2004 at 02:39:39PM +1100]:
   This email is licensed to the recipient for non-commercial
   use, duplication and distribution.
   ---
  
  This email is non-DFSG.  We need to remove it from the list archives.
 
   That's brings up a good point. While Adam is probably joking
 here, there are a lot of people who want things in the archives either
 deleted or modified. Yes there are other archives, but they are not
 our responsability, while stuff on lists.debian.org is.
 
   How do we deal with stuff that's been forwarded to a list by a
 virus? How do we deal with a message that was sent by error? How do we
 deal with a message that was forwarded by a third party without
 authorization from the author? How do we deal with mistakes?
 
   We don't seem to have a clear policy on this at the
 moment. What should we do? 

http://www.debian.org/MailingLists/

  Disclaimer / Privacy policy / Legal information

  The mailing lists are public forums.

  All emails sent to the lists are distributed both to the list
  subscribers and copied to the public archive, for people to browse or
  search without the need to be subscribed.

  Furthermore, you can browse our mailing lists as Usenet newsgroups. It
  can be done using a web interface, like Google or Gmane.

  There may be other places where lists are distributed -- please make
  sure you never send any confidential or unlicensed material to the
  lists. This includes things like e-mail addresses. Of particular note
  is the fact that spammers, viruses, worms etc have been known to abuse
  e-mail addresses posted to our mailing lists.

  Debian maintains the mailing lists in good faith and will take steps
  to curb all noticed abuse and maintain uninterrupted normal
  service. At the same time, Debian is not responsible for all mailing
  list posts or anything that may happen in relation to them.

  Please see our disclaimer of responsibility for more information.

http://www.debian.org/MailingLists/disclaimer

  Our mailing lists are public forums, and our mailing list archives
  are public.

  By sending an email to such a public forum, you agree to public
  distribution of your article. All mails sent to any of our mailing
  lists (and to the bug tracking system) will be publically distributed
  and archived in our mailing list archives.

  Any emails sent by any one person directly to the list, or replies by
  others to those emails sent to the list, are considered published, in
  accordance with the United States law.

  Obviously the author still owns the copyright to the content of these
  emails that they have written. However, that does not mean that the
  Debian Project is under obligation to remove them from a list archive
  once published. Several legal counsels have reviewed this stance and
  confirmed it is correct. 

...You will probably find more documents if you really want to ;-)

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: [OT] Re: A freak (but not so freak) idea: User space apt-get install

[Pascal Hakim]

On Wed, Mar 10, 2004 at 10:26:51PM -0600, Gunnar Wolf wrote:
 Pascal Hakim dijo [Thu, Mar 11, 2004 at 02:39:39PM +1100]:
This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---
   
   This email is non-DFSG.  We need to remove it from the list archives.
  
  That's brings up a good point. While Adam is probably joking
  here, there are a lot of people who want things in the archives either
  deleted or modified. Yes there are other archives, but they are not
  our responsability, while stuff on lists.debian.org is.
  
  How do we deal with stuff that's been forwarded to a list by a
  virus? How do we deal with a message that was sent by error? How do we
  deal with a message that was forwarded by a third party without
  authorization from the author? How do we deal with mistakes?
  
  We don't seem to have a clear policy on this at the
  moment. What should we do? 
 
 http://www.debian.org/MailingLists/
 
   Disclaimer / Privacy policy / Legal information
 
   The mailing lists are public forums.
 
   All emails sent to the lists are distributed both to the list
   subscribers and copied to the public archive, for people to browse or
   search without the need to be subscribed.
 
   Furthermore, you can browse our mailing lists as Usenet newsgroups. It
   can be done using a web interface, like Google or Gmane.
 
   There may be other places where lists are distributed -- please make
   sure you never send any confidential or unlicensed material to the
   lists. This includes things like e-mail addresses. Of particular note
   is the fact that spammers, viruses, worms etc have been known to abuse
   e-mail addresses posted to our mailing lists.
 
   Debian maintains the mailing lists in good faith and will take steps
   to curb all noticed abuse and maintain uninterrupted normal
   service. At the same time, Debian is not responsible for all mailing
   list posts or anything that may happen in relation to them.
 
   Please see our disclaimer of responsibility for more information.
 
 http://www.debian.org/MailingLists/disclaimer
 
   Our mailing lists are public forums, and our mailing list archives
   are public.
 
   By sending an email to such a public forum, you agree to public
   distribution of your article. All mails sent to any of our mailing
   lists (and to the bug tracking system) will be publically distributed
   and archived in our mailing list archives.
 
   Any emails sent by any one person directly to the list, or replies by
   others to those emails sent to the list, are considered published, in
   accordance with the United States law.
 
   Obviously the author still owns the copyright to the content of these
   emails that they have written. However, that does not mean that the
   Debian Project is under obligation to remove them from a list archive
   once published. Several legal counsels have reviewed this stance and
   confirmed it is correct. 
 
 ...You will probably find more documents if you really want to ;-)

Neither of those two documents say that we will keep all postings on
the archives, or that we will remove them, they just say that we will
if we want to.

And in the case of a third party forwarding a message without
permission, this bit doesn't even apply:

   By sending an email to such a public forum, you agree to public
   distribution of your article. All mails sent to any of our mailing
   lists (and to the bug tracking system) will be publically distributed
   and archived in our mailing list archives.

And what happens if I find your home address, and telephone number or
other address you don't want published, and I stick it on a debian
list? Should it stay there?

Pasc
-- 
Pascal Hakim+61 4 0341 1672

Re: [OT] Re: A freak (but not so freak) idea: User space apt-get install

[Gunnar Wolf]

 Neither of those two documents say that we will keep all postings on
 the archives, or that we will remove them, they just say that we will
 if we want to.

Ummm...

   All emails sent to the lists are distributed both to the list
   subscribers and copied to the public archive, for people to browse or
   search without the need to be subscribed.

and

   Obviously the author still owns the copyright to the content of these
   emails that they have written. However, that does not mean that the
   Debian Project is under obligation to remove them from a list archive
   once published. Several legal counsels have reviewed this stance and
   confirmed it is correct. 

seem to address your doubts...

 And in the case of a third party forwarding a message without
 permission, this bit doesn't even apply:
 
By sending an email to such a public forum, you agree to public
distribution of your article. All mails sent to any of our mailing
lists (and to the bug tracking system) will be publically distributed
and archived in our mailing list archives.
 
 And what happens if I find your home address, and telephone number or
 other address you don't want published, and I stick it on a debian
 list? Should it stay there?

I would still apply the second paragraph I just re-quoted - We are not
under obligation to remove it. Now, if someone posted a list of valid
WinXP license numbers to our lists, the listmasters would probably
delete it. And if someone defamates you, publishes your personal
information or something similar, you can _ask_ the listmasters to
remove that from the archive. Of course, they will apply their
personal criteria in order to do so, and they will not be able to
remove it from external archiving sites.

I don't think we need to document things that happen on a per-case
basis.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

HELP, PLEASE!! Apt-Get update Errors

[Xavian-Anderson Macpherson]

I think I read somewhere that there is a problem with one of the libraries
causing APT-GET UPDATE to fial.  I keep getting the same error; UNABLE TO
PARSE PACKAGE FILE  /VAR/LIB/DPKG/STATUS (1).  I would really appreciate
someone telling me how to resolve this.  I am running the testing (with some
packages from the unstable) branch of Debian 3.0.  Everything else works just
fine.

Re: apt-get upgrade

[Oliver Elphick]

On Mon, 2002-11-04 at 13:00, ..::jdb78::.. wrote:
 hi,
 
 i was just wondering why apt-get update /apt-get upgrade wont update ANY 
 files since lets say about 2 months? are there new source.lists or is there 
 no update anymore?

I presume apt-get updzte reported some errors.  What did they say?

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 Lo, children are an heritage of the LORD; and the  
  fruit of the womb is his reward.Psalms 127:3