Hi,
The uploads are done, but the testing migration of pacemaker and pcs
probably deadlocked due to the autopkgtest of the latter. Unstable pcs
needs unstable pacemaker, so they can only go together, which may need
manual intervention on your part.
Furthermore, it may be prudent to take dlm
Sam Hartman writes:
> Don't wait for me on shibboleth-resolver or moonshot-gss-eap to file the
> removal requests.
> They are both basically broken in unstable, so there's no reason to
> block.
Hi,
Removal requests filed.
Please let me know if you need any help; for example I can see that
Giovanni Mascellani writes:
> Some test timeouts are currently too small for architecture riscv64,
> which is built on rather slow QEMU virtual machines. This patch
> increases the timeout, so that automated building does not fail.
Hi Giovanni,
I notice the latest build of 1.0.3-2 succeeded on
Andreas Henriksson writes:
> The package currently fails to build reproducibly on a merged-usr vs
> non-merged system. This is caused by looking up the full path of
> bash via PATH and embedding it in a shipped file.
>
> The problem can be easily fixed by explicitly telling configure
> which
Control: tags -1 - moreinfo
Niels Thykier writes:
> Please go ahead with the upload and remove the moreinfo tag when it is
> ready for unblocking.
Hi, opensaml 3.0.1-1 is already in unstable, ready for unblocking.
--
Thanks,
Feri
On Tue, 26 Mar 2019 11:29:29 +0100 =?utf-8?q?Ferenc_W=C3=A1gner?=
wrote:
> Debhelper compat level 12 is stable and available in stretch-backports,
> but uses the --skip-systemd-native option of invoke-rc.d, thus adds
> init-system-helpers (>= 1.54~) to misc:Pre-Depends. This is necessary
> to
Felipe Sateler writes:
> I'm not opposed to a backport, and I don't think there are many
> problems with attempting it. However, I do not have time to prepare
> and test such a backport. Help welcome.
I can do the busy-work of backporting, but I lack the perspective to
tell whether it's
Michael Biebl writes:
> Personally I prefer to revert the compat bumps when doing backports for
> stretch (like in [1]) as I like to to keep the impact on the stable
> system as minimal as possible. Pulling in a newer i-s-h is a rather
> significant change.
I see. Dropping back to compat 10
Control: reassign 925978 src:shibboleth-sp
Control: forwarded 925978 https://issues.shibboleth.net/jira/browse/SSPCPP-731
Control: tags 925978 + upstream
Control: fixed 925978 3.0.2+dfsg1-1
Matt Weatherford writes:
> This continues to happen, but is easy to manually clear up so low
>
Niels Thykier writes:
> I don't think I have much to add to it really beyond what is covered in
> https://nthykier.wordpress.com/2019/01/04/debhelper-compat-12-is-now-released/
Thanks for the good writeup, I missed it.
> Sure it would be great to have one less caveat for upgrating to compat
>
Valentin Vidic writes:
> On Mon, Mar 25, 2019 at 03:45:58PM +0100, Andreas Beckmann wrote:
>
>> In that case you should probably add Breaks+Replaces against all of the
>> old -dev packages that were merged, just to be on the safe side.
>
> Yes, that is the plan. I th
control: tags -1 -moreinfo
Dmitry Bogatov writes:
> Sorry, I do not understand. You, as init script writer, choose value of
> argument to $NAME. Why can't you limit it to required length?
Sorry, I indeed left out important context, thus even I had difficulty
recalling the reason for my report
Alejandro Claro writes:
> We found a bug in Apache Santuario C, related to ECDSA signature
> generation, few years ego. We provide the fix to the Apache team, and
> Scott Cantor kindly accepted the fix in the project. How ever the fix
> was introduced in series 2.x of the the library.
Dear
Hi,
Is the g++ dependency of the main game binary intentional?
I built the game for stretch, it went OK (after reducing the debhelper
compatibility level to 11, but that isn't a problem). The game starts,
but I'm unable to select a map: the presented list is empty, though
strace shows it finds
Paul Gevers writes:
> I propose you let 2.0.1~rc5-1 migrate to testing
Hi Paul,
OK, this is what Niels suggested as well (I think).
> upload 2.0.1-1 to unstable after that
Without a definite ACK from you?
> provide us with a debdiff between 2.0.1~rc5-1 and 2.0.1-1 in this bug
> report
Dmitry Bogatov writes:
> What about this patch? Would it satisfy your need?
Perfectly. The extra braces (${COMMAND_NAME}, ${NAME}) look somewhat
alien, but as you prefer.
> Can you please review wording -- I am very bad at writing manpages.
I'm no native speaker either, but inserted a couple
Emilio Pozuelo Monfort writes:
> The diff looks fine, please go ahead with 3.0.4-1.
Uploaded, thanks!
--
Feri
Salvatore Bonaccorso writes:
> On Sat, Mar 09, 2019 at 07:25:52PM +0100, wf...@niif.hu wrote:
>
>> I reserved a CVE from Mitre, backported the probable patch to
>> xmltooling 1.6.0-4+deb9u1 in stable and prepared a tentative package
>> with it, please see the debdiff below. I plan to add more
Control: tags -1 - moreinfo
Jonathan Wiltshire writes:
> On Tue, Mar 05, 2019 at 09:45:26AM +0100, Paul Gevers wrote:
>
>> I propose you let 2.0.1~rc5-1 migrate to testing, upload 2.0.1-1 to
>> unstable after that, provide us with a debdiff between 2.0.1~rc5-1 and
>> 2.0.1-1 in this bug report
Control: tag -1 - moreinfo
Jonathan Wiltshire writes:
> Please go ahead and remove the moreinfo tag when it is ready to unblock.
Thanks, uploaded. Looks like Niels has already unblocked it, but I'm
removing the moreinfo tag nevertheless.
--
Regards,
Feri
Moritz Muehlenhoff writes:
> On Tue, Mar 12, 2019 at 10:19:00AM +0100, wf...@niif.hu wrote:
>
>> The resulting packages works fine in my setup. However, I failed to
>> reproduce the original issue under stretch. After consulting upstream,
>> it turns out that the old Xerces library actually
Dear Release Team,
I sponsored the late upload of 4.5.1.1-1, please let me try to make up
for that by providing some more information (hopefully) in favor of the
unblock.
First of all, the Docker changes, which are the biggest part of the src
debdiff, do not affect the binary package at all,
"Debian Bug Tracking System" writes:
> libgphoto2 (2.5.22-3) unstable; urgency=medium
> .
>* debian/patches:
>- Upstream patch to disable 9280 call on exit
> (Closes: #922379)
I confirm that a straightforward backport of 2.5.22-3 works fine with my
camera.
--
Thanks much
Andre Noll writes:
> I also had to override dh_autoreconf for reasons explained in the
> commit message.
It isn't a packaging issue, I just wonder: why do you wrap configure?
The usual approach to making it available is distributing it (and not
requiring Autoconf to build the software from the
On Wed, 24 Apr 2019 17:50:02 +0200 wf...@niif.hu wrote:
> On Mon, 22 Apr 2019 09:07:04 +0200 Salvatore Bonaccorso
> wrote:
>
>>> Please see https://www.openwall.com/lists/oss-security/2019/04/17/1
>>
>> Please note that when fixing the issues, in the original patchsets
>> there were some
Dear Security Team,
I'm ready to upload libqb-1.0.1-1+deb9u1 with the following debdiff:
diff -Nru libqb-1.0.1/debian/changelog libqb-1.0.1/debian/changelog
--- libqb-1.0.1/debian/changelog2016-12-07 14:55:45.0 +0100
+++ libqb-1.0.1/debian/changelog2019-06-16
Valentin Vidić writes:
> On Mon, Jun 24, 2019 at 02:03:11PM +0200, wf...@niif.hu wrote:
>
>> According to https://security-tracker.debian.org/tracker/CVE-2019-10153,
>> the vulnerable code is not present in stretch. However, I don't
>> understand why this does not count:
>>
>>
Niko Tyni writes:
> I've reported this upstream with the attached proposed patch.
Hi Niko,
I tried to apply the Radius.pm part to the installed package, but it
failed at first due to a whitespace error: the installed file is
indented with TAB characters, not spaces like your patch. After
Moritz Muehlenhoff writes:
> Please see https://bugzilla.redhat.com/show_bug.cgi?id=1716286
Hi Moritz,
According to https://security-tracker.debian.org/tracker/CVE-2019-10153,
the vulnerable code is not present in stretch. However, I don't
understand why this does not count:
gregor herrmann writes:
> Upstream has now closed the CPAN RT ticket and released a 0.31
> version which fixes the issue (differently).
>
> I've "backported" the fix (i.e. took most of the 0.31 diff and added
> it as a quilt patch) and pushed it to git. For convenience I'm also
> attaching the
Commenting out the offending conditional die() in
/usr/share/perl5/Authen/Radius.pm:865 restores the expected behavior.
On the other hand, loading dictionary.rfc2865 does not make any difference.
--
Regards,
Feri
On Mon, 22 Apr 2019 09:07:04 +0200 Salvatore Bonaccorso
wrote:
>> Please see https://www.openwall.com/lists/oss-security/2019/04/17/1
>
> Please note that when fixing the issues, in the original patchsets
> there were some behaviour regressions, I think they should be adressed
> in the
I can transfer files to my computer only if "Accept files from trusted
devices" in "Transfer Settings" in the "Local Services" dialog is
*unchecked*. Otherwise the accept dialog does not appear on incoming
transfers, and in 40 seconds the transfer eventually times out with
FORBIDDEN(0x43). The
Hi,
I'm also getting such messages since the buster upgrade:
Message from syslogd@lant at Aug 26 20:05:12 ...
kernel:[686221.093605] do_IRQ: 1.52 No irq handler for vector
Message from syslogd@lant at Aug 27 01:03:12 ...
kernel:[704101.075251] do_IRQ: 1.43 No irq handler for vector
--
Valentin Vidić writes:
> The updated for stable is a bit more tricky because:
>
> https://www.debian.org/doc/manuals/developers-reference/ch05.html#upload-stable
> "Basically, a package should only be uploaded to stable if one of the
> following
> happens:
>
> * a truly critical functionality
-timesyncd.service(8)
While man systemd.unit says that "the unit that conflicts will be
started and the unit that is conflicted is stopped", this doesn't always
work out as expected. From the syslog of the last two reboots:
wferi@noc7:~$ zegrep "Network Time|Reached target" /var/log
A random observation: the segmentation fault happens after outputting
4096 bytes to the test log. It may be related to stdio buffering and
thus it may never appear with line buffered output.
Control: tag -1 - moreinfo
On Wed, 11 Apr 2018 10:08:25 -0700 Ryan Tandy wrote:
> On Wed, Apr 11, 2018 at 06:41:08PM +0200, Ferenc Wágner wrote:
>
>> slapd[4515]: segfault at 4c ip 7f71abdbfc9b sp 7f716f184780 error 4
>> in back_mdb-2.4.so.2.10.7[7f71abdb+39000]
>
> Not familiar
Ryan Tandy writes:
> With your coredump, could you dig a little further into the two
> "sml_mod" structures and show their sm_desc/sm_values/sm_nvalues?
Sure:
(gdb) p *modlist->sml_mod.sm_desc
$8 = {ad_next = 0x0, ad_type = 0x5652a198da20, ad_cname = {bv_len = 3, bv_val =
0x5652a198d900
Hi,
Sadly, it looks like Dima Barksy, the maintainer, isn't around any more.
Is anybody interested in salvaging this package? (Both in the sense of
keeping it around after the Python 2 removal in bullseye and in that of
https://wiki.debian.org/PackageSalvaging.)
--
Regards,
Feri
"Adam D. Barratt" writes:
> On Sun, 2020-02-02 at 12:46 +0100, Ferenc Wágner wrote:
>
>> +corosync (3.0.1-2+deb10u1) buster; urgency=medium
>> +
>> + * [f826af9] This branch is for buster updates
>
> That doesn't really belong in the package changelog.
Agreed.
>> + * [bfbfd3e] New patch:
On Mon, 2 Jul 2018 12:10:34 +0200 Paul Gevers wrote:
> On Sat, 21 Apr 2018 12:15:28 +0200 =?utf-8?q?Ferenc_W=C3=A1gner?=
> wrote:
>
>> --- /usr/bin/autopkgtest-build-lxc 2018-04-18 10:44:36.0 +0200
>> +++ /home/wferi/autopkgtest-build-lxc2018-04-
On Tue, 28 Jan 2020 08:42:50 + "Adam D. Barratt"
wrote:
> On 2020-01-12 14:39, Ferenc Wágner wrote:
>
>> +xml-security-c (1.7.3-4+deb9u2) stretch; urgency=medium
>> +
>> + * [12dd825] New patches: DSA verification crashes OpenSSL on invalid
>> +combinations of key content.
>> +
On Wed, 29 Jan 2020 12:24:36 +0100 =?utf-8?q?Ferenc_W=C3=A1gner?=
wrote:
> I'm looking for guidance first: I'd like to fix #950135 (libxmltooling8:
> Race condition bug in new session cookie feature leads to SP crash) in
> buster.
> [...]
> Upstream cut a new release (3.0.5) for this fix
"Adam D. Barratt" writes:
> On Fri, 2020-01-31 at 23:30 +0100, wf...@niif.hu wrote:
>
>> +xmltooling (3.0.4-1+deb10u1) buster; urgency=medium
>> +
>> + * [7c6eb12] This branch is for buster updates
>> + * [97e580e] New patch: CPPXT-145 - DataSealer is sharing non-
>> thread safe keys.
>
>
Hi,
Don't you think #873057 is actually the same issue discovered with ntp?
Please consider merging it in if you agree.
--
Thanks,
Feri
Helmut Grohne writes:
> On Wed, Nov 27, 2019 at 11:58:53PM +, Sandro Tosi wrote:
>
>> - Convert your Package to Python3. This is the preferred option.
>
> Upstream here. While tcvt started on Python2, much of its development
> actually happend on Python3, so just changing the #! should work.
wf...@niif.hu writes:
> Helmut Grohne writes:
>
>> On Wed, Nov 27, 2019 at 11:58:53PM +, Sandro Tosi wrote:
>>
>>> - Convert your Package to Python3. This is the preferred option.
>>
>> Upstream here. While tcvt started on Python2, much of its development
>> actually happend on Python3, so
Hi,
I'd like to upload the new versions of gphoto2 and libgphoto2 to fix
this migration bug (and to make use of them in qstopmotion). If you
agree, please accept my membership request on Salsa and I'll go ahead.
--
Thanks,
Feri
"Debian Bug Tracking System" writes:
> - set ReadOnlyDirectories to the configuration (Closes: #955206)
Well, not very transparent or general, but certainly address my main
concern. However, the file ownerships still send the wrong message to
me. Could you please explain why the configuration
Hi,
Just noting that according to #956146 "the bullseye toolchain defaults
to linking with --as-needed", so this won't hurt us so bad in the
future.
--
Feri
Control: tags -1 - moreinfo
"Adam D. Barratt" writes:
> Apologies for not replying sooner.
No problem. I was starting to accept that my request was so outlandish
that it didn't even warrant a reply. :)
> On Sun, 2020-02-02 at 14:47 +0100, Ferenc Wágner wrote:
>> I'v got a bold request:
On Wed, 19 Aug 2020 14:04:15 -0700 Steve Langasek
wrote:
> In Ubuntu, we have moved the i386 architecture to a compatibility-only layer
> on amd64, and therefore we are also moving our autopkgtest infrastructure to
> test i386 binaries in a cross-environment.
>
> This requires changes to some
Control: tags 971427 - moreinfo
"Chris Lamb" writes:
>> SNMP MIB files are generally /usr/share/snmp/mibs/*.txt, though
>> these text files aren't documentation. Please make them exempt
>> from package-contains-documentation-outside-usr-share-doc.
>
> Totally ACK that these are
"Adam D. Barratt" writes:
> Please go ahead, bearing in mind that the window for getting fixes into
> the final stretch point release closes this weekend.
Thanks, uploaded.
--
Feri
Alberto Gonzalez Iniesta writes:
> Hi, again. After some days with libknet1=1.16-2, I'm still getting
> errors from time to time (less than with buster's libknet1):
> Jun 22 01:16:54 selma corosync[28610]: [KNET ] link: host: 1 link: 0 is
> down
> Jun 22 01:16:54 selma corosync[28610]:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964244
wf...@niif.hu writes:
> We'd be immensely grateful for your input on this matter, since your
> position more or less determines how we can plan to support the HA users
> in Debian. We'd still prefer a stable update (either to 1.13 as in the
> original request or to a more recent stable release),
Control: found -1 5.5.0-0.bpo.2-amd64
I started to see this problem after upgrading from 5.4.0-0.bpo.4-amd64
to 5.5.0-0.bpo.2-amd64. It goes like:
[21825.096887] rtw_pci :04:00.0: start vif dc:f5:05:54:f6:0d on port 0
[21829.406272] wlo1: authenticate with 38:43:7d:8a:89:0e
[21829.914017]
Dear Stable Release Team,
We'd be immensely grateful for your input on this matter, since your
position more or less determines how we can plan to support the HA users
in Debian. We'd still prefer a stable update (either to 1.13 as in the
original request or to a more recent stable release), but
Control: severity -1 serious
Yavor Doganov writes:
> Thanks; I'll fix this shortly -- the upload will depend on my sponsor
> though. Meanwhile, feel free to upload libgphoto2 whenever you like
> and raise the severity of this bug to serious.
Did so, thanks. I'm willing to sponsor your upload
Yavor Doganov writes:
> wf...@niif.hu wrote:
>
>> Yavor Doganov writes:
>>
>>> Thanks; I'll fix this shortly -- the upload will depend on my sponsor
>>> though. Meanwhile, feel free to upload libgphoto2 whenever you like
>>> and raise the severity of this bug to serious.
>>
>> Did so,
Florian Best writes:
> I would be interested in maintaining this package.
Great! Do you happen to know the upstream project for this software?
The single upstream version ever uploaded to Debian is 0.4.2 from 1999.
It could be useful to know if upstream moved on, the project was
replaced by
On Mon, 21 Dec 2020 09:45:24 +0100 Matthias Klose wrote:
> will try to get an archive test rebuild done.
Hi,
Lucas did an archive rebuild with a beta release, see
https://lists.gnu.org/archive/html/autoconf/2020-09/msg00027.html
(Just in case you didn't notice.)
--
Regards,
Feri
On Mon, 15 Jun 2020 15:23:28 -0700 Felix Lechner
wrote:
> Hi Russ,
>
>> I wonder if we would get all of the utility out of the tag if instead it
>> looked for shared libraries with no NEEDED metadata.
Doesn't shared-lib-without-dependency-information check for that?
>> I think it's only
Sebastian Ramacher writes:
> On 2021-01-05 10:47:56 +0100, Ferenc Wágner wrote:
>
>> I'd like to do successive sourceful uploads for these (the updated
>> packages are already in experimental). The two other impacted
>> packages build fine without any change: shibboleth-resolver and
>>
Michael Biebl writes:
> On Mon, 09 Nov 2020 00:40:31 +0100 =?utf-8?q?Ferenc_W=C3=A1gner?=
> wrote:
>
>> I was surprised that a daemon start failure during install did not stop
>> dpkg from exiting with a successful exit status. After much digging I
>> found
Bill Blough writes:
> I've uploaded xalan 1.12 to unstable. If you would like me to NMU
> xml-security-c with the necessary changes (attached to 977568), I would
> be happy to do so.
Hi Bill,
Thanks for the patch, I included it in the xml-security-c 2.0.2-4
upload.
--
Regards,
Feri
Moritz Mühlenhoff writes:
> On Sat, Nov 07, 2020 at 08:56:38PM +0100, wf...@niif.hu wrote:
>
>> I propose a security upload with the debdiff below. The patch series
>> posted by upstream against 2.0.3 applies cleanly to the buster source,
>> and is hereby included. I'll try to do some testing
14 if you fix those CVEs. Unfortunately I forgot to
upload the prepared package after getting the blessing of the Security
Team, so it slept in my local packaging repo until I noticed it again
importing your 1.1.16-1+deb9u1 upload. Tagged as wferi/1.1.16-1+deb9u1
and pushed to Salsa in case you wan
Control: tag 973254 + patch
Dear Security Team,
I propose a security upload with the debdiff below. The patch series
posted by upstream against 2.0.3 applies cleanly to the buster source,
and is hereby included. I'll try to do some testing while you review.
Regards,
Feri
diff -Nru
On Wed, 6 Jan 2021 22:31:26 +0100 Paul Gevers wrote:
> Do you have any idea why the test would only be failing on this host?
Hi Paul,
Not offhand. It certainly failed to start the Corosync daemon (which
should automatically start after installation, but that's beside the
point). So there's
Sebastian Ramacher writes:
> On 2020-12-26 19:43:53 +0100, Ferenc Wágner wrote:
>
>> I'd like to transition to libqb version 2. The dependency list is
>> fairly short, and mostly contains packages under the HA Team umbrella.
>> The only breakage is caused by symbols file changes, which I'm
Paul Gevers writes:
> On 27-01-2021 22:41, Valentin Vidic wrote:
>
>> On Wed, Jan 27, 2021 at 10:37:56PM +0100, Paul Gevers wrote:
>>
>>> debian@ci-worker-ppc64el-01:~$ sudo cat /etc/lxc/default.conf
>>> # MANAGED WITH CHEF; DON'T CHANGE BY HAND
>>> lxc.net.0.type = veth
>>> lxc.net.0.link =
Andreas kindly provided further refinements for his patch in #985173.
I'll update this stable update request with the new debdiff shortly.
--
Feri
On Wed, 09 Jun 2021 09:17:26 +0200 wf...@niif.hu wrote:
> Andreas kindly provided further refinements for his patch in #985173.
> I'll update this stable update request with the new debdiff shortly.
Here it is:
$ debdiff pacemaker_2.0.1-5+deb10u1.dsc pacemaker_2.0.1-5+deb10u2.dsc
diff -Nru
Salvatore Bonaccorso writes:
> MITRE has assigned CVE-2021-31826 for this issue.
Thanks. I guess you don't want a new security upload for this, but I'll
certainly include it in the changelog of the unstable upload. (And in
the changelog of the next security upload, whenever that happens.)
--
Peter Leipold writes:
> On 5/2/21 2:54 PM, Salvatore Bonaccorso wrote:
>
>> On Sun, Jul 05, 2020 at 01:15:38PM +0200, wf...@niif.hu wrote:
>>
>>> I started to see this problem after upgrading from 5.4.0-0.bpo.4-amd64
>>> to 5.5.0-0.bpo.2-amd64. It goes like:
>>
>> Do you still have the issue
Hi,
Thanks for the timely reminder with all the relevant dates included.
I find this service useful and I'm grateful for it.
--
Feri
Sebastian Ramacher writes:
> Since the new upstream release only fixes the security issue, let's take
> 3.2.2+dfsg1-1.
Thanks, uploaded.
--
Feri
Hi,
The patch in this bug report very much shrinks the window of the
vulnerability, but doesn't close it completely: the file is still
created with default permissions, then chmodded as a separate step.
It's hard, but not impossible to still win the race and open the file
before the chmod,
On Wed, 27 Jan 2021 23:21:08 + Maurizio Cimaschi
wrote:
> it seems that in version 3.0.1 of corosync there's a bug which causes
> unrecoverable splits; it seems that it had been corrected in 3.0.3. Please
> see Github issue #506.
>
> -> https://github.com/corosync/corosync/issues/506
>
>
wf...@debian.org writes:
> Turns out the upstream socket activation code does not include UDP.
> I addressed that in the merge request as well.
For what it's worth, net-snmp upstream merged the patch from
https://github.com/net-snmp/net-snmp/pull/274.
--
Regards,
Feri
Balint Reczey writes:
> On Sun, Mar 14, 2021 at 3:49 PM wrote:
>
>> Debugging suggests that the internal SHA-1 implementation does not work
>> on big-endian architectures. The easy way out is switching to the
>> libcrypto implementation (the package already depends on libssl1.1 and
>> the PAM
Control: reassign -1 libpe-status10 1.1.24-0+deb9u1
Control: severity -1 serious
Thorsten Rehm writes:
> In my opinion the crmsh package should be more strict with the
> pacemaker-cli-utils package
Sorry for not looking into this sooner. What do you mean by being "more
strict"? Does crmsh
Markus Koschany writes:
> Am Freitag, den 26.03.2021, 16:37 +0100 schrieb wf...@niif.hu:
>
>> Thorsten Rehm writes:
>>
>>> In my opinion the crmsh package should be more strict with the
>>> pacemaker-cli-utils package
>>
>> Sorry for not looking into this sooner. What do you mean by being
>>
Hi Andreas,
Sorry for not responding sooner, some mail forwarding problem
intervened. Looks like there's another serious problem with the
security upload breaking the buster upgrade path, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981088. I haven't
asked the Security Team yet, but if
Andreas Beckmann writes:
> According to policy 7.2 you cannot rely on the depends being available
> during purge, only the essential packages are available for sure.
Hi Andreas,
I can't see coturn rely on any of its dependencies during purge, do you?
> (this was observed in a piuparts nodocs
Balint Reczey writes:
> Autopkgtests are failing in CI on s390x due to the following newly added
> tests:
>
> ...
> OK: Y_MD5: correct password accepted
> OK: Y_MD5: incorrect password refused
> FAIL: mysql: correct password refused
> OK: mysql: incorrect password refused
> ...
(It isn't the
Dear Security Team,
Please review the debdiff below for a buster-security upload.
The advisory text changed a little meanwhile, adding credits to Toni
Huttunen, Fraktal Oy for discovering the problem, mentioning the style
sheet spoofing and adding some mitigation tips.
I haven't got a concrete
wf...@niif.hu writes:
> Andreas Beckmann writes:
>
>> According to policy 7.2 you cannot rely on the depends being available
>> during purge, only the essential packages are available for sure.
>
> I can't see coturn rely on any of its dependencies during purge, do you?
Hi Andreas,
Have you
Control: tag 985054 + pending
Andreas Beckmann writes:
> That's something I haven't come across so far ;-) (Conditional usage
> of /usr/share/doc content in postinst, unconditional usage of the
> generated side effect in postrm purge.)
> Please move the bits needed by the package out of
Balint Reczey writes:
> Autopkgtests are failing in CI on s390x due to the following newly added
> tests:
>
> debian/tests/auth:
> ...
> 'mysql': { 'crypt': 2, '323': 'false', 'hash':
> '*1A8A8D8A90F03E8A15D4FFB3FC91A4693F077A84' }, # select
> PASSWORD('foopwd')
> ...
Szia Bálint,
wf...@debian.org writes:
> Craig Small writes:
>
>> Also, how confident are you writing unit files? I can write them but must
>> admit I don't fully understand some of the more exotic features such as
>> socket activation.
>
> My on-hands experience with socket activation is rather limited, but
Moritz Muehlenhoff writes:
> debdiff looks fine, please upload when you had a chance to test it
The updated packages work fine in our infrastructure.
I uploaded the full source package.
--
Thanks,
Feri
Sebastian Ramacher writes:
> The changes look ok. Under the assumption that the upload happens soon,
> please go ahead.
Thank you, uploaded.
--
Regards,
Feri
Felix Lechner writes:
> On Fri, Feb 26, 2021 at 2:36 PM Ferenc Wágner wrote:
>
>> only the first suffix is exempted
>
> Which package triggers the false positive, please? Thank you!
Hi Felix,
The one I created tonight based on the instructions at
Craig Small writes:
> On Fri, 26 Feb 2021 at 23:12, Ferenc Wágner wrote:
>
>> file. If you aren't comfortable with changing the unit files now,
>> shortly before hard freeze, at least enabling support in the daemons
>> would still be very useful and also very easy with the --with-systemd
>>
Adrian Bunk writes:
> Please age package corosync
>
> * [f641780] New patch: stats: fix crash when iterating over deleted keys.
> Cherry-picked from v3.1.4.
> (change by Ferenc Wágner)
>
> autopkgtest for corosync/3.1.2-2: amd64: Pass, arm64: Pass, armhf: Pass,
> i386: Pass, ppc64el: Pass
Niels Thykier writes:
> Unfortunately, I have no intention of acting on this request until the
> tech-ctte has resolved their advice on how they want the /usr-merge
> transition to be resolved (per #995569).
> [...]
> I wish I could provide you with something better, but I am personally
> not
1 - 100 of 105 matches
Mail list logo
