Re: mingw packaging: equivalent of %cmake_build, %cmake_install macros?

[Eric Smith]

In the fmt.spec you posted, I see
>
> %mingw_cmake -G Ninja  [...]
>
> this means that you are generating ninja build scripts, not Makefiles. If
> you want to use ninja, you should call
>
> %mingw_ninja
>
> after %mingw_cmake -G Ninja.
>
Thanks! That appears to be the right thing for the %build section, I'm not
sure what to do about the install section.

It's not that I WANT to use Ninja, it's that the author of the fmt.spec
used it.

To generate Makefiles, call
>
> %mingw_cmake
>
> without the -G Ninja, and after this
>
> %mingw_make_build
>
I've tried doing that for the mingw build only, leaving the native build
using Ninja. The %mingw_cmake succeeds, bu the %mingw_make_build quickly
fails:

+ /usr/bin/make -C build_win32 -O -j16 V=1 VERBOSE=1
make: *** No targets specified and no makefile found.  Stop.
error: Bad exit status from /var/tmp/rpm-tmp.cEdp0L (%build)

Best regards,
Eric
--
___
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

mingw packaging: equivalent of %cmake_build, %cmake_install macros?

[Eric Smith]

I'm trying to add mingw build support to the fmt package spec. I've done
this previously with the pugixml and zipios packages, and submitted the
spec diffs to the package maintainer of those.. Both packages use cmake.
Both in the %build section use %cmake then %cmake_build, and in the
%install section use %cmake_install. As expert neither on cmake nor on
mingw, I'm somewhat baffled as to why there are %cmake_build and
%cmake_install macros, but no corresponding %mingw_cmake_build and
%mingw_cmake_install macros. Is there some equivalent that just happens to
not be obvious to me? What I found worked for both pugixml and zipios was:

original: %cmake; %cmake_build
original install: %cmake_install
added for mingw build:  %mingw_cmake (and did not add anything equivalent
to %cmake_build)
added for mingw install: %mingw_make_install; %{?mingw_debug_install_post)

Unfortunately this simple attempt failed for fmt. The %mingw_cmake doesn't
cause an error, but also doesn't build fmt. The attempted
%mingw_make_install results in: "make: *** No rule to make target
'install'.  Stop." Perhaps this has to do with the fmt build also using
Ninja, which pugixml and zipios do not.

If anyone can offer advice, it would be much appreciated. I started from
the specs from the packages:

pugixml-1.13-4
zipios-2.2.5.0-7
fmt-10.0.0-3

My modified spec files are at:
http://www.brouhaha.com/~eric/fedora-packaging-test/

Best regards,
Eric
@brouhaha
--
___
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

macro(s) to use in RPM spec for /usr/lib/modules-load.d

[Eric Smith]

What macro(s) should I use in an RPM spec to refer to a directory like
/usr/lib/modules-load.d, which is under /usr/lib even if libdir is
/usr/lib64?  Is there something better than %{_usr}/lib/modules-load.d?
___
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/GBF5WJLTQVSXMHGYGBF3723ZYCWFBR7C/

Re: apitrace, bundled libbacktrace

[Eric Smith]

Resurrecting a very old thread:

On Tue, May 13, 2014 at 11:02 AM, Jakub Jelinek  wrote:

> On Tue, May 13, 2014 at 06:56:40PM +0200, Sandro Mani wrote:
> > apitrace 5.0 bundles libbacktrace, which looks like is living within
> > the gcc sources. libbacktrace is not build as a shared library from
> > the gcc sources, and not packaged.
> >
> > Is it feasible to build libbacktrace as a shared library and ship it
> > in a corresponding package?
>
> No.
>
> > Or should I rather go for a bundling exception request?
>
> I'd say so.


ghdl, a VHDL compiler, can produce better run-time diagnostics if
libbacktrace is available:

https://sourceforge.net/p/ghdl-updates/tickets/54/

Is there (still) a good reason why gcc can't make libbacktrace available as
a shared library?

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

Re: cross-compiler support?

[Eric Smith]

On Mon, Dec 19, 2016 at 3:59 PM, Igor Gnatenko  wrote:

> I found only one cross-compiler in repos -- arm-none-eabi-gcc-cs
>
> But it doesn't work:

This package is compiled in bootstrap mode and used only to solve circular
> build dependency. You don't want to use this package. It's not expected to
> work.
>

I've used that package a lot for cross-development for ARM targets,
especially Cortex-M3 microcontrollers. It's intended for bare-metal
targets, not targets running Linux. I've never had any problem with it that
has anything to do with "bootstrap mode".  In fact, for a cross-compiler,
"bootstrap mode" is the only mode there is, because the normal
bootstrapping process for a native compiler (build new compiler using old
compiler, then build new compiler using new compiler) is completely
inapplicable.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Haskell packaging issue: dnf reports "nothing provides ghc()"

[Eric Smith]

On Tue, Dec 13, 2016 at 4:38 PM, Orion Poplawski 
wrote:

> Actually, you do need some more BuildRequires:
> but I can't reproduce your ghc() issue on EL7 or F25.


Thanks for looking at it! With your suggested BuildRequires, scratch builds
on Koji succeed for both F24 and F25, but the resulting F24 RPM has the
same broken ghc() dependency as my local build. Since there's no reason
that it needs to be built for F24, I'll only plan on pushing updates for
F25 and EPEL7.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Haskell packaging issue: dnf reports "nothing provides ghc()"

[Eric Smith]

I'm trying to package BNFC, a Haskell program to translate labelled BNF
grammars to lexer and parser specifications for common lexer and parser
generators (Alex, JLex, Flex, Happy, CUP, and Bison). I've tried to follow
the Haskell packaging guidelines. My package builds locally, and if I
install it with "rpm -Uvh --nodeps" it works fine.

However, trying to install it normally with dnf reports:
Error: nothing provides ghc() needed by bnfc-2.8.1-1.fc24.x86_64

Are the ghc rpm macros causing a problem due to my package not actually
requiring any other ghc packages to be installed?

I've put my current spec and SRPM at:
https://fedorapeople.org/~brouhaha/bnfc/bnfc.spec
https://fedorapeople.org/~brouhaha/bnfc/bnfc-2.8.1-1.fc24.src.rpm

I am very much a novice with Haskell. I've only just started working
through "Haskell Programming from first principles".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd and dmcrypt/luks question

[Eric Smith]

On Sun, Mar 22, 2015 at 11:17 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 zfs-import-cache.service has After=cryptsetup.target, and
 zfs-mount.service has After=zfs-import-cache.service, so the ordering should 
 be there.

Interesting, I didn't notice that the scripts in github already had
the After=cryptsetup.target added. I'm using zfsonlinux release
0.6.3, which didn't have those lines (added 26-jul-2014 to the repo),
and spent the better part of a day trying to figure out what to add,
and winding up with Wants=cryptsetup.target and
After=cryptsetup.target which I added to my local copies.

 Can you verify with 'systemctl show -p
 Before,After,Wants,Requires,
 WantedBy,RequiredBy ...' that the dependencies are there
 as expected?

# systemctl show -p Before,After,Wants,Requires,WantedBy,RequiredBy
zfs-import-cache
Requires=systemd-udev-settle.service
Wants=cryptsetup.target
RequiredBy=
WantedBy=zfs-mount.service
Before=zed.service zfs-mount.service
After=systemd-udev-settle.service cryptsetup.target systemd-journald.socket


I need to set up a second machine or a VM to experiment on, because I
don't want to keep rebooting the production one.
-- 
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 and dmcrypt/luks question

[Eric Smith]

On Sun, Mar 22, 2015 at 9:15 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 I vaguely recall that zfsonlinux did some very strange things. How
 do the units you are using look?

These are the three that I think are relevant:

  
https://github.com/zfsonlinux/zfs/blob/master/etc/systemd/system/zfs-import-cache.service.in
  
https://github.com/zfsonlinux/zfs/blob/master/etc/systemd/system/zfs-import-scan.service.in
  
https://github.com/zfsonlinux/zfs/blob/master/etc/systemd/system/zfs-mount.service.in

There are a few others, as well as the target, in the same directory:
  https://github.com/zfsonlinux/zfs/blob/master/etc/systemd/system/zfs.target.in

 I tried adding:

 Wants=cryptsetup.target
 After=cryptsetup.target
 This should work, although it's hard to say without looking at
 the units.

Thanks! I'm only just starting to learn my way around systemd.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

systemd and dmcrypt/luks question

[Eric Smith]

I'm using a non-Fedora filesystem (zfsonlinux) which provides
appropriate services and a target for systemd. The services state:

Requires=systemd-udev-settle.service
After=systemd-udev-settle.service

This works fine for basic usage, but if trying to use zfs over
dmcrypt/LUKS, the mount service apparently runs before the LUKS
volumes are opened (based on /etc/crypttab). Also it appears that the
LUKS volumes are closed before the zfs file systems are unmounted at
shutdown.

I tried adding:

Wants=cryptsetup.target
After=cryptsetup.target

