date:20241211

Re: flamethrower vs. http-parser

2024-12-11 Thread Petr Menšík

Upstream has switched to cpp-httplib after the latest release, which I 
have packaged. Unfortunately that does not offer any decent parsing of 
URL, which would separate URL text into separate components.


Yes, if http-parser is going to be removed, we may return to bundled 
url_parser. Or we could use libcurl-url(3) for parsing URL. I would have 
expected that would be implemented in every HTTP library, but it does 
not seem so.


Flamethrower uses this only to split URL string into separate 
components. Curl offers that for sure. It is unnecessary big dependency, 
but probably installed even in minimal installation already. 
libcurl-minimal has size under 1MB, which is good enough.


I have pushed change back to bundled url-parser as a first fix. We may 
want to use something small enough. Candidates are:


- uriparser
- ada-url

Some of these might be proposed to upstream, ideally in for of PR.


Dne 10. 12. 24 v 15:33 Stephen Gallagher napsal(a):

On Tue, Dec 10, 2024 at 9:26 AM Petr Špaček wrote:

On 09. 12. 24 15:32, Stephen Gallagher wrote:

On Mon, Dec 9, 2024 at 9:30 AM Stephen Gallagher wrote:

On Sat, Dec 7, 2024 at 12:21 PM Carlos Rodriguez-Fernandez
 wrote:

I took sparse, and http-parser.

http-parser in particular is a dead project upstream. However, there is a good 
set of packages depending on it. There are also past contributors. If any of 
the past contributors want to take it please let me know, I'll be happy to hand 
it over: dck, mrunge, orphan, patches, sgallagh, vascom.


I actually thought I'd removed myself from that package; I've migrated
all of the packages I used to maintain with http-parser over to the
(supported) llhttp package.

The upstream is very dead and it's been strongly implied to me that
there are very likely to be security issues with it. I'd argue that we
need to remove it from the distribution entirely and either fix or
retire the remaining packages depending on it:

* AusweisApp2-0:2.2.1-1.fc41.x86_64
* AusweisApp2-0:2.2.2-2.fc41.x86_64
- Upstream still relies on http-parser and needs to be contacted to
migrate to a maintained parser.

* flamethrower-0:0.11.0-28.fc41.x86_64
- This is actually carrying a Fedora-specific patch to use http-parser
instead of upstream's private fork (called url_parser). Given that
both of them are effectively unmaintained, I think we want to drop our
patch and follow upstream (and contact them about switching to a
maintained parser)

FTR Flamethrower upstream is inactive. Last time I spoke to people who
are in charge of the upstream repo they had no time to maintain it.

If we have a working patch which just needs to be folded upstream that
can be done, I guess, but I would not bet on a proper release with
tarball and all that.

We have a working patch, but it's to let Flamethrower use http-parser,
which is now ALSO unmaintained. So my proposal was that we should just
DROP our patch. If flamethrower is unmaintained anyway, there's no
good reason for us to be carrying an alternate, but also-unmaintained
dep.

Now, if someone wants to do the work to switch it over to llhttp,
that's worth considering.

I can point at two cases where we migrated from http-parser to llhttp
for inspiration:
* libgit2:https://github.com/libgit2/libgit2/pull/6713
* tang:https://github.com/latchset/tang/pull/136 and
https://github.com/latchset/tang/pull/140


I am not sure we want to migrate to llhttp. It contains no documentation 
in current package. CURL has excellent documentation.


The main problem is flamethrower's upstream tries to bundle everything 
needed into the repo. I doubt we want that done with curl too. But if we 
should replace bundled url_parser, I would vote for libcurl. Even though 
it would duplicate already present cpp-httplib parser.



OTOH the tool is useful and the DNS community is using it because it
'mostly works'. Not sure if we want to keep it in Fedora? Opinions?


If we want to keep it in Fedora, we probably need to do the work to
migrate it to a maintained parser.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: flamethrower vs. http-parser

2024-12-11 Thread Vitaly Zaitsev via devel


On 11/12/2024 15:07, Petr Menšík wrote:

Or we could use libcurl-url(3) for parsing URL


Or better https://github.com/ada-url/ada.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Epson inkjet printer drivers orphaned

2024-12-11 Thread Ian Pilcher


