Control: tag -1 pending
Hello,
Bug #1067501 in hipsolver reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: tag -1 pending
Hello,
Bug #1065353 in rocsparse reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: tag -1 pending
Hello,
Bug #1065351 in rocblas reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Hey Cory,
On 2024-02-28 21:16, Cordell Bloor wrote:
> This segfault does seem to be caused by mixing clang-15 and clang-17 in
> the HIP RTC codepath. When libamdhip64 from ROCm 5.6.1 (built with the
> same clang-17 as rocm-compilersupport 6.0+git20231212.4510c28+dfsg-1) is
> used, the segfault
Hi Étienne,
On 2024-02-26 19:29, Étienne Mollier wrote:
> If that helps, the autoremoval timer is reset each time the RC
> critical bug triggering the autoremoval is updated, e.g. when
> reporting an evolution of the situation in a new comment.
thanks for the info! That's incredible useful to
Hi Sebastian,
writing to you as you bumped the severity to 'serious': could the rT
please give us an extension on the autoremoval for this particular bug.
The transition from first-filing-to-serious was unusually short notice,
and caught us in the middle of our own update of the stack.
This
Hi Jeffrey,
On 2023-12-02 11:39, Jeffrey Bencteux wrote:
> Hi,
>
> Both setuid() and setgid() return values are not checked in cron's code used
> to execute user-provided commands:
This issue was reported as CVD-2006-2607 and fixed a long time ago.
Here's the relevant patch:
Version: 5.5.1-1
Closing this bug, as it is invalid. rocrand never failed, according to
the CI logs (even the linked one).
Control: severity -1 important
I'm downgrading this bug, as the suite successfully completed on another
Navi24 device [1]. No longer RC, this should allow migration to testing
again.
Best,
Christian
[1] https://lists.debian.org/debian-ai/2023/10/msg00044.html
Control: tag -1 pending
Hello,
Bug #1052954 in rccl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: tag -1 pending
Hello,
Bug #1052968 in hipcub reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Source: rocfft
Version: 5.5.0-4
Severity: grave
Justification: Can crash the host
autopkgtests for rocfft triggered a soft lockup when run with an 6500 XT
(gfx1034, Navi24).
This is very probably a kernel issue, but I'm filing this bug here until
we have actually identified the root cause, after
Source: rocrand
Version: 5.5.1-1
Severity: serious
The tests from ci.rocm.debian.net failed on gfx1030 [1]. I'm filing this
RC bug to prevent migration to testing.
[1]
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1030/r/rocrand/83/log.gz
Control: tag -1 pending
Hello,
Bug #1045688 in rocm-device-libs reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
On 2023-06-16 17:56, Antonio Terceiro wrote:
> Note that the variable where you inserted a username and password is
> calle debci_amqp_server, and was never supposed to be used for putting a
> password in plain text.
I think this is where the documentation of the --amqp option threw me
off, from
Package: debci
Version: 3.6
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team
Hi,
When using authentication in AMQP connections, the username and password
supplied in the --url option to amqp-consume resp. amqp-publish are
exposed in the proces list, see #1037322:
$ pgrep
Control: tag -1 fixed-upstream
On 2023-06-11 12:28, Christian Kastner wrote:
> Package: amqp-tools
> Version: 0.11.0-1
> Severity: grave
> Tags: security
> Forwarded: https://github.com/alanxz/rabbitmq-c/issues/575
>
> When passing authentication data with either --password
Package: amqp-tools
Version: 0.11.0-1
Severity: grave
Tags: security
Forwarded: https://github.com/alanxz/rabbitmq-c/issues/575
When passing authentication data with either --password or --url, the
data is exposed in the process list, where it can be seen by any user.
Example:
$ pgrep -a
Package: librocprim-dev
Version: 5.3.3-3
Severity: serious
librocprim-dev needs libamdhip64-dev, but this dependency is missing
from the package.
Package: libamdhip64-5
Version: 5.2.3-5
Severity: serious
When working on rocrand, I noticed that the rocrand libraries did not
work without libamd-comgr2 installed.
Cordell Bloor pointed out that libamd-comgr2 is essential to any library
that contains GPU kernels, and the calls are likely to be
(debian-ai, apologies for re-sending, I hit the wrong reply button.)
On 2023-03-08 18:21, Simon McVittie wrote:
> There is *a* version of llvm-toolchain-15 in bookworm, version 1:15.0.6-4,
> which is used by the rocm-hipamd_5.2.3-1 and mesa_22.3.3-1 in bookworm.
> I'm not suggesting that
On 2022-12-13 06:02, Christoph Anton Mitterer wrote:
> On installation there is a file conflict:
> Unpacking libpam-cap:amd64 (1:2.66-1) over (1:2.63-1) ...
> dpkg: error processing archive
> /tmp/apt-dpkg-install-B9lzYA/08-libpam-cap_1%3a2.66-1_amd64.deb (--unpack):
> trying to overwrite
Hi Helmut,
you're quick!
On 2022-12-12 15:17, Helmut Grohne wrote:
> Package: libcap-dev
> Version: 1:2.63-1
> Severity: serious
> Jutsification: fails to install with an unpack errror
> User: helm...@debian.org
> Usertags: rebootstrap
>
> Coinstalling libcap-dev fails:
>
> | Unpacking
On 2022-03-08 21:58, Christian Kastner wrote:
> I'll upload an NMU.
Ah, pulling the newest source from Salsa, I saw Georges' @debian.org
address. Apologies!
In that case, please NMU it yourself (as you've already prepared the
changelog).
Best,
Christian
Hi,
FYI, cron is looking for a new maintainer, see #984736, so I guess that
is why there hasn't been any activity yet.
On 2021-06-22 16:52, Wouter Verhelst wrote:
> Whoever wrote that patch should be slapped around the head with a copy
> of RFC3696.
As evident from the header, that patch was
Hi,
On 2022-02-16 11:57, John Paul Adrian Glaubitz wrote:
> Hello!
>
> On 2/16/22 11:36, Graham Inggs wrote:
>> Is anyone able to help with the bus error on armhf please?
>
> Bus errors are normally easy to spot. Just run the code in question through
> GDB and see where it crashes. Then look at
On 08.03.21 20:26, Markus Frosch wrote:
> Thanks for reporting, haven't been following upstream for a while since I
> don't
> use the package actively anymore.
Admittedly, this particular information was somewhat buried.
> Due to lack of time, I'll upload a minimal patch for now. Feel free to
Package: yubikey-luks
Version: 0.5.1+29.g5df2b95-5
Severity: grave
Justification: confidential information leak
Tags: security
Hi,
Looking at the upstream yubikey-luks repository, I noticed what seems to
be an important recent fix, namely for the password (used as the yubikey
challenge) being
Hi,
On 11.02.21 15:20, Nilesh Patra wrote:
> On Sun, 7 Feb 2021 22:08:58 +0100 =?utf-8?Q?=C3=89tienne?= Mollier
> wrote:
>> I tried to reproduce the bug by building igdiscover 0.11-3 using
>> sbuild in a clean Sid chroot which did include pytest 6:
>>
>> $ schroot -c unstable-amd64-sbuild -d /
Source: sabnzbdplus
Version: 3.1.1+dfsg-1
Severity: serious
User: pyt...@packages.debian.org
Usertags: pytest-v6
Hi,
sabnzbdplus autopkgtests fail with pytest 6 in unstable. The problem
seems to be the -k expression used to exclude particular tests:
> ERROR: Wrong expression passed to '-k':
Source: python-llfuse
Version: 1.3.6+dfsg-2
Severity: serious
User: pyt...@packages.debian.org
Usertags: pytest-v6
Hi,
python-llfuse FTBFS with pytest 6 in unstable:
> ERRORS
>
> _ ERROR at setup of
Source: python-ase
Version: 3.20.1-1
Severity: serious
User: pyt...@packages.debian.org
Usertags: pytest-v6
Hi,
python-ase autopkgtests with pytest 6 in unstable. Apparently, something
is trying to write to /usr/lib/:
> File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187, in
>
Source: xonsh
Version: 0.9.24+dfsg-2
Severity: serious
User: pyt...@packages.debian.org
Usertags: pytest-v6
Hi,
xonsh autopkgtests with pytest 6 in unstable because it uses a
deprecated feature that will be removed soon, and that, by default,
considered an error in pytest 6.
The fragment of the
Source: pytest-mpi
Version: 0.4-2
Severity: serious
User: pyt...@packages.debian.org
Usertags: pytest-v6
Hi,
pytest-mpi autopkgtests fail with pytest 6 in unstable. From the CI log
below, for some reason, the test gets aborted at some point:
> Testing with python3.9:
>
Source: ffc
Version: 2019.2.0~git20200123.6b621eb-3
Severity: serious
User: pyt...@packages.debian.org
Usertags: pytest-v6
Hi,
ffc autopkgtests with pytest 6 in unstable because it uses a deprecated
feature that will be removed soon, and that, by default, considered an
error in pytest 6.
The
Source: gitsome
Version: 0.8.0+ds-4
Severity: serious
User: pyt...@packages.debian.org
Usertags: pytest-v6
Hi,
gitsome autopkgtests fail with pytest 6 in unstable because of changes
to the use of TerminalWriter. See
https://docs.pytest.org/en/stable/changelog.html#id60
The CI error log
Source: docopt
Version: 0.6.2-2.2
Severity: serious
User: pyt...@packages.debian.org
Usertags: pytest-v6
Hi,
docopt autopkgtests fail with pytest 6 in unstable because it uses a
deprecated feature that will be removed soon, and that, by default,
considered an error in pytest 6.
The fragment of
Control: severity -1 important
Tags: -1 unreproducible
Hi Julien,
I'm downgrading because the pytest currently does work with hundreds of
packages, implying that it cannot be (generally) unusable.
On Wed, 09 Dec 2020 21:08:39 +0100 Julien Puydt wrote:
> I was trying to update another package in
Control: notfound -1 elementpath/2.0.4-1
Control: reassign -1 python-xmlschema
On 11/21/20 9:50 PM, Paul Gevers wrote:
> Source: elementpath, python-xmlschema
> Control: found -1 elementpath/2.0.4-1
> Control: found -1 python-xmlschema/1.2.2-2
> Severity: serious
> Tags: sid bullseye
>
Source: qemu-sbuild-utils
Version: 0.1
Severity: serious
X-Debbugs-CC: jo...@debian.org
The sbuild maintainers raised the valid point that it might be better to
incorporate large parts of this software in src:sbuild, in which case
this package should not enter bullseye.
So until this question is
Control: retitle -1 bcolz: FTBFS with newer python3-sphinx
On Mon, 20 Jul 2020 09:51:26 +0200 Christian Kastner wrote:
> Source: bcolz
> Version: 1.2.1+ds2-5
> Severity: serious
> Justification: FTBFS
On 2020-07-20 11:22:16 +0100 "Chris Lamb" wrote:
> Whilst working on the Reproducible Builds effort [0] we noticed that
> numpydoc could not be built reproducibly.
>
> This is because it includes a junit-results.xml and .coverage file
> from the test run. (The latter file should have been
Control: tag -1 pending
Hello,
Bug #965362 in numpydoc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Package: python3-setuptools
Version: 49.3.1-1
Severity: grave
Justification: Package is unusable
The most recent upload broke something badly, setuptools can no longer
be imported:
$ python3 -c 'import setuptools'
Traceback (most recent call last):
File "", line 1, in
File
Source: bcolz
Version: 1.2.1+ds2-5
Severity: serious
Justification: FTBFS
Hi,
bcolz FTBFS on amd64 with an updated version of python3-numpydoc.
Here is the tail of the build log. The error seems to originate
during the build of the documentation:
Control: tag -1 pending
Hello,
Bug #955054 in pygments reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: tag -1 pending
Hello,
Bug #955081 in deap reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: reassign -1 python-skbio
On 2020-02-12 20:00:16 +0100 Paul Gevers wrote:
> With a recent upload of scikit-learn the autopkgtest of python-skbio
> fails in testing when that autopkgtest is run with the binary packages
> of scikit-learn from unstable. It passes when run with only packages
On 2020-02-13 09:31:54 +0100 Andreas Tille wrote:
> Control: tags -1 upstream
> Control: forwarded -1 https://github.com/biocore/scikit-bio/issues/1693
>
> > Due to the nature of this issue, I filed this bug report
> > against both packages. Can you please investigate the situation and
> >
Control: tag -1 pending
On 31.01.20 11:33, Paul Gevers wrote:
> Source: libsvm
> Version: 3.24+ds-2
> X-Debbugs-CC: debian...@lists.debian.org
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: fails-always
>
> Dear maintainers,
>
> With a recent upload of libsvm you added an
On 19.01.20 11:06, PICCA Frederic-Emmanuel wrote:
> Hello, if it is like for my ufo-core package, this could be due to a script
> file with a shebang using python instead of python3
I just tested this and indeed, there were scripts with said python in
the shebang. Changing this to python3 fixed
On 19.01.20 03:23, Sandro Tosi wrote:
> This bug was closed, but the package has still some dependencies towards
> Python2 packages, in details:
>
> (binary:libsvm-tools)Depends->python:any
>
> Re-opening, so that they can be taken care of.
I believe I am missing something; could you expand on
On 11.01.20 06:09, Andreas Tille wrote:
> On Fri, Jan 10, 2020 at 11:45:15PM +0100, Christian Kastner wrote:> Strange.
> I did not intentionally set the branch protection. Hope it
> works now.
Pushing worked after this, thanks.
I test-rebuilt all packages with build dependenci
Hi all,
On 10.01.20 15:33, Chen-Tse Tsai wrote:
> Yes, my changes are merged.
I checked the package and everything looks pretty good. I just added
some minor polishing of my own.
Very surprisingly, not a single symbol has changed since 3.21 -- no
additions, no removals, no changes. It looks as
On 10.01.20 11:07, Andreas Tille wrote:
> since my upload was a bit questionable this gives us the chance
> to discuss it again. What option would you prefer:
>
>1. I just re-upload what is in Git right now to new queue
>2. Somebody who feels more competent takes over
>3. Something
On 2019-12-25 18:08, Chen-Tse Tsai wrote:
> Thanks Andreas and Christian for the updates/comments. I agree that I
> should have been more verbose in the changelog. I'm tracing all the
> commits to learn more about packaging. I was playing with gbp for
> updating upstream. I really like how it
On 2019-12-25 10:59, Andreas Tille wrote:
> Kind regards
>
>Andreas.
I've re-read my original message and feel that I was overly harsh. I was
irritated about the rushed upgrade as in private communication with
Chen-Tse, I highlighted precisely the possible complexity of this
upgrade and
Andreas, what are you doing?
On 2019-12-25 07:52, Andreas Tille wrote:
> On Tue, Dec 24, 2019 at 10:39:55AM -0500, Chen-Tse Tsai wrote:
>> I just submitted a PR for dropping python2 dependencies:
>> https://salsa.debian.org/science-team/libsvm/merge_requests/1
>>
>> Any comment is appreciated.
Hi all,
Regarding liblinear: I thought I already set the Maintainer to Debian
Science Team, I guess I missed it.
On 2019-12-21 20:11, Chen-Tse Tsai wrote:
> I've created an account on Salsa.
>
> Do you think we should remove cdbs and use another build system
> instead? Please let me know if
Hi all,
first of all, apologies for the late reply. I moved in February, and I'm
still in the process of settling in. I have still to unpack my
development machine...
On 2017-02-14 09:39, Raphael Hertzog wrote:
> On Mon, 09 Jan 2017, Sophie Brun wrote:
>> AttributeError: 'BitEnumField' object
Control: reassign -1 graphviz
Control: merge -1 827806
Hi Santiago,
On 2016-08-18 00:21, Santiago Vila wrote:
> Traceback (most recent call last):
> File "pyevolve_ex19_gp.py", line 85, in
> main_run()
> File "pyevolve_ex19_gp.py", line 82, in main_run
> graph.write_jpeg('tree.png',
On 2016-07-03 12:30, László Böszörményi (GCS) wrote:
> In that clean chroot, may you rebuild -13 from source? Then install
> it still in that chroot and see the output of 'dot'.
You were right: with a rebuilt -13, jpeg is no longer present in
'device', either:
device : canon cmap
On 2016-07-03 09:26, László Böszörményi (GCS) wrote:
> Hi Christian,
>
> On Sat, Jul 2, 2016 at 10:05 PM, Christian Kastner <c...@debian.org> wrote:
>> On 2016-07-02 22:03, Christian Kastner wrote:
>>> Support for jpeg seems to have disappeared in graphviz 2.38.
On 2016-07-02 22:03, Christian Kastner wrote:
> Support for jpeg seems to have disappeared in graphviz 2.38.0-14:
>
> $ dot -Tjpeg
> Format: "jpeg" not recognized. Use one of: canon cmap cmapx cmapx_np dot
> eps fig gd gd2 gv imap imap_np ismap pdf pic plain
Control: reassign -1 graphviz
Hi Laszlo,
On 2016-06-21 11:59, Chris Lamb wrote:
> Source: pyevolve
> Version: 0.6~rc1+svn398+dfsg-9
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc:
Control: severity -1 minor
Hi Dominique,
On 2016-05-10 01:52, Dominique Belhachemi wrote:
> Package: libsvm
> Version: 3.12-1.1
> Severity: serious
>
> The source package contains binary files, see
>
> https://sources.debian.net/src/libsvm/3.12-1.1/windows/
>
Hi,
thank you for your report. I've already spent a good amount of time
analyzing the potential impact of this flaw, but I would like to refrain
from further public comments until I have discussed this with security@d.o.
Thanks,
Christian
On 2015-12-27 19:57, Cron Daemon Use-After-Free
Control: tag -1 confirmed pending
Hi Chris,
On 2015-11-08 12:51, Chris Lamb wrote:
> Dear Maintainer,
>
> gitinspector fails to build from source in unstable/amd64:
>
> ==
> ERROR: tests.test_comment
Hi all,
On 2015-06-03 00:02, Cyril Brulebois wrote:
Michael Biebl bi...@debian.org (2015-06-02):
Control: block -1 by 782475
Am 02.06.2015 um 18:11 schrieb Cyril Brulebois:
libudev1-udeb depends on missing libcap2. I suspect the easiest would be
to drop libcap2 support from the udeb build.
Hi,
On 2015-06-06 21:33, Christoph Berg wrote:
Re: Christian Kastner 2015-05-03 554626d8.4090...@kvr.at
I'd strongly opt to change the KillMode as mentioned above.
#debian-devel seems to agree, so I'm upgrading this bug to RC.
(critical as it's killing random processes)
A particular reason
Hi again,
On 2015-06-07 23:22, Cyril Brulebois wrote:
Christian Kastner deb...@kvr.at (2015-06-07):
Sorry for the delay, I was AFK until just now.
I've prepared a quick upload consisting of only Matthias' patch, minus
the superfluous d/shlibs.local as discussed in Michael's follow-up
On 2015-06-02 19:48, Michael Biebl wrote:
Am 02.06.2015 um 18:11 schrieb Cyril Brulebois:
libudev1-udeb depends on missing libcap2. I suspect the easiest would be
to drop libcap2 support from the udeb build. An alternative would be to
try and add a udeb in libcap2. I'd rather have the former
control: tag -1 moreinfo
Hi everyone,
Am 18.05.2015 um 19:04 schrieb Bernhard Übelacker:
Hello,
as I got the same problem on my raspberry, probably I can give
some details.
This is the situation I started:
- put 2015-05-05-raspbian-wheezy.img on SD-card and booted
- changed sources.list
Control: tag -1 + confirmed pending
On 2015-05-03 15:33, Christoph Berg wrote:
Re: To Joerg Morbitzer 2015-05-03 20150503125807.ga3...@msg.df7cb.de
I'd strongly opt to change the KillMode as mentioned above.
#debian-devel seems to agree, so I'm upgrading this bug to RC.
(critical as it's
Hi again,
sorry for the delay.
On 2015-03-24 00:02, Holger Levsen wrote:
I think it's also a question of ordering: if libpam-cap is updated first
and and libcap2-bin is removed second, things go well. If libcap2-bin is
removed first and libpam-cap second, you will encounter the problem.
I
Hi Andreas,
On 2015-03-14 01:56, Andreas Beckmann wrote:
On 2015-03-13 23:49, Christian Kastner wrote:
Would you by chance be available for sponsoring? (No problem if not, but
if yes, please wait for an updated debdiff as the RT approved another
one-line fix.)
I'm not sure
Hi,
On 2015-03-29 15:57, Christian Kastner wrote:
On 2015-03-24 00:02, Holger Levsen wrote:
I think it's also a question of ordering: if libpam-cap is updated first
and and libcap2-bin is removed second, things go well. If libcap2-bin is
removed first and libpam-cap second, you will encounter
Control: tag -1 + moreinfo
Hi Holger,
I'm having problems reproducing this. I just tried upgrading in pristine
wheezy VMs
(a) with libcap2-bin
(b) with libcap2-bin + libpam-cap installed,
and I didn't encounter this issue.
On 2015-03-23 21:06, Holger Levsen wrote:
to fix #768229
Control: tag -1 + confirmed pending
On 2015-03-13 16:33, Andreas Beckmann wrote:
during a test with piuparts I noticed your package fails to upgrade from
'lenny' to 'squeeze' to 'wheezy' to 'jessie'.
Its predecessor 'libcap-bin' installed fine in 'lenny', and was kept
installed during the
On 2015-03-14 01:56, Andreas Beckmann wrote:
On 2015-03-13 23:49, Christian Kastner wrote:
Would you by chance be available for sponsoring? (No problem if not, but
if yes, please wait for an updated debdiff as the RT approved another
one-line fix.)
I'm not sure that this is the correct
On 2015-03-13 23:22, Andreas Beckmann wrote:
libcap2-bin had Conflicts: libcap-bin upto wheezy, this (and a
corresponding Replaces) should return for jessie, it can go away
afterwards, since the default (straight forward) upgrade paths should be
covered.
Oh, I didn't notice that earlier
/control:
+- Add Breaks+Replaces for libcap-bin. libcap-bin was removed after lenny,
+ but the transition to libcap2-bin was not fully handled. Closes: #780411
+
+ -- Christian Kastner deb...@kvr.at Fri, 13 Mar 2015 21:28:23 +0100
+
libcap2 (1:2.24-6) unstable; urgency=medium
* debian
On 2015-03-01 20:50, Bdale Garbee wrote:
Christian Kastner deb...@kvr.at writes:
All of the RC fixes have been in unstable for a while now, so an upload
to t-p-u could be negotiated now with the RT. If you'd like me to take
care of that, please let me know.
Go for it. I'm likely
Hi,
On Mon, 20 Oct 2014 21:29:56 + Bdale Garbee bd...@gag.com wrote:
sudo (1.8.11p1-2) unstable; urgency=low
.
* patch from Jakub Wilk to fix 'ignoring time stamp from the future'
messages, closes: #762465
The above bug has been bumped to serious, making it RC. In case this is
On 2015-02-22 07:43, Michael Gilbert wrote:
On Sat, Feb 21, 2015 at 9:52 PM, Christian Kastner wrote:
It's not backed up in jessie or later. The backup/md5sum stuff is
preceeded by a test for and old version less than 1.7.4p4-4, so in
wheezy and later, all the md5sum stuff is ignored during
On 2015-02-22 17:50, Michael Gilbert wrote:
On Sun, Feb 22, 2015 at 6:35 AM, Christian Kastner wrote:
In wheezy and later, where /etc/sudoers already is a conffile, that is
entirely for dpkg to handle, not for the *.preinst scripts. Anything in
the *.preinst is exclusively for when upgrading
On 2015-02-22 02:05, Michael Gilbert wrote:
On Fri, Feb 6, 2015 at 7:02 PM, Christian Kastner wrote:
I've looked into this now, and I believe that the --compare-versions
issue and the chown/chmod issue is all there is to this bug. I have
attached a new debdiff (v2) with fixes for both.
I
On 2015-02-07 01:02, Christian Kastner wrote:
I have tested this patch in a number of combinations, including (but not
limited to):
sudo (squeeze) - sudo (jessie) upgrade
sudo-ldap (squeeze) - sudo-ldap (jessie) upgrade
Works as intended. An unchanged
Hi,
On 2015-02-07 01:02, Christian Kastner wrote:
I've looked into this now, and I believe that the --compare-versions
issue and the chown/chmod issue is all there is to this bug. I have
attached a new debdiff (v2) with fixes for both.
I have tested this patch in a number of combinations
On 2015-02-18 22:32, Bdale Garbee wrote:
Christian Kastner deb...@kvr.at writes:
Bdale, once such a confirmation (or another fix) is in, how would you
like to proceed? I could help with the RT communication again
Sure. I'm willing to merge a patch and do uploads, but need to know
which
Control: tags -1 + patch
Hi again,
On 2015-01-30 10:27, Christian Kastner wrote:
On 2015-01-30 00:19, Andreas Beckmann wrote:
Which is erroneously moved aside by sudo-ldap.preinst, thereafter dpkg
unpacks sudo-ldap, takes over file ownership (incl. conffiles) from sudo
and once it gets
Control: tags -1 - patch
On 2015-01-30 00:19, Andreas Beckmann wrote:
On 2015-01-29 23:16, Christian Kastner wrote:
Which is erroneously moved aside by sudo-ldap.preinst, thereafter dpkg
unpacks sudo-ldap, takes over file ownership (incl. conffiles) from sudo
and once it gets around
Hi Andreas,
I'm not quite sure we're on the same page yet, but I'm also not 100%
confident that I'm in the right. So here are some additional thoughts:
On 2015-01-29 09:31, Andreas Beckmann wrote:
And while switching sudo-sudo-ldap the following happens:
sudo gets removed, conffile remains
I just noticed that I completely overlooked your other comments to my
original mail. Sorry about that!
On 2015-01-29 09:31, Andreas Beckmann wrote:
On 2015-01-28 23:56, Christian Kastner wrote:
This is the first problem. It is of course possible for this file to be
generally absent (it's
On 2015-01-29 21:25, Andreas Beckmann wrote:
just to make notation clear
/etc/sudoers is a *configuration file*, i.e. rules of preserving user
changes apply
since wheezy it is also a *conffile* i.e. shipped with the package at
/etc/sudoers and managed by dpkg, not to be touched by
, temporarily
+renamed /etc/sudoers back to its original location to complete the switch.
+Closes: #776137
+
+ -- Christian Kastner deb...@kvr.at Wed, 28 Jan 2015 23:39:59 +0100
+
sudo (1.8.10p3-1+deb8u1) testing-proposed-updates; urgency=medium
* Non-maintainer upload.
diff -Nru sudo-1.8.10p3
Hi Martin,
On 2015-01-21 11:35, Martin Pitt wrote:
On both my Debian sid and my Ubuntu system, the only difference
between common-session and common-session-noninteractive is that the
latter does not include libpam-systemd.
Generally speaking, I believe (but haven't verified) that this will
On 2015-01-20 19:28, Felipe Sateler wrote:
For reference, the inclusion of common-session is a local debian
patch[1]. The original file referenced system-auth, which apparently
debian does not use.
[1]
On 2015-01-18 13:52, Joachim Breitner wrote:
Am Samstag, den 17.01.2015, 19:39 +0100 schrieb Christian Kastner:
The copyright information and the license terms for the files
src/Crypt/*
is missing from debian/copyright.
I wonder: Since it is a mix of GPL and BSD, we are effectively
On 2015-01-18 15:09, Joachim Breitner wrote:
Well, that’s how the files are distributed to Debian. But that doesn’t
mean that Debian cannot re-license them all under the GPL... At least I
thought that BSD code can generally be relicensed under the GPL.
Oh, now I understand what you mean.
What
1 - 100 of 155 matches
Mail list logo
