Bug#1082240: ITP: meow -- Print ASCII cats to your terminal
Hi Andrea! This is a new terminal command, which is in the spirit of "cowsay" or "figlet". The name is deliberately short in order to be funny; renaming it to something longer like "ascii-meow" would go against the spirit of the command. There is no other software named meow, and there are no other such ITPs in the debian repositories. There is another Cargo/rust package named "meow"; however, this is an unmaintained piece of software and will likely not be packaged as a Debian package in the future. In addition, this software has been released under the package name "meow" in the Nixpkgs repository: https://search.nixos.org/packages?channel=unstable&show=meow For consistency, the package should be named the same across different package repositories. Hopefully this makes sense and is acceptable! Best, Sergey On Fri, 20 Sept 2024 at 14:44, Andrea Pappacoda wrote: > Hi Sergey, I find the package name "meow" a bit to general, especially for > a package with apparently no users. > > 1. Does other software called "meow" exist? > 2. Have you considered other names, like "ascii-meow"? > > Bye! > > Il 19 settembre 2024 15:30:29 CEST, PixelSergey < > sergey.ichtche...@gmail.com> ha scritto: > >Package: wnpp > >Severity: wishlist > >Owner: PixelSergey > >X-Debbugs-Cc: debian-de...@lists.debian.org, sergey.ichtche...@gmail.com > > > >* Package name: meow > > Version : 2.1.3 > > Upstream Contact: PixelSergey > >* URL : https://github.com/PixelSergey/meow > >* License : MIT > > Programming Lang: Rust > > Description : Print ASCII cats to your terminal > > > >This is a simple app to print ASCII cats directly to your terminal. > >Run `meow` for a single cat, `meow -c ` for more cats, > >or `meow -l` if you think that you are literally the cat that will be > printed. > > > >This package addresses the critical lack of cats in the Linux ecosystem. > >This package needs a sponsor. > > >
Bug#1076038: gnome-shell-extension-appindicator: There are many errors in journalctl with text: JS ERROR: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.UnknownProperty.
Package: gnome-shell-extension-appindicator Version: 46-1 Severity: normal X-Debbugs-Cc: lebfr@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I installed the gnome-shell-extension-appindicator. After that I execute Telegram. It's work fine, but I see many errors in journalctl. Jul 09 21:37:34 comma gnome-shell[1692]: JS ERROR: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.UnknownProperty: Property org.kde.StatusNotifierItem.IconAccessibleDesc was not found in object /StatusNotifierItem _promisify/proto[asyncFunc]/
Bug#1056351: dicod: wrong quotes in MediaWiki snippets in `/etc/dicod.conf`
That's an error in /etc/dicod.conf shipped with debian package. The dicod manual says clearly that: The default pp-setup file changes quote characters to â[ and â], and renames all m4 built-in macros so they all start with the prefix m4_. See https://www.gnu.org.ua/software/dico/manual/html_node/Preprocessor.html Regards, Sergey
Bug#613892: Bug#948151: git: Please consider demoting git-man to Recommends
Did anyone submit a patch to git to work well when no man pages are installed? Also please note that all man packages have a *-doc suffix, not the *-man. It probably can't be renamed now but just to note this to avoid in future. The git package itself also contains a lot of docs in the /usr/share/doc/git folder: It looks like some of them should be moved to a separate folder RelNotes: why would I need the release notes starting from v1.5.0 contrib: it contains some additional tools that not even related to a documentation and definitely should be extracted to a separate package README files: they are for git devs themselves In total all these files take 2.2 MB of disk space. If we can make the git smaller that would be great. Even now it's not that big to be included by default to desktop distributions to make it easier for students or new users to start programming.
Bug#1066025: dh_installsystemd doesn't process user services in /usr/lib/systemd/user/
Thank you, Neils,
> Ubuntu has patched debhelper
Sounds weird. I thought you guys had some communication with each other.
I changed the compact to 13 and indeed the scripts were generated and
included into the resulting package.
When changed to 14 scripts remains the same, no prerm script and nothing
about starting/stopping.
But when changed to 15 then the build failed:
dh_missing: warning: root/.ssh/sshtunnel.config.sh exists in debian/tmp but
is not installed to anywhere
dh_missing: error: missing files, aborting
The following debhelper tools have reported what they installed
(with files per package)
* dh_installdocs: sshtunnel (0)
The debuild created /debian/tmp/ folder and copied all files there.
Previously it copied files to /debian/sshtunnel
I pushed the compact 14 version to a separate branch:
https://github.com/yurt-page/sshtunnel/tree/1.3.x
I'll use the old compact level for now because I want to support old
releases.
I wish to send the ssh tunnel script to the OpenSSH client itself and am
not sure what to do: require the compact 14 or again add scripts manually.
Thank you for the quick response.
On Mon, Mar 25, 2024 at 7:25 PM Niels Thykier wrote:
> Sergey Ponomarev:
> > Hi Niels,
> >
> > I upgraded to Ubuntu 24.04 and now have debhelper 13.14.1ubuntu1.
>
>
> Hi,
>
> In case you are using Ubuntu, you should be filing the bug against
> Ubuntu for future reference. Notably, Ubuntu has patched debhelper and
> even monkey-patch(ed?) debhelper in their official builds on top that.
> Therefore, they have to screen incoming bug reports first to ensure the
> bug is not introduced by their patches.
>
> > Once executed the debuild nothing was generated.
> > When executed the dh_installsystemduser manually also nothing was
> generated.
> > From it's sources I found that it looks for some dependency and I added
> to
> > the /debian/control:
> >
> > Depends: ${misc:Depends}
> >
> > Now this helped and two install/uninstall scripts were generated
> > /debian/sshtunnel.postinst.debhelper
> > /debian/sshtunnel.postrm.debhelper
> >
> > I manually included the scripts to /debian/postinst and /debian/postrm
> and
> > built the deb.
>
>
> If you had to "manually" include those snippets into the deb in a clean
> build, then I think there is something seriously wrong with the
> packaging. Normally, `dh_installdeb` would do that for you if the
> commands are run in the correct sequence.
>
> Now, you mention you ran it manually. So it is possible you did that
> manually after building the deb, in which case you would see this
> behavior. This would also fit that your `debian/rules` likes quite
> standard without any room for mistakes of this kind when I checked it.
>
>
> > It was installed successfully but didn't start the service.
> > I started manually. During uninstall it has not been stopped. There is no
> > prerm script that will do that.
> >
>
> No, this feature is first added in compat 14 apparently (which is not
> stable yet). Sadly, this is not documented in the upgrade checklist for
> reasons I do not understand. The commit that introduced the feature
> recorded it in the wrong place and the remark seems to be completely gone.
>
> I will follow up on this part.
>
> > So the issues are:
> > 1. The debhelper did not execute the dh_installsystemduser. I guess I
> must
> > add it manually to /debian/rules
>
> Either that or you could use the proper debhelper-compat level. That is
> compat 12 or later would do. The package you linked to used compat 11 as
> I recall.
>
> Remember to check the debhelper compat upgrade checklist before you
> update the compat level.
>
> It is in `man 7 debhelper-compat-upgrade-checklist` or `man 7 debhelper`
> (depending on the debhelper version).
>
> > 2. The generated scripts do not start the service after installation.
> > 3. Missing prerm script to stop the service.
>
> As mentioned above, this is compat 14 stuff.
>
> > 4. Surprising need for for ${misc:Depends}
> >
>
> There is no such need in the Debian version of debhelper for
> dh_installsystemduser to generate the snippets. However,
> dh_installsystemduser must either install the services files *or* be run
> after they are installed at the correct location.
>My best guess is that you ran dh_installsystemduser to "early" the
> first time, then the files were in place, followed by you tweaking
> debian/control and then running dh_installsystemduser without clean
> first. That is basically the one way I can make sense of what happened.
>
> That said, you ought have that dependency anyway for other reasons (at
Bug#1066025: dh_installsystemd doesn't process user services in /usr/lib/systemd/user/
Hi Niels,
I upgraded to Ubuntu 24.04 and now have debhelper 13.14.1ubuntu1.
Once executed the debuild nothing was generated.
When executed the dh_installsystemduser manually also nothing was generated.
>From it's sources I found that it looks for some dependency and I added to
the /debian/control:
Depends: ${misc:Depends}
Now this helped and two install/uninstall scripts were generated
/debian/sshtunnel.postinst.debhelper
/debian/sshtunnel.postrm.debhelper
I manually included the scripts to /debian/postinst and /debian/postrm and
built the deb.
It was installed successfully but didn't start the service.
I started manually. During uninstall it has not been stopped. There is no
prerm script that will do that.
So the issues are:
1. The debhelper did not execute the dh_installsystemduser. I guess I must
add it manually to /debian/rules
2. The generated scripts do not start the service after installation.
3. Missing prerm script to stop the service.
4. Surprising need for for ${misc:Depends}
So far I will anyway continue to use the manual scripts because I wish to
support old distros.
Anyway I wanted to have good and proper "official" scripts to install the
user service.
You can play with my simple package here:
http://github.com/yurt-page/sshtunnel
It can be a good sample and test ground.
Best regards and thank you for your work,
Sergey
On Sat, Mar 16, 2024 at 7:50 PM Niels Thykier wrote:
> Control: tags -1 moreinfo
>
> Niels Thykier:
> > Sergey Ponomarev:
> >> debhelper package version: 13.11.6ubuntu1
> >> Ubuntu 23.10 Mantic
> >>
> >> Is there any plan for support of user services?
> >> The user service is complicated by itself because it differs by commands
> >> from system services.
> >> That's why I also asked to make a review of mine scripts to have at
> least
> >> one right example of this.
> >>
> >>
> >> [...]
> >
> > User services are handled by `dh_installsystemduser` (not
> > `dh_installsystemd`) and that command used `/usr/lib` since the
> > beginning as far as I can tell. That command was added in 10.9.1 and
> > should be in the default sequence.
> >
> > Best regards,
> > Niels
> >
> >
>
> Hi Sergey,
>
> I hope the above solved your issues. If so, I will close this bug as
> resolved. :)
>
> Best regards,
> Niels
>
>
Bug#1066025: dh_installsystemd doesn't process user services in /usr/lib/systemd/user/
debhelper package version: 13.11.6ubuntu1 Ubuntu 23.10 Mantic Is there any plan for support of user services? The user service is complicated by itself because it differs by commands from system services. That's why I also asked to make a review of mine scripts to have at least one right example of this. On Mon, Mar 11, 2024 at 10:48 AM Niels Thykier wrote: > Sergey Ponomarev: > > Package: dh-systemd > > > > I created a systemd service to establish SSH connections. > > At beginning I installed the service file > > into /usr/lib/systemd/system/sshtunnel > > So the dh_systemd generated post install and post remove scripts to call > > sysctl daemon-reload. > > I copied them, made a small cleanup and included manually: > > > https://github.com/yurt-page/sshtunnel/commit/1b8f5f4a495802270b894ccf7f047aadab8772ac > > > > Then I wanted to make the tunnel starting from a user and moved the > service > > file into /usr/lib/systemd/user/sshtunnel > > > > But the dh_installsystemd didn't anything about the service file and I > had > > to create manually the install scripts: > > https://github.com/yurt-page/sshtunnel/blob/master/debian/postinst > > https://github.com/yurt-page/sshtunnel/blob/master/debian/prerm > > https://github.com/yurt-page/sshtunnel/blob/master/debian/postrm > > > > So could you please review the scripts and their generation to the > > dh_installsystemd? > > > > Here is a man page for the dh_installsystemd > > > https://manpages.debian.org/testing/debhelper/dh_installsystemd.1.en.html > > > > Hi, > > Which version of debhelper are you using? Support for /usr is only in > unstable/testing. I would recommend adding a Build-Depends on `debhelper > (>=13.11.9~) to ensure you have all the `/usr-merge` related feature > support. In the concrete case, 13.11.8~ might be sufficient (and > happens to be available in stable-backports) > > Best regards, > Niels > >
Bug#1066025: dh_installsystemd doesn't process user services in /usr/lib/systemd/user/
Package: dh-systemd I created a systemd service to establish SSH connections. At beginning I installed the service file into /usr/lib/systemd/system/sshtunnel So the dh_systemd generated post install and post remove scripts to call sysctl daemon-reload. I copied them, made a small cleanup and included manually: https://github.com/yurt-page/sshtunnel/commit/1b8f5f4a495802270b894ccf7f047aadab8772ac Then I wanted to make the tunnel starting from a user and moved the service file into /usr/lib/systemd/user/sshtunnel But the dh_installsystemd didn't anything about the service file and I had to create manually the install scripts: https://github.com/yurt-page/sshtunnel/blob/master/debian/postinst https://github.com/yurt-page/sshtunnel/blob/master/debian/prerm https://github.com/yurt-page/sshtunnel/blob/master/debian/postrm So could you please review the scripts and their generation to the dh_installsystemd? Here is a man page for the dh_installsystemd https://manpages.debian.org/testing/debhelper/dh_installsystemd.1.en.html
Bug#1040456: linux-image-6.1.0-10-amd64: system hang-up after screen is blank
Hello. The problem is solved in the kernel version 6.1.52-1. The package linux-image-6.1.0-12-amd64 works stable. Thanks.
Bug#1010873: RFP: emailrelay -- SMTP email proxy and relay server
Please take a look at the EmailRelay again http://emailrelay.sourceforge.net/. With latest version 2.5 it can act as a full MTA and deliver mail directly. This makes it a great alternative to Postfix. But unlike Postfix it supports Windows and is small and easier to configure. This makes it extremely valuable especially as a good option for self-hosting. I created an Ubuntu PPA https://code.launchpad.net/~stokito/+archive/ubuntu/emailrelay It builds debs for amd64 and also for arm64 and Raspberry Pi (armhf). The build works great without any problems.
Bug#1006223: "stack smashing detected" error in ld while linking with Map-file specified
Looks like the upstream fix for this issue is https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=1273da0414a2f2a31288749a17fe44cbef615ab5 (it also fixes another problematic place with similar code). Also the bug cannot be reproduced in locales like en_US.UTF-8 and appears only when some longer translations are used (e.g., in the ru_RU.UTF-8 locale). -- Sergey Vlasov
Bug#1032027: linux: i_reserved_data_blocks (2) not cleared
Source: linux Severity: normal X-Debbugs-Cc: sergey.aleynikov+...@gmail.com Dear Maintainer, I have the following disk configuration: sda 8:00 14.6T 0 disk └─disk6254:00 14.6T 0 crypt └─disk6-part1254:10 14.6T 0 part └─md09:00 58.2T 0 raid6 ├─md0p1 259:70 128G 0 part / └─md0p2 259:80 58.1T 0 part sdb 8:16 0 14.6T 0 disk └─disk2254:80 14.6T 0 crypt └─disk2-part1254:90 14.6T 0 part └─md09:00 58.2T 0 raid6 ├─md0p1 259:70 128G 0 part / └─md0p2 259:80 58.1T 0 part sdc 8:32 0 14.6T 0 disk └─disk3254:60 14.6T 0 crypt └─disk3-part1254:70 14.6T 0 part └─md09:00 58.2T 0 raid6 ├─md0p1 259:70 128G 0 part / └─md0p2 259:80 58.1T 0 part sdd 8:48 0 14.6T 0 disk └─disk1254:10 0 14.6T 0 crypt └─disk1-part1254:11 0 14.6T 0 part └─md09:00 58.2T 0 raid6 ├─md0p1 259:70 128G 0 part / └─md0p2 259:80 58.1T 0 part sde 8:64 0 14.6T 0 disk └─disk4254:40 14.6T 0 crypt └─disk4-part1254:50 14.6T 0 part └─md09:00 58.2T 0 raid6 ├─md0p1 259:70 128G 0 part / └─md0p2 259:80 58.1T 0 part sdf 8:80 0 14.6T 0 disk └─disk5254:20 14.6T 0 crypt └─disk5-part1254:30 14.6T 0 part └─md09:00 58.2T 0 raid6 ├─md0p1 259:70 128G 0 part / └─md0p2 259:80 58.1T 0 part Device md0 is constructed on top of 6x cryptsetup disks as following: md0 : active raid6 dm-11[6] dm-9[4] dm-7[3] dm-5[2] dm-3[7] dm-1[0] 62499463424 blocks super 1.2 level 6, 64k chunk, algorithm 2 [6/6] [UU] Root filesystem is mounted from md0p1 with the following options: UUID=bff1f017-bca2-4acc-9b97-170474c5e198 / ext4 noatime,nodelalloc,barrier=1,data=ordered 0 1 I've recently observed the following error in dmesg: [163925.493694] EXT4-fs (md0p1): Inode 6562253 (b30df460): i_reserved_data_blocks (2) not cleared! It haven't repeated since. Messages preceeding it are from kvm, like this one: [163814.292207] kvm [31458]: ignored rdmsr: 0x1a2 data 0x0 Does this mean a filesystem corruption? Do I need to take any additional steps (like force fsck), or would it recover silently? -- System Information: Debian Release: 11.6 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-21-amd64 (SMP w/56 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#930641: closed by Debian FTP Masters (Bug#1023560: Removed package(s) from unstable)
On Sun, Nov 06, 2022 at 10:12:34PM +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the guile-2.2-doc package: > > #930641: r5rs.info missing > > It has been closed by Debian FTP Masters . > > Their explanation is attached below along with your original report. > as the package guile-2.2 has just been removed from the Debian archive > unstable we hereby close the associated bug reports. We are sorry > that we couldn't deal with your issue properly. Wow. Brave New Worl^WDebian. Who cares that the issue is valid for guile-3.0 as well?
Bug#790943: Root and local certificate location clash
You made a very good investigation on the topic. I agree that a public cert shouldn't be placed into the same folder as CA certs. There is some mention of a weird bug https://serverfault.com/a/840191/442430 Instead I think that both private key and cert should be merged into a one file and placed into /etc/ssl/private/. It looks like there were a lot of discussions but we didn't come to a single agreement about the place to store certs and how to manage them. Please read my proposition here https://github.com/certbot/certbot/issues/1425#issuecomment-1150116062 I'll appreciate any feedback. Regards, Sergey Ponomarev, stokito.com
Bug#1010874: ITP: jshn -- JSON parsing and generation library in for shell scripts
Package: wnpp Severity: wishlist * Package name: jshn Version : 1.0.0 * URL : https://openwrt.org/docs/guide-developer/jshn * License : ISC Programming Lang: C, Shell Description : jshn (JSON SHell Notation), a shell library and utility for parsing and generating JSON. OpenWrt actively uses shell scripts and JSON for configs and API. But shell scripts don't have built-in functions to work with JSON or other hierarchical structures so provide a shell library jshn.sh that you can import and use. The tool is very handy and useful and I see that Debian lacks it out of the box. In fact it can replace jq and many /sed/ magic in many places. I already created a fork that you can try yourself https://github.com/stokito/jshn-jsonc But I'm going to talk with OpenWrt devs to split the tool from the libubox package and make compilation easy for Debian. Regards, Sergey Ponomarev -- Sergey Ponomarev, stokito.com
Bug#1010873: [RFP]: emailrelay -- SMTP email proxy and relay server
Package: wnpp Severity: wishlist * Package name: emailrelay Version : 2.3.0 * URL : http://emailrelay.sourceforge.net/ * License : GPL-3.0 Programming Lang: C Description : E-MailRelay does three things: it stores any incoming email messages that it receives, it forwards email messages on to another remote email server, and it serves up stored email messages to local email reader programs. More technically, it acts as a SMTP storage daemon, a SMTP forwarding agent, and a POP3 server. OpenWrt has the package and it's used quite often. But also this is an ideal solution for small office or home usage and especially for Freedombox. It takes about 1.4mb which is at least twice smaller than Postfix. But more importantly it has a clear config and makes its usage more secure especially for experienced users. The program is very old, well tested, safe, stable and actively maintained. It is even already debianized, we just need to put it into repo. This is a very important thing to make users more independant. Regards, Sergey Ponomarev
Bug#1008232: RFP: soapui -- API and web service testing tool
As a Java developer I can tell that many of us used SoapUI a lot in times when WebServices and WSDL was a de-facto standard for APIs. Today Postman is mostly used for REST APIs but the SoapUI is still powerful and even recently received a GraphQL support. It's one of the main tools for QA automation. Similar to JMeter that was already debianized. I tried it now and the design remains the same :) But I hope they'll improve it. It has quite annoying popups with ads to upgrade to a paid Pro plan and ReadyAPI tool. I think it worth adding. But not a top priority. Regards, Sergey Ponomarev
Bug#1009693: keepassxc: data loss when adding subgroups from 2 PC to the shared file
Package: keepassxc Version: 2.6.2+dfsg.1-1 Severity: normal Steps to reproduce: 1. Put password file on samba shared folder. 2. 2 users open the file, choose a group and start adding 10 subgroups to that group simulteneously, also adding 1 password entry in each subgroup >From time to time users are asked to merge the file - that is expected. But at the end I get 3 added subgroups lost! We also performed same test with keepassxc 2.7.1 appimage. Bug is there too! -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-0.bpo.2-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages keepassxc depends on: ii libargon2-10~20171227-0.2 ii libc6 2.31-13+deb11u3 ii libgcrypt201.8.7-6 ii libqrencode4 4.1.1-1 ii libqt5concurrent5 5.15.2+dfsg-9 ii libqt5core5a 5.15.2+dfsg-9 ii libqt5dbus55.15.2+dfsg-9 ii libqt5gui5 5.15.2+dfsg-9 ii libqt5network5 5.15.2+dfsg-9 ii libqt5svg5 5.15.2-3 ii libqt5widgets5 5.15.2+dfsg-9 ii libqt5x11extras5 5.15.2-2 ii libsodium231.0.18-1 ii libstdc++6 10.2.1-6 ii libx11-6 2:1.7.2-1 ii libxi6 2:1.7.10-1 ii libxtst6 2:1.2.3-1 ii libykpers-1-1 1.20.0-3 ii libzxcvbn0 2.4+dfsg-2 ii zlib1g 1:1.2.11.dfsg-2+deb11u1 Versions of packages keepassxc recommends: ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1 Versions of packages keepassxc suggests: pn webext-keepassxc-browser pn xclip -- no debconf information
Bug#1009633: keepassxc: segfault with synced group
Package: keepassxc Version: 2.6.2+dfsg.1-1 Severity: normal got segfault when open a file in a shared folder from 2 hosts at the same time with synced group on the same shared folder that is probably bad idea, but it should not segfault $ keepassxc QObject::startTimer: Timers cannot be started from another thread Synchronize /shared/staff/TS/keepass2/synced.kdbx test group with test group Merge test/test with local on top/under test group QObject::startTimer: Timers cannot be started from another thread QObject::startTimer: Timers cannot be started from another thread Synchronize /shared/staff/TS/keepass2/synced.kdbx test group with test group Merge test/test with local on top/under test group Merge testss/testss with local on top/under test group Segmentation fault -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-0.bpo.2-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages keepassxc depends on: ii libargon2-10~20171227-0.2 ii libc6 2.31-13+deb11u3 ii libgcrypt201.8.7-6 ii libqrencode4 4.1.1-1 ii libqt5concurrent5 5.15.2+dfsg-9 ii libqt5core5a 5.15.2+dfsg-9 ii libqt5dbus55.15.2+dfsg-9 ii libqt5gui5 5.15.2+dfsg-9 ii libqt5network5 5.15.2+dfsg-9 ii libqt5svg5 5.15.2-3 ii libqt5widgets5 5.15.2+dfsg-9 ii libqt5x11extras5 5.15.2-2 ii libsodium231.0.18-1 ii libstdc++6 10.2.1-6 ii libx11-6 2:1.7.2-1 ii libxi6 2:1.7.10-1 ii libxtst6 2:1.2.3-1 ii libykpers-1-1 1.20.0-3 ii libzxcvbn0 2.4+dfsg-2 ii zlib1g 1:1.2.11.dfsg-2+deb11u1 Versions of packages keepassxc recommends: ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1 Versions of packages keepassxc suggests: pn webext-keepassxc-browser pn xclip -- no debconf information
Bug#1006414: reportbug: systemd-networkd does not read DHCPV4 config section
Package: systemd Version: 250.3-2 Severity: normal X-Debbugs-Cc: seregaxvm.m...@gmail.com Dear Maintainer, systemd-networkd does not read settings from the [DHCPV4] secrion of the config file, as it should according to the man page. Instead it reads the [DHCP] secion. -- Package-specific info: -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable- updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (100, 'testing'), (50, 'unstable'), (10, 'experimental'), (1, 'experimental- debug') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-1-amd64 (SMP w/32 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.3.1-1 ii libapparmor1 3.0.4-1 ii libaudit11:3.0.7-1 ii libblkid12.37.3-1+b1 ii libc62.33-7 ii libcap2 1:2.44-1 ii libcrypt11:4.4.27-1.1 ii libcryptsetup12 2:2.4.3-1 ii libfdisk12.37.3-1+b1 ii libgcrypt20 1.9.4-5 ii libgnutls30 3.7.3-4+b1 ii libgpg-error01.43-3 ii libip4tc21.8.7-1 ii libkmod2 29-1 ii liblz4-1 1.9.3-2 ii liblzma5 5.2.5-2 ii libmount12.37.3-1+b1 ii libpam0g 1.4.0-11 ii libseccomp2 2.5.3-2 ii libselinux1 3.3-1+b1 ii libsystemd0 250.3-2 ii libzstd1 1.4.8+dfsg-3 ii mount2.37.3-1+b1 ii util-linux 2.37.3-1+b1 Versions of packages systemd recommends: ii dbus [default-dbus-system-bus] 1.12.20-4 ii systemd-timesyncd [time-daemon] 250.3-2 Versions of packages systemd suggests: ii libfido2-11.10.0-1 pn libtss2-esys-3.0.2-0 pn libtss2-mu0 pn libtss2-rc0 ii policykit-1 0.105-32 ii systemd-container 250.3-2 Versions of packages systemd is related to: ii dbus-user-session 1.12.20-4 pn dracut ii initramfs-tools0.140 ii libnss-systemd 250.3-2 ii libpam-systemd 250.3-2 ii udev 250.3-2
Bug#1004332: cntlm: rotate cntlm logs
Package: cntlm
Version: 0.92.3-1+b1
Severity: normal
Tags: patch
X-Debbugs-Cc: seregaxvm.m...@gmail.com
Dear Maintainer,
Cntlm is vary chatty and produces large amount of logs. In my case it filled
250Gb SSD in a week. It would be nice to provide rsyslog and logrotate
configurations with this package so that could be managed with ease.
For this I used the following configurations:
In /etc/rsyslog.d/cntlm.conf
```
if $programname == 'cntlm' then {
/var/log/cntlm.log
~
}
```
and in /etc/logrotate.d/cntlm
```
/var/log/cntlm.log
{
rotate 2
daily
maxsize 100M
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}
```
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (900, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'stable'), (50, 'unstable'), (10, 'experimental'), (1,
'experimental-debug')
Architecture: amd64 (x86_64)
Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cntlm depends on:
ii adduser 3.118
ii libc62.33-2
cntlm recommends no packages.
cntlm suggests no packages.
-- Configuration Files:
/etc/cntlm.conf [Errno 13] Permission denied: '/etc/cntlm.conf'
-- no debconf information
if $programname == 'cntlm' then {
/var/log/cntlm.log
~
}
/var/log/cntlm.log
{
rotate 2
daily
maxsize 100M
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}
Bug#999659: perdition: failed to install, failed to uninstall (error in initscript)
Package: perdition Version: 2.2-3.1+b1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: s...@s73.work Dear Maintainer, The error happens only on first install of the perdition, see instructions below on how to reproduce it. First I get an error during # apt install perdition Failed to stop perdition.service: Unit perdition.service not loaded. invoke-rc.d: initscript perdition, action "stop" failed. That happens only if there was no perdition package installed before. If you had perdition package installed and deleted later then error is not happening, since the command "apt purge" does not delete one generated file. So, to reproduce, either take host where perdition was never installed (apt purge alone will not help here!), or # apt purge perdition then delete generated file: # rm /run/systemd/generator.late/perdition.service Now "apt install" will fail. After installation fails, you will also not be able to delete the package: # apt purge perdition ... Failed to stop perdition.service: Unit perdition.service not loaded. invoke-rc.d: initscript perdition, action "stop" failed. dpkg: error processing package perdition (--remove): installed perdition package pre-removal script subprocess returned error exit status 5 dpkg: too many errors, stopping Here fix is easy, just edit /var/lib/dpkg/info/perdition.prerm and replace the line invoke-rc.d perdition stop with invoke-rc.d perdition stop || true Something similar must be done for the preinstall script in order to fix the install error. Here is full apt install output: # LANG=C apt install perdition Reading package lists... Done Building dependency tree... Done Reading state information... Done perdition is already the newest version (2.2-3.1+b1). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] Setting up perdition (2.2-3.1+b1) ... Failed to stop perdition.service: Unit perdition.service not loaded. invoke-rc.d: initscript perdition, action "stop" failed. dpkg: error processing package perdition (--configure): installed perdition package post-installation script subprocess returned error exit status 5 Processing triggers for libc-bin (2.31-13+deb11u2) ... Errors were encountered while processing: perdition needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) Here is full apt purge output: # LANG=C apt purge perdition Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages will be REMOVED: perdition* 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. 1 not fully installed or removed. After this operation, 468 kB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 19109 files and directories currently installed.) Removing perdition (2.2-3.1+b1) ... Failed to stop perdition.service: Unit perdition.service not loaded. invoke-rc.d: initscript perdition, action "stop" failed. dpkg: error processing package perdition (--remove): installed perdition package pre-removal script subprocess returned error exit status 5 dpkg: too many errors, stopping Errors were encountered while processing: perdition Processing was halted because there were too many errors. needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: 11.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU:ru Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages perdition depends on: ii libc6 2.31-13+deb11u2 ii libdb5.35.3.28+dfsg1-0.8 ii libgdbm61.19-2 pn libidn11 ii libnsl2 1.3.0-2 ii libpam0g1.4.0-9+deb11u1 pn libpopt0 ii libssl1.1 1.1.1k-1+deb11u1 pn libvanessa-adt1 pn libvanessa-logger0 pn libvanessa-socket2 ii lsb-base11.1.0 perdition recommends no packages. Versions of packages perdition suggests: pn perdition-ldap pn perdition-mysql pn perdition-odbc pn perdition-postgresql -- no debconf information
Bug#992430: schroot: user password does not match
Hi Roger, I compared `/etc/shadow` and `/etc/passwd` across my host and from inside the testable chroot environments, no difference, I also checked `/etc/pam.d/common-password` and it looks that bullseye uses `yescrypt` for hashing while buster uses `sha512`. It also says in `/etc/pam.d/common-password`: > if a shadow password hash will be shared between Debian 11 and older releases replace "yescrypt" with "sha512" for compatibility. My buster chroot already has "sha512" set. I tried to set "yescrypt" there but sudo still complains about the wrong password. Regards, Sergey On Wed, Aug 18, 2021 at 4:58 PM Roger Leigh wrote: > Hi, > > I'm not personally familiar with the changes in the latest Debian release, > but please check that all the password, shadow password files etc. are all > copied into the chroot and are self-consistent with one another. Are the > host files using a hash type not supported by the chroot environment? > > Regards, > Roger > > On 18/08/2021, 14:54, "Sergey Vlasov" wrote: > > Package: schroot > Version: 1.6.10-12 > Severity: important > X-Debbugs-Cc: ser...@vlasov.me > > Dear Maintainer, > > When doing schroot into a buster chroot environment, sudo > commands fail due to password not matching the current user password. > There is no such problem for bullseye chroot environment. > > > >
Bug#992430: schroot: user password does not match
Package: schroot Version: 1.6.10-12 Severity: important X-Debbugs-Cc: ser...@vlasov.me Dear Maintainer, When doing schroot into a buster chroot environment, sudo commands fail due to password not matching the current user password. There is no such problem for bullseye chroot environment. To reproduce: 0. make sure your current user belongs to sudo group 1. create buster chroot environment: $ sudo debootstrap buster /schroot-bug/buster 2. create schroot configuration file: $ cat << EOF | sudo tee /etc/schroot/chroot.d/buster [buster] type=directory directory=/schroot-bug/buster users=$USER profile=desktop personality=linux preserve-environment=false EOF 3. enter chroot: $ schroot -c buster 4. test sudo with your current password: $ sudo true [sudo] password for : Sorry, try again. [sudo] password for : Sorry, try again. [sudo] password for : sudo: 3 incorrect password attempts 5. repeat steps 1-4 but replace `buster` with `bullseye`. `sudo true` command accepts the current user password. -- System Information: Debian Release: 11.0 APT prefers stable APT policy: (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages schroot depends on: ii libboost-filesystem1.74.0 1.74.0-9 ii libboost-iostreams1.74.01.74.0-9 ii libboost-program-options1.74.0 1.74.0-9 ii libc6 2.31-13 ii libgcc-s1 10.2.1-6 ii libpam0g1.4.0-9 ii libstdc++6 10.2.1-6 ii libuuid12.36.1-8 ii lsb-base11.1.0 ii schroot-common 1.6.10-12 schroot recommends no packages. Versions of packages schroot suggests: pn aufs-tools | unionfs-fuse pn btrfs-progs ii debootstrap1.0.123 ii lvm2 2.03.11-2.1 pn qemu-user-static pn zfsutils-linux -- no debconf information
Bug#991917: python3-wikitrans: Wiki 2 html conversion errors
Hi Erich, Thanks for your report. > 1. This upstream patch should be included in the package: > > https://git.gnu.org.ua/wikitrans.git/commit/?id=c785e3ad767b12a13ae75a3513ec88a4d1144210 Sure. It will be included when new version is released. > 2. A wrong variable name is used here: > File "/usr/lib/python3/dist-packages/wikitrans/wikimarkup.py", line 662, in > parse_ref > list.append(self.parse_tag(tok)) > TypeError: descriptor 'append' for 'list' objects doesn't apply to a > 'HtmlTagNode' object That's definitely a copy-paste error. I've pushed the following patch https://git.gnu.org.ua/wikitrans.git/commit/?id=90a9ed7108e45fa8c2d0300e1308a99171240255 > 3. WikiDelimNodes (generated by wikimarkup: ''Example'') cause raw > JSON to be > inserted in the HTML: Can you give more detail, please? Regards, Sergey
Bug#991756: linux-image-5.10.0-8-amd64: alsa regression: HDMI output does not work anymore
Package: src:linux Version: 5.10.46-3 Severity: normal X-Debbugs-Cc: s...@s73.work Dear Maintainer, After upgrade from linux kernel linux-image-4.19.0-16-amd64 to linux-image-5.10.0-8-amd64 HDMI sound does not work anymore. That is HP EliteDesk 800 G1 desktop. I also tried # cat /etc/modprobe.d/alsa.conf options snd-intel-dspcfg dsp_driver=1 that makes sound working, but not stable, sometimes it jumps, sometimes produces clicks and sometimes disappears, video in youtube or VLC does not behave stable too. Downgrading kernel linux-image-4.19.0-16-amd64 solves the problem. Quick googling shows that I am not alone, but know solution exists. Output of alsainfo script follows -- Package-specific info: ** Version: Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.46-3 (2021-07-28) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 root=UUID=8401bdfb-7c29-4f78-bc52-fb11e109580e ro quiet ** Not tainted ** Kernel log: [2.850558] systemd[1]: Finished Create list of static device nodes for the current kernel. [2.850765] systemd[1]: modprobe@configfs.service: Succeeded. [2.850896] systemd[1]: Finished Load Kernel Module configfs. [2.851055] systemd[1]: modprobe@drm.service: Succeeded. [2.851187] systemd[1]: Finished Load Kernel Module drm. [2.851858] systemd[1]: Mounting Kernel Configuration File System... [2.857526] fuse: init (API version 7.32) [2.864967] systemd[1]: modprobe@fuse.service: Succeeded. [2.865136] systemd[1]: Finished Load Kernel Module fuse. [2.865982] systemd[1]: Mounting FUSE Control File System... [2.868942] lp: driver loaded but no devices found [2.871223] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro [2.872561] systemd[1]: Finished Remount Root and Kernel File Systems. [2.872701] systemd[1]: Mounted Kernel Configuration File System. [2.872785] systemd[1]: Mounted FUSE Control File System. [2.872965] ppdev: user-space parallel port driver [2.873755] systemd[1]: Condition check resulted in Rebuild Hardware Database being skipped. [2.873788] systemd[1]: Condition check resulted in Platform Persistent Storage Archival being skipped. [2.874323] systemd[1]: Starting Load/Save Random Seed... [2.874877] systemd[1]: Starting Create System Users... [2.878626] systemd[1]: Finished Load Kernel Modules. [2.879244] systemd[1]: Starting Apply Kernel Variables... [2.889290] RPC: Registered named UNIX socket transport module. [2.889292] RPC: Registered udp transport module. [2.889292] RPC: Registered tcp transport module. [2.889293] RPC: Registered tcp NFSv4.1 backchannel transport module. [2.890443] systemd[1]: Mounted RPC Pipe File System. [2.891033] systemd[1]: Starting pNFS block layout mapping daemon... [2.903567] systemd[1]: Started Journal Service. [2.918507] systemd-journald[249]: Received client request to flush runtime journal. [2.947414] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [3.246563] pstore: Using crash dump compression: deflate [3.246574] pstore: Registered efi as persistent store backend [3.248365] input: HP WMI hotkeys as /devices/virtual/input/input22 [3.305818] input: PC Speaker as /devices/platform/pcspkr/input/input23 [3.306316] at24 0-0050: supply vcc not found, using dummy regulator [3.307361] at24 0-0050: 256 byte spd EEPROM, read-only [3.307375] at24 0-0051: supply vcc not found, using dummy regulator [3.307897] at24 0-0051: 256 byte spd EEPROM, read-only [3.307910] at24 0-0052: supply vcc not found, using dummy regulator [3.308240] sd 0:0:0:0: Attached scsi generic sg0 type 0 [3.308426] at24 0-0052: 256 byte spd EEPROM, read-only [3.308437] at24 0-0053: supply vcc not found, using dummy regulator [3.309063] iTCO_vendor_support: vendor-support=0 [3.309132] at24 0-0053: 256 byte spd EEPROM, read-only [3.315639] tpm_tis 00:08: 1.2 TPM (device-id 0xB, rev-id 16) [3.341226] tpm tpm0: TPM is disabled/deactivated (0x7) [3.345834] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [3.345873] iTCO_wdt: Found a Lynx Point TCO device (Version=2, TCOBASE=0x0460) [3.346445] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [3.375485] mc: Linux media interface: v0.10 [3.375770] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters, 655360 ms ovfl timer [3.375772] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules [3.375772] RAPL PMU: hw unit of domain package 2^-14 Joules [3.375773] RAPL PMU: hw unit of domain dram 2^-14 Joules [3.375773] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules [3.404453] cryptd: max_cpu_qlen set to 1000 [3.449186] Adding 4081660k swap on /dev/sda3. Priority:-2 extents:1 across:4081660k SSFS [3.449337] usbcore: registered new interface driver snd-usb-audio [3.489649] AVX2 vers
Bug#991255: libqt5widgets5: Icon does not change anymore on checkable QPushButton
Package: libqt5widgets5 Version: 5.15.2+dfsg-9 Severity: normal Dear Maintainer, The current version of Qt (5.15.2) contains a known bug, due to which the changing of icons on checkable QPushButton does not work. This bug is fixed in Qt 6.1, but the patch is not included in the public branch of Qt 5.15. Is it possible to include this patch in the Debian? Links: https://bugreports.qt.io/browse/QTBUG-82110 https://bugreports.qt.io/browse/QTBUG-86736 The patch: https://codereview.qt-project.org/c/qt/qtbase/+/327734 -- System Information: Debian Release: 11.0 APT prefers stable APT policy: (900, 'stable'), (70, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8), LANGUAGE=ru_RU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libqt5widgets5 depends on: ii libc6 2.31-12 ii libgcc-s1 10.2.1-6 ii libqt5core5a [qtbase-abi-5-15-2] 5.15.2+dfsg-9 ii libqt5gui55.15.2+dfsg-9 ii libstdc++610.2.1-6 libqt5widgets5 recommends no packages. libqt5widgets5 suggests no packages. -- no debconf information
Bug#986737: RFS: deno/1.8.3-1 [ITP] -- A secure JavaScript and TypeScript runtime
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "deno": * Package name: deno Version : 1.8.3-1 Upstream Author : The Deno Authors * URL : https://deno.land * License : MIT Section : devel It builds those binary packages: deno - A secure JavaScript and TypeScript runtime To access further information about this package, please visit the following URL: https://mentors.debian.net/package/deno/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/deno/deno_1.8.3-1.dsc Changes for the initial release: deno (1.8.3-1) unstable; urgency=medium . * Initial release (Closes: 961337) Regards, -- Sergey Abroskin
Bug#986659: ITP: deno -- A secure runtime for JavaScript and TypeScript
Package: wnpp Severity: wishlist Owner: Sergey Abroskin * Package name: deno Version : 1.8.3 Upstream Author : The Deno authors * URL : https://deno.land * License : MIT Programming Lang: Rust Description : A secure runtime for JavaScript and TypeScript Deno is a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust. - Secure by default. No file, network, or environment access, unless explicitly enabled. - Supports TypeScript out of the box. - Ships only a single executable file. - Has built-in utilities like a dependency inspector (deno info) and a code formatter (deno fmt). - Has a set of reviewed (audited) standard modules that are guaranteed to work with Deno: deno.land/std I'm using Deno everyday and I think i'm ready to maintain it.
Bug#843118: RE: seabios: Unable to boot KVM guest with "-display none"
I've re-checked that with "-vga none" seabios@rel-1.14.0 the specific VM doesn't boot and still doesn't on master. And it boots with an old seabios@e38be2d (though compiling it now requires some effort). PS: both host & guest are now debian 10, qemu version is 4.2. Best regards, Sergey Aleynikov ср, 30 дек. 2020 г. в 12:08, Michael Tokarev : > > On Sat, 3 Feb 2018 02:45:18 +0300 Sergey Aleynikov > wrote: > > Hi Michael, > > > > I've also stumbled upon this issue. My host is Debian 9, guest is > > Debian 6. This issue happens with any Qemu version from 2.4 up to 2.11 > > - faulty Seabios doesn't work on any of them, good Seabios works on > > all of them. Guest kernel isn't even loaded - qemu gets stuck at 100% > > cpu. My command line to start VM is the following: > > ( https://bugs.debian.org/843118 ) > > Hi Sergey! > > I just stumbled upon an old and neglected bugreport where you already did > all the good work. Unfortunately it received almost no love and only after > 3 year I come across it again.. > > Can you check whenever this bug is still relevant with current version of > seabios, please? > > Thank you! > > /mjt
Bug#939763: sphinxsearch: Still maintained (same version since stretch)?
Hello Manticore team's member here. Vasyl Gello asked me to step in. Just few notes: 1) On behalf of Manticore team I can assure we can help with pushing and maintaining Manticore's packages for Debian. We have build procedures for Debian 8/9/10 as well as and CI and pre-release production testing and make regular releases (about each 2 months). 2) There's no source available publicly for Sphinx 3.* while Manticore Search's source is available on https://github.com/manticoresoftware/manticoresearch Best wishes, Sergey Nikolaev
Bug#968418: ecj depends on java-wrappers but does not have them as a dependency
Package: ecj Version: 3.16.0-1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ecj depends on: ii libecj-java 3.16.0-1 ii openjdk-11-jre-headless [java8-runtime-headless] 11.0.8+10-1~deb10u1 ii openjdk-8-jre-headless [java8-runtime-headless] 8u222-b10-1~deb9u1 ecj recommends no packages. Versions of packages ecj suggests: ii ant 1.10.5-2 -- no debconf information
Bug#966185: monit: new upstream version 5.27.0
On Fri, Jul 31, 2020 at 11:32:54AM +0200, Christian Göttsche wrote: > > I would appreciate any help with this upgrade. There seems to > > be some issues with dh_autoreconf. > > > > I think they should be solved by using the upstream bootstrap script: > > override_dh_autoreconf: > dh_autoreconf ./bootstrap Thank you, this workaround seems to be working.
Bug#966185: monit: new upstream version 5.27.0
tags 966185 +help thanks On Fri, 24 Jul 2020 14:24:50 +0200 =?UTF-8?Q?Christian_G=C3=B6ttsche?= wrote: > Since about a month there is a new upstream version 5.27.0 [1]. > It would be nice to see it packaged in Debian sid. I would appreciate any help with this upgrade. There seems to be some issues with dh_autoreconf.
Bug#964451: chromium (83.0.4103.116-1~deb10u2) constantly crashes and slow
Package: chromium Version: 83.0.4103.116-1~deb10u2 Followup-For: Bug #964451 Dear Maintainer, Chromium 83.0.4103.116-1~deb10u2 constantly crashes after starting in few minuts. I'm shocked that this is in a stable branch and there are still no fix :( -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common 83.0.4103.116-1~deb10u2 ii libasound2 1.1.8-1 ii libatk-bridge2.0-0 2.30.0-5 ii libatk1.0-0 2.30.0-2 ii libatspi2.0-02.30.0-7 ii libavcodec58 7:4.1.6-1~deb10u1 ii libavformat587:4.1.6-1~deb10u1 ii libavutil56 7:4.1.6-1~deb10u1 ii libc62.28-10 ii libcairo21.16.0-4 ii libcups2 2.2.10-6+deb10u3 ii libdbus-1-3 1.12.16-1 ii libdrm2 2.4.97-1 ii libevent-2.1-6 2.1.8-stable-4 ii libexpat12.2.6-2+deb10u1 ii libflac8 1.3.2-3 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3+deb10u1 ii libgbm1 18.3.6-2+deb10u1 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgtk-3-0 3.24.5-1 ii libharfbuzz0b2.3.1-1 ii libicu63 63.1-6+deb10u1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjsoncpp1 1.7.4-3 ii liblcms2-2 2.9-3 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.20-1 ii libnss3 2:3.42.1-1+deb10u2 ii libopenjp2-7 2.3.0-2+deb10u1 ii libopus0 1.3-1 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpng16-16 1.6.36-6 ii libpulse012.2-4+deb10u1 ii libre2-5 20190101+dfsg-2 ii libsnappy1v5 1.1.7-1 ii libstdc++6 8.3.0-6 ii libvpx5 1.7.0-3+deb10u1 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb-dri3-01.13.1-2 ii libxcb1 1.13.1-2 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.15-2 ii libxdamage1 1:1.1.4-3+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.32-2.2~deb10u1 ii libxss1 1:1.2.3-1 ii libxtst6 2:1.2.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages chromium recommends: ii chromium-sandbox 83.0.4103.116-1~deb10u2 Versions of packages chromium suggests: pn chromium-driver ii chromium-l10n83.0.4103.116-1~deb10u2 pn chromium-shell Versions of packages chromium-common depends on: ii x11-utils 7.7+4 ii xdg-utils 1.1.3-1+deb10u1 Versions of packages chromium-common recommends: ii chromium-sandbox 83.0.4103.116-1~deb10u2 ii dunst [notification-daemon]1.3.2-1 ii fonts-liberation 1:1.07.4-9 ii gnome-shell [notification-daemon] 3.30.2-11~deb10u1 ii libgl1-mesa-dri18.3.6-2+deb10u1 ii libu2f-udev1.1.9-1 ii notification-daemon3.20.0-4 ii upower 0.99.10-1 Versions of packages chromium-sandbox depends on: ii libc6 2.28-10 -- no debconf information
Bug#962147: xserver-xorg-video-ast: Package installs driver .so at path not found by Xorg
Package: xserver-xorg-video-ast Version: 1.1.5-1.1+b1 Severity: normal Dear Maintainer, * What led up to the situation? Running a machine with ASPEED AST2400 video. * What exactly did you do (or not do) that was effective (or ineffective)? Install this package, run 'startx'. * What was the outcome of this action? I observe the only available screen resolution to be 640x480. * What outcome did you expect instead? To be able to select all supported screen resolutions, up to 1920x1200. The problem, as I see it, is that the Xorg package won't look into /usr/lib/x86_64-linux-gnu/xorg/modules/drivers/ for drivers, only into /usr/lib/xorg/modules/drivers/, in which all other xserver-xorg-video-* already install them, see ls -al /usr/lib/xorg/modules/drivers/ | wc -l 25 Moving ast_drv.so into it solved this problem. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Mar 6 2014 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Mar 5 2019 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 06:00.0 VGA compatible controller [0300]: ASPEED Technology, Inc. ASPEED Graphics Family [1a03:2000] (rev 30) 83:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU106 [GeForce RTX 2060 SUPER] [10de:1f06] (rev a1) Xorg X server configuration file status: -rw-r--r-- 1 root root 87 Jun 27 2015 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: --- # NOXORGCONFEXISTED: No X.org configuration file existed when this backup was created. /etc/X11/xorg.conf.d does not exist. /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 4.19.0-9-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2 (2020-04-29) Xorg X server log files on system: -- -rw-r--r-- 1 root root 56904 Jun 3 23:13 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 1353.264] X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 [ 1353.265] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian [ 1353.265] Current Operating System: Linux fangorn 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 [ 1353.265] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-9-amd64 root=UUID=a340a5a0-24a4-4255-bab2-5cbeb945e180 ro quiet intel_iommu=on cgroup_enable=memory swapaccount=1 apparmor=0 nomodeset consoleblank=0 spec_store_bypass_disable=on l1tf=flush kvm-intel.vmentry_l1d_flush=cond nmi_watchdog=0 spectre_v2_user=off random.trust_cpu=off net.ifnames=0 [ 1353.266] Build Date: 05 March 2019 08:11:12PM [ 1353.266] xorg-server 2:1.20.4-1 (https://www.debian.org/support) [ 1353.266] Current version of pixman: 0.36.0 [ 1353.266]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 1353.266] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 1353.268] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jun 3 23:13:18 2020 [ 1353.268] (==) Using config file: "/etc/X11/xorg.conf" [ 1353.268] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 1353.268] (==) ServerLayout "ServerLayout0" [ 1353.268] (==) No screen section available. Using defaults. [ 1353.268] (**) |-->Screen "Default Screen Section" (0) [ 1353.268] (**) | |-->Monitor "" [ 1353.269] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 1353.269] (**) Option "BlankTime" "0" [ 1353.269] (**) Option "StandbyTime" "0" [ 1353.269] (**) Option "SuspendTime" "0" [ 1353.269] (**) Option "OffTime" "0" [ 1353.269] (==) Automatically adding devices [ 1353.269] (==) Automatically enabling devices [ 1353.269] (==) Automatically adding GPU devices [ 1353.269] (==) Max clients allowed: 256, resource mask: 0x1f [ 1353.269] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 1353.269]Entry deleted from font path. [ 1353.269] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 1353.269] (==) ModulePath set to "/usr/lib/xorg/modules" [ 1353.269] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 1353.269] (II) Loader magic: 0x558410c31e20 [ 1353.269] (II) Module ABI versions: [ 1353.269]X.Or
Bug#959024: Problems with uscan'ing on github from tracker.debian.org
Package: tracker.debian.org Severity: important Right now in https://tracker.debian.org/pkg/auto-07p I see: -->8-- Problems while searching for a new upstream version uscan had problems while searching for a new upstream version: In watchfile debian/watch, reading webpage https://github.com/auto-07p/auto-07p/releases failed: 429 too many requests -->8-- Set severity important to reflect the checker status (high).
Bug#902204: monit: spurious "monit alert -- Link up eth0" messages
tags 902204 +fixed-upstream forwarded 902204 https://bitbucket.org/tildeslash/monit/issues/840/regression-failed-link-check-generates thanks
Bug#902204: Processed: Re: Bug#902204: monit: spurious "monit alert -- Link up eth0" messages
tag 902204 +pending thanks On Wed, Apr 22, 2020 at 08:48:49PM +0200, mart...@tildeslash.com wrote: > Hello, > > the problem is fixed: > https://bitbucket.org/tildeslash/monit/commits/f3bea23a52db I'm glad to hear. Please try post to the bug thread next time. Will be 5.27.0 soon (May?) or I should rather port this fix, which seems to be trivial. > > On 5 Feb 2020, at 15:06, Debian Bug Tracking System > > wrote: > > > > Processing commands for cont...@bugs.debian.org: > > > >> severity 902204 normal > > Bug #902204 [monit] monit: spurious "monit alert -- Link up eth0" messages > > Severity set to 'normal' from 'important' > >> thanks > > Stopping processing here. > > > > Please contact me if you need assistance. > > -- > > 902204: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902204 > > Debian Bug Tracking System > > Contact ow...@bugs.debian.org with problems > > > `
Bug#955615: D-Bus policy configuration file is missed
Package: shairport-sync Version: 3.3.5-1 Priority: minor D-Bus policy configuration file is missed and the 'journalct -u shairport-sync' log contains the following message: Could not acquire a Shairport Sync native D-Bus interface "org.gnome.ShairportSync.i524" on the system bus Configuration file can be copied from scripts/shairport-sync-dbus-policy.conf (in shairport-sync source tree) to /etc/dbus-1/system.d/shairport-sync-dbus-policy.conf
Bug#902204: monit: spurious "monit alert -- Link up eth0" messages
severity 902204 normal
thanks
Lowered bug severity to reflect upstream's one.
On Sun, 7 Jul 2019 09:16:45 +0300 Sergey B Kirpichev
wrote:
> forwarded 902204
> https://bitbucket.org/tildeslash/monit/issues/490/separate-link-down-and-link-error-event
> thanks
>
> Martin, please correct me if I set wrong upstream issue for this bug.
>
> On Tue, 19 Feb 2019 22:47:46 +0100 "mart...@tildeslash.com"
> wrote:
> >
> > > On 19 Feb 2019, at 02:47, Vincent Lefevre wrote:
> > >
> > > Hi,
> > >
> > > On 2019-02-18 22:51:50 +0100, mart...@tildeslash.com wrote:
> > >> Hello, the 5dc2681 is not bug.
> > >
> > > Well, I assume that the bug was already present, but I think that it
> > > was 5dc2681 that made it visible.
> > >
> > >> Vincent, please can you run Monit in debug mode and send output? (monit
> > >> -vI)
> > >
> > > When starting monit with the Ethernet cable unplugged:
> > >
> > > # /usr/bin/monit -c /etc/monit/monitrc -vI
> > > Runtime constants:
> > > Control file = /etc/monit/monitrc
> > > Log file = /var/log/monit.log
> > > Pid file = /run/monit.pid
> > > Id file= /var/lib/monit/id
> > > State file = /var/lib/monit/state
> > > Debug = True
> > > Log= True
> > > Use syslog = False
> > > Is Daemon = True
> > > Use process engine = True
> > > Limits = {
> > >= programOutput: 512 B
> > >= sendExpectBuffer: 256 B
> > >= fileContentBuffer: 512 B
> > >= httpContentBuffer: 1 MB
> > >= networkTimeout:5 s
> > >= programTimeout:5 m
> > >= stopTimeout: 30 s
> > >= startTimeout: 30 s
> > >= restartTimeout:30 s
> > >= }
> > > On reboot = start
> > > Poll time = 120 seconds with start delay 0 seconds
> > > Event queue= base directory /var/lib/monit/events with 100 slots
> > > Mail server(s) = localhost:25 with timeout 30 s
> > > Start monit httpd = False
> > > Alert mail to = vinc...@vinc17.net
> > > Alert on = All events
> > >
> > > The service list contains the following entries:
> > >
> > > Network Name = eth0
> > > Interface= eth0
> > > Monitoring mode = active
> > > On reboot= start
> > > Link status = if failed then alert
> > > Link capacity= if changed then alert
Bug#944282: stretch-pu: monit 1:5.20.0-6+deb9u1
On Tue, Jan 28, 2020 at 08:37:37AM +, Adam D. Barratt wrote: > On 2019-11-07 08:49, Sergey B Kirpichev wrote: > > I would like to make an upload to stable in order to fix bug > > #941895 (CSRF check) in the monit package. > > Please go ahead; sorry for the delay. Thanks, uploaded.
Bug#806941: Re: Bug#806941: Change upstream for lib-apache2-mod-rpaf
On Fri, Jan 10, 2020 at 03:51:35PM +0100, Marco d'Itri wrote: > - you orphan the package and let somebody else adopt it so that they can > package a modern version I did, long time ago.
Bug#941895: monit: invalid CSRF check causes login issues
On Mon, Nov 04, 2019 at 12:10:48PM +, Jonathan Wiltshire wrote: > Yes, that seems to solve it - thanks for your patience. Thank you for feedback! I've sent bugreport against release.debian.org: https://bugs.debian.org/944282 Maybe next year the package will be uploaded.
Bug#944282: stretch-pu: monit 1:5.20.0-6+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Dear Release Team,
I would like to make an upload to stable in order to fix bug
#941895 (CSRF check) in the monit package.
Package on mentors.d.n:
https://mentors.debian.net/package/monit
The full patch between this new package version and the version
1:5.20.0-6 currently in Stretch is attached.
diff -Nru monit-5.20.0/debian/changelog monit-5.20.0/debian/changelog
--- monit-5.20.0/debian/changelog 2017-01-11 16:48:27.0 +0300
+++ monit-5.20.0/debian/changelog 2019-10-09 15:47:31.0 +0300
@@ -1,3 +1,9 @@
+monit (1:5.20.0-6+deb9u1) stretch; urgency=medium
+
+ * Implement position independent CSRF cookie value (Closes: #941895).
+
+ -- Sergey B Kirpichev Wed, 09 Oct 2019 15:47:31 +0300
+
monit (1:5.20.0-6) unstable; urgency=medium
* Fix regression from #849886, test monit.log existence (Closes: #850829)
diff -Nru monit-5.20.0/debian/patches/12_PID_CSRF.patch monit-5.20.0/debian/patches/12_PID_CSRF.patch
--- monit-5.20.0/debian/patches/12_PID_CSRF.patch 1970-01-01 03:00:00.0 +0300
+++ monit-5.20.0/debian/patches/12_PID_CSRF.patch 2019-10-09 15:47:31.0 +0300
@@ -0,0 +1,109 @@
+Origin: https://bitbucket.org/tildeslash/monit/commits/f9a9a7a92
+Description: Position independent CSRF cookie value
+Bug-Debian: https://bugs.debian.org/941895
+
+---
+ src/http/processor.c | 61 +--
+ 1 file changed, 45 insertions(+), 16 deletions(-)
+
+--- a/src/http/processor.c
b/src/http/processor.c
+@@ -258,7 +258,7 @@ void set_header(HttpResponse res, const
+ for (n = p = res->headers; p; n = p, p = p->next) {
+ if (IS(p->name, name)) {
+ FREE(p->value);
+-p->value = Str_dup(value);
++p->value = Str_dup(h->value);
+ destroy_entry(h);
+ return;
+ }
+@@ -288,6 +288,7 @@ void set_status(HttpResponse res, int co
+ * @param mime Mime content type, e.g. text/html
+ */
+ void set_content_type(HttpResponse res, const char *mime) {
++ASSERT(mime);
+ set_header(res, "Content-Type", "%s", mime);
+ }
+
+@@ -720,9 +721,11 @@ static void destroy_entry(void *p) {
+ /* - Checkers/Validators */
+
+
+-/**
+- * Do Basic Authentication if this auth. style is allowed.
+- */
++static boolean_t _isCookieSeparator(int c) {
++return (c == ' ' || c == '\n' || c == ';' || c == ',');
++}
++
++
+ static boolean_t is_authenticated(HttpRequest req, HttpResponse res) {
+ if (Run.httpd.credentials) {
+ if (! basic_authenticate(req)) {
+@@ -734,28 +737,54 @@ static boolean_t is_authenticated(HttpRe
+ }
+ if (IS(req->method, METHOD_POST)) {
+ // Check CSRF double-submit cookie (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Double_Submit_Cookie)
+-const char *cookie = get_header(req, "Cookie");
+ const char *token = get_parameter(req, "securitytoken");
+-if (! cookie) {
+-LogError("HttpRequest: access denied -- client [%s]: missing CSRF token cookie\n", NVLSTR(Socket_getRemoteHost(req->S)));
+-send_error(req, res, SC_FORBIDDEN, "Invalid CSRF Token");
+-return false;
+-}
+ if (! token) {
+ LogError("HttpRequest: access denied -- client [%s]: missing CSRF token in HTTP parameter\n", NVLSTR(Socket_getRemoteHost(req->S)));
+ send_error(req, res, SC_FORBIDDEN, "Invalid CSRF Token");
+ return false;
+ }
+-if (! Str_startsWith(cookie, "securitytoken=")) {
+-LogError("HttpRequest: access denied -- client [%s]: no CSRF token in cookie\n", NVLSTR(Socket_getRemoteHost(req->S)));
++const char *cookie = get_header(req, "Cookie");
++if (! cookie) {
++LogError("HttpRequest: access denied -- client [%s]: missing CSRF token cookie\n", NVLSTR(Socket_getRemoteHost(req->S)));
+ send_error(req, res, SC_FORBIDDEN, "Invalid CSRF Token");
+ return false;
+ }
+-if (Str_compareConstantTime(cookie + 14, token)) {
+-LogError("HttpRequest: access denied -- client [%s]: CSRF token mismatch\n", NVLSTR(Socket_getRemoteHost(req->S)));
+-
Bug#941412: CVE-2019-14866
Hi Ola, > Hi Sergey > > I can see that the fix is quite different from the one Thomas proposed. Do > I understand correctly that this fix go around the problem in a different > way? Not quite so. It takes basically the same approach as the fix Thomas proposed, but also removes unnecessary code duplication and ensures informative error diagnostics. > I do not see any explicit value > 0 check. See the return from the to_ascii function. > it looks like the fix allows larger file sizes No, of course all size limits remain the same, Regards, Sergey
Bug#941412: CVE-2019-14866
Hi Ola & Thomas, > I have been preparing fixes for CVE-2019-14866 for Debian oldstable Thank you. The issue has been fixed in commit 7554e3e4 [1]. Regards, Sergey [1] http://git.savannah.gnu.org/cgit/cpio.git/commit/?id=7554e3e42cd72f6f8304410c47fe6f8918e9bfd7
Bug#868164: systemd: fakeraid + cryptsetup (root) + lvm results in 90s time out waiting for device at boot
Hi, I have found, that my problem is caused only in case of mdraid device partitioning. To reproduce: 1. Take 2 HDD (at least by 50 GB) 2. Run from any LiveCD 3. Make two partitions on each HDD: for 256-1024MB and for remaining space, make first partition bootable 4. Create mdraid1 around second partitions of both HDD 5. Repartition md device by 3 partitions: 10GB (md0p1), 20GB (md0p2) and remaining space (md0p3) 6. Using cryptsetup configure luks encryption over md0p2. 7. Install debian 9 or 10, using: /dev/sda1 - /boot, /dev/md0p1 - /root, /dev/md0p2 - /var, /dev/mapper/ - /home After reboot system do not start if default boot options are specified. It will wait for some devices to be ready, but no any password prompt. There is only one way to boot system: run rescue mode and then exit from rescue shell using Ctrl-D. If you create on HDDs four partitions and use them to build four RAID1 devices, then encrypted device configured on /dev/md3 will start on boot successfully (after prompting password). So I think, some boot scripts/services does not know anything about md device partitioning.
Bug#936164: auto-07p: Python2 removal in sid/bullseye
tags 937695 +pending +upstream +fixed-upstream thanks It seems, Python3-compatible release will be available soon: https://github.com/auto-07p/auto-07p/issues/2 On Fri, 30 Aug 2019 07:10:54 + Matthias Klose wrote: > Package: src:auto-07p > Version: 0.9.1+dfsg-7 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Your package either build-depends, depends on Python2, or uses Python2 > in the autopkg tests. Please stop using Python2, and fix this issue > by one of the following actions. > > - Convert your Package to Python3. This is the preferred option. In > case you are providing a Python module foo, please consider dropping > the python-foo package, and only build a python3-foo package. Please > don't drop Python2 modules, which still have reverse dependencies, > just document them. > > This is the preferred option. > > - If the package is dead upstream, cannot be converted or maintained > in Debian, it should be removed from the distribution. If the > package still has reverse dependencies, raise the severity to > "serious" and document the reverse dependencies with the BTS affects > command. If the package has no reverse dependencies, confirm that > the package can be removed, reassign this issue to ftp.debian.org, > make sure that the bug priority is set to normal and retitle the > issue to "RM: PKG -- removal triggered by the Python2 removal". > > - If the package has still many users (popcon >= 300), or is needed to > build another package which cannot be removed, document that by > adding the "py2keep" user tag (not replacing the py2remove tag), > using the debian-pyt...@lists.debian.org user. Also any > dependencies on an unversioned python package (python, python-dev) > must not be used, same with the python shebang. These have to be > replaced by python2/python2.7 dependencies and shebang. > > This is the least preferred option. > > If the conversion or removal needs action on another package first, > please document the blocking by using the BTS affects command, like > > affects + src:auto-07p > > If there is no py2removal bug for that reverse-dependency, please file > a bug on this package (similar to this bug report). > > If there are questions, please refer to the wiki page for the removal: > https://wiki.debian.org/Python/2Removal, or ask for help on IRC > #debian-python, or the debian-pyt...@lists.debian.org mailing list. > >
Bug#941895: (no subject)
cont...@bugs.debian.org Bcc: Subject: Re: Bug#941895: monit: invalid CSRF check causes login issues Reply-To: skirpic...@gmail.com In-Reply-To: <20191009143716.GA17535@note> X-Debbugs-No-Ack: no, please tags 941895 +moreinfo thanks Ok, I'll wait for feedback for 2 weeks. On Wed, 9 Oct 2019 17:37:16 +0300 Sergey B Kirpichev wrote: > On Mon, Oct 07, 2019 at 12:15:13PM +0100, Jonathan Wiltshire wrote: > > I'm happy to sponsor uploads to the stable suites, certainly. You will > > need approval from the stable release managers first then, and I will > > avoid wearing that hat for this case in order to avoid a conflict of > > interest. > > I think, I can handle stable uploads myself, as I did previously. But > if not (release managers may be unhappy with changes) - backports is > only option. > > Meanwhile, I'll raise issue severity (only important+ bugfixes > can enter point releases). > > > I don't monitor monit (haha) or sponsorship-requests generally, so drop > > me a mail when you are ready for it to be uploaded. > > I've cherry-picked > https://bitbucket.org/tildeslash/monit/commits/f9a9a7a92 > - please test package. It was uploaded to the mentors.d.n: > https://mentors.debian.net/package/monit > > Please test. > >
Bug#941895: monit: invalid CSRF check causes login issues
severity 941895 important thanks On Mon, Oct 07, 2019 at 12:15:13PM +0100, Jonathan Wiltshire wrote: > I'm happy to sponsor uploads to the stable suites, certainly. You will > need approval from the stable release managers first then, and I will > avoid wearing that hat for this case in order to avoid a conflict of > interest. I think, I can handle stable uploads myself, as I did previously. But if not (release managers may be unhappy with changes) - backports is only option. Meanwhile, I'll raise issue severity (only important+ bugfixes can enter point releases). > I don't monitor monit (haha) or sponsorship-requests generally, so drop > me a mail when you are ready for it to be uploaded. I've cherry-picked https://bitbucket.org/tildeslash/monit/commits/f9a9a7a92 - please test package. It was uploaded to the mentors.d.n: https://mentors.debian.net/package/monit Please test.
Bug#941895: monit: invalid CSRF check causes login issues
tags 941895 +moreinfo thanks On Mon, Oct 07, 2019 at 11:33:34AM +0100, Jonathan Wiltshire wrote: > Please consider backporting this fix to stretch in the next oldstable > point release. I haven't investigated whether it is the sole change in > 5.21 or whether it would have to be cherry-picked. 5.21 should work, yes. BTW, why you can't use the stable backport? Are you able to sponsor oldstable backport? See https://bugs.debian.org/887350 - the previous stretch backport was sitting on the mentors.d.n more than year...
Bug#941075: monit: no systemctl file for monit
tags 941075 +unreproducible thanks On Tue, Sep 24, 2019 at 04:34:21PM +0200, Han Boetes wrote: >No, it means you can close the bug, and absolutely nothing else. Why you open an issue, if you are not intended to help with it's solution? Lets reiterate my question: --->8-- I don't understand. What conditions lead to the state "monit not running"? -->8-- Could you help with this?
Bug#941075: monit: no systemctl file for monit
On Tue, Sep 24, 2019 at 03:44:03PM +0200, Han Boetes wrote: >Never you mind, you can close the bug. Is that means the problem was identified right, i.e. you are using initscript /etc/init.d/monit directly? >On Tue, Sep 24, 2019 at 12:06 PM Sergey B Kirpichev ><[1]skirpic...@gmail.com> wrote: > I don't understand. What conditions lead to the state "monit not > running"? > > Perhaps, you have system with systemd, but manage monit using > /etc/init.d/monit > script directly. You shouldn't do it, this makes systemd crazy, but > this is not a monit's problem. > > Use systemctl to start/stop/reload monit on systemd-enabled > hosts - and everything should work and systemd will be happy. Please > let me know if you still have problems after using this suggestion.
Bug#941075: monit: no systemctl file for monit
tags 941075 +moreinfo thanks On Tue, Sep 24, 2019 at 11:38:52AM +0200, Han Boetes wrote: > The current monit package does not include a systemctl file, often resulting > in > monit not running. If I'd check the status with systemctl the result was: > active(exited) see also: https://unix.stackexchange.com/questions/241970/what- > does-status-active-exited-mean-for-a-systemd-service I don't understand. What conditions lead to the state "monit not running"? Perhaps, you have system with systemd, but manage monit using /etc/init.d/monit script directly. You shouldn't do it, this makes systemd crazy, but this is not a monit's problem. Use systemctl to start/stop/reload monit on systemd-enabled hosts - and everything should work and systemd will be happy. Please let me know if you still have problems after using this suggestion. > Easy fix: add a systemd file and remove the /etc/init.d/monit file Are you volunteered to debug and fix any problems with systemd-enabled setups and this unit file? Please look to the README.Debian: monit can work with systemd, but it would be better, if you avoid this use case.
Bug#939168: systemd: LXC container fails to start after stretch->buster update inside container
> You should probably attach the output of > reportbug --template lxc > to this bug report so the lxc maintainers have some context. I'm attaching 'lxc-start -n testupg --logfile=lxc.log -l DEBUG' and 'reportbug --template lxc' outputs to this message. > Checking the existing bug reports, there are already a few which concern > sysvinit. > I would suggest that you check them out like > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869892 I've looked at them yesterday, just in case, and didn't see anything obviously related. For example, for this one, I already have cgroupfs-mount installed and /sys/fs/cgroup present. And while I see mounting errors for the container after upgrade (not the attached log, but the original container i've tried to upgrade), they do not seem to be an immediate cause for the startup failure. lxc.log Description: Binary data reportbug.log Description: Binary data
Bug#939168: systemd: LXC container fails to start after stretch->buster update inside container
The init system that fails inside the container is the default one for both stretch/buster - systemd, that's why i've reported this issue here. LXC/init versions on the host haven't changed.
Bug#939168: systemd: LXC container fails to start after stretch->buster update inside container
Source: systemd Version: 241-5 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I'm running LXC containers (lxc version 1:2.0.7-2+deb9u2) on debian stretch. I have several containers with different debian versions inside. After I've done stretch->buster upgrade in one of them, it stopped working with 'lxc-start: tools/lxc_start.c: main: 366 The container failed to start.' message. * What exactly did you do (or not do) that was effective (or ineffective)? This is a reproducible sequence: lxc-create -n testupg -t download # choose debian - stretch - amd64 lxc-start -n testupg lxc-attach -n testupg # inside container vi /etc/apt/sources.list # change stretch -> buster apt-get update apt-get dist-upgrade exit # outside of container lxc-stop -n testupg lxc-start -n testupg # won't work I'd expect containers to keep working after dist-upgrade. -- System Information: Debian Release: 9.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-9-amd64 (SMP w/56 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#935959: linux-image-5.2.0-2-amd64: rt2800usb no longer scan 5Ghz networks
Package: src:linux Version: 5.2.9-2 Severity: important Tags: upstream Dear Maintainer, I have Alfa awus051nh (RT2770) device and 5Ghz stop working after upgrade to 5.2 kernel, on 4.9 all works fine with same configurations. AP working on 5180 channel ➤ lsmod|grep rt2 rt2800usb 28672 0 rt2x00usb 28672 1 rt2800usb rt2800lib 135168 1 rt2800usb rt2x00lib 69632 3 rt2800usb,rt2x00usb,rt2800lib mac80211 868352 3 rt2x00lib,rt2x00usb,rt2800lib cfg80211 819200 2 rt2x00lib,mac80211 crc_ccitt 16384 1 rt2800lib usbcore 299008 9 xhci_hcd,rt2800usb,usbhid,xpad,usblp,usb_storage,xhci_pci,uas,rt2x00usb #iw reg get global country UA: DFS-ETSI (2400 - 2483 @ 40), (N/A, 20), (N/A), NO-OUTDOOR (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW (5490 - 5670 @ 160), (N/A, 20), (0 ms), DFS (5735 - 5835 @ 80), (N/A, 20), (N/A) (57000 - 66000 @ 2160), (N/A, 40), (N/A) reseting country did't help # iw phy0 info Wiphy phy0 max # scan SSIDs: 4 max scan IEs length: 2257 bytes max # sched scan SSIDs: 0 max # match sets: 0 max # scan plans: 1 max scan plan interval: -1 max scan plan iterations: 0 Retry short long limit: 2 Coverage class: 0 (up to 0m) Device supports RSN-IBSS. Supported Ciphers: * WEP40 (00-0f-ac:1) * WEP104 (00-0f-ac:5) * TKIP (00-0f-ac:2) * CCMP-128 (00-0f-ac:4) * CCMP-256 (00-0f-ac:10) * GCMP-128 (00-0f-ac:8) * GCMP-256 (00-0f-ac:9) Available Antennas: TX 0 RX 0 Supported interface modes: * IBSS * managed * AP * AP/VLAN * monitor * mesh point Band 1: Capabilities: 0x27e HT20/HT40 SM Power Save disabled RX Greenfield RX HT20 SGI RX HT40 SGI RX STBC 2-streams Max AMSDU length: 3839 bytes No DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 2 usec (0x04) HT RX MCS rate indexes supported: 0-15, 32 TX unequal modulation not supported HT TX Max spatial streams: 1 HT TX MCS rate indexes supported may differ Bitrates (non-HT): * 1.0 Mbps * 2.0 Mbps (short preamble supported) * 5.5 Mbps (short preamble supported) * 11.0 Mbps (short preamble supported) * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps Frequencies: * 2412 MHz [1] (20.0 dBm) * 2417 MHz [2] (20.0 dBm) * 2422 MHz [3] (20.0 dBm) * 2427 MHz [4] (20.0 dBm) * 2432 MHz [5] (20.0 dBm) * 2437 MHz [6] (20.0 dBm) * 2442 MHz [7] (20.0 dBm) * 2447 MHz [8] (20.0 dBm) * 2452 MHz [9] (20.0 dBm) * 2457 MHz [10] (20.0 dBm) * 2462 MHz [11] (20.0 dBm) * 2467 MHz [12] (20.0 dBm) * 2472 MHz [13] (20.0 dBm) * 2484 MHz [14] (disabled) Band 2: Capabilities: 0x27e HT20/HT40 SM Power Save disabled RX Greenfield RX HT20 SGI RX HT40 SGI RX STBC 2-streams Max AMSDU length: 3839 bytes No DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 2 usec (0x04) HT RX MCS rate indexes supported: 0-15, 32 TX unequal modulation not supported HT TX Max spatial streams: 1 HT TX MCS rate indexes supported may differ Bitrates (non-HT): * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps
Bug#931974: O: festvox-ru - Russian male speaker for Festival
On Sun, Jul 28, 2019 at 05:23:17PM +0200, Samuel Thibault wrote: > Sergey B Kirpichev, le dim. 28 juil. 2019 17:52:29 +0300, a ecrit: > > On Sun, Jul 28, 2019 at 04:44:25PM +0200, Samuel Thibault wrote: > > > We can maintain this along the other voices under the tts-team umbrella. > > > I have added you to the tts-team group on salsa, I guess this is enough > > > for you to transfer the salsa project? > > > > What exactly I should do? > > On salsa, on your festvox-ru project page, in the Settings panel, in the > General subpanel, Expand the Advanced section, and in the Transfert > Project box, you should be able to choose "Debian TTS Maintainers". If > it doesn't appear in the list, I'll increase your access to the group. Thank you, I did. Hopefully, everything ok.
Bug#931974: O: festvox-ru - Russian male speaker for Festival
On Sun, Jul 28, 2019 at 04:44:25PM +0200, Samuel Thibault wrote: > We can maintain this along the other voices under the tts-team umbrella. > I have added you to the tts-team group on salsa, I guess this is enough > for you to transfer the salsa project? What exactly I should do?
Bug#931972: Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
On Wed, Jul 17, 2019 at 06:56:53AM +0200, Sebastiaan Couwenberg wrote: > buster-backports is now open, but the monit package cannot be uploaded > to it in its current shape. > > The version is not correct: 5.26.0-1~bpo9+1 > > For buster-backports '~bpo10+1` should be used. > > Beware that `dch --bpo` still defaults to stretch-backports on buster, > so you need to change the distribution and changelog entry to > buster-backports too. Yes, broken dch was the reason. I didn't fix changelog fully. I hope, that fixed now. Sorry. https://mentors.debian.net/debian/pool/main/m/monit/monit_5.26.0-1~bpo10+1.dsc > The .orig.tar.gz is not available on mentors, and there is no > buster-backports branch in the repo on Salsa yet, so the package cannot > be built currently. > > Please push the buster-backports branch to Salsa, I'll take it from there. Pushed too.
Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
On Sun, 7 Jul 2019 08:29:08 +0200 Sebastiaan Couwenberg wrote: > Please upload a new revision to unstable with source-only changes... Backport for Buster: https://mentors.debian.net/package/monit Please sponsor this package. Sponsorship request: https://bugs.debian.org/931972
Bug#931974: O: festvox-ru - Russian male speaker for Festival
Package: wnpp Severity: normal I am winding down my involvement in Debian to a minimum and I have no intentions to support this package anymore. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it.
Bug#931973: O: libapache2-mod-qos - quality of service module for the apache2
Package: wnpp Severity: normal I am winding down my involvement in Debian to a minimum and I have no intentions to support this package anymore. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it.
Bug#931972: RFS: monit/1:5.26.0-1~bpo9+1 -- backport for buster
Package: sponsorship-requests Severity: normal I am looking for a sponsor for my backport package "monit": To access further information about this package, please visit the following URL: https://mentors.debian.net/package/monit
Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
On Sun, Jul 07, 2019 at 08:29:08AM +0200, Sebastiaan Couwenberg wrote: > Please upload a new revision to unstable with source-only changes to I did just now (5.26.0).
Bug#902204: monit: spurious "monit alert -- Link up eth0" messages
forwarded 902204
https://bitbucket.org/tildeslash/monit/issues/490/separate-link-down-and-link-error-event
thanks
Martin, please correct me if I set wrong upstream issue for this bug.
On Tue, 19 Feb 2019 22:47:46 +0100 "mart...@tildeslash.com"
wrote:
>
> > On 19 Feb 2019, at 02:47, Vincent Lefevre wrote:
> >
> > Hi,
> >
> > On 2019-02-18 22:51:50 +0100, mart...@tildeslash.com wrote:
> >> Hello, the 5dc2681 is not bug.
> >
> > Well, I assume that the bug was already present, but I think that it
> > was 5dc2681 that made it visible.
> >
> >> Vincent, please can you run Monit in debug mode and send output? (monit
> >> -vI)
> >
> > When starting monit with the Ethernet cable unplugged:
> >
> > # /usr/bin/monit -c /etc/monit/monitrc -vI
> > Runtime constants:
> > Control file = /etc/monit/monitrc
> > Log file = /var/log/monit.log
> > Pid file = /run/monit.pid
> > Id file= /var/lib/monit/id
> > State file = /var/lib/monit/state
> > Debug = True
> > Log= True
> > Use syslog = False
> > Is Daemon = True
> > Use process engine = True
> > Limits = {
> >= programOutput: 512 B
> >= sendExpectBuffer: 256 B
> >= fileContentBuffer: 512 B
> >= httpContentBuffer: 1 MB
> >= networkTimeout:5 s
> >= programTimeout:5 m
> >= stopTimeout: 30 s
> >= startTimeout: 30 s
> >= restartTimeout:30 s
> >= }
> > On reboot = start
> > Poll time = 120 seconds with start delay 0 seconds
> > Event queue= base directory /var/lib/monit/events with 100 slots
> > Mail server(s) = localhost:25 with timeout 30 s
> > Start monit httpd = False
> > Alert mail to = vinc...@vinc17.net
> > Alert on = All events
> >
> > The service list contains the following entries:
> >
> > Network Name = eth0
> > Interface= eth0
> > Monitoring mode = active
> > On reboot= start
> > Link status = if failed then alert
> > Link capacity= if changed then alert
> >
> > System Name = zira
> > Monitoring mode = active
> > On reboot= start
> >
> > ---
Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
On Thu, Jul 04, 2019 at 02:13:03PM +0200, Bas Couwenberg wrote: > How often do you expect to need NEW processing for monit? Probably, once every major release. Backport is a frequent request. > Do you know any users of the package who have contributed patches or other > maintainer type bugreports that could be recruited to help co-maintain the > package? Yes, take look in the history. Someone was added to Uploaders, but after year+ of inactivity - I've decided to remove that contributor. > My strong preference is for you to maintain the backport as you are the most > able maintainer of the package, so I hope we can find a solution where I can > support you with the unpleasant bureaucracy to enable you keep doing your > work on the monit package (and its backports). Ok, ping me (e.g. with a bug), when this option will be available. I'll provide a package after few days.
Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
On Thu, Jul 04, 2019 at 12:48:23PM +0200, Bas Couwenberg wrote: > The RT ticket show that you were added to the backports ACL It doesn't help too much: initial upload must be sponsored. > I guess Michal > wasn't available to sponsor your initial backports upload Unfortunately, nobody wasn't available to sponsor for a year. But now we have Anti-Harassment Team. Hooray! > Are you willing to maintain the monit backport if I sponsor the NEW uploads No. Next time _you_ may be unavailable to sponsor backport for a buster+1. I won't give package users impression that backports are supported, when it's not the case. Feel free to provide backport yourself. I also can add you as a co-maintainer and/or step down as a package maintainer.
Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
On Thu, Jul 04, 2019 at 10:31:07AM +0200, Bas Couwenberg wrote: > We rely on monit at $DAYJOB, so I want to help you get monit back in buster. Am afraid, there is no chance for monit to enter buster. Sorry for this situation, but I believe this is not just my fault (see this bug thread). Anyway, if you know someone, who can offer better support for monit in the debian - just tell. I will appreciate any help and/or may step down as a maintainer. > I'm somewhat reluctantly willing to maintain the monit backport > if you don't want to main the package in backports. Sure, do. > Are you willing to maintain monit in backports if the stable update is not > accepted? I will not try again to spend my time for providing backports. Feel free to waste your time.
Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
On Thu, Jul 04, 2019 at 10:54:10AM +0200, Paul Gevers wrote: > Once packages can migrate normally again (somewhere next week if > everything goes as expected), monit will be back in testing and > backports is a viable option. Feel free to do backport. Latest one was dated Fri, 21 Dec 2018 (https://bugs.debian.org/887350). No luck. Have fun with the debian bureaucracy.
Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
On Thu, Jun 27, 2019 at 01:40:42PM +0200, Paul Gevers wrote: > We're sorry, but we'll be removing monit from buster shortly. Thanks for a great release menagement!
Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
On Tue, Jun 18, 2019 at 08:21:38PM +0200, Paul Gevers wrote: > Can you ask somebody else to upload it then? No.
Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
On Mon, 17 Jun 2019 21:19:07 +0200 Paul Gevers wrote: > we don't want packages going though it that don't need to. monit package going to be removed from buster. Maybe this justifies migration from t-p-u? I'm away from my build environment and hardly able to prepare in time that you require for Sid.
Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
On Mon, Jun 17, 2019 at 09:20:18PM +0200, Paul Gevers wrote: > > This debdiff looks good. Can you please upload it as > > 1:5.25.3-1+really5.25.2-1 (with the source tar ball of 1:5.25.2) to > > unstable as requested in bug 930313. tpu isn't covered well by QA, so we > > don't want packages going though it that don't need to. > > Should have been 1:5.25.3+really5.25.2-1. Could you kindly explain what's wrong with the current version? I don't understand why I should set an invalid upstream version.
Bug#930641: r5rs.info missing
Package: guile-2.2-doc Severity: important The Guile manual has broken references to the r5rs.info, which is not installed.
Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package monit in t-p-u. The version
1:5.25.2-3+deb10u1 has only targeted fixes for security
issue #927775 (two CVE's). See attached diff.
diff --git a/debian/changelog b/debian/changelog
index bd3d9b0..8712671 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+monit (1:5.25.2-3+deb10u1) testing-proposed-updates; urgency=medium
+
+ * Backport upstream fixes (Closes: #927775):
++ CVE-2019-11454 Persistent cross-site scripting (XSS) in http/cervlet.c
++ CVE-2019-11455 A buffer over-read in Util_urlDecode in util.c
+
+ -- Sergey B Kirpichev Mon, 17 Jun 2019 10:57:40 +0300
+
monit (1:5.25.2-3) unstable; urgency=medium
* Spelling fixes in manpage
diff --git a/debian/patches/CVE-2019-11454.patch b/debian/patches/CVE-2019-11454.patch
new file mode 100644
index 000..ce73e8d
--- /dev/null
+++ b/debian/patches/CVE-2019-11454.patch
@@ -0,0 +1,20 @@
+Description: Fix CVE-2019-11454
+Origin: https://bitbucket.org/tildeslash/monit/commits/328f607
+Forwarded: not needed
+Bug-Debian: https://bugs.debian.org/927775
+
+---
+ src/http/cervlet.c |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/src/http/cervlet.c
b/src/http/cervlet.c
+@@ -906,7 +906,7 @@ static void do_viewlog(HttpRequest req,
+ StringBuffer_append(res->outputbuffer, "");
+ while ((n = fread(buf, sizeof(char), sizeof(buf) - 1, f)) > 0) {
+ buf[n] = 0;
+-StringBuffer_append(res->outputbuffer, "%s", buf);
++escapeHTML(res->outputbuffer, buf);
+ }
+ fclose(f);
+ StringBuffer_append(res->outputbuffer, "");
diff --git a/debian/patches/CVE-2019-11455.patch b/debian/patches/CVE-2019-11455.patch
new file mode 100644
index 000..3845fd3
--- /dev/null
+++ b/debian/patches/CVE-2019-11455.patch
@@ -0,0 +1,58 @@
+Description: Fix CVE-2019-11455
+Origin: https://bitbucket.org/tildeslash/monit/commits/f12d0cdb
+Forwarded: not needed
+Bug-Debian: https://bugs.debian.org/927775
+
+---
+ src/util.c | 16 +---
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+--- a/src/util.c
b/src/util.c
+@@ -233,7 +233,7 @@ static char *is_str_defined(char *s) {
+ /**
+ * Convert a hex char to a char
+ */
+-static char x2c(char *hex) {
++static char _x2c(char *hex) {
+ register char digit;
+ digit = ((hex[0] >= 'A') ? ((hex[0] & 0xdf) - 'A')+10 : (hex[0] - '0'));
+ digit *= 16;
+@@ -535,7 +535,7 @@ void Util_handleEscapes(char *buf) {
+ */
+ *(buf + insertpos) = *(buf+editpos);
+ } else {
+-*(buf + insertpos) = x2c(&buf[editpos + 3]);
++*(buf + insertpos) = _x2c(&buf[editpos + 3]);
+ editpos += 4;
+ }
+ }
+@@ -571,7 +571,7 @@ int Util_handle0Escapes(char *buf) {
+ switch (*(buf + editpos + 1)) {
+ case '0':
+ if (*(buf + editpos + 2) == 'x') {
+-*(buf + insertpos) = x2c(&buf[editpos+3]);
++*(buf + insertpos) = _x2c(&buf[editpos+3]);
+ editpos += 4;
+ }
+ break;
+@@ -1561,13 +1561,15 @@ char *Util_urlDecode(char *url) {
+ if (url && *url) {
+ register int x, y;
+ for (x = 0, y = 0; url[y]; x++, y++) {
+-if ((url[x] = url[y]) == '+')
++if (url[y] == '+') {
+ url[x] = ' ';
+-else if (url[x] == '%') {
+-if (! (url[x + 1] && url[x + 2]))
++} else if (url[y] == '%') {
++if (! url[y + 1] || ! url[y + 2])
+ break;
+-url[x] = x2c(url + y + 1);
++url[x] = _x2c(url + y + 1);
+ y += 2;
++} else {
++url[x] = url[y];
+
Bug#927775: monit: CVE-2019-11454 CVE-2019-11455
On Wed, 12 Jun 2019 17:07:11 +0200 Ivo De Decker wrote: > As the security team considers this an issue that needs to be fixed for > buster, I'm increasing the severity. Please do not downgrade it again. Thanks for "help", security team. > Note that the revert Paul mentioned in #930313 I don't understand what exactly he mean. I'll try to upload targeted fix to the testing-proposed-updates. > Otherwise we'll be forced to remove monit from > buster manually. I'm fine with this.
Bug#930431: shorewall: overwrite /etc/default/shorewall on update
Package: shorewall
Version: 5.0.15.6-1
Severity: normal
Dear Maintainer,
* What led up to the situation?
Update of the shorewall using apt upgrade
* What exactly did you do (or not do) that was effective (or
ineffective)?
# apt update
# apt upgrade
* What was the outcome of this action?
/etc/default/shorewall was overwritten and startup=1 was replaced with the
startup=0
* What outcome did you expect instead?
/etc/default/shorewall should not be overwritten!
-- System Information:
Debian Release: 9.9
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-9-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages shorewall depends on:
ii bc 1.06.95-9+b3
ii debconf [debconf-2.0] 1.5.61
ii iproute2 4.9.0-1+deb9u1
ii iptables 1.6.0+snapshot20161117-6
ii lsb-base 9.20161125
ii perl 5.24.1-3+deb9u5
ii shorewall-core 5.0.15.6-1
Versions of packages shorewall recommends:
pn libnetfilter-cthelper0
Versions of packages shorewall suggests:
pn make
pn shorewall-doc
-- Configuration Files:
/etc/default/shorewall changed:
startup=1
OPTIONS=""
STARTOPTIONS=""
RELOADOPTIONS=""
RESTARTOPTIONS=""
INITLOG=/dev/null
SAFESTOP=0
/etc/shorewall/shorewall.conf changed:
STARTUP_ENABLED=Yes
VERBOSITY=1
PAGER=
FIREWALL=
BLACKLIST_LOG_LEVEL=
INVALID_LOG_LEVEL=
LOG_BACKEND=
LOG_MARTIANS=Yes
LOG_VERBOSITY=2
LOGALLNEW=
LOGFILE=/var/log/messages
LOGFORMAT="Shorewall:%s:%s:"
LOGTAGONLY=No
LOGLIMIT=
MACLIST_LOG_LEVEL=info
RELATED_LOG_LEVEL=
RPFILTER_LOG_LEVEL=info
SFILTER_LOG_LEVEL=info
SMURF_LOG_LEVEL=info
STARTUP_LOG=/var/log/shorewall-init.log
TCP_FLAGS_LOG_LEVEL=info
UNTRACKED_LOG_LEVEL=
ARPTABLES=
CONFIG_PATH="${CONFDIR}/shorewall:${SHAREDIR}/shorewall"
GEOIPDIR=/usr/share/xt_geoip/LE
IPTABLES=
IP=
IPSET=
LOCKFILE=
MODULESDIR=
NFACCT=
PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin"
PERL=/usr/bin/perl
RESTOREFILE=restore
SHOREWALL_SHELL=/bin/sh
SUBSYSLOCK=""
TC=
ACCEPT_DEFAULT=none
DROP_DEFAULT=Drop
NFQUEUE_DEFAULT=none
QUEUE_DEFAULT=none
REJECT_DEFAULT=Reject
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'
RSH_COMMAND='ssh ${root}@${system} ${command}'
ACCOUNTING=Yes
ACCOUNTING_TABLE=filter
ADD_IP_ALIASES=No
ADD_SNAT_ALIASES=No
ADMINISABSENTMINDED=Yes
AUTOCOMMENT=Yes
AUTOHELPERS=Yes
AUTOMAKE=No
BASIC_FILTERS=No
BLACKLIST="NEW,INVALID,UNTRACKED"
CHAIN_SCRIPTS=Yes
CLAMPMSS=No
CLEAR_TC=Yes
COMPLETE=No
DEFER_DNS_RESOLUTION=Yes
DELETE_THEN_ADD=Yes
DETECT_DNAT_IPADDRS=No
DISABLE_IPV6=No
DOCKER=No
DONT_LOAD=
DYNAMIC_BLACKLIST=Yes
EXPAND_POLICIES=Yes
EXPORTMODULES=Yes
FASTACCEPT=No
FORWARD_CLEAR_MARK=
HELPERS=
IGNOREUNKNOWNVARIABLES=No
IMPLICIT_CONTINUE=No
INLINE_MATCHES=No
IPSET_WARNINGS=Yes
IP_FORWARDING=On
KEEP_RT_TABLES=No
LOAD_HELPERS_ONLY=Yes
MACLIST_TABLE=filter
MACLIST_TTL=
MANGLE_ENABLED=Yes
MAPOLDACTIONS=No
MARK_IN_FORWARD_CHAIN=No
MINIUPNPD=No
MODULE_SUFFIX=ko
MULTICAST=No
MUTEX_TIMEOUT=60
NULL_ROUTE_RFC1918=No
OPTIMIZE=0
OPTIMIZE_ACCOUNTING=No
REJECT_ACTION=
REQUIRE_INTERFACE=No
RESTART=restart
RESTORE_DEFAULT_ROUTE=Yes
RESTORE_ROUTEMARKS=Yes
RETAIN_ALIASES=No
ROUTE_FILTER=Yes
SAVE_ARPTABLES=No
SAVE_IPSETS=No
TC_ENABLED=Internal
TC_EXPERT=No
TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2"
TRACK_PROVIDERS=No
TRACK_RULES=No
USE_DEFAULT_RT=Yes
USE_PHYSICAL_NAMES=No
USE_RT_NAMES=No
VERBOSE_MESSAGES=Yes
WARNOLDCAPVERSION=Yes
WORKAROUNDS=No
ZERO_MARKS=No
ZONE2ZONE=-
BLACKLIST_DISPOSITION=DROP
INVALID_DISPOSITION=CONTINUE
MACLIST_DISPOSITION=REJECT
RELATED_DISPOSITION=ACCEPT
RPFILTER_DISPOSITION=DROP
SMURF_DISPOSITION=DROP
SFILTER_DISPOSITION=DROP
TCP_FLAGS_DISPOSITION=DROP
UNTRACKED_DISPOSITION=CONTINUE
TC_BITS=
PROVIDER_BITS=
PROVIDER_OFFSET=
MASK_BITS=
ZONE_BITS=0
-- debconf information:
shorewall/major_release:
shorewall/dont_restart:
shorewall/invalid_config:
Bug#927775: monit: CVE-2019-11454 CVE-2019-11455
On Sun, Jun 09, 2019 at 01:44:18PM +0200, Salvatore Bonaccorso wrote: > I gave a reason though now in my previous mail I was expecting such explanation before changing in severity... > > > Could you please work out with the Release team via an unblock request > > > if they would wave through the version or a sheduled a targeted fix > > > via testing-proposed-updates? > > > > Yes, I'm planing backports for these fixes. I don't know why this > > require increase in the bug severity. > > Perfect, thanks! The increase in severity was done as per above, to > make sure it is marked release critical and not missed for the > release of buster. > > I still do not get it why a new upstream version was uploaded to > unstable at this point in the freeze, though. I hope, release team will unblock transition, it's a bugfix release.
Bug#927775: monit: CVE-2019-11454 CVE-2019-11455
On Sun, Jun 09, 2019 at 12:08:21PM +0200, Salvatore Bonaccorso wrote: > After some time passed, on 2019-06-03, another Debian security team > member (Moritz Muehlenhoff ) raised the severity to a > release critical value. For no reasons. > Could you please work out with the Release team via an unblock request > if they would wave through the version or a sheduled a targeted fix > via testing-proposed-updates? Yes, I'm planing backports for these fixes. I don't know why this require increase in the bug severity.
Bug#927775: monit: CVE-2019-11454 CVE-2019-11455
severity 927775 important thanks No reasons, so revert back severity. On Tue, 4 Jun 2019 08:00:43 +0300 Sergey B Kirpichev wrote: > On Tue, 23 Apr 2019 06:53:03 +0200 Salvatore Bonaccorso > wrote: > > CVE-2019-11454[0]: > > | Persistent cross-site scripting (XSS) in http/cervlet.c in Tildeslash > > | Monit before 5.25.3 allows a remote unauthenticated attacker to > > | introduce arbitrary JavaScript via manipulation of an unsanitized user > > | field of the Authorization header for HTTP Basic Authentication, which > > | is mishandled during an _viewlog operation. > > > > > > CVE-2019-11455[1]: > > | A buffer over-read in Util_urlDecode in util.c in Tildeslash Monit > > | before 5.25.3 allows a remote authenticated attacker to retrieve the > > | contents of adjacent memory via manipulation of GET or POST > > | parameters. The attacker can also cause a denial of service > > | (application outage). > > Why severity "grave"? Seems wrong accordingly to the > description in https://www.debian.org/Bugs/Developer#severities. > >
Bug#927775: monit: CVE-2019-11454 CVE-2019-11455
On Tue, 23 Apr 2019 06:53:03 +0200 Salvatore Bonaccorso wrote: > CVE-2019-11454[0]: > | Persistent cross-site scripting (XSS) in http/cervlet.c in Tildeslash > | Monit before 5.25.3 allows a remote unauthenticated attacker to > | introduce arbitrary JavaScript via manipulation of an unsanitized user > | field of the Authorization header for HTTP Basic Authentication, which > | is mishandled during an _viewlog operation. > > > CVE-2019-11455[1]: > | A buffer over-read in Util_urlDecode in util.c in Tildeslash Monit > | before 5.25.3 allows a remote authenticated attacker to retrieve the > | contents of adjacent memory via manipulation of GET or POST > | parameters. The attacker can also cause a denial of service > | (application outage). Why severity "grave"? Seems wrong accordingly to the description in https://www.debian.org/Bugs/Developer#severities.
Bug#868164: systemd: fakeraid + cryptsetup (root) + lvm results in 90s time out waiting for device at boot
Please ignore information about start of debian9 before /var mount in my previous message. It was caused by strange config possibly kept from Jessie (/etc/systemd/system/bind9.service.d/override.conf). After removing it, bind starts after /var mount. Best regards, Sergey Belyashov
Bug#902997: pulseaudio: every other time sound card does not get loaded
Problem still presisit. pulseaudio version 12.2.
Bug#926505: hunspell: add dictionary russian with strict yo
Oh, ok then. I'll try to contact the original authors. -- Best regards, S.V. Matsievskiy On Sat, 2019-04-06 at 12:16 +0200, Mattia Rizzolo wrote: > On Sat, Apr 06, 2019 at 01:11:32PM +0300, Sergey wrote: > > I actually wanted it to be hunspell-ru-yo because I wanted this > > dictionary not only for libreoffice, but for emacs as well. > > Sure. Note that all of the hunspell-* packages that you see, with > the > exception of hunspell-en-us and very few others, all come from that > libreoffice big pack. > > It's just for ease of maintenance (it's much easier to keep those > more > that hundred dictionaries together than split them…) that I tend to > prefer it be bundled there, instead of making a separate *source* > package. If it gets into libreoffice-dictioanries, then you'll also > have a separate binary package named hunspell-ru-yo (or whatever > suffix > will be picked), just like, for example, hunspell-de-de-frami (which > is > a variant of hunspell-de-de). >
Bug#926505: hunspell: add dictionary russian with strict yo
I actually wanted it to be hunspell-ru-yo because I wanted this dictionary not only for libreoffice, but for emacs as well. -- Best regards, S.V. Matsievskiy On Sat, 2019-04-06 at 11:53 +0200, Mattia Rizzolo wrote: > Control: reassign -1 src:libreoffice-dictionaries 1:6.2.0-1 > > On Sat, Apr 06, 2019 at 11:13:22AM +0300, Matsievskiy S.V. wrote: > > Russian dictionaries come in two flavors: with and without strict > > yo (ё). > > hunspell-ru provides dictionary without strict yo. > > > > There is a hunspell-ready russian dictionary with strict yo > > available here: > > https://extensions.libreoffice.org/extensions/russian-dictionary-pack > > The archive contains .dic and .aff files; it is licensed under > > LGPL. > > > > Please, add a package for it. It may be named something like > > hunspell-ru-yo. > > This should either be a completely new source package, or be into > libreoffice-dictioanries (which is probably best). > > For the latter case, you may ask on > https://bugs.documentfoundation.org/enter_bug.cgi?product=LibreOffice > (use "linguistic" as a component) asking them to include that > particular > dictionary in the pack. > > I'm not sure on what would be the best name for this particular > dictionary, ru-yo or whatever. Also, it would be best if you could > loop > the original authors of that dictionary, there is a link to a Russian > forum in that extension page: maybe they would also like to end up in > the official dictionary pack of LibreOffice... >
Bug#925078: sgt-puzzles: Please update package from fresh upstream.
Package: sgt-puzzles Version: 20170606.272beef-1 Severity: wishlist Dear Maintainer, Please update the package with fresh upstream version. Most reposted bugs are already fixed in upstream, especially https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852146. This bug prevents playing some puzzles on hard levels. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sgt-puzzles depends on: ii libatk1.0-0 2.30.0-2 ii libc62.28-8 ii libcairo-gobject21.16.0-3 ii libcairo21.16.0-3 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-1 ii libgtk-3-0 3.24.5-1 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 Versions of packages sgt-puzzles recommends: ii google-chrome-stable [www-browser] 73.0.3683.75-1 sgt-puzzles suggests no packages. -- no debconf information
Bug#918806: [bug-mailutils] version 3.5: mail/mailx discard message body when attachment is supplied
Hi Daniel, > Are you aware of this report in debian about mail discarding stdin when > being used to send an e-mail with an attachment? > > https://bugs.debian.org/918806 Thanks for reporting. I fixed it in 43214185092e714e0c233bf196f571bba5c17be0. Meanwhile, you can use the --mime option as a workaround: echo "body text" | /usr/bin/mail --mime -s "some subject" -A "somefile.csv" m...@email.com Regards, Sergey
Bug#923609: Binary incompatibility in libgdbm6
Hi Dmitry,
> Thank you, Sergey. Does incompatibility goes other way too, that version
> without LFS support is incapable of reading file, created with LFS
> version?
Yes, as the accompanying NOTE-WARNING file says:
Gdbm files have never been `portable' between different operating
systems, system architectures, or potentially even different compilers.
Differences in byte order, the size of file offsets, and even structure
packing make gdbm files non-portable.
(btw, this file seems not to be included in the Debian package, perhaps
it makes sense to do so).
> I consider providing statically-linked, LFS-disabled version of
> gdbm_{load,dump,tool}, so user with database, created on stretch could
> do `gdbm_dump old.gdbm | gdbm_load new.gdbm'. Opinions?
That's nice idea. I'm all for it.
Best regards,
Sergey
Bug#923609: Binary incompatibility in libgdbm6
Hello, Investigation of the attached file has shown that it has been created by gdbm 1.8.3 compiled without large file support (sizeof(off_t) == 4). In contrast, gdbm 1.18.1 was compiled with large file support enabled, which naturally lead to the observed behavior. Recompile it with the --disable-largefile flag and it will be able to read the file. Regards, Sergey
Bug#902204: monit: spurious "monit alert -- Link up eth0" messages
tags 902204 -moreinfo
thanks
On Sat, 22 Dec 2018 03:17:27 +0100 Vincent Lefevre wrote:
> So, it seems to be a bug in the monit code that makes it think that
> the link is up while it is not.
>
> In validate.c, I see:
>
> [...]
> for (LinkStatus_T link = s->linkstatuslist; link; link = link->next) {
> Event_post(s, Event_Link, State_Succeeded, link->action,
> "link data collection succeeded");
> }
> // State
> if (! Link_getState(s->inf.net->stats)) {
> for (LinkStatus_T link = s->linkstatuslist; link; link =
> link->next)
> Event_post(s, Event_Link, State_Failed, link->action,
> "link down");
> return State_Failed; // Terminate test if the link is down
> } else {
> for (LinkStatus_T link = s->linkstatuslist; link; link =
> link->next)
> Event_post(s, Event_Link, State_Succeeded,
> link->action, "link up");
Ok, CC upstream to see their opinion (I think this problem wasn't reported yet.)
Bug#919645: RFS: monit/1:5.25.2-2~bpo9+1 [BPO]
Package: sponsorship-requests Severity: normal I (current maintainer of the package) am looking for (6 or 7-th time?) a sponsor for my backport of the package monit. Package can be downloaded from m.d.n: https://mentors.debian.net/package/monit
Bug#887350: monit: Request for a monit backport
On Mon, 24 Dec 2018 17:13:17 +0100 Antoine Joubert wrote: > I wanted to let you know that I’ve not had any issues with your backport of > monit over the week-end. Ok, I've requested (rt.debian.org ticket #7591) upload permissions for backports queue, instead of asking 6 (or 7th) time for sponsorship. No idea how long it will take, but then I'll upload package.
Bug#885224: nlopt: please migrate to guile-2.2
On Fri, 6 Jul 2018 15:29:48 +0200 Andreas Tille wrote:
> I've checked this by simply replacing Build-Depends like this:
>
>
> diff --git a/debian/control b/debian/control
> index 600f8f1..ba9335d 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -9,8 +9,8 @@ Build-Depends: debhelper (>= 11~),
> dh-octave,
> python-all-dev,
> python-numpy,
> - guile-2.0,
> - guile-2.0-dev,
> + guile-2.2,
> + guile-2.2-dev,
> dh-exec
> Standards-Version: 4.1.4
> Vcs-Browser: https://salsa.debian.org/science-team/nlopt
> @@ -175,7 +175,7 @@ Section: libs
> Depends: libnlopt0 (= ${binary:Version}),
> ${shlibs:Depends},
> ${misc:Depends},
> - guile-2.0
> + guile-2.2
> Pre-Depends: ${misc:Pre-Depends}
> Description: nonlinear optimization library -- Guile bindings
> NLopt is a free/open-source library for nonlinear optimization, providing
>
>
> Unfortunately this does not work and leads to build errors. Some
> patches would be welcome.
I suspect, this is fixed in newer version, published
on Github. I'll try to adapt package to build nlopt-2.5.0 (there
are some major changes like changing build system to cmake).
Bug#917109: opensc: Rutoken ECP card not work after upgrade
Package: opensc Version: 0.16.0-3+deb9u1 Severity: normal After upgrading opensc-0.16.0-3, opensc-pkcs11-0.16.0-3 to opensc-0.16.0-3+deb9u1, opensc-pkcs11-0.16.0-3+deb9u1 "Rutoken ECP" token not work: $ pkcs11-tool -L Available slots: Slot 0 (0x0): Aktiv Rutoken ECP 00 00 token state: uninitialized Card shows as uninitialized, but it was initizalied. Before upgrading card was working. After downgrading opensc, opensc-pkcs11 packages card also is working: $ pkcs11-tool -L Available slots: Slot 0 (0x0): Aktiv Rutoken ECP 00 00 token label: Rutoken ECP (User PIN) token manufacturer : Aktiv Co. token model: PKCS#15 token flags: rng, login required, PIN initialized, token initialized hardware version : 0.0 firmware version : 0.0 serial num : X
Bug#917025: tracker.debian.org: 0 new commits since last upload
Package: tracker.debian.org Severity: normal Not sure if this is a duplicate of #910987, but I see the problem. Right now interface on https://tracker.debian.org/pkg/monit shows: -->8-- action needed 0 new commits since last upload, time to upload? normal vcswatch reports that this package seems to have a new changelog entry (version 1:5.25.2-2, distribution unstable) and new commits in its VCS. You should consider whether it's time to make an upload. Here are the relevant commit messages: None Created: 2018-12-21 Last update: 2018-12-21 15:05 -->8--- Latest commit is 727f110b (tagged then, after several minutes, everything was pushed to the public repo _before_ upload to the debian archive was done).
Bug#902204: monit: spurious "monit alert -- Link up eth0" messages
On Fri, Dec 21, 2018 at 01:31:40PM +0100, Vincent Lefevre wrote: > > > > monit is spamming me with spurious "monit alert -- Link up eth0" > > > > messages every 2 minutes! I currently have no Ethernet cable, so > ^ > > > > that "Link up eth0" is wrong, and there are no recent lines about >^^^ > > > > eth0 in the journalctl output. > > > > Please, show /proc/net/dev on system, which is spamming. > > Inter-| Receive| Transmit > face |bytespackets errs drop fifo frame compressed multicast|bytes > packets errs drop fifo colls carrier compressed > eth0: 956331421 927630000 0 0 5275 101028194 > 623527000 0 0 0 > > > > [CEST Jun 23 12:19:47] info : 'eth0' link data collection succeeded > > > [CEST Jun 23 12:19:47] error: 'eth0' link down > > > > It seems, you have an interface with cable unplugged. > > Yes, as said above. Ok, I see, thank you for patience. Does it send you alert if you remove "if changed link capacity then alert" line too, correct? If so, I suspect that the currect monit's behaviour is correct and I suggest you just adding "if failed link then unmonitor"-like line.
Bug#890683: monit: Invalid CSRF Token error on web interface
BTW, backport issue is here: https://bugs.debian.org/887350 Backport was uploaded to mentors: https://mentors.debian.net/package/monit On Fri, 21 Dec 2018 11:26:18 +0300 Sergey B Kirpichev wrote: > tag 890683 + upstream > thanks > > On Sat, 17 Feb 2018 18:28:37 +0100 Peter Baranyi > wrote: > > I am always getting this error when clicking start/stop/restart/disable > > buttons > > on the web interface: > > Invalid CSRF Token > > This makes the web interface read-only, actions cannot be carried out. > > This error is already fixed in sid, version 1:5.25.1-1 > > I think, that the problem is fixed in > https://bitbucket.org/tildeslash/monit/issues/495/invalid-csrf-check > > So, everything should work in stable, if you will use a dedicated > domain for the web interface. Let me know if this workaround doesn't > work. > > For now, I don't think that issue is severe enough and there will > be port of this fix to stable. I hope, monit's backport will be available > soon, so you can try it. > >