On 12/11/24 3:15 AM, Zdenek Dohnal wrote:
If the device supports AirPrint/IPP Everywhere/Mopria/IPP over USB or 
any other driverless standard, the printer works out of the box - or 
that is the intent :) . Then security/setup intentions of vendor, OS and 
user come into the picture - some vendors disable IPP/Airprint/mDNS in 
the printer setup, or OS or user disable mDNS on the machine.. more info 
how to install printer is https://docs.fedoraproject.org/en-US/quick- 
docs/cups-useful-tricks/#_how_to_install_a_print_queue .


My mother's Epson inkjet *claims* to support IPP/Airprint, but it only
accepts an Epson ESC datastream, so I had to install this package to
make it work.

--

If your user interface is intuitive in retrospect ... it isn't intuitive

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Call for the community: Packager Dashboard and bunch of packages

2024-12-11 Thread Frantisek Zatloukal

Thanks a lot Jonathan, I've given you admin rights to all the packages
you've mentioned!

On Thu, Dec 5, 2024 at 6:04 PM Jonathan Wright via devel <
devel@lists.fedoraproject.org> wrote:

> Sorry to see you moving around.  Hope we'll still see you in Fedora land!
>
> I'd be happy to take a few of your packages that are relevant to stacks I
> already maintain:
>
> python-alembic
> python-redis
> python-requests-cache
> python-werkzeug
> spdlog
>
> FAS jonathanspw
>
> On Wed, Dec 4, 2024 at 4:11 PM Frantisek Zatloukal 
> wrote:
>
>> Hi,
>>
>> I'd like to give a heads up through this email. I am transitioning to
>> another team inside Red Hat on January the 1st, and Fedora will no longer
>> be my primary work responsibility. While I am planning on contributing in
>> my free time, I won't be able to dedicate as much time to all the bits I've
>> touched and cared for.
>>
>> First of all - Packager Dashboard (
>> https://packager-dashboard.fedoraproject.org/ ) and its backend. Since
>> these aren't among the primary responsibilities of Fedora QE, jskladan (in
>> CC) will provide a "best effort" maintenance. The backend
>>  is a Python (Flask, Celery,
>> SQLAlchemy, Redis), and provides a REST(ish) API for the React frontend
>> . If you are interested
>> in contributing, contact us, and we can provide more details.
>>
>> As for the packages (*) - they are up for grabs, apart from any of the
>> compute or gaming stuff.
>>
>> Flask, Werkzeug, and Celery suites will be handled by humaton (in CC),
>> but could surely have more than one maintainer. These aren't recommended
>> for beginner packagers, and require at least intermediary Python
>> development and packaging skills.
>>
>> [*] (some of them may have another maintainers, I did only basic
>> filtering)
>> gnome-shell-extension-dash-to-dock
>> gnome-shell-extension-gamemode
>> mozjs115
>> mozjs128 # <<< This adds another mozjsXYZ package every year
>> python-Pallets-Sphinx-Themes
>> python-alembic
>> python-amqp
>> python-aniso8601
>> python-billiard
>> python-celery
>> python-click-didyoumean
>> python-click-repl
>> python-flask
>> python-flask-caching
>> python-flask-cors
>> python-flask-openid
>> python-flask-restx
>> python-flask-session
>> python-flask-sqlalchemy
>> python-httpx
>> python-kombu
>> python-pylibmc
>> python-pytest-click
>> python-pytest-httpx
>> python-pytest-xprocess
>> python-redis
>> python-requests-cache
>> python-respx
>> python-vine
>> python-werkzeug
>> python-wtforms
>> spdlog
>> winetricks
>>
>> --
>>
>> Best regards / S pozdravem,
>>
>> František Zatloukal
>> Senior Quality Engineer
>> Red Hat
>> --
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
>
> --
> Jonathan Wright
> AlmaLinux Foundation
> Mattermost: chat 
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

EDQUOT lurks in most apps

2024-12-11 Thread John Reiser


There's a bug in this program.  Can you spot it?
=
#include 

int
main(int argc, char *argv[])
{
printf("Hello, world!\n");
return 0;
}
=

The bug is that EDQUOT (Disk Quota exceeded: 
/usr/include/asm-generic/errno.h) is not detected.  If a shell 
re-directs stdout into a file,

