Package: wnpp
Severity: wishlist
Owner: Bill MacAllister
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: krb5-wallet
Version : 1.5
Upstream Contact: Bill MacAllister
* URL : https://salsa.debian.org/whm/krb5-wallet
* License : (Expat
, i386, mips64el, ppc64el, s390x
evince | 46.0-1 | unstable | source
evince | 46.0-1 | unstable-debug | source
evince | 46.0-1+b1| unstable | amd64, arm64, armel,
armhf, i386, mips64el, ppc64el, riscv64, s390x
Cheers,
--
Bill.
Imagine
nd that [1] or [2] or whatever is
> > a link, pointing to a wrong place.
> >
> > I agree it's a bug, but I do think it's a pretty harmless one.
>
> Thanks. I'd be grateful for some feedback from other regular Policy
> contributors.
My view is that any issue with single-page
ca6834cf5493fa6a 3463 perl optional
> libfinance-quote-perl_1.60-1.dsc
> ccf54b587f0291e734ec0b2986d0a7b1 267746 perl optional
> libfinance-quote-perl_1.60.orig.tar.gz
> 8503de0de2f3b85ea334012da21716b4 7000 perl optional
> libfinance-quote-perl_1.60-1.debian.tar.xz
>
>
ntains:
> L /var/run - - - - ../run
Why not fix /usr/lib/tmpfiles.d/var.conf to create the correct link then ?
/usr/lib/tmpfiles.d/var.conf is not policy-compliant as it is.
Cheers,
--
Bill.
Imagine a large red swirl here.
Package: libfinance-quote-perl
Version: 1.59-1
Severity: normal
Dear Maintainer,
I ran the Tools > Price Database command in Gnucash using the "Yahoo
as JSON" source and got the following response:
Unable to retrieve quotes for these items.
In the past, this error was resolved by editing
format has been disabled due to various other issues).
Sorry, but why is this so hard to generate a single-page html ?
debiandoc could do it. Using the browser intra-page search is always much
easier/faster that using a search box.
Cheers,
Bill.
Source: xeus
Severity: wishlist
Dear Xeus maintainers,
There is a new major upstream release available (4.0.2).
Do you plan to package it ?
Cheers,
--
Bill.
Imagine a large red swirl here.
non-free packages that are built on the autobuilders
to comply with this requirement. So we do not want 2.2.3 to apply in that
specific case. It seems cleaner to say that the requirement only apply if
Autobuild: yes is declared.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Thu, Apr 04, 2024 at 09:25:36PM +0200, Philipp Kern wrote:
> Hi,
>
> On 04.04.24 20:51, Bill Allombert wrote:
> > I still think we should allow Autobuild: no as an escape hatch.
> > If we want to require non-free package to be autobuildable, we should
>
>
> Also looks good to me. Seconded.
I still think we should allow Autobuild: no as an escape hatch.
If we want to require non-free package to be autobuildable, we should
be more explicit about it (and probably require more feedback from
debian-devel).
Cheers,
--
Bill.
Imagine a large red swirl here.
existing packages and allow
> some input from their maintainers. Are you able to prepare a list of
> the affected packages?
What I suggested was that "Autobuild: yes" imply no network access.
Cheers,
--
Bill.
Imagine a large red swirl here.
P',
+ 'DEFINE'=> '-DOPENLDAP -DLDAP_DEPRECATED=1',
)),
'depend'=> { 'LDAPapi.c' => 'constant.h' },
'clean' => { 'FILES' => 'constant.h' },
The patch is from Quanah Gibson-Mount . Thanks.
Bill
On Mon, Apr 01, 2024 at 06:08:10PM +0200, Aurelien Jarno wrote:
> On 2024-04-01 17:52, Bill Allombert wrote:
> > On Mon, Apr 01, 2024 at 05:29:54PM +0200, Aurelien Jarno wrote:
> > > Package: debian-policy
> > > Version: 4.6.2.1
> > > Severity: normal
>
some security concerns. Would it be possible to extend this
> restriction to all archives?
Does the build daemons actually build non-free ?
Cheers,
--
Bill.
Imagine a large red swirl here.
This is a confirmed bug. I am working on a solution.
Bill
releases.
>
> Please pick one location and install it only there. /usr/bin is preferred
> over any other location.
I would suggest you find out why the binaries are in both directories in the
first place.
Then we can discuss a solution!
Cheers,
--
Bill.
Imagine a large red swirl here.
On Mon, Feb 05, 2024 at 01:20:07PM +, Bastien Roucariès wrote:
> Le lundi 5 février 2024, 12:42:04 UTC Bill Allombert a écrit :
> > On Mon, Feb 05, 2024 at 12:28:02PM +0100, Axel Beckert wrote:
> > > Hi Bill,
> > >
> > > Bill Allombert wrot
c/libpari-gmp-tls8/changelog.Debian.gz
-rw-r--r-- root/root 9997 2023-06-27 18:38
./usr/share/doc/libpari-gmp-tls8/changelog.gz
-rw-r--r-- root/root 766 2022-09-05 21:10
./usr/share/doc/libpari-gmp-tls8/copyright
It is missing all the important files.
Cheers,
--
Bill.
Imagine a large red swirl here.
would let packages maintainers control
which buildflags are used while still providing the benefit of buildflags.
Cheers,
--
Bill.
Imagine a large red swirl here.
o recompile from source.
> >
> > There are far too many different HTML generators out there to handle.
>
> We have done this for doxyen and sphinx, so maybe not for more
This is two out of how many ?
For example, my packages use TtH, GAPDoc, hevea, pod2html.
I do not think it is sustainable.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Thu, Feb 08, 2024 at 06:39:18PM +, Bastien Roucariès wrote:
> Le jeudi 8 février 2024, 18:31:28 UTC Santiago Ruano Rincón a écrit :
> > On Sat, 14 Oct 2023 20:23:18 +0200 Bill Allombert
> > wrote:
> > > On Sun, Sep 18, 2022 at 12:14:07AM +0100, Colin Watson wrote:
eared binary NEW.
Have you actually checked that pari will really be build with the relevant
flags ?
If there is a new ABI, then one should take the opportunity to remove
CFLAGS_i386 := -mpc64
There is no need for a lintian override, this is a well-known lintian bug...
Cheers,
Bill
t.
Fortunately libgap.so.9 was prereleased today.
Would that mess anything if I upload it to experimental ? I expect not.
Cheers,
--
Bill.
Imagine a large red swirl here.
nderstand, what do you mean with "one per dialect" here?
I assume dialect means pt_PT vs pt_BR. Each locale can have a different
page size even if the translation is the same.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Mon, Feb 05, 2024 at 12:28:02PM +0100, Axel Beckert wrote:
> Hi Bill,
>
> Bill Allombert wrote:
> > By the way, what happened to lintian.debian.org ?
>
> Seems as if someone (not me, just noticed it today when
> "private/refresh-data" failed…) pulled t
On Mon, Feb 05, 2024 at 03:26:29AM +0100, Axel Beckert wrote:
> Hi,
>
> Bastien Roucariès wrote:
> > Le dimanche 4 février 2024, 14:02:58 UTC Bill Allombert a écrit :
> > > Areyou still available as lintian maintainer ? It sure would need an
> > > upload.
> &
le as lintian maintainer ? It sure would need an upload.
Cheers,
--
Bill.
Imagine a large red swirl here.
ing able to actually release new version of lintian would be nice.
Hello,
I volunteer to help with Lintian.
I have worked on lintian a long time ago,
I should be able to make new releases at least.
Cheers,
--
Bill.
Imagine a large red swirl here.
signature.asc
Description: PGP signature
On Thu, Feb 01, 2024 at 04:30:40PM +0100, Lukas Märdian wrote:
> Am 01.02.24 um 16:13 schrieb Bill Allombert:
> > On Thu, Feb 01, 2024 at 04:07:38PM +0100, Lukas Märdian wrote:
> > > Hi Bill,
> > >
> > > thanks for the heads-up!
> > > The same de
On Thu, Feb 01, 2024 at 04:07:38PM +0100, Lukas Märdian wrote:
> Hi Bill,
>
> thanks for the heads-up!
> The same debdiff should apply to the version in unstable (4.12.1).
> We'll make sure to NMU the version from unstable.
How do you plan to make sure libgap8t64 actually us
rsion instead of
introducing libgap8t64.
So if one really need to introduce libgap8t64, we need a patch for the version
of GAP in unstable that actually use 64-bit time_t.
Cheers,
--
Bill.
Imagine a large red swirl here.
he practicality of reporting subarchitectures:
1/ users might not be running the latest Debian release, and there is no way to
know
if they plan to upgrade.
2/ the number of users running some subarchitectures is likely to be very small,
which breaks anonymity.
Cheers,
Bill
n3-dev to 3.11.2-2 fixes this issue.
binNMUing libxeus9 might fix this issue, but will probably silently change the
ABI of libxeus9 without
updating the shlibs. This is worrysome. I hope I am wrong about that.
Cheers,
--
Bill.
Imagine a large red swirl here.
Hopefully most mirrors should support https download now.
Cheers,
--
Bill.
Imagine a large red swirl here.
On 2023-12-14 01:54, Bill MacAllister wrote:
This took me longer that I wanted, but I have built kernels the
following
kernels with the patch:
linux-image-6.1.0-15-amd64-dbg_6.1.66-2~afs1_amd64.deb
linux-image-6.1.0-15-amd64-unsigned_6.1.66-2~afs1_amd64.deb
linux-image-6.1.0-15-cloud-amd64
non-i386 were built
manually by porters that used the urgency to decide which packages to build
first.
I do not think this is still the case, except that the security queue is build
first by the autobuilders.
Cheers,
--
Bill.
Imagine a large red swirl here.
On 2023-12-09 09:49, Bill MacAllister wrote:
On 2023-12-08 15:59, Diederik de Haas wrote:
On Saturday, 9 December 2023 00:28:50 CET Jeffrey Altman wrote:
The bug is considered valid by upstream. A proposed fix for this
issue is
being reviewed.
http://lists.infradead.org/pipermail/linux-afs
cy.
Note that I proposed that in bug #229357 in 2004, this was even fully
implemented,
commited to the VCS and finally reverted without explanation.
I am still not sure why I suffered so much hostility over such a simple design.
Cheers,
--
Bill.
Imagine a large red swirl here.
(cleanly) onto a 6.1 kernel.
Bill: can you test this patch and see if it resolved the issue?
Yes, I can test it. Mostly likely I will not get to doing that until
Sunday
night here in California. For sure Monday morning at the latest.
Bill
--
My heart is warm with the friends I make
It looks like this was fixed upstream earlier this year in this commit:
https://gitlab.com/NTPsec/ntpsec/-/commit/9931ebb3d1418b648f80510a86520a4d11bab3d6
The relevant bit is the change to ctl_putarray() to set buffer[0] = 0;
It does not appear that this fix has appeared in a release yet.
Package: ntpsec
Version: 1.2.2+dfsg1-1+deb12u1
Severity: important
Dear Maintainer,
It appears that ntpsec's ntpd returns corrupted values in the "filtdelay",
"filtoffset" and "filtdisp" peer variables visible via ntpq.
reproducer:
$ ntpq
ntpq> peers
(output elided)
ntpq> rv &1 filtdelay
support units dependency package
fp-units-win-wasm-3.2.2 - Free Pascal - Web assmebly support units
fp-units-wasm - Free Pascal - Web assmebly support units dependency package
fp-units-wasm-3.2.2 - Free Pascal - Web assmebly support units
Cheers,
--
Bill.
Imagine a large red swirl here.
After more testing Jeff Altman and Marc Dionne have reported that
the problem accessing AFS files using kafs does not occur if the
client has IPv6 configured.
Bill
--
"Can't sing louder than the guns when I'm gone,
so I guess I'll have to do it while I'm here."
Phil Ochs
ed help with that, please tell me, I have worked on lintian in the
past.
Cheers,
--
Bill.
Imagine a large red swirl here.
signature.asc
Description: PGP signature
When upgrading (with aptitude), initscripts (3.08-1) is set up
before udev (254.4-1). Udev claims to remove the "obsolete
conffile /etc/init.d/udev", but it's still there. However, the
rc*.d symlinks are not -- "update-rc.d udev defaults" fixes it.
Regards.. Bill
Before I started bisecting the 6.1 kernel I thought I should re-examine
the assumption that 6.1.0-9 was a good kernel, i.e. a kernel where
accessing AFS volumes using kafs does not cause seg faults. I tested
6.1.0-2, 6.1.0-5, and 6.1.0-7 without success.
Bill
--
"Can't sing louder
later fail. Which meant that my bisection attempts
where pretty much useless. I will work on a better test for this issue.
Bill
--
"Can't sing louder than the guns when I'm gone,
so I guess I'll have to do it while I'm here."
Phil Ochs
e or it is just this time ?
Do you have files /var/log/popularity-contest.* ?
Sorry for the trouble!
Cheers,
--
Bill.
Imagine a large red swirl here.
.
However, this directly lead to the structural problem we have now.
While it would be OK for a Packaging Manual to say "just use debhelper"
that does not help the debhelper developers that need to know what it
is expected of debhelper.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Sun, Sep 17, 2023 at 08:28:56AM -0700, Russ Allbery wrote:
> Bill Allombert writes:
> > On Sun, Sep 17, 2023 at 10:41:55AM +0200, Marco d'Itri wrote:
> >> On Sep 17, Russ Allbery wrote:
>
> >>> (I am a little confused by this wording, but I think what
stly instance-independent and can
be prefilled, but for that, users expect a minimal directory hierarchy to be
present before first boot.
It seems your scheme favors some usecase over some others.
Cheers
--
Bill.
Imagine a large red swirl here.
t;).
>
> It is unclear what files the Jackson symlink farm proposal would leave
> in /bin. Would /bin/python3 stay? Or would it stay first, but dropped
> at some later point? What about /bin/perl, /bin/zsh, /bin/env, ...?
/bin/perl, /bin/env, /bin/python3 did not exist in the old scheme, so there is
no point in creating them now.
/bin/zsh and /bin/sed existed, though.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Wed, Sep 13, 2023 at 10:47:48AM +0200, Bill Allombert wrote:
> On Tue, Sep 12, 2023 at 08:48:04PM -0700, Russ Allbery wrote:
> > Control: retitle -1 Post-/usr-merge paths for script interpreters
> >
> > Simon pointed out that this bug is not yet ready to act on, which
umented. The idea is that this
> second build probably is faster than a regular build.
Hi!
Is it possible to save the profile data to reperform the second build later ?
Cheers,
--
Bill.
Imagine a large red swirl here.
lead to different paths. We at least need to address that.
Personnally, I favor keeping /bin/sh for consistency, but that is aside.
Cheers,
--
Bill.
Imagine a large red swirl here.
the University of California."
by whatever is required when generating DEBIAN/copyright.
Cheers,
Bill
But we do: we support debhelper 13.11.4 and debhelper 13.11.6.
Even if we support a single implementation, we still need to know what is
expected of it.
Cheers,
--
Bill.
Imagine a large red swirl here.
ny user's PATH
> either, is it?
% grep games /etc/profile /etc/login.defs
/etc/profile: PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
/etc/login.defs:ENV_PATH
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Cheers,
--
Bill.
Imagine a large red swirl here.
ge over /usr/games.
On the other hand, /usr/games allows:
- priviledged accounts to omit /usr/games in their path (root does not have it
e.g)
- quickly find which games are installed on a system (ls /usr/games).
- have a separate partitions for game data (which are amongst the largest
Debian package)
- have a specific policy for /var/games
Cheers,
Bill
allsystemd should do,
otherwise we will not be able to distinguish between bug in dh_installsystemd
and
intended behaviour, and we will end up freezing dh_installsystemd to avoid
introducing
problem by breaking incidental interfaces.
Cheers,
--
Bill.
Imagine a large red swirl here.
ve a
> copyright file.
Or we could generate DEBIAN/copyright from debian/copyright using data in
license-common-list at build time. So maintainers would not need to manage the
copying
themselves.
Cheers,
Bill
one were manually writing
> #!/usr/bin/sh
>
> We can debate about normal vs minor.
>
> I do not think it should be a bug if some automated build process found
> /usr/bin/sh and stuck that into a script.
> I'd support a policy change to make that clear.
I would. Having two pat
eplaces: foo for at least one release.
2/ you decide to rename the package foo to foo1:
foo1 need to Replaces: foo for at least one release.
Cheers,
Bill
ack)?
>
> Hi, monthly ping. Anything I can do to move this forward?
I consider this proposal to be premature. Policy should document current
practice, and I do not think this proposal does that.
It would it more useful to help maintainers adapt their script to conform
to this first, and change policy later.
Cheers,
--
Bill.
Imagine a large red swirl here.
to
bookworm.
I have AVOID_DAILY_AUTOCOMMITS=1 in /etc/etckeeper.conf to prevent these
evil commits since I'll check in my changes when they are good and
ready, and I'll have a much more helpful log message. Whatever it takes
to prevent these unwanted commits would be much appreciated.
--
Bi
ou please intervene? Thank you.
This is premature.
> In the meanwhile, I'll immediately revert the sabotage.
If this package is so important, why is it maintained by NMUs ?
Why cannot the maintainers do a proper upload ?
Cheers,
--
Bill.
Imagine a large red swirl here.
Package: passwordsafe
Version: 1.16.0+dfsg-4
Severity: important
Creating a new entry or editing an existing entry results in the following
crash:
[wohler@olgas ~ (olgas:*%)]$ pwsafe
pwsafe: ./src/core/PWScore.cpp:1890: void
PWScore::GetAllGroups(std::vector >&, bool)
const:
Unfortunately, version 1.17 in trixie does not address this issue for me.
Bill Wohler wrote:
> Just confirmed that it is version 1.16 that I'm running at work. It was
> built from source on a Red Hat 8 system.
>
> Bill Wohler wrote:
>
> > Hi Bill,
> >
> > I
Just confirmed that it is version 1.16 that I'm running at work. It was
built from source on a Red Hat 8 system.
Bill Wohler wrote:
> Hi Bill,
>
> I can confirm this regression as I experienced it when I upgraded from
> bullseye (perhaps with a more recent version than 1.12 fr
s
like relay events to remote machines or analyze events for suspicious
behavior.
OK.
Cheers,
--
Bill.
Imagine a large red swirl here.
Hi Bill,
I can confirm this regression as I experienced it when I upgraded from
bullseye (perhaps with a more recent version than 1.12 from backports)
to bookworm (with PasswordSafe 1.16) yesterday.
Normally, when the database is locked after some time of inactivity, the
password dialog appears
Hi,
Version 1.17.0 is now available in unstable and testing. Can you
confirm whether or not this issue still happens with the new version?
Regards,
Bill
--
uninitialized
[-Wuninitialized]
72 | hint_nentry), hint_nentry(6), hint_topnentry(6), max_ntry(5),
| ^~~
Cheers,
--
Bill.
Imagine a large red swirl here.
/2/menu-2.1.49/2nd/install-menu/install-menu.cc:126·(discriminator·1)
>
> The attached patch to debian/rules fixes this by passing
> -ffile-prefix-map via CXXFLAGS and CFLAGS.
Indeed, I just saw the FTBR on qa.debian.org. Thanks for the patch!
Cheers,
--
Bill.
Imagine a large red swirl here.
Package: ksh93u+m
Version: 1.0.4-3
Severity: normal
Dear Maintainer,
The following:
( read a; print "$a" )
beeps and ignores a tab if entered before two other characters have
been typed. With () removed, it works in an interactive shell but
fails in an invoked script.
Bill
pilgrim:/etc/fapolicyd/rules.d# ls
90-deny-execute.rules
pilgrim:/etc/fapolicyd/rules.d# cat 90-deny-execute.rules
# Deny execution for anything untrusted
deny_audit perm=execute all : all
pilgrim:/etc/fapolicyd# cat fapolicyd.conf
#
# This file controls the configuration of the file access
Package: fapolicyd
Version: 1.1.7-5
Severity: important
Dear Maintainer,
I wanted to try out fapolicyd.
I typed apt install fapolicyd on my recently upgraded bookworm system
While installing it complained about being unable to do something with man
pages.
Immediately after installing no
consider, and the system should not make
assumptions how and why there are used.
Conversely, sometimes I need to use chroots to test init scripts.
start-stop-daemon should not refuse to run in a chroot if policy-rc.d allows
it.
Cheers,
Bill.
On Tue, Jun 06, 2023 at 11:34:17PM +0100, Luca Boccassi wrote:
> On Wed, 7 Jun 2023 00:01:42 +0200 Bill Allombert
> > This is beside the point. Your problematic statement was
> > "The whole project is moving toward git and Salsa ".
> > This is not cond
orking towards that, IMO.
Yes that what I wanted to say.
Cheers,
--
Bill.
Imagine a large red swirl here.
by providing better solutions rather than direct proscriptions, with
more details than just "use native systemd configuration files".
Cheers,
--
Bill.
Imagine a large red swirl here.
On Tue, Jun 06, 2023 at 07:52:35PM -0700, Russ Allbery wrote:
> Bill Allombert writes:
> > On Sun, Jun 04, 2023 at 12:25:54PM +0100, Luca Boccassi wrote:
>
> >> If you prefer, I can reword the general rule to be stricter, ie:
> >> "packages must not use
On Tue, Jun 06, 2023 at 03:16:02PM +0100, Luca Boccassi wrote:
> On Tue, 6 Jun 2023 15:23:35 +0200 Bill Allombert ,
> Luca Boccassi wrote:
> > On Tue, Jun 06, 2023 at 01:38:51PM +0100, Luca Boccassi wrote:
> > > > The diversion system is made precisely to work
; >
> > So that's what I am criticizing.
>
> Sure, and you just coincidentally happened to leave out the part that
> says the exact opposite:
This is beside the point. Your problematic statement was
"The whole project is moving toward git and Salsa ".
This is not conducive of productive interaction.
Cheers,
--
Bill.
Imagine a large red swirl here.
ll not support it_ - whether
> somebody else agrees or disagrees with this won't change any of it.
Consensus is the way the Debian Policy update process works.
But you do not need changes in Policy to report bugs about package that breaks
others, there is the "grave" severity already.
Cheers,
--
Bill.
Imagine a large red swirl here.
m wrong here.
I do not think there is consensus that this should be a RC bug outside of
a case by case basis. It is already awkward to mention systemd explicitly
in this paragraph.
The diversion system is made precisely to work around other packages behavior,
this is a feature not a bug. That it should only be used as last resort, I
think everyone agree. But when it is, it should not be a RC bug.
Cheers,
--
Bill.
Imagine a large red swirl here.
Thanks again, David.
I updated /usr/share/perl5/Finance/Quote/YahooJSON.pm from master [1]
and the quotes worked again for me:
1.
https://github.com/finance-quote/finance-quote/blob/master/lib/Finance/Quote/YahooJSON.pm
--
Bill Wohler aka
http://www.newt.com/wohler/, GnuPG ID:610BD9AD
On Sun, Jun 04, 2023 at 12:25:54PM +0100, Luca Boccassi wrote:
> If you prefer, I can reword the general rule to be stricter, ie:
> "packages must not use diversions where native mechanisms are
> available" or so. Would this be better?
"native mechanisms" seem
Ah, I see. Thanks for the clarification.
Yes, that sounds like a bug to me.
I'll test with the upstream version and see if the problem exists there
(I assume it will - I don't think any of our packaging would cause
this), and then forward upstream.
Thanks for your report!
Hi,
If I understand your report correctly, this sounds like expected
behavior - the program will lock itself in order to protect your
passwords.
You can change this behavior by going to Manage->Options->Security and
then toggling the settings that relate to "Lock password database".
Please let
bian release in years. What is the reason
> for it staying in unstable?
Historical reason. It is required for compatibility with the LSB.
At least that prevent someone to reuse the name by mistake.
Cheers,
--
Bill.
Imagine a large red swirl here.
Here too on bullseye with 1.50~rc2-2.
Editing YahooJSON.pm and changing the URL in $YIND_URL_HEAD as you did
worked for me as well. Thanks for that.
--
Bill Wohler aka
http://www.newt.com/wohler/, GnuPG ID:610BD9AD
It looks like there might have been another issue with the package (test
issues on i386).
I'm uploading another version today to fix that, so it will reset the 20
day timer, but it should migrate without issue after that unless there's
another problem.
I believe it only needs the 20 day delay. If it doesn't migrate after that,
I'll file an unblock request.
ally ran on i386 binaries anymore ?
lintian.debian.org only lists reports for amd64 packages.
I am not sure it is worth the trouble, frankly. I do not see what this would
bring us.
Cheers,
--
Bill.
Imagine a large red swirl here.
t the the CPU is 15 year old is not a sufficient rationale
to stop supporting it. It is more useful for debian-i386 to focus on CPUs that
cannot run debian-amd64 than on CPUs that can.
Cheers,
--
Bill.
Imagine a large red swirl here.
recommendation rather than a must/should (at this point?), or because it's
> more about the
> workflow inside of Debian than package contents?
Yes this is about the workflow and not the package, and so far we have let
developpers pick
whatever workflows suit them.
Cheers,
--
Bill.
Imagine a large red swirl here.
libjpeg9/copyright
>
> This issue may related to changes in the build system. While libjpeg.so.9*
> appear in the old version 1:9d-1, a rebuilt package of version 1:9d-1 on a
> latest unstable Debian system also lacks libjpeg.so.9*.
Ah thanks. I should have checked that the NMU was correct.
Cheers,
--
Bill.
Imagine a large red swirl here.
ld simply be closed, or why not?
$ dpkg -L developers-reference | grep info
/usr/share/info
/usr/share/info/developers-reference.info.gz
Cheers,
--
Bill.
Imagine a large red swirl here.
1 - 100 of 4417 matches
Mail list logo
