> "Ansgar" == Ansgar writes:
Ansgar> using other choices of "Rules-Requires-Root" than "no" and
Ansgar> "binary-targets". The query [1] found two uses:
Can you help me understand how options other than binary-targets or no
were supposed to work/what they make possible?
I have found
package: libapache-mod-auth-kerb
severity: serious
version: 5.4-2.4
tags: security
justification: unmaintained with security weaknesses
Hi. As part of a recent krb5 transition, I took a look at
libapache-mod-auth-kerb.
As part of that transition, libapache-mod-auth-kerb was removed from
testing.
control: tags -1 pending
I've uploaded to delayed/3, using your minimal patch.
Thanks.
--Sam
I'd like to see people chime in who have not participated in the
discussion yet.
I prefer your original text but we'd need to get support for it.
It sounds like we're fairly evenly split among the current participants
in the issue.
--Sam
I've proposed a patch to libapache-mod-auth-kerb.
If someone tests the patch, I'll NMU.
mia-query on the maintainer of libapache-mod-auth-kerb is revealing;
I'll contact the MIA team and suggest orphaning or removing
libapache-mod-auth-kerb.
control: tags -1 patch
Here's a patch that I believe will get libapache-mod-auth-kerb working
with the latest krb5. I'll go upload a krb5 that fixes the breaks
relationship.
I'd appreciate it if someone who actually uses libapache-mod-auth-kerb
will test this patch.
If it gets tested, I'll NMU.
> "Russ" == Russ Allbery writes:
Russ> Marc Haber writes:
Russ> The years are an annoying bit of pedantry. The short version
Russ> is that US copyright law requires a year in the notice, and
Russ> that year is supposed to represent a year in which a
Russ> copyrightable c
> "Paul" == Paul Wise writes:
Paul> switching to another module but I suspect that modauthkerb
Paul> should just get removed from Debian in favour of
Paul> mod_auth_gssapi, which is supposed to be a replacement.
I think that mod_auth_gssapi plus mod_auth_pam and libpam-sss or
lib
control: reassign -1 libapache2-mod-auth-kerb
control: found -1 libapache2-mod-auth-kerb/5.4-2.4
control: retitle -1 FTBFS with krb5 1.18: significant use of internal
APIs and data structures
control: affects -1 libkrb5-3
Hi.
Kerberos 5 1.18 significantly refactors the replay cache implementatio
>>>>> "Sam" == Sam Hartman writes:
>>>>> "Sebastian" == Sebastian Ramacher writes:
>>> I've uploaded to unstable. There's what tracker lists as a
>>> regression in CI tests:
>>>
https://ci.debi
> "Sebastian" == Sebastian Ramacher writes:
>> I've uploaded to unstable. There's what tracker lists as a
>> regression in CI tests:
>>
https://ci.debian.net/data/autopkgtest/testing/ppc64el/s/squid/8297228/log.gz
>>
>> I don't think that regression looks caused by krb5
I've uploaded to unstable.
There's what tracker lists as a regression in CI tests:
https://ci.debian.net/data/autopkgtest/testing/ppc64el/s/squid/8297228/log.gz
I don't think that regression looks caused by krb5 after examining the
log.
Do you need me to request binnmu of libauthen-krb5-admin-per
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Hi. I've uploaded krb5 1.18 to experimental, and the soname of the
administrative libraries (and libkdb5, but that's purely internal)
changed. The ABI differs, but the API is the same.
This was not clear from my message yesterday.
If you want me to prepare an update for buster, and agree to test such
an update, I'm happy to do so.
I don't plan to ever put 1.17.2 into unstable; I plan to ask to move
1.18.2 into unstable shortly.
LTS is beyond my horizon of caring.
I won't stand in your way, and if you never became a DD, I'll be happy
to review and sponsor anything you need, but that's not where my energy
goes.
Thanks for the note. I've been meaning to do a much needed krb5 update
and this definitely pushes it up the priority stack.
I'll work on this over the weekend.
package: lvm2-lockd
version: 2.03.09-3
Hi.
This is a relatively brief bug report, I'm tossing off in the middle of
trying to get something working, and I apologize for not including a lot
of details.
The system where I can reproduce is several tunnels away from anything
with email so I definitely
> "Balint" == Balint Reczey writes:
Balint> Hi Sam, Thank you for the quick response.
>> That said, I think libverto in Debian should support all the
>> options, and certainly should support libevent. That won't make
>> things easier for Ubuntu really, if they want to avoid b
So, the main reason we're using libev is that upstream krb5 uses libev.
I think they do because libev is a smaller more self contained code base
than libevent, and because honestly the KDC isn't normally a performance
bottleneck, so it doesn't much matter.
That said, I think libverto in Debian sho
> "Bill" == Bill Allombert writes:
>> I'd propose that as a first step we change that to
>>
>> Packages are not required to declare any dependencies they have
>> on other packages which are marked Essential (see below), but are
>> permitted to do so even if they do not de
> "Bill" == Bill Allombert writes:
Bill> I am pretty sure we were concerned about source packages being
Bill> unpackable on non Debian systems, though.
And I think we probably still are. I was trying to capture the concerns
there in the part of my message you trimmed.
My rational
> "Giacomo" == Giacomo Catenazzi writes:
Giacomo> The rationale was probably similar so symlinks: they may
Giacomo> fail across different filesystems, and we supported to have
Giacomo> e.g. / /usr /usr/share /usr/local /var (and various /var/*)
Giacomo> /home /tmp /boot etc on
> "Josh" == Josh Triplett writes:
Josh> Long-term, I'd like to see that happen. But I'm a huge fan of
Josh> incremental steps; defining the problem as "eliminate
Josh> Essential" makes it both difficult enough and controversial
Josh> enough to make it unlikely to happen at all
I'm ignoring the case where capabilities are dropped in my analysis.
I've long valued that Debian does not mark file paths as readonly and
would not support this change.
I've worked on other Unix distributions that did this, and I found that
it decreased the quality of life of the sysadmin enoug
> "Axel" == Axel Beckert writes:
Axel> Control: forcemerge 509100 -1 Hi,
Axel> Yeah, this is a long-standing and known issue in aptitude.
I'd ask the aptitude developers to consider whether this issue should be
reprioritized as important rather than normal.
Here's my rationale.
Las
> "rharwood" == rharwood writes:
rharwood> In debian/control, you list the dependency as:
rharwood> Build-Depends: debhelper-compat (= 13)
rharwood> Could it be because 13 != 13.2 ?
No, for a while now virtual packages can be provided at a specific
version.
from apt-cache
> "Petter" == Petter Reinholdtsen writes:
Petter> In Debian Edu, /etc/environment is used to set the required
Petter> HTTP proxy globally. It would be nice if it actually took
Petter> effect for all services. :)
Petter> As far as I know, there is no other alternative for
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
nmu moonshot-gss-eap_1.0.1-6 . ANY . unstable . -m "Rebuild for shibboleth
transition"
Please rebuild moonshot-gss-eap now that new libshibsp-dev and
libshibresolver-dev are in unstable.
I strongly agree with Ian in this matter.
I think there are at least two cases where this issue comes up and is
importand, and where using a debian revision without separate upstream
tarballs is the right approach:
1) small packages currently maintained by the upstream maintainer where
debian rev
control: forcemerge -1 962519
control: severity -1 serious
Yeah, in rearranging the build system I missed an argument to configure
which had consequences more significant than I anticipated. I was not
expecting code/behavior changes because I thought I had literally
cut&paste the configure line f
Thanks.
I am in the middle of fixing.
Apologies I didn't get a fix uploaded before you filed a bug.
Ah!
Never mind.
You opened a merge requests *months ago* and now are getting around to
opening a BTS bug because I'm a bad maintainer and didn't respond to
your merge request.
Got it.
Apologies.
I'll get to this in a couple of days.
I think I was busy being a less-bad DPL back then:-)
Yeah, I just looked at mail server logs, and I have nothing from salsa
even attempted to be delivered going back to may 4.
At one level I totally understand this is not your problem.
At another, if this isn't just something I've done to myself, it could
impact people's responses to merge requests.
I'm not sure I'm seeing how this comes up in practice for krb5-doc.
Would you mind helping my curiosity out.
Also, I'm somewhat horrified that I didn't get a notification for your
MR.
My notification setting for debian/krb5 is watch.
Have you run into other cases where people were not notified of s
> "Jonas" == Jonas Smedegaard writes:
Jonas> How is "matrix chat protocol" inadequate to tell what package
Jonas> does, which a change to capitalization of initial character
Jonas> fixes?
I think this is more confrontational than I'd like to see in Debian.
It is very common in m
package: python3-matrix-nio
version: 0.10.0-1
Hi.
I can't tell from the short description whether this is for the Matrix
chat client, linear algebra, or something else.
It's *probably* not linear algebra from the descriptions and http
emphasis, but I shouldn't have to guess at that.
If it's part o
Package: release.debian.org
Severity: normal
I got a message from testing auto removal saying:
>moonshot-ui 1.1.0+libsecret~2 is marked for autoremoval from testing on
>2020-04-27
>It is affected by these RC bugs:
>952054: moonshot-ui: FTBFS: libmoonshot.vapi:45.34-45.56: error:
No, I missed this.
We're on the same page.
> "Bill" == Bill Allombert writes:
Bill> But is it an actual problem ? Do we see packages marked
Bill> Essential: yes by mistake ?
I think Josh's analysis brought up some important points for me that I
did not consider before and that need to be considered making decisions
in the fu
I concur with the comments raised so far.
I think it would be great to do a better job of outlining the problems
with essential packages in debian-policy.
I don't understand why we would tie our hands though.
A consensus of debian-devel seems adequate to consider those issues and
evaluate them.
If
I think there is another use of debian/copyright beyond just documenting
what ends up in the binaries.
I think that if I read debian/copyright in a source package, I should
expect to understand the licenses I need to comply with when dealing
with the source package.
So for example if the package
Thanks for the prod. I think I can do what you need, but probably not
in the way you suggest.
I'm finding that finishing out my DPL term is taking up enough of my
time that I don't really want to pull in a new krb5 upstream right now.
However it looks like pulling in the patches to the doc bui
> "Melanie" == Melanie Frost writes:
Melanie> The volunteer was elected as a community representative and
Melanie> he's been hounded ever since. It looks like he asked
Melanie> people to stop these games, he resigned and he was still
Melanie> chased.
The issue is that Daniel
that we do value acting to make Debian a place where people
can work free from disruption or harassment.
Sam Hartman
Debian Project Leader
signature.asc
Description: PGP signature
The description should describe what MSAL is.
Might I suggest that wallet is kind of generic and I'm aware of a number
of different tools out there that claim to be wallets of various kinds.
I think the description should do a better job of scoping which wallets
this is good for.
I'll note there's another case where this could be valuable.
If there is an installer in contrib, you can express dependencies on the
package being available in Debian.
Depending on how that installer works, you may not be able to express
dependencies on the installed version in Debian.
I think th
> "Michael" == Michael Biebl writes:
Michael> b/ you need a different way to switch
Michael> over. Reboot into an environment for which you have control
Michael> over, then uninstall systemd/systemd-sysv without
Michael> triggering the removal of most packages.
This is fair
> "Michael" == Michael Biebl writes:
Michael> Tbh, I'm not sure what kind of answer you expect from me.
Michael> I guess I already provided my feedback here and mentioned
Michael> what kind of solution I prefer. I can repeat this in this
Michael> bug report, but I'm not sure
> "Sean" == Sean Whitton writes:
Sean> Encouragement is still normative, so if we're going to encourage it,
Sean> it would be better to say /when/ it's encouraged and when it's not.
I think it should be encouraged when there is not a good reason to do
otherwise.
I think the most com
> "Russ" == Russ Allbery writes:
Russ> Ah, hm, yes, that's a good point that I didn't notice when copying
that
Russ> Policy recommendation over from the recommendations on init scripts.
Russ> The obvious concern here is that multiple packages could use the same
Russ> servic
> "Philipp" == Philipp Kern writes:
Philipp> I'm told it was broken by the upgrade of Apache - apparently it
can no
Philipp> longer do per path client certificate authentication. There is a
Philipp> pending RT ticket from DSA to fix that but I don't think there is
Philipp> an
Russ said off-list he was ready for seconds.
I second his patch with the status being encouraged rather than
recommended change.
In seconding, my primary review criteria was whether I thought the
change accurately reflected what the GR conclusion was.
--Sam
signature.asc
Description: PGP signat
I've reviewed your patch.
It looks good.
One minor suggestion:
+The ``start``, ``stop``, ``restart``, and ``force-reload`` options should
+be supported by all init scripts. Supporting ``status`` is recommended but
+not required. The ``reload`` and ``try-restart`` options are optional.
How about
Russ, I've reviewed your new patch.
I haven't been participating in this discussion before, but I think it
is fair to say that I have significant experience with these sorts of
normative language discussions and Debian policy in general.
I agree with all your changes (with one question below).
My
control: tags -1 patch
> "peter" == peter green writes:
peter> Tags 944714 +patch Thanks.
peter> The easy fix here is to remove -Werror, in the long term of
peter> course migration to a non-deprecated type should be
peter> considered but that is IMO an issue for upstream not
Acknowledged.
DPL is taking up all my Debian time at the moment.
It's not the end of the world if moonshot-trust-router falls out of
testing, but hopefully I'll get to this before it happens.
It's almost certainly simple.
user debian-pyt...@lists.debian.org
usertag 939483 +py2keep
control: user debian-pyt...@lists.debian.org
control: usertag -1 +py2keep
Hi.
The current version of krb5 depends on python2 at least for sphinx and
other items in doc building.
This will be fixed for the next upstream of krb5, which will be released
within a year.
So, we should be able to close t
> "Michael" == Michael Biebl writes:
Michael> On Wed, 30 Oct 2019 13:22:14 + Ian Jackson
Michael> wrote:
>> The bulk of the bug is a discussion about the general approach to
>> allowing Debian users to choose between systemd and elogind (and,
>> therefore, allowing t
> "Diego" == Diego M Rodriguez writes:
Diego> nested. This presents a practical problem: When in an
Diego> environment where the event loop is already running it's
Diego> impossible to run tasks and wait for the result.
The above description should be improved.
Because it's fairl
I think that nextcloud-server-installer would be a better package name.
Also, presumably you are targeting the contrib section rather than the
main section.
How would you feel about an actual packaging of the server (rather than
an installer) that used fastrack.debian.net?
Fastrack is intended to
control: reassign -1 openafs-krb5
control: found -1 1.8.2-1
Openafs maintainers:This may just be a support request; if so feel free
to close. But I'm not sure if there are documentation bugs remaining,
or if you consider the part of the Debian wiki referenced by this under
your control.
What s
> "Mark" == Mark Hindley writes:
Mark> Sam, Since I cannot get a working and robust dpkg-divert
Mark> solution, I feel the need to revisit the validity of these
Mark> concerns.
I'd like to push back on the phrasing here.
What i'm hearing is that after spending a couple of weeks e
> "Thorsten" == Thorsten Glaser writes:
Thorsten> On Wed, 25 Sep 2019, Mark Hindley wrote:
>> libelogind0 can be coninstalled with libsystemd0. However, it is
>> fragile because the file that needs to be diverted out of the way
>> is libsystemd.so.0.26.0 (the actual library fi
control: close -1
The line
default_principal_expiration = 0
does not appear in the kdc.conf Debian installs.
It sounds like this was a bug in your local configuration.
Am I missing something?
>>>>> "Mark" == Mark Hindley writes:
Mark> On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote:
>> Foo-package depends on the latest libsystemd0. I'm running
>> unstable or testing. The latest libsystemd0 isn't building on m
Hi.
I've looked a bit at the systemd code as compared to the elogind code.
One of the major reasons that libsystemd0 cannot be used as a
replacement for libelogind0 is that elogind does not have compatible
cgroup naming.
The systemd (and elogind) libraries do some operations over dbus.
But other
> "Mark" == Mark Hindley writes:
>> If we are going to use c/r/p libsystemd0, is there some way we
>> can limit the potential damage to people who have positively
>> indicated that they want to run a non-default init system? One
>> of the concerns is what happens if apt deci
> "Mark" == Mark Hindley writes:
Mark> Julian,
Mark> On Wed, Sep 11, 2019 at 02:28:55PM +0100, Mark Hindley wrote:
>> > I don't think it's reasonable to ship this package with C/R/P >
>> libsystemd0.
>>
>> I understand that you don't like it. However, for libelogind0
>>>>> "Adam" == Adam Borowski writes:
Adam> On Wed, Sep 11, 2019 at 09:15:58AM -0400, Sam Hartman wrote:
>> I reached out to jcristau to talk about his block hint. Based on
>> our IRC discussion, it sounds like he was having trouble br
Dear Mark:
I reached out to jcristau to talk about his block hint.
Based on our IRC discussion, it sounds like he was having trouble
bringing himself to remove the hint presumably because he doesn't think
the broader issue was being dealt with.
I suggested that he might open his concerns as an
control: severity -1 wishlist
control: tags -1 wontfix
Dear Svante:
By repeatedly manipulating the severity of the bug, by removing the
wontfix tag, you are adding flames to a fire that does not need them.
We have procedures for disagreeing with a maintainer's approach to a
bug, and revert wars
>>>>> "Sam" == Sam Hartman writes:
>>>>> "Josue" == Josue Ortega writes:
Josue> On Mon, Sep 09, 2019 at 08:27:31PM -0400, Sam Hartman wrote:
>>> What are the security implications of enabling this configure
>&
>>>>> "Josue" == Josue Ortega writes:
Josue> On Mon, Sep 09, 2019 at 08:27:31PM -0400, Sam Hartman wrote:
>> What are the security implications of enabling this configure
>> flag?
Josue> Enabling this flag lets rpcbind to open random l
What are the security implications of enabling this configure flag?
Why is it off by default?
control: tags -1 fixed-upstream
The next major version of krb5 will be able to use python3 for docs
building, which is the major remaining use of python2 in the krb5
build/test system.
I expect that we'll be moving to that version soon enough that it will
not be a problem.
If things progress and y
> "Mark" == Mark Hindley writes:
Mark> Michael,
Mark> On Tue, Sep 03, 2019 at 04:56:13PM +0200, Michael Biebl wrote:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934491
>>
>> This bug report should be taken into account here. Not sure why
>> this is not marked
> "Mo" == Mo Zhou writes:
Mo> Hi -devel, I've just filed an RM(#935769) bug against
Mo> src:tensorflow and I believe this is the most appropriate choice
Mo> at this stage. For packages that would easily draw attention
Mo> from the media, not providing them would be much better
package: node-lodash
version: 4.17.11+dfsg-4
The entire description is:
Description-en: Lo-dash is a Node.js utility library
Lo-dash is a Node.js utility library delivering
consistency, customization, performance, & extras.
>>>>> "Felix" == Felix Lechner writes:
Felix> Hi Sam,
Felix> On Wed, Jul 31, 2019 at 8:45 AM Sam Hartman
wrote:
>>
>> I'd recommend starting out with warning. Some day it might move
>> to error, but I think starting o
> "Chris" == Chris Lamb writes:
Chris> (Tagging moreinfo as appropriate.)
I'm assuming that you're arguing that the lintian maintainers should
supply this more info.
Deciding on stuff like this seems well outside what I should be expected
to do as someone writing up a consensus from debi
> "Chris" == Chris Lamb writes:
Chris> (Oh, it is not clear to me why you would mention DPL or
Chris> disavow being a Lintian maintainer; I addressed my question
Chris> to you as you filed this bug, not in any other context or
Chris> mode? I mention it in case I can missing so
control: tags -1 -moreinfo
> "Chris" == Chris Lamb writes:
Chris> I mean we could certainly just whitelist all of
Chris> src:haskell-*, but isn't the entire point of this tag to ask
Chris> people to move to the dh sequencer? Or is it "actually fine"
Chris> for them to use hli
control: tags -1 -moreinfo
> a) Name of this tag (eg. "package-does-not-use-dh")
That seems like a fine name
> b) The "long description" of the tag with a brief rationale,
references, etc.
The recommended way to implement the build process of a Debian package,
in the absence of a good r
package: installation-report
Hi. Figuring out which package a bug belongs on in DI is harder than I
had time for. I figure writing up experience is more valuable than
simply ignoring the problem.
Andy copied because he was interested when I talked to him in person.
My friend Matt (copied) was
Either of these approaches would have been enough to make things less
intimidating to me.
You're most welcome.
I figure between Ubuntu and Fedora we can go find all the bugs we need
to fix before Debian bullseye/the next RHEL for a change like this.
control: severity -1 grave
This is grave: it breaks a related package. I want to avoid this
migrating into testing until we figure out what to do here.
I agree you have identified the right options.
Greg, the issue here is that NFS calls
gss_krb5int_set_allowable_enctypes so the kernel can pa
package: openafs-krb5
version: 1.8.2-1
tags: bullseye
Hi.
In krb5 1.17-4, DES is entirely removed.
src/aklog/aklog.c makes it look like openafs still requires
des-cbc-crc. If so, please upgrade this bug to RC.
Kaduk thinks that's probably not the case though.
If not, please consider removing t
control: severity -1 serious
Adam, playing severity pingpong games is *not* helping me work with
Michael to try and mediate and get you answers to your questions here.
I'm raising the severity back to RC. I've also told Michael that I
think it is important for a non-maintainer submitter of a bu
My second still applies to the following diff; I agree this is
consistent with the discussion so far.
diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index ee9270d..93beb4a 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -259,13 +259,33 @@ files, sockets or setuid or setg
control: tags -1 wontfix
So, the krb5 packages as installed log to syslogd/journald and do not
log to kdc.log.
debian edu is doing something to change that, which is probably a debian
edu bug. Also, it seems likely that if debian edu is messing with the
config files of krb5, it's a serious bug u
> "Paride" == Paride Legovini writes:
I think you could make a compelling argument for an important bug for
this because for those users it will make the package unusable.
I'm not a stable release team member though.
Michael, I've been asked to try and mediate this bug.
Unfortunately, to do that, I'm going to need to ask at least one
question that Adam is already asked. I can assure you that I'm not as
smart as you believe he is, so I really am going to need some help to
understand the situation:-)
What ar
Regretfully, I was unable to validate my hypothesis.
We really need better explanations about why skipping this test is
appropriate.
--Sam
Hi, Paul.
I can think of a number of cases why docker tests might be problematic
in our build environment.
I actually think that if these tests run in a VM but not in a build
environment within a schroot, it's a fairly good sign that the tests
are problematic the way we do builds.
I'll try to do
> "tony" == tony mancill writes:
tony> Hi Paul,
tony> I emailed ar...@buildd.debian.org regarding that this morning
tony> (at 13:35 UTC), but haven't received a response yet. Perhaps
tony> related, but the first arm64 build failed for the upload to
tony> unstable last we
I believe that both Russ's text and Sean's revised text capture the
project level discussions.
I also believe that given those discussions the issues are well
understood enough for us to move forward relatively quickly if new
issues are not raised here. I believe that Russ has adequately
respon
> "Sean" == Sean Whitton writes:
Sean> Let me try to express what I think the problem is. What the
Sean> first sentence says, given the equivalence of RECOMMENDED and
Sean> SHOULD noted above, is "you should use dh unless there is a
Sean> reason not to use dh".
Sean> How
301 - 400 of 1338 matches
Mail list logo
