Don Armstrong wrote:
> > Other tags and BTS data can be used if desired. For example,
> > "divergence fixed-upstream", "divergence wontfix", "divergence
> > help". Versioning information can be used to track when an upstream
> > version resolves the divergence. Discussion and updated patches can
>
Don Armstrong wrote:
> One of the wishlist features for the BTS that I've been contemplating
> setting up is a "summary" feature, whre the current summary of a bug
> is shown at the top, with the history continuing below.
Ah, I think that's the thing I was remembering from the DEP thread.
A mail
Lucas Nussbaum wrote:
> (This discussion is similar to the one about DEPs vs BTS bugs -- a
> discussion on the BTS would always miss a "summary".)
IIRC someone (possibly me or maybe it was aj) posted a design to solve
the lack of a bug summary in the DEP thread.
--
see shy jo
signature.asc
Des
Pierre Habouzit wrote:
> No I read them, and I'm interested in how you intend to do so
> _automatically_. Because if it isn't automatic, then we're back to the
> current situation _plus_ filing bug in our own BTS. I fail to see where
> the revolution is.
>
> And I believe the "automation" of s
Russ Allbery wrote:
> At first glance, I liked this idea in general, but some of the details
> make me wonder if the same concept implemented as a patch tracker separate
> from the BTS would work better. I'm still not sure, though, so some
> thinking out loud about the pros and cons.
Sure (and I
Pierre Habouzit wrote:
> The 3 first. I assumed that everyone knows it's best to present a
> summary of your idea in the first paragraph.
You seem to have actually missed the second sentence, "A change might be
a bug in upstream, or in the debianisation, or in Debian for requiring
the change.".
Pierre Habouzit wrote:
> Okay, still I dislike the idea a lot.
You actually only read the first sentence at first?
> the BTS is unusable past 100 bugs.
Every package accumulates > 100 closed bugs after some period of time,
and this does not make the BTS unusable for that package, because the
c
Loïc Minier wrote:
> The bug tracker is a tool for me; not everything needs to go via bug
> tracking.
I'm not thinking about using the BTS for this just because it happens to
be the hammer at hand, but instead because it looks to be a tool that
allows solving a large percentage of the requiremen
Mike Hommey wrote:
> The BTS would also need something to make it easier to spot patches in a
> bug. Patch tracking is one of the few things bugzilla is not bad at, for
> instance.
I guess you're talking about a way for the BTS allow downloading of the last
(or preferred) patch sent to a bug. And
What if we just decide that changes made to upstream sources[1] qualify
as a bug? A change might be a bug in upstream, or in the debianisation,
or in Debian for requiring the change. But just call it a bug.
Everything else follows from that quite naturally..
The bug can be tracked, with a patch, i
Josselin Mouette wrote:
> Are you deliberately omitting the sane formats to distribute patched
> debian sources that are implemented?
I'm talking about the formats that I expect to be using. The implication
thst I'm somehow insane is not very useful.
--
see shy jo
signature.asc
Description: Di
Raphael Hertzog wrote:
> On Fri, 16 May 2008, Joey Hess wrote:
> > Coming up with a complex set of requirements that everyone has to follow
> > up front in their workflow[1] is not going to yeld the best results, and
> > I think that's my core reason for disliking R
Theodore Tso wrote:
> How often is a logical change more than just a single commit?
I think the most common case for me is when I need to bring the change
forward to new upstream versions (with conflicts). In that case, I'll
end up with multiple commits in the VCS hostory for the change.
> So nor
Raphael Hertzog wrote:
> A VCS surely allows browsing and examining patches. But when I dig in a
> VCS history, it's because I have something precise to look up, I will
> rarely check it ouf of curiosity. debian/patches/ on the contrary is
> something that gets my attention when I unpack a source p
George Danchev wrote:
> Then comes even more, even Ben Laurie (as he writes in
> his blog) with all his aggression missed to find the debian's pkg-openssl VCS
> repo [1] unless he has been helped by someone at some point. I'm not against
> the VCS repo (I myself use some for my packaging), I jus
Josselin Mouette wrote:
> Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
> > You're insinuatiog that a VCS does not allow easily browsing and
> > examining patches, and I just don't buy it.
>
> I can do more than insinuating: a VCS does not allow
Raphael Hertzog wrote:
> I totally agree that we need to make our changes more visible. In the
> openssl case, the patch in question is inside the .diff.gz and you don't
> notice it in the unpacked source package. I tend to give a look to what's
> in debian/patches/ when I rebuild a package but not
It would be nice to have a list which Recommends are ignored/overridden
the most when installing packages, to identify Recommends that need to be
downgraded to Suggests. Could we derive such a list from popcon data? I
think it would need to be done by analyzing each individual popcon data
submissio
Josselin Mouette wrote:
> TTBOMK, triggers don’t tell you what has changed in a subdirectory.
Actually they do.
--
see shy jo
signature.asc
Description: Digital signature
I'm tracking all known trigger-related patches as well as todo items in
the wiki at http://wiki.debian.org/DpkgTriggers
--
see shy jo
signature.asc
Description: Digital signature
Josselin Mouette wrote:
> > - scrollkeeper
>
> It will probably be deprecated soon, so I don’t think it is necessary to
> put effort into it.
How soon? Before lenny? It's not much effort to triggerise this I think.
--
see shy jo
signature.asc
Description: Digital signature
Michael Biebl wrote:
> [1] Will changes to subdirectories (e.g /usr/share/applications/kde)
> also lead to a trigger
The docs don't seem to say, but my tests show that registering interest
does cause trigger updates for files in subdirs.
--
see shy jo
signature.asc
Description: Digital signatu
Suggested off-list: update-grub
I agree that this would be nice. Particularly if many old kernel
packages are removed, the multiple update-grub calls become annying.
--
see shy jo
signature.asc
Description: Digital signature
Michael Biebl wrote:
> > - update-icon-caches
> > - update-desktop-database
> > These are not very slow, nor used by a great many packages,
> > but triggerizing them would allow getting rid of dh_icons and
> > dh_desktop eventually, which I would appreciate.
>
> Sounds interesting.
>
Hubert Chathi wrote:
> > Things I want to see use triggers, in approximate priority order:
>
> [... snip very nice list ...]
>
> How about defoma? fontconfig?
defoma-app and defoma-font act on a specific application/font that is being
installed/removed. Converting this kind of thing to use trig
Rene Engelhard wrote:
> Maybe also fc-cache calls?
I don't have many of those here, but if desired I think it could be made
to use triggers, yes.
--
see shy jo
signature.asc
Description: Digital signature
Pierre Habouzit wrote:
> On Sun, Mar 30, 2008 at 08:25:15PM +0000, Joey Hess wrote:
> > - update-menus
> > Run by zillions of postinsts and postrms, many of these can be
> > gotten rid of entirely by using triggers, which is a big
> > complexity win.
> &g
dpkg in experimental supports triggers now, and in many cases trigger
support can be added to packages without creating a hard dependency on
a new version of dpkg.
Things I want to see use triggers, in approximate priority order:
- scrollkeeper
This is a huge speed pig, and d-i has hacks
Bas Wijnen wrote:
> This does break versions which go from 1 to 1.1 to 1.2 to 2 to 2.1, etc,
> but we're talking about native packages, which means we can expect
> upstream not to be so crazy.
People do this all the time, for completly sane reasons.
--
see shy jo
signature.asc
Description: Di
Please remind me when this or something similar gets into debian so I
can review it for possible inclusion in the desktop task.
--
see shy jo
signature.asc
Description: Digital signature
William Pitcock wrote:
> I think you mean package install-time improvements, due to postponing
> ldconfig until the end of the installation. However, I am not sure how
> useful this is because many maintainer scripts not generated by
> debhelper call ldconfig locally.
>
> Obviously the maintainer
William Pitcock wrote:
> On Sun, 2008-03-09 at 20:38 +0100, Raphael Hertzog wrote:
> > And what is the problem exactly? The delay in patch integration?
If you'd look at submitting patches to dpkg from the perspective of any
recent patch submitter, I'd think that the problem would be clear.
--
se
Charles Plessy wrote:
> Then, because "a consensus between the Release Managers and the
> developer community as a whole" has been required, a GR will be needed.
> Since it is a necessary step, the writing of it may be a useful tool to
> clarify arguments before presenting them to the persons in ch
Philipp Marek wrote:
> * Some files have a commit-pipe defined, so that eg. the passwords get
> stripped out of the shadow files.
> In case of a restore all passwords have to be set afresh.
> * For a few files that include passwords (like ddclient) there are
> already filters.
Is there some
Package: wnpp
Severity: wishlist
Owner: Joey Hess <[EMAIL PROTECTED]>
The nslu2 needs non-free firmware for its ethernet. This is currently
distributed in the d-i installation images on slug-firmware.net.
The firmware can be downloaded from
<http://downloadcenter.intel.com/Detail_Desc
Riku Voipio wrote:
> I think the short term solution to this dilemma is to compile a list
> of attributions needed to be included in advertizment material.
> Also a list should be compiled attributions needed n documentation
> (such as libjpeg's). Obviously most distributors/boob writers will
> not
Daniel Leidert wrote:
> Why should I mirror the upstream VCS and blow up
> svn.d.o or my own VCS servers?
Because disk space is so much cheaper than your time that I can't even
find the adjectives to describe how much cheaper it is?
--
see shy jo
signature.asc
Description: Digital signature
Russ Allbery wrote:
> With that source package format, everyone using quilt or simple-patchsys
> can trivially satisfy this requirement, and most uses of dpatch are
> similarly trivial. It doesn't provide all of the power of a git or bzr
> package format, but it's a lot easier to implement
I hope
Clint Adams wrote:
> On Mon, Jan 28, 2008 at 05:37:03PM -0800, Russ Allbery wrote:
> > This work flow simply doesn't work with our current source package format
> > and a patch management system. Requiring this to work *with the current
> > source package format* essentially means outlawing using
Francois Marier wrote:
> Now the problem (see bug #462658) is that if you ever put a non-empty
> password there, then, you can no longer get rid of it after
> dpkg-reconfiguring the package. debconf seems to be ignoring empty password
> fields and still returns the previous value.
This is a defic
Would it be possible to get access to the binaries? I'm interested in
choose-mirror, localechooser, ikiwiki, libperl-critic-perl, and
fbreader, which differed only in package size between the two builds.
That's semi-understandable for choose-mirror, but I can't guess what
would make the others buil
Andreas Tille wrote:
> If you ask me personally the situation with zillions of competing
> VSC systems is even worse than the hand full of tools to build
> Debian packages. I personally refuse to switch VCS every six month
> because there is a newer and even better one if you trust the one
> or ot
FWIW, I'm very disappointed in this thread so far -- everyone in it
seems to be missing between 50 and 90% of the point of my blog post.
Pierre Habouzit wrote:
> Oh and don't try to ask for complete uniformity in packaging, there
> are 1000 DDs, 10 times as many packages, different needs (you do
Michael Biebl wrote:
> Another way would be, to make dpkg smarter about such cases.
> As you want to write a special utility for this, how would you hook this
> up into the install/upgrade process? If you have to edit maintainer
> scripts again, you haven't gained a lot imho.
You've gained not
Stefano Zacchiroli wrote:
> Yeah, but a point is: should we make the snippet in a package and then
> have a dependencies on this? This is going to be suboptimal since some
> of those snippets have to be called in preinst and pre-depends are not
> nice ...
Moving conffiles is very specific to dpkg,
Stephen Gran wrote:
> My concern with this is that it can be important to have the files moved
> in a particular order relative to other things happening in your
> preinst, and a single #DEBHELPER# token might not be flexible. I'm sure
> joeyh will come up with something simple, elegant, flexible
Petter Reinholdtsen wrote:
> I just noticed that when I rewrote the conffile removal code in
> initscripts recently, I copied code from
> http://wiki.debian.org/DpkgConffileHandling and accidently replaced
> the code that created *.dpkg-old files with code that would create
> *.dpkg-bak. I will ch
Ben Finney wrote:
> Why do you think "debian package" is proper capitalisation? What does
> the word "debian" refer to in that term, if not Debian?
A package format.
--
see shy jo
signature.asc
Description: Digital signature
Raphael Geissert wrote:
> Some weeks ago I noticed that some package descriptions incorrectly spell
> some project names, mainly because of capitalisation.
> For example GNOME is being spelt in some packages as Gnome, or simply gnome,
> when its right spelling: GNOME. Other project names such as De
Gabor Gombas wrote:
> IMHO there can be many init scripts that currently do not wait for the
> process to stop but they should if you want to do this refactoring. Some
> random checks:
If a package only shuts down cleanly because the rest of the shutdown
process is slow, it is already buggy. Espec
Thijs Kinkhorst wrote:
> Several DSA's have been stalled the past months because of missing i386
> builds. It would be great if we can reduce that.
i386 d-i is also broken due to missing i386 builds now. (partman-*
version skew)
--
see shy jo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
wit
Interesting idea, though so few packages lack dependencies that it won't
catch much. Perhaps grepping for package that don't depend on any shared
libraries would catch more?
Raphael Geissert wrote:
> maximilian attems <[EMAIL PROTECTED]>
>klibc
>linux-2.6 (U)
heh
> Andreas Barth <[EMAIL
Petter Reinholdtsen wrote:
> What about changing the default values for dh_installinit for a future
> debhelper compatibility layer, to use 'start 20 2 3 4 5 . stop 80 1 .'
> instead of 'default' when calling update-rc.d?
Then you'd have to use 'dh_installinit -- defaults' to get the
non-default b
Petter Reinholdtsen wrote:
> How does it more cleanly shut down X? That seem to be the logic
> behind providing all the stop scripts in runlevel 0 and 6, just to
> kill a process. There is nothing magic about sending a signal. :)
xdm's init scripts stops it by sending a TERM, waiting up to 5 sec
Petter Reinholdtsen wrote:
>
> [Andreas Metzler]
> > Is this acceptable according to policy? This will simply discard all
> > local customzations like disabling he service in a special runlevel.
>
> As far as I know, this is the official and supported way. There is no
> 'move' option in the upda
Petter Reinholdtsen wrote:
> Ubuntu discovered this a while back, and introduced a method to avoid
> calling stop scripts in runlevel 0 and 6. It is the "multiuser"
> extension to update-rc.d
Why is this extension not available in our update-rc.d? As a bonus it
could stop at sequence number 80 to
Miros/law Baran wrote:
> Ah, but it's been there, once. I remember that my first Debian
> installation included in the default setup all the accounts used by
> qmail (if not the qmail itself).
That's becaused qmail needs/needed hardcoded uids, so we created them.
Later this changed to reserving th
Ondrej Certik wrote:
> Hi,
>
> I recently become a Debian Maintainer, so I wanted to upload a new
> version of python-numpy package, relevant fields from debian/control:
>
> Maintainer: Debian Python Modules Team
> <[EMAIL PROTECTED]>
> Uploaders: Marco Presi (Zufus) <[EMAIL PROTECTED]>, Alexandr
Raphael Hertzog wrote:
> And shlibs files are ignored if dpkg-shlibdeps is able to find
> symbols files.
Ah, that wasn't clear, I must have missed that in the documentation.
--
see shy jo
signature.asc
Description: Digital signature
Florian Weimer wrote:
> * Russ Allbery:
>
> >> As I understand it, this is only the case on i386 - on other arches,
> >> /usr/bin/perl links to libperl, although the modules don't.
> >
> > ...indeed. That's bizarre. Why is i386 different than all the other
> > platforms?
>
> Performance penalty
Raphael Hertzog wrote:
> Given that shlibs are still used as fallback, I don't see a reason to
> remove -V, in particular given that unofficial archs might not have
> symbols files when they are arch-specific and when something specific
> needs to be done to add support for a new arch.
I thought t
Raphael Hertzog wrote:
> With debhelper 5.0.61, dh_makeshlibs will also call dpkg-gensymbols if it
> finds debian/.symbols (or debian/.symbols.). So
> for packages using debhelper, the only thing to do is to drop the right
> symbol file(s) at the right place and add build-depends on dpkg-dev (>=
>
So FWIW, I have aalib using a symbol file, it's what I used to test the
debhelper modifications. Haven't uploaded it yet because it will have to
build-depend on the recent dpkg bugfix. Also because dpkg-shlibdeps is
now smart enough to complain about some unnecessary linkages to things
like libm an
lpr's standard priority nonwithstanding, CUPS has been the default print
system in Debian -- if you select the desktop or print server tasks --
for at least the last two releases. This is why popcon shows 5000 lpr
installations to 45000 cupsys installations.
Yes, it would make more sense for samba
Josh Triplett wrote:
> Thus, I would argue that:
>
> * No locate should have standard priority as long as findutils
> contains locate.
> * locate should move out of findutils into a separate package.
> * Once that happens, if any locate should have priority standard,
> mlocate should.
> * Howe
Neil Williams wrote:
> I propose to file bugs against packages that use inconsistent
> DEB_BUILD_OPTIONS or which do not support DEB_BUILD_OPTIONS that would
> actually benefit Emdebian.
>
> As with the other mass bug filing from this set, I will tag the reports
> 'crossbuilt' and file as wishlist
Neil Williams wrote:
> In this context, I believe "package documentation" should mean:
> "All files in the package that are installed beneath /usr/share/doc
> which are not mandated by Policy."
>
> Therefore, copyright and changelogs are excluded as are manpage and
> info pages but README, TODO, A
Kurt Roeckx wrote:
> Atleast some packages now don't run the testsuite when
> DEB_BUILD_GNU_TYPE != DEB_HOST_GNU_TYPE.
>
> Are there any other reasons why testsuites shouldn't be run?
Speed, and wanting to build a package even if its test suite is broken,
I guess.
Neil Williams wrote:
> There ne
Bart Samwel wrote:
> I wouldn't mind having the packages installed in the laptop task if that
> fixes it. However, the laptop task currently uses the task-fields method,
> which AFAICT means that the dependent packages should list themselves as
> being part of the laptop task, something that wil
Josselin Mouette wrote:
> You may be interested to learn that we plan to downgrade a number of
> dependencies of the gnome metapackages to Recommends.
>
> If this means tracking them later on to be sure that everything needed
> is installed, maybe we need a way to improve the coordination between
Raphael Hertzog wrote:
> The problem is not so much on manually installed package but on initial
> installation. I'm not sure what would get installed via the laptop task if
> we made that a Recommends...
d-i can't afford to install recommends by default (best way to change
that is to make all use
Colin Watson wrote:
> > I don't much like any of the switch ideas, since they would probably
> > not be able to express all possible collections of man pages (given
> > debhelper's current command line parser). The manpage:encoding idea
> > could work, but might have ambiguity issues with man pages
Colin Watson wrote:
> Once we have a consensus on install locations, dh_installman should IMO
> be changed to do the recoding automatically; to do this, it needs to be
> told the source encoding. Joey, what do you think is the best way to do
> this? Options that come to mind are:
>
> * --languag
Goswin von Brederlow wrote:
> Does that mean it purposefully fails 132 files, works flawless on the
> rest and has no more "weird" cases? Or is the 132 the sum of the two?
Yes, it detects it cannot handle the 132 and fails at delta creation
time, works correctly on all the rest.
--
see shy jo
Faidon Liambotis wrote:
> On the first run of the tool on the whole archive, pristine-gz succeded
> in recognizing 21869 of 22566 orig.tar.gz (almost 97% of the archive).
> It explicitelly failed on 206 of them (0.91%) while something weird,
> probably a bug, happened on the rest 491 (2.18%).
>
>
Felipe Sateler wrote:
> That defeats the purpose of autoconf, and makes much of automake's
> functionality redundant. If you are going to require automake, autoconf and
> libtool installed, why then generate the intermediate steps (configure and
> Makefile's)? Plus it defeats another goal of autoto
Josselin Mouette wrote:
> Le lundi 01 octobre 2007 à 20:00 +0200, Juliusz Chroboczek a écrit :
> > Since this particular bug is trivial to reproduce (ls ~/.mozilla/firefox/),
> > it would appear that the Firefox maintainers are mass-closing bug
> > reports without even checking what they are about.
Junichi Uekawa wrote:
> > [EMAIL PROTECTED]:~> pristine-tar stash
> > lib/debian/unstable/uqm-voice_0.3.orig.tar.gz uqm-voice.delta
>
> Hmm.. I don't quite understand why this stashing is required. Why
> would that be. Also another question would be, would it work, for
> example, with upstream w
both bsdgames and mono-mcs contain a "monop" program. bsdgames in
/usr/games, and the other in /usr/bin.
bsdgames's monop has been around since 1993 or so and has that name on
the bsd systems that bsdgames's games come from. It probably has few
users, so renaming would not be too annoying, aside f
Pierre Habouzit wrote:
> Now that the BTS has versionning, one can use the last version with
> the bug marked as "found" to know if the ping is necessary or not. If
> it's a BTS feature (and not done by the maintainer themselves) that
> would be, say, 2 mails a year (if those are triggered every
Pierre Habouzit wrote:
> later than today on IRC we discussed that, and _I_ find perfectly
> sensible that bugs that are opened for say 1 year, get a "ping" mail to
> the submitter to say (basically):
But not if the bug is a security bug, and not if the bug is forwarded to
an upstream BTS, where i
(Reposted here with additions from my blog, for people who don't read that.)
Keeping pristine upstream tarballs around is a pain, especially when working
in a team. Wouldn't it be nice to be able to keep them in revision control?
Except, it would use far too much disk...
Here's a solution. It gen
Joerg Jaspert wrote:
> On 11150 March 1977, Peter Eckersley wrote:
> > I've seen reports from very large sites indicating that User-Agent
> > strings are almost as useful as cookies for tracking their users.
>
> I cant believe this. Looking at the stats from packages.debian.org - U-A
> is the wors
Luca Capello wrote:
> This is strange: the Homepage field is shown for some packages [1] and
> not for others [2], e.g. reported below:
> =
> [EMAIL PROTECTED]:~$ apt-cache show ikiwiki | grep "^Homepage"
> Homepage: http://ikiwiki.info/
>
> [EMAIL PROTECTED]:~$ apt-cache show deb-gview | grep
Kurt Roeckx wrote:
> See http://bugs.debian.org/438179
This bug was closed by adding a config option. Why wasn't it cloned to
all the network clients (apt, ntp, etc) that exhibit undesirable
behavior due to this change in glibc? Perhaps because the list is too
long for anyone to enumerate it.
--
Steve Langasek wrote:
> Arguably if the consensus is that the default minimum password length should
> be raised in the users' best interests, we would want to change the
> makepasswd package's default at the same time.
And we might also want to make d-i do the same checks, currently it
enforces n
Harald Dunkel wrote:
> Many packages FTBFS (silently!) if an environment variable TAPE
> is set. That happens if your rules script uses something like
>
> tar -c modules | bzip2 -9 > omfs.tar.bz2
>
> for example. If $TAPE is set, then tar writes to $TAPE instead
> of stdout (possibly corrupti
Marc Haber wrote:
> What is the current recommended way to run perl scripts suid?
Ever since that warning was added to perl-suid, many years ago, I've
been writing my own suid wrappers for perl scripts in C.
> Why is perl-suid going away, and how am I supposed to replace its
> functionality?
Wel
Stefano Zacchiroli wrote:
> And even in this case, I still see as not harmful proceeding to fix the
> packages which are not using dh_md5sums atm.
I agree.
> One of the reason is that no one yet showed code implementing this in
> dpkg
#155676 actually
--
see shy jo
signature.asc
Description:
Peter Samuelson wrote:
> I'd opt for dpkg generating the checksums upon _extracting_ the .deb
> file.
Not all debian systems have fast CPU and fast disk.
--
see shy jo
signature.asc
Description: Digital signature
Peter Samuelson wrote:
> The thing is, if you're checking your system, you have to have
> something to check it against. If this is the md5sums file in
> /var/lib/dpkg/info, it doesn't matter whether it's included in the
> package. But if you're using the copy from the .deb (because, say, you
> d
Steve Langasek wrote:
> I'm in total agreement with this. I was staying out of this thread because
> I've been one of the proponents of using -0.x for NMUs of native packages in
> spite of the inconsistency with Policy, and I wasn't sure that this
> reasoning wasn't just a post-hoc rationalization
James Westby wrote:
> However you say
>
> The .orig.tar.gz from the maintainer's last release is kept in the archive
>
> but for a native package there is no .orig.tar.gz, there is a .tar.gz.
You're right. I wonder if there's a good way to deal with this
discreprency and rename the .tar.gz to
NMUs of native packages have always seemed sorta strange to me, and I think
I've figured out why as I was painting a room. Painting is a great way to
think, since you already are in a frame of mind that avoids painting yourself
into corners. ;-)
Many native packages are not Debian-specifc software
[EMAIL PROTECTED] wrote:
> Because it may be more important to be able to identify an NMU from the
> version number than to be able to identify a native package from the
> version number...
I don't see why it's important to be able to tell that from a version
number at all. It's also not the ratio
Julien Cristau wrote:
> It also implies that if there is no debian_revision, upstream_version
> can contain a hyphen.
Utterly false:
The may contain only alphanumerics[1] and the
characters `.' `+' `-' `:' (full stop, plus, hyphen, colon) and
should start with a di
(For the second time, please preserve my CC.)
Bart Martens wrote:
> Yes, lintian. Two examples where lintian seems to follow/accept the
> numbering described in developer's reference:
>
> Example one: Try doing an NMU of dh-make-php with adding ".0.1". Then
> lintian produces this warning:
> W:
(Please keep debian-devel in the CC. This issue is a project-wide
isssue.)
Bart Martens wrote:
> How do other tools this?
Other well-respected tools in debhelper's situation, such as?
yada
It introduces a completely nonstandard Upstream-Source field in
debian/control which it tak
Bart Martens wrote:
> Now imagine that someone would do an NMU of dh-make-php. The right
> version would be 0.2.3-0.1 according to Debian Policy.
Actually, policy doesn't say any such thing. That syntax was invented by
the developer's reference. And it's IMHO dubious.
Consider two packages:
fo
Raphael Hertzog wrote:
> The rationale is simply that it's not always easily doable while using the
> official installation methods, and that changing it manually is
> error-prone and can be confusing in some cases.
>
> While it's important that all files in /usr/share be arch-independent
> (becaus
301 - 400 of 1577 matches
Mail list logo
