date:20240330

Bug#1067582: gnuplot: please provide a profile to break B-D cycle

2024-03-30 Thread Thorsten Glaser

Hi Dima,

>- Today leptonlib Build-Depends on gnuplot-nox only if !nocheck. So if
>  you build leptonlib with testing disabled, there's no dependency on
>  gnuplot

oh, that is maybe new? But I see other packages depending on
gnuplot-nox, so this would still be very helpful.

>- Today the gnuplot source package has a hard Build-Depends on wxt and
>  qt. Removing either of those (even in a specific profile) would make
>  it impossible to build gnuplot-qt and gnuplot-x11 packages with the
>  same set of functionality they normally have.

Yes, I just hacked the package to just not build these two packages,
basically by commenting lines from d/rules and removing the paragraphs
from d/control (although the -N flag for dh would also do) and I got
the expected gnuplot-nox and no -qt/-x11. (m68k only, the other arches
will need this as well, so… still needed.)

>  If a profile was added
>  to loosen either of these dependencies, but that dramatically changed
>  the end product, would that be useful?

Build profiles are allowed to remove packages from the result, as long
as the other packages are not drastically changed.

Since gnuplot builds x11, qt and nox separately anyway (and arch:all is
also built separately), that would work.

It may be best to look at another package where a build profile is used
to elide a binary package to have an example of how this can go. If you
want, I can search one for you, I’ve worked with several of them during
the last few weeks.

Thanks,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1068024: Potential solution to your downgrade problem in dpkg

2024-03-30 Thread Thorsten Glaser

Joshua Hudson dixit:

>2) Statically link all the decompressor libraries into dpkg. Yes this means

Totally no.

Also, at this point in time, I’m pretty sure that new external
suggestions are… not very helpful. The situation is being analysed
by a cross-team taskforce, please let them do the already-stressing
job ☻

bye,
//mirabilos
-- 
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against
 ╳  HTML eMail! Also,
╱ ╲ header encryption!

Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

2024-03-30 Thread Diane Trout

Hi Julian,

On Sat, 2024-03-30 at 20:22 +, Julian Gilbey wrote:
> Lovely to hear from you, and oh wow, that's amazing, thank you!
> 
> I can't speak for anyone else, but I suggest that pushing your
> updates
> to the science-team package would be very sensible; it would be silly
> for someone else to have to redo your work.
> 
> What more is needed for it to be ready for unstable?

The things I think are kind of broken are:

We've got 7.0.0 and upstreams current version is 15.0.2.

the pyarrow 7.0.0 tests fail because it depends on a python test
library that breaks with pytest 8.0. Either I need to disable the
python tests or upgrade to a newer version.

My upgrade didn't go smoothly because uscan found also upstreams debian
watch file which is too loose and matches some other tar balls on their
distribution site.

(Though I don't know why uscan keeps looking for watch files after
finding one in debian/watch)

And you were probably right in that arrow needs to be a team, because I
have no idea how to get other the other languages interfaces packaged.

Oh and I probably need to get the pyarrow installed somewhere, since it
was stopping at the tests I hadn't run into dh_missing errors yet.

Diane

Bug#1068117: dieharder: dab_monobit2 crashes with ntuple > 17

2024-03-30 Thread Lucas Thode

Package: dieharder
Version: 3.31.1.4-1.1
Severity: normal
X-Debbugs-Cc: thode...@gmail.com

Dear Maintainer,

`dieharder -d 209 -n $nvalue` crashes for $nvalue>17:

$ dieharder -d 209
#=#
#dieharder version 3.31.1 Copyright 2003 Robert G. Brown  #
#=#
   rng_name|rands/second|   Seed   |
mt19937|  1.55e+08  |2819069712|
#=#
test_name   |ntup| tsamples |psamples|  p-value |Assessment
#=#
dab_monobit2|  12|  6500|   1|0.40510331|  PASSED
$ dieharder -d 209 -n 12
#=#
#dieharder version 3.31.1 Copyright 2003 Robert G. Brown  #
#=#
   rng_name|rands/second|   Seed   |