to the [Unit] section of the zfs services, but that didn't seem to
help. Can anyone offer advice on how to properly represent the
necessary dependencies?  Ideally it should be done in a way that still
works if the system has no encrypted block devices.

If a suitable solution can be found, I'll be happy to send it upstream
to the zfsonlinux developers. Presumably this would be useful for use
of any other out-of-tree filesystems over dmcrypt.

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

[EPEL-devel] building EPEL7 packages against EL7.1?

[Eric Smith]

Bug #1203649 was reported against dragonegg, which is tied to the
specific version of gcc it is built against, because it uses the gcc
plugin interface. EL7.1 has a newer gcc, so dragonegg has to be
rebuilt. I did a new build (fedpkg build from epel7 branch), but it
still built against gcc from EL7.0. Is there a way to build EPEL
packages against EL7.1?
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] building EPEL7 packages against EL7.1?

[Eric Smith]

On Sat, Mar 21, 2015 at 10:44 AM, Kevin Fenzi ke...@scrye.com wrote:
 It might be this in your spec:

 #%global gcc_vr 4.8.2-16.2.el7_0

 # is not a comment in a spec file. The %global is still expanded.
 Replace % with # or something to make it not do so.

That was it. Thanks for the assistance!
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: systemd and dmcrypt/luks question

[Eric Smith]

On Sat, Mar 21, 2015 at 4:37 AM, Corey Sheldon sheldon.co...@gmail.com wrote:
 did you rebuild the initramfs and /or initrd after this change?

I didn't. I'm not using ZFS on root (or anything else needed during
boot), so I didn't think that was necessary. I'll give it a try.
Thanks for the suggestion.
-- 
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: [EPEL-devel] Python3 vote

[Eric Smith]

On 03/19/2015 05:57 PM, Stephen John Smoogen wrote:
 At the last meeting I promised we would hold a vote on the Python 3 on the
 mailing lists.

+1

Eric
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: IntelliJ

[Eric Smith]

I think it's a great idea. IntelliJ is the basis for the new Android dev
env (though Eclipse can still be used). I looked at trying to package it
again, but as you say it looks like a pretty big task.
-- 
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: EPEL Can 7 packages depend on Software Collections packages?

[Eric Smith]

On Tue, Aug 26, 2014 at 3:08 PM, Stephen John Smoogen smo...@gmail.com wrote:
 No they can not. Every package we ship in EPEL must only rely on what is
 shipped in either EPEL or base RHEL (or CentOS as it doesn't have a ton of
 confusing channels).

OK.  I suppose I should ask the collections people whether a
collection package for EL is allowed to depend on EPEL.

Thanks!
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: Make buildSRPMFromSCM faster?

[Eric Smith]

On Sat, Jul 19, 2014 at 7:12 PM, Richard Shaw hobbes1...@gmail.com wrote:
 On Sat, Jul 19, 2014 at 7:20 PM, Eric Smith space...@gmail.com wrote:
 That could lead to packages that happen to build some of the time due
 to an undetected dependency on something that isn't in the BR but
 happens to be in a cached buildroot.
 I fail to see why this would occur building an SRPM, the dependencies should

Right. A thinko on my part.  Sorry.
-- 
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: Make buildSRPMFromSCM faster?

[Eric Smith]

On Sat, Jul 19, 2014 at 5:30 AM, Richard W.M. Jones rjo...@redhat.com wrote:
 (1) Limit the use of macros in Source lines, so that only a simple,
 standard, perhaps pre-cached buildroot can be used.

How about just trying to parse the Source lines, and if that fails due
to use of macros that can't be evaluated in a simpleminded way, revert
to the method used now?
-- 
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: Make buildSRPMFromSCM faster?

[Eric Smith]

On Sat, Jul 19, 2014 at 7:26 AM, Richard Shaw hobbes1...@gmail.com wrote:
 How about not rebuilding the chroot every time... It's not like you have to
 worry about leftover BR's from building another package.

That could lead to packages that happen to build some of the time due
to an undetected dependency on something that isn't in the BR but
happens to be in a cached buildroot.
-- 
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: Adding pkg-config not provided by upstream when packaging a library?

[Eric Smith]

On Mon, Jun 16, 2014 at 12:57 AM, Kalev Lember kalevlem...@gmail.com
wrote:

 Otherwise it could create a situation where software developed
 on Fedora relies on .pc files and doesn't work on other distros, and the
 other way around: software developed on other distros won't use the nice
 pkg-config integration available on Fedora.


Obviously I can't speak for what other distributions are likely to do, but
I'd expect there to be a not entirely trivial chance that other
distributions that use pkg-config might use our .pc files if upstream
doesn't provide them.

I don't think it's breaking compatibility in any real sense anyhow; in the
absence of .pc files, porting some package that uses this library to or
from another distribution is still going to require mucking with the
Makefile to do the same thing.  Having a .pc file doesn't make that any
more difficult.  But I accept that my opinion on this is apparently in the
minority.


 so please
 don't be discouraged here, just go through the upstream process. :)