then the data might never be captured, and the problem would go
undetected until another program tries to read the file,
but does not find the expected data.

It is a very common programming error to omit the call to close() of an
output file, *AND/OR* not to check the return value of close().
["What could possibly go wrong?"  Answer: EDQUOT or ENOSPC.]
Upon exit(), then the Linux kernel implicitly closes all open file
descriptors, but *IGNORES ALL ERRORS* in doing so. It's even documented
on the manpage:  "Failing to check the return value when closing a file
may lead to silent loss of data.  This can especially be observed with
NFS and with disk quota" [or when the output goes into a VM container.]

The app should call close() and check the return value.  Before calling
close(), then a paranoid programmer will call fsync() (and check for
errors) in order to increase the reliability and integrity of data.

The C runtime library (package glibc) implementation of exit()
could help by calling close_range() of low-numbered output
[not input!] file descriptors, especially stdout, and checking
for errors.

The Linux kernel could help by not ignoring errors from close() when
called by exit().  If a signal cannot be delivered because too much
process state has been erased already, then the kernel should log
the first 5 errors per day.



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: EDQUOT lurks in most apps

2024-12-11 Thread Stephen Smoogen

On Wed, 11 Dec 2024 at 11:28, John Reiser  wrote:

> There's a bug in this program.  Can you spot it?
> =
> #include 
>
> int
> main(int argc, char *argv[])
> {
>  printf("Hello, world!\n");
>  return 0;
> }
> =
>
> The bug is that EDQUOT (Disk Quota exceeded:
> /usr/include/asm-generic/errno.h) is not detected.  If a shell
> re-directs stdout into a file,
> then the data might never be captured, and the problem would go
> undetected until another program tries to read the file,
> but does not find the expected data.
>
> It is a very common programming error to omit the call to close() of an
> output file, *AND/OR* not to check the return value of close().
> ["What could possibly go wrong?"  Answer: EDQUOT or ENOSPC.]
> Upon exit(), then the Linux kernel implicitly closes all open file
> descriptors, but *IGNORES ALL ERRORS* in doing so. It's even documented
> on the manpage:  "Failing to check the return value when closing a file
> may lead to silent loss of data.  This can especially be observed with
> NFS and with disk quota" [or when the output goes into a VM container.]
>
> The app should call close() and check the return value.  Before calling
> close(), then a paranoid programmer will call fsync() (and check for
> errors) in order to increase the reliability and integrity of data.
>
>
I have seen this listed as NOT A BUG even with realtime programmers because
the application can be run in all kinds of ways which could induce failures
that are 'environment' versus 'application'. I expect it depends on the
exact environment but what is the correct code? Something like the
following?

===

#include 
#include 

// This would be better with subroutines but this is supposed to be
// hello world.
int main(int argc, char *argv[]){
int err=0;
err=printf("Hello, world!\n");
if (err < 0){ // we got an error somewhere
err=fclose(stdout);
if (err != 0){ // we got a bigger error
return err;
}
err=fclose(stderr);
if (err != 0){ // we got a bigger error
return err;
}
return 1;
} else {
err=fclose(stdout);
if (err != 0){ // we got a bigger error
return err;
}
err=fclose(stderr);
if (err != 0){ // we got a bigger error
return err;
}
return 0;
}
}

===


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: EDQUOT lurks in most apps

2024-12-11 Thread Tulio Magno Quites Machado Filho

Stephen Smoogen  writes:

> I have seen this listed as NOT A BUG even with realtime programmers because
> the application can be run in all kinds of ways which could induce failures
> that are 'environment' versus 'application'. I expect it depends on the
> exact environment but what is the correct code?

AFAIU, it's best to call fsync() before calling close().
The manpage for close() suggests the following [1]:

A careful programmer who wants to know about I/O errors may precede
close() with a call to fsync(2).

It's also worth mentioning that printf() may not be able to catch this
kind of error [2].

[1] 
https://www.mankier.com/2/close#Notes-Dealing_with_error_returns_from_close()
[2] https://www.mankier.com/2/close#Errors-ENOSPC

-- 
Tulio Magno
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Next MUMPS petsc Hypre upgrades

