Re: Debian built from non-Debian sources

[Alexey Salmin]

On Wed, Jul 19, 2017 at 3:59 PM, Holger Levsen  wrote:
> I dont even see how there would
> be much delay, if we had the policy of say requiring a debian-cd upload
> (to sid) with the changes made to create the stable upload.

Sid likely won't work here because both sid and testing may get ahead
of the version used to build stable image. And even if sources match,
packages won't because of the build environment. The backports repo
looks more suitable, but again at some point you may want to see a
backported testing version of utilities there, not patched stable.

> And maybe (probably?) there is a case for the Stretch images where one tool
wasnt uploaded yet. Seems like a bug to me too (if thats the case), but not
really a reason for a flamewar nor calling out trolling.

In the compilers development a failure to build itself is normally
considered a critical compiler bug that blocks the release. Even
though bootstrapping is not the main purpose of compiler existence.
Similarly, a failure to produce an install image of debian on a system
running the same version of debian sounds like a perfectly valid
ground the delay the release.

I guess when the next release approaches someone may want to set up
nightly image builds of testing using clean testing environment and
report bugs in the building process (if any) as RC. I know the
debian-cd team already have weekly builds of testing, but I assume
they run the patched toolchain from alioth repo. I'll see if I can
arrange a self-build testing framework for x86 and amd64, but I'll
definitely won't be able to cover all archs.

Re: Debian built from non-Debian sources

[Alexey Salmin]

On Tue, Jul 18, 2017 at 9:15 PM, Ian Jackson
 wrote:
> Steve McIntyre writes ("Re: Debian built from non-Debian sources"):
>> For the record, all the changes I'm talking about go into public git
>> with all of the configuration and scripting that we use on our image
>> building machine.
>
> For me, this is the important part.  (There should be a pointer to it
> somewhere, ideally.)
>
> Since some people apparently want to improve it, then perhaps you
> could provide the url for the repo and they could send you patches.

I assume it's the repo on alioth [1].

[1] 
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?a=project_list;pf=debian-cd

Re: Debian built from non-Debian sources

[Alexey Salmin]

On Tue, Jul 18, 2017 at 4:51 PM, Scott Kitterman <deb...@kitterman.com> wrote:
>
>
> On July 18, 2017 8:41:43 AM EDT, Alexey Salmin <alexey.sal...@gmail.com> 
> wrote:
>>On Tue, Jul 18, 2017 at 2:09 AM, Steve McIntyre <st...@einval.com>
>>wrote:
>>> Making images often requires tweaks to the build script at/near
>>> release time. The archive continues to be a moving target until very
>>> close to that time. More than once we've fixed things or added
>>> workarounds in the image generation scripts *on release day*. I'm not
>>> going to remove the ability to do that and make working images to
>>> pander to your ideals here.
>>
>>This is very understandable. The thing is however, exact same
>>arguments can be applied to justify e.g. usage of proprietary software
>>to produce Debian images. In both cases tools used to reproduce an
>>image are not available to the community and it doesn't make much
>>difference whether these tools are completely unavailable or just
>>incorporate some non-public patches and tweaks. This is where people
>>get worried.
>
> Until someone volunteers to help, I think this is just a bunch of nit picking 
> that the people who are doing the work should actively ignore.  Personally, I 
> think sniping about how people who are doing the work are doing it "wrong" by 
> people who aren't is one of the most demotivating things that happens in 
> Debian.
>
> Is there anyone who cares about this that is willing to help?
>
> Scott K
>

No one can volunteer to fix it until it's acknowledged this is worth
fixing. So far it's maintained that the current approach is the right
one and should not be changed "to pander to smb's ideals". This is
something I disagree with. I write that reproducibility of images is a
valuable property and if current processes don't ensure it, then it's
reasonable to improve these processes. Now, if we manage to agree on
that -- then yes, volunteers are welcome to implement the actual
change. At the moment they're clearly not.

