> "Helmut" == Helmut Grohne writes:
Helmut> In this work, limitations with --chroot-mode=unshare became
Helmut> apparent and that lead to Johannes, Jochen and me sitting
Helmut> down in Berlin pondering ideas on how to improve the
Helmut> situation. That is a longer story, but
> "Richard" == Richard Lewis writes:
Richard> Otto Kekäläinen writes:
>> Could you point me to some Debian Bug # or otherwise share
>> examples of cases when a build succeeded locally but failed on
>> official Debian builders due to something that is specific for
>> sbuil
> "Daniel" == Daniel Markstedt writes:
Daniel> Hi all, I have drafted a release of the netatalk package
Daniel> that addresses 5 critical deb bugs. However, I myself am
Daniel> only an uploader in name and don't yet have actual upload
Daniel> privileges. And my co-maintainer
> "Andreas" == Andreas Tille writes:
Andreas> Are there any blockers to accept this DEP which I might
Andreas> have missed?
Honestly, the git-buildpackage default layout is good enough, and dep-14
involves change that doesn't feel like it brings enough value to me.
I.E. I think t
Hi folks. I've just uploaded Mit Kerberos 1.4.3-1 to experimental.
I'm writing to you because your package links against the main
kerberos library (libkrb53) and I'd like you to confirm that the
Kerberos support in your package still works against this version.
The public ABI and API of MIt Ker
> "Chip" == Chip Salzenberg <[EMAIL PROTECTED]> writes:
Chip> Who does a developer have to fuck around here to get his key
Chip> deleted? -- Chip Salzenberg <[EMAIL PROTECTED]>
Chip> -- To UNSUBSC
Hi. As you are no doubt aware by now, getting your key removed is a
great myster
In order to actually get something done in an electronic office, we
need a certain amount of infrastructure. In a large environment, the
incremental costs are somewhat visible, but you won't see how much
work it took to get there. In practice, starting from ground zero
means identi
> "Bernd" == Bernd Eckenfels <[EMAIL PROTECTED]> writes:
Bernd> Hello Sam, On Sat, Dec 30, 2000 at 11:27:44PM -0500, Sam
Bernd> Hartman wrote:
>> In order to actually get something done in an electronic
>> office, we need a certain amount of infrastructure.
Bernd> Thanks f
> "Gerfried" == Gerfried Fuchs <[EMAIL PROTECTED]> writes:
Gerfried> * Sven Luther <[EMAIL PROTECTED]> [2003-05-16
Gerfried> 13:33]:
>> Such a package should be as close to possible to the version
>> actually in testing, and not depend on packages and/or versions
>> that ar
[Please cc me; I'm very behind on -devel]
I'm very confused by this bug and am sufficiently busy this week that
I'm not going to be able to diagnose it right now.
Could anyone who has a chance to do so please look at exactly what is
failing from a dependency standpoint?
I get the feeling I'm
> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
Joey> Steve Langasek wrote:
>> - It will now be possible to choose md5 vs. crypt passwords at
>> install time without violating policy. (Currently, a number of
>> conffiles are being modified by maintainer scripts in order to
Does the krb524 functionality disappear from the KDC if you turn off
krb4?
If so, that will be a problem for current openafs, although probably
not for future openafs.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Last night I uploaded a more or less rewrite of krb5-config to
experimental. The goal of this rewrite is to significantly reduce the
number of cases where users are asked questions or where the resulting
configuration is completely wrong.
krb5-config is responsible for generating /etc/krb5.conf
I'd recommend coordinating any such model with the upstream Kerberos
implementations and with distributions.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Folks, there was a longish discussion on IRC starting about an hour
ago about dash and bash.
I agree we want to move the default /bin/sh to /bin/dash.
However I'm failing to understand why we want dash to be essential.
If I'm not using dash as my /bin/sh why do I need it?
If the answer is that
> "Luk" == Luk Claes writes:
Luk> We want everyone to use dash by default. If someone does not
Luk> want to use the default, they are free to do so, but the
Luk> default system shell is supposed to always be on the system.
Why?
I agree something should always provide /bin/sh.
I do
> "Siggy" == Siggy Brentrup writes:
8
>> I agree we want to move the default /bin/sh to /bin/dash.
>> However I'm failing to understand why we want dash to be
>> essential. If I'm not using dash as my /bin/sh why do I need
>> it?
Siggy> So you are complaining about a smal
Steve, let's take a step back and calm down.
Are you saying that your objection to engineering a solution where
dash doesn't need to be essential is that it's not worth the effort?
I *think* that was the point of your message but am not entirely sure.
--
To UNSUBSCRIBE, email to debian-devel-re
>>>>> "Steve" == Steve Langasek writes:
Steve> On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote:
>> Steve, let's take a step back and calm down.
>> Are you saying that your objection to engineering a solution
>> where
Hi, folks.
I've just uploaded krb5 1.6.1 to experimental. This is a new version
with enhanced plugin support, support for realm referrals, support for
storing Kerberos credentials in the Linux keyring rather than on disk,
and generally improvements all around. The one big feature that is
missi
> "Marcus" == Marcus Better <[EMAIL PROTECTED]> writes:
Marcus> Russ Allbery wrote:
>> Correct. In general, you never want to have Kerberos keys in
>> your KDC for a service principal for enctypes that that service
>> doesn't support.
Marcus> Is there an easy way to find
Yeah, I'm reasonably sure that alternatives are wrong for kadmin.
Editor is intended to be used by a user. Kadmin is often used by
users but is also quite often used by scripts.
Editors also can all work with text files. It's basically not true
that you can use a heimdal kadmin against an MIT re
package: wnpp
severity: wishlist
owner: hartm...@debian.org
name: krb5-appl
URL: http://web.mit.edu/kerberos/dist/krb5-appl
License: MIT Kerberos license
(roughly MIT license plus a requirement that if you modify the
software you must mark it as modified)
description: Contains fairly anci
> "Matt" == Matt Zimmerman <[EMAIL PROTECTED]> writes:
Matt> I think a single "Will you be using NIS?" question would be
Matt> justified; this could provide defaults for md5 vs. crypt
Matt> passwords and setuid-ness of unix_chkpwd, and so those
Matt> questions could be suppress
> "Andreas" == Andreas Metzler <[EMAIL PROTECTED]> writes:
Andreas> Steve Langasek <[EMAIL PROTECTED]> wrote:
>> On Fri, Nov 14, 2003 at 11:37:45AM -0500, Matt Zimmerman wrote:
Andreas> [...]
>>> > I'd rather see a solution where we have some nis support
>>> package that >
> "aj" == Anthony Towns writes:
aj> or overloaded with work, or, for that matter, fixing compromised Debian
aj> servers -- do you think it's desirable and possible to:
aj> * for confirmed bugs with a known fix, upload a fixed package
aj> within a day or two
> "Christian" == Christian Surchi <[EMAIL PROTECTED]> writes:
Christian> Ari wrote to me in the end of october to ask me about
Christian> my intention about logjam packaging. I had an enormous
Christian> backlog and I could not be able to reply. Then he filed
Christian> a wish
> "Russell" == Russell Coker <[EMAIL PROTECTED]> writes:
Russell> Do we have a library in Debian that provides reliable
Russell> stream based communication over UDP?
librx from openafs provides this functionality; it may be somewhat
more complexity than you are looking for.
> "Ari" == Ari Pollak <[EMAIL PROTECTED]> writes:
>> IIRC Ari has caused upset with NMUs before; xscreensaver, I
>> believe. (I express no opinion about whether that upload was a
>> good idea or not.)
Ari> Didn't you sponsor the upload?
Um, so? While yes the sponsor is at
> "Ari" == Ari Pollak <[EMAIL PROTECTED]> writes:
Ari> I had been taking the full brunt of the responsibility for
Ari> the xscreensaver NMU, but since I was a pre-NM at the time
Ari> and sponsors of uploads are supposed to follow Debian policy
Ari> as well, he ended up taking m
Won't removing kernel-source-2.4.18 create a problem for other arches?
Yes, the machine had a bad disk crash and I restored the other
services but failed to get debian-kerberos working. IT is up now.
Hi.
I noticed that in order to implement your read-only root proposal, you
propose to modify the pam package.
I'm not really sure I see the justification for read-only /. I can
see several possible justifications and some of the possible goals
conflict.
Until you get general consensus on a spe
>>>>> "Jamie" == Jamie Wilkinson <[EMAIL PROTECTED]> writes:
Jamie> This one time, at band camp, Sam Hartman wrote:
>> Until you get general consensus on a specific goal, I'm
>> unlikely to accept such changes if they are submitted
OK, I think my worst fears are realized. You do actually want to
solve all the goals I could have imagined you possibly wanting to try
try and solve.
I think I am very likely to wait until there is a policy change or at
least text that would be good guidelines as a policy change before
implementi
[I'm responding to Herbert directly to draw attention to this question
and make sure I get a response from him. I have also read the rest of
this thread even though I am responding to a fairly early message. ]
I'm approaching this as the maintainer of the openafs package, which
has a kernel mod
> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes:
Herbert> I doubt the increase is going to be that significant.
Herbert> Since most of these will eventually become part of the
Herbert> mainstream kernel or get dropped.
I hope that is not actually the trend we see.
>> im
[cc list is an attempt at stakeholders for this issue. If I missed
people, I'm sorry. If I annoyed people by ccing them even though they
read the list, well I'm sorry too, but there are a fair number of
people who tend to want to be explicitly cc'd when an issue pertains
to them.]
Summary: He
One thing that strikes me as excellent about Debian is the build
system. The autobuilders and tools make it very likely that package
builds are reproducible and a variety of tools like debhelper make it
easier to do the "right thing" in many circumstances than doing
something wrong. I've come a
> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes:
Herbert> BTW, this is how the kernel images are organised on
Herbert> alpha/i386/sparc.
This is misleading. The kernel-image-*-arch packages are much simpler
because they do not depend both on a kernel source package and on a
mod
L PROTECTED] (kernel-image-i386 maintainer),
[EMAIL PROTECTED] (concerned about package size)
Subject: Referring what kernel-images to build to the technical committee?
Reply-to: debian-devel@lists.debian.org
From: Sam Hartman <[EMAIL PROTECTED]>
Resent-Message-ID: <[EMAIL PROTECTED]&
L PROTECTED] (kernel-image-i386 maintainer),
[EMAIL PROTECTED] (concerned about package size)
Subject: Referring what kernel-images to build to the technical committee?
Reply-to: debian-devel@lists.debian.org
From: Sam Hartman <[EMAIL PROTECTED]>
Resent-Message-ID: <[EMAIL PROTECTED]&
>>>>> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes:
Herbert> Sam Hartman <[EMAIL PROTECTED]> wrote:
>> This is misleading. The kernel-image-*-arch packages are much
>> simpler because they do not depend both on a kernel sour
> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Brian> I have got a bug report #95246 requesting Heimdal be
Brian> compiled against openldap2. This would enable being able to
Brian> store the Kerberos database in the openldap database. All
Brian> data is stored in LDAP encry
> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
Joey> If these tools become widly enough accepted that we think
Joey> everyone should have them available by default, we can make
Joey> them standard priority.
In the new universe (debbootstrap, tasksel, etc) where a user might
nev
> "Petr" == Petr Cech <[EMAIL PROTECTED]> writes:
>> Since this question is currently being referred to legal
>> advice, do you want me to move postgresql into non-us, which
>> will force any packages depending on it into non-us too, or
>> should I leave it alone pending resol
> "Ivan" == Ivan E Moore <[EMAIL PROTECTED]> writes:
Ivan> Solution?: create a program (update-dm?) that would pull
Ivan> the current list of window/session-managers installed on the
Ivan> system and build the appropriate config files for whichever
You should probably consider w
> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>> "Aaron" == Aaron Lehmann <[EMAIL PROTECTED]> writes:
Aaron> So you're saying it's better to hardcode syscall numbers
Aaron> and stuff than using the kernel headers? Sre...
Manoj> We already have a process f
>>>>> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes:
Herbert> Sam Hartman <[EMAIL PROTECTED]> wrote:
>> We do? please explain what it is. Herbert produces kernel
>> headers packages for all flavors of kernels he produce
> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes:
Herbert> I won't look at all of them as this is really the
Herbert> upstream maintainer's job.
This brings up an interesting point. While we should work with
upstream maintainers to fix these problems, we should also try to
avoid
So, a week or so ago, I asked for comments on some problems I've been
having with the Debian kernel modules build system for modules not in
the Linux source tree. I'm only dealing with modules for upload to
Debian. The make-kpkg solution seems to work for individuals building
modules for their
>>>>> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes:
Herbert> Sam Hartman <[EMAIL PROTECTED]> wrote:
>> for needs to be determined by the architecture maintainers.
>> For Sparc, modversions are not used so you can probably buil
>>>>> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes:
Herbert> Sam Hartman <[EMAIL PROTECTED]> wrote:
>> This brings up an interesting point. While we should work with
>> upstream maintainers to fix these problems, we should a
>>>>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>> "Sam" == Sam Hartman <[EMAIL PROTECTED]> writes:
>>>>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>>>> &q
> "Henrique" == Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
Henrique> AFAIK, I cannot do that. If I build against testing, I
Henrique> help the breakage by adding yet another package that
Henrique> depends on the outdated libraries that are in testing,
Henrique> th
> "Marc" == Marc Haber <[EMAIL PROTECTED]> writes:
Marc> On Sun, 2 Sep 2001 22:49:00 +0200 (CEST), Santiago Vila
Marc> <[EMAIL PROTECTED]> wrote:
>> However, you can repackage the .orig.tar.gz source and remove
>> the non-US bits from it. Then you could upload both source and
> "Jules" == Jules Bean <[EMAIL PROTECTED]> writes:
Jules> This seems a step back from the old freeze procedure, where
Jules> you could upload to frozen (and, I assume, auto-builders
Jules> were building against frozen)
Well, once your library and all dependencies are frozen you
>>>>> "Marc" == Marc Haber <[EMAIL PROTECTED]> writes:
Marc> On 02 Sep 2001 23:18:56 -0400, Sam Hartman
Marc> <[EMAIL PROTECTED]>
Marc> wrote:
>>>>>>> "Marc" == Marc Haber
>>>>>>
> "Randolph" == Randolph Chung <[EMAIL PROTECTED]> writes:
>> The Automatic Package Building System page[1] lists the build
>> daemons with web pages. It does not list those without,
>> however. Since my latest libcdaudio packages are considered
>> out of date on i386, I was
package: wnpp
severity: wishlist
Hi. AS discussed below, I intend to package OpenSSH using the current
Debian sources with patches to allow krb5 authentication. I will use
the patches available at
http://www.sxw.org.uk/computing/patches/openssh.html. These patches
attempt to comply with draft-i
package: wnpp
severity: wishlist
I'm planning on packaging libsasl2-gssapi-mit, a version of the GSSAPI
plugin for libsasl2 compiled against MIT Kerberos.
This package has the same source as cyrus-sasl2, but different build
environment and options. It's not really possible to avoid having two
so
[There are some questions at the end; comments would be greatly
appreciated on the questions if you have ever been involved in the
release process or library transitions before. This is my first big
transition.]
The libkrb53 package (providing the MIT Kerberos shared libraries) has
been stable f
>>>>> "Julien" == Julien BLACHE writes:
Julien> Sam Hartman wrote: Hi,
>> That is, if I made the dependency in libkrb5-3.symbols look
>> like libkrb5-3|libkrb53 (and similar changes for other symbols
>> files), then both the package
>>>>> "Sam" == Sam Hartman writes:
>>>>> "Julien" == Julien BLACHE writes:
Julien> Sam Hartman wrote: Hi,
>>> That is, if I made the dependency in libkrb5-3.symbols look
>>> like libkrb5-3|libkrb53 (and simi
> "Julien" == Julien BLACHE writes:
I really appreciate your help here!
Julien> As you note in your second reply, the goal is to decouple
Julien> the packaging change from the krb4 dismissal: 1 introduce
Julien> libkrb5-3 (Replaces: libkrb53), with libkrb53 depending on
Julie
OK, so I think we're all set.
The plan now is to
1) Build twice, once into build and once into build-krb4. We only
pull libkrb4.so out of build-krb4. 2) Move all the libraries out of
libkrb53 and libkadm55 (sorry, in my previous mails I was simplifying
a bit) except for libkrb4.so.2.
3) Make
> "Brian" == Brian May writes:
Brian> Ben Finney wrote:
>> I invite anyone interested in knowing how the distinct areas of
>> identity, trust, and security intersect with the OpenID system,
>> to research the available documentation.
>>
Brian> ...except openid has se
>>>>> "Sam" == Sam Hartman writes:
Sam> OK, so I think we're all set. The plan now is to
Sam> 1) Build twice, once into build and once into build-krb4. We
Sam> only pull libkrb4.so out of build-krb4. 2)
This works at least.
> "Steve" == Steve Langasek writes:
Steve> Actually, I was meaning to comment on this. Why would you
Steve> not simply point the shlibs at the component library
Steve> packages at this stage? The only side effect is that the
Steve> version of krb5 that includes the split lib
>>>>> "Julien" == Julien BLACHE writes:
Julien> Sam Hartman wrote: Hi,
>> It turns out this fails impressively. The problem is that the
>> library packages depend on each other. So, for example,
>> libk5crypto3 is needed by li
Folks, I'd appreciate it if people could try and test version
1.6.dfsg.4~beta1-8 from experimental of the krb5 package.
The biggest change is a packaging reorganization. So, while I'm
certainly interested in Kerberos users testing the packages, I'm most
interested in people other than me conf
I'd like to chime in with the general concern that the proposal to
remove a bunch of groups from udev seems under-baked and that the
current groups have value.
I definitely would like to see the tss (tpm) group remain along with
the kvm and fuse groups. I think scanner is important as well.
I ca
package: wnpp
severity: wishlist
owner: hartm...@debian.org
URL: git://git.project-moonshot.org/trust_router.git
http://www.project-moonshot.org/
license: bsd-3-clause
Description: The trust router establishes a DH key between two RADIUS
servers to protect a RADIUS over TLS session. GSS-API au
package: wnpp
severity: wishlist
owner: hartm...@debian.org
URL: http://www.shibboleth.org/
Source: svn https://svn.shibboleth.net/extensions/cpp-sp-resolver/trunk
Description: Shibboleth library to access Attribute Resolver
The Shibboleth Service provider consumes information about an
authenti
package: wnpp
owner: hartm...@debian.org
severity: wishlist
URL: http://www.project-moonshot.org/
source: git://git.project-moonshot.org/moonshot-ui.git
License: BSD-three-clause
Description: Project Moonshot provides federated access to services
combining the best of EAP, RADIUS (over TLS), SAML
package: wnpp
severity: wishlist
owner: hartm...@debian.org
URL: http://www.project-moonshot.org/
source: git://git.project-moonshot.org/moonshot-ui.git
license: BSD-3-Clause
Description: This package manages the Moonshot identity store,
permitting users to add and remove identities as well as to
package: wnpp
severity: wishlist
owner: hartm...@debian.org
x-debbugs-cc: debian-devel@lists.debian.org
source: git://git.project-moonshot.org/mech_eap.git
license: BSD-3-Clause
Description: Project moonshot provides federated access to a wide range
of applications. This package adds a GSS-API m
Hi. back in 2011, I gave a talk at Debconf about the value of Debian to
people hoping to put together changes across an operating system. I was
using my work in Project moonshot as an example; we've been looking at
integrating new security services throughout an operating system.
Debian has bee
Early morning, Wednesday, November 19, the results of the GR on init
system coupling will be announced.
No result will make everyone happy. In fact, that morning, some of our
developers, users and contributors will be really unhappy.
I would be dishonest if I said I didn't hope to be happy and r
Hi.
I've read the original proposal and believe it is generally going in the
right direction.
things I liked:
* didn't pick between dgit/git-dpm/git-pq; documented the common parts
* Seemed to really focus on one clear scope.
* Discouraged overlay packaging.
I've tried to read the arguments, an
> "Patrick" == Patrick Ouellette writes:
Patrick> On Thu, Nov 13, 2014 at 11:06:08PM +0100, Matthias Klumpp wrote:
Patrick> I did not ask for evangelization about how wonderful binary
Patrick> logs are, nor for a lesson on how to get the info out of
Patrick> systemd with the
> "Patrick" == Patrick Ouellette writes:
I think this is a bug.
On my system things get logged both to the journal and to
/var/log/syslog.
My understanding talking to systemd folks is that the behavior I'm
seeing is intended and that unless you went out of your way to
configure something di
package: syslog-ng-core
severity: important
version:3.3.5-4
justification: does not enable systemd unit.
syslog-ng-core's postinst does not enable its syslog unit.
I'm guessing that including systemd in the dh sequence is not quite
doing enough to actually turn it on.
Unfortunately dh-systemd i
> "Russ" == Russ Allbery writes:
>>> A second option is to migrate on upgrade the uid/gid information
>>> into an override in /etc/systemd/system. Requires dealing with
>>> a dynamically generated config file in preinst/postinst, though,
>>> which means the tools that help pr
> "Didier" == Didier 'OdyX' Raboud writes:
Didier> Systems cross-craded from Ubuntu to Debian are absolutely
Didier> not supported, and I wouldn't be surprised if some of the
Didier> issues you're seeing are in some way related to this.
I've seen both these issues on pure Debian
> "Didier" == Didier 'OdyX' Raboud writes:
Didier> Steve's suggestions stands though: separated and actionable
Didier> bugs for these two issues filed on the corresponding
Didier> packages are way more helpful than a general "non-sysvinit
Didier> init systems are made of fail"
package: wnpp
severity: wishlist
URL: https://fedorahosted.org/libverto/
Description: libverto provides a common interface on top of libev, libevent,
glib, tevent.
The goal is to allow development of asynchronous libraries that will work
with whatever event loop an application happens to be u
package: wnpp
severity: wishlist
URL: libradsec branch of http://www.project-moonshot.org/gitweb/radsecproxy.git
URL2: http://software.uninett.no/radsecproxy/
Description: libradsec is a library for RADIUS clients and servers
This library features support for RADSEC (RADIUS over TLS/DTLS) as wel
For myself, I'd feel a lot more comfortable with DDs seconding than DMs
seconding.
In my mind, when you sign up to be a DM, you're signing up to do a good
job of maintaining one or more packages.
In my mind a part of the additional commitment in agreeing to be a DD is
to think about the broader
hi.
A few months ago, Russ Allberry stepped down from co-maintaining
krb5-appl.
I'm reasonably happy to keep maintaining it, although when we thought
about it, we cannot think of anyone using the package.
It provides krb5 versions of rlogin, rsh, ftp and telnet.
The telnet is insecure and should
FWIW, I'm not seeing enough demand that I'm interested in maintaining
krb5-appl.
I plan to request removal.
If there's a debian developer who thinks I'm making the wrong call they
should feel free to turn my removal request into a request to adopt the
package.
--Sam
--
To UNSUBSCRIBE, email
control: subscribe -1
> "Charles" == Charles Plessy writes:
Charles> The 3.0 (native) format is useful when packaging a work
Charles> that is developped and distributed in a Git repository.
Charles> Please leave us this possibility.
Let me describe the use case I have which is
>>>>> "Andreas" == Andreas Beckmann writes:
Andreas> On 2014-02-05 10:57, Sam Hartman wrote:
>> tarballs useful; anyone who is likely to want to build this from
>> source probably has a copy of git and can checkout a tag.
Andreas> Su
I've tried to do a reasonable job with the krb5-config package of
updating a user-managed krb5.conf and keeping it in sync with debconf
data.
It's quite old and I doubt it's best practice any more but it is an
example of how to approach a non-shell-script package.
The debconf-managed comment is an
> "Neil" == Neil Williams writes:
That makes sense and I do something similar as appropriate. Even so, I
do not wish to maintain the upstream tarball as a maintained artifact.
There are cases where packaging release releases are made. Maintaining
pristine-tar commits for daily builds is a
> "Bernhard" == Bernhard R Link writes:
As I mentioned I have a packaging branch and an upstream branch.
I wish to use debian revisions to reflect packaging changes.
It's slightly more complex than changes to debian directory involve a
debian revision change; changes to other things involve
> "Russ" == Russ Allbery writes:
Russ> Ian Jackson writes:
>> Secondly, there doesn't appear to be any support in policy for
>> this restriction.
Russ> Policy definitely supports this restriction, as Guillem
Russ> pointed out. I want to echo that analysis as one of the
> "Russ" == Russ Allbery writes:
>> Citation requested. I looked for this today and couldn't find
>> it.
Russ> Policy lacks a section that clearly defines native and
Russ> non-native packages, which is a long-standing bug in Policy.
Russ> Currently, that information is i
> "debianfan" == debianfan writes:
debianfan>I would like to propose forking Debian if the ctte
debianfan> committee selects systemd
It's with great hesitation that I jump in here, and I know what I'm
doing is wrong.
I hope I've earned enough credibility over the years in the
Thanks for sharing this.
So, you're frustrated and very disappointed because Ddebian, something
you cared about deeply has drifted so far away from what you want that
you can no longer support it?
I hope that if you decide to fork, you succeed in creating something
that meets your needs. I hope t
1 - 100 of 458 matches
Mail list logo
