Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org
* Package name: golang-gopkg-goose.v1
Version : 0.0~git20170406.3228e4f-1
Upstream Author : Canonical Ltd
* URL : https://github.com/go-goose
Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-mhilton-openid
Version : 0.0~git20181012.aeae87e-1
Upstream Author : Martin Hilton
* URL : https://github.com/m
Simon Richter writes:
> Bootstrapping a new Debian system works by unpacking Essential packages
> with ar+tar, i.e. not using dpkg. These packages will always be unpacked
> to the file names listed inside the packages.
Well, bootstrapping a new Debian system involves running a tool that
bootstra
Hi,
> > (I've used /bin -> /usr/bin as an example, but the canonicalization must
> > deal with the other merged paths too.)
/lib and /lib64 are a bit special, because they are part of the ELF ABI,
and any manipulation of these paths needs to be atomic.
Bootstrapping a new Debian system works by
Simon Richter writes:
> I think the main blocker at the moment is that the dpkg change *also*
> has the potential to break a lot of things if it isn't carefully
> designed.
I think you can simplify that problem space considerably because we know
exactly what symlinks we care about and we don't i
Hi,
On Fri, Nov 19, 2021 at 12:28:56PM -0700, Sam Hartman wrote:
> But we could you know fix dpkg:-)
> I'm sure that will be painful at the political level, but personally I
> think it needs doing.
I think the main blocker at the moment is that the dpkg change *also*
has the potential to break a
* Russ Allbery [2021-11-19 11:46]:
I also don't understand why this isn't the correct solution. It seems
obvious to me that we should simply teach dpkg about path aliases and have
it update both its internal state and its processing of new packages to
canonicalize paths so that it has an accura
On Fri, Nov 19, 2021, at 3:23 PM, Zack Weinberg wrote:
> On Thu, Nov 18, 2021, at 8:06 PM, Luca Boccassi wrote:
>>> On Thu, 2021-11-18 at 16:23 -0500, Zack Weinberg wrote:
>>> Luca Bocassi wrote:
>>> ...
nobody has actually seen [the file disappearance bug]
happen, to the best of my knowl
On Thu, Nov 18, 2021, at 8:06 PM, Luca Boccassi wrote:
>> On Thu, 2021-11-18 at 16:23 -0500, Zack Weinberg wrote:
>> Luca Bocassi wrote:
>> ...
>>> nobody has actually seen [the file disappearance bug]
>>> happen, to the best of my knowledge.
>>
>> I already explained why that doesn't prove the bug
Richard Laager writes:
> Is this particularly hard to fix, though?
> Can't we just do something like the following pseudo-code:
[...]
> (I've used /bin -> /usr/bin as an example, but the canonicalization must
> deal with the other merged paths too.)
> The second bit ensures that all new opera
Hi
On 18-11-2021 22:44, Marco d'Itri wrote:
On Nov 18, Zack Weinberg wrote:
Are you seriously claiming that that phenomenon is not a severity:critical bug?
I am seriously claming that whatever you are referring to, if true, is
such a contrived example that does not actually happen in real li
> "Michael" == Michael Biebl writes:
Michael> Am 17.11.2021 um 19:57 schrieb Sam Hartman:
Michael> AIUI simply moving files from / to /usr within the same
Michael> package is not problematic.
Sorry, I was being overly simplistic.
I think your understanding is mostly correct.
You
> "Marco" == Marco d'Itri writes:
Marco> On Nov 18, Zack Weinberg wrote:
>> Are you seriously claiming that that phenomenon is not a
>> severity:critical bug?
Marco> I am seriously claming that whatever you are referring to, if
Marco> true, is such a contrived example tha
On 2021-11-19 15:37 +0100, Michael Biebl wrote:
> On 19.11.21 11:58, Philip Hands wrote:
>> Ansgar writes:
>>
* doing this will, in a non-negligible number of cases, trigger the
bug to manifest on systems where that package is upgraded from a
version where the move had not taken pl
On Fri, 19 Nov 2021 11:58:39 +0100, Philip Hands
wrote:
>Given that these bugs are going to be utter bastards to reproduce, and
>you can be sure that we'll have enough diversity in installed systems
>that some people are going to manage to be sufficiently unlucky, it
>would be nice to know the sor
Package: wnpp
Severity: wishlist
Owner: Felix Zielcke
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: pcmemtest
Version : 1.5
Upstream Author : Martin Whitaker
* URL : https://github.com/martinwhitaker/pcmemtest
* License : GPL-2
Programming Lang:
On 19.11.21 11:58, Philip Hands wrote:
Ansgar writes:
* doing this will, in a non-negligible number of cases, trigger the
bug to manifest on systems where that package is upgraded from a
version where the move had not taken place to one where it has.
Why do you claim that?
Given packages al
On Fri, Nov 19, 2021 at 10:06:13AM +0100, Ansgar wrote:
> Given packages already did such moves in the last years and you claim
> this happens in a non-negligible number of cases, could you please
> point to some examples where this already happens in practice?
You need a / → /usr¹ and a pkg-a → p
Ansgar writes:
>> * doing this will, in a non-negligible number of cases, trigger the
>> bug to manifest on systems where that package is upgraded from a
>> version where the move had not taken place to one where it has.
>
> Why do you claim that?
>
> Given packages already did such moves in the
Andrey Rahmatullin writes:
> On Thu, Nov 18, 2021 at 04:08:23PM +0100, Stephan Lachnit wrote:
>> > > I don't know if that has been proposed before, but how about waiving
>> > > the NEW queue requirement for experimental packages as a start?
>> > > [...] Since packages in experimental will never
Simon Richter writes:
> Hi,
>
> On 11/18/21 4:08 PM, Stephan Lachnit wrote:
>
>> I guess this raises the (maybe already answered) question if the
>> additional license QA from NEW is for the end-product (i.e. Debian
>> stable) or for the servers that run the Debian infrastructure, which
>> of co
On Thu, 2021-11-18 at 23:01 -0500, The Wanderer wrote:
> * to date, package maintainers have not yet begun moving
> already-packaged files from / to /usr/ (specifically because doing so
> would break systems that have not yet been migrated to merged-/usr,
> and Debian has not yet declared that such
22 matches
Mail list logo