Re: Debian built from non-Debian sources

[Alexey Salmin]

On Tue, Jul 18, 2017 at 2:09 AM, Steve McIntyre  wrote:
> Making images often requires tweaks to the build script at/near
> release time. The archive continues to be a moving target until very
> close to that time. More than once we've fixed things or added
> workarounds in the image generation scripts *on release day*. I'm not
> going to remove the ability to do that and make working images to
> pander to your ideals here.

This is very understandable. The thing is however, exact same
arguments can be applied to justify e.g. usage of proprietary software
to produce Debian images. In both cases tools used to reproduce an
image are not available to the community and it doesn't make much
difference whether these tools are completely unavailable or just
incorporate some non-public patches and tweaks. This is where people
get worried.

Re: Can we kill net-tools, please?

[Alexey Salmin]

On Sun, Jan 8, 2017 at 10:49 PM, Tom H  wrote:
> On Fri, Jan 6, 2017 at 7:58 PM, Toni Mueller  wrote:
>> On Thu, Dec 29, 2016 at 09:01:51PM +0500, Andrey Rahmatullin wrote:
>>> On Thu, Dec 29, 2016 at 10:30:26AM -0500, Theodore Ts'o wrote:
>
>
 Ifconfig has been deprecated; you should probably use "ip a show
 dev lo" instad of the shorter and more convenient "ifconfig lo"
>>>
>>> ... and often wrong
>>
>> The BSD ifconfig can do this with ease, and since ages, too. Why is
>> the Linux ifconfig _so_ different? Forking for the sake of it?
>
> Is there any relationship between current ifconfig on Linux and the
> BSDs, other than the name? I don't think so. The BSDs have continued
> to develop ifconfig, adding many features and options.

Right, but this raises all kinds of questions like "Is it possible to
improve the ifconfig on Linux to catch up with the BSD version? And
even with ip?". Networking standards and protocols are
platform-independent, maintaining a Unix-wide interface to do the
basic networking stuff sounds like a reasonable thing to do. At this
time ifconfig seems to be the answer, no ip is visible on the BSDs
horizon.

I realize that net-tools version is long gone, but what about the GNU
inetutils one? It's supported and is not Linux-specific. Maybe a new
default implementation of ifconfig should be provided rather than
simply discarding one from a basic install. Another question is
whether you absolutely have to switch to netlink to have a reasonable
ifconfig implementation or ioctl is still acceptable (I don't know).

Alexey

Re: apt-listbugs

[Alexey Salmin]

Thank you, Francesco! Actually your mail convinced me that this should
be discussed more widely. It's probably too early for a bugreport on
the apt-listbugs because my original idea with using the affects
field will not work as is (see below).
This is why I'd like to hear opinions from debian-devel.
We're discussing the #642757: severe lag and high cpu usage when
using non-free nvidia driver with Xserver 1.11.1 which affected many
people. An the worst thing is: despite the fact it was reported
several times (13 reports merged) people were not warned by
apt-listbugs during the upgrade because they were upgrading
xserver-xorg-core and bugreport is against the
nvidia-graphics-drivers. More details below.

On Tue, Oct 18, 2011 at 2:37 AM, Francesco Poli
invernom...@paranoici.org wrote:
 On Mon, 17 Oct 2011 09:30:56 +0700 Alexey Salmin wrote:
 Many people got almost unusable desktops
 without any warning despite the fact this bug had been reported
 already. You upgrade one package and crash another, this is exactly
 what affects is for.

 In your example, if I understand correctly, you upgrade
 nvidia-graphics-drivers and crash xserver-xorg-core.
 This is described by the fact that bug #642757 is assigned to
 nvidia-graphics-drivers, but affects xserver-xorg-core.

No! That's the whole point! You upgrade xserver-xorg-core from 2:1.10
to 2:1.11 and your desktop dies because of a bug in
nvidia-graphics-drivers. If the issue was caused by an upgrade of
nvidia stuff everything would be fine: there's a bug in the nvidia
package and apt-listbugs warns you about it during the upgrade. But
it's not that way in this case. There's a bug in one package and it's
exposed by a new version of another. Probably that's a common scenario
e.g. a bug in a script could be exposed by a newer version of
interpreter or vice a verse. In this case you'll not get a warning
from apt-listbugs at all.

There're some ideas coming into mind how to solve it:

* Add Breaks: xserver-xorg-core (= 2:1.10.99) to nvidia-graphics-drivers
I won't work. As Andreas pointed out you can't add it to the package
which is in the archive already. Making a dummy commit wouldn't make
the things any better: it will not prevent people from upgrading
xserver-xorg-core but if will block the upgrade of
nvidia-graphics-drivers

* Create a dummy bug report on xserver-xorg-core saying e.g.
xserver-xorg-core 2:1.11 is incompatible with nvidia-graphics-drivers
285.05.09-1
It may help a bit but:
- Somebody should care enough to create such bug reports and close
them as appropriate.
- I doesn't depend on the actual version of nvidia-graphics-drivers
installed so it will show up in the cases it shouldn't.

* Make use of the 642757 affects xserver-xorg-core record
That was my original idea but it will not work as is because AFAIK
currently there's not way to specify the version of package affected
by some bug. So if someone have a nvidia-graphics-drivers=285.05.09-1
installed he'll be warned at ANY update of the xserver-xorg-core (even
when he makes a downgrade workaround) which is just useless.