mt19937|  2.54e+08  | 152376536|
#=#
test_name   |ntup| tsamples |psamples|  p-value |Assessment
#=#
dab_monobit2|  12|  6500|   1|0.10580971|  PASSED
$ dieharder -d 209 -n 17
#=#
#dieharder version 3.31.1 Copyright 2003 Robert G. Brown  #
#=#
   rng_name|rands/second|   Seed   |
mt19937|  2.29e+08  |2998370165|
#=#
test_name   |ntup| tsamples |psamples|  p-value |Assessment
#=#
dab_monobit2|  17|  6500|   1|1.|  FAILED
$ dieharder -d 209 -n 18
*** stack smashing detected ***: terminated
Aborted
$ dieharder -d 209 -n 27
*** stack smashing detected ***: terminated
Aborted
$ dieharder -d 209 -n 28
Segmentation fault

P.S. There are more issues with this test not liking non-standard n values, as
can be seen from it failing miserably on mt19937 with -n 17, but the crash is
the most glaring problem.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dieharder depends on:
ii  libc6 2.37-15
ii  libdieharder3t64  3.31.1.4-1.1
ii  libgsl27  2.7.1+dfsg-6+b1

dieharder recommends no packages.

dieharder suggests no packages.

-- no debconf information

Bug#1067952: mes: FTBFS on armhf

2024-03-30 Thread Vagrant Cascadian

Control: forwarded 1067952 
https://lists.gnu.org/archive/html/bug-mes/2024-01/msg8.html

On 2024-03-29, Kentaro HAYASHI wrote:
> mes 0.26-1 fails to build on armhf.
>
> FYI:
>
> https://buildd.debian.org/status/fetch.php?pkg=mes=armhf=0.26-1=1704511792=0

Yeah, forwarded this upstream in January, but have not yet found a fix.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1068024: Potential solution to your downgrade problem in dpkg

2024-03-30 Thread Joshua Hudson

The dpkg -> xz-utils downgrade problem has a suggestion that suggests
itself.

1) Downgrade dpkg's dependency to the last known good. It doesn't matter
how old so long as it can read the file formats. I understand this is
likely to be 5.4.1.

2) Statically link all the decompressor libraries into dpkg. Yes this means
gzip, bzip2, zstd, and xz's libraries. Today's compile and link time
optimizers are pretty good; it should be able to drop all references to the
compression side pretty much by itself. This would generally be a pretty
good change of its own as it makes the minimal system easier to understand
and the net-install CD smaller.

Then you're free to do what you need to do for all the other dependencies
of xz-utils.

Bug#1068024: revert to version that does not contain changes by bad actor

2024-03-30 Thread Thorsten Glaser

Christoph Anton Mitterer dixit:

>Is anyone on the Debian side trying to figure out how far we've been
>practically affected?

Yes, a multi-team task force is working on it and will inform users
once it is known how to proceed, inclusing how much to throw away
and rebuild.

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#1068024: revert to version that does not contain changes by bad actor

2024-03-30 Thread Thorsten Glaser

Pierre Ynard dixit:

>version into the Debian archive, as seen in #1067708. To quote Thorsten
>from that thread:
>
>> Very much *not* a fan of NMUs doing large changes such as
>> new upstream versions.
>
>I can't say why exactly he would not be a fan, but with hindsight that
>was an interesting call.

It turned out to indeed be related, although I cannot blame Sebastian
for not spotting it, as well as it was hidden. I actually wrote about
that earlier on Fedi: (Markdown formatting lost here though)

| I was considering replying to this comment on the “please update xz
| package” bugreport earlier with that the discussion is not irrelevant
| and that it’s the maintainer’s responsibility on new upgrades to check
| for new legal issues and “other hidden gems”.
|
| I didn’t because I didn’t want to bother going in with an annoyed
| self-righteous “user”.
|
| Now it turns out all three of the involved ones were “string + number
| @ freemailer” #JiaT75 sockpuppets, so it’s probably okay I didn’t
| bother.
|
| Not that I blame Sebastian — it was very well hidden, and even my
| usual diffing between old and new version would not have found it.
|
| I do take away from this to also check the diff between VCS repo at
| the time of the release and release tarball. Perhaps also between
| branch and tag if they, like Apache Tomcat, introduce extra commits
| there.

>Is xz-utils going to be maintained? Will we want to keep in the archive
>an unmaintained low-level library - low-level as in, susceptible of
>getting pulled as a dependency in lots of places - and rely on it for
>components such as dpkg?

That scenario you describing here would actually be much less of a
problem. The problem comes when the library in that state then does
get updates that probably are not even necessary but shiny enough
people demand them.

bye,
//mirabilos (also a Debian Developer, despite the From)
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#940151: unattended-upgrades: i configure my unattended-upgrade conf with following Origins:

2024-03-30 Thread Wesley Schwengle



Hi,

> Unattended-Upgrade::Allowed-Origins {
> "o=Debian, a=stable";
> "o=Debian Backports, a=buster-backports"; };

The problem with the example is that it uses a=CODENAME-backports and not
a=stable-backports. The a= should be n= or codename= when using the CODENAME.

I've created PR https://github.com/mvo5/unattended-upgrades/pull/359 for this.

Cheers,
Wesley

Bug#1068024: revert to version that does not contain changes by bad actor

2024-03-30 Thread Thorsten Glaser

Christoph Anton Mitterer dixit:

>Can we be confidently sure that going back to 5.4.5 is enough?

No.

>The last one, still from Lasse Collin seems to be 5.4.1:

In this bugreport, we’re discussing going back to before any
contributions by the adversary. To see whether it’s an option
at all (and it sounds like a sensible step right now) which
joeyh confirmed (thanks).

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#1068024: revert to version that does not contain changes by bad actor

2024-03-30 Thread Christoph Anton Mitterer

One more thing:

Is anyone on the Debian side trying to figure out how far we've been
practically affected?

I mean let's assume we're "lucky", and the backdoor is only in
5.6.0/5.6.1... and that none of the adversary's earlier commits
introduced any serious holes[0] which wouldn't be known yet.

Then many servers running Debian (which is then typically Debian
stable), would be sill safe.

However, many people (and I'd guess that includes DDs/DMs) run their
workstations/laptops with testing/unstable.
So IMO it's not enough to know that Debian stable is likely not
affected - I'd be rather relieved if I'd knew that there's a good
chance that the personal computers of most DDs/DMs (who push uploads,
etc. pp.) were (at least practically) safe.

Some guy decrypted[1] the strings from the maleware's binary payload:
https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01#file-hashes-txt-L115
where only /usr/sbin/sshd would be named.

Should(!) it turn out, that the actual binary payload actually only
affects sshd and especially does not on it's own pull in evil code, it
might at least be that all people who hadn't sshd running (or not
directly accessible because a router/firewall/etc. was in front of it),
would effectively still be safe.
No idea whether or not this is really the case - but if so, it might at
least mean that many workstations/laptops are safe, because they're not
usually directly accessible from the internet.

But even then, it would probably need to be checked whether all the
versions that Debian ever used/shipped in
testing/unstable(/experimental) were actually fully identical to the
versions that are now analysed by forensic folks.

Is the security team doing anything like that?

Cheers,
Chris.

PS: if someone from the security team reads along,
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
which is from Sam James of Gentoo, seems to collect good information on
what is known so far.
Might be worth to add to the links in the security tracker.

[0] There are reports about an added '.' in the CMakeLists.txt
disabling some sandboxing, but AFAICS at least the current version uses
autotools for building?!

[1] He also provided the code he used to do so.
https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01?permalink_comment_id=5006546#gistcomment-5006546

1 2 >

1 - 100 of 138 matches

Mail list logo