2024-12-11 Thread Antonio T. sagitter


Hi all.

In some days, i will build in Rawhide

PETSc-3.22.2
MUMPS-5.7.3
hypre-2.32.0
sundials-7.1.1

and all related packages.

Regards.
--
---
Antonio Trande
Fedora Project
https://fedoraproject.org/wiki/User:Sagitter
mailto: sagit...@fedoraproject.org
GPG key: 0x40FDA7B70789A9CD
GPG keys server: https://keys.openpgp.org/



OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: EDQUOT lurks in most apps

2024-12-11 Thread Miroslav Suchý


Dne 11. 12. 24 v 5:27 odp. John Reiser napsal(a):

If a shell re-directs stdout into a file,
then the data might never be captured,




Similar problem is when user redirect the output to /dev/null - the output is 
never printed.

Or when user push power button between printf() and return.



--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora CoreOS Community Meeting Minutes 2024-12-11

2024-12-11 Thread Michael Armijo

Minutes:
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-12-11/fedora-coreos-meeting.2024-12-11-16.30.html
Minutes (text):
https://meetbot-raw.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-12-11/fedora-coreos-meeting.2024-12-11-16.30.txt
Log:
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-12-11/fedora-coreos-meeting.2024-12-11-16.30.log.html

=
# #meeting-1:fedoraproject.org: fedora_coreos_meeting
=

Meeting started by @marmijo:fedora.im at 2024-12-11 16:30:16



Meeting summary
---
* TOPIC: roll call (@marmijo:fedora.im, 16:30:20)
* TOPIC: Action items from last meeting (@marmijo:fedora.im, 16:35:04)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1838
(@marmijo:fedora.im, 16:38:38)
* TOPIC: Fedora 42 changes considerations (@marmijo:fedora.im, 16:39:13)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1838
(@marmijo:fedora.im, 16:39:21)
* LINK: https://fedoraproject.org/wiki/Changes/Ansible11 (@marmijo:
fedora.im, 16:40:37)
* TOPIC: Open Floor (@marmijo:fedora.im, 16:41:58)

Meeting ended at 2024-12-11 16:47:54

Action items


People Present (lines said)
---
* @marmijo:fedora.im (25)
* @jlebon:fedora.im (8)
* @zodbot:fedora.im (6)
* @dustymabe:matrix.org (4)
* @meetbot:fedora.im (2)
* @gurssing:matrix.org (1)
* @ydesouza:fedora.im (1)
* @aaradhak:matrix.org (1)
* @hricky:fedora.im (1)
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: HEADS UP: icu 76 coming to rawhide

2024-12-11 Thread Tom Hughes via devel


On 11/12/2024 08:18, Vitaly Zaitsev via devel wrote:

On 05/12/2024 19:22, Pete Walter wrote:

I am in the process of updating icu from 74.2 to 76.1 in rawhide


It looks like there were some API changes in version 76.1.

 From the libkiwix package build log:

In file included from /usr/include/unicode/unistr.h:37,
  from /usr/include/unicode/regex.h:52,
  from ../src/tools/regexTools.cpp:22:
/usr/include/unicode/char16ptr.h:317:10: error: ‘is_convertible_v’ is 
not a member of ‘std’; did you mean ‘is_convertible’?

   317 | std::is_convertible_v
   |  ^~~~
   |  is_convertible
/usr/include/unicode/char16ptr.h:317:28: error: expected primary- 
expression before ‘,’ token

   317 | std::is_convertible_v
   |    ^
/usr/include/unicode/char16ptr.h:331:13: error: ‘u16string_view’ in 
namespace ‘std’ does not name a type; did you mean ‘u16string’?
   331 | inline std::u16string_view toU16StringView(std::u16string_view 
sv) { return sv; }

   | ^~
   | u16string

This comes with a soname bump, but as usual, I'm including a libicu74 
compat package providing the old soname to not break the world while 
the rebuilds are in progress, so no rawhide breakage is expected.


Is it possible to use this libicu74 compatibility package until the 
upstream fixes this issue? How long do you plan to keep it in Fedora?


Likely there is just a #include  missing - it was probably
being included by accident before as a side effect of something else.

The other option is that you're not in C++17 mode and that is now
required if std::is_convertible_v is used.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Epson inkjet printer drivers orphaned

