I've created a non-responsive maintainer check for: Robert-André Mauchin
I need to get gtiocompressor in rawhide.
This is part of my effort to get cantata built for qt6 and also get that pushed
to
rawhide. Rex Dieter is the maintainer for that package, and I've created a
non-responsive mainta
I've initiated a request also here:
https://bugzilla.redhat.com/show_bug.cgi?id=2381541
Has anyone been able to contact Rex?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Package uses old fedora account system
https://bugzilla.redhat.com/show_bug.cgi?id=237
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://do
From what I've been reading it seems the path of least resistance is to just
keep the Fedora Workstation branding and have two options: GNOME or KDE
Plasma. I don't believe that it should be overly confusing to ask people to
pick one. I just asked Google Gemini to come up with a suggestion an
On 4/26/23 16:04, Vitaly Zaitsev via devel wrote:
On 20/04/2023 23:20, Matthew Miller wrote:
It’s time to transform the Fedora devel list into something new
I think such serious questions should be put to a vote. Not a FESCo
vote, but a vote for all Fedora contributors (can be combined with
Thanks Pavel, and thankyou to the previous maintainer for their efforts.
On Tuesday, 4 April 2023 at 09:18:32 pm AEST, Major Hayden via devel
wrote:
On Mon, Apr 3, 2023, at 18:32, Pavel Solovev wrote:
> I'm packaging required go dependencies and I'll grab it.
Thank you, Pavel! ;)
--
M
The previous maintainer orphaned Kitty terminal package on 29th March 2023.
See: https://bugzilla.redhat.com/show_bug.cgi?id=2165819
https://sw.kovidgoyal.net/kitty/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
yubioath-desktop and potentially yubikey-manager-qt will not be included in the
F38 repository due to packaging issues. For additional information and
suggested mitigations, please review:
https://discussion.fedoraproject.org/t/f38-yubioath-desktop-yubikey-manager-qt-will-no-longer-be-available
On 12/22/22 15:39, Lennart Poettering wrote:
Well, the thing is: a chain of trust is a*chain*, hence you must
ultimately hook validation to what the firmware provides you with as
root. And that ultimately is the SecureBoot db on commodity hardware.
Well, the thing with a chain of trust is the
On 12/20/22 21:27, Simo Sorce wrote:
Finally, unless this proposal harms Fedora I do not see why oppose it.
If, as you fear, it won't work ... then it won't and we'll try
something else.
You do realize that the day that Lenovo started to sell it's hardware
with Fedora pre-installed ( as it w
On 15.4.2022 00:44, Kevin Kofler via devel wrote:
One of the reasons people use GNU/Linux is exactly to escape the hardware
manufacturers' planned obsolescence treadmill.
True but that does not mean Fedora is the best distro for that + it
looks like hw vendors are taking lessons from the Apple
On 14.4.2022 23:25, Nikolay Nikolov wrote:
On 4/15/22 01:53, Jóhann B. Guðmundsson wrote:
On 14.4.2022 22:24, Nikolay Nikolov wrote:
On 4/14/22 23:49, Jóhann B. Guðmundsson wrote:
On 14.4.2022 18:20, Chris Adams wrote:
Once upon a time, Robbie Harwood said:
Given there is consensus that
On 15.4.2022 00:38, Kevin Kofler via devel wrote:
Jóhann B. Guðmundsson wrote:
Trying to support that legacy scenario where certain hw may or may not
work is a nightmare for developers, support teams and Fedora since
Fedora is not a distribution with a long term support, LTS distributions
are
is response to me in private when I
exposed him last time here on devel.
"little idiot: the Fedora COC don't apply for pruvate mails just because
the topic is fedora relevant"
On 14.4.2022 21:46, Reindl Harald (privat) wrote:
Am 14.04.22 um 22:49 schrieb Jóhann B. Guðmund
On 14.4.2022 22:24, Nikolay Nikolov wrote:
On 4/14/22 23:49, Jóhann B. Guðmundsson wrote:
On 14.4.2022 18:20, Chris Adams wrote:
Once upon a time, Robbie Harwood said:
Given there is consensus that legacy BIOS is on its way out
I don't think this statement is true, unless Fedora do
On 14.4.2022 18:29, Peter Boy wrote:
Maybe "legacy BIOS on physical hardware" is on its way out, but it
doesn't seem that it is true across the board in VM environments.
That’s maybe true for desktops, but in the server world any server needs to be
able to do bios boot, because of the data ce
On 14.4.2022 18:20, Chris Adams wrote:
Once upon a time, Robbie Harwood said:
Given there is consensus that legacy BIOS is on its way out
I don't think this statement is true, unless Fedora doesn't want to be
considered for a bunch of popular VM hosts (e.g. Linode and such) that
have no stated
On 14.4.2022 16:38, Ben Beasley wrote:
I’m not talking about refurbished parts or new old stock. I’m talking about the
brand-new SATA HDDs and SSDs, ATX power supplies, case fans, and other
components that are backwards-compatible in systems pushing twenty years old
(SATA) or older (PSUs, fans
On 14.4.2022 15:53, Peter Boy wrote:
Am 14.04.2022 um 17:33 schrieb Jóhann B. Guðmundsson :
It should be quite apparent prevent the hw support lifecycle dialog from ever
occurring again we need a rigid planned supported hw lifecycle.
Again, the legacy BIOS discussion is not about hardware
On 14.4.2022 14:07, Martin Jackson wrote:
In many industrial and retail use cases, 10 years is the low end. 3-5 years is
an accounting timeline (for depreciation) not necessarily the useful life of
the asset. If the asset can be used after it’s done depreciating that is a
bonus for the company
On 14.4.2022 13:09, Ben Beasley wrote:
For desktop-class hardware, the parts that are most likely to fail
around the decade mark are storage drives, power supplies, and perhaps
fans. All of these are fully standardized and in plentiful supply;
there is no reason that first-party hardware vendor
On 14.4.2022 12:18, JadoNena via devel wrote:
But for here we deal with the real world where budgets require plans and
hardware exists for years.
If you are dealing with the real world with real businesses then you
should be aware of the fact that businesses are usually on a 3 - 5 year
hw r
On 14.4.2022 11:42, Kevin Kofler via devel wrote:
Jóhann B. Guðmundsson wrote:
For example EU has regulation that requires vendors to have spare parts
available for 7–10 years after date of manufacturing so it makes sense
for the project to support hw no longer than a decade from the date of
On 14.4.2022 11:53, Peter Boy wrote:
Am 14.04.2022 um 12:57 schrieb Jóhann B. Guðmundsson :
For example EU has regulation that requires vendors to have spare parts
available for 7–10 years after date of manufacturing so it makes sense for the
project to support hw no longer than a decade
On 14.4.2022 09:17, Tomasz Torcz wrote:
On Thu, Apr 14, 2022 at 10:01:30AM +0200, Ralf Corsépius wrote:
Am 13.04.22 um 20:05 schrieb David Cantrell:
The Legacy BIOS SIG is a good proposal to handle this sort of ongoing work in
Fedora.
I do not agree with this statement. Like previous "Legac
On 14.4.2022 02:23, Demi Marie Obenour wrote:
On 4/13/22 17:11, Jóhann B. Guðmundsson wrote:
On 13.4.2022 08:04, David Bold wrote:
It seems I must be missing something? Why should we not care about a
significant number of our users, just because other OSs have more users?
Could you explain
On 13.4.2022 08:04, David Bold wrote:
It seems I must be missing something? Why should we not care about a
significant number of our users, just because other OSs have more users?
Could you explain that?
First of all this is not significant number of Fedora's users ( or in
the overall deskt
On 12.4.2022 20:44, Mark Otaris wrote:
Your calculations have to be off; I’m pretty sure there are way more than 100
Fedora users with a Nvidia GPU. The Linux Hardware Project alone reports 106 Fedora
users with Nvidia GPUs (which is actually 29% of their sample) so that’s a hard
minimum: http
On 12.4.2022 00:24, Mark Otaris wrote:
However, the majority of Linux PC users *must* step out of the happy path
to get their hardware working for two cases:
* NVIDIA graphics
* Broadcom wireless
In the Firefox Public Data Report, GPU vendor is 69% Intel, 13% Nvidia, 13%
AMD, 5% other. I don’t
I really don't see we have much of a choice here. X11 is eventually going away
and Wayland is the path forward. That's already been decided, so at this point
it isn't a matter for debate. Human nature being what it is, people tend to
procrastinate and not do anything until pressed up against
On 19.10.2020 17:25, Michael Catanzaro wrote:
On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis
wrote:
I'am also have Thikpads and MSI running BIOS and some of those
machines still are the beast in some terms. Dropping BIOS would
pretty much force me to use something else.
I don't want to
. Will try to continue my activity there. I'm not a part of the
ambassadors group though.
--
Dhanesh B. Sabane
https://dhanesh95.gitlab.io
PGP ID: 0xB69A98C9C1642329
Fingerprint: 9655 11F2 0D18 E76A 2396 D64D B69A 98C9 C164 2329
___
devel mailing list --
Hey Michel,
> I'll take python-lupa
>
> Thanks for your work over the years, and hope you at least remain a
> user,
I've provided you admin access for python-lupa. Thank you so much for taking it
up! :)
I'll definitely remain a user and will try to help out with evangelism. I hope
I'll get en
Hey Andy!
> On Mon, 7 Sep 2020 at 07:44, Dhanesh B. Sabane wrote:
>
> If there are no takers, I'd like to maintain the python-blindspinner
> package. I see there is some room to bring in its "click" dependencies.
I've provided you admin access on python-bli
Hey Pruthvi,
> I am looking for packages to maintain and this would help a lot.
>
Do let me know the package that you'd like to maintain and I'll add you as a
co-maintainer for it.
Have a good one!
Cheers!
Dhanesh Sabane
___
devel mailing list -- d
Hello Lumir,
> I'd like to maintain:
>
> python-first
> python-pipdeptree
> python-pipreqs
> python-yarg
>
> These are dependencies of pipenv we (@python-sig) maintain so please add
> me as an admin and this group as co-maintainer.
>
I've added you as admin and @python-sig as committer for th
nesh95/projects
Please let me know if anyone would like to take these up by replying to
this email. I'll orphan all the packages that don't attract a
maintainer till Sunday, 13th Sept 2020.
Cheers!
--
Dhanesh B. Sabane
https://dhanesh95.gitlab.io
PGP ID: 0xB69A98C9C1642329
Fingerprint: 9655
On 6.7.2020 12:07, Tomasz Torcz wrote:
On Mon, Jul 06, 2020 at 01:31:30PM +0200, Gerd Hoffmann wrote:
The BIOS provides block device access at sector level, so the boot
loader has little choice but implementing drivers for all kinds of
stuff. Or use fragile block lists like lilo did in the last
On 6.7.2020 18:39, Javier Martinez Canillas wrote:
On Mon, Jul 6, 2020 at 10:39 AM Jóhann B. Guðmundsson
wrote:
On 5.7.2020 18:34, Javier Martinez Canillas wrote:
On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering wrote:
[snip]
Please submit additions to the spec as PRs to systemd github
On 5.7.2020 19:31, Solomon Peachy wrote:
On Sun, Jul 05, 2020 at 07:18:47PM -, Tom Seewald wrote:
In terms of physical x86 systems, you are right that UEFI is the
overwhelming majority. But as stated elsewhere in this thread, a lot
of cloud providers and virtualization software default to us
On 5.7.2020 18:34, Javier Martinez Canillas wrote:
On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering wrote:
[snip]
Please submit additions to the spec as PRs to systemd github. We added
a number of new keys in the past that sd-boot itself doesn't make use
of (devicetree and such), and we'd be
On 2.7.2020 10:16, nick...@gmail.com wrote:
On Wed, 2020-07-01 at 21:14 -0400, Sam Varshavchik wrote:
Solomon Peachy writes:
Even putting that aside, for the past several years CSM/BIOS has
been
slowly bitrotting due to a lack of real testing, as the last few
Windows
releases have mandated use
On 2.7.2020 01:42, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 9:23 PM Jóhann B. Guðmundsson wrote:
On 2.7.2020 01:06, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson wrote:
On 1.7.2020 23:28, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 7:19 PM Björn Persson wrote
On 2.7.2020 01:06, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson wrote:
On 1.7.2020 23:28, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 7:19 PM Björn Persson wrote:
Jóhann B. Guðmundsson wrote:
More user friendly than Grub ( has lilo like interface easier to change
On 1.7.2020 23:28, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 7:19 PM Björn Persson wrote:
Jóhann B. Guðmundsson wrote:
More user friendly than Grub ( has lilo like interface easier to change
kernel entry, which goes nicely with the default editor change )
This made me go "What?!". I
On 1.7.2020 23:18, Björn Persson wrote:
Jóhann B. Guðmundsson wrote:
More user friendly than Grub ( has lilo like interface easier to change
kernel entry, which goes nicely with the default editor change )
This made me go "What?!". I used Lilo back in the day. Its user
interface w
> On Sun, Jun 28, 2020 at 7:54 PM Gerald B. Cox
> I'm wondering, how do you actually want to define a "production
> release" of a kernel module?
> Does being part of an upstream kernel release (not in staging modules)
> not qualify?
> Because that's already
On 1.7.2020 21:50, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 5:29 PM Jóhann B. Guðmundsson wrote:
On 1.7.2020 21:00, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
wrote:
On 1.7.2020 16:10, Solomon Peachy wrote:
On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto
On 1.7.2020 21:39, Ricky Zhang wrote:
I second your point.
I don't see any upside to discontinue support of legacy BIOS. Even my latest
machine support legacy BIOS. UEFI caused more headache to me than bringing in
any real positive user experiences.
What headache exactly? You had bad user ex
On 1.7.2020 20:31, Ralf Corsepius wrote:
On 6/30/20 3:34 PM, Jóhann B. Guðmundsson wrote:
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream
changes it beg the question if now would not be the time to stop
supporting booting in legacy bios mode and move to uefi only
supported
On 1.7.2020 21:00, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
wrote:
On 1.7.2020 16:10, Solomon Peachy wrote:
On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
I'm currently using BIOS, grub, grub2 basically everywhere, even on
fresh new mac
On 1.7.2020 17:17, Peter Robinson wrote:
The use of legacy or uefi are changes that users have to manually change
themselves in their bios from manufactures default settings. There is no
tool that can do that for them or migrate those settings however users
should be able to change this for hardw
On 1.7.2020 16:10, Solomon Peachy wrote:
On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
I'm currently using BIOS, grub, grub2 basically everywhere, even on
fresh new machines,
This won't be the case for much longer; Intel will finally drop CSM
("BIOS") support this year.
Even
On 1.7.2020 09:36, Lennart Poettering wrote:
On Di, 30.06.20 19:15, Gerd Hoffmann (kra...@redhat.com) wrote:
Hi,
So I can't say I'm thrilled about a future that depends on EFI for
virt, but I'm resigned to the fact this is the direction the world
is taking. So we're not likely to have any
On 30.6.2020 22:38, Kevin Kofler wrote:
Jóhann B. Guðmundsson wrote:
sd-boot is already installed on end users system, is light weight
compared to Grub ( sd-boot only supports uefi,smaller code size, easier
to maintain ).
And that is exactly the problem, systemd-boot has only a small fraction
On 30.6.2020 22:31, nick...@gmail.com wrote:
On Tue, 2020-06-30 at 21:55 +, Jóhann B. Guðmundsson wrote:
On 30.6.2020 21:14, nick...@gmail.com wrote:
On Tue, 2020-06-30 at 20:32 +, Jóhann B. Guðmundsson wrote:
Grub discourages users who have tried sd-boot from
coming/returning
to
On 30.6.2020 21:14, nick...@gmail.com wrote:
On Tue, 2020-06-30 at 20:32 +, Jóhann B. Guðmundsson wrote:
Grub discourages users who have tried sd-boot from coming/returning
to
Fedora [1].
Bottom line I think this will be a good move for the distribution and
a
good time to start looking
On 30.6.2020 19:22, Robbie Harwood wrote:
Jóhann B. Guðmundsson writes:
On 30.6.2020 17:49, John M. Harris Jr wrote:
On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote:
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes
it beg the question if now would
On 30.6.2020 18:32, John M. Harris Jr wrote:
On Tuesday, June 30, 2020 11:29:13 AM MST Jóhann B. Guðmundsson wrote:
On 30.6.2020 17:49, John M. Harris Jr wrote:
On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote:
Given Hans proposal [1] introduced systemd/grub2/Gnome
On 30.6.2020 18:45, Reindl Harald (privat) wrote:
Am 30.06.20 um 20:29 schrieb Jóhann B. Guðmundsson:
On 30.6.2020 17:49, John M. Harris Jr wrote:
On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote:
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes
it
On 30.6.2020 17:49, John M. Harris Jr wrote:
On Tuesday, June 30, 2020 6:34:27 AM MST Jóhann B. Guðmundsson wrote:
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes
it beg the question if now would not be the time to stop supporting
booting in legacy bios mode and move to
On 30.6.2020 17:47, Robbie Harwood wrote:
Jóhann B. Guðmundsson writes:
On 30.6.2020 13:56, Igor Raits wrote:
On Tue, 2020-06-30 at 13:34 +, Jóhann B. Guðmundsson wrote:
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream
changes it beg the question if now would not be the
On 30.6.2020 17:15, Gerd Hoffmann wrote:
Hi,
So I can't say I'm thrilled about a future that depends on EFI for
virt, but I'm resigned to the fact this is the direction the world
is taking. So we're not likely to have any choice and will have to
work to mitigate any downsides it brings.
Rig
On 30.6.2020 14:27, Daniel P. Berrangé wrote:
On Tue, Jun 30, 2020 at 04:00:00PM +0200, Florian Weimer wrote:
* Jóhann B. Guðmundsson:
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream
changes it beg the question if now would not be the time to stop
supporting booting in legacy
On 30.6.2020 14:18, Tom Hughes via devel wrote:
On 30/06/2020 14:56, Igor Raits wrote:
I think there are many people still install OS in the legacy mode, but
I don't really have numbers. One thing we should definitely do if we
deprecate legacy BIOS is to properly warn users that still use this
On 30.6.2020 13:56, Igor Raits wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-30 at 13:34 +, Jóhann B. Guðmundsson wrote:
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream
changes
it beg the question if now would not be the time to stop supporting
ments on how such move might affect you so
feedback can be collected for the future on why such a change might be
bad, how it might affect the distribution and scope of such change can
be determined for potential system wide proposal.
Regards
Jóhann B.
1.
https://fedoraprojec
0 at 3:00 PM Justin Forbes wrote:
> On Sat, Jun 27, 2020 at 5:17 PM Gerald B. Cox wrote:
> >
> >
> >
> > On Sat, Jun 27, 2020 at 2:30 PM Chris Murphy
> wrote:
> >>
> >> On Sat, Jun 27, 2020 at 2:53 PM Gerald B. Cox wrote:
> >>
&g
t;silly you... BTRFS
should only be used in non-critical systems - if you're concerned about
stability you shouldn't be running it."
===> If we are considering BTRFS as a default, at a bare minimum there
should be an official production release from the project.
On Sun, Jun 28,
On Sat, Jun 27, 2020 at 5:04 PM Chris Murphy
wrote:
>
> But if you can state clearly why it isn't persuasive in a way anyone
> could possibly answer, I'm sure someone will try. And it would help
> improve the proposal.
>
Making something the default is a high bar to clear. There needs to be a
c
On Sat, Jun 27, 2020 at 2:30 PM Chris Murphy
wrote:
> On Sat, Jun 27, 2020 at 2:53 PM Gerald B. Cox wrote:
>
> > Why would we be installing something by default that has widely known
> broken functionality?
>
> Because the default configuration we're using isn't
On Sat, Jun 27, 2020 at 2:01 PM Josef Bacik wrote:
> On 6/27/20 4:53 PM, Gerald B. Cox wrote:
> >
> >
> > On Sat, Jun 27, 2020 at 1:23 PM Chris Murphy > <mailto:li...@colorremedies.com>> wrote:
> >
> >
> > The proposal has n
On Sat, Jun 27, 2020 at 1:23 PM Chris Murphy
wrote:
>
> The proposal has nothing to do with raid56, let alone by default. The
> installer doesn't offer it as an option. And it's not relevant to the
> desktop. We're talking about single device btrfs file systems.
>
>
Isn't the proposal talking ab
I was an early adopter and used BTRFS for many years, singing its praises.
I was particularly interested in the RAID capabilities. Then in 2016 the
bomb was dropped that:
"It turns out the RAID5 and RAID6 code for the Btrfs file-system's built-in
RAID support is faulty and users should not be mak
On 16.6.2020 21:44, Solomon Peachy wrote:
"retired" tells you nothing more than "no longer packaged".
"packaged" does not mean "maintained by fedora". It certianly doesn't
mean "kept up to date with upstream releases" or "kept updated with
security fixes"
And "broken" in this context means not
On 16.6.2020 20:22, Gerald Henriksen wrote:
Given the number of cases of evil people getting access to computer
systems, and the fallout of said attacks, any package left on a system
after it no longer is being maintained is not only broken but a
security risk.
Unless the process and the approa
On 16.6.2020 12:21, Kamil Paral wrote:
I'd like Fedora systems to be transparent and honest. If some packages
need to be removed, tell me about it, and ideally also tell me why
(e.g. no longer maintained). If possible, tell me how to avoid it
temporarily (it might be months or years, but unma
If I understand the discussion here:
https://discussion.fedoraproject.org/t/can-the-copr-category-be-removed-from-the-latest-list/2420
Alot of the traffic can be dealt with using the "do not list this category
in latest" function - and there will be an RFE for the "new" category. The
one
thing th
ohn Harris wrote:
> On Sunday, September 1, 2019 6:22:04 AM MST Gerald B. Cox wrote:
> > John you're comparing apples and oranges. One is active the other is
> > passive. One uses your space allocation the other doesn't.
>
> Sorry, what? What space allocation? If
John you're comparing apples and oranges. One is active the other is
passive. One uses your space allocation the other doesn't.
On Sat, Aug 31, 2019, 19:07 John Harris wrote:
> On Friday, August 30, 2019 5:40:22 AM MST Gerald B. Cox wrote:
> > You just explained exactly w
On Thu, Aug 29, 2019 at 6:55 AM Chris Peters wrote:
>
> PS I won't take this thread any further. The irony of a back and forth in
> the back and forth thread doesn't escape me!
>
>
That's hilarious and true. I was thinking the exact same thing...
___
d
You just explained exactly why it was different ;-)
On Wed, Aug 28, 2019 at 9:23 PM John Harris wrote:
> On Wednesday, August 28, 2019 5:09:23 AM MST Gerald B. Cox wrote:
> > It's somewhat ironic that Discourse would solve this issue. As I
> > previously mentioned, I al
I use the gmail android app and on desktop I use the gmail web interface.
On Thu, Aug 29, 2019 at 3:19 PM Przemek Klosowski via devel <
devel@lists.fedoraproject.org> wrote:
> On 8/27/19 8:36 PM, Gerald B. Cox wrote:
> > Regarding NNTP I've haven't used newsreaders
n Thu, Aug 29, 2019 at 12:52 PM Iñaki Ucar wrote:
> On Thu, 29 Aug 2019 at 17:36, Gerald B. Cox wrote:
> >
> > If I do that, I believe I get into a situation where the other builds
> f29, f30 and F32 are behind, which if I remember correctly causes other
> issues - and shoul
Adam Williamson
wrote:
> On Thu, 2019-08-29 at 07:56 -0700, Gerald B. Cox wrote:
> > Guys, I'm still getting this message:
> > fedpkg update
> > Could not execute update: Could not generate update request: Cannot find
> > release associated with build: copyq-3.9.2-1.
Guys, I'm still getting this message:
fedpkg update
Could not execute update: Could not generate update request: Cannot find
release associated with build: copyq-3.9.2-1.fc31, tags: ['f31']
A copy of the filled in template is saved as bodhi.template.last
I just checked bodhi and other packages are
I'm still getting these messages when I try to do "fedpkg update" for F31:
fedpkg update
Could not execute update: Could not generate update request: Cannot find
release associated with build: copyq-3.9.2-1.fc31, tags: ['f31']
A copy of the filled in template is saved as bodhi.template.last
On We
Neal, while you're at it, can you find out what is going on with the RSS
support. There was quite a bit of discussion about it - but that has been
going on for years now and nothing seems to be happening.
On Tue, Aug 27, 2019 at 11:49 AM Neal Gompa wrote:
> On Tue, Aug 27, 2019 at 2:31 PM Emman
On Wed, Aug 28, 2019 at 1:40 AM Kevin Kofler wrote:
> I wrote:
> >> But what about the die-hard NNTP users? You entirely ignored my post to
> >> which you are supposedly replying.
>
> Gerald B. Cox replied:
> > I believe there is a plugin for that with Discourse:
It's somewhat ironic that Discourse would solve this issue. As I
previously mentioned, I also don't like having my inbox flooded with forum
threads that don't interest me. The mailing list solution requires you
setup filters or continuously delete dozens of emails. Discourse however
allows you t
Google John, Google is your friend... ;-)
https://wiki.list.org/DEV/ModernArchiving
On Tue, Aug 27, 2019 at 10:32 PM John Harris wrote:
> On Tuesday, August 27, 2019 6:27:49 PM MST Gerald B. Cox wrote:
> > Don't know what to tell you... it was a planned feature for Mailman 3,
&
Don't know what to tell you... it was a planned feature for Mailman 3, and
it is mentioned here:
https://gitlab.com/mailman/hyperkitty/issues/51
On Tue, Aug 27, 2019 at 10:23 PM John Harris wrote:
> On Tuesday, August 27, 2019 6:20:57 PM MST Gerald B. Cox wrote:
> > Well, th
On Tue, Aug 27, 2019 at 10:20 PM Gerald B. Cox wrote:
> Well, there is an open ticket to do just that - apparently some people
> have a bigger imagination. ;-)
>
> On Tue, Aug 27, 2019 at 10:08 PM John Harris wrote:
>
>> On Tuesday, August 27, 2019 5:43:54 PM MST Gerald B.
Well, there is an open ticket to do just that - apparently some people have
a bigger imagination. ;-)
On Tue, Aug 27, 2019 at 10:08 PM John Harris wrote:
> On Tuesday, August 27, 2019 5:43:54 PM MST Gerald B. Cox wrote:
> > > On Tuesday, August 27, 2019 5:02:36 PM MST Gerald
email within HyperKitty.
On Tue, Aug 27, 2019 at 10:00 PM John Harris wrote:
> On Tuesday, August 27, 2019 5:58:11 PM MST Gerald B. Cox wrote:
> > > On Tuesday, August 27, 2019 5:36:58 PM MST Gerald B. Cox wrote:
> > >
> > > How exactly do your RSS feedreaders handl
> On Tuesday, August 27, 2019 5:36:58 PM MST Gerald B. Cox wrote:
>
> How exactly do your RSS feedreaders handle threading?
Don't you mean how HyperKitty will handle it? I won't be responding from my
Feedreader, I would be reading the contents from the feed, and if I was
int
> On Tuesday, August 27, 2019 5:02:36 PM MST Gerald B. Cox wrote:
>
>
>
> You could also just use NNTP, which wouldn't require you to have anything in
> your mailbox. Then you can reply from the same client, as well :)
Yeah, Kevin mentioned NNTP also... but as I men
> On 8/27/19 11:00 AM, Gerald B. Cox wrote:
>
> Would your concerns be addressed if tjere was a gateway from this email
> list to Discord? Would something simple that just stores each email in a
> separate Discord item work, and if not, why?
>
> BTW, is there a gateway
Hey Kevin:
> Gerald B. Cox wrote:
>
> If the plan is to replace mailing lists with something that cannot even
> provide the same functionality, that is unreasonable and isn't going to
> happen.
>
>
> But you are assuming that we actually WANT to migr
People keep mentioning HyperKitty as an alternative to Discourse. While I
believe Discourse has more functionality, one thing that would make HyperKitty
a somewhat acceptable alternative would be the addition of RSS support. So I
started to investigate and found that several tickets were opene
1 - 100 of 1346 matches
Mail list logo
