Since it sounds like you're experiencing this in an OpenStack cloud,
one workaround would be to boot your server instance with
configdrive enabled; cloud-init knows how to get its metadata that
way as well.
--
Jeremy Stanley
tags 1089501 + fixed-upstream
It was pointed out to me in IRC by jaltman that Linux 6.12 support
was newly added in 1.8.13.1, per its release notes.
says as
much).
I'm personally surprised that it's not packaged in Debian yet, but
you might want to check whether there's interest from the Debian
OpenStack team in collaborating on a package for it.
--
Jeremy Stanley
signature.asc
Description: PGP signature
Unfortunately this is now appearing in sid since Linux 6.10 has been
uploaded there as well.
--
Jeremy Stanley
eally help anyone else.)
--
Jeremy Stanley
, but you're right the concern is greater in
Debian due to the recent transition.
--
Jeremy Stanley
It looks to me like the default Exim config in Debian explicitly
calls /usr/bin/spfquery.mail-spf-perl from the spf-tools-perl
package, not the libspf2 implementation supplied by the spfquery
package. Also spf-tools-perl is suggested by exim4-base, while
neither spfquery nor any other packages buil
Seems like this commit may address the build failure?
https://git.openafs.org/?p=openafs.git;a=commit;h=c4c1689
--
Jeremy Stanley
right files too, or is it really simply a hard-coded list of
matching patterns?
Regardless, this is great work, thanks for kicking off the
reevaluation!
--
Jeremy Stanley
signature.asc
Description: PGP signature
This is now addressed upstream in the following commit, so you
should be able to drop the patch when packaging the next release
(whenever that happens):
https://gitlab.xiph.org/xiph/ezstream/-/commit/c9426f2
The fix for this appears to have merged upstream in January, so
could probably be backported in Salsa:
https://gerrit.openafs.org/14882
Source: rust-nitrocli
Version: 0.2.4-1
Severity: wishlist
Dear Maintainer,
Now that the bullseye freeze is behind us, it would be nice to have a
new version of nitrocli. The currently packaged version is several years
old, and lacks support for recent hardware (e.g. my Librem Key fobs).
I've been
ude
https://packages.debian.org/python3-testrepository or
https://packages.debian.org/python3-stestr (both are
subunit-emitting test runners), which pretty much all of the
OpenStack projects moved to years ago as replacements for nose.
--
Jeremy Stanley
signature.asc
Description: PGP signature
it was version 8 of bash, and
so it's name was switched to bashate in order to avoid confusion.
--
Jeremy Stanley
signature.asc
Description: PGP signature
nificant amount of new security or
privacy for Debian users, that would be disingenuous. Just say the
default is switching to HTTPS because that's what users, by and
large, expect today.
--
Jeremy Stanley
signature.asc
Description: PGP signature
posed by plain HTTP when used for unrelated
purposes, and no longer needing to repeatedly explain to users that
Debian has gone to great lengths to implement package distribution
security which doesn't really depend at all on transport layer
encryption.
--
Jeremy Stanley
signature.asc
Description: PGP signature
other environments expecting to configure IPv6 via
DHCP with the Bullseye cloud images.
--
Jeremy Stanley
Package: python-openstackclient-doc
Version: 5.4.0-4
Severity: normal
The manpage for the openstack CLI mentions the following:
AUTHORS
Please refer to the AUTHORS file distributed with
OpenStackClient.
COPYRIGHT
Copyright 2011-2014 OpenStack Foundation and the auth
Thanks for pulling this into unstable and testing! Is there any work
in progress to fix it in stable as well? I took a quick peek in
Salsa and didn't see any merge requests or an obvious branch for
Buster's 1.8.2 (just the debian/1.8.2-1 tag).
With the release of libnitrokey 3.6 on September 19, this
functionality now seems to be officially available upstream. The
nitrokey-authenticator package which is an rdep for this mentions in
its description "The application supports both, Nitrokey Pro2 and
LibremKey. For the latter, however, you n
In my case, even after upgrading it continued to refuse to rebuild
until I manually blew away an earlier failed build in
/var/lib/dkms/openafs/ but after that, yes, it's back to working
great for me as well. Thanks!!!
--
Jeremy Stanley
I'm trying to address this as part of
https://salsa.debian.org/kernel-team/linux/-/merge_requests/203 if
interested folks want to take a look at the third commit there
("[x86] PMIC operation region support") and see if it looks
reasonable.
--
Jeremy Stanley
I've submitted
https://salsa.debian.org/kernel-team/linux/merge_requests/203 in an
attempt to address this.
Package: linux
Version: 5.5~rc7-1~exp1
Severity: wishlist
CONFIG_INTEL_CHT_INT33FE (already enabled) began requiring
CONFIG_USB_ROLES_INTEL_XHCI and CONFIG_TYPEC_MUX_PI3USB30532 as of
kernel version 4.17.
CONFIG_INTEL_SOC_PMIC_CHTWC (already enabled) started to require
CONFIG_I2C_DESIGNWARE_PLATF
es ecosystem? I'm honestly curious as I
still only ever see checksums in hexidecimal notation. The
sha512sum(1) manpage makes no mention of having support for
verifying base64-encoded checksums, for example.
There's something to be said for sticking with traditional
standards; newer is not always better.
--
Jeremy Stanley
This sounds a lot like
https://bugzilla.redhat.com/show_bug.cgi?id=1376835 which includes a
potential patch (unfortunately no indication if this got upstreamed,
or whether it's reproducible with newer Apache releases).
--
Jeremy Stanley
queens/admin/remote-console-access.html#serial-console
I can imagine for some deployments, none of the users might
want/need a graphical OOB console for their instances at all so
wouldn't want to incur the overhead (especially securing it, as
Jonathan so notes.)
--
Jeremy Stanley
Added a hardware entry to the wiki for this with some more extensive
notes/gotchas:
https://wiki.debian.org/InstallingDebianOn/GPD/Pocket
--
Jeremy Stanley
th bare
minimum installation and carefully tracking individual packages I
need. I can't imagine there would be any problem installing typical
Tasks on this device.
--
Jeremy Stanley
am for this and planning to update it to
support Python 3.x in preparation for 2.7 reaching end of life?
--
Jeremy Stanley
for this and planning to update it to
support Python 3.x in preparation for 2.7 reaching end of life?
--
Jeremy Stanley
Proposed https://salsa.debian.org/kernel-team/linux/merge_requests/4
for this.
--
Jeremy Stanley
Package: linux
Version: 4.16~rc5-1~exp2
Severity: wishlist
Power management for GPD Pocket UMPC systems requires kernel driver
modules built by setting CONFIG_PWM_LPSS_PLATFORM,
CONFIG_INTEL_INT0002_VGPIO, CONFIG_INTEL_CHT_INT33FE,
CONFIG_TYPEC_FUSB302, CONFIG_BATTERY_MAX17042 and
CONFIG_CHARGER_B
I'm seeing this logged to the journal/syslog by default on shutdown
under an up to date sid install.
--
Jeremy Stanley
On 2018-03-24 00:03:12 + (+), Simon McVittie wrote:
[...]
> On Fri, 23 Mar 2018 at 20:30:17 +0000, Jeremy Stanley wrote:
> > This may also serve to help narrow down (via reverse dependency) the
> > list of packages which will trigger violent reactions when mixed in
>
This may also serve to help narrow down (via reverse dependency) the
list of packages which will trigger violent reactions when mixed in
the same context with pip 10 invocations, per
https://github.com/pypa/pip/issues/4805 .
--
Jeremy Stanley
Tags: +patch
Proposed https://salsa.debian.org/kernel-team/linux/merge_requests/1
for this.
Package: linux
Version: 4.16~rc5-1~exp1
Severity: wishlist
Support for the fan controller on GPD pocket systems has merged to
mainline for 4.16, but is not yet configured to be built in the latest
kernel packages.
Control: tags -1 confirmed fixed-upstream patch pending upstream
Attached is the fix applied in upstream revision control, which I
will add to debian/patches in a coming 2.3-2 upload.
--
Jeremy Stanley
From: Jeremy Stanley
Date: Fri, 10 Mar 2017 15:13:31 +
Subject: [PATCH] Fix Py3K
Package: weather-util
Version: 2.3-1
Severity: important
When running with a clean cache using compressed correlation data files
(such as those provided by the weather-util-data package), the following
traceback is observed:
fungi@cthulhu:~$ weather kffa
Searching via station...
Traceback (most r
.
[...]
It's not packaged for Debian yet nor do I see any RFP/ITP, but I've
been happily using https://github.com/tehmaze/diagram for a few
years (installable from PyPI via pip so probably easy enough to
package). Its default mode uses 8-dot Braille patterns for axis
graphs.
--
Jeremy Stanley
a feature which will probably ship
in the next JJB release anyway.
--
Jeremy Stanley
signature.asc
Description: Digital signature
An updated package of 2.2 is in the works for sid, and I'm planning
to propose a trivial build-time revision to the 2.0 package suitable
for stable-proposed-updates.
The expanded correlation data format in 2.0 came about as a result
of an earlier change in NWS/NOAA's content hosting, and was aimed
Thanks for the heads up!
I've confirmed that a simple sed -i to replace all occurrences of
http://weather.noaa.gov/pub/ with http://tgftp.nws.noaa.gov/ in
configuration and correlation data files it seems to get things
working again. I'll see about getting an update put together
tomorrow.
On 2016-05-17 14:32:46 +0100 (+0100), James Page wrote:
[...]
> * URL : https://github.com/openstack/python-monascaclient
[...]
Note that's just a mirror of the official copy on git.openstack.org.
--
Jeremy Stanley
mat like NOAA's, I will be happy to start
incorporating it into the weather utility."
To restate, right now this utility only knows where to download
forecast data files for the USA.
--
Jeremy Stanley
rted working on a fix for the multi-URL problem, but it's
not likely to make it into Jessie since the release freeze is
already well underway.
--
Jeremy Stanley
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ensch/+archive/ubuntu/sane-git/+build/6962214
and was able to use the scanner normally thereafter.
--
Jeremy Stanley
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
-I was paraphrasing Ralph Waldo Emerson's warning against
consistency for consistency's sake--it wasn't meant as a personal
slight in any way whatsoever.
--
Jeremy Stanley
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Okay, not _mine_ specifically, but
someone's...) Changing the established values in a keymap out from
under users is foolish when the gains are nearly nonexistent and the
workaround is relatively trivial for those who actually want to side
with hobgoblins.
--
Jeremy Stanley
--
To UNSUBSC
properly starting on reboot again.
--
Jeremy Stanley
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
nd the
latter could lead to conflicts in the future when someone else comes
along who actually wants to package the software which is shipping
with that library).
Anyway, apologies for the detour and thanks for the ongoing
packaging effort--that hard work doesn't go unnoticed!
--
Jeremy Stanle
on
its face, at least, it seems dubious that you should actually need a
Debian wrapper around a Python wrapper around a Javascript library
which is itself already packaged in Debian.
--
Jeremy Stanley
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
least in most cases distro packagers shouldn't
need to worry about them unless the equivalent JS libs aren't
already in their distros.
--
Jeremy Stanley
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On 2014-06-16 15:29:20 +0800 (+0800), David Adam wrote:
> I removed my package so that Guillaume could upload his, but I
> think that took his 2.0.16 package away too - sorry. Guillame does
> have a 2.0.16 package available.
It would be great to get that moving again... there are a lot of bug
fixe
It looks like the proposed source package has fallen off mentors.d.n
in the past month. Is this still in progress? Thanks in advance!
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( ki
This sounds like a subset of python-pbr's features. What additional
benefits does it provide?
http://packages.debian.org/sid/python-pbr
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN );
On 2013-09-30 22:09:55 -0300 (-0300), gustavo panizzo wrote:
[...]
> Upstream Author : OpenStack LLC,
[...]
Worth noting: OpenStack, LLC has not existed for over a year. While
many copyright notices have not been updated to reflect it, all
copyright held by the old LLC was transferred to the Op
Odd, my first message must have gotten greylisted by BDO since it's
showing up after my second message in the bug log. At any rate, I'm
attaching the patch I'll be applying in the next upstream release in
case you or anyone else using 2.0 finds it useful to apply manually
in the interim.
--
{ IRL(
Thanks! I'll fix this upstream and backport a patch for the version
going into Wheezy (hopefully I can get the RMs to hint it in). I
agree the search cache notification doesn't belong in terse output.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP
On 2012-07-11 21:17:59 + (+), Jeremy Stanley wrote:
[...]
> hopefully I can get the RMs to hint it in
[...]
Scratch that. Re-reading the Wheezy release policy, we'd need to be
able to argue that this is at least "important: a bug which has a
major effect on the usability
I've forwarded this upstream (to myself). I've received several
reports of this specific oversight in the past couple of months and
a fix for it is incorporated into the upcoming 2.0 release. I'll
close this bug with the new upload soon. Thanks!
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.o
On Fri, Mar 12, 2010 at 02:03:37PM +, Jeremy Stanley wrote:
> Thanks! I'll see if I can find why NOAA/NWS stopped publishing their
> METAR index or where they moved it.
[...]
Okay, so it looks like NOAA didn't move it, but rather there's
probably some temporary problem
On Fri, Mar 12, 2010 at 02:05:13PM +, The Fungi wrote:
> I've confirmed this bug is still present in my development version
> as well. I'll see if I can track down and fix the issue shortly.
Apologies for the delay... attached is a patch which solves this
issue in 1.4. I've integrated my devel
The get_metar() function is attempting to parse the name of the
locality out of the first line of the decoded METAR. Using the
verbose output option you can see why this won't work:
fu...@cthulhu:~$ weather -viKMJX
Station name not available
Mar 12, 2010 - 09:55 AM EST / 2010.03.12 1455 U
On Thu, Mar 11, 2010 at 07:11:59PM -0500, Celejar wrote:
> Here are a couple of working urls:
[...]
Thanks! I'll see if I can find why NOAA/NWS stopped publishing their
METAR index or where they moved it. Worst case, I'll update the
documentation with these alternative locations.
--
{ IRL(Jeremy_
> The way I see it, whenever ID is given, the program should ignore
> the City and St tags from the default section of the configuration
> file if there's no forecast for that location. Current behaviour
> is quite confusing, having weather conditions and forecast for
> different places - it doesn'
This bug is being "fixed" upstream by an addition in the FAQ file:
5. Why do I get the wrong forecast when specifying -i or --id?
The -i or --id switch (or the id parameter in an alias definition),
only tells weather(1) what current conditions to retrieve. If you
specify -f or --forecast on the c
-util
Version: 1.1-1
Maintainer: Jeremy Stanley <[EMAIL PROTECTED]>
Build-Depends-Indep: debhelper (>= 4.1.67), python
Architecture: all
Standards-Version: 3.6.2
Format: 1.0
Priority: extra
Section: utils
Installed-Size: 64
Architecture: all
Depends:
On Sat, Apr 22, 2006 at 08:02:20PM +0200, gregor herrmann wrote:
> You might (with your upstream hat on) take a look at (python-)pymetar,
> a nice python module that can retrieve METAR data from all around the
> world.
Thanks! I actually looked at it before I started writing my util,
and it looks
Package: evms
Version: 2.5.4-2
Severity: grave
Tags: patch
Justification: renders package unusable
A syntax error in the evms postinst leaves the package in an
unconfigured state:
Setting up evms (2.5.4-2) ...
/var/lib/dpkg/info/evms.postinst: line 37: syntax error near unexpected token
`fi'
dp
71 matches
Mail list logo