2024-12-11 Thread Zdenek Dohnal


On 12/10/24 20:04, Mateus Rodrigues Costa wrote:

I am a user of epson-inkjet-printer-escpr, my question is if, when
CUPS drops driver support for driver in the near future in favor of
IPP, what will happen to Epson printer driver.


If your device really needs the classic driver from 
epson-inkjet-printer-escpr, you can install the printer via 
legacy-printer-app, which is a printer application providing IPP 
interface for classic drivers which are not covered by any other printer 
applications. However if the device is not pretty old bought from bazaar 
or the cheapest model from a vendor (recently I found out Brother sells 
in one country the cheapest model without any IPP Everywhere/AirPrint 
support - in 2024...), you might not need it.


As I report here every year, printers which can't be used via IPP 
(either via ethernet, wifi or USB - yes, IPP can work over USB if the 
device has a dedicated USB interface 7/1/4) uses a printer application 
as a middleware for CUPS to see it.



Also, would it be possible to use Epson printers on Linux without
these two packages as of today?


If the device supports AirPrint/IPP Everywhere/Mopria/IPP over USB or 
any other driverless standard, the printer works out of the box - or 
that is the intent :) . Then security/setup intentions of vendor, OS and 
user come into the picture - some vendors disable IPP/Airprint/mDNS in 
the printer setup, or OS or user disable mDNS on the machine.. more info 
how to install printer is 
https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_install_a_print_queue 
.


As others mentioned, there are Epson models already working without the 
package, so at least some models might support driverless.



Zdenek

--
Zdenek Dohnal
Senior Software Engineer
Red Hat, BRQ-TPBC

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Syntax highlighting with tree-sitter-rpmspec

2024-12-11 Thread Andreas Schneider

Hi,

I'm working on tree-sitter-rpmspec [1] for syntax highlighting using tree-
sitter e.g. in neovim. In the meantime it is working quite well. I don't cover 
100% of the spec file specification yet and there are still issues with macros 
(especially macro nesting). I'm slowly getting there.

Below is a screenshot which shows the current state. Left is tree-sitter-
rpmspec and right is the vim-regex highlighting.

https://xor.cryptomilk.org/neovim/syntax-highlight-neovim.png

Try it out, give feedback or create MRs in case you want to contribute code.

Neovim:
https://github.com/nvim-treesitter/nvim-treesitter?tab=readme-ov-file#adding-parsers


Best regards


Andreas


[1] https://gitlab.com/cryptomilk/tree-sitter-rpmspec


-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: HEADS UP: icu 76 coming to rawhide

2024-12-11 Thread Vitaly Zaitsev via devel


On 11/12/2024 09:23, Tom Hughes wrote:

ikely there is just a #include  missing - it was probably
being included by accident before as a side effect of something else.


Yes, /usr/include/unicode/char16ptr.h (line 317[1]) explicitly uses 
std::is_convertible_v but doesn't have #include  in this 
public header. I think it's a bug in icu.


[1]: 
https://github.com/unicode-org/icu/blob/main/icu4c/source/common/unicode/char16ptr.h#L317


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: HEADS UP: icu 76 coming to rawhide

2024-12-11 Thread Vitaly Zaitsev via devel


On 05/12/2024 19:22, Pete Walter wrote:

I am in the process of updating icu from 74.2 to 76.1 in rawhide


It looks like there were some API changes in version 76.1.

From the libkiwix package build log:

In file included from /usr/include/unicode/unistr.h:37,
 from /usr/include/unicode/regex.h:52,
 from ../src/tools/regexTools.cpp:22:
/usr/include/unicode/char16ptr.h:317:10: error: ‘is_convertible_v’ is 
not a member of ‘std’; did you mean ‘is_convertible’?

  317 | std::is_convertible_v
  |  ^~~~
  |  is_convertible
/usr/include/unicode/char16ptr.h:317:28: error: expected 
primary-expression before ‘,’ token

  317 | std::is_convertible_v
  |^
/usr/include/unicode/char16ptr.h:331:13: error: ‘u16string_view’ in 
namespace ‘std’ does not name a type; did you mean ‘u16string’?
  331 | inline std::u16string_view toU16StringView(std::u16string_view 
sv) { return sv; }

  | ^~
  | u16string