Um, no.  I'm not about to waste time trying to convince anyone at Intel to
add that to their library. They expect it to be statically linked with an
application.  If someone else feels like tilting at windmills and trying to
convince Intel, more power to them.  I'll just remove the .pc files from my
package.  The only reason I'm trying to package it as a shared library at
all (contrary to upstream's expectations) is that there wouldn't really be
any good reason for FPC to grant a bundling exception.

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

Adding pkg-config not provided by upstream when packaging a library?

[Eric Smith]

Because a new version of the Free42 calculator has switched to the Intel
decimal floating point library (an implementation of the decimal part of
IEEE-754), I'm working on packaging it:

https://bugzilla.redhat.com/show_bug.cgi?id=1098820

Intel supplies it as portable code intended to be linked directly with an
application, and builds and tests all 16 combinations of four binary
compile-time options, with the name of the resulting library based on the
values of those options.  It is essential that the program making use of
the library use the correct defines to match the specific library variant
being used.

When I've packaged other libraries for Fedora that didn't include
pkg-config files, it seemed desirable to add them.  However, in this case
Michael Schwendt commented in the package review that I am adding to the
API here, and that it results in incompatibilities.

Since there are sixteen variants of the library, I am providing sixteen
corresponding pkg-config files.  When another program uses the library, by
using pkg-config in their Makefile (or other build system), it will ensure
that they are getting the right C preprocessor defines for the chosen
library variant.

I don't really understand how this is adding to the API or results in
incompatibilities.  Do other people think that doing this is a mistake?
Would it actually be better for the package not to provide pkg-config files?

Thanks!
Eric
-- 
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: Adding pkg-config not provided by upstream when packaging a library?

[Eric Smith]

-- 
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: Adding pkg-config not provided by upstream when packaging a library?

[Eric Smith]

On Sun, Jun 15, 2014 at 4:16 PM, Kevin Kofler kevin.kof...@chello.at
wrote:

 Eric Smith wrote:
  I don't really understand how this is adding to the API or results in
  incompatibilities.  Do other people think that doing this is a mistake?
  Would it actually be better for the package not to provide pkg-config
  files?

 The reason we do not recommend adding non-upstream pkg-config files is that
 software developed on Fedora then starts relying on those .pc files being
 present and does not work on any other distribution. Those added .pc files
 are useless for portable software.


I don't see that it's any more useless than having to hack up Makefiles in
some other way to do the equivalent, but if that's the policy, I'll remove
them.

Thanks,
Eric
-- 
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: Orphaning drgeo, drgeo-doc

[Eric Smith]

On Thu, Jun 12, 2014 at 12:05 PM, Yaakov Selkowitz yselk...@redhat.com
wrote:

 IMHO it would be nice if this could stay in, but I'm not a Fedora packager
 (yet? :-).

FWIW, I just posted a patch for the FTBFS:


I'll take over the 1.x pre-smalltalk package, incorporate your patch
(thanks for that!), and otherwise try to maintain the package.  If you
become a Fedora packager, you are welcome to take it over from me.

I'm also willing to try to package the 2.x (Smalltalk) version.  Squeak is
already in Fedora, and I have a little bit of Smalltalk experience, but no
experience with packaging Smalltalk programs.  Perhaps if I run into
trouble I might be able to get some assistance from the Squeak package
maintainer(s).

Eric
-- 
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: Qt packages necessaries to develop for Android

[Eric Smith]

On Tue, Jun 10, 2014 at 5:49 PM, Kevin Kofler kevin.kof...@chello.at
wrote:

 Hunting for patents is one thing (I wouldn't recommend it either), but
 looking for obviously patent-encumbered stuff (like MP3 codecs) is another
 .


Unfortunately it is generally not obvious what things are obviously
patent-encumbered.
-- 
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: Qt packages necessaries to develop for Android

[Eric Smith]

On Mon, Jun 9, 2014 at 10:50 AM, Isaac Cortés González 
w.isaac.cor...@gmail.com wrote:

 So, should I just clone the git repositories and build from those raw
 sources?


Sounds reasonable 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: Qt packages necessaries to develop for Android

[Eric Smith]

On Sun, Jun 8, 2014 at 8:36 PM, Isaac Cortés González 
w.isaac.cor...@gmail.com wrote:

 I can look for any patented or closed source software


IANAL, but multiple lawyers have told me that it is generally a bad idea to
go looking for patents, at least in the US.  If they're brought to your
attention, you should probably do whatever is necessary to avoid them, but
you shouldn't actively seek them out, even just to try to confirm that
you're not using anything patented.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Request for comments regarding default configuration of pam_abl module

[Eric Smith]

In bug #1079767, it is requested that the default configuration for pam_abl
be changed such that multiple root login failures from a network host will
(temporarily) blacklist that host.  The existing default configuration
deliberately does not do that, due to potential for a Denial of Service.
For example, in a classroom or lab, students might try to log into a server
as root, and failures could prevent the instruction from being able to do
so from the same machines in the lab.  Another scenario would be a
miscreant breaking into one machine on a network, that happens to be used
to ssh into another machine on the network, and getting that first machine
blacklisted.

I understand the motivation to blacklist malicious hosts that try
dictionary attacks against root, but I don't like having the default
configuration susceptible to a DoS.  My feeling is that the default
configuration provides some value, but that the system administrator should
make the choice as to whether to tighten the rules and potentially have a
DoS issue.

I'm interested in hearing in opinions of other developers, before making a
decision about the proposed change.

Thanks!
Eric
-- 
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Eric Smith]

On Fri, Mar 21, 2014 at 8:07 PM, Lennart Poettering mzerq...@0pointer.dewrote:

 You do realize that if software engineering has shown something then
 yes, software development is never finished, it's a process. You do need
 maintains for such things.


The software in my microwave oven, coffee maker, thermostat, DVD player,
stereo receiver, and many processors in my car (including engine control,
antilock brakes, and many others) is quite definitely finished.  That's not
to say that there aren't any bugs, but the vendors aren't sending me any
updated versions.  That's an existence proof that software *can* be good
enough and not need updates.  Granted, most software is not good enough,
but the lack of updates to a piece of software is not sufficient to
establish a priori that the software should be discarded.
-- 
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: LinuxCNC RTAI kernel

[Eric Smith]

On Feb 12, 2014 4:54 PM, Christopher Meng cicku...@gmail.com wrote:

 2014-2-12 PM6:32于 Sandro Mani manisan...@gmail.com写道：

  By the way, concerning OpenCASCADE, this would also open up the
possibility for packaging Code-Aster and Salome for Fedora. I once started
looking at packaging them, but stalled of since it's quite an effort.
Anyone else interested in joining the effort?

 Eric Smith is packaging it already.

I asked on the Fedora Legal list whether it was OK to package it with the
new license, and the answer was yes. I worked on an RPM, but several people
suggested that it would be better to wait for OCE (downstream) to be
rebased on the new OpenCASCADE release, and the OCE package to be moved
from RPM Fusion into Fedora.

Previously I had been unaware of the existence of OCE. Since there are
already packages in RPM Fusion using it, which may also be able to move
into Fedora after OCE does, I abandoned packaging my own RPM for
OpenCASCADE.

I don't know how long it will take for OCE to make it into Fedora. If other
developers don't want to wait for that, I could resume my efforts or
collaborate with other developers to finish an OpenCASCADE package.
However, then we'd likely end up with two forks in Fedora, which seems
somewhat undesirable.

Richard Shaw is the OCE package maintainer. He just emailed me today about
it. At the very least, if anyone does work on packaging OpenCASCADE, it
would be worthwhile to try to somehow coordinate things with him to try to
have an orderly transition plan, since OCE is probably the preferred
long-term solution. As Richard points out, OCE has a better (more
maintainable) build system.

Eric
-- 
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: LinuxCNC RTAI kernel

[Eric Smith]

I wrote:
 but several people suggested that it would be better to wait for OCE
(downstream) to be rebased on the new OpenCASCADE release, and the OCE
package to be moved from RPM Fusion into Fedora.

I see that OCE 0.15 was released yesterday, and is now based on the
upstream OpenCASCADE 6.7.0, which is the LGPL version, so my guess is that
it shouldn't take too long for the RPM Fusion OCE package to be updated and
submitted for review as a Fedora package.

Eric
-- 
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: OpenCASCADE and applications depending on it (was: LinuxCNC RTAI kernel)

[Eric Smith]

On Feb 13, 2014 4:29 PM, Sandro Mani manisan...@gmail.com wrote:
 On 14.02.2014 00:12, Eric Smith wrote:
 but several people suggested that it would be better to wait for OCE
(downstream) to be rebased on the new OpenCASCADE release, and the OCE
package to be moved from RPM Fusion into Fedora.

 Christopher mentioned that you also were looking at Salome / Code Aster:
how far did you get?

I was looking at OpenCASCADE and FreeCAD, but not Salome. There was
probably someone else looking at that.

Eric
-- 
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: Fedora.next in 2014 -- Big Picture and Themes

[Eric Smith]

On Jan 23, 2014 2:33 PM, Kevin Fenzi ke...@scrye.com wrote:

 On Thu, 23 Jan 2014 19:03:02 +0100
 Thorsten Leemhuis fed...@leemhuis.info wrote:
  I'm still undecided if I overall like Fedora.next or fear it. But more
  and more I tend to the latter position and wonder if it might be wise
  to slow things down: Do one more Fedora release the old style in round
  about June; that would give us more time to better discuss and work
  out Fedora.next and get contributors involved better in the planing.

 This is not practical. Lots of people are thinking about a
 fedora.next, qa folks are coding away, lots of people who normally
 would be working on the next release are not. If we tell them to stop
 all that and go back to normal, we could, but then fedora.next will
 likely never ever happen.
[...]
 The current problem I have with Fedora.next is that it's so abstract.

How are QA folks coding away for Fedora.next, rather than traditional
Fedora QA processes, if Fedora.next is so abstract?

I still don't understand what the Fedora.next Products accomplish that
Spins don't/can't.

Eric
-- 
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: Fedora.next in 2014 -- Big Picture and Themes

[Eric Smith]

On Jan 24, 2014 10:29 AM, Kevin Fenzi ke...@scrye.com wrote:
 The things they are working on have been known for years, but our 6
 month release cycle with no hope of being able to work on tooling
 hasn't allowed them to do so.

Thanks for the clarification. I'm certainly on board with lengthening a
release cycle to give them opportunity to improve the QA infrastructure,
irrespective of Fedora.next.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

trouble with library dependency when main package depends on -libs subpackage

[Eric Smith]

I'm having a bit of trouble with RPM dependencies.  I'm trying to package
faifa, which manages HomePlug AV interfaces.  There's a library (libfaifa)
and two executables, faifa and hpav_cfg.  I'm putting the executables in
the main package (faifa), the shared library in a -libs subpackage, and the
headers in a -devel subpackage.  I have both the main package and -devel
subpackage depending on the -libs subpackage, both using the line:

Requires:   %{name}-libs%{_isa} = %{version}-%{release}

When I attempt to install the main package, it says that there's an
unsatisfied Requires: libfaifa.so.0()(64bit) even if I already have the
-libs subpackage installed.

I'm sure I've overlooked something in the packaging guidelines and other
relevant documentation, but I can't seem to figure out how to fix this.
Any assistance will be much appreciated. My spec and SRPM are at:
http://fedorapeople.org/~brouhaha/faifa/

Thanks!
Eric
-- 
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: trouble with library dependency when main package depends on -libs subpackage

[Eric Smith]

The problem was that it was non-executable.  Thanks for the help!


On Fri, Nov 29, 2013 at 2:13 PM, Michael Schwendt mschwe...@gmail.comwrote:

 On Fri, 29 Nov 2013 13:26:20 -0700, Eric Smith wrote:

  I'm having a bit of trouble with RPM dependencies.  I'm trying to package
  faifa, which manages HomePlug AV interfaces.  There's a library
 (libfaifa)
  and two executables, faifa and hpav_cfg.  I'm putting the executables in
  the main package (faifa), the shared library in a -libs subpackage, and
 the
  headers in a -devel subpackage.  I have both the main package and -devel
  subpackage depending on the -libs subpackage, both using the line:
 
  Requires:   %{name}-libs%{_isa} = %{version}-%{release}
 
  When I attempt to install the main package, it says that there's an
  unsatisfied Requires: libfaifa.so.0()(64bit) even if I already have the
  -libs subpackage installed.
 
  I'm sure I've overlooked something in the packaging guidelines and other
  relevant documentation, but I can't seem to figure out how to fix this.
  Any assistance will be much appreciated. My spec and SRPM are at:
  http://fedorapeople.org/~brouhaha/faifa/

 Query the built packages with rpm. Verify the Provides in the -libs
 package. Use rpmls to display the contents of the -libs package.
 Make sure the shared lib is executable at the end of %install.
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk)

[Eric Smith]

On Thu, Jul 25, 2013 at 12:57 PM, Reindl Harald h.rei...@thelounge.net wrote:
 if that would be the case i would not run Apache 2.4, and Zend Opcache
 in production on Fdora 17