MY SUGGESTION IS:
- Extend the affects record in the BTS to store the version of the
package affected
- Implement a feature in the apt-listbugs to make use of this records

I'll try to express this with more details:
1) There packages A of version X and B of version Y installed
2) You're trying to upgrade package B to version Z
3) There's a bug report NNN on package A=X and it affects B=Z
4) In this case apt-listbugs should warn you before upgrading B to Z

What do you think?

Alexey

 Where is the bug in this case?
 In nvidia-graphics-drivers, I would say: otherwise, the bug report
 should be reassigned elsewhere...

 As a consequence, which is the package that the user should _not_
 upgrade or install, in order to avoid being hit by the bug?
 Again, nvidia-graphics-drivers.
 And apt-listbugs correctly checks the bugs assigned to
 nvidia-graphics-drivers, before the upgrade or the installation of this
 package.

 There's no use in stopping an upgrade or installation of
 xserver-xorg-core because of a bug that merely affects this package:
 it's the other package (nvidia-graphics-drivers) the only one which is
 able to introduce the bug into the user's system.

 In summary, as long as a bug report is correctly assigned to the
 package that is actually responsible for the issue, this package is the
 only one which should not be upgraded/installed, in order to avoid
 introducing the bug into the system.

 This means that apt-listbugs should ignore the affects field, when
 run in apt mode. Which is exactly what it does.

 As far as apt-listbugs list pkg is concerned, listing bugs that
 merely affect pkg (while being assigned to a different package
 other_pkg) is a bit troublesome: how does that combine with version
 tracking?
 What if the user issues apt-listbugs list pkg/version?
 There's no indication about the version of other_pkg...
 I am convinced that this would generate a bunch

Re: lilo removal in squeeze (or, please test grub2)

[Alexey Salmin]

On Mon, May 31, 2010 at 10:25 PM, Marc Haber
mh+debian-de...@zugschlus.de wrote:
 I fully agree. The grub situation is as with KDE: Old version
 abandoned, new version not finished.

Not exactly. I was testing KDE4 since 3.97 and it was quite
interesting and amusing. Not many people like to test bootloader on
themself, though.

/* also grub2 works pretty well for me but nevertheless I've no idea
why we need to remove good old stable lilo */

Alexey


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktim3xsh7lcbbtvkkxlxmi5hfaw9cwz7l05-qv...@mail.gmail.com

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Alexey Salmin]

