Package: dpkg-dev
Version: 1.17.18
Severity: normal
The new dpkg-buildpackage -g option can also be passed to
dpkg-genchanges, but is not documented on its man page. This makes it
hard to figure out that dpkg-buildpackage --changes-option=-g can be
used.
-- System Information:
Debian Release: jes
Guillem Jover wrote:
> But, this has a nice side-effect, you can also do something like:
>
> $ dpkg-buildpackage --changes-option=-g
>
> which will perform a normal full build, but filter the generated
> .changes file to only include source+arch-indep packages. Which I
> think is what you'd be
Raphael Hertzog wrote:
> Funnily this can already be done with “dpkg-buildpackage
> --changes-option=-S” but it will generate a _.changes file
> that list only the source package (that's because the filename
> is decided by dpkg-buildpackage while the content comes from
> dpkg-genchanges).
Hmm, so
Guillem Jover wrote:
> Hmm, I had already pondered about this when I saw the announcement. So,
> while I agree such option would make life easier for people that want
> to do “almost-source-only uploads” right now (because TBH the other
> alternatives are very annoying), on first thought this seeme
Package: dpkg-dev
Version: 1.17.10
Severity: wishlist
Now that the archive supports source-only uploads, with the exception
that arch:all debs have to still be uploaded (as no autobuilder is
responsible for them), dpkg-genchanges -S is useful, but not quite
right.
It would be good to have an opti
Guillem Jover wrote:
> While it's true the format is not being used in Debian, that dgit might
> obsolete it there too, that it might have been a mistake to add the git
> and bzr formats to dpkg and that the formats are marked as experimental,
> I'd be slightly uncomfortable removing them from dpkg
Package: dpkg-dev
Version: 1.17.1
Severity: minor
dgit obsoletes the 3.0 (git) source format, which is unused anyway.
Please remove it.
--
see shy jo
signature.asc
Description: Digital signature
Nicholas Bamber wrote:
> Techincally the shell script
> fragments incorporated into Debian maintance scripts by debhelper may
> fall into this category
For code that is licensed like so?
Redistribution and use in source and binary forms, with or without
modification, are permitted under any cir
Modestas Vainius wrote:
> I don't think it is a fair statement. Examples of minimal dh rules all over
> the place in your blog, debhelper package and dh manual page DO NOT have
> build
> flags handling. It is true that it's the result of inappropriate dpkg-
> buildpackage behaviour but it's stil
Raphael Hertzog wrote:
> Joey, once the new dpkg is in unstable, can we revert this and get the
> packages fixed to use the proper dpkg-buildflags interface to adjust
> the flags to avoid the failure?
>
> Because in my opinion, it's much more important to have a wide usage of
> dpkg-buildflags. Yo
Sven Joachim wrote:
> Hi folks,
>
> with this change from dpkg-dev git:
>
> ,
> | * dpkg-buildpackage no longer exports the compiler flags. Closes: #560070
> | Packages must directly call dpkg-buildflags to retrieve them.
> `
>
> and the following from debhelper 8.9.4:
>
> ,
>
Raphael Hertzog wrote:
> Please reconsider. I think it's been well explained that version numbers
> ought to start with a "number".
Where? Also, f is a number around here.
Example breakage includes the bitlbee bzr snapshots, which many stable
users of bitlbee were probably using.
--
see shy jo
Sven Joachim wrote:
> No, it does not like the trailing space after "urgency=low" in the 2.50
> entry.
I see. dpkg-parsechangelog has no problem with trailing space, so
maybe dpkg-mergechangelog should also be less strict.
(dropping severity to minor)
--
see shy jo
signature.asc
Description:
Package: dpkg-dev
Version: 1.15.8.6
Severity: normal
File: /usr/bin/dpkg-mergechangelogs
j...@gnu:~/src/tasksel>git stash apply
dpkg-mergechangelogs: warning: .merge_file_qmEqOI(l1365): bad key-value after
`;': `urgency=low '
LINE: tasksel (2.50) unstable; urgency=low
dpkg-mergechangelogs: war
Raphaël Hertzog wrote:
> dpkg-gencontrol could be modified to always append the value of
> ${implicit:} at the end of the corresponding field.
Note this would mean that for depends fields, the content of the
substvar would need to start with ", ".
> CCing -devel and Joey Hess
Raphael Hertzog wrote:
> > * If doing as the man page suggests and avoiding a pre-depends
> > by testing dpkg-maintscript-helper supports.
> > Here you'd presumably still want to let the action happen
> > in a later upgrade if the old conffile is still present.
> > (At least when removing a
Package: dpkg-dev
Version: 1.15.7.2
Severity: wishlist
--merge-prereleases is nice, but requires
a) Everyone used the same base version number. There are many
ways that can not happen, maybe someone thinks the next
version will be 1.1 and someone else 1.0.1. Or maybe
the version is da
Package: dpkg
Version: 1.15.7.2
Severity: normal
It's not clear from dpkg-maintscript-helper(1) if the package
version is optional. Omitting the package version can be useful:
* If doing as the man page suggests and avoiding a pre-depends
by testing dpkg-maintscript-helper supports.
Here you'
Package: dpkg
Version: 1.15.7.2
Severity: minor
When run without a parameter, dpkg-maintscript-helper fails
trying to shift away parameters that do not exist.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimen
cwillu wrote:
> New information on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575891
>
> Turns out to have been an unsafe assumption on dpkg's part with
> apparently astronomic odds of being triggered on most filesystems.
>
> Putting /var/lib/dpkg on an ext3 mount (I used a bind mount from
Eugene V. Lyubimkin wrote:
> They are important. Unless .deb have a "canonical" name, I cannot use packed
> .debs as cached archives to install with cupt/apt.
apt web-escapes various characters, including the : in an epoch, so
you would have to modify filenames even if the epoch was included.
(An
I'd forgotten that I submitted a patch to dpkg over a year ago to add a
dpkg-conffile(8) utility.
Note that the code on the wiki has changed slightly to handle a couple
of cases since I wrote dpkg-conffile last year. The wiki version puts a
space after $CONFFILE here to work around a bug:
Raphael Hertzog wrote:
> I can add .swo but I don't think it's safe/interesting to ignore .sw[a-p].
> Is that enough for you?
> Flash file are .swf for examples and it would be annoying to lose them
> because we were too generous in the default ignore list.
Is it not possible to ignore `.*.sw?`
Package: dpkg-dev
Version: 1.14.25
Severity: minor
The default ignores includes vi .swp files, but vim will also create
.swo, .swn, etc if the same file is being edited by two or more vims
at once.
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable')
A
Raphael Hertzog wrote:
> Package: dpkg
> Version: 1.14.19
> Severity: wishlist
>
> On Wed, 04 Jun 2008, Joey Hess wrote:
> > The triggered script is called once at the end of the dpkg run, and once
> > after the set of changed packages are unpacked. (I'm not sure
appends the rpm changelog, generating a changelog
file like this:
splix (1.1.1-2) experimental; urgency=low
* Converted from .rpm format to .deb by alien version 8.71
-- Joey Hess <[EMAIL PROTECTED]> Thu, 01 May 2008 15:00:54 -0400
- New upstream release
- Removed PPDs for the Xerox Pas
Package: dpkg-dev
Version: 1.14.18
Severity: normal
dpkg-buildpackage exporting CFLAGS can cause packages to FTBFS. See for
example #475979. In this case the package consists of a top-level
makefile, that runs a makefile in a subdirectory. The toplevel makefile
sets CFLAGS to some value, but does
Package: dpkg-dev
Version: 1.14.18
Severity: normal
The trigger documentation should be included.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SM
Hmm, on -user there have been some (detail-less) complaints lately of
dpkg apparently looping.
http://lists.debian.org/debian-user/2008/03/msg01417.html
ISTR another bug can't find it in the archives.
--
see shy jo
signature.asc
Description: Digital signature
Adam D. Barratt wrote:
> reassign 452806 dpkg
> retitle 452806 [dpkg-parsechangelog] Please maintain trailing whitespace
> kthxbye
>
> Hi,
>
> On Sun, 2007-11-25 at 11:41 +0100, Josselin Mouette wrote:
> > Package: devscripts
> > Version: 2.10.10
> > Severity: normal
> > File: /usr/bin/dch
> >
>
> I haven't checked, but this sounds very similar to #20471. There's a patch
> in that bug. If you can take some time to verify if it also fixes this
> issue, it would be nice.
I applied this patch on top of current git master
(rev 98cdd8883f0661e24ff72d4c29d73554586eddf8), and have been using it
Raphael Hertzog wrote:
> I haven't checked, but this sounds very similar to #20471. There's a patch
> in that bug. If you can take some time to verify if it also fixes this
> issue, it would be nice.
I tried 0001-Check-dependencies-_on_-the-package-we-re-to-upgrade.patch :
[EMAIL PROTECTED]:~joey
ore ...
Setting up libzlcore (0.8.13-1) ...
Setting up libzltext (0.8.13-1) ...
Setting up fbreader (0.8.13-1) ...
[EMAIL PROTECTED]:/home/joey/src/packages/fbreader>dpkg -s libzlui-gtk
Package: libzlui-gtk
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 220
Maintainer: Joe
Raphael Hertzog wrote:
> We have changed that to "optional" in the git repo. Did you also open a
> bug on ftpmaster's side?
No, it seemed better to let the dpkg maintainers decide if I was right
and handle replying to the override messages as usual.
--
see shy jo
signature.asc
Description: Dig
Package: dselect
Version: 1.14.7
Severity: normal
Tags: d-i
dselect's priority was recently dropped from required to important
(#452652), but important is still a much-inflated priority (so is
standard -- optional would be ok). dselect is not the kind of core unix
tool that policy defines as candi
Guillem Jover wrote:
> Well then there's also the argument that there's no point in having it
> in the source control either, it could be inferred from the section.
> But those seem quite weak and specific ways to do so.
Determining a file's type from its extension is "weak and specific"?
Tell tha
Guillem Jover wrote:
> There's 278 udebs in the current main Packages file. Each Package-Type
> field takes 19 bytes, so 5282 bytes of bloat. In comparison the
> Description field takes 49416 bytes. If you are really concerned about
> "bloat", maybe you could trim those down instead.
We are consta
Guillem Jover wrote:
> It's not included and has never been, because only the ones with B are.
> But now it's explicit given that dpkg-gencontrol supports the
> field. Package-Type should have been XB- from the beginning. That
> information is pertinent to the binary package and not to the changes
Frans seems to be spot on, dpkg should honor XC-Package-Type, and
Package-Type should be treated as an implicitly "XC" field, that is not
propigated into built packages. Unless you have a plan for including
Package-Type in a [u]]deb that I'm unaware of.
--
see shy jo
signature.asc
Description:
To reproduce this bug, run dpkg-shlibdeps on a package that does not
yet have a debian/tmp/DEBIAN directory.
For example, this displays the perl warning. It also generates an empty
substvars file despite the binaries linking to libc6 and stuff.
[EMAIL PROTECTED]:~package/aalib>dpkg-shlibdeps -Td
Package: dpkg-dev
Version: 1.14.8
Severity: serious
dpkg-gencontrol -plibaa-bin -ldebian/changelog -isp
-Tdebian/libaa-bin.substvars -Pdebian/libaa-bin
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
dpkg-gencontrol: warning: unknown substitution variable ${misc:
Package: dpkg-dev
Version: 1.14.8
Severity: normal
Exiting subroutine via last at /usr/share/perl5/Dpkg/Path.pm line 52.
Exiting subroutine via last at /usr/share/perl5/Dpkg/Path.pm line 52.
Exiting subroutine via last at /usr/share/perl5/Dpkg/Path.pm line 52.
Seen while running dpkg-shlibdeps in
Package: dpkg
Version: 1.14.5
Severity: normal
[EMAIL PROTECTED]:/home/joey>dpkg-divert --remove /tmp/foo
Use of uninitialized value in string eq at /usr/sbin/dpkg-divert line 224.
Use of uninitialized value in length at /usr/sbin/dpkg-divert line 224.
Use of uninitialized value in length at /usr/
Bill Allombert wrote:
> + The syntax is a list of options separated by
> + commas that are implemented in the build process.
> + The following options are defined:
If commas are used as delimiters, it should use ", " as the delimiter
for consistency with other fields u
Ian Jackson wrote:
> While we are at it we should write a specification for Build-Options,
> something like:
>
> The Build-Options field appears (only) in the first stanza in
> debian/control. It gives a whitespace-separated list of options.
> The meanings of these options is defined in pol
Package: dpkg
Version: 1.14.2
Severity: normal
Setting up nano (2.0.6-1) ...
Use of uninitialized value in string ne at /usr/sbin/update-alternatives line
461.
Use of uninitialized value in string ne at /usr/sbin/update-alternatives line
461
Use of uninitialized value in string ne at /usr/sbin/u
severity 410605 normal
thanks
dpkg does not FTBFS, the severity was inflated.
if (actualread < 0 ) {
const char *errmsg = BZ2_bzerror(bzfile, &err);
if (err == Z_ERRNO) {
if (errno == EINTR) continue;
errmsg= strerror(errno);
Frank Lichtenheld wrote:
> Yeah, that's indeed a problem. But that isn't solved by the current
> implementation either. When I think about it there is now way the
> -l option (if pointing to a directory that is not known to dpkg)
> changes anything about the build currently since the local shlibs
>
Package: dpkg-dev
Version: 1.13.11
Severity: normal
Tags: d-i
Currently all automatically generated udeb library dependencies are
wrong. This causes numerous problems in d-i. In June I proposed a
solution here:
http://lists.debian.org/debian-dpkg/2005/06/msg00198.html
There were no objections an
tag 317967 - security
thanks
Presumably this bug was fixed in dpkg 1.13.11, which was released well
after the fixed zlib got into the archive. Although I've not actually
checked all the builds to see.
Therefore I am not tracking this bug as a security hole, and IMHO it
should be closed, unless th
Florian Weimer:
> To some extent, it's a policy decision. Is dpkg-deb supposed to
> process untrusted input?
Are you in the habit of installing third-party debs w/o using dpkg to
dump their control files for review? Lets fact it, there are a lot[1]
of third-party debs out there, this is something
Package: dpkg
Version: 1.13.9
Severity: normal
There seems to be some buffering going on with writes to dpkg.log. If
you tail it you'll see stuff like this:
2005-06-17 01:09:22 status unpacked smpeg-gtv 0.4.5+cvs20030824-1.1
2005-06-17 01:09:22 status unpacked smpeg-gtv 0.4.5+cvs20030824-1.1
2005
Package: dpkg-dev
Version: 1.13.9
Severity: important
[EMAIL PROTECTED]:~/tmp/t>apt-get source bogl
Reading Package Lists... Done
Building Dependency Tree... Done
Need to get 95.8kB of source archives.
Get:1 http://http.us.debian.org unstable/main bogl 0.1.18-1.1 (dsc) [649B]
Get:2 http://http.us.
Scott James Remnant wrote:
> reassign 222652 dpkg-dev
> thanks
>
> ... [EMAIL PROTECTED] ...
> -- what was on YOUR mind? :p
Argh, that often-made typo finally escaped my box. Thank you mutt. No,
not that way. Bleh.
> On Mon, 2005-06-13 at 12:0
54 matches
Mail list logo
