Bug#1065416: requesting input on recent posts to #1065416

2024-08-16 Thread Bastian Blank
On Fri, Aug 16, 2024 at 12:58:22PM +0200, Stefano Rivera wrote: > The Technical Committee is hoping that this will be resolved without > requiring us to make a decision. If the take-over offer resolves the > issue, then we will probably vote to take no further action. Well, take-over removes the n

Bug#1065416: requesting input on recent posts to #1065416

2024-08-16 Thread Bastian Blank
On Sat, Jul 20, 2024 at 01:01:42PM +0200, Matthias Klose wrote: > I am re-adding lea...@debian.org, and now also commun...@debian.org. I still > don't see this as an issue that the Technical Committee should decide. This > is aggressively confrontational behavior of one of the Debian kernel > maint

Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

2024-05-13 Thread Bastian Blank
Hi On Sun, May 12, 2024 at 11:54:42PM +0200, Helmut Grohne wrote: > On Sun, May 12, 2024 at 07:35:09PM +0200, Bastian Blank wrote: > > > 1. API expectation of *-$arch-cross packages > > I asked exactly that in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=10654

Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

2024-05-12 Thread Bastian Blank
On Sun, May 12, 2024 at 01:53:33PM +0200, Helmut Grohne wrote: > 2+3+6+7. linux-libc-dev could be split into linux-libc-dev-common >arch:all m-a:foreign and the symlink farms could be kept in >linux-libc-dev:any m-a:same retaining the size reduction. This would not actually work. linux-li

Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

2024-05-12 Thread Bastian Blank
Hi Helmut On Sun, May 12, 2024 at 01:53:33PM +0200, Helmut Grohne wrote: > > Care to just share what you actually found? Where is it broken and how > > to see this? > > Because this whole thing started with "it is broken, but I won't tell > > you where or what or how". > Quite clearly, this is no

Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

2024-03-29 Thread Bastian Blank
Hi On Thu, Mar 21, 2024 at 08:48:01PM +0100, Helmut Grohne wrote: > I was recently working on gcc builds and this disagreement currently > makes stuff unbuildable. Hence I looked into solutions and/or > workarounds. Care to just share what you actually found? Where is it broken and how to see th

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

2023-05-18 Thread Bastian Blank
Hi Gunar On Thu, May 18, 2023 at 12:14:42PM -0600, Gunnar Wolf wrote: > dpkg has many bits that make it special. It has been discussed whethe > dpkg should be a native package or it should become non-native; if it > were non-native, having a patch that contradicts the upstream author's > wishes wo

Bug#1007717: Native source package format with non-native version

2022-03-29 Thread Bastian Blank
On Tue, Mar 15, 2022 at 04:29:17PM +, Ian Jackson wrote: > 1. Declare explicitly that there is nothing wrong with a package with > a native format, but a non-native version number. > 2. Request that the dpkg maintainer relax the restriction which > prevents the use of 3.0 native with

Bug#978636: move to merged-usr-only?