I wouldn't run *anything* in production on Fedora 17. That's what the
downstream enterprise distributions are for.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk)

[Eric Smith]

On Thu, Jul 25, 2013 at 4:14 PM, Adam Williamson awill...@redhat.com wrote:
 On Thu, 2013-07-25 at 16:04 -0600, Eric Smith wrote:
 On Thu, Jul 25, 2013 at 12:57 PM, Reindl Harald h.rei...@thelounge.net 
 wrote:
  if that would be the case i would not run Apache 2.4, and Zend Opcache
  in production on Fdora 17

 I wouldn't run *anything* in production on Fedora 17. That's what the
 downstream enterprise distributions are for.

 We've been through this rodeo a few days ago. There's a solid body of
 opinion that your statement is going too far. Many of us run
 'production' systems of various types on Fedora. (All of
 happyassassin.net runs on Fedora, FWIW).

And what are you going to do for security updates on Fedora 17?  Live
without?  Backport and rebuild everything yourself?

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk)

[Eric Smith]

On Thu, Jul 25, 2013 at 4:54 PM, Reindl Harald h.rei...@thelounge.net wrote:
 i really do not justify my decisions inside support cycles
 because *you* quote out of context and sound like booh nobody
 is running Fedora in production

And I didn't say that nobody is running Fedora in production.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: EPEL (was Re: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk))

[Eric Smith]

On Mon, Jul 22, 2013 at 10:52 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
 On 07/22/2013 04:41 PM, Stephen Gallagher wrote:
 They chose to use a _downstream_ distribution. RHEL *is* Fedora, it's
 just a Fedora that's been hardened and held to a certain level of
 ABI/API compatibility.
 Which is my point exactly instead of helping increasing the overall quality
 of Fedora the infrastructure decide to run to another distribution.

 RHEL != Fedora

But it's not an objective of Fedora to have long-term-stable releases
suitable for running servers!  No one in their right mind runs any
rapid development distribution (not just Fedora) on critical
infrastructure.

If you think Fedora should somehow transition into being a good
distribution for critical infrastructure, you'll have to propose some
radical changes to Fedora to make that happen.

It is a Good Thing that RHEL != Fedora. If RHEL did rapid development
instead of long term stable, people wouldn't buy it.  If Fedora did
long term stable instead of rapid development, we'd need yet another
distribution to do the rapid development.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Jul 18, 2013 12:22 AM, James Hogarth james.hoga...@gmail.com wrote:
 Oh how do you get your logs to read in windows from your lvm/ext4/btrfs
filesystems currently in a disk boot scenario?

Using ext2fsd:
http://www.ext2fsd.com

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Thu, Jul 18, 2013 at 1:56 AM, James Hogarth james.hoga...@gmail.com wrote:

  Oh how do you get your logs to read in windows from your lvm/ext4/btrfs
  filesystems currently in a disk boot scenario?

 Using ext2fsd:
 http://www.ext2fsd.com


 ... I'd suggest you read that page and then look at my question and think
 real hard...

Maybe your question is poorly stated, then.

What I thought you asked was how to read Linux log files from a
Windows installation, e.g., when Linux fails to boot.  In the past
I've been able to do that using ext2fsd without much difficulty. I
used that method when I wasn't able to boot a rescue or live CD, and
the last resort would have been to pull the hard drive from the
machine and use a different computer to inspect it.   But if
/var/log/messages is not made available by default, then using ext2fsd
won't work, and other methods become more difficult also.

My main complaint is that removing the default syslog to
/var/log/messages makes it harder for me to diagnose broken machines
that OTHER people have set up, because those other people aren't going
to have installed a non-default syslog daemon.  Certainly if it's a
machine I'm installing, I'll know to install syslog.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Thu, Jul 18, 2013 at 9:54 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
 Why not read this files on another Fedora host ( or some other distro that
 uses systemd )?
 What's the reason for this hard dependency on Windows?

Because I was about six hundred miles away from my office, didn't want
to take the user's computer apart if I could avoid it, and didn't have
a drive dock to hook up the user's drive to my laptop.  The user had
Windows available on the machine, so I took advantage of it to figure
out what was wrong with Linux and fix it.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Thu, Jul 18, 2013 at 10:11 AM, James Hogarth james.hoga...@gmail.com wrote:
 Then you were not using it with a default installed Fedora anyway which has
 a default of LVM in place

I don't remember why there wasn't LVM. I don't remember whether I was
the one that installed Linux on that machine in the first place.  I
might have been.

 That or live media is the best option in general... I know above you said
 you couldn't use a live CD and I'm quite curious as to why.

The machine didn't have a working optical drive.  If I'd had a live
image on USB that probably would have worked.  If I hadn't been
hundreds of miles from the nearest computer store, I'd have just
bought another optical drive, or a drive dock, or a cable to use the
optical drive out of my laptop, or any number of things that would
have made it easier to solve the problem.  I was motivated to try to
solve it using only what happened to be at hand.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Wed, Jul 17, 2013 at 8:32 AM, drago01 drag...@gmail.com wrote:
 On Wed, Jul 17, 2013 at 3:58 PM, Denys Vlasenko dvlas...@redhat.com wrote:
 Progress happens by removing stuff which works?
 Yes and replacing it by stuff that's better.
 You know people know use cars rather then horses. Not because horses
 stopped working but because cars turned to be better at the job.


That happened because end users chose that for themselves, not
because a few elite people said cars are better, so we're going to
make people jump through extra hoops if they want to keep using the
horses they already have.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Wed, Jul 17, 2013 at 8:39 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
 Allowing editing of log files is a pure security risk...

So is giving a sysadmin the root password, but we do it.

I generally make a copy of a log file and edit the copy, but I'd
oppose anything that took away the ability for log files to be edited.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Tue, Jul 16, 2013 at 2:06 PM, Chris Adams li...@cmadams.net wrote:
 I don't like things that have differing
 behavior between a TTY and a pipe.

I don't either, but that battle was lost many years ago with the 'ls'
command, which defaults to columnar output to a tty but not to a pipe.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin

[Eric Smith]

On Tue, Jul 16, 2013 at 2:22 PM, Reindl Harald h.rei...@thelounge.net wrote:
 /bin/sh is *not* a bash script
 /bin/sh is *whatever* your default shell would be

I certainly hope not.  I've worked on plenty of Unix machines where
the default shell was csh or tcsh, but if /bin/sh had been csh or a
link to it, all hell would have broken loose.

/bin/sh had bloody well better be something that is compatible with
the Bourne shell.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Tue, Jul 16, 2013 at 6:13 PM, Matthew Miller
mat...@fedoraproject.org wrote:
 On Tue, Jul 16, 2013 at 08:58:40PM -0400, Ding Yi Chen wrote:
 You still have not addressed the third party programs and scripts
 that monitor /var/log/messages
 A) If someone is installing a program that expects this file, they can also
 install rsyslog.

So? The same argument could be made for programs that expect the binary journal.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Sendmail

[Eric Smith]

+1 for this proposal.

One of the first steps I take after installing Fedora on a new machine
is to remove the MTA. It would be nice for this to be the default.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

I vote against this proposal as stated.

I want all the systems I administer to have a /var/log/messages
without any special configuration having to be done.  I don't care
whether /var/log/messages is written by syslog or systemd journal, as
long as it has essentially the same text-based format as presently
provided by syslog, but having to take a manual step to configure
systemd journal to produce it is unacceptable.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Sendmail

[Eric Smith]

On Mon, Jul 15, 2013 at 11:50 AM, DJ Delorie d...@redhat.com wrote:
 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.

Even with an MTA installed, the default was for mail to root was to be
unknowingly ignored.  With no MTA installed, at least a program that
tries to send mail to root can discover that it failed, and log
something to syslog (or systemd journal, or something), though that's
arguably what it should have been doing in the first place rather than
sending mail to root.  In my experience it is far more common for a
sysadmin to look at the syslog on a machine than to mail delivered to
root on that machine.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Mon, Jul 15, 2013 at 12:01 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
 (Just to mention this: we are neither the pioneer on the
 no-default-syslog feature nor on no-default-sendmail... A lot of other
 distros stopped installing an MTA by default a long time ago --
 including Ubuntu since 2007 or so -- and some others have switched to
 only-journal mode already too -- for example ArchLinux

 So, we are just following on these ones, on the sendmail thing even with
 a 6 year lag...)

I can see advantages to not having an MTA by default, but I don't see
the advantage in not having /var/log/messages.  I don't want to have
to use special tools in place of a text editor, grep, etc.  As I said
elsewhere, I don't care whether /var/log/messages is written by syslog
or by systemd, but the default should still be to provide it.  It's
fine by me if the default is to generate a binary journal IN ADDITION
to /var/log/messages.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

 One process less in the system → faster bootup.

As has been pointed out, it could easily be the systemd journal
process that writes to /var/log/messages, so there wouldn't
necessarily be one fewer process.

 Logs not duplicated → less disk usage.

