Re: Is this true ?

[DJ Delorie]

Lee Thomas Stephen  writes:
> With Great Power comes great responsibility (Spiderman movie)

Wasn't the original quote "With great power there must also come great
responsibility" ?

The shorter version implies the responsibility is part of the power, but
the longer version creates an onus to provide the responsibility
yourself.

> I wonder whether the current generation of Redhatters knows the power
> that they wield.

Yes, which is why we believe in free software and open source.  We want
others to have that power for themselves, too.
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: goal: booting with an empty /etc

[DJ Delorie]

Lennart Poettering  writes:
> Well, as you might be aware many distributions these days do more than
> "files dns" for "hosts", and similar for the other databases, and
> hence a built-in default in glibc is great, but most distributions and
> image builders probably want to pick different defaults without having
> to patch glibc for this.

I agree.  My point was that (1) glibc has a built-in default, and (2)
most distros/users/installers customize it anyway, so storing a
"default" version anywhere other than /etc is not needed.
--
___
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: goal: booting with an empty /etc

[DJ Delorie]

Zbigniew Jędrzejewski-Szmek  writes:
> I'm not entirely sure if you're just doing Friday trolling or if
> you're serious.

Serious.  I have many machines and VMs, and every time I do a Fedora
install, I have a list of your choices I have to revert because they
don't work for me.  It's tiring.

>> I fear this will end like the /tmp fiasco where one /tmp became many tmp
>> directories, and no consistent rule about which one to use.
>
> /tmp is generally backed by RAM and does not survive a reboot.

Not on any of my machines.  I want tmp files around after a reboot so I
can figure out what caused the reboot.

>> This can be achieved without "empty /etc" as a goal.  For example, why
>> can't we use podman's overlay filesystem to mount /usr/etc under /etc so
>> that all the configuration appears in /etc but installed vs changed
>> files are kept segregatable?
>
> (FTR, not "podman's". The filesystem is a kernel thing.)
>
> If the goal was to just move everything wholesale, that'd be a

I meant, rpms install into the lower fs, and the user edits the upper
fs.  You can "revert" to "factory settings" by wiping just the upper fs.

You can expose the two layers elsewhere (like /usr/etc) if that helps
with the merging.

> (Another problem is that this scheme only works "live". If you want
> to look *into* an image from the outside, the overlay wouldn't be
> assembled, so the tools need to know how to handle the config split
> manually.)

If you get your way, /etc would be empty anyway ;-)

>> > For example, /etc/services is a list of port:service mappings, and people
>> > maybe used to edit that twenty years ago,
>> 
>> I still edit this one.
>
> Great for you. So you can be the one person who uses the override
> mechanism for this file.

That you assume I'm the only one is part of the problem.

>> > Another common case is "empty" configuration files, i.e. templates
>> > that show the default configuration.
>> 
>> I find these VERY helpful when trying to fix configuration issues on my
>> machines.
>
> Right. I'm not saying that those should go away. Quite the opposite.

If you move them away from where I expect to find them, effectively
they've gone away.  Instead of having everything I need in the one spot,
I have to go hunting for it.  If history is right, everyone will choose
a different spot and finding info will become very difficult.  Even
*documenting* where to find this information will become difficult,
because everyone puts their docs in different places.

Please figure out a way to make upgrades more reliable without having to
retrain millions of Linux users or turn Fedora into Windows.  I'm not
sure I'm exaggerating here.
--
___
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: goal: booting with an empty /etc

[DJ Delorie]

Zbigniew Jędrzejewski-Szmek  writes:
> That built-in would be enough only if it enabled all the modules
> that we need it to support.

It enables the ones that *glibc* needs to run at a minimum.  Your case
is different, which is why you modify /etc/nsswitch.conf.

> I tried to figure out what the default is, but could find that info.
> Is is documented somewhere?

Yes.  It's in the glibc manual, section "Notes on the NSS Configuration
File".  It boils down to either "files dns" or "files" for most entries.
--
___
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: goal: booting with an empty /etc

[DJ Delorie]

Lennart Poettering  writes:
> That said, I would certainly enjoy more if glibc would natively
> fallback to /usr/lib/glibc/nsswitch.conf or something like that if
> /etc/nsswitch.conf does not exist.

glibc has an internal default for nsswitch.conf if one isn't found.
Putting a custom nsswitch.conf in yet another non-standard directory is
not needed.
--
___
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: goal: booting with an empty /etc

[DJ Delorie]

Zbigniew Jędrzejewski-Szmek  writes:
> There is a long-term goal of moving packaged files out of /etc,

I will note that I'm opposed to this goal as a goal per-se.

If you want an empty directory, "mkdir /etc2" should work for you.

I fear this will end like the /tmp fiasco where one /tmp became many tmp
directories, and no consistent rule about which one to use.

> so that only actual local configuration remains in /etc.

This can be achieved without "empty /etc" as a goal.  For example, why
can't we use podman's overlay filesystem to mount /usr/etc under /etc so
that all the configuration appears in /etc but installed vs changed
files are kept segregatable?

> For example, /etc/services is a list of port:service mappings, and people
> maybe used to edit that twenty years ago,

I still edit this one.

> The same is also true for /etc/bash_completion.d/

I delete this package completely, so I don't care where its config goes.

> Another common case is "empty" configuration files, i.e. templates
> that show the default configuration.

I find these VERY helpful when trying to fix configuration issues on my
machines.

> Other distributions are ahead of us in supporting empty /etc.

"Be like everyone else" is not one of our goals.

> If you are a maintainer of a package with files in /etc, please consider
> whether they are strictly necessary, and if possible, move stuff to /usr.

Unless such file could be changed by a user, in which case it belongs in
/etc.

> At some point, I think we should make this an explicit goal in Fedora.

Please don't.
--
___
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: strub causing libgcc to fail to build on rl78-elf

[DJ Delorie via Gcc]

Alexandre Oliva  writes:
> This looks like a latent bug in the port.

I'm not surprised, that port was weird.

> This was just a plain asm insn in strub.c:
>
>   /* Make sure the stack overwrites are not optimized away.  */
>   asm ("" : : "m" (end[0]));
>
> whose constraint passes during reload, rl78_alloc_physical_registers
> leaves it alone and clears virt_insns_ok, so when cprog_hardreg attempts
> to extract constraints again, rl78_as_legitimate_address rejects r8 as
> the address because virt insns are no longer ok.

Some background: the "virtual" registers are memory-mapped registers
that use a common addressing scheme to access non-mapped registers.
When we convert from virtual to physical, we can map that reg to a
physical reg, or we replace the reg with a mem, but then usually have to
split up the insn.

For this insn, "converting" should have mapped or reloaded r8 to a valid
address register.  I doubt we have a way to have two patterns for user
asms like we do for, say, addhi3.

I suspect that something in the virt->phys logic just doesn't know how
to check for mem constraints in user asms.

> I'm not at all familiar with this port, and I don't know what was
> supposed to happen here, but ISTM that either physical registers should
> be allocated for asms, or non-B0 regs should be accepted in asms.

non-bank-zero registers aren't valid as real address registers, because
in gcc's reality they *are* mems.  The chip can bank switch them, but
gcc doesn't (the interrupt handlers, being asm, can do so, which is why
one bank is reserved for that).

Re: Free Software and the New Sexism

[DJ Delorie]

"Alfred M. Szmidt"  writes:
> Free software as such cannot be sexist, but that you do not wish to
> partake in communities where who you are is imaterial, to the point
> where you do not wish to spread the message that computer rights
> matters is sad.  Hopefully you will reconsider, and fight for both
> your right and other peoples rights to use a computer -- irrespective
> of what other values or opinions you hold.

I'm going to agree with Alfred on this one.  Free Software is about
making software free for *everyone*, and that includes all the "evil"
people in the world.  FS is not about making you friends.

Re: Update on DNF05 in Fedora

[DJ Delorie]

Samantha Bueno  writes:
> We've gone ahead and decided not to replace DNF with DNF05 in Fedora
> 39 and, perhaps notably, Fedora 40 as well.

For those of us who upgraded to DNF05 in rawhide to test it, is there a
quick reference for our paths forward?  Er, backward?  I upgraded at the
wrong time and spent half a day recovering my system, I'd rather avoid
that if I have to go back to DNF04...
___
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: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[DJ Delorie]

Fabio Valentini  writes:
> in Fedora 39 - whether the switch still looks doable for this release,
> or whether it should be reverted for F39 and postponed to F40.

I spent most of yesterday repairing a rawhide VM that had a bad upgrade,
resulting in dnf segfaulting and making the machine difficult to fix.
Had to build a second rawhide VM as a baseline to guide a manual
download and install of affected RPMs.  Very not happy, and I would
advise more testing before making it official.

#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-sse2.S:142
Downloading 0.00 MB source file 
/usr/src/debug/glibc-2.37.9000-16.fc39.x86_64/string/../sysdeps/x86_64/multiarch/strlen-sse2.S
142 movdqu  (%rax), %xmm4
(gdb) where
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-sse2.S:142
#1  0x7fc9d36614e8 in __printf_buffer (buf=buf@entry=0x7ffe8ca81350, 
format=0x7fc9c5160293 "%s: %s: %s\n", ap=0x7ffe8ca81460, mode_flags=2) at 
/usr/src/debug/glibc-2.37.9000-16.fc39.x86_64/stdio-common/vfprintf-process-arg.c:435
#2  0x7fc9d3682106 in __vsnprintf_internal (string=string@entry=0x0, 
maxlen=maxlen@entry=0, format=format@entry=0x7fc9c5160293 "%s: %s: %s\n", 
args=args@entry=0x7ffe8ca81460, mode_flags=mode_flags@entry=2) at vsnprintf.c:96
#3  0x7fc9d3724922 in ___vsnprintf_chk (s=s@entry=0x0, 
maxlen=maxlen@entry=0, flag=flag@entry=2, slen=slen@entry=18446744073709551615, 
format=format@entry=0x7fc9c5160293 "%s: %s: %s\n", ap=ap@entry=0x7ffe8ca81460) 
at vsnprintf_chk.c:34
#4  0x7fc9c50d66ae in vsnprintf (__ap=0x7ffe8ca81460, __fmt=0x7fc9c5160293 
"%s: %s: %s\n", __n=0, __s=0x0) at /usr/include/bits/stdio2.h:68
#5  rpmlog (code=4, fmt=0x7fc9c5160293 "%s: %s: %s\n") at 
/usr/src/debug/rpm-4.18.0-11.fc39.x86_64/rpmio/rpmlog.c:446
#6  0x7fc9c4f811b1 in renderLogMsg (iErrCode=283, zFormat=, 
ap=ap@entry=0x7ffe8ca816a0) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:31531
#7  0x7fc9c4f81294 in sqlite3_log (iErrCode=, 
zFormat=) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:31542
#8  0x7fc9c4f91887 in walIndexRecover (pWal=0x563fa87849c8) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:64936
#9  walIndexReadHdr (pWal=pWal@entry=0x563fa87849c8, 
pChanged=pChanged@entry=0x7ffe8ca8195c) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:422
#10 0x7fc9c4f91edb in walTryBeginRead (pWal=pWal@entry=0x563fa87849c8, 
pChanged=pChanged@entry=0x7ffe8ca8195c, useWal=useWal@entry=0, cnt=cnt@entry=1) 
at /usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:66260
#11 0x7fc9c4f931cc in sqlite3WalBeginReadTransaction 
(pChanged=0x7ffe8ca8195c, pWal=0x563fa87849c8) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:66554
#12 pagerBeginReadTransaction (pPager=0x563fa8b75098) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:58955
#13 sqlite3PagerSharedLock (pPager=0x563fa8b75098) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:61124
#14 0x7fc9c4f98ef8 in lockBtree (pBt=0x563fa893ab28) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:71967
#15 sqlite3BtreeBeginTrans (p=0x563fa88f5b88, wrflag=0, pSchemaVersion=0x0) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:6823
#16 0x7fc9c4ff410a in sqlite3InitOne (db=0x563fa88f5d18, iDb=iDb@entry=0, 
pzErrMsg=pzErrMsg@entry=0x7ffe8ca82878, mFlags=mFlags@entry=0) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:138178
#17 0x7fc9c4ff487c in sqlite3Init (db=db@entry=0x563fa88f5d18, 
pzErrMsg=pzErrMsg@entry=0x7ffe8ca82878) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:138372
#18 0x7fc9c4ff48cf in sqlite3ReadSchema (pParse=0x7ffe8ca82870) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:138398
#19 0x7fc9c4feca53 in sqlite3Pragma (pParse=0x7ffe8ca82870, pId1=, pId2=0x7ffe8ca81ee0, pValue=, minusFlag=) 
at /usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:135486
#20 0x7fc9c5086335 in yy_reduce.isra.0 (yypParser=0x7ffe8ca81e80, 
yyruleno=250, yyLookaheadToken=..., pParse=0x7ffe8ca82870, 
yyLookahead=) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:172382
#21 0x7fc9c501fd2d in sqlite3Parser (yyminor=, 
yymajor=, yyp=0x7ffe8ca81e80) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:173016
#22 sqlite3RunParser (pParse=, zSql=) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:43244
#23 0x7fc9c4ff3895 in sqlite3Prepare (db=db@entry=0x563fa88f5d18, 
zSql=zSql@entry=0x7fc9c5715eae "PRAGMA journal_mode = WAL; PRAGMA foreign_keys 
= ON;", nBytes=nBytes@entry=-1, prepFlags=prepFlags@entry=128, 
pReprepare=pReprepare@entry=0x0, ppStmt=ppStmt@entry=0x7ffe8ca82b38, 
pzTail=0x7ffe8ca82b40)
at /usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:138700
#24 0x7fc9c4ff49f0 in sqlite3LockAndPrepare (pzTail=0x7ffe8ca82b40, 
ppStmt=0x7ffe8ca82b38, pOld=0x0, prepFlags=128, nBytes=-1, zSql=0x7fc9c5715eae 
"PRAGMA journal_mode = WAL; PRAGMA foreign_keys = ON;", db=0x563fa88f5d18) at 

