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: 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: 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: 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: 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: 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: 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: 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: 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

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

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: 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: 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: Guideline change: glibc malloc as the C/C++/Rust allocator

[DJ Delorie]

Jan Kratochvil  writes:
> So why glibc greated an N+1 allocator (by DJ Delorie) instead of just
> importing/using tcmalloc (which is license-compatible with glibc)?

I didn't create an N+1 allocator.  We're still using the Doug Lea
allocator from ancient times.  My recent work added a relatively minor
bit of code that improved performance (which makes alternate allocators
less of a win, and sometimes worse), and we've been working on security
bugs all along, but it's not a "new" allocator by any stretch of the
imagination.

As for replacing it, I/we are not against that in principle, although
that's a glibc topic and not a Fedora topic.  However, keep in mind that
glibc's allocator has been tested against a HUGE collection of software,
compared to other mallocs that might have a much smaller testing
breadth.  To replace glibc's allocator would require a huge testing
effort, and careful consideration of EVERY glibc-specific feature, hack,
hook, and historical divot that Fedora apps might rely on (I'm looking
at you, Emacs).

So if you can prove that some alternate allocator can serve as a
*general* purpose *system-wide* default allocator, and has better
performance (speed, RSS, VSZ, etc) all the time, for all apps in Fedora
(and other Linux distros, and Hurd, etc) that use it, with fewer
security bugs and no missing features... yeah, we're listening.
Patches welcome :-)

I will repeat that this is not really a Fedora topic, and is independent
of the "alternate mallocs in Fedora" topic, which exists for a different
reason.  I'm posting this purely for clarification.
___
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 Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y4SE4ODPMRGSZRSEXHE3QBZIXARPICL2/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

[DJ Delorie]

Michal Schorm  writes:
> Can someone explain me *real quick* what is the multilib good for? - or
> more precisely, why whould anone run 32-bit software on x86_64 OS?

Among other reasons, 32-bit code can be smaller and faster than 64-bit
code for some applications.  When trying to stuff many containers or VMs
into one server, disk and memory space might be overriding
considerations.  There might be old code that isn't 64-bit aware yet,
and the cost of fixing it might not be justified, especially if there's
an on-disk data format that's 32-bit-centric, or if the authors are
unavailable.  Building only 32-bit code cuts your QA time in half if you
have to support both 32 and 64 bit hosts.  You might have optimizations
written in 32-bit assembly, or libraries that are only available as
32-bit versions.  Or you may rely on someone else's 32-bit code that is
closed source, or abandoned.

That doesn't even touch on the continued need for 32-bit embedded
platforms, where 32-bit things on a 64-bit host can be used as a "cross
development" system.
___
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 Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RIYC4LS42YI3JVSGRDW5UUDYIWSZQBOM/

Re: Hiding the grub menu by default on single OS installs

[DJ Delorie]

Hans de Goede  writes:
> 1) . . ., no way to get to the menu

I think this steps over a line we should not cross.

There's a huge difference between HIDING grub's functionality, and
essentially DISABLING it.  While I'm opposted to hiding the grub menu in
general, as long as there's some obvious way to access it, it's only a
small annoyance.

But I boot rarely, and when I do, it's usually because something has
gone horribly wrong and I need as much control over the boot process as
possible to get the system running again.  Making it difficult for me to
even find the tools I need only makes a bad day worse.  And the benefit
of a few seconds of boot time is no benefit at all for me.

And don't say "well you can change it if you want to" if my use case
represents a significant portion of Fedora users.  Do we even know how
many users will end up changing it?  Or would prefer it available?  Vs
how many users really need that extra 1-2 seconds of boot time
reduction?

And don't say "it will show a menu when it thinks you need it" because
that's just plain hubris.  I can pretty much guarantee that its idea of
when *I* need it, does not match *my* idea.

Perhaps boot time is a concern for some Fedora users, like laptops (why
aren't they just sleeping?) or VMs/containers (kickstart can change the
defaults anyway), but for others it's an impedement (servers, desktops).
Let's not go so far to please one group of users that we aggravate
(or even alienate) another.
___
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 Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FH2K4AX7WG5K5BLQCMUHMPSBQAKKYJK3/

Re: Hiding the grub menu by default on single OS installs

[DJ Delorie]

Chris Adams  writes:
> If I know I want the menu (say I need to boot single-user to fix
> something), how would I do that in this setup?

Ah, that reminds me of the good old days of looking up on the internet
which of the many keys on the keyboard gets me into the BIOS setup
menu...
___
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 Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FNNQU6KRGDUSF5OMKXK3JRBEUYG67JMT/

malloc trace/playback for glibc 2.26 and rawhide...

[DJ Delorie]

With glibc 2.26 there's a new per-thread cache in malloc, which
improves malloc performance in general, and hopefully, specifically
for the apps which each of you are most concerned about.  In the event
that you feel it doesn't help, or if you have other concerns about
malloc performance, there's another part of my malloc performance work
that's not in glibc 2.26 - the ability to capture and play back malloc
activity.