True. So keep /var/log/messages and make the binary journal optional.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Mon, Jul 15, 2013 at 2:40 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
 We created the journal with real
 usecases in mind, and we are not giving those up.

I don't actually care whether there's a binary journal or not, but far
more of us have real usecases for /var/log/messages, so we shouldn't
give up that being available by default.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Mon, Jul 15, 2013 at 2:43 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 So removing the binary journal has huge downsides.

I don't dispute that removing it would have a downside.  I might
dispute that the downside is huge, but for now I'll let that pass.

 The need for
 /var/log/messages filters down to wanting to use less or shell
 built-ins to read the data, which is a valid usecase, but not
 worth the overhead in 99% of cases.

But it's what people actually use in 99.9% of cases.  99.9% of the
time I don't need the extra information in the binary journal.  Making
/var/log/messages unavailable by default has a huge down side.

If we go to having only binary logs by default, maybe we should also
go to having only binary configuration files by default.  It's
basically the same arguments: there's more information available; it's
easier for software to parse; it can be made more reliable; special
tools are OK and people don't really need to open it in a text editor.
 We've seen how well that works on Windows.  Blech.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Mon, Jul 15, 2013 at 2:53 PM, Matthew Miller
mat...@fedoraproject.org wrote:
 I just want to look at the file without having to learn to type journalctl
 isn't very compelling to me, even though I do recognize the change cost.

 However, the diagnostic value of an easily-accessible /var/log/messages is
 pretty high

How are those two statements not contradictory?  Either an
easily-accessible /var/log/messages is of high value, or it isn't.

 and I think there are real use cases there. I'm not convinced
 that this needs to be at the minimal level, though, and I'm not sure it
 should be the default for the desktop case, either.

 And, in other cases, you're probably customizing your package install set
 anyway, right? (And, probably logging to a remote host.)

On the desktop is exactly where I think it's important to keep
/var/log/messages.  On servers it is expected that sysadmins will do a
lot of unique configuration.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Mon, Jul 15, 2013 at 3:06 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
 It's a matter of finding the right balance: i.e. what can be text files,
 and where we have to win more by making it binary. I am pretty sure this
 is a case where we win more by sticking to binary files. It's totally
 fine if you disagree on this, but I'd still like to ask you to think
 about whether your specific usecase and specific requirements are strong
 enough to (continue to) be the default for Fedora, instead of just being
 your local configuration of Fedora.

 I mean, you should never forget that on your own machines everything
 will stay as is: you will install syslog, and things will be exactly as
 before.

I have thought a lot about usecases, and it's exactly because I have
to maintain other people's systems that use the default installation,
and I routinely have to use more, less, cat, grep, vi, etc. on
/var/log/messages that I don't want to see it go away.  It's far
easier for me to tell someone a grep command on the phone than to also
have to tell them to run some other tool and pipe the input into grep,
or into a temp file that I can have them look at in an editor.
/var/log/messages is there, it works, and it is BETTER than a binary
format even if it doesn't contain as much information.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Mon, Jul 15, 2013 at 3:06 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
 On Mon, 15.07.13 14:53, Eric Smith (brouh...@fedoraproject.org) wrote:
 If we go to having only binary logs by default, maybe we should also
 go to having only binary configuration files by default.  It's
 basically the same arguments: there's more information available; it's
 easier for software to parse; it can be made more reliable; special
 tools are OK and people don't really need to open it in a text editor.
  We've seen how well that works on Windows.  Blech.

 Nobody is proposing this.

Nobody is seriously proposing it, yet no one has given much
explanation of why binary-only logs are better than text logs that
isn't essentially the same as the arguments for the Windows Registry.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Sendmail

[Eric Smith]

On Mon, Jul 15, 2013 at 3:12 PM, Till Maas opensou...@till.name wrote:
 Bash usually tells you when there is mail in the spool, which is IMHO a
 big difference to /dev/null.

Funny, I just ssh'd into my machine, and it didn't tell me anything
about mail being in the spool, but when I do an ls on the spool
directory, there it is.

Maybe it has something to do with that users don't often log in as root.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Sendmail

[Eric Smith]

On Mon, Jul 15, 2013 at 3:14 PM, Till Maas opensou...@till.name wrote:
 But the information cron sends via email is usually more important than
 the regular log entries, because output in cron jobs usually means there
 is an error. It seems wrong to store the important data hidden among
 less important data.

Then the syslog severities are configured wrong.  That's not a good
justification for using email rather than syslog.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Mon, Jul 15, 2013 at 3:21 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
 (But
 really, the comparison is just wrong, since the registry is a
 configuration store, and not a log store.)

It's not a perfect analogy, yet the arguments for both seem very
similar, which is why I brought it up. We should try to learn from the
mistakes made by other systems, rather than rushing to repeat them.

Microsoft uses binary logs also, and they are really awful.  Maybe
your binary journal is far better than MS' logs, but  all the
arguments I've seen for it so far make it seem like the advantages are
mainly for complex use cases, and for those someone is going to do a
bunch of system configuration work anyhow, so it doesn't make sense
for that to be the default.  The default should be simple, and the
configuration should be done if you want something complex, rather
than the other way around.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Sendmail

[Eric Smith]

On Mon, Jul 15, 2013 at 3:31 PM, Robert Nichols
rnicholsnos...@comcast.net wrote:
 So, all users on a multi-user system are now expected to dig through
 syslog output to see the output from their cron jobs?

A fair point, but in my experience the most common case is a
single-user system where the user doesn't even use cron.  I'm not sure
whether that's most common in general, but if it is, I think it's
acceptable to have installing an MTA as a manual step on a multiuser
system where there are user cron jobs.

Having the MTA installed by default on end-user systems I administer
has always been problematic, which is why I always remove it.  The
users I've supported have never gained any benefit from having a local
MTA, and normally their MUA points to a remote IMAP server, so they
wouldn't ever see local email.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Sendmail

[Eric Smith]

On Mon, Jul 15, 2013 at 3:45 PM, Till Maas opensou...@till.name wrote:
 Oh, sorry, I was imprecise. Bash actually tells you when new mail is put
 into the spool. E.g. if you log in as root, touch /var/spool/root and
 wait up to 60 seconds and run e.g. ls, bash should tell you that there
 is new mail before the next prompt.

Sure. And how often does a typical user log in as root to discover that email?

Even on systems I administer myself, I don't log in as root, or su,
all that often.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Mon, Jul 15, 2013 at 3:46 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
 But this specific usecase certainly warranted this, and the
 journal does deliver the requirements we cared for.

I'm sure it does.  But I think those requirements mainly apply to
servers and enterprise installations, not the average Fedora
installation.  For the most common use case, doing without
/var/log/messages just makes things more complicated for the user
and/or sysadmin.  I'm all for being able to get fancy binary journals
as a configurable option.  Or even by default, as long as it doesn't
take away also getting a text log by default as well.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Mon, Jul 15, 2013 at 3:53 PM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
 And honestly I dont understand why people are ack/nack-ing this since this
 is FESCO decision

Some of us would like to think that FESCO members might be influenced
by arguments made on the development list.  Maybe that's just wishful
thinking.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Eric Smith]

On Jul 15, 2013 5:51 PM, Lennart Poettering mzerq...@0pointer.de wrote:

 On Tue, 16.07.13 09:13, Dan Fruehauf (malko...@gmail.com) wrote:

   Well, there are certain things on Unix that are text files and many
   things that are not. Binary log files have a long tradition on Unix,
for
   example in wtmp and utmp. We have binary files in /etc, and everywhere
   else.
  
  And the reason for that being? I have no idea either, it's probably too
old
  to be dug. Howver yes, I'd like these to be text based as well.

 Oh, the reasons are pretty well-known for those cases. For example
 wtmp/utmp is binary so that utmp works nicely as sparse file and the
 entries may be accessed using the UID number as seek index (multipled by
 the fixed entry size). So, it's about indexing, exactly as for journal
 files. The Unix guys back then chose binary when it made sense for their
 immediate technical requirements. And for us it's the exact same.

I don't believe that was the reason, since when utmp was invented, Unix had
16-bit UIDs and did not have sparse files.  On the other hand, I don't know
the actual reason.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Eric Smith]

Does NM in F19 support statically assigning multiple subnets to the
same physical interface, WITHOUT using VLANs?  I often need that on
server machines, and wasn't able to figure out any way to do it with
NM on F17, but I haven't yet tried it on F19.

With the old-style network configuration, it was easy to manually
configure this by creating /etc/sysconfig/network-scripts/eth3:n
config files.  Also, it was very easy to automate creating and
removing them, while I have yet to be successful scripting changes to
NM configurations, though probably I'm overlooking some simple way of
doing that.

Previously it has seemed that the old-style network configuration was
more robust than NM, though not as user-friendly. However, I know that
NM has been getting more robust over time, so that may no longer be
true.

Eric