2021-01-26 Thread Bastian Blank
On Tue, Jan 26, 2021 at 09:56:46AM +, Simon McVittie wrote: > Oh, I see. So when you say "both" in 1a, you're referring to the overall > system - like the fact that we have both /bin/bash and /usr/bin/perl. Yes. > I don't see how we can force all packages to only ship files in /usr/* > (your

Bug#978636: move to merged-usr-only?

2021-01-26 Thread Bastian Blank
On Tue, Jan 26, 2021 at 09:01:12AM +, Simon McVittie wrote: > On Tue, 26 Jan 2021 at 08:02:06 +0100, Bastian Blank wrote: > > On Mon, Jan 25, 2021 at 09:22:29PM +, Simon McVittie wrote: > > > Some developers seem to be using "merged /usr" to refer to mul

Bug#978636: move to merged-usr-only?

2021-01-25 Thread Bastian Blank
On Mon, Jan 25, 2021 at 09:22:29PM +, Simon McVittie wrote: > Some developers seem to be using "merged /usr" to refer to multiple > concrete layouts: > 1. an arrangement where all regular files that have traditionally been >in /bin, /sbin, /lib and /lib64 are physically located in /usr, >

Bug#947847: please install systemd-sysusers using update-alternatives

2020-01-29 Thread Bastian Blank
On Wed, Jan 29, 2020 at 05:06:31PM +0100, Svante Signell wrote: > * E) systemd is not available on non-Linux - You don't need an alternative for something that does not exist. - Have you ever tried to build those parts of the systemd package on your favorite glibc non-Linux? Bastian -- There'

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

2017-07-02 Thread Bastian Blank
On Tue, Jun 27, 2017 at 11:31:57AM -0700, Josh Triplett wrote: > On Sun, 25 Jun 2017 23:37:13 +0100 Colin Watson wrote: > > I could arrange for the relevant grub2 postinst scripts to remove > > /etc/default/grub.d/init-select.cfg entirely when appropriate conditions > > apply. In addition to a se

Re: bastardizing packages or stepping down

2015-03-06 Thread Bastian Blank
On Fri, Mar 06, 2015 at 10:46:26AM +0100, Kurt Roeckx wrote: > I didn't see any request to make sure the chroots are updated. > Not having read the whole thing, would this solve your problem? We have 2015, we even have snapshot aware filesystems to make it safe. Why for gods sake is this still a m

Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-19 Thread Bastian Blank
On Sat, Jan 18, 2014 at 11:33:32PM +0100, Michael Biebl wrote: > On Sat, Jan 18, 2014 at 01:20:41PM +0100, Bastian Blank wrote: > > - lvm2.service is statically hooked to local-fs.target, as all local > > mounts. > lvm2.service is not a local mount, so that is not really a

Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-18 Thread Bastian Blank
Untested patch: - Static services with the correct name. - lvm2.service is statically hooked to local-fs.target, as all local mounts. - lvm2-early.service is statically hooked to cryptsetup.target, as all crypto devices. | drwxr-xr-x root/root 0 2014-01-18 12:32 ./lib/systemd/ | drwxr

Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-18 Thread Bastian Blank
On Sat, Jan 18, 2014 at 11:47:11AM +0100, Michael Stapelberg wrote: > --- /dev/null > +++ b/debian/lvm2-activation-early.service Wrong name. > +[Unit] > +Description=Activation of LVM2 logical volumes > +Documentation=man:lvm(8) man:vgchange(8) > +DefaultDependencies=no > +After=systemd-udev-sett

Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-16 Thread Bastian Blank
On Mon, Dec 02, 2013 at 03:11:03PM -0800, Don Armstrong wrote: > On Mon, 02 Dec 2013, Bastian Blank wrote: > > On Sun, Dec 01, 2013 at 05:49:13PM -0800, Don Armstrong wrote: > > > Bastian: Would such a patch be acceptable in principle? > > After systemd was fixed, yes. >

Bug#728486: Current patch for resolving lvm/systemd compatibility

2013-12-02 Thread Bastian Blank
On Sun, Dec 01, 2013 at 05:49:13PM -0800, Don Armstrong wrote: > Bastian: Would such a patch be acceptable in principle? After systemd was fixed, yes. Bastian -- Conquest is easy. Control is not. -- Kirk, "Mirror, Mirror", stardate unknown -- To UNSUBSCRIBE, email to debian-c

Re: Number typo in the Constitution

2012-07-09 Thread Bastian Blank
On Mon, Jul 09, 2012 at 04:07:38AM +0100, Ian Jackson wrote: > - Increment the section numbers of sections A.2 to A.6; I don't think this is a good idea, because it breaks _all_ existing references. At least in germany, they add a letter in this cases. So this would be A.1 and A.1a. Bastian

Re: #342455

2006-02-10 Thread Bastian Blank
On Fri, Feb 10, 2006 at 04:40:22PM -0800, Steve Langasek wrote: > Otherwise, having access to the underlying block devices means having access > to meddle with anything on the LVM devices as well. And who says that anyone have access to the underlying device? Bastian -- ... The prejudices peopl

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

2006-01-03 Thread Bastian Blank
On Tue, Jan 03, 2006 at 03:26:30PM +, Ian Jackson wrote: > Thanks for your patches. I don't have time right know to look at the > technicalities in detail. I did not get any response about the patches from upstream yet. >Do we have all of the relevant Debian LVM

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

2005-12-23 Thread Bastian Blank
206) +++ debian/changelog(local) @@ -1,3 +1,9 @@ +devmapper (2:1.02.02-1.0permission.1) UNRELEASED; urgency=low + + * Make device mode modificable. + + -- Bastian Blank <[EMAIL PROTECTED]> Fri, 23 Dec 2005 20:03:04 +0100 + devmapper (2:1.02.02-1) unstable; urgency=low

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

2005-12-23 Thread Bastian Blank
On Tue, Dec 20, 2005 at 12:35:00AM -0500, Raul Miller wrote: > I'm trying to ask why you are unwilling to have devmapper disks provide > a default of root.disk 660? Why can't you allow that to be the default? You can always make permissions less strict, you can't make them more strict, as the che

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

2005-12-23 Thread Bastian Blank
On Sat, Dec 17, 2005 at 03:09:37PM +, Roger Leigh wrote: > Bastian Blank <[EMAIL PROTECTED]> writes: > > > On Sat, Dec 17, 2005 at 12:41:17PM +, Roger Leigh wrote: > >> > Which procedure? You seem to know something I don't know. ("Overwrite"

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

2005-12-17 Thread Bastian Blank
On Sat, Dec 17, 2005 at 12:41:17PM +, Roger Leigh wrote: > > Which procedure? You seem to know something I don't know. ("Overwrite" > > means in my context: chmod of static devices or a MODE setting in the > > udev config) > A chown/chmod of the device is not scalable or practical. You recreat

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

2005-12-17 Thread Bastian Blank
On Fri, Dec 16, 2005 at 02:43:29PM -0500, Raul Miller wrote: > On 12/16/05, Bastian Blank <[EMAIL PROTECTED]> wrote: > > On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote: > > > Are you saying that the current default permissions on (eg) /dev/hda* > > >

Re: Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

2005-12-16 Thread Bastian Blank
On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote: > Bastian Blank writes ("Re: Bug#342455: tech-ctte: Ownership and permissions > of device mapper block devices"): > > On Tue, Dec 13, 2005 at 03:55:01PM +, Ian Jackson wrote: > > > [Raul Miller:] >

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

2005-12-14 Thread Bastian Blank
On Tue, Dec 13, 2005 at 03:55:01PM +, Ian Jackson wrote: > > 1) change devmapper defaults -- patch rejected, no reason given > Certainly I agree that the defaults should be changed. At least in my point of view, a default is something which can be changed easily, maybe in a config file. In thi