Re: F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)

[DJ Delorie]

Jens-Ulrik Petersen  writes:
> I have just now pushed fixes for all ghc*, so can you try to rebuild
> them again in your repo?

All succeeded :-)

https://copr.fedorainfracloud.org/coprs/djdelorie/libffi-3.4.4/builds/
___
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: F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)

[DJ Delorie]

Jens-Ulrik Petersen  writes:
> I have just now pushed fixes for all ghc*, so can you try to rebuild
> them again in your repo?

That's a good question, to which I know not the answer.  Fred?  Can MPB
be told to retest a specific set of packages?  Or do I have to start
from scratch and/or do them manually?
___
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: F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)

[DJ Delorie]

Jarek Prokop  writes:
> Are the libffi/rebuilt packages available anywhere for us to
> experiment with?

MPB uses COPR, so..

"before" builds: 
https://copr.fedorainfracloud.org/coprs/djdelorie/libffi-3.4.4.checker/
"after" builds:  https://copr.fedorainfracloud.org/coprs/djdelorie/libffi-3.4.4/

> We have a reasonably reliable reproducer in Ruby [0] (also included in
> commit message [1]), but it is not executed as part of test suite,

Yes, fork-without-exec case is a known "that should never have worked"
case that only happens to work when your closure's backing store is also
forked, which file-based mappings are *not*.  You need either really old
(rwx mmap, which security disables) or really new (static trampolines,
which are r-x/rw- mmap'ed) libffi to support that.  Hopefully that means
your reproducers should not reproduce with the new libffi.

> Moreover, rebuild with current Ruby specfiles won't tell you much as
> we commented out the tests [2] to have less flaky builds. I'd
> recommend uncommenting the lines and run 5 to 10 builds (or just run
> any of the 2 reproducers).

Well, if you comment out the tests, I have no way of knowing I broke
anything, so have to rely on posting Change Requests and letting you let
me know ;-)

Not saying you did anything wrong; if you have tests that pass or fail
depending on system configurations outside your control, it's difficult
to reliably test what you want to test.  I'm just saying that when you
disable tests, automated processes have no insight into those failures.
___
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: F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)

[DJ Delorie]

Jens-Ulrik Petersen  writes:
>  According to mpb at least:
>
> mpb?

Mass PreBuilder https://gitlab.com/fedora/packager-tools/mass-prebuild

> The majority of those packages are maintained by me... so I can't say I 
> thrilled.
> I thought ghc 9 was supposed to be okay with static trampolines?

MPB uses BuildRequires to collect all packages that *might* be affected
by your change.  It builds all those packages with and without your
change, and lets you know what you broke.  In this case, one broke (cjs,
since fixed), ten didn't build before my change anyway[*], and the rest
were OK.  So if your package doesn't already FTBFS, you're good.

> Are the results available?

MPB uses COPR, so..

"before" builds: 
https://copr.fedorainfracloud.org/coprs/djdelorie/libffi-3.4.4.checker/
"after" builds:  https://copr.fedorainfracloud.org/coprs/djdelorie/libffi-3.4.4/

Note: I've done this before, so only look at the builds that are less
than a month old.  There should be an "after" build for all packages
that BuildRequires libffi, and a "before" package for each package that
failed to build "after".

[*] I'm still investigating these, but usually, it's not related to the
change you're making.
___
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: F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)

[DJ Delorie]

Zbigniew Jędrzejewski-Szmek  writes:
> Sounds good. Can you post the list of affected packages here?

According to mpb at least:

0ad 
Agda 
Io-language 
Macaulay2 
ShellCheck 
alex 
bench 
brainfuck 
bustle 
cab 
cabal-install 
cabal-rpm 
chromium 
cjs 
cpphs 
darcs 
dhall 
dhall-json 
dl-fedora 
ecl 
fbrnch 
firefox 
gambas3 
gforth 
ghc 
ghc-DAV 
ghc-HaXml 
ghc-aeson-pretty 
ghc-cheapskate 
ghc-clientsession 
ghc-criterion 
ghc-doctest 
ghc-hakyll 
ghc-hgettext 
ghc-highlighting-kate 
ghc-hjsmin 
ghc-hspec-discover 
ghc-pretty-show 
ghc-pretty-simple 
ghc-servant-server 
ghc-tidal 
ghc-vty 
ghc-wai-app-static 
ghc-wai-websockets 
ghc9.0 
ghc9.2 
ghc9.4 
ghc9.6 
ghcid 
git-annex 
git-repair 
gitit 
gjs 
glib2 
gnustep-base 
gobject-introspection 
gtk2hs-buildtools 
guile 
guile22 
guile30 
hadolint 
happy 
haskell-platform 
hedgewars 
hledger 
hledger-ui 
hledger-web 
hlint 
hscolour 
hwk 
icecat 
idris 
ispc 
jna 
koji-tool 
libffi 
libomp 
librep 
lldb 
llvm 
llvm11 
llvm12 
llvm13 
llvm14 
llvm15 
llvm7.0 
llvm8.0 
lsfrom 
lua-lgi 
micropython 
moarvm 
mozjs102 
mozjs78 
mozjs91 
newlisp 
ocaml-ctypes 
ormolu 
p11-kit 
pagure-cli 
pandoc 
patat 
perl-Alien-FFI 
perl-FFI-Platypus 
perl-Glib-Object-Introspection 
php 
pkgtreediff 
polyml 
pygobject2 
pygobject3 
pypy 
pypy3.9 
python-cffi 
python-pyopencl 
python-tox 
python2.7 
python3.10 
python3.11 
python3.12 
python3.6 
python3.7 
python3.8 
python3.9 
qt-creator 
racket 
rakudo 
rhbzquery 
rocm-runtime 
rpmbuild-order 
ruby 
rubygem-ffi 
seamonkey 
shake 
squeak-vm 
thunderbird 
unlambda 
wayland 
xmobar 
xmonad 
yosys 
___
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

[rpms/perl-Crypt-DES] PR #1: Fix C99 compatibility issue

[DJ Delorie]

djdelorie opened a new pull-request against the project: `perl-Crypt-DES` that 
you are following:
``
Fix C99 compatibility issue
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Crypt-DES/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Thoughts welcome: interface between automated test gating and the "critical path"

[DJ Delorie]

It sounds to me like the problem is "how do we best use the available
automated test resources?" so I'll answer accordingly.  Ignore me if I
misunderstood ;-)

We currently have a small list of packages that are gated behind openQA,
and insufficient openQA resources to expand this list to all packages.

We also have a gating system based on karma, where users provide the QA
manually.  At least, one hopes.  The karma system has some
configurability for how much karma is needed, and for how long, etc.

What about a merger of those systems, where the openQA results count as
a type of user, contributing to the status?  Give each package a "QA
Priority" that ranges from "full gating" to "five second rule", where
the openQA resources and the user work together to prioritize and test
packages according to need:

* full gating requires all openQA tests to pass AND meet karma
  requirements, openQA does these first.

* partial gating is like above, but either one (openQA or karma) can be
  sufficient if enough time passes.

* reject only allows an openQA failure to reject an update, but the lack
  of openQA success need not stop it if it has enough karma. (glibc uses
  this paradigm - a ci/cd failure is an automatic reject, but a ci/cd
  pass adds nothing to the consensus needed)

... and so on down the list. Each user, including openQA, can "vote" a
pass or fail, and the rules say how all those passes and fails result in
the update's overall pass or fail.

This would allow the openQA resources to prioritize updates that it
knows *needs* openQA results, which allocating spare cycles to packages
that could benefit from testing but don't require it.  It also means
that additional openQA resources can be put to use immediately, while
still allowing for growth in critical path size, without being wasted on
unseen results.
___
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: [PATCH] parser: Ignore CFWS in In-Reply-To, References headers

[DJ Delorie]

Stephen Finucane  writes:
> diff --git patchwork/parser.py patchwork/parser.py
> index e6e1a7fb..17cc2325 100644
> --- patchwork/parser.py
> +++ patchwork/parser.py
> @@ -31,6 +31,7 @@ from patchwork.models import SeriesReference
>  from patchwork.models import State
>  
>  
> +_msgid_re = re.compile(r'<[^>]+>')

Ok; a msgid is  and we don't support <> (empty) msgid

>  if 'In-Reply-To' in mail:
>  for in_reply_to in mail.get_all('In-Reply-To'):
> -r = clean_header(in_reply_to)
> -if r:
> -refs.append(r)
> +ref = _msgid_re.search(clean_header(in_reply_to))
> +if ref:
> +refs.append(ref.group(0))

Instead of appending the header as-is, we extract all <*> patterns, OK.
Would have the same effect if the string only had a msgid in it.

>  if 'References' in mail:
>  for references_header in mail.get_all('References'):
> -h = clean_header(references_header)
> -if not h:
> -continue
> -references = h.split()
> +references = _msgid_re.findall(clean_header(references_header))
>  references.reverse()
>  for ref in references:
> -ref = ref.strip()
>  if ref not in refs:
>  refs.append(ref)

Likewise OK.

> diff --git patchwork/tests/test_parser.py patchwork/tests/test_parser.py

The rest looks all OK to me, without needing line-by-line review.

Thanks!
Reviewed-by: DJ Delorie 

___
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork

Re: [OS-BUILD PATCH] redhat/kernel.spec.template: Fix intel-speed-select compile

[DJ Delorie]

Prarit Bhargava  writes:
>> So this papers over the real problem. I looked at the Makefile and wonder why
>> CFLAGS wasn't being passed over even with "override" being used to append the
>> flags. Seems the real problem is that the updated CFLAGS aren't being passed
>> to the submake used to build the tool. I did this here and it seems to have
>> fixed the problem:

There's a HUGE difference between "CFLAGS=x make" and "make CFLAGS=x",
or setting CFLAGS inside a Makefile.  That make treats environment
variables as makefile variables doesn't mean they're equal.

Make variables are NOT passed to child processes if they originate in
the Makefile, but environment variables are, and sometimes make
variables start off as environment variables, which can make it seem
otherwise:

When 'make' runs a recipe, variables defined in the makefile are
  placed into the environment of each shell.  This allows you to pass
  values to sub-'make' invocations (*note Recursive Use of 'make':
  Recursion.).  By default, only variables that came from the
  environment or the command line are passed to recursive invocations.
  You can use the 'export' directive to pass other variables.  *Note
  Communicating Variables to a Sub-'make': Variables/Recursion, for full
  details.

I will add that, noted during testing, using the "FLAG+=something" form
on the command line does NOT trigger the "from the command line" rule if
the FLAG otherwise didn't trigger it itself.  This might be the specific
case here.

So I don't think this is papering over the real problem, I think this is
the right solution (or use export), for when you don't collect such
variables in a .included file.

