tags 1102414 moreinfo
thanks
removing this package breaks b-d -- mind taking a look into this
breakage and removing the tag when it's addressed?
Checking reverse dependencies...
# Broken Build-Depends:
rails: ruby-chromedriver-helper
thanks!
tags 1102277 moreinfo
thanks
# Broken Depends:
endless-sky-high-dpi: endless-sky-high-dpi
mind taking a look into this and removing the moreinfo tag when it's addressed?
paultag
--
:wq
tags 1101962 moreinfo
thanks
Thanks for filing this/doing QA work
This looks to break two related packages:
Checking reverse dependencies...
# Broken Depends:
php-mdb2-driver-mysql: php-mdb2-driver-mysql
php-mdb2-driver-pgsql: php-mdb2-driver-pgsql
They may also need a ROM bug if there's no r-d
tags 1090743 moreinfo
thanks
as noted in the report:
# Broken Build-Depends:
fonts-dejavu: woff-tools
fonts-fantasque-sans: woff-tools
that are pending some work - please remove the tag when this is ready
and we can process right away.
paultag
--
:wq
Yeah, there was a subtle bug in the title -- but it's all good. You can see
how the parser understands it at https://ftp-master.debian.org/removals
No worries, I've processed that second package. Please do reopen this bug
if I've missed yet another one :)
paultag
--
:wq
tags 1095558 moreinfo
thanks
Checking reverse dependencies...
# Broken Depends:
ruby-rails-assets-jquery.slimscroll: ruby-rails-assets-jquery.slimscroll
another r-dep to sort out before we can process this one -- just drop
moreinfo when it's sorted
thanks!
paultag
--
:wq
tags 1087665 moreinfo
thanks
Looks like there's one more r-dep (r-build-dep) that needs a quick look
before we can process this one
Checking reverse dependencies...
# Broken Build-Depends:
ruby-thinking-sphinx: ruby-appraisal
After that's in good shape drop the moreinfo tag and we can process th
tags 1098965 moreinfo
thanks
(m64k and sh4 aren't arches for Debian, you'll need to talk with ports for
that)
processing this for armel/armhf -- a few snags:
Checking reverse dependencies...
# Broken Depends:
fastp: fastp [armel armhf]
python-isal: python3-isal [armel armhf]
xrootd: libxrdec1t64
tags 1095845 moreinfo
thanks
On Wed, Feb 12, 2025 at 11:51 AM Dmitry Shachnev wrote:
> python3-pyqt5.qtremoteobjects binary package will also need to be removed,
it is cruft and not built from pyqt5 source since 5.15.11+dfsg-2 upload.
>
Checking reverse dependencies...
# Broken Depends:
qutebr
tags 1095937 moreinfo
thanks
Checking reverse dependencies...
# Broken Depends:
libprelude: ruby-libprelude
robot-testing-framework: librobottestingframework-ruby2
ruby-dataobjects-sqlite3: ruby-dataobjects-sqlite3
ruby-eb: ruby-eb
ruby-gd: ruby-gd
ruby-gsl: ruby-gsl
ruby-mmap2: ruby-mmap2
ruby-pr
tags 1095813 moreinfo
thanks
Checking reverse dependencies...
# Broken Depends:
psychopy: psychopy
--
:wq
tags 1095652 moreinfo
thanks
There's one more broken b-d that needs a quick look:
Checking reverse dependencies...
# Broken Build-Depends:
hyprpaper: libwlroots-dev
Paul
--
:wq
I have processed this change.
Please double check the outcome just because e2fsprogs is important (pun
intended).
kibi -- just a heads up that this change is now live in case there is
fallout for d-i as a result. Let me know if anything bad happens and I can
help sort it out.
paultag
On Tue, Feb 18, 2025, 8:56 AM Roberto C. Sánchez wrote:
> I agree that something like this effort is likely to reduce the
> occurence of that sort of thing. And, yes, CVE is probably not a great
> proxy. But Santiago has discussed this with quite a few of us on the LTS
> team at various points al
On Mon, Feb 17, 2025 at 9:14 PM Santiago Ruano Rincón
wrote:
> There are two numbers accompanying the source packages: the amount of
> currently open security issues in sid, and the number of security issues
> that have been present in Debian ever (as you mention).
>
I've been biting my tongue a
tags 1095501 moreinfo
thanks
Checking reverse dependencies...
# Broken Depends:
glowing-bear: glowing-bear
could you take a look into this
--
:wq
tags 1095485 moreinfo
thanks
Checking reverse dependencies...
# Broken Depends:
libjs-jsxc: libjs-jsxc
could you take a look into this?
tags 1095465 moreinfo
thanks
Checking reverse dependencies...
# Broken Depends:
node-markdown-it-html5-embed: libjs-markdown-it-html5-embed
mind taking a look into this
--
:wq
tags 1094503 moreinfo
thanks
Checking reverse dependencies...
# Broken Build-Depends:
ruby-faraday: ruby-em-synchrony
mind taking a look into this?
--
:wq
I agree. I checked all the breakage, nothing is in testing, and there's
been ample time to react. The breakage here is worth the upside. I
think ganeti is in use by DSA; hopefully someone can get that back into
good shape.
Thanks for your work over many years!
Paul
--
:wq
tags 1094807 - moreinfo
thanks
I was closing tabs and I re-read the bug here. I understand now that the
ask is that we do the removal since the maintainers of the r-deps /
r-build-deps haven't acted since 2021, and the maintenance burden here
isn't worth any shipping, and there's still time to rea
tags 1094451 moreinfo
thanks
# Broken Depends:
libjs-jsxc: libjs-jsxc
ruby-rails-assets-diaspora-jsxc: ruby-rails-assets-diaspora-jsxc
# Broken Build-Depends:
ruby-rails-assets-diaspora-jsxc: ruby-rails-assets-jquery.slimscroll
Mind taking a look into this breakage?
Paul
--
:wq
tags 1094456 moreinfo
thanks
Checking reverse dependencies...
# Broken Depends:
ruby-rails-assets-diaspora-jsxc: ruby-rails-assets-diaspora-jsxc
# Broken Build-Depends:
ruby-rails-assets-diaspora-jsxc: ruby-rails-assets-jquery-colorbox
Mind taking a look into this?
Paul
--
:wq
tags 1094502 moreinfo
thanks
I see the synchrony removal request, but the rest look real here
Checking reverse dependencies...
# Broken Depends:
ruby-em-synchrony: ruby-em-synchrony
# Broken Build-Depends:
ruby-em-synchrony: ruby-em-http-request (1.1.2-2 >=)
ruby-em-websocket: ruby-em-http-reque
tags 1094501 moreinfo
thanks
I see the removal request for http-request but webmock looks like it's
sticking around. Mind taking a look into these?
Checking reverse dependencies...
# Broken Depends:
ruby-em-http-request: ruby-em-http-request
# Broken Build-Depends:
ruby-em-http-request: ruby-em-
tags 1094609 moreinfo
thanks
Checking reverse dependencies...
# Broken Depends:
gitlab/contrib: gitlab
Mind taking a look into this?
Paul
--
:wq
tags 1094645 moreinfo
thanks
Checking reverse dependencies...
# Broken Depends:
gitlab/contrib: gitlab
Mind taking a look into this relation?
--
:wq
tags 1094807 moreinfo
thanks
Gotcha! Thanks for dealing with this migration - it's a sticky one. I'd be
happy to help with other removals as needed that are blocking this one.
I'm adding the moreinfo tag so that we don't trip over this every time
through the removal queues -- but this all looks i
tags 1094823 moreinfo
thanks
Checking reverse dependencies...
# Broken Build-Depends:
nanovg: fonts-entypo
Mind taking a look into this relationship?
Paul
--
:wq
tags 1095054 moreinfo
thanks
This package does look to have rDeps -- mind taking a look into
Checking reverse dependencies...
# Broken Depends:
rally-openstack: python3-rally-openstack
# Broken Build-Depends:
rally-openstack: python3-saharaclient
--
:wq
hppa, sh4, and x32 are not official arches, and they are not maintained via
the ftpteam / debian (in sid). as a result, i've dropped those arches from
this request, since I have no ability to action that.
paultag
--
:wq
I had to manually construct the removal command (there was enough info in
the bug but it wasn't formatted correctly), so there's always a risk of
miscommunication. Here's the log:
paultag@fasolo:~$ dak rm -p -d 1091920 -R -C package -m "remove nvptx-tools
binary on unused architectures" -b -a
arme
tags 1091836 moreinfo
thanks
processing this removal breaks a few other packages:
# Broken Depends:
c-blosc2: libblosc2-dev
pytables: python3-tables-lib
zmat: octave-zmat
we may need to stop building those packages on this arch or otherwise
change the nature of the depends relationship before th
Yes indeed, looks great, thank you for your work!
On Mon, Dec 30, 2024 at 7:39 PM Aurélien COUDERC wrote:
> control: tags -1 - moreinfo
>
> Dear Paul,
>
> On Fri, 27 Dec 2024 22:56:53 -0500 "Paul R. Tagliamonte" <
> paul...@gmail.com> wrote:
> > tags 1090
On Sun, Dec 29, 2024 at 6:12 AM Cyril Brulebois wrote:
> Cyril Brulebois (2024-12-29):
> > I can't believe this just happened.
> >
> > There was no advance warning for the installer team (that I'm aware of),
> > the removal not only removed the package from unstable but also from
> > testing rig
On Sun, Dec 29, 2024 at 6:12 AM Cyril Brulebois wrote:
> Cyril Brulebois (2024-12-29):
> > I can't believe this just happened.
> >
> > There was no advance warning for the installer team (that I'm aware of),
> > the removal not only removed the package from unstable but also from
> > testing rig
Hey Hefee
I also filed a bug with my comments from the RM, then I closed it in the
morning because I realized I was wrong. Please ignore that bug and my
previous comments. It's all fine. Sorry about that, it's my fault.
Paul
On Sat, Dec 28, 2024, 9:38 PM Hefee wrote:
> Hey,
>
> thx for removi
; On Sat, Dec 28, 2024 at 09:28:12AM -0500, Paul R. Tagliamonte wrote:
> > On second thought I don't think fixing the arch constraints on arch all
> is
> > worth the squeeze.
>
> TTBOMK restricting dependencies to specific archs in Arch: all
> packages is not possible in
tags 1090954 - moreinfo
tags 1088212 - moreinfo
thanks
On second thought I don't think fixing the arch constraints on arch all is
worth the squeeze.
; reopen 1090075
> thanks
> On 28/12/2024 03:28, Paul R. Tagliamonte wrote:
>
> Heyya Peter,
>
> There's a subtle syntax in the bug title; so I took the liberty of fixing
> it by hand. I think the auto-decrufter already resolved this situation
>
> I don't think the a
Package: nextcloud-desktop
Severity: important
User: paul...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks
I processed #1091356 which removed
dolphin-nextcloud | 3.13.2-2 | mips64el
libnextcloudsync-dev | 3.13.2-2 | mips64el
libnextcloudsync0t64 | 3.13.2-2 |
tags 1091323 moreinfo
thanks
processing this removal breaks a few relations in the archive. please
ensure these relations are sorted and then remove the moreinfo tag and we
can process it.
# Broken Depends:
libt3widget: libt3widget-dev
libt3widget2t64
libt3window: libt3window-dev
tags 1091313 moreinfo
thanks
processing this removal breaks the following relation
# Broken Build-Depends:
remrun: python3-cfg-diag (0.4 >=)
please resolve this relationship and remove the tag and we can process this
paultag
--
:wq
tags 1091088 moreinfo
thanks
# Broken Depends:
meta-kde: kde-baseapps
this relationship needs to be fixed for the arches in question, and after
that's in good shape, feel free to drop the tag and we can process this
paultag
--
:wq
tags 1090982 moreinfo
thanks
# Broken Build-Depends:
tellico: libkf5sane-dev
this relation needs to be sorted first, and when that's in good shape feel
free to remove the moreinfo tag and we'll get around to processing this
again
paultag
--
:wq
tags 1090954 moreinfo
thanks
# Broken Depends:
debian-design: design-desktop-graphics
this package is arch:all so it likely needs an arch constraint; please drop
the moreinfo tag when it's in good shape and i can process this
--
:wq
tags 1090948 moreinfo
thanks
# Broken Depends:
akonadi-contacts: libkf5akonadicontact-dev
libkf5akonadicontact5
please resolve these relations and remove the moreinfo tag when it's ready
to be processed again
paultag
--
:wq
I see the other bug now, cancel that, thank you
On Fri, Dec 27, 2024 at 10:44 PM Paul R. Tagliamonte
wrote:
> tags 1090909 moreinfo
> thanks
>
> # Broken Depends:
> itinerary: itinerary
>
> the itinerary package needs to no longer hold this relationship on i386
> (maybe
tags 1090909 moreinfo
thanks
# Broken Depends:
itinerary: itinerary
the itinerary package needs to no longer hold this relationship on i386
(maybe by no longer building on it), and then please remove the moreinfo
tag and we can process this
paultag
--
:wq
pour one out for bird; thank you for your many years of service
--
:wq
tags 1090393 moreinfo
thanks
processing this removal results in a broken build-depends relationship
looks like facet-analyser has a architecture: any build-dep relation on
this package.
facet-analyser will need to exclude s390x before i can continue with this
removal. once that relationship is
tags 1089928 moreinfo
thanks
processing this removal breaks relations in the archive
I initially checked (because it's a -dev) if it was arch:all so I could
process this, but they look to be arch-any. please ensure those packages
aren't built (or don't have the relationship) on mips64el,ppc64el a
tags 1089121 moreinfo
thanks
removing glycin-loaders will break a relationship in the archive; please
resolve this and then remove the moreinfo tag
Checking reverse dependencies...
# Broken Depends:
loupe: loupe
--
:wq
tags 1089878 moreinfo
thanks
processing this removal breaks relations in the archive, please ensure
these are fixed then remove the moreinfo tag
thanks!
paultag
Checking reverse dependencies...
# Broken Depends:
libkf5calendarsupport: libkf5calendarsupport5abi1
# Broken Build-Depends:
libkf5c
tags 1089850 moreinfo
thanks
removing gimp from s390x results in broken relationships. Please fix these
(likely by removals for s390x after updating the arches on each package)
and remove the moreinfo tag once there are no more dangling relationships
paultag
# Broken Depends:
debian-design: de
tags 1089685 moreinfo
thanks
removing this package breaks a dependency relationship, please ensure that
is fixed and remove the moreinfo tag once it's in sid
thank you!
# Broken Depends:
rally-openstack: python3-rally-openstack
--
:wq
tags 1089582 moreinfo
thanks
> The last remaining rdep was postgresql-16-repmgr, removal of that was
> requested in #1089581.
was processing this removal but repmgr is still in sid; that removal was
for 32 bit arches. Can you file a removal for that package, then remove the
moreinfo here and i ca
tags 1088212 moreinfo
thanks
# Broken Depends:
init-system-helpers: init-system-helpers
please remove the moreinfo tag when this relation is resolved
paultag
--
:wq
tags 1087913 moreinfo
thanks
Broken Build-Depends
opensubdiv: ptex-base
This needs to be resolved before continuing with this removal, please
remove the tag when this is sorted
Thanks!
paultag
--
:wq
I suggest someone looking for a removal file a ROM bug so this shows up in
the tracker when we go through and process removals.
https://wiki.debian.org/ftpmaster_Removals
On Fri, Dec 6, 2024, 8:21 AM Andreas Tille wrote:
> Package: ftp.debian.org
> Severity: normal
> X-Debbugs-Cc: Rene Weber ,
Package: python3-meshtastic
Severity: important
thanks
It appears as though python3-meshtastic is missing a dependency on
python3-dotmap. I don't see dotmap in the archive, so this may be an issue
:)
$ meshtastic
Traceback (most recent call last):
File "/usr/bin/meshtastic", line 5, in
fro
Package: meshtastic
Severity: serious
User: paul...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks
The LICENSE file is Apache 2. The pyproject.toml says GPL-3. I did some
looking upstream, and there's a bug[1] and a PR that was fixed last week[2].
I don't love the w
Package: meshtastic
Severity: serious
User: paul...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks
The LICENSE file is Apache 2. The pyproject.toml says GPL-3. I did some
looking upstream, and there's a bug[1] and a PR that was fixed last week[2].
I don't love the w
On Thu, Jun 20, 2024 at 11:00 AM Gerardo Ballabio <
gerardo.balla...@gmail.com> wrote:
>
> I might have misunderstood Paul's questions. If so I'm sorry (if Paul
> wishes he could explain what he actually meant), but I think that my
> questions are relevant too.
I've been following the thread and h
I sure want to stay clear of this conversation, so I'm going to drop this
and make it brief
(not to grandstand, but in the spirit of being honest and speaking my truth
-- I personally (without any hats on) I'm interested in the end-goals --
this effort seems like a good thing to help move the proj
The *binary* removal request was proper, I think a -D/--do-close snuck
into dak rm (easy thing to do here), which we usually only do with
source removals.
I've sent a control message, I'll get these reopened. Sorry about that.
paultag
On Wed, Apr 17, 2024 at 9:57 AM Vincent Lefevre wrote:
>
>
There's also a very through exploration at https://github.com/amlweems/xzbot
Including, very interestingly, a discussion of format(s) of the
payload(s), and a mechanism to replace the backdoor key to play with
executing commands against a popped sshd, as well as some code to go
along with it.
p
On Tue, Apr 2, 2024 at 5:12 PM Pierre-Elliott Bécue wrote:
> If you have a master key on your laptop, when a yubikey is in, while
> running gpg --edit-key your_main_key, you can use the "addcardkey" to
> create a subkey on the Yubikey directly.
>
Yeah, seconded for sure. This is the configuratio
Sorry about that, the last patch had build cruft. Updated. I ought to
have read through better - sorry about that.
paultag
--
:wq
vim-listxattr.debdiff
Description: Binary data
Package: vim
Severity: wishlist
Tags: patch
I sent a fix to upstream vim to handle a bug where vim would attempt
to allocate size_t max (for me, 0x aka
18446744073709551615 bytes) when the filesystem responded with an
error on listxattr other than not supported.
The upstream patch
I don't usually (ever?) pipe up with my other hat(s) on the
@openbsd.org lists -- but --
With my @debian.org hat on, I'll note that we[1] (and I think Fedora
too?) took issue with the name "ssh3", since it is not using (or even,
frankly, related to) the OpenSSH protocol. It'll parse a few OpenSSH
> I agree.
> Removal request by maintainers are fine.
> Removal requests by anyone for un-maintained packages are ok.
> Removal requests by third-parties for packages with a maintainer are
> a situation to take a closer look at least.
Without:
1) my ftpteam hat on
2) any specific reference to t
On Sat, Aug 19, 2023 at 2:29 PM Roberto C. Sánchez wrote:
> The reasons why the FTP masters might reject a package from the archive
> are public [0]. Nowhere on the list is there an entry that says
> "somebody doesn't like this package" or "it has stuff that might offend
> someone" as a valid rea
On Sat, Aug 19, 2023 at 2:29 PM Roberto C. Sánchez wrote:
> The reasons why the FTP masters might reject a package from the archive
> are public [0]. Nowhere on the list is there an entry that says
> "somebody doesn't like this package" or "it has stuff that might offend
> someone" as a valid rea
Packages will be removed from experimental if it contains a newer version
in unstable (a so called "NVIU" removal).
Which is to say if someone uploads to experimental with a fix, and someone
else uploads to unstable without that change but a huger version, the
experimental package will be removed.
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
The Sunlight Foundation (very sadly) dissolved a few years back, and
the API is now offline. This package is no longer useful and should be
removed.
--
:wq
Package: php-dompdf-svg-lib
Severity: serious
User: paul...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks
As noted in :
This package is LGPLv3+ (LGPL-3.0+) not LGPLv3 (LGPL-3.0). Please
update your copyright file in another upload before it migrates to
testing/stab
Package: php-dompdf-svg-lib
Severity: serious
User: paul...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks
As noted in :
This package is LGPLv3+ (LGPL-3.0+) not LGPLv3 (LGPL-3.0). Please
update your copyright file in another upload before it migrates to
testing/stab
Package: ftp.debian.org
Severity: normal
I wrote olla to allow short names when addressing hosts by overloading
getaddrinfo. Lately, this seems like a bad idea, since anything that
lets you get away with this is something that isn't checking the
peer's identity (ok; not true for SSH but for the ge
I did send this to the right place!
I had to go onto IRC to confirm - and someone was nice enough to start
a review. May be good for others waiting for feedback to join the IRC and
do the same. I suspect this ML is a bit disused for contributions.
>From the conversation on IRC which I'm putting i
> So I think route.8 is where we should try to have complete documentation,
> and once that is done we should change Xr's and other documentation to
> point at route.8 instead of netstat.8
In an effort to have my interactions on this list wind up being helpful
rather than more work for overworked
On Tue, Dec 20, 2022 at 8:27 PM Paul R. Tagliamonte wrote:
>
> Heyya tech@,
>
> Please keep me on cc, I'm not subscribed
Please keep me on cc. The last message wasn't sent to me, so my In-Reply-To
is going to be wrong. I'm not subscribed to tech@.
>From the web:
&g
Heyya tech@,
Please keep me on cc, I'm not subscribed
I've been working on porting some of my linux specific software to
work on OpenBSD. While working with some routing-specific code,
I needed to pull up show.c to map the letters in `route show` to the
RTF_ values.
I figured while I was in ther
ectory-arguments-to-ld.patch".
Both patch flavors build on my Debian sid box and an OpenBSD 7.2 box.
paultag
--
:wq
From a9168d998d72b3d24afd050aedcc38bfb9839cd5 Mon Sep 17 00:00:00 2001
From: "Paul R. Tagliamonte"
Date: Fri, 16 Dec 2022 18:56:42 -0500
Subject: [PATCH] Pass add
It seems like this change would mean a single physical data is not "one
site" as defined by the end user rules if each 'customer' gets a globally
routable subnet.
That does seem like a good distinction, since a single site hosting 10,000
customers' virtual infrastructure should probably be treated
Hello!
Please keep me on CC, I am not subscribed to this list (yet)
I've been using the C API to stream audio from my program to my speakers.
That's been great! I'm, however, I'm now at a place where I need to
send the audio from my program to another program as an input (or more
specifically, a
I searched my records and found the rejection. Looks like it's fixable.
Quoted here and I've cc'd the ftpteam if anyone has questions
+--+
| REJECT reasoning |
+--+
A trainee points out:
ext\libstrawberry-common\core\scoped_nsautorelease_pool.mm has a
I searched my records and found the rejection. Looks like it's fixable.
Quoted here and I've cc'd the ftpteam if anyone has questions
+--+
| REJECT reasoning |
+--+
A trainee points out:
ext\libstrawberry-common\core\scoped_nsautorelease_pool.mm has a
Package: python3-lib389
Version: 2.0.15-1
thanks
```
# dsctl ds cockpit enable
/bin/sh: 1: rpm: not found
Error: The 'cockpit' package is not installed on this system
```
--
:wq
In the same way Martin Shkreli can claim the state of New York has
stopped him from doing pharmaceutical research -- breaking the rules
results in consequences. They were the results of your own actions.
Blaming others is shirking responsibility.
On Wed, Mar 23, 2022 at 11:51 AM Adam Borowski wro
> That is a big gray area, but restrictions exist in
> the US [3]
The Hatch Act only applies to Employees of the United States Federal
Government from engaging in political activity using their official
position (in the case of a regular, and not restricted federal
employee). You can't engage in p
I seemed to remember we retain actual outside council last i knew. Is that
still the case?
This request ought to come from the ftp team if we do do this, fwiw
Paul
On Tue, Feb 1, 2022, 4:12 AM Stephan Lachnit
wrote:
> On Mon, Jan 31, 2022 at 10:47 AM Jonathan Carter wrote:
> >
> > As for get
> While I also agree with Paul that the current name is somewhat dated
> technologically, it is not fatally flawed. Therefore, I think we
> should leave the naming decision to the FTP masters themselves.
This doesn't change anything about this thread or this email, but in the spirit
of trying to b
7;s. I thought I did this last month but it
doesn't look to be updated fully. I don't know if it's A, B or A & B that's
flagging for you
paultag
On Thu, Mar 25, 2021 at 3:14 PM Kurt Roeckx wrote:
> On Wed, Mar 24, 2021 at 05:13:28PM -0400, Paul R. Tagliamonte wrote:
&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
> Under 4.1.5 of the Constitution, the developers by way of GR are the body
> who has the power to issue nontechnical statements.
>
>
https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md
> is a statement which I believe Deb
After running a "make install" in git with the 5.10.0-trunk-amd64 kernel, I
can confirm the WiFi card is working on the new Dell XPS 13.
Thanks again for maintaining this package!
Paul
--
:wq
After running a "make install" in git with the 5.10.0-trunk-amd64 kernel, I
can confirm the WiFi card is working on the new Dell XPS 13.
Thanks again for maintaining this package!
Paul
--
:wq
Package: firmware-atheros
Severity: wishlist
thanks
The spiffy new Dell XPS 13 9310 is shipping, but is not sold as supporting
linux yet -- but appears to work great, with the exception of the Qualcomm
Technologies 802.11ax chipset.
In addition to #97994's CONFIG_ATH11K kernel change, Vincent poi
Package: firmware-atheros
Severity: wishlist
thanks
The spiffy new Dell XPS 13 9310 is shipping, but is not sold as supporting
linux yet -- but appears to work great, with the exception of the Qualcomm
Technologies 802.11ax chipset.
In addition to #97994's CONFIG_ATH11K kernel change, Vincent poi
That url will be used by go get. A go get should determine the right path
based on meta headers. It should import fine!
What's the thing you're trying to do here?
Paul
On Sun, Mar 15, 2020, 12:39 PM Tong Sun wrote:
> On Sun, Mar 15, 2020 at 2:24 AM Vincent Bernat wrote:
> >
> > ❦ 14 mars 20
1 - 100 of 284 matches
Mail list logo