This comes with a soname bump, but as usual, I'm including a libicu74 compat 
package providing the old soname to not break the world while the rebuilds are 
in progress, so no rawhide breakage is expected.


Is it possible to use this libicu74 compatibility package until the 
upstream fixes this issue? How long do you plan to keep it in Fedora?


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora eln compose report: 20241212.n.0 changes

2024-12-11 Thread Fedora ELN Report

OLD: Fedora-eln-20241211.n.0
NEW: Fedora-eln-20241212.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  2
Dropped packages:4
Upgraded packages:   15
Downgraded packages: 0

Size of added packages:  13.46 MiB
Size of dropped packages:8.47 MiB
Size of upgraded packages:   5.16 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -22.83 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: gtk2-2.24.33-19.eln144
Summary: GTK+ graphical user interface library
RPMs:gtk2
Size:12.96 MiB

Package: leafpad-0.8.19-44.eln144
Summary: GTK+ based simple text editor
RPMs:leafpad
Size:511.28 KiB


= DROPPED PACKAGES =
Package: libXp-1.0.4-7.eln144
Summary: X.Org X11 libXp runtime library
RPMs:libXp
Size:132.09 KiB

Package: motif-2.3.4-35.eln144
Summary: Run-time libraries and programs
RPMs:motif
Size:5.95 MiB

Package: nedit-5.7-18.eln144
Summary: A GUI text editor for systems with X
RPMs:nedit
Size:2.34 MiB

Package: xorg-x11-xbitmaps-1.1.3-3.eln144
Summary: X.Org X11 application bitmaps
RPMs:xorg-x11-xbitmaps
Size:48.61 KiB