I created these tools to help with the malloc performance testing,
since reliably recreating situations I wanted to test was difficult -
especially with apps that interacted with the user, like LibreOffice.
It's also handy for capturing data from apps that are difficult to
configure (think, "requires other hosts to provide services" or "only
happens with my /etc/passwd") and the occasional (gasp!) proprietary
app that cannot be included in a bug report.

Anyway, I've put the patch (suitable for rpmbuild) and tools tarball
(they can run on a separate machine), along with a pointer to a COPR
repo with F26 and rawhide builds of glibc-2.26.90-5 (x86 32/64 only
for F26, ppc64le included for rawhide), here:

  http://people.redhat.com/dj/glibc/

Instructions for using the tools are also there.  The tarball also
includes a sample trace (of /bin/ls ;) to play with.

So, if you think you have malloc-related performance issues, or want
to benchmark a difficult application on different malloc
implementations (the simulator is a regular app, you can LD_PRELOAD an
interposed malloc), please give this a try.

If you think you have an unusual app and want me to consider your
malloc performance in future work, please feel free to send me
(privately, they're huge) a workload to include in my collection :-)

Thanks!
DJ
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable coredumpctl by default

[DJ Delorie]

Zbigniew Jędrzejewski-Szmek  writes:
> You still can restore such behaviour pretty easily. Just set the
> kernel.core_pattern sysctl.

Yup, that's what I do.  Just adding my two cents on Fedora trying to
help me "be a developer" without doing what I need as a developer.

But I typically uninstall abrt too.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable coredumpctl by default

[DJ Delorie]

Jan Kurik  writes:
> Note that coredumpctl is intended as a developer tool,

As a developer, I remove abrt and anything else that redirects cores
away from my development area.  It's really hard to debug a core dump if
you can't find the core file.

Just sayin'
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Installation validation test change proposal: merge USB tests into 'default boot and install', add more environment columns

[DJ Delorie]

> U.S. rural areas? :-D

I'm pretty rural, and even I have good internet.  Maybe we need to
redefine "rural" to be independent of physicality :-)

> Based on feedback from Ambassadors, DVD images may still be useful
> giveaways in regions with less access to bandwidth. I'm not sure what
> to do about that.

Having been through the "mail disks" end of things myself, I can agree
that having *some* way of bulk transferring data to people in need is,
if not mandatory, at least very useful.  However, I would condition that
with "any method that works" - it doesn't need to be an installable
image, for example, as long as the recipient can use it locally to do an
install somehow (for example, a split-up directory tree that, when
combined, makes an nfs-installable repo, would be sufficient).

We'd need to consider how often such disks are needed vs the effort of
making them "pretty" on our end.  For example, if an Ambassador can use
their laptop, or a USB stick, to bootstrap an install (i.e. at an
installfest), then use that machine to install to others... etc.

Just saying, while a cd/dvd/bluray is the easiest thing to mail, it's
not the only option to enable those folks.  We need to balance
stack-of-cds vs bluray vs usbstick vs laptop vs effort on our end vs
what the actual problem is (i.e. "test Fedora" vs "local full repo").

(personally, I think a bootable USB is much more useful than an
installable disc, as long as the USB can store user data and thus not be
transient, but I too have a few older machines that can't boot USB)

> I downloaded djgpp over a second-hand 1200 baud modem in the early 90s.

Me too.  Oh wait... ;-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packaging FPGA bitstreams

[DJ Delorie]

Nico Kadel-Garcia  writes:
> It's certainly a direct violation of the intent of the GPL licensed
> tools that form so much of the base of Fedora's build environment.

The GPL3 no longer requires us to provide tools used to compile such
objects, as long as such tools are general-purpose and used unmodified:

  "The “Corresponding Source” for a work in object code form means all
   the source code needed to generate, install, and (for an executable
   work) run the object code and to modify the work, including scripts
   to control those activities. However, it does not include the work's
   System Libraries, or general-purpose tools or generally available
   free programs which are used unmodified in performing those
   activities but which are not part of the work. For example,
   Corresponding Source includes interface definition files associated
   with source files for the work, and the source code for shared
   libraries and dynamically linked subprograms that the work is
   specifically designed to require, such as by intimate data
   communication or control flow between those subprograms and other
   parts of the work."

We can reject such binaries based on Fedora's philosophy, but we cannot
reject them as violating the GPL.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ltrace FTBFS patch

[DJ Delorie]

> How about 
> https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=rawhide=ltrace

Done, BZ 1347879
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

ltrace FTBFS patch

[DJ Delorie]

Not sure where to send this, but...

From 1280b78688baaf9a576af5a0a0a658fd0f0ea7e4 Mon Sep 17 00:00:00 2001
From: DJ Delorie <d...@rawhide.delorie.com>
Date: Fri, 17 Jun 2016 19:27:55 -0400
Subject: Fix FTBFS due to gcc and glibc updates

- comment out tautological asserts that gcc 6 complains about
- replace readdir_r (deprecated) with readdir
- remove bogus chunk in ltrace-0.7.91-unwind-elfutils.patch

diff --git a/ltrace-0.7.91-tautology.patch b/ltrace-0.7.91-tautology.patch
new file mode 100644
index 000..24ff020
--- /dev/null
+++ b/ltrace-0.7.91-tautology.patch
@@ -0,0 +1,96 @@
+diff -r -U3 -p ltrace-0.7.91.orig/filter.c ltrace-0.7.91.dj/filter.c
+--- ltrace-0.7.91.orig/filter.c2012-12-16 20:53:44.0 -0500
 ltrace-0.7.91.dj/filter.c  2016-06-17 19:07:23.678490985 -0400
+@@ -79,7 +79,7 @@ filter_lib_matcher_name_init(struct filt
+ {
+   switch (type) {
+   case FLM_MAIN:
+-  assert(type != type);
++  //assert(type != type);
+   abort();
+ 
+   case FLM_SONAME:
+@@ -137,7 +137,7 @@ matcher_matches_library(struct filter_li
+   case FLM_MAIN:
+   return lib->type == LT_LIBTYPE_MAIN;
+   }
+-  assert(matcher->type != matcher->type);
++  //assert(matcher->type != matcher->type);
+   abort();
+ }
+ 
+Only in ltrace-0.7.91.dj/: filter.c~
+diff -r -U3 -p ltrace-0.7.91.orig/sysdeps/linux-gnu/proc.c 
ltrace-0.7.91.dj/sysdeps/linux-gnu/proc.c
+--- ltrace-0.7.91.orig/sysdeps/linux-gnu/proc.c2013-10-11 
15:27:11.0 -0400
 ltrace-0.7.91.dj/sysdeps/linux-gnu/proc.c  2016-06-17 18:59:42.333774042 
-0400
+@@ -242,9 +242,10 @@ process_tasks(pid_t pid, pid_t **ret_tas
+   size_t alloc = 0;
+ 
+   while (1) {
+-  struct dirent entry;
+   struct dirent *result;
+-  if (readdir_r(d, , ) != 0) {
++  errno = 0;
++  result = readdir(d);
++  if (result == NULL && errno != 0) {
+   fail:
+   free(tasks);
+   closedir(d);
+Only in ltrace-0.7.91.dj/sysdeps/linux-gnu: proc.c~
+diff -r -U3 -p ltrace-0.7.91.orig/sysdeps/linux-gnu/x86/fetch.c 
ltrace-0.7.91.dj/sysdeps/linux-gnu/x86/fetch.c
+--- ltrace-0.7.91.orig/sysdeps/linux-gnu/x86/fetch.c   2013-10-24 
08:33:35.0 -0400
 ltrace-0.7.91.dj/sysdeps/linux-gnu/x86/fetch.c 2016-06-17 
18:52:33.962842191 -0400
+@@ -523,7 +523,7 @@ classify(struct process *proc, struct fe
+ 
+   default:
+   /* Unsupported type.  */
+-  assert(info->type != info->type);
++  //assert(info->type != info->type);
+   abort();
+   }
+   abort();
+Only in ltrace-0.7.91.dj/sysdeps/linux-gnu/x86: fetch.c~
+diff -r -U3 -p ltrace-0.7.91.orig/sysdeps/linux-gnu/x86/trace.c 
ltrace-0.7.91.dj/sysdeps/linux-gnu/x86/trace.c
+--- ltrace-0.7.91.orig/sysdeps/linux-gnu/x86/trace.c   2012-12-16 
20:53:45.0 -0500
 ltrace-0.7.91.dj/sysdeps/linux-gnu/x86/trace.c 2016-06-17 
18:52:16.699844065 -0400
+@@ -145,7 +145,7 @@ arch_type_sizeof(struct process *proc, s
+   return (size_t)-2;
+ 
+   default:
+-  assert(info->type != info->type);
++  //assert(info->type != info->type);
+   abort();
+   }
+ }
+@@ -158,7 +158,7 @@ arch_type_alignof(struct process *proc,
+ 
+   switch (info->type) {
+   default:
+-  assert(info->type != info->type);
++  //assert(info->type != info->type);
+   abort();
+   break;
+ 
+Only in ltrace-0.7.91.dj/sysdeps/linux-gnu/x86: trace.c~
+diff -r -U3 -p ltrace-0.7.91.orig/value.c ltrace-0.7.91.dj/value.c
+--- ltrace-0.7.91.orig/value.c 2013-10-10 08:43:55.0 -0400
 ltrace-0.7.91.dj/value.c   2016-06-17 19:11:43.441047589 -0400
+@@ -363,7 +363,7 @@ value_set_word(struct value *value, long
+   u.u64 = word;
+   break;
+   default:
+-  assert(sz != sz);
++  //assert(sz != sz);
+   abort();
+   }
+ 
+@@ -414,7 +414,7 @@ value_extract_word(struct value *value,
+   *retp = (long)u.u64;
+   return 0;
+   default:
+-  assert(sz != sz);
++  //assert(sz != sz);
+   abort();
+   }
+ }
+Only in ltrace-0.7.91.dj/: value.c~
diff --git a/ltrace-0.7.91-unwind-elfutils.patch 
b/ltrace-0.7.91-unwind-elfutils.patch
index 6a855a8..3b46a76 100644
--- a/ltrace-0.7.91-unwind-elfutils.patch
+++ b/ltrace-0.7.91-unwind-elfutils.patch
@@ -379,24 +379,6 @@ diff -u ltrace-0.7.91/proc.c ltrace-0.7.91-pm/proc.c
struct library_symbol *libsym = NULL;
while ((libsym = library_each_symbol(lib, libsym,
 diff -u ltrace-0.7.91/proc.c.orig ltrace-0.7.91-pm/proc.c.orig
 ltrace-0.7.91/proc.c.orig  2013-10-23 01:01:15.0 +0200
-+++ ltrace-0.7.91-pm/proc

Re: systemd 230 change - KillUserProcesses defaults to yes

[DJ Delorie]

Lennart Poettering  writes:
> Again, this isn't just work-arounds around broken programs. It's a
> security thing. It's privileged code (logind, PID 1) that enforces a
> clear life-cycle on unprivileged programs.

You're making three invalid assumptions here:

1. You're assuming that such programs are unpriviledged (or undesired)

2. You're assuming that it's PID 1's job to enforce security policy

3. You're assuming that this rule is desired by all users

Fedora as a distro needs to determine which of these assumptions are
valid *for Fedora* and set the defaults accordingly, as well as
determining if/how to give users the freedom to set them differently.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[DJ Delorie]

Lennart Poettering  writes:
> Again, as mentioned before: key here is that permitting user processes
> to stick around after all sessions of the user ended needs to be a
> privilieged concept. It should not be allowed for user code to stick
> around after logout, unless this is explicitly permitted by the admin,
> and this hence needs to be enforced by privileged code.

How many Fedora installs are multi-user these days?  How many
single-user desktops are we afflicting with a "you must ask an admin"
rule, when there is no admin besides the user sitting at the keyboard?

Any rule that tries to split users into "unpriviledged" and "admin" is
short-sighted.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[DJ Delorie]

Lennart Poettering  writes:
> Sorry, but systemd is pretty exactly this: a process babysitter.

It's becoming a user nanny instead.  I wish it would stop trying to
enforce its "my way or the highway" approach to system rules.  I've been
playing whack-a-mole trying to keep up with all the tweaks I need
(assuming I can find them) to let me do what I want to do with my own
machine.

I am not a baby and do not need a babysitter.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

[DJ Delorie]

Tomasz Torcz  writes:
>   Shouldn't that be /usr/lib/distro.repos.d (for distribution-provided

-1

Having such a small amount of information spread all over the filesystem
only makes things harder to manage.  Keeping it in one place means the
whole "where am I getting stuff" question can be answered with one "ls"
without having to ensure that X other directories are empty or
non-conflicting.  Having one directory also means there is no confusion
about search order or override rules.

Fedora is already complicated enough without adding this, and spreading
out the information solves no actual problems.

I'm also going to +1 the suggestion for /etc/repos.d
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: 3D printing SIG

[DJ Delorie]

I'm in, at least for chatting and such.  I've got a Rostock MAX V1 delta
with a custom Repetier 0.92 firmware and a few hardware mods, and use
OpenSCAD, slic3r (modified), and pronterface to drive it.

http://www.delorie.com/photos/3d_prints/
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: CVE-2015-7547 fix for Fedora 21

[DJ Delorie]

Igor Gnatenko  writes:
> Why do you want to build such packages for EOLed distro?

Because he's a nicy guy and it's an important patch?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Self-Reintroduction: DJ Delorie

[DJ Delorie]

I've been around for a while, but as I'm taking on a new role inside
Red Hat, I'll be showing up in different places here and upstream, so
I figured I'd refresh everyone's memory as well as announce the change :-)

For those who don't know me, I'm the creator of the DJGPP project, a
senior engineer at Red Hat for the last 17 years, and a
maintainer/contributor for many upstream projects, including gcc,
binutils, newlib, and gdb.  I was also active in the Fedora ARM
bootstrap project, and wrote the initial (stage 1-3) bootstrap scripts
for it.  I also do electronics, woodworking, and metalworking as
hobbies, so I tend to show up in lots of forums...

In my new role at Red Hat I'll be focusing more on glibc work, so
expect to see me poking my nose around there too now :-)

DJ Delorie
work: d...@redhat.com
personal: d...@delorie.com
fedoraproject: djdelorie
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Self-Reintroduction: DJ Delorie

[DJ Delorie]

> Hey D.J.!

And not to point you out, but I should have clarified this... my first
name really is DJ - it's not Dj or D.J. or DeeJay or any other
variation (although my account names are always lower case dj).  Yes,
I have legal proof of this, and no, I won't share it ;-)

DJ
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: DNF could improve messages about package auto-removal

[DJ Delorie]

> If the package yumdb entry (now dnfdb) says it was installed as a
> dependency

This is the part I assumed was there.

Is there a separate dnf command to list all installed-as-dependencies
that nothing depends on any more?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: DNF could improve messages about package auto-removal

[DJ Delorie]

> > 1) Some magic command to run after remove to remove the now unneeded
> > cruft.
> 
>  The vast majority of users don't care about saving that $0.0001 of disk
> space, so never need or want to run this and don't.

One would hope (assume?) that there's something to keep dnf from
thinking I no longer need Firefox, or emacs, or some other big package
just because nothing else depends on it any more.

It would be disturbing if removing some tiny package caused the whole
rest of my system to be uninstalled...
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why packages sources are NOT mirrored?

[DJ Delorie]

Stephen John Smoogen  writes:
> I would talk with the mirrors in your area and find out why they don't
> mirror it.

Do mirror sites have the option to not include sources? [*]

If so, does letting them have this choice have GPL implications?  I
mean, if they're distributing binaries without making the sources
available via the same site...  (and one of the arguments for that
clause of the GPL was "the user may not be able to access the part of
the internet where you put the sources" - which seems to be the case
here)


[*] granted, they can mirror whatever they want, but I mean, in order to
be listed as an official Fedora mirror and participate in the yum
update network...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: FESCO request to revert password confirmation change in F22

[DJ Delorie]

 Why not? The user surely knows better what a good password is than the 
 software does. If the user picks a crappy password, there's probably a good 
 reason.

You have an alarmingly naive understanding of our user base...

(not that *I* want to give up control of my passwords, but I'm not an
average user)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no

[DJ Delorie]

  So if we truly want to address this feature, we should also disallow
  non-root user password based ssh logins.

 Do I get this right? You want to disallow any remote logins (which 
 nowadays means using ssh)?

No, he means that ssh connections should require a pre-shared key.  My
systems are set up that way, you can't just ssh in from anywhere, you
can only ssh in from machines that have your private key.  If you try
to log in without a pre-shared key, it won't prompt you for your unix
password, it will just fail.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[DJ Delorie]

 and developers deserve a better environment.

No, developers deserve the environment they ask for, not what someone
else thinks is better.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[DJ Delorie]

 Next time, don't be 6 month late if you're going to be flippant.

I, for one, am happy to welcome our new more-reasonable-less-paranoid
overlords.  I've been disabling my firewall for ages, as my machines
are behind an enterprise firewall anyway.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[DJ Delorie]

  I, for one, am happy to welcome our new more-reasonable-less-paranoid
  overlords.  I've been disabling my firewall for ages, as my machines
  are behind an enterprise firewall anyway
 
 that don't apply for a notebook, especially not if the enduser is=20
 connected to a public WLAN and if you think that you are proctected=20
 because a firewall in front of the WAN security is not your bussiness
 
 https://www.google.at/search?q=3Dsecurity+attackers+from+the+inside
 
 * one infected machine inside the LAN
 * vulnerable port open
 * you are done
 
 and no, that is not theory, that happens every single day again and=20
 again and hits people feeling safe because a firewall in front of the=20
 internet until they learn it the hard way
 
 less-paranoid =3D=3D no business in security
 
 before Edward Snowden made informations public a lot of people which=20
 told that things are happening also where called paranoid

I'm aware of all your rhetoric and I'm aware of the security concerns.

If you really want full security, your only choice is to disconnect
from the Internet.  Everything else is a compromise, and I choose to
place my compromise somewhere else than where you choose.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[DJ Delorie]

 So the target audience has shifted from developers to developers who
 don't understand ports, don't like user prompts and are behind
 enterprise firewalls.

Certainly not.  I've never assumed I was an average user.  There are
many different reasons why people might want a more open firewall
configuration, mine is only one of them.

Also, I do understand ports (I've written lots of networking software)
and it would be wonderful if we had a popup that said Your
application foo wants to accept traffic from the Internet, is that
OK? but I understand how difficult that would be to implement.

Fedora is about choice.  My OP on this thread was to show that at
least one person was happy with the new choice when everyone else
seemed to be trying to remove that choice from me.  *Why* I am happy
with that choice is up to me.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[DJ Delorie]

 The best analogy would probably be a condom with a whopping 129024
 holes in it.

That's a horrible analogy, and totally inappropriate for this mailing
list.  Could we please keep this civil and reasonable?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Mozilla enabled ads in Firefox and they're active in Fedora

[DJ Delorie]

 That's also a questionable feature. Such a text box should not send 
 anything before you confirm it.

Perhaps as part of the firewall installation step, the user could be
given a list of sites that their PC may call home to - including
official repos - and let them opt-in or opt-out accordingly.  If we
block, say, *.mozilla.com at the firewall level, there's no chance
that firefox will call home before the user has a chance to set their
preferences.

Of course, we'd need an obvious way to let them opt-in later, after
they've set their preferences, else why doesn't google work? and
why can't I yum update? will become FAQs.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Mozilla enabled ads in Firefox and they're active in Fedora

[DJ Delorie]

 Not every user understands the connection between website does not
 work - firewall configuration

True, which means that we have to use words that they *do* understand.

For extra coolness, a per-user firewall and some way of popping up a
query dialog when they violate a firewall rule.  We detected you're
trying to access *mozilla.com, which is currently blocked due to your
privacy choices.  Would you like to enable access to *mozilla.com at
this time?

Not that I expect such a tool to be practical, if even possible... ;-)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[DJ Delorie]

 For the journal you always keep all log history in it's original
 state

On low-bandwidth systems, like laptops or diskless nodes, it's a
performance hit to generate the log entry in the first place.  It's
really important to be able to configure the system to *generate* a
minimal amount of communications.  Being able to filter the results
later is a separate issue.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The coding in binary code and assembly are necessary currently?

[DJ Delorie]

 The coding in assembly is necessary currently?

Yes, but only for limited cases where a higher level language is
inappropriate or insufficient.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The coding in binary code and assembly are necessary currently?

[DJ Delorie]

 that question makes no sense at all and it's the wrong mailing-list

The question made sense to me, and where else would one discuss
development besides a devel@ list?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd dependencies

[DJ Delorie]

 What's the rationale here? I mean, we have so many dependencies, if
 you want to minimize them, you have a lng way to go...

When I bootstrapped Fedora for ARM way back when, I had to deal with
these dependencies.  A lot.  Finding a minimal set of RPMs to
cross-compile to get a bootable core was very difficult because of
dependencies, and managing the path up to koji was a nightmare.  Even
after that, there were some packages that couldn't be built *at all*
because of circuilar dependencies or dependencies on them.

So, to all of you who say oh well to dependencies... I hate you.

Seriously.  Not only have you made my personal job miserable for a
while, but you demonstrate the worst traits of engineering.  If
there's a problem, you don't hide it or just let it be because we're
used to it.  You *fix* it.  And you make sure it *stays* fixed.  Take
some pride in your work!  Do the best you can!  If you're only willing
to do mediocre work and let problems exist because you can't be
bothered to fix them, then Fedora will at best be a mediocre product.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd dependencies

[DJ Delorie]

 If I saw systemd-filesystem installed, then I would think that
 something needs to be placed into the systemd folder structure,

Perhaps the bug is this: that you need to install a whole other RPM
just to make a directory exist so you can put a file in it.

Why can't the RPM providing the file just make the directory and not
have a dependency at all?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Bugzilla column width - only 80+1 characters!?

[DJ Delorie]

 Welcome to the 21st century!

Do we have different eyes and brains than we did last century?
Because otherwise, excessively wide paragraphs are just as hard to
read now as they were then.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 System Wide Change: Replace Yum With DNF

[DJ Delorie]

 If you have any other suggestions other than keeping the name, we
 will be open to consider them.

My suggestion is to keep the name, but as you're not open to that
option, there's no point in me bothering, is there?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 System Wide Change: Replace Yum With DNF

[DJ Delorie]

 Nothing will change for you, the yum command will still exist for a
 few more Fedora releases,

Which only postpones the problem.

 just as the `service` command that was superseded by systemctl like
 5 releases of Fedora ago exists.

Which is currently annoying me, for the same reason.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 System Wide Change: Replace Yum With DNF

[DJ Delorie]

 Actually it is. The pretty much part is exactly the reason why to
 change the name. If we didn't, a ton of users who are not reading
 this conversation would start filing regression bugs. If we set
 their expectations right, warning them that yum is no more, they are
 far less likely to do so.

The right way to handle this is the way that every other package
handles it.  Detect the no-longer-compatible option and tell the user
that option is no longer available.  That way, the only users who
are ever inconvenienced are the few that are using the obsolete
option.

The wrong way to solve this is to inconvenience *every* user for the
sake of the few who need it.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 System Wide Change: Replace Yum With DNF

[DJ Delorie]

Forcing the users to type a different command name to get exactly the
same functionality only serves to annoy the user.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: advertisement in packaged software (e.g. Firefox)

[DJ Delorie]

 Why do we care about using the Firefox trademark?  We should just
 rename the package.  Debian do that and it hasn't hurt them.

Debian has different core values than Fedora does.  The relevent
Fedora value is this one:

  Friends

  We believe success comes from a strong community, made of people
  from around the world, working together. There's a place in Fedora
  for anyone who supports our values and wants to help. By
  collaborating with each other openly and transparently, and with a
  strong, supportive partnership with our sponsors, we can achieve
  great things.

The Firefox project is part of our community.  If we change their
package and discard their branding, we alienate part of our community.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: advertisement in packaged software (e.g. Firefox)

[DJ Delorie]

 A party who is molesting me with ads and tries to spy on me, hardly
 is my friend.

Those are strong words, and based mostly on here-say.  Even the Fedora
installer molests you with ads for various non-default packages.
Should we ban the installer?  Of course not.

There are specific issues that we are going to be worried about here,
but the key word is worry, not act.  Firefox is proposing a
feature and assuring us that it's safe and respectful.  Until we have
proof (or even evidence) that it's otherwise, we should refrain from
acting prematurely, and instead stick to what our values say we should
do.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fatal flaw in the udev paradigm?

[DJ Delorie]

Can you wildcard the greylist so that modemmanager *never* runs?  I
haven't used a modem in decades but MM keeps mucking with all my
serial-connected toys.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fatal flaw in the udev paradigm?

[DJ Delorie]

 But better yet, mind sharing which toys you have so we can update the
 black/greylists as appropriate?

I make them myself using FTDI chips, usually, and they talk plain
RS-232 using terminal emulators and such:

http://www.delorie.com/electronics/

I also get a lot of eval boards with usb-serial chips on them.

They're plain serial ports, but they're not modems.

IMHO the assumption that every serial port might be a modem is the
wrong assumption these days.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Red Hat and Fedora Working Groups

[DJ Delorie]

 That said,  please don't top-post: [1]

Also, please trim irrelevant material [1]

 [1] 
 http://fedoraproject.org/wiki/Mailing_list_guidelines#If_You_Are_Replying_to_a_Message
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: fedmsg for voting?

[DJ Delorie]

 FWIW, if you log in to https://badges.fedoraproject.org/ and visit
 your profile,

I got Internal Server Error when I tried this...  and now I'm on the
home page, when what I really wanted was to make sure I had nothing to
do with it :-P

 you can opt out of all badge-stuff in one click (Deactivate
 Account).

Does this deactivate your FAS account, or just the badges?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: fedmsg for voting?

[DJ Delorie]

 Oh no!  Sorry about that.  I just tried it too but I couldn't
 duplicate the error.

It worked this time, must have been new-account-mess.

   you can opt out of all badge-stuff in one click (Deactivate
   Account).
 =20
  Does this deactivate your FAS account, or just the badges?
 
 Just the badges.  You won't show up on the badges.fp.o frontpage, or the
 badges.fp.o leaderboard, and the backend awarder won't consider you
 for future badges.  Deactivating your account there has no effect beyond
 the badges systems.

Thanks!  I'm out.

Why wasn't it opt-in in the first place?  We expect that of mailing lists...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning

[DJ Delorie]

 If your package reports disk space usage to users, and bases this on
 filesystem free space, please consider whether it might need to take
 LVM thin provisioning into account.

Perhaps you could include a small code snippet explaining *how* to do
this?  Is there an lvm_thin_statfs() we can use?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 System Wide Change: No Default Sendmail

[DJ Delorie]

I worry about the security implications of mail that would have gone
to root@ being either silently discarded or unknowingly ignored.

If there is no other way to send mail to local users, we should have a
local MTA configured for such.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: SSD cache

[DJ Delorie]

I think this is a bad idea, at least for my setup.  I really don't
want my small expensive boot SSD being beaten to death trying to cache
a multi-terabyte array, especially since I have plenty of RAM that
already serves that purpose (the machine rarely reboots).

At the very least, this feature should be disabled if the SSD is the
boot/root drive.  When SSDs fail, they fail completely, and it's
irresponsible to cause early failure on a drive that's critical for
booting and OS operation.

Also, I think such features should be postponed until/unless there's a
clear and obvious way to configure/disable them that doesn't involve
installing additional packages or editing obscure text files.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[DJ Delorie]

 But these core parts should work for 100 % users. In all cases, which 
 are in scenarios you can imagine. And in 90 % of scenarios you can not 
 imagine. Or in scenarios, which are anecdotal for you.

+1 - anything which reduces the tools we have to repair systems or
 investigate security issues, is a bad thing.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[DJ Delorie]

 And the outputs of these files are the exact same text streams you are
 used to. However, enhanced with a lot of niceties that make them more
 user friendly. For example, you get colors based on the log level, or
 there's a line drawn between reboots. You get the time zone corrected,
 and you get unconditional PID data, you can filter very very easy, the
 data is unfakable and so on.

So, despite what you just said, the output is *not* the exact same
text, and thus not a direct replacement for it?

/me shudders to think of all the sed/awk/perl scripts you're planning
on breaking.

I still vote no on dropping a default /var/log/messages.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: SSD cache

[DJ Delorie]

 it's not going to be shoved down your throat.

I've found this to be untrue in Fedora.

  At the very least, this feature should be disabled if the
  SSD is the boot/root drive.  When SSDs fail, they fail
  completely, and it's irresponsible to cause early failure
  on a drive that's critical for booting and OS operation.
 
 By default, bcache runs a write-through cache -- it only
 caches clean data. If the caching SSD dies, the bcache layer
 can just forward requests to spinning drive. No data is lost.

No, I wasn't worried about the spinny disks.  I was worried about the
SSD itself, in the case where the SSD hosts both boot/root *and* a
cache for, say, a /home array.

  Also, I think such features should be postponed
  until/unless there's a clear and obvious way to
  configure/disable them that doesn't involve installing
  additional packages or editing obscure text files.
 
 Again -- no one is forcing you to use this. It's opt-in.

Please read the /tmp-on-tmpfs thread for an example of what I'm
worried about.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[DJ Delorie]

 i will look at throwing together a script to give us some comparisons
 between the build times on the different arches.

I've already done this, last time it came up...

http://www.delorie.com/arm/koji-compare-build-times.tar.gz
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[DJ Delorie]

  http://www.delorie.com/arm/koji-compare-build-times.tar.gz
 
 HTTP request sent, awaiting response... 403 Forbidden
 2013-07-12 08:53:13 ERROR 403: Forbidden.

wget is blocked unless you're clueful enough to use the -U flag.
Consider it a spot check for smart enough to not recursively download
my entire web server.

The server should have told you that in the error message.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[DJ Delorie]

 i will look at throwing together a script to give us some comparisons
 between the build times on the different arches.

 I've already done this, last time it came up...
 http://www.delorie.com/arm/koji-compare-build-times.tar.gz

Also, I'm running the script now, I'll post results when it finishes,
let's not ALL hit the koji database at the same time ;-)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[DJ Delorie]

 Also, I'm running the script now, I'll post results when it
 finishes, let's not ALL hit the koji database at the same time ;-)

Results here:

http://www.delorie.com/arm/f19-times.html

includes the raw time data from  koji
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[DJ Delorie]

 Stack protector is not a new requirement in Fedora. It's been part of 
 the distribution for years.

xterm has been part of the distribution for years also, but it's not a
release requirement.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

[DJ Delorie]

If at 9:50am on release morning, aliens threatened to blow up the
world if we shipped, we'd certainly do something about it.

But it would be insane to expect us to *document* that we'd do
something about it.

IMHO it's perfectly reasonable for documented policy to simply say
bugs after this point won't stop a release because there are
rational people behind the process to handle exceptional cases, and no
amount of imagined example scenarios make the policy any less
appropriate.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

[DJ Delorie]

 So what you're saying is that you negotiate with terrorists? :-p

Anyone else want to negotiate?

(sorry, couldn't resist ;)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Hardcoded TMPDIR - anywhere else?

[DJ Delorie]

   ## Use $MOZ_TMPDIR if set. Otherwise use /var/tmp instead of /tmp
   ## because of 1GB /tmp limit in Fedora 18 and later.

 It is insane to hardcode /var/tmp.

Considering the comment, they probably think it's insane to put /tmp
in RAM, and since web browsers are often used to download huge files
and /tmp is the default non-hardcoded dir, they're trying to avoid
users complaining about failed downloads.

Note that this is one of the cases the opponents of the tmp-in-tmpfs
change predicted.  No surprise that they want to avoid bug reports due
to unexpected (to the user) behavior, and in fact, this is what the
tmp-in-tmpfs proponents suggested (using /var/tmp) for such cases
anyway.

For reference, see the very long debate about tmp-in-tmpfs.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How do *you* use Fedora?

[DJ Delorie]

I'm WAY out on the bell curve...

I have two PCs.  One of them, the one I sit in front of, has four
monitors (on one Radeon HD card), video capture and playback, digital
and analog audio (digital goes to a surround system receiver, analog
to gaming headphones), an SSD plus a dual-3Tb raid1 all in a hot-swap
bay, and a bunch of other stuff (mostly usb - lab equipment, scanner,
two android devices, etc).  It's a six-core i7 with 24 GB of RAM, and
typically about half the RAM is in active use (the rest is for cache).
I have some guest OSs but don't run them unless I need to, but the PC
itself is up 24/7.

I run fvwm2 across all monitors as one giant screen (the main screen
is not the leftmost screen, and eventually won't be the topmost one
either), and assign two virtual desktops to the local PC.  I tried
gaming under a composited desktop but the FPS dropped so compositing
was dropped too.

The other two virtual desktops are assigned to my other PC, which sits
in the basement and only talks over X and ssh.

I do *not* use any ramdisks or tmpfs.  I also remove abrt as it takes
too long to run if anything crashes (they tend to be BIG crashes).

This setup is used for software development, gaming, EDA, email (10
mailboxes to monitor), web, and as a home (er, office :) theater.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Improving the Fedora boot experience

[DJ Delorie]

 We nowadays live in times where BIOS POST takes 500ms,

HA!  I wish mine was that fast.  With all the different BIOS chips
doing thier own thing for all the add-on cards and peripherals I have,
it takes about 45 seconds just to get to GRUB at all.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Pulseaudio and S/PDIF [was Re: ConsoleKit and esound retirement]

[DJ Delorie]

(subject changed, please strip the [was...] when replying)

 On 13/02/13 10:15 AM, DJ Delorie wrote:
  (well, more like crap, since I still haven't figured out how to
  get pulseaudio to use my digital audio outputs).
 
 Really? It's not that hard. It's either a device or a profile right on 
 the very first tab of GNOME sound properties. If you're using 
 pavucontrol, devices are on the 'Output Devices' tab, profiles are on 
 the 'Configuration' tab. It's rather easier than doing the same thing 
 with ALSA, really.

I know all about those.  I've tried them all.  I've gone through all
the online discussions about how to get digital outputs to work with
pulseaudio.  I've hacked at the config files and tried to trace the
operation.  I've been doing this with every update since pulseaudio
was introduced, and they're all clean installs, not upgrades.  It
worked just fine with ALSA.  I've even run GNOME sound properties,
despite not running a GNOME desktop.  I haven't yet tried F18 though,
because I don't yet have the spare days it takes to do that.

It just doesn't work.

I know the hardware works, because XBMC uses the digital output just
fine (and sounds seriously better).  The motherboard is a Gigabyte
GA-X58A-UD3R although I do have an HDMI-compatible video card (and
yes, I know you have to disable audio on that, the video card is much
more recent than my PA woes).

00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio 
Controller
03:00.1 Audio device: ATI Technologies Inc Barts HDMI Audio [Radeon HD 6800 
Series]
07:00.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 
02)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ConsoleKit and esound retirement

[DJ Delorie]

 Have you tried using Audacious ?

Just did.  No thanks.  /me uninstalls those five RPMs...

 You can set it to classic mode, at which point it user experience is
 identical to xmms.

No, it's not.  It's close enough to fool someone who doesn't use xmms
regularly, but it's different enough to really annoy those of us who
do.

Reminds me of a friend who hates anything gtk-on-windows because it
looks enough like windows that your instinct is to use your windows
techniques, but it's different enough to burn you every time you try
that.

 With the advantage that it uses a modern toolkit,

Disadvantage, if you ask me.  First thing audacious did was spew
random errors to the screen and change my Firefox and emacs cursors.
Then it ask which of the most recent minecraft jar files I wanted to
listen to.  When I finally located my *music* folder in its playlist
chooser, it refused to play my shoutcast streams, instead filling the
log window with more useless errors.  I managed to find one .wav it
would play, and it defaulted to 120% volume which made it sound like
crap (well, more like crap, since I still haven't figured out how to
get pulseaudio to use my digital audio outputs).

All this was before I figured out how to switch it to Winamp mode (not
xmms mode) but it doesn't support all the customization options that
xmms does, so it didn't look or act like xmms.  Plus, the playlist
management system is completely different.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: the need of Offline Updates

[DJ Delorie]

 But, e.g. if openssl is updated for security issues, all dependent
 services need to be restarted. If not, you're still e.g. vulnerable.
 That can't be your wish.

Ah, but if sshd is restarted in the middle of the update, and you
ssh'd into the machine to do the update, it kills the install halfway
through and leaves you with an unusable system until you log in on the
console, clean up the rpm database, fix ssh, and restart it all.  DAMHIKT.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ConsoleKit and esound retirement

[DJ Delorie]

 and change my Firefox and emacs cursors.

And now I have to restart my entire session to reset my gtk themes,
because of one rogue app.  Thanks.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ConsoleKit and esound retirement

[DJ Delorie]

 You have other serious system issues not affiliated with Audacious if
 this is the case.

If I don't run gnome is considered other serious system issues, I
suppose so.

Restarting didn't help, I still had the wrong cursor in emacs and
firefox, but only the emacs and firefox run remotely back to my
display, the local emacs and firefox had the right cursors.  I still
can't figure out how to get rid of the wrong cursor without also
getting rid of the right cursors, so I'm currently *not* using Xcursor
because the theme stuff is so confusing.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ConsoleKit and esound retirement

[DJ Delorie]

 Well, it looks like you aren't running ANY desktop environment,

fvwm2, emacs, firefox, xterm.  Plus a few other things as needed.
This is for two computers running four monitors (one computer is the
local one with the monitors, the other is strictly ssh and remote X,
each computer has its own desktop I switch between).  It's a horror
show each time I upgrade, usually takes a few days to get everything
settled again.

 or at least one that doesn't provide an XSettings manager.

This is the first time I've *heard* of an XSettings manager.

 Did the evil gnome-settings-daemon even get autospawned? Try killall
 gnome-settings-daemon.

I did kill it.  It was running again anyway.  I killed it again and
replaced it with a script that just calls /bin/true :-)

Some of the appearance changed back when I killed the daemon, but I'll
have to reinstall the theme to see if the cursor is fixed.

I have a hard time keeping programs from running xrdb too, I usually
end up renaming that too.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ConsoleKit and esound retirement

[DJ Delorie]

 Hmm, we still have xmms in the repo?

/me is very glad we still have xmms in the repo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Feature Suggestion] UsrMove continued

[DJ Delorie]

 * /root was initially on a root partition because 'root' user should be
 able to login even when all other FS (including /usr) are not mounted.
 Since now it can't do anything without /usr anyway, /root dir don't have
 to be in /.

As an example of why this is a bad idea...

I have a file server that, until recently, had /usr on an LVM so it
could be dynamically resized.  Sometimes, the machine would
unexpectedly reboot and be unable to bring the VGs up.  The repair
scripts were in ~root.  I would boot the rescue disk, ro-mount /, and
run the repair scripts.

If ~root were in the VG somewhere I would not have been able to repair
the system.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Reverting tmp on tmpfs mis-feature

[DJ Delorie]

 2012/8/22 Richard W.M. Jones rjo...@redhat.com:
  broken tmp on tmpfs
 
 Could you give a reason why you think so?

Can we not repeat the VERY long thread on why this is/isn't a broken feature?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel