Quoting Todd Zullinger (2024-08-15 01:12:01)
> Piper McCorkle wrote:
> > On Wednesday, 14 August 2024 16:43:54 CDT Agathe Porte wrote:
> >> Or maybe I could tar the upstream .git folder and store everything else
> >> as plain files? But still a binary blob in source package. And
> >> extracting the
On Wed, Aug 14, 2024 at 11:43:54PM +0200, Agathe Porte wrote:
> Note that the qmk tool does require a git repository to work, so I did
> not consider shipping only the code.
Is there any reason qmk couldn't be patched to accept a plain directory
as an alternative to a git repository? It looks lik
Piper McCorkle wrote:
> On Wednesday, 14 August 2024 16:43:54 CDT Agathe Porte wrote:
>> Or maybe I could tar the upstream .git folder and store everything else
>> as plain files? But still a binary blob in source package. And
>> extracting the tar into a .git in the filesystem in /usr/share/ may
>
On Wednesday, 14 August 2024 16:43:54 CDT Agathe Porte wrote:
> Or maybe I could tar the upstream .git folder and store everything else
> as plain files? But still a binary blob in source package. And
> extracting the tar into a .git in the filesystem in /usr/share/ may
> raise a lot of Lintian war
Hello everyone,
I have recently packaged qmk¹ into debian² (see rationale³).
However the tool still needs to git clone the qmk_firmware repository⁴
at runtime before being able to do any work. This is what the
autopkgtest currently does⁵, with the needs-internet restiction⁶.
¹ https://github.com
ng to create a deb file that will install icons in the menu. I've
created .desktop files and placed them under /usr/share/applications. These
icons do appear, but under KDE, they appear under the "Lost and found" category.
I have not been able to find a guide on how to control which
On Tue, 06 Aug 2024 17:48:32 +0200
Hans wrote:
Hello Hans,
>believe it is mostly under ~/username/Desktop/
That's the location for desktop shortcuts, not kicker menu items.
--
Regards _ "Valid sig separator is {dash}{dash}{space}"
/ ) "The blindingly obvious is never imm
> I'm trying to create a deb file that will install icons in the menu. I've
> created .desktop files and placed them under /usr/share/applications. These
> icons do appear, but under KDE, they appear under the "Lost and found"
> category. I have not been able to find
Hello everyone,
I'm trying to create a deb file that will install icons in the
menu. I've created .desktop files and placed them under
/usr/share/applications. These icons do appear, but under KDE,
they appear under the "Lost and found&qu
Package: wnpp
Severity: wishlist
Owner: Ajayi Olatunji
X-Debbugs-CC:debian-devel@lists.debian.org
* Package name : ruby-google-apis-core
Version : 0.11.2
Upstream Author : Google LLC
* URL : https://github.com/google/google-api-ruby-client#readme
* License : Apache-2.0
Programming Lang:Ruby
Des
Package: wnpp
Severity: wishlist
Owner: Ajayi Olatunji
X-Debbugs-CC:debian-devel@lists.debian.org
* Package name: ruby-deb-version
Version : 1.0.2
Upstream Author : Nemo
* URL : https://github.com/captn3m0/ruby-deb-version#readme
* License : MIT
On Tue, Sep 19, 2023 at 11:39:49AM +0200, Johannes Schauer Marin Rodrigues
wrote:
> I was about to say that zdebootstrap by Adam Borowski used to be a thing four
> years ago but now I see another commit from two days ago so maybe it's still
> alive and usable?
>
> https://git.sr.ht/~kilobyte/zdeb
and 128 core (AMD
> Epyc...), on last gen NVMe, using a local mirror, it's really painful to see
> how slow the debootstrap process is, compared to what it could be. Unpacking
> multiple .deb at the same time seems a very good idea to me, as well as
> parallelizing everything we can.
On 9/16/23 07:01, Hideki Yamane wrote:
* So, if we change {data,control}.tar file format in .deb from xz to zst,
we can reduce package installation time than ever since less decompression
time. It saves our lifetime a bit :)
* Downside: package file size is a bit larger than now, but
Hi,
On Mon, Sep 18, 2023 at 4:20 PM Helmut Grohne wrote:
>
> Hi,
>
> On Sat, Sep 16, 2023 at 10:31:20AM +0530, Hideki Yamane wrote:
> > Today I want to propose you to change default compression format in .deb,
> > {data,control}.tar."xz" to ."zst"
Hi,
On Sat, Sep 16, 2023 at 10:31:20AM +0530, Hideki Yamane wrote:
> Today I want to propose you to change default compression format in .deb,
> {data,control}.tar."xz" to ."zst".
>
> I want to hear your thought about this.
I am not very enthusiastic ab
Hallo,
* Hideki Yamane [Sat, Sep 16 2023, 10:31:20AM]:
> Today I want to propose you to change default compression format in .deb,
> {data,control}.tar."xz" to ."zst".
I tend to agree but...
> # Compared to past change to xz proposal (in DebConf12)
>
> T
On Sun, 2023-09-17 at 22:16 +0200, Joerg Jaspert wrote:
>
> I do not think wasting space is any good idea.
>
> > ## More bandwidth
> > According to https://www.speedtest.net/global-index, broadband
> > bandwidth
> > in Nicaragua becomes almost 10x
>
> And elsewhere it may have gone up a diff
Stephan Verbücheln wrote...
> If you want to open that debate (again?), one should probably switch to
> lzip. It uses the same LZMA compression like xz, but has a way more
> sane file format.
Besides the fact dpkg already has zstd support while lzip is missing, so
that was a way bigger changes: I
On 16988 March 1977, Hideki Yamane wrote:
Today I want to propose you to change default compression format in
.deb,
{data,control}.tar."xz" to ."zst".
I want to hear your thought about this.
Negative.
# Compared to past change to xz proposal (in DebConf12)
* Mor
If you want to open that debate (again?), one should probably switch to
lzip. It uses the same LZMA compression like xz, but has a way more
sane file format.
Also note that the (pretended) multi-threading-capability of xz is
mostly based on its improper file format[1]:
> The xz-utils manual says
On Sun, Sep 17, 2023 at 09:31:03AM +0530, Hideki Yamane wrote:
> On Sat, 16 Sep 2023 13:34:02 +0200
> Guillem Jover wrote:
> > That's not correct. dpkg-deb is doing multi-threaded xz decompression
> > since 1.21.13, and dpkg-source is doing multi-threaded xz compressio
On Sat, 16 Sep 2023 14:25:48 -0400
"M. Zhou" wrote:
> Be careful if it bloats up our mirrors. Is there any estimate on
> the extra space cost for a full debian mirror?
Yes, sure, I'll do some experiment for it later.
Thank you for your comment!
--
Hideki Yamane
On Sat, 16 Sep 2023 13:34:02 +0200
Guillem Jover wrote:
> That's not correct. dpkg-deb is doing multi-threaded xz decompression
> since 1.21.13, and dpkg-source is doing multi-threaded xz compression
> and decompression since 1.21.14.
>
> Also the Ubuntu zstd implementatio
Lee wrote:
> What did you do to get the "Performance counter stats" section in the
> results for time?
alias time="perf stat"
--
Robert Edmonds
edmo...@debian.org
On 9/16/23, Robert Edmonds wrote:
> $ time xz -v -k -T0 -6 data.tar
> data.tar (1/1)
> 100 %71.9 MiB / 452.5 MiB = 0.15921 MiB/s 0:21
>
> Performance counter stats for 'xz -v -k -T0 -6 data.tar':
>
> 206,070.39 msec task-clock #9.602 CPUs
> ut
hmark, but it is slow.
Anecdotally, for "linux-image-6.5.0-1-amd64_6.5.3-1_amd64.deb" the
data.tar component takes 72 MB when compressed with xz -6, and 80 MB
when compressed with zstd -19, so about 10% larger with zstd.
This is specifically with multi-threaded compression. The behavio
+0530, Hideki Yamane wrote:
> Hi,
>
> Today I want to propose you to change default compression format in
> .deb,
> {data,control}.tar."xz" to ."zst".
>
> I want to hear your thought about this.
On Sat, Sep 16, 2023 at 10:31:20AM +0530, Hideki Yamane wrote:
> Today I want to propose you to change default compression format in .deb,
> {data,control}.tar."xz" to ."zst".
> According to https://www.speedtest.net/global-index, broadband bandwidth
>
more than 10x CPU power than 2012.
That's not correct. dpkg-deb is doing multi-threaded xz decompression
since 1.21.13, and dpkg-source is doing multi-threaded xz compression
and decompression since 1.21.14.
Also the Ubuntu zstd implementation did not have multi-threaded support
at all, the
I think it's a good idea now that dpkg supports it [1]. Ubuntu already
did it years ago [2], and some non-deb based distros as well (e.g.
Fedora, Arch).
Cheers,
Stephan
[1]: https://bugs.debian.org/892664
[2]: https://balintreczey.hu/blog/hello-zstd-compressed-debs-in-ubuntu/
Hi,
Today I want to propose you to change default compression format in .deb,
{data,control}.tar."xz" to ."zst".
I want to hear your thought about this.
# Compared to past change to xz proposal (in DebConf12)
There are reasons why I propose this
* More bandwidth
is architecture -- all buildd!
>
> Is there really no mips64el porterbox, or is it only a transitory
> situation?
As others have mentioned there's one such box. You can use the
following script to get the available porterbox for any arch:
<https://www.hadrons.org/~guillem/deb
Am Donnerstag, dem 28.10.2021 um 11:58 +0300 schrieb Uladzimir Bely:
>
> I need to cache outside of schroot these .deb files that were downloaded by
> apt. They are supposed to be used for creaing a local partial debian
> repository, so that the second build will use this local rep
I investigated $apt_keep_downloaded_packages=1 and found that this feature was
added in more recent version of sbuild than debian `buster` provides (https://
bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=933723 is a bug where it was
solved)
Probably, that's why I couldn't get any results under
gt; based distro for embedded systems. In two words, it's similar to Buildroot,
> Yocto and others, but it uses official Debian packages plus allows to build
> own customer packages.
>
> Currently it uses some own set of scripts to download dependencies, install
> them is build
Hello.
Thanks for the idea with $apt_keep_downloaded_packages=1. I'll try to play
with it.
Previously I tried to mount external directory to /var/cache/apt/archives
inside schroot, but finally found it almost empty (only some .lock file was
there, AFAIR). As I understand, that it was really us
, but it uses official Debian packages plus allows to build
own customer packages.
Currently it uses some own set of scripts to download dependencies, install
them is build chroot and build the package. Every .deb that was downloaded
during system build is cached internally. So, for the seco
> I need to cache outside of schroot these .deb files that were downloaded by
> apt. They are supposed to be used for creaing a local partial debian
> repository, so that the second build will use this local repo instead of
> internet one.
>
> Currently it's done by p
n overlay)
>
> I need to cache outside of schroot these .deb files that were downloaded by
> apt.
A caching proxy is indeed a good answer for this question but if for some
reason you don't want to use it, you can bind-mount some directory from
outside the chroot as /var/cache/apt/
When building a package with sbuild, some packages (dependencies of package
being built) are internally downloaded and installed by apt. After the build
finished, schroot is cleaned again (while everything is done in overlay)
I need to cache outside of schroot these .deb files that were
On Sun, Sep 12, 2021 at 03:10:27AM +, Paul Wise wrote:
> On Fri, Sep 10, 2021 at 6:03 PM David Kalnischkies wrote:
> > Because this thread started with the idea to switch the default of d-i
> > and co to another URI. If you target only apt then you still need
> > a solution for d-i and a way to
On Sun, Sep 12, 2021 at 03:10:27AM +, Paul Wise wrote:
> ISTR the future of creating new Debian installations is to move from
> debootstrap to dpkg/apt. As an interim step, debootstrap could [...]
I've switched all my occurances of using debootstrap to mmdebstrap and
am a very happy user of it
On Fri, Sep 10, 2021 at 6:03 PM David Kalnischkies wrote:
> Because this thread started with the idea to switch the default of d-i
> and co to another URI. If you target only apt then you still need
> a solution for d-i and a way to convert whatever d-i had into what apt
> gets in the end (of the
could see that would be a net gain would be to generalizes
> > sources.list more. Instead of having a user select a specific protocol and
> > path, allow the user to just select high-level objects. Make this a new
> > pseudo-protocol for backward compatibility, and introduce s
> > > generalizes
> > > sources.list more. Instead of having a user select a specific protocol and
> > > path, allow the user to just select high-level objects. Make this a new
> > > pseudo-protocol for backward compatibility, and introduce something like
> > >
the user to just select high-level objects. Make this a new
pseudo-protocol for backward compatibility, and introduce something like
deb apt:// suite component[s]
so the default could be something like
deb apt:// bullseye main
deb apt:// bullseye/updates main
then the actual protocols, servers
Hi,
On 10.09.21 01:46, Paul Wise wrote:
Another important argument is that it creates a dependency on
third-party commercial CDNs, and their *continued* sponsorship.
This dependency on external providers is unavoidable, Debian
definitely cannot afford to run our own CDN at the scale needed t
his a new
> pseudo-protocol for backward compatibility, and introduce something like
> deb apt:// suite component[s]
> so the default could be something like
> deb apt:// bullseye main
> deb apt:// bullseye/updates main
> then the actual protocols, servers, and paths could be manag
On Fri, Sep 10, 2021 at 09:33:56AM +0200, Helmut Grohne wrote:
Laptops of end-user systems are the target, but also developers. When
people gather at a place (conference, hackspace, private meetup, etc.)
downloading of .debs should just work quickly by default. Many such
sites could easily provid
e you can prefix
the source URL with the proxy URL, i.e.
deb http://proxyhost:3142/deb.debian.org/debian unstable main
Maybe we could introduce this as an "official" APT proxy mode, where
http(s)://REPO gets replaced by http://PROXY_URL/REPO (and the proxy
can decide whether o
ppose you could instead add an apt option
to pass the https request to the proxy via GET instead of using
CONNECT, but I think that also won't necessarily work on an existing
proxy.
apt-cacher-ng has a second mode of operation where you can prefix
the source URL with the proxy URL, i.e.
deb h
Hallo,
* Michael Stone [Wed, Sep 08 2021, 07:25:26PM]:
> On Wed, Sep 08, 2021 at 03:56:14PM +0200, Ansgar wrote:
> > On Wed, 2021-09-08 at 15:41 +0200, Helmut Grohne wrote:
> > > On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote:
> > > > So what do you suggest then? Tech-ctte as with merged-/u
On Fri, 2021-09-10 at 09:33 +0200, Helmut Grohne wrote:
> If
> we installed auto-apt-proxy by default, much of the local caching
> would
> just work.
If you push for a local caching method to be used by default, apt
should always request (In)Release.gpg from a regular mirror (not auto-
discovered
On Wed, Sep 08, 2021 at 07:12:18PM -0400, Michael Stone wrote:
> Why not simply automate setting it at install time using preseed? I'm
> honestly not sure who the target audience for auto-apt-proxy is--apparently
> someone who has an infrastructure including a proxy, possibly the ability to
> set d
On Thu, Sep 9, 2021 at 6:03 PM Simon Richter wrote:
> Another important argument is that it creates a dependency on
> third-party commercial CDNs, and their *continued* sponsorship.
This dependency on external providers is unavoidable, Debian
definitely cannot afford to run our own CDN at the sca
Hi,
On 04.09.21 22:12, Hideki Yamane wrote:
The TLS layer is not part of the security model, so we'd be teaching
users to look for the wrong thing, kind of like the "encrypted with SSL"
badges on web pages in the 90ies.
Is there any strong reason to use HTTP than HTTPS now?
The strongest
* Michael Stone [2021-09-09 09:05]:
Because the controversy concerning changing the default is over
whether it's reasonable for someone using auto-apt-proxy to have to
manage additional configuration settings.
Ah, I understand your point now and I agree.
It would be an inconvenience, yes, not
On Thu, Sep 09, 2021 at 02:54:21PM +0200, Timo Röhling wrote:
* Michael Stone [2021-09-09 08:32]:
I'm honestly not sure who the target audience for auto-apt-proxy
is--apparently someone who has an infrastructure including a
proxy, possibly the ability to set dns records, etc., but can't
chang
* Michael Stone [2021-09-09 08:32]:
I'm honestly not sure who the target audience for auto-apt-proxy
is--apparently someone who has an infrastructure including a
proxy, possibly the ability to set dns records, etc., but can't
change defaults at install time or via some sort of runtime
configu
this a new pseudo-protocol for backward compatibility, and
introduce something like
deb apt:// suite component[s]
so the default could be something like
deb apt:// bullseye main
deb apt:// bullseye/updates main
then the actual protocols, servers, and paths could be managed by
various p
On Thu, Sep 09, 2021 at 08:36:28AM +0200, Timo Röhling wrote:
* Michael Stone [2021-09-08 19:12]:
Why not simply automate setting it at install time using preseed?
I'm honestly not sure who the target audience for auto-apt-proxy
is--apparently someone who has an infrastructure including a prox
* Michael Stone [2021-09-08 19:12]:
Why not simply automate setting it at install time using preseed? I'm
honestly not sure who the target audience for auto-apt-proxy
is--apparently someone who has an infrastructure including a proxy,
possibly the ability to set dns records, etc., but can't ch
2021, സെപ്റ്റംബർ 9 4:42:18 AM IST, Michael Stone ൽ എഴുതി
>On Wed, Sep 08, 2021 at 01:09:13PM +0200, Helmut Grohne wrote:
>>Enabling https by default quite simply breaks the simple recipe of
>>installing auto-apt-proxy. Would you agree with auto-apt-proxy's
>>postinst automatically editing your s
All,
I am against automatically setting HTTPS. Their should be an option in
the installer to set or unset HTTPS while configuring the mirror! I
like a lot of folks am on a metered internet connection with a UTM
proxy firewall. I have multiple computers that need patched and only
having to download
On Wed, Sep 08, 2021 at 03:56:14PM +0200, Ansgar wrote:
On Wed, 2021-09-08 at 15:41 +0200, Helmut Grohne wrote:
On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote:
> So what do you suggest then? Tech-ctte as with merged-/usr? Or a
> GR? Or
> something else?
I propose that the proponents pay
On Wed, Sep 08, 2021 at 01:09:13PM +0200, Helmut Grohne wrote:
Enabling https by default quite simply breaks the simple recipe of
installing auto-apt-proxy. Would you agree with auto-apt-proxy's
postinst automatically editing your sources.list to drop the s out of
https? The answer repeatedly giv
On Wed, 2021-09-08 at 15:41 +0200, Helmut Grohne wrote:
> On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote:
> > So what do you suggest then? Tech-ctte as with merged-/usr? Or a
> > GR? Or
> > something else?
>
> I propose that the proponents pay the cost. In this case, it is a bit
> unclear
On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote:
> So what do you suggest then? Tech-ctte as with merged-/usr? Or a GR? Or
> something else?
I propose that the proponents pay the cost. In this case, it is a bit
unclear what that means precisely (which likely is the reason they
haven't done
On Wed, 2021-09-08 at 13:13 +0100, Tim Woodall wrote:
> This is a bit tongue in cheek, but how about these sites where the
> .debs are downloaded from publish their *private* key? They openly
> accept that anyone can MITM them.
If you have access to the private key, you can request the CA to revok
On Wed, 8 Sep 2021, Helmut Grohne wrote:
I do see the advantages of using https. I do not see how to not make it
happen without breaking relevant use cases. Same with the /usr-merge. I
do see the advantages. I've stopped counting the things that broke. Most
recent one is the uucp FTBFS. Change h
On Wed, 2021-09-08 at 13:53 +0200, Helmut Grohne wrote:
> On Wed, Sep 08, 2021 at 01:37:37PM +0200, Ansgar wrote:
> > Maybe we should just find out who is responsible for this decision
> > and
> > reassign the bug to them. The installer team maintaining d-i and
> > debootstrap or the mirror team s
On Wed, Sep 08, 2021 at 01:37:37PM +0200, Ansgar wrote:
> Maybe we should just find out who is responsible for this decision and
> reassign the bug to them. The installer team maintaining d-i and
> debootstrap or the mirror team seem reasonable choices?
We've already tried that approach on the /u
On Wed, 2021-09-08 at 13:09 +0200, Helmut Grohne wrote:
> On Thu, Sep 02, 2021 at 10:22:15AM +0900, Hideki Yamane wrote:
> > Some users want proxy but they can configure their settings.
> > So just change "default setting for {deb,security}.debian.org"
> > is no
Hi,
On Thu, Sep 02, 2021 at 10:22:15AM +0900, Hideki Yamane wrote:
> Some users want proxy but they can configure their settings.
> So just change "default setting for {deb,security}.debian.org"
> is not so harmful, IMO.
I fear you are putting this upside down. In reali
On Fri, Sep 03, 2021 at 02:42:29AM +, Paul Wise wrote:
> httpredir.d.o was an alternative CDN-like thing that was based on HTTP
> redirects to the mirror network. It had lots of problems, but now that
> we have a mirror checker and zzz-dists, perhaps it could work better.
> The mirror:// method
On Thu, 2 Sep 2021 21:26:11 +0200
Simon Richter wrote:
> The TLS layer is not part of the security model, so we'd be teaching
> users to look for the wrong thing, kind of like the "encrypted with SSL"
> badges on web pages in the 90ies.
Is there any strong reason to use HTTP than HTTPS now?
S
Hi,
On 03.09.21 13:11, Simon Richter wrote:
[Revocation mechanism]
If we don't have one, shouldn't we worry more about that given the
widespread use of TLS?
We have a big hammer, shipping a new ca-certificates package. If we want
something that only affects apt, but not other packages, that mec
On Fri, 2021-09-03 at 13:11 +0200, Simon Richter wrote:
> > > - If I deselect all CAs in the configuration dialog of the
> > > ca-certificates package, what mechanism will allow apt to work?
>
> > If people intentionally detrust them, they have to deal with the
> > fallout.
>
> So this introdu
Hi,
On 02.09.21 23:02, Ansgar wrote:
As it is now, I can install a Debian system where no X.509
certificate authorities are trusted.
That doesn't change with the proposal?
- If I deselect all CAs in the configuration dialog of the
ca-certificates package, what mechanism will allow apt
On Thu, Sep 2, 2021 at 9:06 PM Ansgar wrote:
> Accessing www.debian.org will also not work on such systems (and unlike
> deb.d.o that does not even offer non-https). It's not Debian's problem.
The Tor onion services offer alternatives to the https PKI:
https://onion.debian.org/
> Is replacing d
On Thu, 2021-09-02 at 21:26 +0200, Simon Richter wrote:
> As it is now, I can install a Debian system where no X.509
> certificate authorities are trusted.
That doesn't change with the proposal?
> - If I deselect all CAs in the configuration dialog of the
> ca-certificates package, what mechan
Hi,
On 02.09.21 03:22, Hideki Yamane wrote:
Providing "default secure setting" is good message to users.
The TLS layer is not part of the security model, so we'd be teaching
users to look for the wrong thing, kind of like the "encrypted with SSL"
badges on web pages in the 90ies.
We hav
On 2021-09-02 12:27:34 -0400 (-0400), Roberto C. Sánchez wrote:
[...]
> In this context, it might make sense to describe using HTTPS as
> the transport for APT operations is providing "default
> confidentiality".
Which, as similarly discussed, it really doesn't do either (because
of deterministic
On Thu, Sep 02, 2021 at 04:08:37PM +, Jeremy Stanley wrote:
> On 2021-09-02 10:22:15 +0900 (+0900), Hideki Yamane wrote:
> [...]
> > Providing "default secure setting" is good message to users.
> [...]
>
> As previously covered, I'd suggest steering clear of referring to
> this as adding "def
On 2021-09-02 10:22:15 +0900 (+0900), Hideki Yamane wrote:
[...]
> Providing "default secure setting" is good message to users.
[...]
As previously covered, I'd suggest steering clear of referring to
this as adding "default security." That implies APT wasn't already
effectively secure over plain
Hi,
On Wed, 01 Sep 2021 07:46:07 -0700
Russ Allbery wrote:
> >> I believe that the discussion has later identified that doing so would
> >> break squid-deb-proxy-client and auto-apt-proxy. Given that the
> >> security benefits are not strong (beyond embracing goo
Ansgar writes:
> On Wed, 2021-09-01 at 11:15 +0200, Helmut Grohne wrote:
>> I believe that the discussion has later identified that doing so would
>> break squid-deb-proxy-client and auto-apt-proxy. Given that the
>> security benefits are not strong (beyond embracing good ha
On Wed, 2021-09-01 at 11:15 +0200, Helmut Grohne wrote:
> I believe that the discussion has later identified that doing so
> would
> break squid-deb-proxy-client and auto-apt-proxy. Given that the
> security
> benefits are not strong (beyond embracing good habits), I think the
>
Processing control commands:
> tags -1 + moreinfo
Bug #992692 [general] general: Use https for {deb,security}.debian.org by
default
Added tag(s) moreinfo.
--
992692: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992692
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Control: tags -1 + moreinfo
On Sun, Aug 22, 2021 at 09:56:57PM +0900, Hideki Yamane wrote:
> As we discussed on -devel(*), it seems that we can enable https for
> {deb,security}.debian.org by default. With this bug report, I'll
> collect related things and fix it.
I be
I'm actually doing this since around 10 years.
My first implementation (predating both auto-apt-proxy and
squid-deb-proxy-client) was a custom DHCP option containing a proxy.
I've locally used that with success for quite a while in my own
environments. It does have a few downsides:
On Sat, Aug 21, 2021 at 10:28:04AM +0200, Wouter Verhelst wrote:
> On Thu, Aug 19, 2021 at 10:11:33PM +, Jeremy Stanley wrote:
> > On 2021-08-19 16:37:13 -0400 (-0400), Kyle Edwards wrote:
> > > On 8/19/21 3:46 PM, Simon Richter wrote:
> > > > For the most part, users would configure https if t
Package: general
Severity: wishlist
Dear developers,
As we discussed on -devel(*), it seems that we can enable https for
{deb,security}.debian.org by default. With this bug report, I'll
collect related things and fix it.
- Update mirror list (how?)
- Update security mirror setting i
On Sat, Aug 21, 2021 at 11:05:23PM +, Stephan Verbücheln wrote:
> What about HTTP 304 Not Modified?
What about them? Care to give details?
Note that APT nowadays hardly makes requests which can legally be
replied to with 304 as it knows which index files changed (or not)
based on comparing t
What about HTTP 304 Not Modified?
Regards
On 2021-08-21 12:04:32 +0100 (+0100), Phil Morrell wrote:
> On Sat, Aug 21, 2021 at 10:40:32AM +0200, Wouter Verhelst wrote:
[...]
> > However, I've not been able to come up with a scheme which is simple
> > enough to be doable on a LAN while at the same time be usable by larger
> > network provide
On Sat, Aug 21, 2021 at 09:45:54AM +0200, Tomas Pospisek wrote:
> On 21.08.21 09:14, Philipp Kern wrote:
> > defense in depth if we wanted to, but maybe the world just agreed that
> > you need to get your clock roughly correct. ;-)
>
> I remember seeing apt-get refusing to update packages or the i
that apt should use that one in preference to
> > deb.debian.org.
>
> This already exists in the form of an avahi service announcement for
> _apt_proxy._tcp, issued by both squid-deb-proxy and apt-cacher-ng.
> Literally the only thing needed client-side is installation of
>
On 8/20/21 4:56 PM, Russ Allbery wrote:
> Jeremy Stanley writes:
>
>> I agree with all of the above, my point was that the current state of
>> HTTPS doesn't especially improve integrity for Debian package management
>> over the signed indices and checksums we already rely on, and trying to
>> use
1 - 100 of 976 matches
Mail list logo