= UPGRADED PACKAGES =
Package:  annobin-12.79-1.eln144
Old package:  annobin-12.77-1.eln144
Summary:  Annotate and examine compiled binary files
RPMs: annobin-annocheck annobin-docs annobin-libannocheck 
annobin-plugin-clang annobin-plugin-gcc annobin-plugin-llvm
Size: 5.39 MiB
Size change:  -51.33 KiB
Changelog:
  * Mon Dec 09 2024 Nick Clifton   - 12.78-1
  - GCC Plugin: Fix building with gcc 15.  (#32429)

  * Tue Dec 10 2024 Nick Clifton   - 12.79-1
  - GCC Plugin: Tidy up use of gcc's diagnoatic headers.  (#32429)
  - Testsuite: Use configured compiler when running tests.


Package:  cinnamon-6.4.2-2.eln144
Old package:  cinnamon-6.4.2-1.eln144
Summary:  Window management and application launching for GNOME
RPMs: cinnamon
Size: 7.67 MiB
Size change:  13.08 KiB
Changelog:
  * Wed Dec 11 2024 Leigh Scott  - 6.4.2-2
  - Add a nightlight applet to ease disabling


Package:  cockpit-composer-53-1.eln144
Old package:  cockpit-composer-52-1.eln144
Summary:  Composer GUI for use with Cockpit
RPMs: cockpit-composer
Size: 1.99 MiB
Size change:  -649 B
Changelog:
  * Wed Dec 11 2024 Packit  - 53-1
  - bump testlib
  - translations update


Package:  cronie-1.7.2-3.eln144
Old package:  cronie-1.7.2-2.eln144
Summary:  Cron daemon for executing programs at set times
RPMs: cronie cronie-anacron cronie-noanacron
Size: 630.33 KiB
Size change:  -23.78 KiB
Changelog:
  * Mon Dec 09 2024 Ond??ej Poho??elsk??  - 1.7.2-3
  - Create anacron timestamp files with correct permissions


Package:  dotnet8.0-8.0.111-2.eln144
Old package:  dotnet8.0-8.0.108-2.eln143
Summary:  .NET Runtime and SDK
RPMs: aspnetcore-runtime-8.0 aspnetcore-runtime-dbg-8.0 
aspnetcore-targeting-pack-8.0 dotnet-apphost-pack-8.0 dotnet-hostfxr-8.0 
dotnet-runtime-8.0 dotnet-runtime-dbg-8.0 dotnet-sdk-8.0 
dotnet-sdk-8.0-source-built-artifacts dotnet-sdk-dbg-8.0 
dotnet-targeting-pack-8.0 dotnet-templates-8.0
Size: 2.74 GiB
Size change:  -27.54 MiB
Changelog:
  * Fri Oct 11 2024 Omair Majid  - 8.0.110-1
  - Update to .NET SDK 8.0.110 and Runtime 8.0.10

  * Mon Nov 18 2024 Omair Majid  - 8.0.111-1
  - Update to .NET SDK 8.0.111 and Runtime 8.0.11

  * Tue Dec 10 2024 Omair Majid  - 8.0.111-2
  - Fix ELN build
  - Resolves: RHBZ#2321109


Package:  firefox-133.0.3-1.eln144
Old package:  firefox-133.0-2.eln144
Summary:  Mozilla Firefox Web browser
RPMs: firefox
Size: 271.52 MiB
Size change:  -12.90 KiB
Changelog:
  * Wed Dec 11 2024 Martin Stransky  - 133.0.3-1
  - Updated to 133.0.3


Package:  gnome-settings-daemon-47.2-2.eln144
Old package:  gnome-settings-daemon-47.1-1.eln144
Summary:  The daemon sharing settings from GNOME to GTK+/KDE applications
RPMs: gnome-settings-daemon
Size: 4.21 MiB
Size change:  -148.76 KiB
Changelog:
  * Wed Dec 11 2024 David King  - 47.2-1
  - Update to 47.2

  * Wed Dec 11 2024 David King  - 47.2-2
  - Update to 47.2


Package:  ibus-table-1.17.9-1.eln144
Old package:  ibus-table-1.17.8-1.eln144
Summary:  The Table engine for IBus platform
RPMs: ibus-table
Size: 1.20 MiB
Size change:  1.21 KiB
Changelog:
  * Wed Dec 11 2024 Mike FABIAN  - 1.17.9-1
  - Update to 1.17.9
  - Make the setup tool use the wrapper itb_sound.py instead of using
simpleaudio unconditionally (Resolves: github-mike-fabian-issue#162)
  - Translation update from Weblate (new language Kabyle: kab 29.3%)


Package:  json-glib-1.10.6-1.eln144
Old package:  json-glib-1.10.0-1.eln144
Summary:  Library for JavaScript Object Notation format
RPMs: json-glib json-glib-devel
Size: 1.53 MiB
Size change:  11.58 KiB
Chan

Re: EDQUOT lurks in most apps

2024-12-11 Thread Florian Weimer

* John Reiser:

> The C runtime library (package glibc) implementation of exit()
> could help by calling close_range() of low-numbered output
> [not input!] file descriptors, especially stdout, and checking
> for errors.

ENOSPC also has this problem.

We would have to fsync (after the implicit fflush), to make sure that
storage actually gets allocated, and that does not meet performance
expectations of users.  The kernel does not offer a mechanism that
detects ENOSPC errors, but does not force the contents to disk.  Closing
a file descriptor is an approximation for some cases because it triggers
non-flushing allocation, but it's tricky to use because it has
unintended side effects for old-style POSIX file locks.

There is some code in gnulib that closes the standard descriptors, but
this is the wrong thing to do from the application side because it can
lead to use-after-free problems.  Applications should just call fflush
and fsync.

Thanks,
Florian

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: flamethrower vs. http-parser

Re: flamethrower vs. http-parser

Re: Epson inkjet printer drivers orphaned

Re: Call for the community: Packager Dashboard and bunch of packages

EDQUOT lurks in most apps

Re: EDQUOT lurks in most apps

Re: EDQUOT lurks in most apps

Next MUMPS petsc Hypre upgrades

Re: EDQUOT lurks in most apps

Fedora CoreOS Community Meeting Minutes 2024-12-11

Re: HEADS UP: icu 76 coming to rawhide

Re: Epson inkjet printer drivers orphaned

Syntax highlighting with tree-sitter-rpmspec

Re: HEADS UP: icu 76 coming to rawhide

Re: HEADS UP: icu 76 coming to rawhide

Fedora eln compose report: 20241212.n.0 changes

Re: EDQUOT lurks in most apps

17 matches

Site Navigation

Mail list logo

Footer information