On Feb 19, The Wanderer wrote:
> Is there a reason this is all looking to merge /* into /usr/* instead of
> the other way around?
Yes, nicely documented by the links collected here:
https://wiki.debian.org/UsrMerge .
--
ciao,
Marco
signature.asc
Description: PGP signature
On Feb 19, Guillem Jover wrote:
> For any pathname that has been hardcoded a symlink can be used for
> backwards compat, nothing unlike /bin or /sbin here. This looks just
> like a normal bug from a botched transition, nothing special.
Creating symlinks in /bin and /sbin DOES NOT result in a merg
在 2020-02-18二的 23:58 -0500，The Wanderer写道：
> On 2020-02-18 at 20:50, Guillem Jover wrote:
>
> > On Sun, 2020-02-16 at 11:59:56 +, Simon McVittie wrote:
> >
> > > I would be grateful if people who advocate transitioning
> > > individual packages, and people who consider the approach taken by
>
On 2020-02-18 at 20:50, Guillem Jover wrote:
> On Sun, 2020-02-16 at 11:59:56 +, Simon McVittie wrote:
>
>> I would be grateful if people who advocate transitioning
>> individual packages, and people who consider the approach taken by
>> usrmerge and debootstrap to be sufficient, could refer
On Sun, 2020-02-16 at 11:59:56 +, Simon McVittie wrote:
> I would be grateful if people who advocate transitioning individual
> packages, and people who consider the approach taken by usrmerge and
> debootstrap to be sufficient, could refer to their preferred route in a
> way that makes it clea
On Fri, 3 Jan 2020 at 06:29, Simon McVittie wrote:
> On Fri, 03 Jan 2020 at 00:05:10 +0800, Shengjing Zhu wrote:
> > The advantages of sysusers.d and tmpfiles.d are that you don't need to
> > call some magic scripts.
> > You only need to write declarative configuration files.
>
> Individual packa
On Tue, 18 Feb 2020 at 15:47:17 -0500, Antoine Beaupré wrote:
> The tricky part here is generating a new version without mangling
> debian/changelog all the time. I haven't found a great story for that
> that works with git, but maybe you can generate syntetic commits to fake
> a new Debian package
Hello,
On Tue, Feb 18, 2020 at 10:10:05PM +0100, Marco d'Itri wrote:
> On Feb 18, Simon McVittie wrote:
>
> > No. Sorry, I phrased that badly. The consensus that I think we have is:
> > we are no longer attempting to support systems booting without /usr
> > mounted, and therefore it is not a bug
Hi.
I don't know of a way to do a install from the menus in d-i, but you can
use the --no-merged-usr switch to debootstrap.
Presumably you could boot d-i or at least a live system and run
debootstrap manually from a shell.
On Feb 18, Simon McVittie wrote:
> No. Sorry, I phrased that badly. The consensus that I think we have is:
> we are no longer attempting to support systems booting without /usr
> mounted, and therefore it is not a bug if programs and libraries on the
> rootfs have dependencies in /usr. (That's a
On 2020-02-08 22:07:48, Otto Kekäläinen wrote:
> Hello!
>
> I've ended up in being both the maintainer in Debian and an upstream
> developer for a couple of packages and I have been fantasizing about
> how to optimize my workflow so that I primarily fix all bugs and do QA
> directly on the upstream
Package: wnpp
Severity: wishlist
Owner: Adam Cecile
* Package name: python-libais
Version : 0.17+git.20190917.master.e464cf8
Upstream Author : Kurt Schwehr
* URL : https://github.com/schwehr/libais
* License : Apache-2.0 / BSD-3-Clause
Programming Lang: C++ /
On Tue, 18 Feb 2020 at 12:44:18 +0100, Marco d'Itri wrote:
> On Feb 16, Simon McVittie wrote:
> > I think we have consensus that consolidating all static OS files into /usr
> > (removing the distinction between /usr and the static parts of the root
> > filesystem) is the route that Debian is takin
Package: wnpp
Severity: wishlist
Owner: "Luca Boccassi"
X-Debbugs-CC: debian-devel@lists.debian.org
Control: block 949763 by -1
* Package name: azure-data-lake-store-python
Version : 0.0.48
Upstream Author : Microsoft Corporation
* URL : https://github.com/Azure/azure-
On Tue, 2020-02-18 at 17:58:30 +0100, Svante Signell wrote:
> I recently installed Debian/bullseye/sid in a VM from a snapshot. After
> running that image I realized the I got a merged-user installation.
>
> As for now I have:
> bin -> usr/bin
> lib -> usr/lib
> lib32 -> usr/lib32
> lib64 -> usr/l
On Tue, 2020-02-18 at 12:25 +0100, Marco d'Itri wrote:
> On Feb 17, Wouter Verhelst wrote:
>
> > - Figure out a way for 32-bit binary-only programs to keep working when
> > they touch a time_t beyond 2038.
> I am sure that around 2035 "time namespaces" or something similar will
> be implemente
Simon Richter writes:
> On Tue, Feb 18, 2020 at 12:25:48PM +0100, Marco d'Itri wrote:
>> I am sure that around 2035 "time namespaces" or something similar will
>> be implemented to solve this.
> Hopefully a bit earlier. I have a few pieces of software that only build in
> virtual machines with
On Tue, 2020-02-18 at 17:35 +, jnq...@gmail.com wrote:
> On Tue, 2020-02-18 at 17:58 +0100, Svante Signell wrote:
> > Hello,
> >
> > I recently installed Debian/bullseye/sid in a VM from a snapshot.
> > After running
> > that image I realized the I got a merged-user installation.
> >
> > As f
On Tue, 2020-02-18 at 17:58 +0100, Svante Signell wrote:
> Hello,
>
> I recently installed Debian/bullseye/sid in a VM from a snapshot.
> After running
> that image I realized the I got a merged-user installation.
>
> As for now I have:
> bin -> usr/bin
> lib -> usr/lib
> lib32 -> usr/lib32
> lib
Roberto C. Sánchez writes ("Re: Announcing miniDebConf Montreal 2020 -- August
6th to August 9th 2020"):
> On Sat, Feb 15, 2020 at 12:05:29AM -0500, Jerome Charaoui wrote:
> > Following the announcement of the DebConf20 location, our desire to
> > participate became incompatible with our commitmen
Hello,
I recently installed Debian/bullseye/sid in a VM from a snapshot. After running
that image I realized the I got a merged-user installation.
As for now I have:
bin -> usr/bin
lib -> usr/lib
lib32 -> usr/lib32
lib64 -> usr/lib64
libx32 -> usr/libx32
sbin -> usr/sbin
Is there some way to ach
> "Marco" == Marco d'Itri writes:
>> I think we have consensus that consolidating all static OS files
>> into /usr (removing the distinction between /usr and the static
>> parts of the root filesystem) is the route that Debian is
>> taking. I think we do not have consensus on h
Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry
* Package name: isodatetime
Version : 2.0.1
Upstream Author : Oliver Sanders
* URL : https://github.com/metomi/isodatetime
* License : LGPL 3.0
Programming Lang: Python
Description : Python ISO
Package: wnpp
Severity: wishlist
Owner: Alois Micard
* Package name: golang-github-jaytaylor-html2text
Version : 0.0~git20190408.01ec452-1
Upstream Author : J. Elliot Taylor
* URL : https://github.com/jaytaylor/html2text
* License : Expat
Programming Lang:
Hi,
On Tue, Feb 18, 2020 at 12:25:48PM +0100, Marco d'Itri wrote:
> > - Figure out a way for 32-bit binary-only programs to keep working when
> > they touch a time_t beyond 2038.
> I am sure that around 2035 "time namespaces" or something similar will
> be implemented to solve this.
Hopefull
On Feb 16, Simon McVittie wrote:
> To be clear, what Guillem means by "a proper /usr-merged migration"
> here is changing individual library packages, so that the path to their
Everything I suppose, not just libraries.
> I think we have consensus that consolidating all static OS files into /usr
On Feb 17, Wouter Verhelst wrote:
> - Figure out a way for 32-bit binary-only programs to keep working when
> they touch a time_t beyond 2038.
I am sure that around 2035 "time namespaces" or something similar will
be implemented to solve this.
--
ciao,
Marco
signature.asc
Description: PGP
27 matches
Mail list logo