>> ```
>> $ git diff
>> diff --git a/tools/power/x86/intel-speed-select/Makefile
>> b/tools/power/x86/intel-speed-select/Makefile
>> index d2fba1297d96..0858aba12d21 100644
>> --- a/tools/power/x86/intel-speed-select/Makefile
>> +++ b/tools/power/x86/intel-speed-select/Makefile
>> @@ -40,7 +40,7 @@ prepare: $(OUTPUT)include/linux/isst_if.h
>> $(OUTPUT)include/linux/thermal.h
>>   ISST_IN := $(OUTPUT)intel-speed-select-in.o
>> 
>>   $(ISST_IN): prepare FORCE
>> -   $(Q)$(MAKE) $(build)=intel-speed-select
>> +   $(Q)$(MAKE) CFLAGS="$(CFLAGS)" $(build)=intel-speed-select

You could throw an "env" in there somewhere to see what ended up in the
environment (and thus passed down by default) and what didn't.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[patch 1/1] models: add "comment added to patch" event

[DJ Delorie]

This small patch stitches in "comment added" events into the event
queue.

Signed-off-by: DJ Delorie 
Closes: #424

diff --git a/patchwork/api/event.py b/patchwork/api/event.py
index 71f9593..45b3f4f 100644
--- a/patchwork/api/event.py
+++ b/patchwork/api/event.py
@@ -13,6 +13,7 @@ from rest_framework.serializers import SlugRelatedField
 from patchwork.api.embedded import CheckSerializer
 from patchwork.api.embedded import CoverSerializer
 from patchwork.api.embedded import PatchSerializer
+from patchwork.api.comment import PatchCommentSerializer
 from patchwork.api.embedded import ProjectSerializer
 from patchwork.api.embedded import SeriesSerializer
 from patchwork.api.embedded import UserSerializer
@@ -31,6 +32,7 @@ class EventSerializer(ModelSerializer):
 current_state = SlugRelatedField(slug_field='slug', read_only=True)
 previous_delegate = UserSerializer()
 current_delegate = UserSerializer()
+comment_added = PatchCommentSerializer()
 created_check = SerializerMethodField()
 created_check = CheckSerializer()
 previous_relation = SerializerMethodField()
@@ -40,6 +42,7 @@ class EventSerializer(ModelSerializer):
 Event.CATEGORY_COVER_CREATED: ['cover'],
 Event.CATEGORY_PATCH_CREATED: ['patch'],
 Event.CATEGORY_PATCH_COMPLETED: ['patch', 'series'],
+Event.CATEGORY_PATCH_COMMENT_ADDED: ['patch', 'comment_added'],
 Event.CATEGORY_PATCH_STATE_CHANGED: ['patch', 'previous_state',
  'current_state'],
 Event.CATEGORY_PATCH_DELEGATED: ['patch', 'previous_delegate',
@@ -80,7 +83,7 @@ class EventSerializer(ModelSerializer):
 'id', 'category', 'project', 'date', 'actor', 'patch',
 'series', 'cover', 'previous_state', 'current_state',
 'previous_delegate', 'current_delegate', 'created_check',
-'previous_relation', 'current_relation',
+'previous_relation', 'current_relation', 'comment_added',
 )
 read_only_fields = fields
 versioned_fields = {
@@ -102,4 +105,4 @@ class EventList(ListAPIView):
 .prefetch_related('project', 'patch__project', 'series__project',
   'cover', 'previous_state', 'current_state',
   'previous_delegate', 'current_delegate',
-  'created_check')
+  'created_check', 'comment_added')
diff --git a/patchwork/migrations/0046_patch_comment_events.py 
b/patchwork/migrations/0046_patch_comment_events.py
new file mode 100644
index 000..6d1a798
--- /dev/null
+++ b/patchwork/migrations/0046_patch_comment_events.py
@@ -0,0 +1,24 @@
+# Generated by Django 3.1.13 on 2022-02-25 07:01
+
+from django.db import migrations, models
+import django.db.models.deletion
+
+
+class Migration(migrations.Migration):
+
+dependencies = [
+('patchwork', '0045_addressed_fields'),
+]
+
+operations = [
+migrations.AddField(
+model_name='event',
+name='comment_added',
+field=models.ForeignKey(blank=True, null=True, 
on_delete=django.db.models.deletion.CASCADE, related_name='+', 
to='patchwork.patchcomment'),
+),
+migrations.AlterField(
+model_name='event',
+name='category',
+field=models.CharField(choices=[('cover-created', 'Cover Letter 
Created'), ('patch-created', 'Patch Created'), ('patch-completed', 'Patch 
Completed'), ('patch-comment-added', 'Patch Comment Added'), 
('patch-state-changed', 'Patch State Changed'), ('patch-delegated', 'Patch 
Delegate Changed'), ('patch-relation-changed', 'Patch Relation Changed'), 
('check-created', 'Check Created'), ('series-created', 'Series Created'), 
('series-completed', 'Series Completed')], db_index=True, help_text='The 
category of the event.', max_length=25),
+),
+]
diff --git a/patchwork/models.py b/patchwork/models.py
index 6304b34..74229de 100644
--- a/patchwork/models.py
+++ b/patchwork/models.py
@@ -1022,6 +1022,7 @@ class Event(models.Model):
 CATEGORY_COVER_CREATED = 'cover-created'
 CATEGORY_PATCH_CREATED = 'patch-created'
 CATEGORY_PATCH_COMPLETED = 'patch-completed'
+CATEGORY_PATCH_COMMENT_ADDED = 'patch-comment-added'
 CATEGORY_PATCH_STATE_CHANGED = 'patch-state-changed'
 CATEGORY_PATCH_DELEGATED = 'patch-delegated'
 CATEGORY_PATCH_RELATION_CHANGED = 'patch-relation-changed'
@@ -1032,6 +1033,7 @@ class Event(models.Model):
 (CATEGORY_COVER_CREATED, 'Cover Letter Created'),
 (CATEGORY_PATCH_CREATED, 'Patch Created'),
 (CATEGORY_PATCH_COMPLETED, 'Patch Completed'),
+(CATEGORY_PATCH_COMMENT_ADDED, 'Patch Comment Added'),
 (CATEGORY_PATCH_STATE_CHANGED, 'Patch State Changed'),
 (CATEGORY_PATCH_DELEGATED, 'Patch Delegate Changed'),
 (CATEGORY_PATCH_RELATION_CHANGED, 'Patch Relation Changed'),
@@ -1113,6 +1115,12 @@ c

Re: [patch v2] glob: resolve DT_UNKNOWN via is_dir

[DJ Delorie]

Paul Eggert  writes:
>>> +# define dirfd(str) __dirfd (str)
>> 
>> This needs an #undef before it, else it causes build errors as glibc
>> already has a definition for dirfd() and it conflicts with this one.
>> Prudence says they should *all* be protected as such, but I only mention
>> the new one.
>
> Thanks, I protected it with an ifdef instead as that's more likely 
> perform better.

The use in glob.c conflicts with the definition in glibc, so #undef is
needed, not #ifndef.  glibc has:

  /* This is the data type of directory stream objects.
 The actual structure is opaque to users.  */
  typedef struct __dirstream DIR;
  extern int dirfd (DIR *__dirp) __THROW __nonnull ((1));

What works in a glibc build is this:

  # undef dirfd
  # define dirfd(str) __dirfd (str)

Re: pipewire and wireplumber

[DJ Delorie]

Roger Heflin  writes:
> He has a graphical login session.

I very clearly stated that I did not.  I boot to a text login prompt,
log in, and run "exec xinit .xsession -- -listen tcp -retro" (I have a
script for it called "x" :)

I've never had much luck getting login managers to run my weird
environment correctly.

> I am going to guess he is using straight-X windows with one of the
> ancient simple window managers (twm, mwm).

fvwm2 :-)

> DJ: are you the same DJ Delorie that did the work 30 years ago on
> djgcc for DOS?  If so, that was some good work.  I used it for some
> image processing work.

Yes.  You're welcome!  It's always good to hear that someone found my
work useful.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: pipewire and wireplumber

[DJ Delorie]

"R. G. Newbury"  writes:
> If you don't mind answering, was it a Rhode Island Red cockerel or a hen 
> which you sacrificed to learn these arcane secrets? And, full-moon at 
> midnight, or dark of the moon? Or did this take moving up to a goat?

It took a LOT of googling to find the one person who mentioned it
elsewhere in the space-time continuum.

> Or are you a graduate of Hogwarts? Because I am quite sure that none of 
> these snippets show up anywhere in the so-called documentation. Pure 
> magic, just like any sufficiently advanced technology.

IIRC it was Arch's or Gentoo's forums that had this bare-metal-gem.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: pipewire and wireplumber

[DJ Delorie]

Geoffrey Leach  writes:
> Is there a 'Getting Started With pipewire' and/or wireplumber
> somewhere? Or should they 'just work' and I need to check my
> connections?

As a non-gnome (and non-display-manager) user, I share these .xsession
snippets:

# Required by pipewire, at least
export XDG_RUNTIME_DIR=$(mktemp -d /tmp/$(id -u)-runtime-dir.XXX)

# Required by most things
eval `dbus-launch --sh-syntax --exit-with-session`

pipewire &
pipewire-pulse &
(sleep 2 ; wireplumber & ) &


There wasn't a pipewire-specific config; it uses the same ALSA backend
as pulseaudio used.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [patch v2] glob: resolve DT_UNKNOWN via is_dir

[DJ Delorie]

Paul Eggert  writes:
> I don't see how the patch fixes the case where readdir_result_type (d) 
> returns DT_LNK; this might be a symlink to a directory.

It was not part of the problem I was trying to solve.  A DT_LNK was
already a known file type, and handled, so I left it alone.

> Proposed pair of patches attached (I haven't installed these). The first 
> is yours but with tabs turned to spaces and with ChangeLog equal to your 
> log entry. The second contains my proposed improvements. I haven't 
> tested except on the Gnulib test cases (which aren't much).

I tested it on upstream glibc; it needs one #undef but was otherwise ok.

Reviewed-by: DJ Delorie 

> Of course performance will suffer with all these correctness patches, 
> but that can wait until a rewrite.

Modern XFS and EXT filesystems should not hit these code paths at all,
except for symbolic links, and even then only with GLOB_ONLYDIR.

> +# define dirfd(str) __dirfd (str)

This needs an #undef before it, else it causes build errors as glibc
already has a definition for dirfd() and it conflicts with this one.
Prudence says they should *all* be protected as such, but I only mention
the new one.

> +  case DT_LNK: case DT_UNKNOWN:

I contemplated the case of symbolic links; I couldn't find anything in
the standards about it but I went with "glob does what shell wildcards
do" and those followed links, and I think that makes sense, so OK.  I
added that case to my local test area and it seems to do what I think
people will expect it to do.

[patch v2] glob: resolve DT_UNKNOWN via is_dir

[DJ Delorie]

[v2: changed malloc failure from ignore to error; added support for
alloca; tested by copying to glibc and testing there]

The DT_* values returned by getdents (readdir) are only hints and
not required.  In fact, some Linux filesystems return DT_UNKNOWN
for most entries, regardless of actual type.  This causes make
to mis-match patterns with a trailing slash (via GLOB_ONLYDIR)
(see make's functions/wildcard test case).  Thus, this patch
detects that case and uses is_dir() to make the type known enough
for proper operation.

Performance in non-DT_UNKNOWN cases is not affected.

The lack of DT_* is a well known issue on older XFS installations
(for example, RHEL 7 and 8, Fedora 28) but can be recreated by
creating an XFS filesystem with flags that mimic older behavior:

$ fallocate -l 10G /xfs.fs
$ mkfs.xfs -n ftype=0 -m crc=0 -f /xfs.fs
$ mkdir /xfs
$ mount -o loop /xfs.fs /xfs

diff --git a/lib/glob.c b/lib/glob.c
index f8d8a306f2..c28c92a42c 100644
--- a/lib/glob.c
+++ b/lib/glob.c
@@ -1381,7 +1381,33 @@ glob_in_dir (const char *pattern, const char *directory, 
int flags,
   if (flags & GLOB_ONLYDIR)
 switch (readdir_result_type (d))
   {
-  case DT_DIR: case DT_LNK: case DT_UNKNOWN: break;
+  case DT_DIR: case DT_LNK: break;
+ case DT_UNKNOWN:
+   {
+ /* The filesystem was too lazy to give us a hint,
+so we have to do it the hard way.  */
+ char *fullpath, *p;
+ bool isdir;
+ int need = strlen (directory) + strlen (d.name) + 2;
+ int use_alloca = glob_use_alloca (alloca_used, need);
+ if (use_alloca)
+   fullpath = alloca_account (need, alloca_used);
+ else
+   {
+ fullpath = malloc (need);
+ if (fullpath == NULL)
+   goto memory_error;
+   }
+ p = stpcpy (fullpath, directory);
+ *p++ = '/';
+ strcpy (p, d.name);
+ isdir = is_dir (fullpath, flags, pglob);
+ if (!use_alloca)
+   free (fullpath);
+ if (isdir)
+   break;
+ continue;
+   }
   default: continue;
   }
 

Re: cURL author receives rude LogJ4 security inquiry

[DJ Delorie]

Akira Urushibata  writes:
> When you get something for free, you are supposed to say thanks.

While I agree with you in general, when you say "you are supposed to..."
you are restricting freedoms.

When you choose to write free software, you choose to let people use it
without quid pro quo[*].  If you don't like those terms, don't write Free
Software.

If a Fortune 500 company files a bug report, it's an opportunity to
present your consulting rates and contract terms :-)


[*] aside from agreeing to the GPL or equivalent, of course

Re: Do mirages appear when images are enlarged?

[DJ Delorie]

Akira Urushibata  writes:
> Mr. Kaz Kylheku claims that artifacts that never existed in reality
> may show up when images are magnified.  If anybody believes that this
> is true, please show me examples.  I believe they would be of interest
> to follow list members.

Recent demonstrations of AI "upscaling" old low-resolution photos or
analog video to "4K quality" are an excellent example of this.  They
fill in details where none exist, based on copying them from other
similar data where it does.

> In a previous post I provided links to two newspaper articles,

The Rittenhouse trial was televised.  Did you watch it yourself, or are
you relying on third-party, likely biased, sources?

(Note: I have not watched it myself, and base my comments below on this
analysis video: https://www.youtube.com/watch?v=NxoYNpBMaCg )

> Both considered the judge's decision declaring the image inadmissible
> bizarre.

The judge did not declare the image inadmissable at all.  He declared
that Apple's software could not be used to zoom the image unless the
prosecution provided expert testimony that the admissibility of the
image would not be changed by such zooming.  An expert was not available
in the time allotted, so an alternate software that was previously
vetted was used instead.

> We already have software that add color to old black-and-white
> photographs.

This is an excellent example of adding details that aren't in the
original image - if the image was colorized, and the color was used as
evidence in the trial, I would hope the judge would declare it
inadmissible.

> Judges must be careful when deciding whether something can be admitted
> as evidence or not.  Where judges are elected, voters should consider
> whether a candidate understands technology, at least the kind which
> is now commonplace.

I think in this case, the judge *did* understand that our *current*
technology MIGHT be able to use "AI" to add details to zoomed images,
and thus the prosecution had to do due diligence to prove that such was
not the case.  It was not the image which was a concern, it was software
which might modify the image in such a way which might taint the
evidence.  Whether you believe that Apple software does this or not is
irrelevent; it still must be proven in court.

> As programmers we must keep in mind how much difference an accurate
> record can make.  We also must be willing to be informative to
> consumers who need advice on the matter.

Agreed 100%

Re: [patch] glob: resolve DT_UNKNOWN via is_dir

[DJ Delorie]

Florian Weimer  writes:
> I thought the bug is that it's not actually a hint?  That DT_UNKNOWN
> here leads to incorrect results in glob?

All the DT_* are hints, according to the man pages, which say that
DT_UNKNOWN must be handled by the caller.  So I guess it depends on
whether the original developers knew this and weren't worried about
accuracy, or if there were no filesystems that ever returned DT_UNKNOWN
for regular files, so it was decided to always include "I don't know"'s
as a "future proofing" option.

Doesn't matter to me either way, of course.

Re: [patch] glob: resolve DT_UNKNOWN via is_dir

[DJ Delorie]

Florian Weimer  writes:
>> +  if (fullpath == NULL)
>> +/* This matches old behavior wrt DT_UNKNOWN.  */
>> +break;
>
> Shouldn't this report memory allocation failure to the caller?

We could easily replace that break with a "goto memory_error" but that
changes the new logic from "better hint" to "mandatory function".

[patch] glob: resolve DT_UNKNOWN via is_dir

[DJ Delorie]

The DT_* values returned by getdents (readdir) are only hints and
not required.  In fact, some Linux filesystems return DT_UNKNOWN
for most entries, regardless of actual type.  This causes make
to mis-match patterns with a trailing slash (via GLOB_ONLYDIR)
(see make's functions/wildcard test case).  Thus, this patch
detects that case and uses is_dir() to make the type known enough
for proper operation.

Performance in non-DT_UNKNOWN cases is not affected.

The lack of DT_* is a well known issue on older XFS installations
(for example, RHEL 7 and 8, Fedora 28) but can be recreated by
creating an XFS filesystem with flags that mimic older behavior:

$ fallocate -l 10G /xfs.fs
$ mkfs.xfs -n ftype=0 -m crc=0 -f /xfs.fs
$ mkdir /xfs
$ mount -o loop /xfs.fs /xfs

[tested by importing this change to glibc, and using that to run make's 
testsuite]

diff --git a/lib/glob.c b/lib/glob.c
index 22c459574..d0521bb4a 100644
--- a/lib/glob.c
+++ b/lib/glob.c
@@ -1381,7 +1381,26 @@ glob_in_dir (const char *pattern, const char *directory, 
int flags,
   if (flags & GLOB_ONLYDIR)
 switch (readdir_result_type (d))
   {
-  case DT_DIR: case DT_LNK: case DT_UNKNOWN: break;
+  case DT_DIR: case DT_LNK: break;
+ case DT_UNKNOWN:
+   {
+ /* The filesystem was too lazy to give us a hint,
+so we have to do it the hard way.  */
+ char *fullpath, *p;
+ bool isdir;
+ fullpath = malloc (strlen (directory) + strlen (d.name) + 
2);
+ if (fullpath == NULL)
+   /* This matches old behavior wrt DT_UNKNOWN.  */
+   break;
+ p = stpcpy (fullpath, directory);
+ *p++ = '/';
+ strcpy (p, d.name);
+ isdir = is_dir (fullpath);
+ free (fullpath);
+ if (isdir)
+   break;
+ continue;
+   }
   default: continue;
   }
 

Re: Update to GCC copyright assignment policy

[DJ Delorie via Gcc]

"Maciej W. Rozycki"  writes:
>  My interpretation of this would be for modifications rather than original 
> sources, so v3+ applies to unmodified sources (for obvious reasons, given 
> that the recipient of the sources is not a copyright holder), however as a 
> copyright holder I can release my modifications say under v4 or v4+.  It 
> is unclear to me if the newer licence will then "stick" to the rest of the 
> sources, but I suspect it will.  A copyright assignment made to FSF (or 
> another legal entity) prevents this complication from happening.

I see two cases here:

1. You release a modified copy of gcc, your parts can be whatever you
   want, sure, as long as it's GPLv3 compatible.

2. You're contributing *to* gcc, in which case, I'd hope that any
   attempts to impose a different license would be rejected at the patch
   review step.

Re: Update to GCC copyright assignment policy

[DJ Delorie via Gcc]

Paul Koning via Gcc  writes:
>> GCC's license is "GPL version 3 or later", so if there ever needed to be a
>> GPL v4, we could move to it without needing permission from anyone.
>
> I don't think that is what the license says.  It says:
>
> GCC is free software; you can redistribute it and/or modify
> it under the terms of the GNU General Public License as published by
> the Free Software Foundation; either version 3, or (at your option)
> any later version.
>
> To me that means the recipient of the software can relicense it under
> a later license.  It doesn't say to me that the original distribution
> can do so.

I've never read it that way.  To me it says "a recipient may
redistribute it under terms of a newer license, but the license remains
v3+ even if they do" - we're giving the recipient a choice of actions,
but not power to relicense.

I.e. a recipient is not permitted to relicense the code, ever.  However,
they may act as if it's licensed under a newer license.  If they share
the code, *that* recipient gets to make the same choice - v3 or newer.

So if the original copyright holder can't change the license, nobody
can.

Re: Censorship protest relevance (was: Re: Continuation of my previous mail)

[DJ Delorie]

shulie  writes:
> That is MOSTLY, but not completely true.  The Phone company, for
> example, can not disconnect you because your a communist.

That's an example of the contract thing I mentioned.  They entered into
a contract where, in exchange for a temporary monopoly, they agreed to
operate under certain rules.  Most scarce resources (roads, radio
spectrum, etc) are managed this way here.

You can certainly make your own private phone company and kick out
whoever you want, but don't expect the same benefits that big phone
company gets.

The interesting question is: what will happen when the government starts
*forcing* companies to follow these rules, without compensation?  That's
where the censorship argument comes into play, and possibly the Fifth
Amendment (government can't just "take" without compensation).

Re: Censorship protest relevance (was: Re: Continuation of my previous mail)

[DJ Delorie]

Jacob Bachmeyer  writes:
> Since GNU is based in USA, is this particular protest obsolete, as any 
> such censorship applied to us would be clearly unconstitutional,

For those outside the USA (and probably many inside too ;) ...

The USA laws don't work that way; the first amendment *only* prevents
the government from censoring the non-government, it has no power over
private people or organizations from censoring their own speech.  There
is no such thing as a "free speech right" in the USA *outside of* the
laws themselves.

  "Congress shall make no law respecting an establishment of religion,
  or prohibiting the free exercise thereof; or abridging the freedom of
  speech, or of the press; or the right of the people peaceably to
  assemble, and to petition the Government for a redress of grievances."

Note the "Congress shall make no law" part.  That's all there is.
Nothing else is covered, nothing else is prevented, nothing else is
guaranteed.

So no, censorship in the USA is NOT unconstitutional.  Only laws that
cause censorship are.

(as an amusing twist, laws that try to *prevent* private censorship
could be considered unconstitutional, since that's also government
trying to control speech)

HOWEVER...

USA law doesn't stop private individuals or organizations from entering
into contracts that limit speech, and providing for damages etc if
violated, as long as the contract is fair and valid.  The government can
thus offer a contract whereby a clinic (for example) receives funds in
exchange for an agreement to limit speech.  This is not considered
censorship since the clinic may choose to not enter in to the contract
and thus not be limited.  Voluntary is OK, involuntary is not.  This is
no different than, for example, an NDA you must sign in exchange for
employment.

That such clinics may in fact go out of business without government
funding, while relevent in reality, is irrelevent in this context.


[and I couldn't tell if you were referring to the manual, or the federal
program referred to therein, so I tried to cover both, as neither is
legally considered "censorship"]

Re: The anti-GNU defamatory group of Ludovic Court�s - Re: assessment of the GNU Assembly project

[DJ Delorie]

"Alfred M. Szmidt"  writes:
> There is indeed no such group in the GNU project,

There is a GNU Assembly.  You may disagree with it, or wish it didn't
exist, or have complaints about its purpose or status, but it exists.
Denying this doesn't help resolve any of the issues around it.

And I really don't understand your fear of GNU maintainers getting
together and discussing things outside of an FSF-sanctioned enclave.

Re: The anti-GNU defamatory group of Ludovic Court�s - Re: assessment of the GNU Assembly project

[DJ Delorie]

"Alfred M. Szmidt"  writes:
> Because you disagree with a message is not a reason to reject it.
> In either case, there is no such thing as a "GNU assembly",

Wow, such hypocrisy.  Just because you disagree with the GNU Assembly
doesn't mean it doesn't exist.

Re: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI

[DJ Delorie]

I normally would complain about taking options away from users, but as I
typically use ssh for root *anyway*, I felt this wasn't appropriate
(although I have a friend who never uses ssh keys, always
password-over-ssh).

I would, however, ask that the config file have a commented out option
that re-enables it, with a suitable text comment clearly saying
"uncomment this to allow root passwords over ssh".

Perhaps that comment might be a good place to mention ssh-copy-id ?

Such comments make the "best practices" much more discoverable without
frustrating users who just want to make things work.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: assessment of the GNU Assembly project

[DJ Delorie]

"Kaz Kylheku (gnu-misc-discuss)" <936-846-2...@kylheku.com> writes:
> Those goons

Can we stop with the name-calling, please?  

> (What they are extremely comfortable with is---doh!---using the
> work without paying anyone.)

As one of the goon-workers, I (and my whole group) get paid by our head
goons to work on Free Software.  You're welcome.

Re: Retiring a set of old X utilities

[DJ Delorie]

Peter Hutterer  writes:
> xfd

I use this a lot; what is the modern replacement for it?
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: police report against the petition mob

[DJ Delorie]

There's a huge difference between an armed insurrection at a political
capital, and people expressing their opinions calmly in writing
(regardless of what those opinions are, or how much you sensationalize
them).  Choosing such highly "emotionally charged" words when making
such unfair comparisons only adds fuel to the fire.

Please use kinder words.

(and I mean this for people on both sides of this conversation)

Re: Truth matters when writing software and selecting leaders

[DJ Delorie]

Akira Urushibata  writes:
> In my opinion the FSF leaders are not doing things in the right order.

People are quite able to do more than one thing at a time.

> until those who are spreading misinformation are brought to justice.

Beware - a lot of what you think is "misinformation", others think is
"my opinion".  The question of what speech is "actionable" is not one we
can easily define (unless one is a judge, at least in the USA).  Do not
fall into the trap of saying "You should be punished unless I agree with
what you say."

> Truth is important

The problem with Truth is that there's your Truth, and someone else's
Truth.  Don't confuse "truth" with "facts".  Truth is often colored by
one's own beliefs and opinions.

Re: Web versions

[DJ Delorie]

aviva  writes:
> On 3/14/21 6:18 PM, DJ Delorie wrote:
>>  If WebAssembly or Javascript can be used in a
>> way that honors the four freedoms,
>
> But it can't...period.  And in the real world , it doesn't.  We don't
> promote software that hurts peopleperiod.

It can and it does, and I showed you that *I* use it in that way.  The
software has been very helpful to me, in ways I completely control.

But don't let me interfere with your period.

Re: Web versions

[DJ Delorie]

aviva  writes:
> On 3/14/21 6:18 PM, DJ Delorie wrote:
>> Thus, in a way you are arguing AGAINST the
>> user's freedom.
>
> No - I am arguing against creating a system where you lose control of
> your computer and it is over run by hackers because of poor deisgn. 
> NOTHING can excuse that,

GCC has been used to write software that hacks into other people's
computers.  Should we argue against writing gcc?  After all, there's no
exuse for using software for criminal activities.

You are arguing that we should take away a technology from the user,
because some people use that technology in ways you disagree with.
However, other people use that same technology in other ways.  It is not
the technology that is evil, it's how it's used that may be evil.

Re: Web versions

[DJ Delorie]

aviva  writes:
> On 3/14/21 6:18 PM, DJ Delorie wrote:
>> This application totally honors the four freedoms,
>
> No - it doesn't actually.  It fails value one that the user is in
> control of there system.

How so?  I downloaded the sources and ran them on my own system.  How am
I not in control?

Re: Web versions

[DJ Delorie]

>>> technology which is designed to be slaveware and dependent un insecure
>> This is a value judgement
>
>
> Right, being a slave is bad.  That IS a value judgement.  Values - that
> those are good.  Get some!

Since you insist on misinterpreting, let me clarify.

The value judgement is that the "technology is designed to be something".

I say that the technology just *is*.  We should judge the technology
independently of how some people choose to use it.

Re: Web versions

[DJ Delorie]

shulie  writes:
> technology which is designed to be slaveware and dependent un insecure

This is a value judgement on the developer writing the software, not the
technology of the software itself.  Please do not confuse the two.

For example, I regularly use a javascript application that is served by
another site but runs 100% on my computer with 100% of the sources
available to myself.  I think I even did a "save file" to run it when
the network is down.  This application is hosted in source form on
github and licensed in a GNU-compatible way.

This application totally honors the four freedoms, yet uses a technology
you say we should not use.  Thus, in a way you are arguing AGAINST the
user's freedom.

> Or maybe they will, but that doesn't mean it is something the GNU
> project should promote.

The GNU project should promote Free Software in all the ways that the
user can benefit from those freedoms, regardless of what technology
underlies those freedoms.  If WebAssembly or Javascript can be used in a
way that honors the four freedoms, the FSF's position should be to
encourage *those* ways, and discourage *other* ways.  Discouraging the
technology itself is, IMHO, outside the FSF's scope.

Re: Web versions

[DJ Delorie]

"Alfred M. Szmidt"  writes:
> Depending on someone else to even be able to run
> your program is something we defintily do not want.

Are you arguing against Javascript, or SaaS, or just proprietary Saas?

Consider the following:

You have a Free Software browser which you built yourself.  It includes
a Javascript engine (also FS) which complies with all relevent
standards.  You check out a repository that includes sources for gcc,
binutils, et al, along with sources for some application.  You build
gcc, binutils, et al locally, and use them to build webasm versions of
each of those plus your application.

Now you run your browser and point it at file:///myapp.html

Everything I've suggested so far complies with the wording and spirit of
the GPL, and is fully under the user's control.

Would you object to this just because it's "in a browser" ?

Personally, I see a huge difference between a "service" and a "trap".
There must be a way to offer a service to others in a way that complies
with the spirit of the GPL.  We don't complain about others pre-building
packages for us, because we *could* build them ourselves.  Why not say
the same for SaaS?  We don't complain about the service if we *could*
provide that service for ourselves locally?

I think we need to be careful about how we present our arguments, and
remain focused on the Free Software aspects, so as not to preclude
things which *could* be Free Software just because someone showed one
counterexample.

Warning: this email was sent using a server which is not under your
control, done on your behalf.  You have been warned.

Re: F35 Change: "Fedora Linux" in /etc/os-release

[DJ Delorie]

Vitaly Zaitsev via devel  writes:
> Ofc we can use it, but only when we will get rid of all GNU libraries, 
> compiler and utilities. :-)

Please don't start this tired old argument again.  "Fedora Linux" is a
name, not an ISO standard, we can call it whatever we want.  We respect
that you may have a differing opinion, but you must respect that others
may not share it.  Feel free to start your own distro with whatever name
*you* choose ;-)

BTW as a GNU C library maintainer, I have no problem calling it "Fedora
Linux".  Communication is about using words that convey understanding,
not about confusing the message for political gain.

Also, telling people how they may or may not use GNU packages is
contrary to the GNU Manifesto.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [PATCH v3 6/6] stdlib: Add testcase fro BZ #26241

[DJ Delorie]

Adhemerval Zanella via Libc-alpha  writes:
> -tst-setcontext9 tst-bz20544
> +tst-setcontext9 tst-bz20544 tst-canon-bz26341

New test, ok.

> +LDLIBS-tst-canon-bz26341 = $(shared-thread-library)

Ok.

> diff --git a/stdlib/tst-canon-bz26341.c b/stdlib/tst-canon-bz26341.c

> +/* Check if realpath does not consume extra stack space based on symlink
> +   existance in the path (BZ #26341)

Is this allowed to be two lines?

> +   Copyright (C) 2020 Free Software Foundation, Inc.

Year is wrong now :-)

> +#include 
> +#include 
> +#include 
> +#include 

Ok

> +#define __sysconf sysconf
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Ok

> +static char *filename;
> +static size_t filenamelen;
> +static char *linkname;
> +
> +#ifndef PATH_MAX
> +# define PATH_MAX 1024
> +#endif

Ok.

> +static void
> +create_link (void)
> +{
> +  int fd = create_temp_file ("tst-canon-bz26341", );
> +  TEST_VERIFY_EXIT (fd != -1);
> +  xclose (fd);
> +
> +  char *prevlink = filename;
> +  int maxlinks = __eloop_threshold ();
> +  for (int i = 0; i < maxlinks; i++)
> +{
> +  linkname = xasprintf ("%s%d", filename, i);
> +  xsymlink (prevlink, linkname);

linkname -> prevlink -> filename

> +  add_temp_file (linkname);
> +  prevlink = linkname;
> +}
> +
> +  filenamelen = strlen (filename);
> +}

On exit, linkname has the last link created.  Needs a comment to that
effect.


> +static void *
> +do_realpath (void *arg)
> +{
> +  /* Old implementation of realpath allocates a PATH_MAX using alloca
> + for each symlink in the path, leading to MAXSYMLINKS times PATH_MAX
> + maximum stack usage.
> + This stack allocations tries fill the thread allocated stack minus
> + both the resolved path (plus some slack) and the realpath (plus some
> + slack).
> + If realpath uses more than 2 * PATH_MAX plus some slack it will trigger
> + a stackoverflow.  */
> +
> +  const size_t realpath_usage = 2 * PATH_MAX + 1024;
> +  const size_t thread_usage = 1 * PATH_MAX + 1024;
> +  size_t stack_size = support_small_thread_stack_size ()
> +   - realpath_usage - thread_usage;
> +  char stack[stack_size];
> +  char *resolved = stack + stack_size - thread_usage + 1024;

This points us at PATH_MAX away from the end of stack[].  Ok.  Also
forces most of the stack to get used up :-)

> +  char *p = realpath (linkname, resolved);

We assume the test will crash if we use more stack than we allocated.

> +  TEST_VERIFY (p != NULL);

realpath() must succeed, ok

> +  TEST_COMPARE_BLOB (resolved, filenamelen, filename, filenamelen);

And give us the right result, ok

> +  return NULL;
> +}
> +
> +static int
> +do_test (void)
> +{
> +  create_link ();
> +
> +  pthread_t th = xpthread_create (support_small_stack_thread_attribute (),
> +   do_realpath, NULL);
> +  xpthread_join (th);
> +
> +  return 0;
> +}

Run the test in a thread with a small stack, ok.

> +#include 

LGTM with that comment.

Reviewed-by: DJ Delorie 

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

[DJ Delorie]

Daniel P. Berrangé  writes:
> Perhaps this is heresy, but we could stop calling our main development
> stream "rawhide", and instead call it "main", then it will be trivially
> aligned with the "main" git branch name :-)

But fedoras aren't made of sheets of main, they're made from sheets of
rawhide...
___
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

Re: Gow, Cygwin alternative refers to GNU programs as open source UNIX tools

[DJ Delorie]

Jean Louis  writes:
> I have downloaded packages. For GNU tools I can find sources. For Gow,
> I cannot find.

Perhaps the runtime was elided under the "major components" part of GPL
sec 3 ?

 "However, as a special exception, the source code distributed need not
  include anything that is normally distributed (in either source or
  binary form) with the major components (compiler, kernel, and so on)
  of the operating system on which the executable runs, unless that
  component itself accompanies the executable."

That exception was added so that DJGPP-built GNU executables did not
need to include DJGPP's sources, just the GNU sources.  DJGPP has been
distributing GNU binaries this way for 30 years (the "corresponding
sources" are the GNU sources, although the DJGPP sources themselves are
available elsewhere in the typical DJGPP mirror area).

As for the GOW sources themselves, the GPL allows for "mere aggregates"
and perhaps that applies here.  If you use a non-GNU "cp" command to
copy a GNU "find" binary, does that make the non-GNU "cp" illegal?  Of
course not.  If GOW is independent of the GNU tools, other than to copy
them to your machine, I don't see how the GPL derivative-work rules
apply.

> This package below is distributed as gow-0.8.0 "source" and contains
> binaries. Users receiving binaries cannot know to which license each
> binary is there, unless they would be experienced.

This is no different than any other GNU-including distribution, like
Fedora or Ubuntu.  This is why GNU tools are supposed to print their
license when run in a default way.

> There is nowhere written or explained how to make the Gow oneself and
> I do not find source for Gow.

I see no reason why you're entitled to it, either.

Re: glibc troubles in rawhide?

[DJ Delorie]

Fabio Valentini  writes:
> ImportError: /lib64/libglib-2.0.so.0: undefined symbol: lstat64, version 
> GLIBC_2.33

This looks like something was built against the new glibc, but tried to
run against the old glibc...
___
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

Re: how to control webcam.

[DJ Delorie]

"home user"  writes:
>> guvcview has a "-z" option to bring it up in control-only mode,
>
> I did not see that option in the man page.  How did you know (or find out) 
> about it?

I ran "guvcview --help" and hoped it printed help :-)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@lists.fedoraproject.org

Re: how to control webcam.

[DJ Delorie]

I use gtk-v4l to control the webcam during meetings

guvcview has a "-z" option to bring it up in control-only mode,
otherwise it grabs the video stream too.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[DJ Delorie]

Neal Gompa  writes:
> Oh man, that takes me back! I started on DOS with the MS-DOS Editor,
> then went onto the DOS port of Emacs and using DJGPP, then jumped to
> Linux years later...

Now *that* takes me back to the days when I wrote DJGPP ;-)

And for anyone who thinks vi is hard to use, try the original ed (not
edlin) on CP/M.

IMHO the default editor should have the following characteristics:

* arrow keys always move the cursor
* insert, delete, and backspace always do what they say
* ASCII keys always mean "add this character" (insert or overwrite)

* Every other option should have an obvious hint on the screen, such as
  a menu bar or hotkey line, like:

  [F1] exit [F2] save [Ctrl-Z] undo [Ctrl-X] cut

  if it doesn't fit on one line, it's too complicated.

(ed did the opposite of all those, btw ;)

(nano seems to hit most of these, although it's two lines of hints and
INSERT didn't do what I expected - and it wasn't obvious how to get out
of the mode INSERT put me in)
___
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

Re: What are the differences between RHEL and Fedora Server?

[DJ Delorie]

ToddAndMargo via users  writes:
> So RHEL's "prioritization" is different from mine

Yes, which is why RHEL is not the best choice for you.  I'm OK with
that, but there's no reason to take it so personally.  "Doesn't do what
I want" is not the same as "RHEL is trash."

> It does not matter that bugs reported from the community would
> strengthen the overall health of the the product.

We do care about the community, and we do fix bugs reported by the
community.  We do this in this other project called "Fedora" so if
that's what you want, that's what you should use ;-)

(although, ironically, I'm currently working on backporting to RHEL an
upstream patch set that wasn't requested by a customer)
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@lists.fedoraproject.org

Re: What are the differences between RHEL and Fedora Server?

[DJ Delorie]

ToddAndMargo via users  writes:
> The idea is that you can rely on things, including the locked in bugs,

As someone who has a full time job fixing bugs in RHEL, I can
emphatically state that this is not the case at all.

If you want a bug fixed in RHEL, contact your RHEL account manager or
file a RHEL bug.  We prioritize bug fixes according to customer need and
impact.  For example, we won't fix a bug that requires an ABI change if
we promise no ABI changes, etc.  But this is what our customers want.

You seem to have a bias against RHEL but the things you list as weak
points are considered benefits by others.  When an OS upgrade with
recertification could take MONTHS, you absolutely want something that's
not going to change for years on end, yet still has security fixes and
tech support behind it.

> In my technical opinion, RHEL is trash,

Please stop trash-talking something just because it isn't the best
choice for you.  Choose something more appropriate and move on.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@lists.fedoraproject.org

Re: Code of Conduct issue

[DJ Delorie]

"John M. Harris Jr"  writes:
> it is important that issues such as this can be talked about publicly, 

I disagree.  It has nothing to do with Fedora development[*], and allowing
EITHER side to continue this "discussion" allows either side to badger
and bully the opposition until people comply just to shut you up.

Please take this discussion elsewhere, and I support any moderation of
these types of discussions here.


[*] Following the CoC is relevent, discussing it is not.
___
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

Re: How to elf/tst-ldconfig-* in cross test setup

[DJ Delorie]

Vineet Gupta  writes:
>> $ make test-wrapper='> to>/br/build/glibc-867196a7635/scripts/cross-test-ssh.sh root@192.168.0.20' 
>> xcheck
>> subdirs=elf
>
> FWIW the original failures were here
>
>   lock_fd = open (concat (pristine_root_path, "/lock.fd", NULL),
>O_CREAT | O_TRUNC | O_RDWR, 0666);
>   if (lock_fd < 0)
> FAIL_EXIT1 ("Cannot create testroot lock.\n");   <

That's inside test-container.c and should be referring to the
test-root's root (i.e. /br/build/glibc-867196a7635/testroot.root/lock.fd

Is there a UID mismatch between the two systems?  Did you run a full
"make check" at least once, to build the initial testroot?  It does a
full "make install" into $build/testroot.pristine/ to use as the basis
for the container's root.


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: How to elf/tst-ldconfig-* in cross test setup

[DJ Delorie]

Vineet Gupta  writes:
> When you say containers is this linux cgroups or something at a higher
> level: does it need any specific distro container package. Please
> remember this is a constrained system built off of buildroot.

It should not require anything beyond what kernel/glibc provides - we
even build our own /bin/sh for in-container use.  All the
containerization code is in support/test-container.c.  However, some
kernels and/or OSs are *configured* (i.e. for security reasons) to
disallow certain types of namespace unsharing - those should be detected
by test-container and flagged as unsupported tests.

By "container" I mean a simple filesystem/pid namespace using unshare,
sort of a fancy chroot() but it changes your UID and PID also.

See 
https://developers.redhat.com/blog/2018/11/16/microcontainers-for-unit-testing/
for some background info.


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: How to elf/tst-ldconfig-* in cross test setup

[DJ Delorie]

Vineet Gupta  writes:
> No, I'm running this is a cross-compiled setup where the test artifacts are 
> on a
> NFS mounted host. Here's the full strace for test
>
>
> $ strace_static -f
> ~/br/build/glibc-867196a7635/build/elf/tst-ldconfig-ld_so_conf-update

This is a manual run.  Even with a cross setup, you still run
test-container on the cross target:

$ strace_static -f
~/br/build/glibc-867196a7635/build/support/test-container \
~/br/build/glibc-867196a7635/build/elf/tst-ldconfig-ld_so_conf-update

The containerized tests are (in this case) containerized because they
rely on setup files (like /etc/ld.so.conf) inside the container to run
the test.  Otherwise you end up corrupting the host OS.

The test infrastructure knows how to run containerized tests on remote
machines, though... any reason why you're not using that setup?

Note: if containers aren't yet supported on your platform, it's OK to
just skip those tests.  Also, it's not always a good idea to run a
containerized test outside the container; the tests assume they can
trash the container as part of the test.


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: How to elf/tst-ldconfig-* in cross test setup

[DJ Delorie]

Vineet Gupta via Libc-alpha  writes:
> The issue is expected src-path for dso.
>
> | [pid   168] renameat(AT_FDCWD, "/usr/lib/tst-ldconfig-ld-mod.so", AT_FDCWD,
> | "/tmp/tst-ldconfig/libldconfig-ld-mod.so") = -1 EXDEV
> |  (Invalid cross-device link)
>
> In cross setup, /usr/lib needs to be the host path where test is built or the 
> dso
> needs to be copied over to target at the canonical location. I'm not sure 
> what the
> right approach is so any pointers would be great.

This rename should be happening inside the test-container, in a
subdirectory of the build, so should not be a cross-dev link.  Are you
trying to run these tests manually?


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

HEADS UP: make 4.3 coming to rawhide

[DJ Delorie]

In about a week I'll be building make 4.3 for rawhide.  As part of
this, I'll be cleaning up some old Fedora-specific patches that
shouldn't be needed any more (ha!).  In addition, please note any make
4.3-specific changes in its NEWS file:

http://git.savannah.gnu.org/cgit/make.git/tree/NEWS

This build will provide valuable testing time for make 4.3 before the
beta decision point.

Change Request: https://fedoraproject.org/wiki/Changes/MAKE43

Specific incompatibility callouts:

* WARNING: Backward-incompatibility!
  Number signs (#) appearing inside a macro reference or function invocation
  no longer introduce comments and should not be escaped with backslashes:
  thus a call such as:
foo := $(shell echo '#')
  is legal.  Previously the number sign needed to be escaped, for example:
foo := $(shell echo '\#')
  Now this latter will resolve to "\#".  If you want to write makefiles
  portable to both versions, assign the number sign to a variable:
H := \#
foo := $(shell echo '$H')
  This was claimed to be fixed in 3.81, but wasn't, for some reason.
  To detect this change search for 'nocomment' in the .FEATURES variable.

* WARNING: Backward-incompatibility!
  Previously appending using '+=' to an empty variable would result in a value
  starting with a space.  Now the initial space is only added if the variable
  already contains some value.  Similarly, appending an empty string does not
  add a trailing space.
___
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

Re: Harrassment on this list

[DJ Delorie]

Alexandre François Garreau  writes:
> Yet expressing it directly, without filter, it has already been 
> said, is unkind.

I agree, and I think this is a key point to understand.  The FSF has
stated that it will accept work from anyone regardless of what they
BELIEVE.  Kindness is about what people SAY.  I don't think there's a
conflict there.

You can believe in something and choose not to talk about it if you know
the audience would react poorly to what you say or how you say it, that
is kindness.  Choosing to say something that would hurt someone else is
unkind, even if you belive it is true.  It's not about what you believe,
it's about how you choose to talk about that belief.  Communication
happens best when both sides choose carefully how they communicate.

I have never heard the FSF say "we'll accept patches from anyone, no
matter how they behave on our mailing lists".

Re: State of the GNUnion 2020

[DJ Delorie]

Eli Zaretskii  writes:
> No one, not even the above quote, said they have "no impact" in
> general.

I didn't say that.  I said you could argue that.  It's a point to
consider and discuss, that's all.  Sometimes an extreme viewpoint makes
discussion clearer, and the results can be applied to the more vague
cases afterwards.

> The guiding principles of what it takes to be a maintainer of a GNU
> project are communicated to each one of us when he or she is
> appointed.  Those principles have very important impact on what we do,
> day in and day out, as part of our job as maintainers.

But being a leader in a project for a community of developers is so much
more than just doing the GNU maintainership duties.  One of the side
effects of being a good leader is that you have a stronger community,
more developers, more *effective* contributors, etc.  A leader can grow
a community, not just accept patches from it.  This is what the
"outsiders" can see when they choose which project to contribute to.

> Are you really saying that the general public cares about our
> day-to-day decisions, or about how frequently we make releases, or our
> commit rate?

No, but if that's all a maintainer is doing, that's not leadership.

> If you disagree, please show a few examples of such interest, where
> deeper involvement of the leadership in routine management of a
> project did or could have mattered as far as general public is
> concerned.  I could think of none, but maybe my memory is biased.

Can you not remember all those years of djgpp development?  All the
users who came for help, and stayed to help?  You were as responsible
for the success of that community as I was.

> "Can provide" or "does provide"?  Are you saying that leadership _can_
> be from more than one person, or are you saying that it already is?

Both.  Looking at the tools (gcc, glibc, binutils, gdb) I see a strong
guiding hand from the project leads (stewards, maintainers, whatever)
that very much says "leaders".  These are people who not only accept
patches but organize conventions, plan future work, arrange for tutors,
and even in some cases handle sponsorships.  I would say these projects
are thriving under their own leadership *despite* the lack of leadership
from above.

But still, a growing concern in these projects is - why do people choose
to work for other projects and not GNU?  How do we convince, for
example, younger developers to participate?  Having someone who can
accept patches is insufficient to solve this.

Re: State of the GNUnion 2020

[DJ Delorie]

a...@gnu.org (Alfred M. Szmidt) writes:
> That speaks more to the fact that the GNU project leadership has no
> impact on project adaptation, or contributor activity.  But rather it
> is a individual effort by each project maintainer.

One could argue that this indicates that what you term "GNU leadership"
is not providing leadership to the projects, and that the maintainers
must provide that leadership themselves.  What is the point of
leadership that has no impact?

Perhaps this view does not align with your view, but we must also
consider how the general public (or at least the general
free-software-involved public) views us from the outside.  If they are
more likely to be influenced by the maintainers than by RMS, from
*their* point of view, the maintainers *are* the GNU leadership.  We
should not be blind to how we are perceived by others.

And don't fall into the trap of thinking leadership can only come from
one person.  RMS may be "the leader" but he's not the only one providing
leadership to others.

Re: State of the GNUnion 2020

[DJ Delorie]

Jean Louis  writes:
> * DJ Delorie  [2020-02-19 21:01]:
>> 
>> "Kaz Kylheku (gnu-misc-discuss)" <936-846-2...@kylheku.com> writes:
>> > On 2020-02-17 12:37, Andy Wingo wrote:
>> >> Thought experiment: what would GNU be if all of its packages stopped
>> >> developing?  Dead, right?
>> >
>> > The immediate effect would become more of a stable base for the vast
>> > amount of material that depends on it.
>> 
>> For about a month or so, until the next bug, security problem, or
>> missing feature were reported... then people would switch to whatever
>> software was responsive to these problems.  If GNU doesn't respond,
>> someone will eventually fork the software (because they can :) and GNU
>> would lose users.
>
> When people continue developing free software it is a win, not loss.

The question wasn't "what would free software be?"  it was "what would
GNU be?"

There are a lot of projects that are free software but not GNU.  If
people choose to work on those projects instead of GNU, GNU loses, even
if free software wins.

Re: State of the GNUnion 2020

[DJ Delorie]

"Kaz Kylheku (gnu-misc-discuss)" <936-846-2...@kylheku.com> writes:
> On 2020-02-17 12:37, Andy Wingo wrote:
>> Thought experiment: what would GNU be if all of its packages stopped
>> developing?  Dead, right?
>
> The immediate effect would become more of a stable base for the vast
> amount of material that depends on it.

For about a month or so, until the next bug, security problem, or
missing feature were reported... then people would switch to whatever
software was responsive to these problems.  If GNU doesn't respond,
someone will eventually fork the software (because they can :) and GNU
would lose users.

Even DJGPP continues to be responsive (albeit very slowly) to these
things, to remain relevent to the subset of users who need it.

Re: Endorsing version 1.0 of the GNU Social Contract

[DJ Delorie]

"Andreas R."  writes:
> The wiki has been described as a tool for *all* GNU maintainers, even
> though it's only available to a certain subset of GNU maintainers
> willing to agree to new stipulations that were never part of being a
> GNU maintainer.

The wiki states "currently limited to GNU Maintainers".  It does not
explicitly state that being a GNU maintainer is sufficient to guarantee
access, although it does state "wiki for GNU Maintainers".  I see no
ambiguity here, it's intended audience is GNU maintainers,
non-maintainers are not invited yet.

It states that the wiki is governed by a code of conduct.  In today's
legal climate, it's almost required to have such a thing when you invite
others to be contributors (such as GNU requiring a copyright assignment,
this wiki requires a CoC agreement).  The CoC does not seem onerous, it
basically says "don't be a jerk".  If your life goal is to be a jerk,
expect to be not welcome in all sorts of places, including GNU projects.

> Until this distinction becomes more clear, pointing out the difference
> helps prevent misunderstanding.

Incessantly pointing out the difference, as the sole point of an entire
email, does not add anything to the conversation.

Re: Endorsing version 1.0 of the GNU Social Contract

[DJ Delorie]

a...@gnu.org (Alfred M. Szmidt) writes:
> The wiki does not represent the views of the GNU project.  Nor will it
> be hosted on GNU infrastructure, as was made quite clear by the head
> of the GNU project.

I think we all agree on this, and repeating it is not adding anything to
the conversation.  The wiki has clearly been described by its creators
as a tool for the *maintainers*.  We all agree that official
communications go on gnu.org.  But as much as we all support RMS's
position as project head, tools that work for one person (RMS,gnu.org)
do not scale to the hundreds of maintainers (who use git,wikis,irc).

If it's important to you to declare that all communications not-from-RMS
"do not represent the views of the GNU project" you'll just spend all
your time posting on mailing lists, irc, and usenet; disclaiming every
message by every person working on any GNU package.

Disclaimer: This email does not represent the views of the GNU project.

Re: State of the GNUnion 2020

[DJ Delorie]

a...@gnu.org (Alfred M. Szmidt) writes:
> You make the incorrect assumption that the health of the GNU project
> should be measured in how many new projects are adopted or released --
> instead of what our goal is to provide a free operating system.

Are we DONE producing that operating system?  No?  If not, why not?
Aren't all those developers who finished their packages working on
other, new packages?  Why aren't the package counts continuing to
increase, if the developers are otherwise unoccupied?

I think, package activity *is* a valid metric if the goal is "all
packages in the OS are free."

If a set of developers finish a package, and don't start on a new one, I
think that says something interesting about the health of GNU and its
community.

Re: What's GNU -- and what's not

[DJ Delorie]

a...@gnu.org (Alfred M. Szmidt) writes:
> You make the assumption that the views of the maintainers are the
> views of the GNU project -- this has never been the case.  GNU
> maintainers do not define what the GNU project is.

Because we are all code monkeys, aka programming slaves.  As long as we
do what we're told we can be as mean and horrible as we want, because
GNU only cares about results, not whether people like us or not.

Re: Feedback on the GNU Social contract and new wiki.gnu.tools.

[DJ Delorie]

Namecheap, and likely most domain services, automatically block all
personal information by default.  Protecting users' privacy is in line
with GNU standards.  Attempting to expose people's hidden private
information is not.

make 4.3 - F32 or F33?

[DJ Delorie]

I've taken a look at the new make release, and updating Fedora's make
won't be that tricky (aside from some noted backwards
incompatibilities[1], who knows) but I see no reason to rush it into a
last-minute update this close to branching F32.  My current plan is to
introduce it to rawhide just after the F32 branch to give folks time
to see if the update breaks anything, but I'm open to convincing
arguments to push it (or backport it) into F32 also.

We also have some paranoia patches leftover from the 3.8->4.0 update,
including one that changes how newlines are quoted in shell jobs
(upstream quotes backslashes and newlines with more backslashes,
Fedora quotes them with '').  Does anyone have any opinions on this?
Other distros don't have similar patches, but... paranoia :-)



[1] From NEWS:

* WARNING: Backward-incompatibility!
  Number signs (#) appearing inside a macro reference or function invocation
  no longer introduce comments and should not be escaped with backslashes:
  thus a call such as:
foo := $(shell echo '#')
  is legal.  Previously the number sign needed to be escaped, for example:
foo := $(shell echo '\#')
  Now this latter will resolve to "\#".  If you want to write makefiles
  portable to both versions, assign the number sign to a variable:
H := \#
foo := $(shell echo '$H')
  This was claimed to be fixed in 3.81, but wasn't, for some reason.
  To detect this change search for 'nocomment' in the .FEATURES variable.

* WARNING: Backward-incompatibility!
  Previously appending using '+=' to an empty variable would result in a value
  starting with a space.  Now the initial space is only added if the variable
  already contains some value.  Similarly, appending an empty string does not
  add a trailing space.

* NOTE: Deprecated behavior.
  Contrary to the documentation, suffix rules with prerequisites are being
  treated BOTH as simple targets AND as pattern rules.  Further, the
  prerequisites are ignored by the pattern rules.  POSIX specifies that in
  order to be a suffix rule there can be no prerequisites defined.  In this
  release if POSIX mode is enabled then rules with prerequisites cannot be
  suffix rules.  If POSIX mode is not enabled then the previous behavior is
  preserved (a pattern rule with no extra prerequisites is created) AND a
  warning about this behavior is generated:
warning: ignoring prerequisites on suffix rule definition
  The POSIX behavior will be adopted as the only behavior in a future release
  of GNU make so please resolve any warnings.
___
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

Re: GNU - Principles and Guidelines

[DJ Delorie]

Jean Louis  writes:
> Why should any policy of GNU be changed when they have been
> functioning well for decades?

This argument was used when GPLv2 was introduced, and again with GPLv3.
Things change, we must adapt.  "The old way is good enough" is not a
good long-term policy.

Re: GNU - Principles and Guidelines

[DJ Delorie]

Jean Louis  writes:
> The hypothetical case you wish to present would be dividing GNU
> project and FSF, which also does not make sense.

I agree.

> Please note that RMS is founder of the FSF, and hypothetically, with
> help of few members, could also re-submit the Articles of Association
> of the FSF and could make quite a new FSF structure.

I suggested that that happen, to close this loophole.

> making, in my personal opinion and based on the Massachusets laws
> where FSF was incorporated, RMS could insist on the influence or
> policies of the FSF in such a way, that those hypothetical divisions
> of the GNU project and FSF could be limited, or that other directions
> of the FSF could be controlled as he wish.

So let's amend the policies!  Isn't that what we're all talking about?

> According to US laws on trademarks, that would be very hard. As number
> one, the trademark was meant for GNU project, as I said there are

I didn't say "GNU project" I said "RMS".  If they assigned someone else
do perform that function, they would still - legally, not morally - be
acting in the interests of the GNU project - as they see it.  It would
be horrible and messy and entirely unlikely, but legally they could do
it.  Let's change it!

> To have ownership of trademark is not the power to
> choose the leader,

I did say indirectly.  They can't "choose a leader" but they can empower
someone to effectively become the leader, at least to a degree.  We all
seem to agree this is wrong, but instead of fixing it, we continue
arguing with each other about words.

> I wish you would get advise by attorney.

If the conversation has gotten to this point, both sides have lost.

> I find it actually bad manners that you are hypothetically giving
> readers of this mailing list an opportunity to divide FSF and GNU.

I find it disheartening that you assume that's my purpose.  By exposing
the hypothetical problem, we can solve it before it becomes a real
problem.

> You said, you don't want that to happen, but then again, you are the
> one presenting the opportunity to others.

I doubt they need *me* to see this opportunity.

> GNU leader is not chosen, GNU leader decided himself to create GNU
> project.

The GNU leader himself has already said he's working on how to choose a
successor, though.

Re: GNU - Principles and Guidelines

[DJ Delorie]

Mike Gerwitz  writes:
> The FSF does provide essential resources for the GNU Project, but it has
> no say in how the project is governed.  Those decisions must be made by
> rms.

It's important to remember that one of the "essential resources" is the
GNU trademark itself, which means that the FSF has the final say over
who/what can use it and who/what cannot.  While this "say" is typically
ceded to RMS, that is at the FSF's sufferance, legally.

So - worst case - the FSF could revoke RMS's permission to use the GNU
trademark and effectively remove him from the GNU project.  I don't ever
expect this to happen (and hope it doesn't) but I'm not going to agree
that the FSF has "no say in how the project is governed" when they
legally/effectively have the power to choose the leader.

Perhaps remedying this is something that could be added to the
governance discussion - how the GNU leader is chosen, what powers the
FSF is required to cede, and how to enforce those.

Re: What is a software stakeholder?

[DJ Delorie]

Akira Urushibata  writes:
> The term "stakeholder" requires explanation.

In this case, the original literal meaning isn't as appropriate as the
modern figurative meaning.

https://www.google.com/search?q=define+stakeholder

"2. A person with an interest or concern in something, especially a
business."

In our case, "stakeholders" are all the people who have committed time
and/or resources to helping the GNU project, who have invested of
themselves to make it succeed, and thus have an interest in seeing their
work continue to thrive.

(Amusingly, the (1) definition from above refers to gambling wagers, not
real estate.  Times change.)

Re: Proposals for the new GNU/FSF relationship

[DJ Delorie]

[original mailing lists added back in; your mails make replying
difficult as they do not include the mailing list address]

nylxs  writes:
> On 12/27/19 4:39 AM, Mark Wielaard wrote:
>> As volunteers for the GNU Project we are happy that the FSF provides GNU
>> with services like fiscal sponsorship, technical infrastructure,
>> promotion, copyright assignment, and volunteer management.  And we note
>> that the FSF is looking for feedback on this relationship going forward:
>> 
>>   https://www.fsf.org/news/fsf-and-gnu
>
>
> No that is a lie.

But it's almost word-for-word what the FSF posted on their web site...

Perhaps the wording is simply vague?  You're interpreting it in a way
that benefits you, and he's interpreting it in a way that benefits him,
neither being wrong?

Either way, it's harmful to use harsh words like "lie" when you could
have said "that's not how I interpreted it" or "I think you're
mistaken".  Please try to be more kind in the future.

Re: list moderation

[DJ Delorie]

Alexandre François Garreau  writes:
> Aren’t these two statements contradictory (as governance is made of by 
> people, 
> and currently a single one)? as it was stated before (for instance by Dora)

Consider the difference between "how does the consensus model compare to
the committee model?" and "I think John Doe should be on the committee."

Even at the RMS level, we can discuss "should RMS have more advisors?"
without specifically naming any.

Re: List posting rules

[DJ Delorie]

Marcel  writes:
> I invite you to post _ALL_ my censored messages in chronological order,

If your solution to "I broke the rules" is "post my messages anyway, so
I can get away with breaking the rules"... no thanks.

If you have a problem with the moderation, that's between you and the
moderators.  The rest of us will wait until you can compose a posting
that does not break the rules, to hear what you have to say.

Moderators - please continue doing your job.

Re: gnu-misc-discuss@gnu.org is premoderated

[DJ Delorie]

Jean Louis  writes:
> 2. dictator, potentate -- (a ruler who is unconstrained by law)
> 3. authoritarian, dictator -- (a person who behaves in a tyrannical
> manner; "my boss is a dictator who makes everyone work overtime")

These.  It was Uli at the time.  The experience was very negative.

Re: gnu-misc-discuss@gnu.org is premoderated

[DJ Delorie]

Dora Scilipoti  writes:
> Oh! I thought the conversations here were started to talk about a new
> governance model specifically for GNU.

Well... it's all related, but each sub-project in GNU itself needs a
local governance model, and even if it's different than the top-level
GNU model, they interact, so there's room for discussion there too.

In the glibc case, the topic started when the maintainers couldn't reach
consensus on a change, and we didn't have a way to move forward.
Remember, the glibc case, we have nine stewards (official maintainers),
70 listed maintainers (developers), and 490 copyright assignments.
Running glibc is more complicated than running a small one-developer
project, even if (or especially when) RMS gets involved.

Also remember that glibc is on its third major governance model (I
think) - dictator, committee, and consensus.

Re: gnu-misc-discuss@gnu.org is premoderated

[DJ Delorie]

Dora Scilipoti  writes:
> What if I want to propose a governance model that includes someone as
> head of a committee, for example. Am I not allowed to name and talk
> about the qualities of the person I consider relevant for the position?

*Here* it's reasonable to talk about how the *model* works - a committee
with a singular head, vs for example multiple heads, or no committee at
all.

If you want to *implement* that model in your project, the topic of
which person to choose as committee head belongs in your project's
mailing list.

I think that's an appropriate divide between globally-useful
information, and project-specific information.

Re: GNU project _does_ discriminate contributors by classes (was: A GNU “social contract”?)

[DJ Delorie]

> if a contributor-to-be happens to be an employee, FSF does not trust
> his words about origin of his contribution,

This seems reasonable to me in the USA.  Many companies have a clause in
their contracts that say that the company owns anything the employee
creates during their tenure, *even off hours*.  Given how complex
employment contracts are, it's reasonable to ask for a legal disclaimer
from employers, much like we ask for assignments from contributors.
It's not about trusting the people involved, it's about protecting
against people *not* involved who may have bad intentions, who may take
advantage of honest mistakes.

The FSF has always been careful about legal clarity of their ownership
of GNU contributions; employer disclaimers is just another one of these.

Also consider that some of us might be using the USA legal definition of
"class" here wrt discrimination:

  https://definitions.uslegal.com/p/protected-class/

Defining your own classes outside of those might lead to
misunderstandings.

Re: A GNU "social contract"

[DJ Delorie]

a...@gnu.org (Alfred M. Szmidt) writes:
> They shouldn't be required to defend the GNU projects values, we
> welcome everyone.  And that is on purpose.

I see a problem here... GNU is inclusive to anyone who is willing to be
a dumb code monkey who doesn't care about freedom, but is unwilling to
be inclusive to people who believe in the dream and want to drive it
forward?

I didn't sign up to be someone who "does what you're told and shut up we
don't want your opinion, type faster."  I've spent the last 30 years
contributing because I believed in the dream, can't it be my dream too?

Re: Turning GNU into a bottom-up organization

[DJ Delorie]

Colby Russell  writes:

>   This software might be open source and use the open source development 
>   model, but it won't be free software 
>
> If that's the case, then it has to be true that the four freedoms are 
> necessary but not sufficient to say that a piece of software is free 
> software. 

He was referring to open source software, not Free Software.  The Four
Freedoms on the GNU Philosophy page are followed by this sentence:

"A program is free software if it gives users adequately all of these
freedoms."

Thus, by definition, the Four Freedoms are sufficient.

___
gnu-misc-discuss mailing list
gnu-misc-discuss@gnu.org
https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss

Re: Turning GNU into a bottom-up organization

[DJ Delorie]

Ruben Safir  writes:
>> So the question becomes... what happens if, $diety forbid, RMS gets hit
>> by a bus?  Who does the "appointing" then?  
>
> weel it certainly can't be anyone who makes a public petition to remove
> RMS.  Those people are autmoatically not viable canidates.

There is nothing "automatic" about it.  RMS can appoint whomever he
wants, for whatever reasons, despite your objections, if he feels that's
the best person for the position.  He has shown a remarkable ability to
think rationally and not let emotions get the better of him, unlike most
of the rest of us, and the fact that someone has expressed a contrary
opinion might not be a deciding factor.

But that doesn't answer the question.

> Richard can apoint someone.  When he gets hit by a bus, then worry
> about what to do next.

I, personally, would rather know that there's a plan for "what to do
next" other than "ignore it and let someone else worry about it."

And if you're the one ignoring it, it's likely someone else will make
plans without your input.

___
gnu-misc-discuss mailing list
gnu-misc-discuss@gnu.org
https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss

Re: Turning GNU into a bottom-up organization

[DJ Delorie]

 writes:
> This is already solved. The GNU domain (and many copyrights and right to
> issue new versions of licenses etc.) is held by FSF.

Well, that covers quite a bit.  Not all of it, I assume.  That might be
enough for projects that live 100% in the gnu.org domain, but not all
do.  The ones that do, just need to check that they really are, and the
ones that don't, need a plan.

But I still say that every project should ask themselves the question -
are they covered?  Do they need to do anything to protect their project
from disaster?

Knowing - even if it's the simple "we're 100% on gnu.org" - is better
than sticking your head in the sand and finding out too late that you're
wrong.

___
gnu-misc-discuss mailing list
gnu-misc-discuss@gnu.org
https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss

Re: Turning GNU into a bottom-up organization

[DJ Delorie]

Ruben Safir  writes:
> Appointment has always worked.

In another project I contribute to, there was a conversation about the
project's "bus factor":

https://en.wikipedia.org/wiki/Bus_factor

We tried to restructure the project so that no one role had a bus factor
of one.

RMS is a bus factor of one.

So the question becomes... what happens if, $diety forbid, RMS gets hit
by a bus?  Who does the "appointing" then?  How can we be assured that
the project continues with the same goals as before?

Every GNU project should ask themselves this question too - is there one
person who, if they went MIA, would cause the project undue distress?
Say, a keeper of passwords, or owner of domains?  If so, does the
project have a plan for fixing that?  Appointing a new maintainer will
not magically make secret passwords appear.

But as for the larger topic - RMS does not appoint *everyone*.  As he
noted, he delegates that authority to maintainers.  Historically, he's
had a hands-off approach to the practical day to day operation of the
projects, so for most projects appointing a new maintainer *is not
enough*.  How can a project mitigate this problem?  What needs to be
documented, shared, escrowed, so that a new appointee can just step into
the task and ensure a robust continuation of the project?

Even if we all agree on the "big picture simple answer" the details and
"best practices" are just as important.

Do you have any suggestions for filling in these details?

___
gnu-misc-discuss mailing list
gnu-misc-discuss@gnu.org
https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss

Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories

[DJ Delorie]

"vvs vvs"  writes:
> Ok, now I see that Fedora is just for activists. If I'm not one of
> them then I don't deserve any possibility to use it and should blame
> myself. Thanks for explaining it to me.

I think you're overreacting a bit, but there is some truth in this.
Fedora is created and maintained by the community.  You are part of the
community.  If enough of the community shares your needs, some fraction
of those will step up to do the work, and you all benefit.  If your
needs aren't shared by enough of the community, either you need to do it
all yourself (or pay someone to act on your behalf), or your needs will
never get met.

This has nothing to do with "deserve" or "blame" - it's just numbers.
Most people have switched to 64-bit, so most work is done for 64-bit,
even if not all the 64-bit users are also contributors.

The 32-bit community has shrunk to the point where there aren't enough
contributors to keep the builds building and the fixes fixing, and there
are real problems backing up because of that, even if they don't affect
you personally.  When there are enough problems and no contributors,
what other choice do we have?  It's broken and nobody is fixing it.

Thus comes the hard part of any project - put up or shut up.  Harsh, but
it's the root of how things get done - they get done by people doing
them.  Do or do not, there is no sit-on-the-mailing-list-and-hope.

Back when I started the DJGPP project, I had to do everything myself.
The community grew and there were lots of contributors.  Then the
community shrunk until we're back down to 2 people doing all the work.
Thus is the cycle of projects, but I don't complain that not enough
people are still using DOS :-)

OTOH you won't hurt our feelings if you switch distros.  Go where your
community is ;-)
___
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

Re: i686 hw builders running out of ram in cpio?

[DJ Delorie]

John Reiser  writes:
> Very similar to  https://bugzilla.redhat.com/show_bug.cgi?id=1729382

Ah, thanks.
___
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

i686 hw builders running out of ram in cpio?

[DJ Delorie]

Anyone else seeing this?  It seems to only happen on physical i686
machines, not vm's, but that's based on only three builds so far.

https://koji.fedoraproject.org/koji/taskinfo?taskID=36329825

BUILDSTDERR: create archive failed: cpio: write failed - Cannot allocate 
memory

(this is after the build itself finished, while writing out one of the RPMs)

  totalusedfree  shared  buff/cache   available
Mem:  131924260  899932   105240472201225783856   129959024
Swap:   20971442048 2095096


So far this build has failed on:
  buildhw-04.phx2.fedoraproject.org
  buildhw-02.phx2.fedoraproject.org

but has succeeded on:
  buildvm-30.phx2.fedoraproject.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

Re: DNF remove only?

[DJ Delorie]

Geoffrey Leach  writes:
> A package has been broken and needs to be re-installed. DNF sees the
> package as installed and won't take any action. DNF remove removes
> dependencies, so that's a solution, but requires considerable work and
> is frught with problems.

Use "dnf download" to get the RPM in question, and use RPM to reinstall
it.  Then you have more options.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: why the long pause after bash "command not found"?

[DJ Delorie]

"Robert P. J. Day"  writes:
>   what in the name of mutt is bash doing all that time? if there's no
> such command, why the long pause in giving me a new prompt?

It's probably trying to give you a clue on how to install the right
package to get that command.

Try removing PackageKit-command-not-found if you don't want that
"feature".
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: Need a statement on Fedora's purpose

[DJ Delorie]

ToddAndMargo via users  writes:
> Okay one last slam at RHEL:

As someone who works full-time on RHEL[*], please consider that your
understanding of what RHEL is and who it is for may color your
experience with it.  You are not the ideal RHEL customer, so of course
it doesn't meet your strict needs for constant change, bug-free
operation, and free support.

And perhaps your time is not as valuable to you as it is to the myriad
employees who have to qualify and certify their applications on a dozen
or more operating systems and a wide range of specific hardware
configurations just to make a living, but feel free to self-certify
anything you use if that's what you need, or hire someone to do it on
your behalf.

I hope you find a distro that makes you happy, but please don't consider
other distros to be "bad" just because they aren't right for you.


[*] and Fedora, and upstream, but I officially speak for none of them...
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

[bug #53152] Intermittent timeout running regression test features/output_sync

[DJ Delorie]

Follow-up Comment #2, bug #53152 (project make):

I can reliably reproduce this on Fedora 26 if I have enough busy-wait
processes running, using this command line:

while true; do date; rm mksync; make -j2 -dr; done

and this Makefile:

all: foo baz
foo: bar
date > mksync
bar:
@echo bar
baz:
while [ ! -f mksync ]; do sleep 1; done
@echo baz

Based on the output, it looks like the jobs are queued breadth-first, but only
one at a time actually runs, so the all.baz child runs before the all.foo
child... i.e. with -j2 the first two jobs queued are all.foo.bar (not
all.foo!) and all.baz.  all.foo.bar runs, then all.baz, but all.foo remains
queued until the load is reduced.

I suspect a depth-first search would solve this; the jobs would be queued in
the same order as with -j1... all.foo.bar, all.foo, then all.baz.  However,
that would also mean we'd not parallelize as much as possible.

Alternately, if the job token for the last dependency of a rule could be
reserved for the parent rule - as if the parent got the token, and let its
children "borrow" it, at least the rules *could* be run in the same order as
-j1.

A third option is to test for system load as jobs are queued, so that in this
case all.baz wouldn't even be queued in the first batch.

(yes, I looked at the code; no, I couldn't figure out where to fix anything
;)

GNU Make 4.2.1
Updating goal targets
Considering target file 'all'.
 File 'all' does not exist.
 Looking for an implicit rule for 'all'.
 No implicit rule found for 'all'.
  Considering target file 'foo'.
   File 'foo' does not exist.
Considering target file 'bar'.
 File 'bar' does not exist.
 Finished prerequisites of target file 'bar'.
Must remake target 'bar'.
Need a job token; we don't have children
bar
Putting child 0x55ab69cf95c0 (bar) PID 30261 on the chain.
Recipe of 'bar' is being run.
   Finished prerequisites of target file 'foo'.
  The prerequisites of 'foo' are being made.
  Considering target file 'baz'.
   File 'baz' does not exist.
   Finished prerequisites of target file 'baz'.
  Must remake target 'baz'.
Live child 0x55ab69cf95c0 (bar) PID 30261 
Reaping winning child 0x55ab69cf95c0 PID 30261 
Removing child 0x55ab69cf95c0 PID 30261 from chain.
Need a job token; we don't have children
while [ ! -f mksync ]; do sleep 1; done
Putting child 0x55ab69cf95c0 (baz) PID 30262 on the chain.
  Recipe of 'baz' is being run.
 Finished prerequisites of target file 'all'.
The prerequisites of 'all' are being made.
Live child 0x55ab69cf95c0 (baz) PID 30262 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: nsswitch.conf: list of module packages that enables themselves

[DJ Delorie]

Pavel B™ezina  writes:
> Do you know about any package that installs an nsswitch.conf module and 
> automatically enables it in /etc/nsswitch.conf? So far I have two 
> packages - nss-mdns and systemd.

I don't know about enabling, but it's easy to ask the database what
packages provide NSS modules.  Here's a run from my (sorry, old)
system:

$ dnf whatprovides '/usr/lib64/libnss_*'

sssd-client-1.16.0-4.fc26.x86_64 : SSSD Client libraries for NSS and PAM
Filename: /usr/lib64/libnss_sss.so.2

systemd-container-233-7.fc26.x86_64 : Tools for containers and VMs
Filename: /usr/lib64/libnss_mymachines.so.2

systemd-libs-233-7.fc26.x86_64 : systemd libraries
Filename: /usr/lib64/libnss_myhostname.so.2
Filename: /usr/lib64/libnss_resolve.so.2
Filename: /usr/lib64/libnss_systemd.so.2

glibc-nss-devel-2.25-13.fc26.x86_64 : Development files for directly linking NSS
: service modules
Filename: /usr/lib64/libnss_compat.so
Filename: /usr/lib64/libnss_db.so
Filename: /usr/lib64/libnss_dns.so
Filename: /usr/lib64/libnss_files.so
Filename: /usr/lib64/libnss_hesiod.so
Filename: /usr/lib64/libnss_nis.so
Filename: /usr/lib64/libnss_nisplus.so

libvirt-nss-3.2.1-7.fc26.x86_64 : Libvirt plugin for Name Service Switch
Filename: /usr/lib64/libnss_libvirt.so.2
Filename: /usr/lib64/libnss_libvirt_guest.so.2

samba-winbind-modules-2:4.6.15-0.fc26.x86_64 : Samba winbind modules
Filename: /usr/lib64/libnss_winbind.so
Filename: /usr/lib64/libnss_winbind.so.2
Filename: /usr/lib64/libnss_wins.so
Filename: /usr/lib64/libnss_wins.so.2

sssd-client-1.16.1-4.fc26.x86_64 : SSSD Client libraries for NSS and PAM
Filename: /usr/lib64/libnss_sss.so.2

systemd-container-233-7.fc26.x86_64 : Tools for containers and VMs
Filename: /usr/lib64/libnss_mymachines.so.2

systemd-libs-233-7.fc26.x86_64 : systemd libraries
Filename: /usr/lib64/libnss_myhostname.so.2
Filename: /usr/lib64/libnss_resolve.so.2
Filename: /usr/lib64/libnss_systemd.so.2

glibc-nss-devel-2.25-6.fc26.x86_64 : Development files for directly linking NSS
   : service modules
Filename: /usr/lib64/libnss_compat.so
Filename: /usr/lib64/libnss_db.so
Filename: /usr/lib64/libnss_dns.so
Filename: /usr/lib64/libnss_files.so
Filename: /usr/lib64/libnss_hesiod.so
Filename: /usr/lib64/libnss_nis.so
Filename: /usr/lib64/libnss_nisplus.so

libnss-mysql-1.5-26.fc26.x86_64 : NSS library for MySQL
Filename: /usr/lib64/libnss_mysql.so.2
Filename: /usr/lib64/libnss_mysql.so.2.0.0

libnss-pgsql-1.5.0-0.15.beta.fc26.x86_64 : Name Service Switch library that
 : interface with PostgreSQL
Filename: /usr/lib64/libnss_pgsql.so.2
Filename: /usr/lib64/libnss_pgsql.so.2.0.0

libvirt-nss-3.2.1-3.fc26.x86_64 : Libvirt plugin for Name Service Switch
Filename: /usr/lib64/libnss_libvirt.so.2
Filename: /usr/lib64/libnss_libvirt_guest.so.2

netresolve-core-0.0.1-0.17.20160317git.fc26.x86_64 : Core netresolve libraries
Filename: /usr/lib64/libnss_netresolve.so.2
Filename: /usr/lib64/libnss_netresolve.so.2.0.0

netresolve-devel-0.0.1-0.17.20160317git.fc26.x86_64 : Development files for
: netresolve
Filename: /usr/lib64/libnss_netresolve.so

nss-altfiles-2.18.1-8.fc26.x86_64 : NSS module to look up users in
  : /usr/lib/passwd too
Filename: /usr/lib64/libnss_altfiles.so.2

nss-pam-ldapd-0.8.14-8.fc26.x86_64 : An nsswitch module which uses directory
   : servers
Filename: /usr/lib64/libnss_ldap.so
Filename: /usr/lib64/libnss_ldap.so.2

nss_wrapper-1.1.3-2.fc26.x86_64 : A wrapper for the user, group and hosts NSS
: API
Filename: /usr/lib64/libnss_wrapper.so
Filename: /usr/lib64/libnss_wrapper.so.0
Filename: /usr/lib64/libnss_wrapper.so.0.2.3

samba-winbind-modules-2:4.6.5-0.fc26.x86_64 : Samba winbind modules
Filename: /usr/lib64/libnss_winbind.so
Filename: /usr/lib64/libnss_winbind.so.2
Filename: /usr/lib64/libnss_wins.so
Filename: /usr/lib64/libnss_wins.so.2

sssd-client-1.15.2-5.fc26.x86_64 : SSSD Client libraries for NSS and PAM
Filename: /usr/lib64/libnss_sss.so.2

systemd-container-233-6.fc26.x86_64 : Tools for containers and VMs
Filename: /usr/lib64/libnss_mymachines.so.2

systemd-libs-233-6.fc26.x86_64 : systemd libraries
Filename: /usr/lib64/libnss_myhostname.so.2
Filename: /usr/lib64/libnss_resolve.so.2
Filename: /usr/lib64/libnss_systemd.so.2
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List 

Re: [PATCH] Fix DJGPP LTO with debug

[DJ Delorie]

Richard Biener  writes:
> DJ, did you ever run the testsuite with a configuration that has LTO
> enabled?  I don't see any djgpp results posted to gcc-testresults.
> Quick googling doesn't yield anything useful with regarding on how to
> do actual testing with a cross so I only built a i686-pc-msdosdjgpp
> cross cc1/lto1 from x86_64-linux which went fine.

CC's Andris, our current gcc maintainer within DJGPP.  I know he just
built 8.2 binaries for us, I don't know what his testing infrastructure
looks like.