On Thu, Jun 20, 2013 at 12:01 PM, Stephen Gallagher sgall...@redhat.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 06/20/2013 11:08 AM, Reindl Harald wrote:


 Am 20.06.2013 17:01, schrieb Matthew Miller:
 On Thu, Jun 20, 2013 at 11:52:54AM +0200, Harald Hoyer wrote:
 And why is NetworkManager and firewalld in the minimal
 install?

 We are on track to replace the legacy network and firewall init
 scripts with these. It's a slow track, but that's the direction

 *do not* remove iptables.service for a lot od reason explained
 often enough as well as NM is utterly useless on servers and
 workstations with several *static* configured NIC's


 Mind if I ask why you think this way about NetworkManager? The NM
 currently shipping in Fedora 19 has full support for managing static
 NICs, as well as bonding, bridging and VLAN support for enterprise
 use-cases.

 NetworkManager has historically been perceived as a desktop/laptop
 tool but in its current incarnation it should be usable for all but
 the most esoteric enterprise workloads.

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.13 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iEYEARECAAYFAlHDQ18ACgkQeiVVYja6o6Me0wCeNYAGhOf1YSn+x9nlBVqNWewF
 t9oAn2u80JWIyr/PV3jL5H6LLfXMFQC5
 =UPum
 -END PGP SIGNATURE-
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Getting rid of systemd-sysv-convert?

[Eric Smith]

On Thu, Jun 20, 2013 at 3:27 PM, Reindl Harald h.rei...@thelounge.net wrote:
 yes - why was such a basic service *not* a systemd-unit
 at the F15 release-day?

 in my understanding of develop quality software this
 would not have happened and systemd at all not be
 shipped as replacement until the rest of the distribution
 is ready

That's one development model.  Another is to do a more gradual
transition, instead of a sharp cliff.  We could debate the relative
merits of the two models until the cows come home, but it's a moot
point as the gradual transition is what was chosen.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: A need for build triggers automatic rebuilds

[Eric Smith]

On Wed, Jun 19, 2013 at 4:23 AM, Nicolas Mailhot
nicolas.mail...@laposte.net wrote:
 You don't need a special trigger. You need your requirements to match the
 constraints declared at the rpm level, then incompatibilities will be
 caught at this level by normal distro tooling.

How does that work?  A pointer to the docs is fine; My own search
apparently hasn't turned up the right stuff.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: icedtea-web installed and enabled by default in Fedora 19

[Eric Smith]

On Tue, Jun 18, 2013 at 11:29 PM, Dhiru Kholia dhiru.kho...@gmail.com wrote:
 Some recent news,

 http://www.theregister.co.uk/2013/06/14/java_june_critical_patch_update/

 The majority are vulnerable through browser plugins, 11 of which are
 exploitable for complete control of the underlying operating system,
 said Ross Barrett, senior manager of security engineering at Rapid7.

I can see how a vulnerability in Java running in user space can cause
all sorts of problems for the user, but unless someone is running a
browser as superuser, how can it possibly take complete control of
the underlying operating system?  Surely that would require a
privilege escalation vulnerability in the kernel or a setuid program,
and such a vulnerability is the fault of that package, not of Java.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bugzilla.redhat.com vs upstream bug trackers

[Eric Smith]

Is the source code of the Red Hat Bugzilla instance published
somewhere?  A quick search didn't turn it up.

Eric

On Mon, Jun 17, 2013 at 11:45 AM, Eric Smith space...@gmail.com wrote:
 Is the source code of the Red Hat Bugzilla instance published
 somewhere?  A quick search didn't turn it up.

 Eric


 On Mon, Jun 17, 2013 at 11:19 AM, Haïkel Guémar karlthe...@gmail.com wrote:
 Le 17/06/2013 17:37, Jóhann B. Guðmundsson a écrit :

 No it would not.

 This can be solved technically and I have already explain how to do so
 in the past at least between two mozilla bugzilla instances and there
 was some bugzilla maintainer from Red Hat ( we are not running our own
 bugzilla instance so we cannot hack as we please but are forced  to
 abide to what ever internal RH bugzilla admins have set that nobody in
 the community knows about ) looking into it but then he quit and that
 effort died with him as I understood it from James at that time.

 JBG

 If using Red Hat Bugzilla instance is the problem, then it's worth
 taking a look at having our own bugtracker.
 In fact, it's already been examined by our awesome infrastructure team
 and i personnally believe that we should help them fixing that.
 https://fedoraproject.org/wiki/Infrastructure_Fedora_bug_tracker

 Best regards,
 H.
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bugzilla.redhat.com vs upstream bug trackers

[Eric Smith]

On Mon, 17 Jun 2013 11:46:13 -0600 Eric Smith
brouh...@fedoraproject.org wrote:
 Is the source code of the Red Hat Bugzilla instance published
 somewhere?  A quick search didn't turn it up.

On Mon, Jun 17, 2013 at 1:18 PM, Kevin Fenzi ke...@scrye.com wrote:
 It's very close to upstream bugzilla 4.4 at this point I think.

Thanks!  It seems quite a bit different than other Bugzillas I use,
but they're all significantly older versions, so I'll try 4.4.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bugzilla.redhat.com vs upstream bug trackers

[Eric Smith]

On Mon, Jun 17, 2013 at 1:57 PM, Jeffrey Ollie j...@ocjtech.us wrote:
 In no way should packagers be expected to provide end-user support for
 packages, be an expert in every aspect of a package, or be expected to
 work with upstream to debug issues because the end user is unwilling
 to do the work themselves (in essence becoming an upstream developer
 themselves).

I agree.  For some of the packages I maintain, I am able to do some
bug fixing myself, and forward the patches upstream.  For other
packages, I have done the packaging because I use the software, but I
am not at all knowledgeable about the innards, and get lost quickly
trying to fix any bugs.  I think it's reasonable in those cases to
advise that the user report the bugs upstream.

If there was consensus that handling it that way was bad, and that the
package maintainer had to accept more responsibility for bug fixing,
then I'd be happy to hand over the package maintenance duties to
another Fedora package maintainer that was willing to do that.

 Well, let's take Asterisk.  First off, there are a lot of components

That's a good example, but I think there are a lot of packages far
simpler than that which are still too complicated to necessarily
expect the Fedora packager to do all of the software maintenance.

Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

help requested for consolehelper/pam in gsmartcontrol

[Eric Smith]

I have gsmartcontrol working with consolehelper in F17, but it fails
to launch in F18 and F19, and logs messages like this:

Jun 12 19:33:30 localhost /etc/gdm/Xsession[2594]: The password you typed is in\
valid.
Jun 12 19:33:30 localhost /etc/gdm/Xsession[2594]: Please try again.

I suspect that the pam configuration in /etc/pam.d/gsmartcontrol might
need to change.  What was working in F17 was:

#%PAM-1.0
authinclude config-util
account include config-util
session include config-util

Any advice on what to do or how to debug this will be much
appreciated.  The bug is #882555.

I briefly considered trying to convert it to use polkit, but that
looks even more complicated, so if possible I'd like to stick with
consolehelper for now.

Thanks!
Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: help requested for consolehelper/pam in gsmartcontrol

[Eric Smith]

I have no idea how it's happening, but I do seem to get another pair
of these messages to /var/log/messages every time I click on
gsmartcontrol in the menu.

On Thu, Jun 13, 2013 at 9:19 AM, Eric Smith space...@gmail.com wrote:
 I have no idea how it's happening, but I do seem to get another pair
 of these messages to /var/log/messages every time I click on
 gsmartcontrol in the menu.

 On Thu, Jun 13, 2013 at 9:18 AM, Miloslav Trmač m...@volny.cz wrote:
 On Thu, Jun 13, 2013 at 5:10 PM, Eric Smith brouh...@fedoraproject.org 
 wrote:
 I have gsmartcontrol working with consolehelper in F17, but it fails
 to launch in F18 and F19, and logs messages like this:

 Jun 12 19:33:30 localhost /etc/gdm/Xsession[2594]: The password you typed 
 is in\
 valid.
 Jun 12 19:33:30 localhost /etc/gdm/Xsession[2594]: Please try again.
 /etc/gdm/Xsession ?!  I'm not even sure what is writing this to
 syslog (userhelper would either show the message in a dialog or to
 stderr).  Might be a red herring, or might indicate a
 misconfiguration.

 In case it helps, this message is output based on PAM return codes
 PAM_{AUTH_ERR,AUTHTOK_ERR,PERM_DENIED}.
 Mirek
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: help requested for consolehelper/pam in gsmartcontrol

[Eric Smith]

Adam Williamson awill...@redhat.com wrote:
 If I were you I'd just look at any app that's still using consolehelper
 and working, and copy its configuration. Shouldn't be too hard.

