Hi,
On 06.05.23 05:58, Guillem Jover wrote:
Debian Policy forbids info files not mentioned in Policy, except if their
names start with an underscore to flag them as non-critical.
I think you might be mixing up .deb ar members with entries in the
control member in the .deb?
Oof, yes
Le ven. 5 mai 2023 à 22:58, Guillem Jover a écrit :
> If there's ever a need for something like this, I think that would
> belong in a linter.
const std::array suffixes {
".clilibs",
".conffiles",
".config",
".fortran_mod",
Hi!
Thanks for the patches.
On Sat, 2023-05-06 at 04:11:05 +0900, Simon Richter wrote:
> Debian Policy forbids info files not mentioned in Policy, except if their
> names start with an underscore to flag them as non-critical.
I think you might be mixing up .deb ar members with entries
Debian Policy forbids info files not mentioned in Policy, except if their
names start with an underscore to flag them as non-critical.
---
src/main/unpack.c | 29 +
tests/t-multiarch/Makefile | 24
2 files changed, 41 insertions(+), 12
Hi all,
This is about policy-rc.d vs DPKG_ROOT,
for context: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23983566
[ continuing here as suggested by Helmut ]
On Mon, 23 Aug 2021 12:39:59 +0200
Helmut Grohne wrote:
> Hi Lorenzo,
>
> On Sat, Aug 21, 2021 at 10:30:21PM +0200, lorenzo wrote
On Sun, 2020-08-23 at 08:25:11 +0300, sam wrote:
> I have been having below error with below command.
>
> $ sudo apt-get update && sudo apt-get upgrade
>
> Do you want to continue? [Y/n] y
> dpkg: error: info database format (2) is bogus or too new; try getting a
>
Hello,
On Tue 23 Jul 2019 at 10:14PM +01, Ian Jackson wrote:
> Sean Whitton writes ("Bug#932753: tag2upload should record git tag signer
> info in .dsc [and 1 more messages]"):
>> AIUI a fingerprint fails to uniquely identify a PGP key unless you also
>> include the
Sean Whitton writes ("Bug#932753: tag2upload should record git tag signer info
in .dsc [and 1 more messages]"):
> AIUI a fingerprint fails to uniquely identify a PGP key unless you also
> include the cryptographic algorithm that was used and the key size. So
> for example
Hello,
On Mon 22 Jul 2019 at 07:55PM +01, Ian Jackson wrote:
> That means the original "uploader" information (ie the identity of the
> person signing the git tag) is not any more present in the source
> package. To rememdy that I propose the following new field:
>
>
Ian Jackson writes:
> Ian Jackson writes ("Re: Bug#932753: tag2upload should record git tag signer
> info in .dsc [and 1 more messages]"):
>> Russ Allbery writes ("Bug#932753: tag2upload should record git tag signer
>> info in .dsc [and 1 more messages]"
Ian Jackson writes ("Re: Bug#932753: tag2upload should record git tag signer
info in .dsc [and 1 more messages]"):
> Russ Allbery writes ("Bug#932753: tag2upload should record git tag signer
> info in .dsc [and 1 more messages]"):
> > Git-Tag-Info: fingerp
:
> >
> > Git-Tag-Info: fingerprint=FINGERPRINT
> > Git-Tag-Tagger: Firstname Surname
>
> This LGTM if other people like the look.
I wonder if just
Git-Tag-Fingerprint: FINGERPRINT
for the first field might be not only simpler but also en
Russ Allbery writes ("Bug#932753: tag2upload should record git tag signer info
in .dsc [and 1 more messages]"):
> One thing that jumps out at me here is that this field isn't extensible,
> since anything after the first space-separated word has to be taken to be
> the t
Ian Jackson writes:
> That means the original "uploader" information (ie the identity of the
> person signing the git tag) is not any more present in the source
> package. To rememdy that I propose the following new field:
> Git-Tag-Info: FINGERPRINT Firstname Surname
s and dm.txt. It then turns that into a
source package which it signs with its own key.
That means the original "uploader" information (ie the identity of the
person signing the git tag) is not any more present in the source
package. To rememdy that I propose the following new field:
Control: reassign -1 dpkg 1.19.2
Control: affects -1 shared-mime-info gconf2
On Mon, Oct 22, 2018 at 07:29:33PM +0200, Andreas Beckmann wrote:
> Package: shared-mime-info,gconf2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: found -1 1.10-1
&
On 2016-07-25 16:12 +0530, Satya Prakash Prasad wrote:
This list is for discussing dpkg development, so is not the right
place to ask for help building packages. debian-user or
debian-toolchain are more appropriate lists.
> I am in need to build gcc-4.9/libgcc1_4.9.2-10_amd64.deb locally so that
I am in need to build gcc-4.9/libgcc1_4.9.2-10_amd64.deb locally so that I
can copy this deb file to another host for installation.
I am aware that we can build .deb & install file using below steps:
# apt-get source gcc version 4.9# dpkg-checkbuilddeps# apt-get install
# dpkg-buildpackage -uc -u
On Tue, 2012-01-31 at 15:39:33 +0100, Raphael Hertzog wrote:
> On Tue, 31 Jan 2012, Guillem Jover wrote:
> > So my preferred solution would be to just get rid of those strings
> > altogether, if someone wants to see the copyright, they should check
> > the source code. I've had a patch around to do
Hi,
On Tue, 31 Jan 2012, Guillem Jover wrote:
> So my preferred solution would be to just get rid of those strings
> altogether, if someone wants to see the copyright, they should check
> the source code. I've had a patch around to do just that (attached),
> but I've not applied it more out of cou
Hi!
On Tue, 2012-01-31 at 08:53:39 +0100, Raphael Hertzog wrote:
> we have lots of translatable strings containing just copyright
> information. I'm not quite sure why those strings are translatable but
> I can imagine that it was meant so that translators can add themselves
> to the list. In prac
Hello,
we have lots of translatable strings containing just copyright
information. I'm not quite sure why those strings are translatable but
I can imagine that it was meant so that translators can add themselves
to the list. In practice, none of the translators have been doing this.
On the other
Guillem Jover wrote:
> But even then I think
> I'd just prefer switching the code to use chunked I/O instead, which
> should be as reliable, and use consistently way less memory at any
> given time.
Hmm, that basically means reverting commit 864e230e, since stdio
uses chunked I/O internally.
It
Hi!
On Tue, 2010-05-25 at 13:36:16 -0500, Jonathan Nieder wrote:
> Use mmap instead of slurping entire "Packages" or "available" files
> into memory. This should reduce memory pressure on low-memory
> machines.
>
> Reported-by: Bill Allombert
> Signed-off-by: Jonathan Nieder
> ---
> Bill Allom
Use mmap instead of slurping entire "Packages" or "available" files
into memory. This should reduce memory pressure on low-memory
machines.
Reported-by: Bill Allombert
Signed-off-by: Jonathan Nieder
---
Bill Allombert wrote:
> Maybe this is because I reran autoreconf
> before compiling or beca
On Fri, 19 Feb 2010 20:35:31 -0600, Jonathan Nieder wrote:
> Hi again,
>
> Three more thoughts and I’ll shut up. (Is there a web page and
> mailing list for this VCS-based archive project?)
Hi,
Thanks for the interest, your comments are valuable.
There is some information at
https://wiki.u
Hi again,
Three more thoughts and I’ll shut up. (Is there a web page and
mailing list for this VCS-based archive project?)
James Westby wrote:
> We want to confirm that each source package is in the VCS. We don't want
> the VCS getting out of date as someone forgot to commit, that's just a
> pa
Hi!
On Thu, 2010-02-18 at 03:04:47 -0600, Jonathan Nieder wrote:
> “dpkg-deb -I foo.deb” leaks the file handle for the package’s
> control file. Check for read errors and close the file before
> it falls out of scope.
>
> Found by cppcheck.
>
> Reported-by: Raphael Geissert
> Signed-off-by: Jo
On Thu, 18 Feb 2010 11:40:51 -0600, Jonathan Nieder wrote:
> Okay, let me see if I understand:
>
> - The main user of this information would be the archive infrastructure;
> - The idea is to confirm that for each submitted binary package, the
>corresponding source is available;
We want to
James Westby wrote:
> On Tue, 16 Feb 2010 15:21:19 -0600, Jonathan Nieder
> wrote:
> > People could get the information you want by looking at the
> > appropriate tag in the repository pointed to by Vcs-foo.
>
> Except that as I said, you don't know that the tag in Vcs-foo was what
> was actual
On Thu, 18 Feb 2010 10:14:51 +0100, Raphael Hertzog wrote:
> On Tue, 16 Feb 2010, James Westby wrote:
> > > Right now, dpkg-dev building tools are mostly VCS-agnostic (I would like
> > > this to change, by providing a generic vcs-buildpackage) and the only
> > > solution to add those fields is to
On Tue, 16 Feb 2010 15:21:19 -0600, Jonathan Nieder wrote:
> Hi James,
>
> James Westby wrote:
>
> > We have the Vcs-* fields in debian/control now that allow you to find
> > the Vcs for the package you are looking at, and this is very useful. I
> > think there is room to extend this a little fu
On Tue, 16 Feb 2010, James Westby wrote:
> > Right now, dpkg-dev building tools are mostly VCS-agnostic (I would like
> > this to change, by providing a generic vcs-buildpackage) and the only
> > solution to add those fields is to pass -D parameters to the dpkg-source
> > call.
>
> Which isn't cur
deb --info. Thanks to Raphael Geissert for
+the report and patch.
+
[ Modestas Vainius ]
* Implement symbol patterns (Closes: #563752). From now on, it is possible to
match multiple symbols with a single entry in the symbol file template.
diff --git a/dpkg-deb/info.c b/dpkg-deb/inf
Hi again,
Jonathan Nieder wrote:
> The information about dirty trees would have to be put elsewhere,
> though. Maybe a magic line in debian/README.source, or if necessary,
> maybe this information would need to be in control (forgive me, I
> don’t know what is necessary to make data accessible t
Hi James,
James Westby wrote:
> We have the Vcs-* fields in debian/control now that allow you to find
> the Vcs for the package you are looking at, and this is very useful. I
> think there is room to extend this a little further using automated
> tools to record information about which revision w
On Tue, 16 Feb 2010 17:47:39 +0100, Raphael Hertzog wrote:
> Hi James,
>
> On Tue, 16 Feb 2010, James Westby wrote:
> > I would therefore propose two new fields that would be optional in a
> > .dsc file, and possibly the Sources file, but not debian/control as they
> > are derived data. They woul
Hi James,
On Tue, 16 Feb 2010, James Westby wrote:
> I would therefore propose two new fields that would be optional in a
> .dsc file, and possibly the Sources file, but not debian/control as they
> are derived data. They would be:
>
> * Vcs-*-revision: A string meaningful to the Vcs that was u
Hi,
We have the Vcs-* fields in debian/control now that allow you to find
the Vcs for the package you are looking at, and this is very useful. I
think there is room to extend this a little further using automated
tools to record information about which revision was built as well.
This could be us
On Mon, 26 Oct 2009, Lucas Nussbaum wrote:
> No, the build was done with version 1.15.4. You need to build-depend on
> install-info, which is no longer provided directly by dpkg.
>
> dpkg people, wouldn't it make sense to depend on install-info in dpkg,
No, the whole poin
nit -plibgnucrypto-java
> > > > > dh_installdebconf -plibgnucrypto-java
> > > > > dh_installemacsen -plibgnucrypto-java
> > > > > dh_installcatalogs -plibgnucrypto-java
> > > > > dh_installpam -plibgnucrypto-java
> > > > > dh_installlo
Hi!
Some comments on the changes I made when applying it.
On Sat, 2009-08-29 at 19:57:24 -0400, David Benjamin wrote:
> Here's the first refactoring patch mentioned in "dpkg list-file performance".
>
> ===
> Refactor: split off emptying a package's file info
>
[ CCing you, as I don't know if you are subscribed. ]
Hi Bastian!
On Sun, 2009-08-30 at 09:42:35 +0200, Bastian Blank wrote:
> Currently there are packages showing up that include this as dependency:
> | dpkg (>= 1.15.4) | install-info
>
> cdebootstrap, which uses a rather
Hi folks
Currently there are packages showing up that include this as dependency:
| dpkg (>= 1.15.4) | install-info
cdebootstrap, which uses a rather primitive dependency resolver, can't
cope with that and will always assume that dpkg will fullfill that.
Thats why I want to know what t
Here's the first refactoring patch mentioned in "dpkg list-file performance".
===
Refactor: split off emptying a package's file info
Put it into a separate function for reuse by other routines and to
simplify ensure_packagefiles_available.
Signed-off-by: David Benjamin
On Di, 11 Aug 2009, Guillem Jover wrote:
> > AFAIS all the info-browsers now have a dependency on install-info,
> > so we should be ready to upload the new dpkg.
>
> Ideally not until all info-browsers have migrated to testing, to not
> tie them and create a monster transit
Hi!
On Mon, 2009-08-10 at 20:59:20 +0200, Norbert Preining wrote:
> AFAIS all the info-browsers now have a dependency on install-info,
> so we should be ready to upload the new dpkg.
Ideally not until all info-browsers have migrated to testing, to not
tie them and create a monster tran
Hi Raphael, hi all,
AFAIS all the info-browsers now have a dependency on install-info,
so we should be ready to upload the new dpkg.
Best wishes
Norbert
---
Dr. Norbert Preining Vienna University of Technology
On So, 28 Jun 2009, Raphael Hertzog wrote:
> > After that jed-extra (no response) and konqueror (you wrote email) are
> > open before all the packages providing info-browser are fixed.
>
> I suggest you upload the jed-extra NMU in DELAYED/3 and inform the
> maintainer. For k
and will be processed if the package is not removed
until then.
> After that jed-extra (no response) and konqueror (you wrote email) are
> open before all the packages providing info-browser are fixed.
I suggest you upload the jed-extra NMU in DELAYED/3 and inform the
maintainer. For konqu
ges providing info-browser are fixed.
On Fr, 26 Jun 2009, Raphael Hertzog wrote:
> > Who will file bugs against lintian, debhelper, policy?
>
> I just did so. Policy is #534638, debhelper #534639 and lintian #534640.
Perfect, thanks, and debhelper fixed dh_installinfo already. Perfec
Hi,
On Wed, 10 Jun 2009, Norbert Preining wrote:
> On Mi, 10 Jun 2009, Norbert Preining wrote:
> > Ok, I have uploaded the version of texinfo to unstable, and have filed
> > bugs against all info browsers, can be found at the same usertag as
> > before.
>
> Who wil
On Sun, 21 Jun 2009, Norbert Preining wrote:
> > Hopefully maintainers will do it quickly, in any case I will try to help
> > if we have to NMU some of them.
>
> I have prepared NMUs for jed, jed-extra, kdebase(konqueror), tkinfo,
> pinfo, emacs21 and send debdiffs to the respective bug reports.
>
Hi Raphael,
On Di, 09 Jun 2009, Raphael Hertzog wrote:
> > I can do the bug filing, but I am not sure if I can prepare NMUs for all
> > of them.
>
> Hopefully maintainers will do it quickly, in any case I will try to help
> if we have to NMU some of them.
I have prepared NMUs for jed, jed-extra,
Hi Raphael,
On Mi, 10 Jun 2009, Norbert Preining wrote:
> Ok, I have uploaded the version of texinfo to unstable, and have filed
> bugs against all info browsers, can be found at the same usertag as
> before.
Who will file bugs against lintian, debhelper, policy?
Best wishes
Hi Raphael,
On Di, 09 Jun 2009, Raphael Hertzog wrote:
> > And from the time-line it would mean first to upload texinfo/i-i to
> > unstable, and then file bugs against the info browsers.
>
> Yes, although it should happen more or less at the same time in the ideal
> case.
On Tue, 09 Jun 2009, Norbert Preining wrote:
> Do we have bugs against the info browsers already filed?
Not that I know.
> And from the time-line it would mean first to upload texinfo/i-i to
> unstable, and then file bugs against the info browsers.
Yes, although it should happen mor
d right now. The bugs have a very low impact and
> should not block the rest of the transition. However the bugs against the
> info-browsers will have to be tracked more agressively, even offering NMUs
> to speed things up probably.
Do we have bugs against the info browsers already fil
ld go ahead right now. The bugs have a very low impact and
should not block the rest of the transition. However the bugs against the
info-browsers will have to be tracked more agressively, even offering NMUs
to speed things up probably.
If you need help for something, please tell us.
Cheers
> > > some cases or need to upgrade dpkg or any of the info-readers.
> > > * Make info providing packages depend on install-info.
> > > * Make info providing packages Break old dpkgs.
> > > * Not remove calls to install-info from packages until squ
On So, 17 Mai 2009, Raphael Hertzog wrote:
> It's the prein...@logic.at apparently:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=prein...@logic.at;tag=texinfo-transition
Ups, right, probably forgot to set the From correctly.
> > Next is I guess sending bug reports to i
On Sun, 17 May 2009, Bill Allombert wrote:
> > So there's several options that come to mind for that:
> >
> > * We don't care, and expect users might miss docs on the dir file in
> > some cases or need to upgrade dpkg or any of the info-readers.
> >
en drafted with the idea of inflicting
> > minimal disruption.
> >
> > > > Yes. If the new texinfo/install-info is installed it will work on the
> > > > triggers. Packages that are old will call install-info which is a
> > > > wrapper
> > >
On Sat, 16 May 2009, Norbert Preining wrote:
> I have sent out bug reports to all the packages shipping info files
> without dir section.
Thanks.
> I have added a usertag: texinfo-transition from prein...@debian.org to
> find these bugs.
It doesn't look like so, the follow
* Guillem Jover [2009-05-17 04:15]:
> Dropping calls to install-info is something that we should probably
> only ask maintainers to do once the new install-info and dpkg packages
> are in testing. We should probably detangle those two steps in the wiki
> timeline.
Thanks, th
es Lenny includes this trigger ?
> > >
> > > > Did you consider what will when a partial lenny to squeeze update is
> > > > made ?
>
> Yes, most of the plan has been drafted with the idea of inflicting
> minimal disruption.
>
> > > Yes. If the new texinfo/
Hi!
Just in case this was not clear from the bug report, and as exmplained
on bug 528877, for now the info files should just get the missing info
dir entry added. Once the new install-info and dpkg packages have
migrated to testing maintainers should be able to start dropping the
direct calls to
Hi!
On Sat, 2009-05-16 at 21:39:51 +0200, Norbert Preining wrote:
> On Sat, 16 May 2009, Rafael Laboissiere wrote:
> > This means that if I fix this bug and upload right now the jed package to
> > unstable, it will fail to install the info files. Am I missing something
> >
On Sat, May 16, 2009 at 09:54:35PM +0200, Norbert Preining wrote:
> Hi Bill,
>
> On Sat, 16 May 2009, Bill Allombert wrote:
> > Does Lenny includes this trigger ?
>
> No.
>
> > Did you consider what will when a partial lenny to squeeze update is made ?
>
>
Hi Bill,
On Sat, 16 May 2009, Bill Allombert wrote:
> Does Lenny includes this trigger ?
No.
> Did you consider what will when a partial lenny to squeeze update is made ?
Yes. If the new texinfo/install-info is installed it will work on the
triggers. Packages that are old will call i
On Sat, 16 May 2009, Rafael Laboissiere wrote:
> This means that if I fix this bug and upload right now the jed package to
> unstable, it will fail to install the info files. Am I missing something
> or have the regarding packages just been uploaded?
Yes, that is true, please wait wit
On Fri, 15 May 2009, Raphael Hertzog wrote:
> Norbert, can you go ahead with this transition RSN ?
(sorry, working as mountain guide makes me offlines now and then)
I have sent out bug reports to all the packages shipping info files
without dir section. I have added a usertag: texinfo-transit
ave to go
> > thorugh the "mass bug filing" thingy on d-d? Right?
>
> In theory yes, but since those are real bugs in the documentation I think
> nobody will complain if you omit that step (and you're the Debian expert
> for info files since you maintain texinfo).
>
>
On Fri, 01 May 2009, Norbert Preining wrote:
> On Mo, 27 Apr 2009, Raphael Hertzog wrote:
> > In theory yes, but since those are real bugs in the documentation I think
> > nobody will complain if you omit that step (and you're the Debian expert
> > for info files
Hi
2009/5/1 Norbert Preining :
>
> Ok, here is a bug email, if someone wants to read it before I send it
> out:
Sounds fine to me!
Best regards
--
Danai
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian
On Mo, 27 Apr 2009, Raphael Hertzog wrote:
> In theory yes, but since those are real bugs in the documentation I think
> nobody will complain if you omit that step (and you're the Debian expert
> for info files since you maintain texinfo).
Ok, here is a bug email, if someone wa
t that step (and you're the Debian expert
for info files since you maintain texinfo).
Up to you.
> > And also file bugs against all info-browsers to request their update
> > as soon as install-info is in unstable.
>
> Ok, will check the list of info browsers. But that sh
On Fr, 24 Apr 2009, Raphael Hertzog wrote:
> > - report bugs against those packages failing to provide fully working
> > info files
Here is the list I created (format: pkg file).
acct usr/share/info/accounting.info.gz
barcode usr/share/info/barcode.info.gz
bcron usr/share/info/b
On Thu, 23 Apr 2009, Norbert Preining wrote:
> Next steps we should do?
> - report bugs against those packages failing to provide fully working
> info files
> - ???
And also file bugs against all info-browsers to request their update
as soon as install-info is in unstable.
Cheers,
ow, so here we go ...
Next steps we should do?
- report bugs against those packages failing to provide fully working
info files
- ???
Best wishes
Norbert
---
Dr. Norbert Preining Vienna Universi
On Do, 16 Apr 2009, Raphael Hertzog wrote:
> Try running it with #!/bin/dash and you can also use checkbashism (of
> devscripts) to verify your script.
Ok, maybe for one of the next versions ...
> > Yes, but NEW will take at least a week, so I will do it now.
>
> Not if we prod an ftp assistant
On Thu, 16 Apr 2009, Norbert Preining wrote:
> On Do, 16 Apr 2009, Raphael Hertzog wrote:
> > Looks fine for me. I would have avoided bashisms but since you explicitely
> > use bash, it's ok.
>
> Sorry, I always and ever programmed if in sh then for bash. I have no
> idea what are bashism and what
On Do, 16 Apr 2009, Raphael Hertzog wrote:
> Looks fine for me. I would have avoided bashisms but since you explicitely
> use bash, it's ok.
Sorry, I always and ever programmed if in sh then for bash. I have no
idea what are bashism and what not. If you send a dash-compliant version
it would be fi
On Thu, 16 Apr 2009, Norbert Preining wrote:
> On Di, 14 Apr 2009, Norbert Preining wrote:
> > New version attached, thanks for reviewing
>
> Any comments on that?
Looks fine for me. I would have avoided bashisms but since you explicitely
use bash, it's ok.
> And, comments on upload to experimen
On Di, 14 Apr 2009, Norbert Preining wrote:
> New version attached, thanks for reviewing
Any comments on that?
And, comments on upload to experimental or unstable?
I want to upload that before tomorrow because tomorrow I am leaving for
one week in Switzerland. That would be a good time to let it
Hi all,
thanks for the remarks
On Di, 14 Apr 2009, Nicolas François wrote:
> I don't think all info files are named *.info.gz or *.info.
Right, good observation
> Also, it could be more robust to space issues to run something like:
> find "$INFODIR" -type f |
On 2009-04-14 16:25 +0200, Nicolas François wrote:
> On Mon, Mar 16, 2009 at 01:36:35PM +0100, Norbert Preining wrote:
>> On Mo, 16 Mär 2009, Nicolas François wrote:
>>
>> > I will try to review update-info-dir next week.
>>
>> That would be great, please use
On Tue, 14 Apr 2009, Nicolas François wrote:
> > ginstall-info "$i" "$INFODIR/dir" || true
>
> I would propose to detect errors from ginstall-info, but still continue:
>
> errors=0
>
> ...
>
> ginstall-info
Hello Norbert,
Sorry, I forgot to report my findings.
On Mon, Mar 16, 2009 at 01:36:35PM +0100, Norbert Preining wrote:
> On Mo, 16 Mär 2009, Nicolas François wrote:
>
> > I will try to review update-info-dir next week.
>
> That would be great, please use the version from
On Di, 14 Apr 2009, Norbert Preining wrote:
> - Do we need any special control entries (breaks, suggests, etc) in the
> new package? (current debian/control attached)
Forgot that one, and found that there is a bug in the current control
file, under package install-info I stil
Hi all,
On Di, 14 Apr 2009, Raphael Hertzog wrote:
> We should file those bugs now with an explanation of the problem.
> You should also upload texinfo/i-i now given that it has to go through
> NEW.
Ok, still a review from someone else would be nice.
Before uploading two questions:
- Do we nee
On Mon, 13 Apr 2009, Norbert Preining wrote:
> How do we proceed now with that? As said in a different email some weeks
> ago, only ~50 of around 580 total info files fail when called with
> ginstall-info.
We should file those bugs now with an explanation of the problem.
You should al
n are already sooo
long and I guess nobody will read it. The Wiki collects the most
important things.
On Do, 26 Mär 2009, Neil Williams wrote:
> * install-info operations will all then happen in triggers, not
> directly via maintainer scripts.
> http://bugs.debian.org/cgi-bin/bugreport.
Hi all,
On So, 22 Mär 2009, Raphael Hertzog wrote:
> I have updated the wiki page with your announce and the other comments:
> http://wiki.debian.org/Transitions/DpkgToGnuInstallInfo
Thanks.
> I guess it's ok to send the announce to -devel now. Do you want to take
> care of it ?
For the next 3
On Sun, 15 Mar 2009, Norbert Preining wrote:
> On Fr, 13 Mär 2009, Raphael Hertzog wrote:
> > I guess so. Asking for review/test on -devel is certainly a good idea at
> > this point.
>
> I have prepared a document/email. Can one of you take a look at that and
> extend/clarify/whatever it?
I have
On Tue, 2009-03-17 at 08:35:43 +0100, Raphael Hertzog wrote:
> On Tue, 17 Mar 2009, Guillem Jover wrote:
> > this way it might be possible to reuse this as the wrapper for the
> > install-info package.
Sorry, I should have added "in case we actually want to reuse the
code&quo
On Di, 17 Mär 2009, Raphael Hertzog wrote:
> so much when Norbert would certainly prefer to not have to separately
> compile an executable given he can use a simple shell wrapper.
Agreed.
To follow your wrapper I have added the package name to the warning message
(DPKG_MAINTSCRIPT_PACKAGE).
Bes
On Tue, 17 Mar 2009, Guillem Jover wrote:
> > A new version of the patch is in my branch, it should fix all the points you
> > have brought up (except the common wrapper thing):
> > http://git.debian.org/?p=users/hertzog/dpkg.git;a=commitdiff;hb=pu/install-info
>
>
Hey!
On Mon, 2009-03-16 at 12:34:51 +0100, Raphael Hertzog wrote:
> I can add print this additionnal information in case there's no
> /urs/bin/install-info and we have DPKG_RUNNING_VERSION set.
Checking now the new warning, it might also make sense to print the
package in
On Mo, 16 Mär 2009, Nicolas François wrote:
> > - file bugs against all the info shipping packages with problematic info
> > files
>
> Maybe recommend that install-info should be called without options but the
> info files themselves should be updated.
> And --section s
1 - 100 of 546 matches
Mail list logo
