Je Fri, 8 Jun 2001 14:42:00 +0200,
Arthur Korn <[EMAIL PROTECTED]> scribis:
> c) change MAKEDEV to print the messages if any devices have to
> be created, and remove that message-printing stuff from
> packages.
Except that output from MAKEDEV may screw up (the stdout-using)
debconf. Please leave
On Sat, 21 Apr 2001 13:36:36 -0700, Sean 'Shaleh' Perry <[EMAIL PROTECTED]>
wrote:
> I was recently mailed about lintian failing on UPX compressed binaries in
> packages.
How does it fail? (In what way do the compressed binaries not conform
to policy?)
-itai
On 30 Nov 2000 08:33:59 -0500, Itai Zukerman <[EMAIL PROTECTED]> wrote:
> 1. an existing file is itself weakinstall.
> 2. the existing file has the same permissions, owner, and
> contents as the new weakinstall file.
Oops: How do you upgrade a weakinstall file owned
On Wed, 29 Nov 2000 18:43:51 -0500, Ben Collins <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 29, 2000 at 05:08:22PM -0500, Itai Zukerman wrote:
> > I would prefer that *any* modification to a .deb increment its
> > version.
>
> That would be bad. Do that and then the Packa
On Wed, 29 Nov 2000 12:51:33 -0500, Ben Collins <[EMAIL PROTECTED]> wrote:
> Maybe it would be easier to label things like conffiles, but call it
> "weakinstall". Treat it like a directory, where many packages can install
> it and own it, and removing them wont remove it unless no other packages
>
> Sooner or later sigs will start traveling around with .deb's (that's
> another discussion, save it for later, it is coming soon). When those sigs
> are changed or updates by the archive maintainers or the release manager,
> the md5sum of the package will change, but the UUID will remain the same.
On Sun, 26 Nov 2000 18:43:54 -0600, Chris Lawrence <[EMAIL PROTECTED]> wrote:
> Anyway, here's how reportbug treats things as of 1.5; YMMV:
>
> - If we find an Origin that we recognize (i.e. in lowercase, it's a
> valid argument to the -B option), we use internal defaults for that
> origin in hand
> So what if a friend gives me a floppy with a package and I have no
> idea where it comes from and only email net access?
Then you could E-mail your friend or the maintainer, and ask them to
E-mail you back the tiny origin file or the tiny package containing
it. I don't see why this is any diffe
> > I think the package should be able to override any default origin
> > data, not the other way around.
>
> No, a package needs to have its own info since the origin file might
> not exist.
I don't follow the reasoning behind that, so maybe a specific example
will clear things up. Here's how I
On Sun, 26 Nov 2000 04:28:44 +0100, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> Origin gives a package a way to indicate where it is coming from.
> This can be used to find information about its origin in
> /etc/dpkg/origins/. The origin information file there
> can list an Bugs field that overri
> > dpkg-buildpackage --system-type i386-linuxlocal
> >
> > (or something). And, if that's the case, probably the system type
> > should be part of the deb (the Architecture field)?
>
> Maybe create an env var that this dpkg-dirs script will use to override
> the default file?
>
> DEBIAN_DIR_
> +include /etc/dpkg-dev/dirs.$(DEBIAN_GNU_HOST_TYPE)
>
> - ./configure
> + ./configure --sbindir=$(sbindir) --bindir=$(bindir) --etcdir=$(etcdir)
The proposal makes perfect sense, I just have one concern: I see that
dpkg-buildpackage takes an architecture flag, but I don't think
there's
> [...]
> When people are upgrading from potato to (stable) woody,
> libc6 will often need to know what services to restart before the new init
> scripts are unpacked.
Again, is there any way to detect which running services need to be
restarted, and then to *warn* the sysadmin that maybe they oug
> > Well, that's not necessarily true. The Origin field could just
> > provide a *way* to get the bug-submission data you need. I mean:
>
> Which is entirely silly considering that I frequently make bugreports
> while I'm not online and batch-send them when I dialin. Your scheme
> would make tha
> > That does not make sense to me. I think the program that reports bugs
> > against a package should know from the Origin how to do that so if we
> > change to another BTS we would only need to change that program.
>
> No, that's silly. That would mean all bugreporting tools would need
> a comp
15 matches
Mail list logo