On Fri, May 7, 2010 at 2:59 PM, Mike Hommey m...@glandium.org wrote:
 On Fri, May 07, 2010 at 09:47:36AM +0200, Josselin Mouette wrote:
 Le jeudi 06 mai 2010 à 21:11 +0200, Petter Reinholdtsen a écrit :
  These days, the init.d script dependencies in Squeeze are quite
  complete, so complete that it is actually possible to run all the
  init.d scripts in parallell based on these dependencies.  If you want
  to test your Squeeze system, make sure dependency based boot
  sequencing is enabled, and add this line to /etc/default/rcS:
 
    CONCURRENCY=makefile

 Seems to work fine for me. However the gain isn’t really important,
 given that the critical path includes fsck and networking.

 And kernel+initramfs. That's more than half the boot time (without
 even CONCURRENCY=makefile) here.

AFAIK the main idea right now is not to significantly speed up the
boot process but to move from obsolete lexicographic script ordering
and keep up with event-driven trends in the kernel. It's important to
test new infrastructure carefully and spread it across Debian users,
after that we can work on further improvements like decreasing the
boot time. I'm not a insserv developer though, please correct me if I
get it wrong.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/j2q87a8dc11005070113t8a909d24n85506ab99ffe6...@mail.gmail.com

Re: btrfs

[Alexey Salmin]

I think it's reasonable for package maintainers to check compatibility
with the kernel from the
distribution they upload package to. Especialy here when package is
newer then kernel driver.
It's of course harder to supervise the situation when kernel pass
ahead of user-space packages
but it's also possible.

Alexey

2009/10/7 Josselin Mouette j...@debian.org:
 Le mercredi 07 octobre 2009 à 14:12 +1100, Russell Coker a écrit :
 I expect that the kernel team tends to be more careful about uploads to
 Unstable than most package maintainers due to the scope of damage that a bad
 kernel can cause.

 I think it is unreasonable to ask them to check interactions with
 hundreds, if not thousands, of packages in the archive. You are asking
 the impossible from people who are already doing a great job providing
 kernel images that basically never break after an upgrade – unlike, say,
 CUPS packages.

 Cheers,
 --
  .''`.      Josselin Mouette
 : :' :
 `. `'   “I recommend you to learn English in hope that you in
  `-     future understand things”  -- Jörg Schilling



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: btrfs

[Alexey Salmin]

 On Wed, 7 Oct 2009, Alexey Salmin alexey.sal...@gmail.com wrote:
 I think it's reasonable for package maintainers to check compatibility
 with the kernel from the
 distribution they upload package to. Especialy here when package is
 newer then kernel driver.
 It's of course harder to supervise the situation when kernel pass
 ahead of user-space packages
 but it's also possible.

 In general I agree that user-space tools should not be uploaded until there is
 a kernel that can work with them.  The fact that I made a filesystem with
 mkfs.btrfs and can't mount it is obviously not ideal.  Of course with this
 type of change if the upload of the btrfs-tools had been delayed so that the
 kernel got in first then we would STILL have had the same situation (I
 believe that there was neither forward nor backward compatibility).

I just mean that it's easier for package maintainers to see if their upload
breaks compatibility than observe that a kernel update broke something.
Of course both situations are bad.

Alexey


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Remove a package?

[Alexey Salmin]

Hello! At first I want to say that I'm not sure that this mailing list
is a right place for my letter. Secondly, this letter isn't actually
about some specific package, I'm just interested in understanding
Debain policies.
Is there any way to remove some package from debian distribution? For
example: package bcrypt is completely dead. It doesn't work at amd64
at all because of obvious bug, which I've reported here (path
included) half a year ago, but got no response. Last update of
official site (http://bcrypt.sourceforge.net/) was in September 2002.
This program doesn't work and has no support. Is there any reason to
keep such packages?

Alexey


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org