Makes sense.  I already have mtr-gtk installed, and it uses
consolehelper.  As it happens, it exhibits the same behavior, and uses
an identical PAM configuration, which worked in F17 but fails in F19.
(I haven't bothered to try it in F18.)  Filed bug #974334.

Now I'll look for another app that uses consolehelper.  Repoquery
shows that there are still 49 packages depending on usermode, and
presumably at least a few others use consolehelper.

 But I think it's trivial to convert an app to use PK
 as a simple 'su wrapper' too

If so, it's a shame that the polkit documentation doesn't give a
trivial example of doing exactly that.  Oh well.

Thanks!
Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: udev rules, ACL_MANAGE, udev-acl?

[Eric Smith]

Tomasz Torcz wrote:

   You need either to classify device in udev rules or tag it with uaccess.
I made a writeup some time ago:
http://enotty.pipebreaker.pl/2012/05/23/linux-automatic-user-acl-management/
I hope it helps.

Thanks Tomasz!  That was extremely helpful!  It completely solved my 
udev issue for the software I'm packaging.


Eric

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

udev rules, ACL_MANAGE, udev-acl?

[Eric Smith]

I'm trying to package something that talks to a USB device. Upstream has 
a udev rule that uses the group plugdev, which apparently is not used 
in Fedora, and I've seen advice to instead use an ACL_MANAGE variable 
and a udev-acl executable.  However, I can't find any documentation on 
either, and udev-acl no longer even seems to exist.  (Was it part of 
ConsoleKit?)


Is there documentation anywhere on how to write appropriate udev rules, 
or examples thereof?  It appears that everything I can find with Google 
is out of date.


Thanks!
Eric

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Eric Smith]

On 01/28/2013 08:47 AM, Máirín Duffy wrote:
I think switching the desktop that has been our default for over 10 
years and 18 releases requires just a bit more research and reason 
than that. ~m 


I don't disagree with the more research and reason part, but the 
current default desktop has only been our default for four releases, 
F15 through F18.  I don't recall any serious research and reason 
having been involved in the switch that occurred when F15 was being 
developed.  As far as I can tell, it was just thrust upon us without 
much consideration as to whether it was good, bad, or indifferent.  My 
proposal is at least only that, a proposal, and is not being thrust upon 
anyone without discussion and ultimately a vote.


Eric

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Eric Smith]

On 01/29/2013 05:25 AM, Dan Mashal wrote:

Lets have a poll. A very public one.

On the main website. Not somebody's blog. And let's let the users 
decide what they want.


I'll tell you what, last time I checked #1 spin is KDE.



I like that idea.  It's ultimately up to FESCo to decide, but a poll 
would give them more information as a basis for the decision.


Eric

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Eric Smith]

On 01/28/2013 09:27 AM, Peter Robinson wrote:
The gnome desktop certainly isn't perfect but I see a lot more users 
using it than most of the rest of the other options.


That's selection bias.  It's the default, so of course it's going to get 
more users.  That doesn't necessarily mean that they like it more than 
alternatives.


The fact that GNOME is working on a classic mode in and of itself 
demonstrates that someone has finally realized that not all users want a 
tablet-style interface for their desktop.  However, we unfortunately 
don't have any hard quantitative information about what users want.


I based my proposal on having watched several moderately experienced 
computer users struggle with Gnome Shell and complain that it was more 
difficult for them to use than what they were accustomed to.  I realize 
that this is only anecdotal evidence, and that there reportedly are 
other users that found Gnome Shell to be easier to use.



I don't believe the no one uses it so we should change has much credence


I agree, and certainly didn't make that argument in the proposal.

but it would be nicer if the gnome team actually initiated a feedback 
loop with Fedora about some of the issues too. 


That would be great.

Eric

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Eric Smith]

On 01/28/2013 09:56 AM, inode0 wrote:
After four releases it isn't bad to step back and take a look at how 
things are working out. I hope we can do that with an eye to where we 
want to go in the future rather than looking to the past.


I couldn't have said it better.  I'm much more concerned about providing 
a good experience for Fedora users than about Cinnamon in particular.


Eric

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: intel ipw2100/ipw2200 firmware must be removed

[Eric Smith]

Kevin Fenzi wrote:


See:
http://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Binary_Firmware


Ralf Ertzinger wrote:
Question about that: The first requirement is that the file is 
non-executable. Does that mean that Fedora cannot ship firmware for 
hardware that has a CPU compatible with the host CPU? 



If it does mean that, it will be a problem for the ARM architecture, as 
many hardware devices using downloaded firmware use ARM cores.


The specific statement is:

The files are non-executable (note: this means that the files 
cannot run on their own, not that they are just chmod -x)


I'm not sure what it means for files to run on their own.  I don't 
think I have a single file on any of my computers that can run on its 
own.  As far as I can see, even the Linux kernel cannot run on its own.


Perhaps it means that the file can't be in a supported executable format 
such as ELF?  Downloaded firmware often is in raw binary format, but 
it's certainly conceivable that some might be in ELF format.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 17 ARM GA Release

[Eric Smith]

Rahul Bhalerao wrote:

Is there a build compatible with WM8650 ARM 926 EJ-S or Cortex Nuvoton M0?


It is nearly guaranteed that there will never be a Fedora build for a 
Cortex-M0 from any vendor.  Or Cortex-M1, M3, or M4.  The Cortex-M and 
Cortex-R series cores don't have an MMU, so they can't run a normal 
Linux kernel.  Some Cortex-M or Cortex-R parts might support enough 
memory to run uCLinux, but a normal Fedora distribution can't run on 
uCLinux.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Eric Smith]

Andrew Haley wrote:
The problem with this claim is that it equivocates on the meaning of 
a right. There are at least two definitions of a right in this 
sense: moral rights and legal rights. These are not the same. Moral 
rights are not in the gift of any Government. While we may not have a 
legal right to run whatever software we wish on hardware we own, it's 
not at all unreasonable to claim a moral right to do so. Andrew. 


Orthogonal to moral vs. legal rights, there is also a distinction 
between positive and negative rights.  If you have a positive right to 
something, that actually puts an obligation on someone to guarantee that 
you get/have/exercise the something.  If you have a negative right to 
something, that only prohibits taking the something away from you, but 
doesn't put an obligation on anyone to guarantee that you 
get/have/exercise the something.


For instance, in the US the right to use a printing press is protected 
by the First Amendment (freedom of speech), but it is a negative right, 
in that the government can't (except in very limited circumstances) do 
anything to prevent you from using a printing press, but the government 
is NOT obligated to provide you with a printing press.  On the other 
hand, the right to an attorney for criminal defendants, protected by the 
Sixth Amendment, has been interpreted by SCOTUS a positive right, since 
if you cannot afford an attorney the government is obligated to provide 
one for you.


I would claim that the moral right to run whatever software we wish on 
hardware we own is a negative right; it doesn't put any obligation on 
another party to help you do it.  If you can hack up Fedora to run on a 
Nokia Windows phone, more power to you, but Nokia and Microsoft aren't 
obligated to help you do it, and aren't legally prohibited from doing 
things that make it difficult for you to exercise your moral right.  
Possibly in this example someone might consider Nokia and Microsoft to 
be infringing their moral right, but (in the US at least) they'd have no 
recourse.


Eric

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Eric Smith]

I wrote:


I would claim that the moral right to run whatever software we wish on
hardware we own is a negative right; it doesn't put any obligation on
another party to help you do it.  If you can hack up Fedora to run on a
Nokia Windows phone, more power to you, but Nokia and Microsoft aren't
obligated to help you do it, and aren't legally prohibited from doing
things that make it difficult for you to exercise your moral right.


Andrew Haley wrote:
I think I'd disagree with you there. I don't think it's any different 
from someone using extensive technical measures to prevent anyone 
other than the authorized dealers of a particular car from servicing 
it. Such a move would be treated as anti-competitive in many 
countries, and IMO software should be treated in the same way. 


If the things that make it difficult to run software of your choosing on 
a device can be proven to serve no purpose but to stifle competition, 
then yes.  But often those things have other purposes as well.  For 
example, requiring firmware updates to be signed has a demonstrable 
purpose in preventing certain types of malware from infecting a product, 
so that feature cannot be said to serve no purpose other but to stifle 
competition.


Eric

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Eric Smith]

Seth Johnson wrote:

The positive/negative right formulation is a post-New Deal notion,
rooted in the question of whether it has been textually granted --
very different from the notion that we hold rights prior to
government.


Nevertheless, even prior to that formulation rights like freedom of the 
press were effectively negative rights, in that they did not obligate 
anyone else to give you a printing press.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

[Eric Smith]

Jesse Keating wrote:
The point in which you find yourself arguing over the semantics of 
Goodwin's law is also a clear indication that the thread has lost any 
amount of usefulness.


Godwin's Meta-Law?  Or maybe Keating's Corollary to Godwin's Law?

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: MATE 1.2

[Eric Smith]

Stefan Schulze Frielinghaus wrote:

On Sat, 2012-06-02 at 10:21 -0400, Randall Berry wrote:

  Does anyone plan to package MATE 1.2[1] for Fedora? MATE is a promising
A Gnome 2.3 fork. If so I would like to be a co-maintainer.  Or if
nobody is planning on it I'll gladly start the project with a little
help from a co-maintainer.

I do not remember the outcome of the discussion but there was something
going on in December last year:

http://lists.fedoraproject.org/pipermail/devel/2011-December/160369.html



The outcome was that a bunch of people were deriding MATE and not 
wanting it in Fedora.  After some time without anyone willing to review 
the first few packages, I abandoned my effort.  At this point I do not 
have the time or energy to go back to work on it.


