BTW, only 32bit kernel is affected by such behavior with this patch, not
amd64..
On Wed, Jun 26, 2024 at 7:30 PM Milan Kostić wrote:
> Package: src:linux
> Version: 4.19.316-1
> Severity: normal
>
> Dear Maintainer,
>
>
> Very weird behavior on a last update with cursor
Package: src:linux
Version: 4.19.316-1
Severity: normal
Dear Maintainer,
Very weird behavior on a last update with cursor, when i open nearly any app.
It is busy when it is not busy,
flickers like crazy, do not want to close windows, etc... anyway i bisected
this to:
mm: fix
Yes, this stupid thing should be fixed in
https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/303
Milan
a look at the attached patch. It applies and fixes the bookworm and
bullseye versions. It seems the buster version is not vulnerable to this
particular issue.
MilanDate: Tue Apr 23 10:54:50 2024 -0700
Author: Mark Nudelman
Author: Milan Kupcevic
Origin: upstream, https://github.com/gwsw
On 4/20/24 15:59, Johannes Schauer Marin Rodrigues wrote:
Quoting Milan Kupcevic (2024-04-20 21:46:14)
On 4/20/24 15:05, Johannes Schauer Marin Rodrigues wrote: [...]
Quoting Milan Kupcevic (2024-04-20 20:50:27)
This package builds just fine either on or off an island. The "pre-
to tell me if I
should delay it longer.
As well pushed in a separte branch on salsa, which can be merged if
accepted to unstable:
https://salsa.debian.org/debian/less/-/tree/sid-2024-security-fixes?ref_type=heads
Regards.
Salvatore
ACK.
Thank you Salvatore; much appreciated.
Milan
Hi Josch,
On 4/20/24 15:05, Johannes Schauer Marin Rodrigues wrote:
[...]
Quoting Milan Kupcevic (2024-04-20 20:50:27)
This package builds just fine either on or off an island. The "pre-built
artifacts" is actually the build support provided by the upstream for their
official relea
Hi Josch,
This package builds just fine either on or off an island. The "pre-built
artifacts" is actually the build support provided by the upstream for
their official release package. It is nice to rebuild the build support,
but is not required nor always desired.
Milan
On 2/
on2 and possible dependences of above (libgcc_s).
So if the reason is cryptsetup, all these dependences should be removed, we do
not need it anymore.
Milan
e anything with -d 209 and -n over 15 corrupts memory and cannot
get
any useful output.
Milan
; to force static link.
This is what I get from current code
(https://github.com/eddelbuettel/dieharder):
./dieharder/dieharder -d 209 -n 17 -p 1
Error: Can only use ntup up to 15.
Read test description with dieharder -d 209 -h.
Milan
:
https://github.com/eddelbuettel/dieharder/pull/24
Milan
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:simulide
New release version is reducing supported architectures down to
amd64 and i386 only.
Milan
upstream for a
license change or drop the files from the source package.
Hi Bastian,
I was not able to identify any invariant sections in documentation. As
far as I can see this document [0] is free and is eligible for Debian
main in accordance with General Resolution 2006/001 [1]
Milan
[0
at this point is to upload
the updated package version together with the newly introduced
dependencies to sid and let the system to auto-remove the old package
from bookworm.
As soon as bookworm gets released we can make the updated esptool
available via bookworm-backports.
Milan
On 2/21/23 07:16
Just FYI - I think that the whole problem can be avoided by merging this patch
https://github.com/P-H-C/phc-winner-argon2/pull/331
(we have the patch applied in cryptsetup for embedded libargon already).
Just upstream is no longer responding here...
Milan
hello Sarraf,
On Thu, Feb 23, 2023 at 2:44 PM Ritesh Raj Sarraf wrote:
> On Thu, 2023-02-23 at 14:19 +0100, Milan Oravec wrote:
> > > >
> > >
> > > By KVM, do you mean just pure KVM ? Or the management suite too,
> > > libvirt ?
> > >
>
Hello,
On Thu, Feb 23, 2023 at 1:35 PM Ritesh Raj Sarraf wrote:
> Hello Milan,
>
> On Mon, 2023-02-20 at 09:51 +0100, Milan Oravec wrote:
> > > >
> > >
> > > So did you trigger a cluster takeover ? My guess is it is your
> > > target
> >
Hello,
On Thu, Feb 16, 2023 at 2:16 PM Ritesh Raj Sarraf wrote:
> Hello,
>
> On Wed, 2023-02-15 at 19:21 +0100, Milan Oravec wrote:
> > > > I've lot of this error messages ind dmesg:
> > > >
> > > > Feb 09 10:56:05 virt2n kernel: connection2
00 00 00
[Wed Feb 15 19:05:12 2023] sd 1:0:0:3: [sdh] tag#65 FAILED Result:
hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK
[Wed Feb 15 19:05:12 2023] sd 1:0:0:3: [sdh] tag#65 CDB: Test Unit Ready 00
00 00 00 00 00
[Wed Feb 15 19:05:12 2023] sd 1:0:0:15: [sdaf] tag#6 FAILED Result:
hostb
repository under the common lisp team at salsa and drafted a
BX> merge request[4].
Thank you for your effort, feel free to take over the package and upload
it with a changed maintainer. I have no longer interest in the package
and have forgotten I’m listed there as a maintainer rather than the
Common Lisp team.
Regards,
Milan
On 12/13/22 14:30, Dirk Eddelbuettel wrote:
On 13 December 2022 at 14:23, Milan Broz wrote:
| We have the same issue with empty lines, temporarily workarounded by adding
-fcommon to CFLAGS (on several places)
| (so yes, it was gcc-10 introduced problem).
:-/
| But that off_t fix works too
We have the same issue with empty lines, temporarily workarounded by adding
-fcommon to CFLAGS (on several places)
(so yes, it was gcc-10 introduced problem).
But that off_t fix works too, thanks!
Milan
Actually this patch is better, just displays usage and also check upper
boundary (another segault with -d 10 ...)
https://github.com/mbroz/dieharder/commit/7d60208c8a8beabe6d3d5a88399b83ebf03240a5
Package: dieharder
Version: 3.31.1.2-1+b1
Severity: normal
Dear Maintainer,
dieharder utility segfaults if standalone help (-h) option is used.
$ dieharder -h
Segmentation fault (core dumped)
Fix is trivial, see patch here
el list.
Cryptsetup cannot "optimize" any performance flags to use, this would fix one
issue and cause many others.
Milan
Today's unstable update to 102.0.2-1 breaks NNTP completely for me.
Reading the upstream bug link, I tried to disable master password, then
it was somehow able to connect to one server, but never to others (I have 3
NNTP accounts in my profile).
So this is a quite major regression...
Milan
0.3.19-4, no changes in config.)
With 0.3.44-1 from unstable it works again.
Thanks!
Milan
le error - if not, we have to fix it.
(Verbose option only translates return code to something readable but there
should
be an error message much earlier.)
Is it simple cryptsetup open activation (no systemd-cryptsetup magic)?
(If so, please add new issue upstream and link this bug, we will fix that.)
Thanks,
Milan
Package: isc-dhcp-server
Version: 4.4.1-2.3
Followup-For: Bug #968298
Dear Maintainer,
-- System Information:
Debian Release: 11.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Hello,
what's the status of the fix/patch in this bug?
We see many leaks for cryptsetup in valgrind tests if running under Debian
(while other distros apparently do not have this problem) and it seems
all reported problems are with poptGetNextOpt ...
Thanks,
Milan
Package: wnpp
Severity: wishlist
* Package name: python3-reedsolo
Version : 1.5.4
Upstream Author : Tomer Filiba
* URL : https://github.com/tomerfiliba/reedsolomon
* License : CC0
Programming Lang: Python
Description : reed solomon encoder/decoder
A
store a timestamp in the range from 1970-01-01 00:00:01 UTC
through 2106-02-07 06:28:15 UTC. If you are having trouble with
timestamps after 2038-01-19 03:14:07 UTC but not later than 2106-02-07
06:28:15 UTC, that is likely due to a limitation present at some other
place i.e. glibc, gcc, filesystem, kernel ...
Milan
Package: gzip-win32
Version: 1.10-2
Severity: serious
Affects: win32-loader
Tags: d-i pending
Owner: Milan Kupcevic
Submitter: Thomas Gaugler
Merge request opened 6 months ago by Thomas Gaugler:
I noticed that gzip-win32 1.10-2 depends on the libssp-0.dll dynamic link
library.
Therefore
unreproducible.
Please find attached build log and buildinfo files for comparison and
let me know if you are able to reproduce this bug in your environment.
Milan
dpkg-buildpackage -us -uc -ui
dpkg-buildpackage: info: source package simavr
dpkg-buildpackage: info: source version 1.6+d
Package: grub-efi-amd64
Version: 2.02+dfsg1-20+deb10u2
Followup-For: Bug #908200
Dear Maintainer,
*** Reporter, please consider answering these questions, where
appropriate ***
* What led up to the situation?
On my server, I'd like to have the grub installed on all disks of
the RAID.
46ee71edcd13e1dad50815ad65c28779aa6f7503
752c9a52798f11d3b765b673ebaa3058eb25316e
Milan
I use Dovecot 1:2.3.4.1-5+deb10u1 on Debian 10. Setting
"stats_writer_socket_path=" does not resolve the issue in my case, I
also get "net_connect_unix() failed". The following patch is supposed
to fix the issue:
https://dovecot.org/pipermail/dovecot/2019-January/114170.html
On 20/01/2020 14:11, Guilhem Moulin wrote:
> Milan, should I forward that upstream (verbatim)?
Sure, put it to the upstream, issue tracker , but I definitely need a clear
reproducer (with the latest stable - 2.2.2 or 2.3.0-rc0) - ideally with
attached debug and system log.
(Debug
I sent patch upstream, if you could, please reply directly to the dm-devel list:
https://www.redhat.com/archives/dm-devel/2020-January/msg00012.html
Thanks!
Milan
with your name)
Thanks for the report!
Milan
On 2020-01-02 15:54, Bernd Zeimetz wrote:
>
> any idea if this affects 14.2.4?
>
Reports are pointing to 14.2.5, so far.
Also see https://tracker.ceph.com/issues/43317
Milan
/43364
Milan
On 2019-12-27 16:14, Thomas Goirand wrote:
> On 12/26/19 1:49 AM, Bernd Zeimetz wrote:
>> Hi Milan,
>>
>> I gave you access to the salsa team as requested.
Sounds good.
>>
>> Please coordinate what you want to work on with Thomas (zigo@d.o) and me.
>
Package: ceph-osd
Version: 14.2.4-4
Severity: grave
Tags: upstream fixed-upstream
A critical bluestore data corruption bug[0][1] affecting OSDs configured with
separate db and/or wal devices has been introduced in 14.2.3 and is affecting
both 14.2.3 and 14.2.4 upstream releases[2]. This bug has
gt; should be.
I agree.
>
> What will happen - after ceph migrated to testing - is a backport to buster.
>
Excellent.
> If you want to help, please test hte packages and look into build issues.
>
I will look into it.
Could you please push the uploaded version commits to the package salsa
repository?
Milan
with upstream[0] svn commit 1415. Please
engage the upstream development project and explain the problem and
possible solutions. In the meantime I'm setting severity of this bug
report to wishlist and tagging it as an upstream issue.
Milan
[0] http://svn.savannah.gnu.org/viewvc/avrdude?view=rev
eam development project if you want to argue about their decision.
In the meantime I'm setting severity of this bug report to wishlist and
tagging it as an upstream issue.
Milan
signature.asc
Description: OpenPGP digital signature
On 26/08/2019 08:03, Milan Broz wrote:
> No need to report it upstream, I'll fix it. This is really stupid bug, all
> sizes in code
> must be uint_64t. I just wonder why no static analysis screamed here, I run
> it on 32bit...
Fixed here
https://gitlab.com/cryptsetup/crypt
On 26/08/2019 03:28, Guilhem Moulin wrote:
> On Sun, 25 Aug 2019 at 12:43:26 +, n...@waifu.club wrote:
>> Not only the access to protected data is lost, the integritysetup's "open"
>> operation actually succeeds. All reads on the incorrectly created DM device
>> will of course fail with I/O
in sid, testing and buster-pu. I'm about to upload fixed
basez/1.6-3+deb9u1 package for stretch. See attached debdiff.
Milan
diff -Nru basez-1.6/debian/changelog basez-1.6/debian/changelog
--- basez-1.6/debian/changelog 2016-10-27 09:33:37.0 -0400
+++ basez-1.6/debian/changelog 2019-08
in sid and testing. I've prepared fixed basez/1.6-3+deb10u1 package
for buster. See attached debdiff.
Milan
diff -Nru basez-1.6/debian/changelog basez-1.6/debian/changelog
--- basez-1.6/debian/changelog 2016-10-27 09:33:37.0 -0400
+++ basez-1.6/debian/changelog 2019-08-11 18:59
f you want to fill an issue for us, tracker
is here https://gitlab.com/cryptsetup/cryptsetup/issues
Thanks,
Milan
es here.)
You can change PBKDF parameters for existing device (preserving data) with
cryptsetup luksConvertKey command, it takes the same PBKDF options.
(So you can "downgrade" to PBKDF2 or decrease limits.)
Milan
levis deal with LUKSv2 headers B-)
Clevis/Tang already supports direct metadata store to LUKS2 token objects
(so the luksmeta package is obsolete for LUKS2 format).
IIRC they use cryptsetup token command in the wrapper.
Milan
using LUKS2 with luksmeta does not make sense (there will be no gap for
your metadata),
so you should use --type luks1 anyway.
Thanks,
Milan
< util_blitter_generate_mipmap: Assertion `!util_format_has_stencil(desc)'
failed.
I think debian Mesa packages should disable these assertions, that was
disabled before in 18.2.8 and earlier...
Maybe it is leftover because of Meson build system now, that have
assertions enabled by default, so
additem=avrdude
and work with the upstream on the issue.
Milan
ntical chip).
>
> Likewise while I'm here, the ATtiny84A has an identical problem,
> similarly fixed by
>
> part parent "t84"
> id = "t84a";
> desc = "ATtiny84A";
> ;
>
> There are likely to be many more "A" variants that should be aliased
> like these.
>
Please file a bug report at:
http://savannah.nongnu.org/bugs/?func=additem=avrdude
and work with the upstream on the issue.
Milan
On Sat, Oct 13, 2018 at 11:38:42AM +0200, Milan Bouchet-Valat wrote:
> OK, thanks, I guess it's fine as long as the default is OpenBLAS.
> BTW, it would be very useful to build with USE_BLAS64=1
> OPENBLAS_SYMBOLSUFFIX=64_ to use an ILP64 BLAS. Without this,
> packages using BinaryBu
OK, thanks, I guess it's fine as long as the default is OpenBLAS.
BTW, it would be very useful to build with USE_BLAS64=1
OPENBLAS_SYMBOLSUFFIX=64_ to use an ILP64 BLAS. Without this, packages
using BinaryBuilder/BinaryProvider which call BLAS won't install. This
affects notably Arpack.jl, which
I second this (and I'm sure this reflects the opinion of upstream in
general). It's really important that after installing the julia package
one gets the same performance as with official upstream binaries. It's
a trap to use the Netlib reference BLAS/LAPACK by default, which is
known to be
Package: julia
Version: 0.7.0-2
Severity: normal
Hi,
I've noticed that the package currently builds a single sysimage for
the baseline CPU target (i.e. pentium4 and x86-64). Recent Julia
versions allow specifying multiple targets via JULIA_CPU_TARGET. This
allows building one image for the
Package: ghostscript
Version: 9.20~dfsg-3.2+deb9u5
After upgrade from ghostscript 9.20~dfsg-3.2+deb9u2 to 9.20~dfsg-3.2+deb9u5,
pstoedit with the option "-psarg -r9600x9600" no longer works. The following
commands can be used to reproduce the issue:
$ cat test.tex
\documentclass{article}
On 16/09/18 00:08, procmem wrote:
> The recommended config paramters by Milan Broz:
>
> # cryptsetup luksConvertKey --key-slot 1 --pbkdf argon2id
> --pbkdf-force-iterations 50 --pbkdf-memory 1048576 --pbkdf-parallel 4
>
NO!
This was an example, as you asked how to setup key
regards
On Fri, 2018-09-07 at 03:14, Michael Biebl wrote:
> Control: tags -1 + moreinfo
>
> On Mon, 6 Feb 2017 15:45:20 +0100 "Milan P. Stanic" wrote:
> > Package: systemd
> > Version: 232-15
> > Severity: normal
> >
> > Dear Maint
us as ceph12 and let me and potentially other
interested people to work on packaging of ceph13?
Milan
signature.asc
Description: OpenPGP digital signature
Package: ceph
Version: 10.2.5-7.2
Severity: normal
Please update ceph package to Mimic v13.2.x long term stable release series.[0]
Milan
[0] http://docs.ceph.com/docs/master/releases/mimic/
Package: wnpp
Severity: normal
I haven't used (and maintained) the package for very long time, so I'm
orphaning it.
Package: wnpp
Severity: normal
The only purpose of packaging cpopen was to provided it as a required
dependency for Vdsm packaging. Since Vdsm packaging has been abandoned,
there is no sense to provide cpopen in Debian any longer. So I'm
orphaning the package and it can safely disappear.
Package: wnpp
Severity: normal
The only purpose of packaging sanlock was to provide it as a required
dependency for Vdsm packaging. Since Vdsm packaging has been abandoned,
I'm orphaning the package. If you use it for some purpose, please
consider adopting and fixing it.
Package: wnpp
Severity: normal
The only purpose of packaging safelease was to provided it as a required
dependency for Vdsm packaging. Since Vdsm packaging has been abandoned,
there is no sense to provide safelease in Debian any longer. So I'm
orphaning the package and it can safely disappear.
Package: wnpp
Severity: normal
The only purpose of packaging pthreading was to provided it as a required
dependency for Vdsm packaging. Since Vdsm packaging has been abandoned,
there is no sense to provide pthreading in Debian any longer. So I'm
orphaning the package and it can safely
Package: wnpp
Severity: normal
The only purpose of packaging ioprocess was to provided it as a required
dependency for Vdsm packaging. Since Vdsm packaging has been abandoned,
there is no sense to provide ioprocess in Debian any longer. So I'm
orphaning the package and it can safely disappear.
Thank you for the report and the patch. I applied the patch and
uploaded the updated package. I'm going to review the bug further
later, together with updating the package to a new upstream version and
other changes.
Regards,
Milan
Any news? Unless you willing to backport libgit2 patches to use MbedTLS
(which appear to be ready upstream) soon, it would probably be better
to remove the julia package, which is now totally outdated. Julia 0.4.7
can only be confusing for users as the language has changed a lot since
then.
The upstream patch (that is compatible with older libcryptsetup as well so can
be applied globally) is here
https://pagure.io/volume_key/c/ecef526a51c5a276681472fd6df239570c9ce518?branch=master
Thanks,
Milan
On 01/24/2018 02:15 PM, Guilhem Moulin wrote:
> Currently blocking on #888072; if fixing that bug (or
> removing volume-key from testing) takes too long we'll make sure
> cryptsetup 2:2.0.0-1 doesn't migrate to testing by raising the severity
> of #888162.
This bug have patch in upstream
t;
instead of "--key-file -".
Thanks,
Milan
Package: ovirt-guest-agent
Version: 1.0.13.dfsg-2
Severity: wishlist
ovirt-guest-agent 1.0.12.2.dfsg-2 doesn't work with oVirt 4.2 due to
changed paths. It would be nice to make a backport of the new package
version for stretch so that users of stable don't have to install the
package from
Package: ovirt-guest-agent
Version: 1.0.13.dfsg-2
ovirt-guest-agent 1.0.12.2.dfsg-2 doesn't work with oVirt 4.2 due to
changed paths. But when one upgrades to 1.0.13.dfsg-2, the agent still
doesn't start and it's necessary to reboot the system or to trigger the
necessary changes manually:
Package: dfu-programmer
Version: 0.6.1-1
Severity: normal
Upstream version 0.7.2 of the dfu-programmer has been available for some time
already[0]. Could we please have this package up to date?
Milan
[0] https://sourceforge.net/projects/dfu-programmer/files/dfu-programmer/
Package: wnpp
Severity: wishlist
Owner: Milan Kupcevic <mi...@debian.org>
* Package name: simulide
Version : 0.1.5
Upstream Author : Santiago González <santig...@gmail.com>
* URL : https://sourceforge.net/projects/simulide/
* License : GPL-3
Prog
Package: wnpp
Severity: wishlist
Owner: Milan Kupcevic <mi...@debian.org>
* Package name: simutron
Version : 1.0.1
Upstream Author : Santiago González <santig...@gmail.com>
* URL : https://sourceforge.net/projects/simutron/
* License : GPL-3
Prog
retitle 568156 ITP: simavr - a lean and mean AVR simulator
owner 568156 !
thanks
New upstream URL:
https://github.com/buserror/simavr
too).
>
Because dpkg-buildpackage and debuild fully support the "-S" option.
Pdebuild used to do it fine, it fails now.
Milan
signature.asc
Description: OpenPGP digital signature
https://anonscm.debian.org/cgit/collab-maint/avrdude.git/commit/?id=777cf870879c9d14190dcce0fdd458283e48d5c2
Anton Gladky <gl...@debian.org> writes:
> If you are agree with this upload, I can reschedule it to day/0 and
> let it be built right now.
Yes, I agree.
Thanks,
Milan
Anton Gladky <gladky.an...@gmail.com> writes:
> I have prepared an NMU (versioned as 3.3.0-2.1) and
> uploaded to DELAYED/5.
Thank you very much for the NMU!
Regards,
Milan
On уто, 2017-02-14 at 23:38, Elimar Riesebieter wrote:
> * Milan P. Stanic <m...@arvanta.net> [2017-02-14 23:03 +0100]:
>
> [...] = 0
> > newfstatat(AT_FDCWD, "/home/mps/.popt", {st_mode=S_IFREG|0644, st_size=0
On уто, 2017-02-14 at 22:52, Elimar Riesebieter wrote:
> * Elimar Riesebieter <riese...@lxtec.de> [2017-02-14 22:27 +0100]:
>
> > * Milan P. Stanic <m...@arvanta.net> [2017-02-14 22:04 +0100]:
>
> > > mocp didn't created .moc file in $HOME, there i
On уто, 2017-02-14 at 22:27, Elimar Riesebieter wrote:
> * Milan P. Stanic <m...@arvanta.net> [2017-02-14 22:04 +0100]:
>
> > On уто, 2017-02-14 at 21:25, Elimar Riesebieter wrote:
> > > * Milan P. Stanic <m...@arvanta.net> [2017-02-14 21:10 +0100]:
> >
On уто, 2017-02-14 at 21:25, Elimar Riesebieter wrote:
> * Milan P. Stanic <m...@arvanta.net> [2017-02-14 21:10 +0100]:
>
> [...]
> > > In the past we have had a segfault caused by a defective mediafile.
> > > Did you tested moc loading only files which are know
On уто, 2017-02-14 at 20:21, Elimar Riesebieter wrote:
> * Milan P. Stanic <m...@arvanta.net> [2017-02-14 19:08 +0100]:
>
> [...]
> > > Anyway, could you please run "mocp -D" and provide the
> > > mocp_client_log and mocp_server_log in a compre
On уто, 2017-02-14 at 15:38, Elimar Riesebieter wrote:
> control: forwarded -1 mocma...@daper.net
>
> * Milan P. Stanic <m...@arvanta.net> [2017-02-14 12:57 +0100]:
>
> > Package: moc
> > Version: 1:2.6.0~svn-r2935-1
> > Severity: normal
> >
>
Package: moc
Version: 1:2.6.0~svn-r2935-1
Severity: normal
Dear Maintainer,
* What led up to the situation?
starting mocp from cli on aarch64, testing
* What exactly did you do (or not do) that was effective (or
ineffective)?
mocp
* What was the outcome of this
Package: systemd
Version: 232-15
Severity: normal
Dear Maintainer,
* What led up to the situation?
Installed Debian on the acer chromebook R13 (mediatek MT8173 SOC,
board called elm (oak)) armv8 with the kernel source from chromeos
site and built myself for that
I may confirm that this workflow helped:
$ apt-get source libpango1.0-0/testing
$ cd pango1.0-1.40.3
$ # solve the dependency on newer version of libthai
$ dpkg-buildpackage -b -uc -d # "-d" because of the dependency on debhelper>=10
$ sudo dpkg -i ~user/{libpango,gir}*.deb # needed BEFORE
Package: inkscape
Version: 0.92.0-3~bpo8+1
Severity: important
Dear Maintainer,
inkscape package in jessie backports, as every inkscape >=0.92, needs
libpango of version >=1.37.1 to render fonts correctly. However, the
package dependency says "libpango1.0-0 >=1.22" which is not correct.
Look at
without being asked to do
so and without any explanatory notice is not acceptable. Please either
fix the bug or make sure the package is not installed by default.
Thank you,
Milan
1 - 100 of 729 matches
Mail list logo