Eric

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: another upgrade, another disaster

[Eric Smith]

Neal Becker wrote:
I did try distro-sync, but it looked like there would be a lot of 
issues, so I abandoned that idea. 


I'd expect that if distro-sync has a lot of issues, preupgrade and 
Anaconda are likely to as well.  None of these do any magic.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Strategy for packaging an ARM Cortex-M toolchain

[Eric Smith]

Rob Spanton wrote:

There are an increasing number of ARM Cortex-M based boards around, and
I'd like to get a cross-compilation toolchain for them into the Fedora
repositories.


I hope you're more successful with that than I was.  I found a 
resounding lack of interest when I put an arm-none-eabi binutils up for 
review some time back, in preparation for corresponding gcc and gdb 
packages.


I agree with Ralf that this is a different target than arm-gp2x-linux, 
and should be totally independent of it.  However, there might be 
overlap with the cross-gcc package, which builds a gcc-arm-linux-gnu 
package.  That triple sounds like it is for cross compiling to a Linux 
ARM platform, but note that some of the other triples that they build, 
e.g., c6x-linux-gnu arm-h8300-linux-gnu, are actually for non-Linux 
target platforms, so possibly the gcc-arm-linux-gnu package might be 
suitable for non-Linux ARM Cortex-M3 development.


I've personally had much better luck with the Mentor Sourcery (formerly 
CodeSourcery) distribution of the GNU tools for targeting ARM than with 
the official FSF distribution.  The Mentor Sourcery team seems to be one 
of the largest contributors to maintaining the GCC ARM target, and their 
distribution has bug fixes and such *much* earlier than the official FSF 
distribution.  It was my intent to package the Sourcery toolchain, but I 
didn't push it any further when there was no interest in the binutils.


I'm doing cross-development for a custom board with an Energy Micro 
EFM32GG380F1024, which is a Giant Gecko part containing a Cortex-M3 
core, 1MB flash, 128KB RAM, full-speed USB, and a bunch of other 
peripherals.  I started with the original Gecko part because it was the 
only ultra-low-power ARM chip with a decent amount of RAM back in 2010, 
but there may be a few others getting close to it now.


Eric


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers

[Eric Smith]

Michel Alexandre Salim wrote:

LLVM is becoming an increasingly integral part of our distribution
(with mesa now using it to build the LLVMpipe renderer, for example)
that I don't really feel comfortable maintaining it mostly by myself.


I'm not sure how much help I'd be with maintaining the native LLVM 
package, though I'm willing to try.  However, because I have an 
application that uses the LLVM libraries and needs to build for both 
Linux and Windows, I've taken a shot at packaging a mingw-llvm package.  
The package review bug is:

https://bugzilla.redhat.com/show_bug.cgi?id=819670

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fwd: Approving commit access for djvulibre

[Eric Smith]

Jonathan Underwood wrote:

Some months ago I requested commit on the el6 branch of djvulibre, but
the package owner (cc'd) hasn't responded. Please can someone grant me
commit access so I can make some updates?


There's a process to be followed for this kind of issue:

http://fedoraproject.org/wiki/Package_maintainer_policy#What_to_do_if_a_maintainer_is_absent

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GitHub is a terrible upstream

[Eric Smith]

Corey Richardson wrote:

Getting source tarballs from github is a nightmare. See
http://lists.fedoraproject.org/pipermail/devel/2011-February/148676.html

The debian tool doesn't help very much because one still needs revision
garbage in the specfile. Is there any more recent ways to mitigate this?
Perhaps we could lobby github to change their ways, at least partially?


I don't know if this will be of any use to you, but for tcplay there 
isn't a tagged release, so I use this script to create an suitable 
tarball from a github commit with a known hash, by doing a clone then 
archiving it locally.  Certainly this doesn't solve the problem of not 
having a source URL.


#!/bin/sh
# usage: tcplay-get-snapshot.sh hash
git clone git://github.com/bwalex/tc-play
( cd tc-play  \
  git archive --format=tar --prefix=tcplay-$1/ $1 \
) | xz - tcplay-$1.tar.xz

Best regards,
Eric

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

package with binaries only in /usr/sbin: rpmlint no binaries error, empty debuginfo

[Eric Smith]

I'm working on packaging HP's LTFS filesystem (which uses fuse), and it 
has binaries only in /usr/sbin.  rpmlint complains that there are no 
binaries, and the debuginfo package is empty.


[eric@p1 SPECS]$ rpm -qlvp ../RPMS/x86_64/hpltfs-1.2.2-1.x86_64.rpm
-rw-r--r--1 rootroot 1217 Mar 30 00:11 
/etc/ltfs.conf
-rw-r--r--1 rootroot  400 Mar 30 00:11 
/etc/ltfs.conf.local
-rwxr-xr-x1 rootroot 3698 Mar 30 00:11 
/etc/rc.d/init.d/ltfs
-rwxr-xr-x1 rootroot 5895 Mar 30 00:11 
/usr/sbin/ltfs
-rwxr-xr-x1 rootroot 5929 Mar 30 00:11 
/usr/sbin/ltfsck
-rwxr-xr-x1 rootroot 5929 Mar 30 00:11 
/usr/sbin/mkltfs
-rwxr-xr-x1 rootroot 5929 Mar 30 00:11 
/usr/sbin/unltfs
drwxr-xr-x2 rootroot0 Mar 30 00:11 
/usr/share/doc/hpltfs-1.2.2
-rw-r--r--1 rootroot26536 Mar 30 00:11 
/usr/share/doc/hpltfs-1.2.2/COPYING.LIB
-rw-r--r--1 rootroot 3144 Aug 23  2011 
/usr/share/doc/hpltfs-1.2.2/INSTALLING.linux
-rw-r--r--1 rootroot11268 Aug 31  2011 
/usr/share/doc/hpltfs-1.2.2/README.txt
[eric@p1 SPECS]$ rpmlint hpltfs.spec  ../RPMS/x86_64/hpltfs-*.rpm 
../SRPMS/hpltfs-1.2.2-1.src.rpm

hpltfs.x86_64: E: no-binary
hpltfs.x86_64: E: incorrect-fsf-address 
/usr/share/doc/hpltfs-1.2.2/COPYING.LIB

hpltfs-debuginfo.x86_64: E: empty-debuginfo-package
3 packages and 1 specfiles checked; 3 errors, 12 warnings.
[warnings edited out for brevity]

How do I placate rpmlint and get a proper debuginfo, short of moving the 
binaries into /usr/bin?


Thanks!
Eric

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: package with binaries only in /usr/sbin: rpmlint no binaries error, empty debuginfo

[Eric Smith]

Michael Schwendt wrote:
Rather short files = suspicious! Read on. ;) 

Thanks, I should have spotted that!

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM as a primary architecture

[Eric Smith]

DJ Deloried...@redhat.com  wrote:



Buy a trimslice and run it with iSCSI.


Pete Zaitcev wrote:

This is not good enough for me to become involved with Fedora on ARM.
Glad it works for you, but I need a real system, like a Netwinder.


You did see that there's a Trimslice H model that can accomodate a 
2.5 HD or SSD, right?


Or is there something else missing the Netwinder had that the Trimslice 
is missing?



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

More explanation requested for warning about rawhide inheriting updates

[Eric Smith]

The Join the package collection maintainers page gives the warning:

Be sure that you build for rawhide (master) branch before pushing 
updates for any other branches! Otherwise, those updates will get 
inherited into rawhide, which is almost certainly not what you want.


I've never really understood that, but it's never previously caused me 
any concern.  Since I am now in a situation where I want to push an 
update to a branch (f16) without pushing any change to rawhide, it has 
me worried.  Can someone please elaborate on how this inheriting 
updates into rawhide works, and what can be done to avoid it?  I suppose 
the meaning is probably crystal clear to everyone else who has read that 
warning, but apparently I'm being dense again.


Thanks!
Eric

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More explanation requested for warning about rawhide inheriting updates

[Eric Smith]

Bruno Wolff III wrote:

Rawhide inherits from updates of the most recent branch, which is 
currently the branched release (f17). Updates will inherit from the 
release. A package is only inherited if there are no builds for it at 
the current level.

[and more good explanation]

Thanks!  That's exactly what I needed to know.

There is a trick to use when you want to make an update for one 
release that you won't be doing in later releases and where you want 
to keep the later release versions higher than the update. You can add 
.1 (or .2 etc) after %{dist}. 


I've seen that done, but didn't know the purpose.  I think it's the 
right case in my situation.  I've updated muParser in rawhide, and am 
pushing updates for F16 and F17.  muParser has a new so version.  
Meshlab depends on muParser, but meshlab currently won't build in F17 
and rawhide due to GCC 4.7 becoming more picky about C++ namespace 
rules.  I'm waiting for help upstream with getting Meshlab to build with 
GCC 4.7, but in the mean time I want to do a rebuild of meshlab for F16 
to use the new muParser.  It looks like I should add the .1 suffix 
after %{dist}for F16 and push an update.


Eric

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel