Anyone know how to packet rust projects as rpms? stgit-2 specifically

[David Howells]

Hi,

Does anyone know how to package a rust project as an rpm on Fedora 37,
specifically stgit-2?

stgit, of which I make heavy use, has been rewritten in rust but I can't
manage to build it.

https://github.com/stacked-git/stgit

I've found rust2rpm to create a specfile, but that doesn't any insert
BuildRequires for "dnf builddep" to pick up.

Running "rpmbuild -bb" shows a bunch of unsatisfied deps, but I can't find all
of them as prepackaged rpms.

The git-repository crate that stgit depends on, if I download it with crate
install, it can't be installed as it doesn't have an executable in it.  I
think the problem is that it's just a library.

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

Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)

[David Howells]

I wonder if we should drop the cloog package from Fedora.  It was separated
from gcc so that both gcc and cross-gcc could use it.  However neither of them
now do.

Also, the isl package was split out from gcc so that cross-gcc could use it
also, but gcc now seems to be carrying its own isl package of a different
version (0.12.2 rather than 0.16.1).  Do we still build with isl support or
could this also be dropped?

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

Re: Suggestion: Use a unified kernel image by default in the future.

[David Howells]

Sharpened Blade via devel  wrote:

> It would be stored with permissions for only root to read it, and you disk
> should be encrypted, or none of this matters.

It doesn't matter if your disk is encrypted.  Whilst your computer is online,
the contents are accessible.  If your kernel memory is accessible through
/dev/mem or /dev/kmem, there's a chance that your keys can just be read
directly.

One of the things secure boot can do is lock down *read* access to your raw
memory/kernel virtual memory to make it harder for someone to steal your
secrets.  It's not a secure as using a TPM ought to be, though.

And if you want to keep your key safe, you should really keep it in a
removable hardware device.  Leaving it on your hard drive, even with perms
such that only root can read it isn't necessarily safe enough, sadly.

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

Re: Suggestion: Use a unified kernel image by default in the future.

[David Howells]

Sharpened Blade via devel  wrote:

> [...] Software should be secure by itself, [...]

That's impossible to achieve.  Without hardware support, you cannot make your
software secure.

Further, human beings are involved in the writing of the software - and the
larger the codebase and the more people involved, the more bugs there will be.

Add to that the authors of Linux have spent ages providing all sorts of
interesting ways for one process to affect another, from strace to /dev/mem to
ebpf.

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

Re: Can't login with kinit using 2FA

[David Howells]

Michael Catanzaro  wrote:

> Whatever is needed for Fedora kerberos to work needs to be a dependency of
> gnome-online-accounts

What if you're not using gnome?

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

Re: Meaning of Size Directories

[David Howells]

John Reiser  wrote:

> On 3/16/21, David Howells wrote:
> > John Reiser  wrote:
> > 
> >> See the manual page "man 2 getdents".
> > Um, which bit?  I don't see anything obvious to that end.
> 
> On that manual page:
> =
> The system call getdents() reads several linux_dirent structures from the 
> directory
> referred to by the open file descriptor fd into the buffer pointed to by dirp.
>[snip]]
> On  success, the number of bytes read is returned.
> =

It doesn't say anything about the size of the directory there.  "Number of
bytes read is returned" should be taken as how much of the user buffer was
filled - information you need to know to be able to parse it.

Further, there's getdents() and there's getdents64() and their structs are of
different sizes.  By your logic st_size would have to be the number of
linux_dirent structs for use with the former and the number of linux_dirent64
structs for use with the latter...  And then there's readdir() as well with
it's old_linux_dirent struct.

So, no, it cannot work like that.

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

Re: Meaning of Size Directories

[David Howells]

John Reiser  wrote:

> See the manual page "man 2 getdents".

Um, which bit?  I don't see anything obvious to that end.

On AFS directories are handled as files that the filesystem downloads and
parses locally.  The size returned in st_size is the size of the directory
content blob.

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

Re: btrfs hash algorithm (should xxhash be the default?)

[David Howells]

Matthew Miller  wrote:

> Plus, it's 64 bit instead of 32 bit. The 256-bit algorithms are obviously
> much, much slower and probably not right for a default, but should we
> consider making xxhash the default for Fedora Linux systems with btrfs?

Does this affect what's on disk?

David
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal to deprecated `fedpkg local`

[David Howells]

Vít Ondruch  wrote:

> I wonder, what would be the sentiment if I proposed to deprecated the `fedpkg
> local` command. I don't think it should be used. Mock should be the preferred
> way. Would there be anybody really missing this functionality?

Mock is waaay overkill a lot of the time.  It's a lot simpler and easier just
to do fedpkg local.  The main thing wrong with fedpkg local is that it likes
to put stuff in the user's homedir - something it shouldn't do unless it's
actually run there.  That's a pain if the user's homedir is on a network
filesystem.

David
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34, ppc64 and changing from 64k to 4k page size?

[David Howells]

Daniel Pocock  wrote:

> Given the problems with the 64k page size, is it feasible to offer the
> 4k page size as default for ppc64 users in Fedora 34?

It doesn't necessarily help you if you're, say, upgrading from F33 and are
already using 64K pagesize.  Your formatted filesystems may already depend on
this - in which case you may find your system is unbootable.

David
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Deprecating SCP

[David Howells]

Jakub Jelen  wrote:

> Today, I set up a copr repository with the current openssh from Fedora + the
> patch [2] for anyone to test and provide feedback, either here on the mailing
> list, or in the github PR according to ones preferences.

Does it work with connection sharing (ControlPath, ControlMaster,
ControlPersist config options)?

David
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: btrfs and default page sizes (4k vs 64k)

[David Howells]

Neal Gompa  wrote:

> This didn't become a serious problem until Red Hat made the
> unfortunate (though not realized at the time) mistake of switching to
> 64k pages for ARM and POWER. We got that change in Fedora for POWER
> but not ARM. It has led to all kinds of unfortunate problems that are
> gradually being worked on and fixed upstream.

There have been arches in the kernel that didn't support a 4K page size.  FRV,
for example, only supported 16K pages.  I don't know if any of the
"non-regular" arches still in the kernel have similar constraints.

David
___
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

The Fedora Packaging Guidelines point at the old FHS site

[David Howells]

Hi,

The packaging guidelines pages:

https://docs.fedoraproject.org/en-US/packaging-guidelines/

https://fedoraproject.org/w/index.php?title=Packaging:Guidelines=528452#Filesystem_Layout

still point at the old Filesystem Hierarchy Standard (FHS) site:

http://www.pathname.com/fhs/

This hasn't been updated since something like 2004.

The FHS is now maintained by the Linux Foundation:

https://wiki.linuxfoundation.org/lsb/fhs

David
___
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

Re: How to install a mountpoint directory from an rpm?

[David Howells]

Nico Kadel-Garcia  wrote:

> > > > I really don't want to have to tell ordinary users that "you can't use 
> > > > this
> > > > unless you first go and write some systemd scripting".
> > >
> > > If you're willing to take on the work to activate afs dependent
> > > structures and components, it becomes your responsibility to integrate
> > > it well.
> >
> > By "you" are you referring to me personally, or anyone wanting to use the 
> > kafs
> > client?
> 
> Anyone willing to do the work.

Do *what* work?  Do you mean setting up an entire AFS cell and configuring all
the servers?

> > If you're referring to someone wanting to just use the kafs client, why 
> > should
> > they need to do anything other than install kafs-client?  Say they're a
> > student at a university that has an already-existing AFS infrastructure.  
> > They
> > should just be able to install kafs-client, then they should immediately be
> > able access the infrastructure with no required local configuration, 
> > provided
> > the infrastructure includes DNS SRV or AFSDB records telling kafs where to
> > find the cell's Volume Location servers and appropriate kerberos servers.
> 
> Say they're not, and need some other distinct setup. If it's
> standardized, as is seeming more apparent from the existing SELinux
> hooks, OK. Perhaps it's worth adding to the FSH, if it's such a
> standard usage?

The case I'm trying to make simplest is someone who just needs to gain access
to an already existing AFS infrastructure.  It can be made such that someone
in that position has to do zero configuration, apart from installing the
kafs-client package.

Anyone who wants to do anything more interesting, will have to do their own
configuration, but the kafs-client rpm contains stuff that can be used as a
template.

If you happen to be so inclined, kafs is almost completely network-namespace
aware and can be used in containerised environments.  You can mount individual
volumes directly if you wish.  The bits that aren't in place yet are the
request-key upcall namespacing, which I'm working on, and the ability to
provide keys to a container from the outside - which I'm also working on.

> > But to some extent what you're describing is not the fault of AFS, no matter
> > the client driver.  Whatever is trawling the rootfs can observe the crossing
> > into a separate filesystem.  I should make statx() set attributes to tell 
> > you
> 
> Not without getting the directory information about "/" to report
> information about that unique node. You see the problem?

No.  That's something statx() should be able to tell you.  Now, I will grant
that at the moment it won't tell you that what is mounted on /afs is a magic
dir full of automount points, but it *will* set STATX_ATTR_AUTOMOUNT on each
inode that is an automount point.  This is done by the core kernel for each
inode that is flagged S_AUTOMOUNT internally.

> > That's a bit out of date.  See:
> >
> > https://www.infradead.org/~dhowells/kafs/
> > https://www.infradead.org/~dhowells/kafs/todo.html
> >
> > The pioctl thing is the most vexing bit.  Linus point-blank refuses to let 
> > the
> > pioctl interface into the code, so I'm having to build in workarounds:
> >
> > https://www.infradead.org/~dhowells/kafs/user_interface.html
> >
> > David
> 
> I'd be inclined to take Linux's opinion over yours on the matter. Not
> to question your personal expertise, but he's earned a lot of trust
> for his successful authorship and insight in the Linux kernel.

I should rotfl at that one!  Besides, who said my opinion of the pioctl
interface doesn't coincide with Linus's?

The reason I was trying to build pioctl into the kernel - or, at least, the
kafs filesystem - is so that OpenAFS's toolset could be used directly with
kafs.  But the pioctl interface has been somewhat, um, abused, so Linus's
position is understandable (and it's not just Linus who holds this opinion, I
should add).

> I'm curious what AFS is providing over NFSv4 and autofs based mounts?

Access to 35 years worth of existing AFS infrastructure and the data stored
therein, through a global namespace with server transparency.

But this is really for other people to answer, and I suspect the answers may
differ by organisation.

David
___
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

Re: How to install a mountpoint directory from an rpm?

[David Howells]

Nico Kadel-Garcia  wrote:

> > I really don't want to have to tell ordinary users that "you can't use this
> > unless you first go and write some systemd scripting".
> 
> If you're willing to take on the work to activate afs dependent
> structures and components, it becomes your responsibility to integrate
> it well.

By "you" are you referring to me personally, or anyone wanting to use the kafs
client?

If you're referring to someone wanting to just use the kafs client, why should
they need to do anything other than install kafs-client?  Say they're a
student at a university that has an already-existing AFS infrastructure.  They
should just be able to install kafs-client, then they should immediately be
able access the infrastructure with no required local configuration, provided
the infrastructure includes DNS SRV or AFSDB records telling kafs where to
find the cell's Volume Location servers and appropriate kerberos servers.

> > > \And violating a much more important, namely the File System Hiearchy.
> > > If you can find a good reason to violate that, publish your reasoning.
> >
> > Well, there's 35 years of history, expectation, experience, documentation 
> > and
> > scripting for a start that expect the global AFS namespace to be mounted on
> > /afs on a UNIX box (Windows is different).
> 
> Including the fact that, since its invention, it has *always* demanded
> a reboot of the client using it to clear the status of "/afs" in the
> root filesystem from screwing up basic system opertations that check
> anytingn in /. It's never worked well.

Perhaps kafs is different?

You can unmount things in /afs directly.  You can evict all unbusy mounted
cells by:

for i in /afs/*; do umount $i; done

But to some extent what you're describing is not the fault of AFS, no matter
the client driver.  Whatever is trawling the rootfs can observe the crossing
into a separate filesystem.  I should make statx() set attributes to tell you
that (a) it's a general automounter, (b) it's a network filesystem and (c) the
dirs are automount points - then the trawlers can work out for themselves to
leave this alone.

> > For the in-kernel AFS client to "work out of the box", it must mount the
> > dynamic root on /afs.  That is what people who use AFS generally expect.
> 
> And it destabilizes the client by locking up any queries of "/",
> mandating a reboot at least once a week. I first encountered that
> issue in the 1980's, and again lat MIT in the 1990's. Since those
> systems all got forced reboots anyway, on at least a weekly basis even
> if someone was logged into the workstations, it was And over time, it
> was deemed pretty pointless with autofs enabled NFS mounting thgouth
> "/net/$SERVERNAME/".  As best I can tell, the "/afs/" automounting
> generated lockups of the "/" directory was never fixed. Do you have
> any experience that contradicts this weekly reboot requirement?

kafs and AF_RXRPC have been written from scratch, sharing zero code with
OpenAFS, Transarc or whatever you were using in the 1980s and 1990s.

> I'm not insisting it's not been fixed, but it was a big pain at the time.
> 
> > > By the way, I've dealt with /afs style automounting before, and it was
> > > a nightmare to clean up after when it inevitably croaked precisely due
> > > to the root filesystem location of "/afs".
> >
> > "a nightmare to clean up"?  "inevitably croaked"?  "precisely due to the 
> > root
> > filesystem location"?  Please elaborate.
> 
> See above. It hung up kernel "stat" operations on the "/" directory,
> with increasing delays over the course of roughly a week until it
> could be cleared only by a reboot. It's a not an unheard of problem
> with confused mountpoints of any type that are mounted directly under
> "/", and it's one of the reasons the FSH delegates subdirectories.

What's mounted on /afs by kafs is a pseudo-volume that's not backed by the
network.  Think of it as kafs's own automounter.  Doing a stat on it is a
trivial operation.  Directories can be made in it by lookup of cell names (or
by preloading).

> > "umount /afs" or "systemctl stop afs.mount" will unmount the kafs (the
> > in-kernel afs filesystem) dynroot and all its automounts.  Note that kafs
> > works differently to, say, OpenAFS.  OpenAFS has a single superblock that is
> > the entire AFS namespace and every volume, every vnode you access appears in
> > there.  kafs, however, creates a superblock for each volume and uses the
> > d_automount dentry operation to operate AFS mount points.
> >
> > David
> 
> According to the Linux kernel notes about KAFS:
> 
> This filesystem provides a fairly simple secure AFS filesystem driver. It is
> under development and does not yet provide the full feature set.  The
> documentation is at
> https://www.kernel.org/doc/Documentation/filesystems/afs.txt, and
> says:
> 
>The features it does support include:
> 
>  (*) Security (currently only AFS kaserver and KerberosIV tickets).
>  (*) File reading and 

Re: How to install a mountpoint directory from an rpm?

[David Howells]

Nico Kadel-Garcia  wrote:

> > I seem to remember you can't create root level directories from a
> > program either.
> 
> Of course you can. The program needs to run with root privileges. and
> not violate whatever SELinux or other "/" mountpoint restrictions
> exist.
> 
> It's a *Bad Idea(tm), since it violates the File System Hierarchy, but
> that hardly makes it impossible.

Note that I don't feel any requirement that the /afs directory should be
installed by the filesystem rpm.  For my purposes, it would be fine if it's
created or installed by the kafs-client rpm or created on demand by the
systemd script for starting the mount.

Note further that there does need to be a systemd script to effect the mount
as this has a dependency on another systemd script that loads the
configuration into the kernel.

I really don't want to have to tell ordinary users that "you can't use this
unless you first go and write some systemd scripting".

> \And violating a much more important, namely the File System Hiearchy.
> If you can find a good reason to violate that, publish your reasoning.

Well, there's 35 years of history, expectation, experience, documentation and
scripting for a start that expect the global AFS namespace to be mounted on
/afs on a UNIX box (Windows is different).

For the in-kernel AFS client to "work out of the box", it must mount the
dynamic root on /afs.  That is what people who use AFS generally expect.

> By the way, I've dealt with /afs style automounting before, and it was
> a nightmare to clean up after when it inevitably croaked precisely due
> to the root filesystem location of "/afs".

"a nightmare to clean up"?  "inevitably croaked"?  "precisely due to the root
filesystem location"?  Please elaborate.

"umount /afs" or "systemctl stop afs.mount" will unmount the kafs (the
in-kernel afs filesystem) dynroot and all its automounts.  Note that kafs
works differently to, say, OpenAFS.  OpenAFS has a single superblock that is
the entire AFS namespace and every volume, every vnode you access appears in
there.  kafs, however, creates a superblock for each volume and uses the
d_automount dentry operation to operate AFS mount points.

David
___
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

Re: How to install a mountpoint directory from an rpm?

[David Howells]

Jason L Tibbitts III  wrote:

> DH> I'm not entirely clear how I should go about requesting FPC
> DH> approval.  It says it is preferable that a ticket be filed in the
> DH> packaging committee pagure - do they mean to raise an issue, do you
> DH> know?
> 
> Just file a ticket:
> 
> https://pagure.io/packaging-committee/new_issue
> 
> That's it, really.

I've done that, thanks:

https://pagure.io/packaging-committee/issue/888

David
___
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

Re: How to install a mountpoint directory from an rpm?

[David Howells]

Zbigniew Jędrzejewski-Szmek  wrote:

> > >I need to install a directory (/afs) that will be a mountpoint that a 
> > >systemd
> > >service (also installed in the rpm) will mount upon.
> 
> Nope. New top-level directories are a big thing and need FPC approval:
> https://fedoraproject.org/w/index.php?title=Packaging:Guidelines=528452#Filesystem_Layout
> (I can't find the text in the new guidelines, but the new guidelines don't
> support searching, so finding anything is PITA, so I'll just assume that
> this is still valid...)

I'm not entirely clear how I should go about requesting FPC approval.  It says
it is preferable that a ticket be filed in the packaging committee pagure - do
they mean to raise an issue, do you know?

> Regarding the FPC approval: I don't think it should be granted. There
> is no good reason to create a mount point like this under root.

Ummm...  There's ~35 years of history of use of /afs as a cross-platform
global namespace[*]; there are organisations, people, computers, scripts with
this as an expectation.  The Linux kernel now contains an AFS filesystem of
its own, written from scratch and now enabled in the Fedora kernel; to be
compatible with OpenAFS, AuriStor, Transarc, Arla it really needs the dynamic
root mounting on /afs.

Note that, for my purposes, /afs only needs to exist if the kafs-client
package is installed.

> It should go somewhere under /run or /var.

Well, I could mount it there, but then I'd really need a symlink or bind mount
at /afs to deal

Note the SELinux rules already have /afs as the mountpoint:

matchpathcon /afs/
/afssystem_u:object_r:mnt_t:s0

Thanks,
David

[*] Give or take Windows
___
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

How to install a mountpoint directory from an rpm?

[David Howells]

Hi,

I need to install a directory (/afs) that will be a mountpoint that a systemd
service (also installed in the rpm) will mount upon.

What's the best way to encode this in the specfile?

I did have:

%files
/afs

but that doesn't upgrade correctly.  Someone gave me another way to do it:

%post
%systemd_post afs.mount

# Create /afs directory if it doesn't exist
if [ ! -d /afs ]; then
mkdir /afs
chown root.root /afs
chmod 0755 /afs
[ -x /usr/sbin/restorecon ] && /usr/sbin/restorecon /afs
fi

%files
%ghost %dir /afs

but rpmlint complains about the chown:

kafs-client.x86_64: W: dangerous-command-in-%post chown

The git repo is here:


http://git.infradead.org/users/dhowells/kafs-client.git/shortlog/refs/heads/next


The second patch from the top is the one that tries to fix the mountpoint dir
installation issue ("spec: Treat /afs special").

Thanks,
David
___
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

Re: Signing Kernel Module with the Private Key

[David Howells]

Nicolas Viéville  wrote:

> As Petr Pisar said it, last Fedora's kernel uses a compiled binary software
> sign-file file. It is still a perl script in RHEL.

That is correct till RHEL-8.

> Concerning compressing modules, they have to be built, stripped (if needed),
> signed and compressed, in that order to make them work with secure boot.  So
> if the build process compresses your modules automatically, you have to
> decompress them before signing, and re-compress them after signing.

That is correct.

David
___
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

Re: KWin shortcuts being swallowed

[David Howells]

Pawel Veselov  wrote:

> I am using KDE, and I have a bunch of KWin shortcuts, for example,
> Meta+F, that bring windows to front/back. I also have one of those
> keyboards that replays macros (K55 if one's curious), so I have a key
> that plays Meta+F back as a macro. It was working fine until at some
> point it started, every now and again, to translate that macro to 'f',
> rather than front/back event.

Have you switched to using Wayland rather than X?

David
___
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

Is there an independent lib for parsing Kerberos config files?

[David Howells]

Hi,

I've made the keyutils package use the profile parsing routines from the
-lkrb5 library (the config data I need to parse is from an external source, so
the format is already set).  The problem is that some other distributions are
using Heimdal rather than MIT kerberos and those routines are not available
there.

Does anyone know if there's some other library available for parsing these
things that might be more readily cross-platform?

Thanks,
David
___
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

Re: Debuginfo exclusion list?

[David Howells]

Richard W.M. Jones  wrote:

> Another method might be to add an alternate strip binary/script which
> filters based on your preferred criteria.
> 
>   %global __strip %{_sourcedir}/my-strip.sh

Just marking the relevant files non-executable works in my case, but thanks
for the suggestion.

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

Debuginfo exclusion list?

[David Howells]

Hi Mark,

Is it possible to specify from a specfile an list of files and/or directories
in the installation output that should be ignored for the purposes of
debuginfo extraction?  If not, can this be added?

I maintain cross-gcc and there are some files that get
installed that must not be stripped.  They are, typically, isolated in a
common directory - for example, in the gcc-x86_64-linux-gnu, I have the
following ELF files:

/usr/bin/x86_64-linux-gnu-cpp
/usr/bin/x86_64-linux-gnu-gcc
/usr/bin/x86_64-linux-gnu-gcc-ar
/usr/bin/x86_64-linux-gnu-gcc-nm
/usr/bin/x86_64-linux-gnu-gcc-ranlib
/usr/bin/x86_64-linux-gnu-gcov
/usr/bin/x86_64-linux-gnu-gcov-dump
/usr/bin/x86_64-linux-gnu-gcov-tool
/usr/lib/gcc/x86_64-linux-gnu/7/32/crtbegin.o
/usr/lib/gcc/x86_64-linux-gnu/7/32/crtbeginS.o
/usr/lib/gcc/x86_64-linux-gnu/7/32/crtbeginT.o
/usr/lib/gcc/x86_64-linux-gnu/7/32/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/7/32/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/7/32/crtfastmath.o
/usr/lib/gcc/x86_64-linux-gnu/7/32/crtprec32.o
/usr/lib/gcc/x86_64-linux-gnu/7/32/crtprec64.o
/usr/lib/gcc/x86_64-linux-gnu/7/32/crtprec80.o
/usr/lib/gcc/x86_64-linux-gnu/7/32/libgcc.a
/usr/lib/gcc/x86_64-linux-gnu/7/32/libgcov.a
/usr/lib/gcc/x86_64-linux-gnu/7/crtbegin.o
/usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o
/usr/lib/gcc/x86_64-linux-gnu/7/crtbeginT.o
/usr/lib/gcc/x86_64-linux-gnu/7/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/7/crtfastmath.o
/usr/lib/gcc/x86_64-linux-gnu/7/crtprec32.o
/usr/lib/gcc/x86_64-linux-gnu/7/crtprec64.o
/usr/lib/gcc/x86_64-linux-gnu/7/crtprec80.o
/usr/lib/gcc/x86_64-linux-gnu/7/libgcc.a
/usr/lib/gcc/x86_64-linux-gnu/7/libgcov.a
/usr/libexec/gcc/x86_64-linux-gnu/7/cc1
/usr/libexec/gcc/x86_64-linux-gnu/7/collect2
/usr/libexec/gcc/x86_64-linux-gnu/7/liblto_plugin.la
/usr/libexec/gcc/x86_64-linux-gnu/7/liblto_plugin.so

Everything in /usr/bin and /usr/libexec can be stripped, but everything in
/usr/lib must not be.

At the moment the cross-gcc package won't build in the Fedora build farm.

I think the gcc package may well be in the same boat.

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

How to fix 'E: hardcoded-library-path in /usr/lib/debug"' in cross-gcc?

[David Howells]

Hi,

When creating an update for cross-gcc, I see:

cross-gcc.src:388: E: hardcoded-library-path in /usr/lib/debug"

from dist.rpmlint.

cross-gcc's spec file does stuff to /usr/lib/debug because it's a compiler and
the debuginfo shouldn't be extracted from some of the compiled bits it ships
with (crt*.o files and libgcc archives, for example).

Is there a right way to do this so as not to incur the above error?

I imagine the same problem occurs in gcc also since I copied the debuginfo
extraction code from there.

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

Re: Is it possible to manually insert shared library deps in an RPM?

[David Howells]

Panu Matilainen  wrote:

> %if %{__isa_bits} == 64
> Requires: libisl.so.15()(64bit)
> %else
> Requires: libisl.so.15()
> %endif

Should "(64bits)" be appended on, say, ia64 where there is no 32-bit
userspace?

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

Re: Is it possible to manually insert shared library deps in an RPM?

[David Howells]

Panu Matilainen  wrote:

> >> %if %{__isa_bits} == 64
> >> Requires: libisl.so.15()(64bit)
> >> %else
> >> Requires: libisl.so.15()
> >> %endif
> >
> > That doesn't work.  It complains about illegal characters.
> 
> Sure it works. It's copy-pasted from a spec I just built *just in case*
> there's been some sort of wacko regression someplace, that's not the case.
> 
> Parentheses have always been a common part of rpm provides and requires, if
> you're getting errors there's something else going on.
> Feel free to point me to the spec that's giving you illegal character errors
> from the above.

It works now, thanks.  I'm not sure what I did before, but:

Requires: libisl.so.13()(64bit)

definitely did produce an error, but now no longer does.

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

Re: Is it possible to manually insert shared library deps in an RPM?

[David Howells]

Kevin Kofler  wrote:

> So I think that the library should really be linked, not dlopened.

That was my suggestion too, but Jakub doesn't like that idea.

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

Re: Is it possible to manually insert shared library deps in an RPM?

[David Howells]

Panu Matilainen  wrote:

> %if %{__isa_bits} == 64
> Requires: libisl.so.15()(64bit)
> %else
> Requires: libisl.so.15()
> %endif

That doesn't work.  It complains about illegal characters.

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

Re: Is it possible to manually insert shared library deps in an RPM?

[David Howells]

Okay, creating a script:

#!/bin/sh
if [ -x /usr/lib/rpm/redhat/find-requires ] ; then
FINDREQ=/usr/lib/rpm/redhat/find-requires
else
FINDREQ=/usr/lib/rpm/find-requires
fi
$FINDREQ $*
case `uname -m` in
*64)
echo 'libisl.so.15()(64bit)'
;;
*)
echo 'libisl.so.15()'
;;
esac

gives me the following:

warthog>rpm -qpR x86_64/gcc-x86_64-linux-gnu-6.3.1-1.fc26.x86_64.rpm
...
libisl.so.15()(64bit)
...

which seems more or less what I was looking for.  Deciding whether or not I
want to include the "(64bit)" flag is another issue to be solved.

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

Re: Is it possible to manually insert shared library deps in an RPM?

[David Howells]

Daniel P. Berrange  wrote:

> See the section "requires filtering"
> 
>   
> https://fedoraproject.org/wiki/PackagingDrafts/FilteringAutomaticDependencies
> 
> instead of filtering you'd be augmenting, but that's fine.

This scriptlet would seem to be inconsistent with the way find-requires works:

$FINDREQ $* | sed -e '/libbadreq.so/d'

but find-requires seems to require the filenames to be piped in rather than
passed on the command line.

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

Re: Is it possible to manually insert shared library deps in an RPM?

[David Howells]

Stephen Gallagher  wrote:

> What's wrong with doing:
> 
> Requires: isl%{?_isa} >= %{isl_version}
> 
> Other than you'll have to be aware and deal with any eventual soname bump, of
> course.

They bumped it somewhere between isl-0.14 (which gcc uses now) and isl-0.16.1
(which gcc wants to use).

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

Is it possible to manually insert shared library deps in an RPM?

[David Howells]

Hi,

gcc and cross-gcc currently dynamically load the isl-0.14 shared library -
which means that rpm-build doesn't automagically detect a:

libisl.so.13()(64bit)

but, rather, the gcc binary rpm must include a:

Requires: isl = %{isl_version}

clause.

Is it possible to instead do something like:

Requires: libisl.so.13()(64bit)

(though this doesn't work because it complains about an illegal char) so that
it is pegged to the major version of the library rather than the specific isl
version?

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

Re: cross-compiler support?

[David Howells]

Igor Gnatenko  wrote:

> > Well there is gcc-arm-linux-gnu for example but that's for kernels per
> > description
> Didn't see it before... But looks like it doesn't work either:
> /usr/bin/arm-linux-gnu-ld: cannot find crt1.o: No such file or directory
> /usr/bin/arm-linux-gnu-ld: cannot find crti.o: No such file or directory
> /usr/bin/arm-linux-gnu-ld: cannot find -lc
> /usr/bin/arm-linux-gnu-ld: cannot find crtn.o: No such file or directory

Yeah - it's intended for building kernels (though it can build anything that
provides its own userspace).

There are a number of reasons I *don't* provide userspaces:

 (0) I build cross-compilers for 20-ish arches (note that not all kernel
 arches are actually supported by upstream gcc and binutils).

 (1) No single upstream C library supports all the arches I can build a
 cross-compiler for, so I would have to include multiple C libraries in
 the SRPM and build some arches differently to others.  Some I won't be
 able to bootstrap at all without an old or hacked version of a C library.

 (2) Do I bootstrap-build a single config for each arch or several configs?
 What one or ones do I pick?  Note that not all configs of a single arch
 are necessarily supported by the same C library (consider MMU vs NOMMU).
 Further note that each bootstrap increases the build footprint and
 installation footprint - and at some point the package will become
 unbuildable.

IMHO, it shouldn't be necessary for the compiler to know anything about the C
library...

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

Re: Packagers - Flag day 2016 Important changes

[David Howells]

Mike McLean  wrote:

> 1) make sure your krb5.conf has:
> includedir /etc/krb5.conf.d/

Should there be something in there other than a crypto-policies symlink?

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

Re: upcoming build and release developer flag day December 12 2016

[David Howells]

Michael Catanzaro  wrote:

> I have no idea how this fancy Kerberos works or integrates with GNOME,
> but the above is a truism that stands the test of time.

Kerberos integrates fine with KDE's Konqueror.  If I go to a kerberised page
for which I have a TGT, KDE will do the ticket look up automatically.

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

Re: How to obsolete a subpackage?

[David Howells]

Florian Weimer  wrote:

> I think if you want silent deletion, you'll have to add “Obsoletes:
> binutils-sh64-linux-gnu” to the cross-binutils-common package.

Yeah, the following worked:

@@ -129,6 +133,9 @@ converting addresses to file and line).
 Summary: Cross-build binary utility documentation and translation files
 Group: Development/Tools
 BuildArch: noarch
+%if !%{build_sh64}
+Obsoletes: binutils-sh64-linux-gnu
+%endif
 %description -n %{cross}-binutils-common
 Documentation, manual pages and translation files for cross-build binary image
 generation, manipulation and query tools.

I forgot to put the '!' in the %if condition, which didn't help.

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

How to obsolete a subpackage?

[David Howells]

I need to obsolete one of the arch subpackages in the cross-binutils rpm (and
also in the cross-gcc rpm) because binutils no longer supports that arch
(sh64).

Just marking the appropriate subpackage as obsoleted in the specfile for the
cross-binutils-common subpackage causes dnf to complain:

warthog>sudo dnf upgrade ./noarch/cross-binutils-common-2.27-1.fc26.noarch.rpm 
./x86_64/binutils-*
Last metadata expiration check: 0:20:38 ago on Wed Sep 14 15:06:27 2016.
Error: package binutils-sh64-linux-gnu-2.26.1-1.fc24.x86_64 requires 
cross-binutils-common = 2.26.1-1.fc24, but none of the providers can be 
installed
(try to add '--allowerasing' to command line to replace conflicting packages)

Is this the right way to do things?

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

Re: g++ __VA_ARGS__ error

[David Howells]

Jan Synacek  wrote:

>  #define ssprintf(dest, ...) snprintf((dest), sizeof(dest), __VA_ARGS__)

Did you want:

#define ssprintf(dest, ...) snprintf((dest), sizeof(dest), ## __VA_ARGS__)

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

How do avoid "hardcoded-library-path in /usr/lib/debug" from rpmlint

[David Howells]

Hi,

In cross-gcc, the specfile needs to do its own debuginfo manipulation because
it has binary files that must not be stripped inside the package - and
preferably must not even be looked at by the manipulation tools because they
are likely to be for a completely different target to the system toolchain.

However, rpmlint objects to the script with:

cross-gcc.src:381: E: hardcoded-library-path in /usr/lib/debug"

how do I avoid this?  This ought to affect the system gcc package also since I
copied the script from there.

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

rpmlint vs zero-length files

[David Howells]

Hi,

How do I prevent rpmlint from objecting to some specific zero-length files?

I'm building a bunch of cross-compilers, and the installation includes some
zero-length files that appear to have to be there, but are zero-length (and in
some cases look like they have to be empty).

gcc-h8300-linux-gnu.armv7hl: E: zero-length 
/usr/lib/gcc/h8300-elf/5.3.1/install-tools/macro_list
gcc-h8300-linux-gnu.i686: E: zero-length 
/usr/lib/gcc/h8300-elf/5.3.1/install-tools/macro_list
gcc-h8300-linux-gnu.x86_64: E: zero-length 
/usr/lib/gcc/h8300-elf/5.3.1/install-tools/macro_list
gcc-m68k-linux-gnu.armv7hl: E: zero-length 
/usr/lib/gcc/m68k-linux-gnu/5.3.1/plugin/include/sysroot-suffix.h
gcc-m68k-linux-gnu.i686: E: zero-length 
/usr/lib/gcc/m68k-linux-gnu/5.3.1/plugin/include/sysroot-suffix.h
gcc-m68k-linux-gnu.x86_64: E: zero-length 
/usr/lib/gcc/m68k-linux-gnu/5.3.1/plugin/include/sysroot-suffix.h
gcc-sh64-linux-gnu.armv7hl: E: zero-length 
/usr/lib/gcc/sh64-linux-elf/5.3.1/install-tools/macro_list
gcc-sh64-linux-gnu.i686: E: zero-length 
/usr/lib/gcc/sh64-linux-elf/5.3.1/install-tools/macro_list
gcc-sh64-linux-gnu.x86_64: E: zero-length 
/usr/lib/gcc/sh64-linux-elf/5.3.1/install-tools/macro_list

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

Re: cross-gcc error: Error: missing operand

[David Howells]

Richard W.M. Jones  wrote:

> I would file a bug about this, but I noticed that cross-gcc is at
> version 5.2.1.  Are we going to update it to 6.0?  If so, are there
> any testing packages that you would like me to try?

As we speak[*], I'm just preparing an update to 5.3.1 for Rawhide, F23 and F22
and will then commence gcc-6 for Rawhide.

[*] Well, type.

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

Re: Changes in F24 schedule - two weeks slip

[David Howells]

Jan Kurik  wrote:

> let me inform you about changes in Fedora 24 schedule.
> 
> There is a will to accommodate GCC6 compiler in F24 and use it to
> compile all the binaries delivered in this release [1].

Do the cross-gcc packages also need moving to GCC6 immediately as I believe
they're used to compile some bits too?

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

Installation of symlinks - should wrapper scripts be used instead?

[David Howells]

I maintain the cross-binutils and cross-gcc packages.  These produce powerpc64
subpackages with binaries in.  However, since I was asked to provide support
for ppc64-linux-gnu-x in addition to powerpc64-linux-gnu-x commands, I provide
symlink rpms for the ppc64 name that link to the former name.

This, however, seems to go messily wrong if a symlink is being installed to a
filename that is already populated with a file.  It appears that the symlinks
so far installed don't get cleaned up.

Would it be better to install wrapper scripts instead?

David
-- 
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: How to package python extensions that need a special preprocessor?

[David Howells]

Guy Streeter  wrote:

> > I'm trying to package a python module that has a C extension that has a 
> > special preprocessor that turns protocol definition files into C.
> ...
> See the setup.py in this package:
> 
> https://git.fedorahosted.org/cgit/python-libnuma.git/
> 
> It runs msgfmt on the provided message catalog files at build time.

Okay, thanks for the reference.  That takes me part the way there - but as I
understand it, message catalogue files aren't then compiled with the C
compiler and built into the extension module, right?

David
-- 
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: How to package python extensions that need a special preprocessor?

[David Howells]

Guy Streeter  wrote:

> Do you just need to control the build order, so your preprocessor runs
> first?

Yes.

> You can over-ride "build" to make that happen.

Okay.

> Or use something like
> 
>  ./setup.py build_prep build_ext build

I'd rather not do that - I'd rather 'build' built everything.

David
-- 
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: can't submit updates for f22?

[David Howells]

Peter Robinson pbrobin...@gmail.com wrote:

  updates-testing always enabled here and only:
  python-fedora-0.5.4-1.fc21.noarch
 
 It seems it should be, maybe issues with local mirror being out of sync?
 https://bodhi.fedoraproject.org/updates/FEDORA-2015-13829

I only see 0.5.4:

warthogyum list python-fedora --enablerepo=updates-testing
Loaded plugins: auto-update-debuginfo, langpacks
fedora-debuginfo/21/x86_64/metalink |  18 kB  00:00 
rpmfusion-free-debuginfo| 2.7 kB  00:00 
rpmfusion-free-updates-debuginfo| 2.7 kB  00:00 
updates-debuginfo/21/x86_64/metalink|  18 kB  00:00 
updates-debuginfo   | 3.0 kB  00:00 
updates-testing/21/x86_64/metalink  |  19 kB  00:00 
updates-testing | 4.7 kB  00:00 
updates-testing-debuginfo/21/x86_64/metalink|  17 kB  00:00 
updates-testing-debuginfo   | 3.0 kB  00:00 
(1/5): updates-debuginfo/21/x86_64/primary_db   | 643 kB  00:00 
(2/5): updates-testing/21/x86_64/group_gz   | 230 kB  00:00 
(3/5): updates-testing/21/x86_64/updateinfo |  94 kB  00:00 
(4/5): updates-testing/21/x86_64/primary_db | 809 kB  00:00 
(5/5): updates-testing-debuginfo/21/x86_64/primary_db   |  59 kB  00:01 
rpmfusion-free-updates-debuginfo/21/x86_64/primary_db   |  38 kB  00:00 
Installed Packages
python-fedora.noarch0.3.37-1.fc21@updates   
Available Packages
python-fedora.noarch0.5.4-1.fc21 updates-testing

The rpmlint automated test failed.  Would that prevent it appearing?

David
-- 
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: DNF and regular expressions

[David Howells]

Germano Massullo germano.massu...@gmail.com wrote:

 What is wrong with DNF's regular expression
 # dnf remove *debuginfo*.fc20.x86_64

Do you mean 'regular expression' or did you mean 'glob'?

If you did mean 'regular expression', then did you want:

dnf remove .*debuginfo.*[.]fc20[.]x86_64

David
-- 
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: F23 System Wide Change: Default Local DNS Resolver

[David Howells]

Paul Wouters p...@nohats.ca wrote:

 I think most people end up running dnsmasq because of KVM/libvirtd ? I
 think those dnsmasq's should be run in dhcp only mode and point to
 the hosts's unbound.

I'm using dnsmasq to look up *.redhat.com addresses over VPN whilst looking up
other addresses from my ISP.

David
-- 
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: F23 System Wide Change: Default Local DNS Resolver

[David Howells]

Jan Kurik jku...@redhat.com wrote:

 Install a local DNS resolver trusted for the DNSSEC validation running on
 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.

 The automatic name server entries received via dhcp/vpn/wireless
 configurations should be stored separately (e.g. this is stored in the
 NetworkManager internal state), as transitory name servers to be used by the
 trusted local resolver. In all cases, DNSSEC validation will be done
 locally.

How does this interact with dnsmasq which also wants to be the only name
server entry in resolv.conf?

David
-- 
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: GCC 5 compatibility problems: GCC 4.10?

[David Howells]

Paolo Bonzini pbonz...@redhat.com wrote:

   I'm encountering a few problems with GCC 5 due to code that fails to
   work with GCC major releases above 4.  In particular, there are at least
   problems with the kernel
 
  fedora's kernel builds, can you be more specific about the problems you're 
  experiencing?
 
 Kernels older than 3.18 don't build, which is a pain if you're bisecting
 a kernel bug introduced before 3.18.

Any particular arch?  And what's the error?

David
-- 
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: gcc5 C++11 ABI rebuilds and FTBFS packages

[David Howells]

Anything that depends on cross-gcc for C++ might also be affected.  I recently
moved cross-gcc to gcc-5 (there was lag behind the gcc rpm due to breakage in
the arches the base gcc package doesn't build).

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

F22 cross-gcc is upgraded to gcc-5.1.1 to match the F22 gcc package

[David Howells]

This affects at least the following packages:

ipxe, seabios, sgabios, openbios, SLOF

Rawhide is also upgraded thusly.

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

Is it too late in the F22 cycle to upgrade cross-gcc to gcc-5?

[David Howells]

It's taken quite a long time to sort out the bugs in gcc-5 with regard to
lesser-used arches, so I've only just managed to get cross-gcc in rawhide
upgraded to gcc-5, despite the main gcc package having got there a while ago.

Is it too late in the F22 cycle now to upgrade cross-gcc there to gcc-5?  I'm
not entirely sure what depends on it or how to find out?

David
-- 
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: Is it too late in the F22 cycle to upgrade cross-gcc to gcc-5?

[David Howells]

Josh Boyer jwbo...@fedoraproject.org wrote:

 I don't think anything in the distro depends on the cross compilers.
 There's no associated Change, etc.  Unless there's something I'm
 missing, you should be able to update them, build, and file an update
 in Bodhi to get the appropriate karma.

I was under the impression there was some boot-time stuff that depended on
them, but I don't remember which package and I'm not sure how to find out
barring asking on this list.

David
-- 
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: Is it too late in the F22 cycle to upgrade cross-gcc to gcc-5?

[David Howells]

Cole Robinson crobi...@redhat.com wrote:

 FWIW qemu firmware pacakges build with cross-gcc: ipxe, seabios, SLOF,
 openbios. We want to build for the target architecture but ship as noarch,
 since the roms aren't used by the host machine but only used by qemu-system-*,
 which should run on any host arch.

Which of the cross compilers do these use?

David
-- 
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: Is it too late in the F22 cycle to upgrade cross-gcc to gcc-5?

[David Howells]

Cole Robinson crobi...@redhat.com wrote:

 ipxe, seabios, sgabios: binutils-x86_64-linux-gnu gcc-x86_64-linux-gnu
 openbios: gcc-powerpc64-linux-gnu gcc-sparc64-linux-gnu
 SLOF: gcc-powerpc64-linux-gnu

They all build on x86_64 F21 with the new cross gcc.

David
-- 
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: Reason why non-commiters are not allowed to create buildroot overrides?

[David Howells]

Susi Lehtola jussileht...@fedoraproject.org wrote:

 The reason why buildroot overrides can't be made by anyone is that the
 maintainer might not want people to build packages against the new version, if
 for example it breaks things.

Should the broken new version be made unavailable in that case then?

David
-- 
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: gcc5 ICE xserver build on ARM

[David Howells]

David Airlie airl...@redhat.com wrote:

 Not sure how best to proceed.

Can the software be cross-compiled?  If so, I could provide you with a
cross-compiler.

David
-- 
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: Can rpmbuild produce a 'build logs' rpm also?

[David Howells]

I have raised a bz related to this:

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

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

Can rpmbuild produce a 'build logs' rpm also?

[David Howells]

Can rpmbuild be taught to produce a 'build logs' rpm (or tarball or something)
that isn't automatically added to the installation set by koji/bodhi and that
can get generated even in the event of a build failure?

I have seen two examples of where this could be useful:

 (1) gcc-5 dumps a whole chunk of tar'd, bzip'd and uuencoded testing logs to
 stdout because it has nowhere else to put them.

 (2) I'm seeing a config failure building cross-gcc on ARM that doesn't occur
 on x86_64 or i686 - but it happens in koji where I can't get at the
 config.log to see what happened.

David
-- 
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: Can rpmbuild produce a 'build logs' rpm also?

[David Howells]

Richard W.M. Jones rjo...@redhat.com wrote:

 I don't think an RPM would help.  However it would be nice if Koji
 allowed you to pull files from the build tree, especially after a
 failure.

Even if it just grabbed every file ending in .log from the build tree, that
might be useful.

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

Re: F22 System Wide Change: GCC5

[David Howells]

Jaroslav Reznik jrez...@redhat.com wrote:

 Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.

Does cross-gcc need to switch simultaneously?  Some packages are built with
that, I believe.

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

Re: F22 Self Contained Change: Wine to use mesa Direct3D

[David Howells]

Jaroslav Reznik jrez...@redhat.com wrote:

 Gallium Nine implements the d3d9 API with Gallium 
 internal API, which maps better to d3d9 than OpenGL.

Does it pass D3D9 requests down to the graphics card where possible?

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

Upgrading cloog to 0.18.1 for {,cross-}{gcc,binutils}

[David Howells]

Would there be any problem with upgrading cloog to 0.18.1 so that binutils,
gcc, cross-binutils and cross-gcc can use it?  Also, should I put isl-0.12.2
into it's own package or should it be added to cloog?

Or should I make a gcc-cloog (and gcc-isl)?

David
-- 
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: Upgrading cloog to 0.18.1 for {,cross-}{gcc,binutils}

[David Howells]

Jakub Jelinek ja...@redhat.com wrote:

 What do binutils need cloog/isl for btw?

I'm not sure, but in binutils/configure, I see:

with_cloog
with_isl
with_isl_include
with_isl_lib
enable_isl_version_check
with_cloog_include
with_cloog_lib
enable_cloog_version_check

It's possible it doesn't actually use cloog:

warthog2grep -rl cloog *
ChangeLog
config/ChangeLog
config/cloog.m4
config/isl.m4
configure
configure.ac
Makefile.def
Makefile.in
Makefile.tpl

'isl' turns up a lot more (it matches things like 'islower'), but excluding
most obvious false positives shows that isl probably isn't actually used
either.

David
-- 
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: Upgrading cloog to 0.18.1 for {,cross-}{gcc,binutils}

[David Howells]

Jakub Jelinek ja...@redhat.com wrote:

 The toplevel configure is shared with gcc.  That doesn't mean anything
 built in binutils actually uses it.

Ah, ok.

 BTW, cloog 0.18.3 has been released 2 days ago, perhaps it is usable with
 latest 4.8.x/4.9.x.  Note GCC 5.x will only need isl and not cloog.

Sounds like ISL should be its own package then.  Does gcc need patching to use
isl-0.14?

David
-- 
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: Upgrading cloog to 0.18.1 for {,cross-}{gcc,binutils}

[David Howells]

Jakub Jelinek ja...@redhat.com wrote:

 What do binutils need cloog/isl for btw?

Hmmm...

/usr/lib64/libisl.so.13.1.0-gdb.py
/usr/lib64/libisl.so.13.1.0-gdb.pyc
/usr/lib64/libisl.so.13.1.0-gdb.pyo

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

What are the ELF shared lib symbol versioning best practices?

[David Howells]

Is there a good description of ELF shared library symbol versioning best
practices somewhere?

In particular, under what conditions do you need to create a new section in
the versioning file given to the linker's --version-script option when new
symbols are added?

And what do you do if you've done it wrong?

For example, in libkeyutils, I added a couple of symbols to KEYUTILS_1.4 when
I should perhaps have created KEYUTILS_1.5 and added them there:


http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=49249ce7d84a967fcdc06fbe6bf1d0cf89ac5215

I have been given a patch to move these symbols to KEYUTILS_1.5, but checking
the keyctl program with readelf -s, I see:

47:  0 FUNCGLOBAL DEFAULT  UND 
recursive_session_key_sca@KEYUTILS_1.4 (7)

so I would guess applying this patch would break anything that uses this.

I assumed that adding them to KEYUTILS_1.4 would be okay because nothing
would've tried to use them previously because they didn't exist in any
version.

David
-- 
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: Future changes in the new package and new branch processes

[David Howells]

Pierre-Yves Chibon pin...@pingoured.fr wrote:

 * packager creates the scm-request and set fedora-cvs flag to ?

I find this step counter intuitive.  I accidentally set it to '+' rather than
'?' and then was confused about why things weren't progressing.  Can it be
split into two flags?  On requesting git creation and one showing that git
creation has been performed?

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

The xtrace package needs to be removed from Fedora

[David Howells]

Hi,

The xtrace package has been renamed to the x11trace package due to a collision
with the name of a glibc tool.  The xtrace package should now be removed from
Fedora.

I can see a fedpkg retire option for removing it from Rawhide, but is it
possible to remove it now from F21 and earlier?

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

Re: The xtrace package needs to be removed from Fedora

[David Howells]

David Howells dhowe...@redhat.com wrote:

 I can see a fedpkg retire option for removing it from Rawhide

Which doesn't work, possibly due to a script error:

ERROR:rpkg:Could not retire package: 'Namespace' object has no 
attribute 'msg'

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

Re: The xtrace package needs to be removed from Fedora

[David Howells]

David Howells dhowe...@redhat.com wrote:

  I can see a fedpkg retire option for removing it from Rawhide
 
 Which doesn't work, possibly due to a script error:
 
   ERROR:rpkg:Could not retire package: 'Namespace' object has no 
 attribute 'msg'

Fixed in fedpkg-1.18-1 (bz 1107646).

David
-- 
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: are compiler flags being honored?

[David Howells]

Dhiru Kholia dhiru.kho...@gmail.com wrote:

 In Fedora, we recently enabled -fstack-protector-strong in system rpm
 configuration - but are all packages using this enhanced hardening
 feature?

What's the performance overhead of enabling this for everything?

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

cross-gcc is updated to gcc-4.9.0 in updates-testing for F19+

[David Howells]

So anyone that is using it to build their own packages, if you could check it
in the next three weeks.

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

Odd debugedit message: -b arg has to be either the same length as -d arg, or more than 1 char longer

[David Howells]

I'm seeing this message:

extracting debug info from 
/home/dhowells/rpmbuild/BUILDROOT/cross-gcc-4.9.0-2.fc21.x86_64/usr/lib/gcc/hppa-linux-gnu/4.9.0/libcloog-isl.so.4
/usr/lib/rpm/debugedit: -b arg has to be either the same length as -d arg, or 
more than 1 char longer

but only on some machines.  Anyone know what it portends?

rpm -qf /usr/lib/rpm/debugedit
rpm-build-4.11.2-2.fc20.x86_64

on both machines I've tried it on.

David
-- 
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: Odd debugedit message: -b arg has to be either the same length as -d arg, or more than 1 char longer

[David Howells]

Dan Horák d...@danny.cz wrote:

 as a user or root? IIRC building as root leads to strange errors
 sometimes

As a user in both cases.

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

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

[David Howells]

DJ Delorie d...@redhat.com wrote:

  Welcome to the 21st century!
 
 Do we have different eyes and brains than we did last century?
 Because otherwise, excessively wide paragraphs are just as hard to
 read now as they were then.

But we do have wide logfile excerpts that are much easier to read if they
don't get word-wrapped.

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

Announcing an X11 protocol tracing package

[David Howells]

xtrace, an X11 protocol tracing package that is already available in Debian is
now also available in updates-testing for F20 and Rawhide.

xtrace-1.3.1-5.fc20 newpackage  testing 2014-03-30

This is used by running a program under xtrace, eg:

xtrace xterm

The xtrace program then acts as a dummy/proxy X server to the program it runs,
setting DISPLAY appropriately.  It can also be run as a standalone proxy for
processes to connect to:

xtrace -D :9

The output appears on stderr or can be dumped into a file.  It looks like:

000::01c7: 20: Request(77): ImageText16 drawable=0x07a0002d gc=0x07a0002c x=2 
y=13 string=0x2000;
000::01c8: 32: Request(65): PolyLine coordinate-mode=Previous(0x01) 
drawable=0x07a0002d gc=0x07a00032 points={x=2 y=2},{x=5 y=0},{x=0 y=12},{x=-5 
y=0},{x=0 y=-12};
000::01c8: Event PropertyNotify(28) window=0x07a00022 atom=0x14d(unrecognized 
atom) time=0x3dfa5e3f state=NewValue(0x00)
000::01c8: Event PropertyNotify(28) window=0x07a00022 atom=0x1c7(unrecognized 
atom) time=0x3dfa5e3f state=NewValue(0x00)
000::01c8: Event PropertyNotify(28) window=0x07a00022 atom=0x1cf(unrecognized 
atom) time=0x3dfa5e40 state=NewValue(0x00)

David
-- 
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: Packages with missing %check

[David Howells]

Alexander Todorov atodo...@redhat.com wrote:

 How about making %check a packaging requirement in all cases - run tests or
 add a comment explaining why not, how to run them (e.g. make test) or why
 there are no tests for this package.

Does %check install the package and run the tests as root?  For the keyutils
package that I maintain, this would be a requirement to be able to run the
testsuite because:

 (1) There are certain operations that cannot be tested if you're not root.

 (2) The kernel must be able to upcall to executables installed by the rpm.

I imagine this applies to some other packages also.

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

Re: f20, anaconda, net install and video out of range ....

[David Howells]

Paul Wouters p...@nohats.ca wrote:

 dracut-initqueue[474]: Warning: /dev/rot does not exist.

Is this an error message that needs fixing up?

David
-- 
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: Heads up; F22 will require applications to ship appdata to be listed in software center

[David Howells]

Richard Hughes hughsi...@gmail.com wrote:

 As the subject suggests, Fedora 22 will require applications to have a
 long description to be shown in the software center.

What constitutes an 'application' in this sense?  Does 'gcc' count for
instance?  How about 'find'?

David
-- 
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: Should a working fedup in Fedora N's stable repository be a release criterion for N+1?

[David Howells]

Adam Williamson awill...@redhat.com wrote:

   - Install fedup 0.7.0
   - Try it and watch it fail or hang
   - Update to fedup 0.8.0 from updates-testing
   - Run fedup
  
  ends up downloading all rpms *twice* a sucking up a correspondingly
  immense amount of disk space.
 
 Um, I'm fairly sure it doesn't. It only re-downloads stuff that's
 different from the previous run.

There was a bug whereby fedup-0.7.3 would delete all the downloaded RPMs after
failing to install them.  See:

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

This is reportedly fixed in fedup-0.8.0.

David
-- 
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: Can we have better ssh fingerprint collision messages?

[David Howells]

valent.turko...@gmail.com valent.turko...@gmail.com wrote:

 I really enjoy working with ssh on Ubuntu just for this simple reason,
 they have user friendly ssh fingerprint collision messages:
 
 $ ssh root@192.168.1.1
 @@@
 @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
 @@@
 IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
 Someone could be eavesdropping on you right now (man-in-the-middle attack)!
 It is also possible that a host key has just been changed.
 The fingerprint for the RSA key sent by the remote host is
 c0:3b:b2:60:a6:e2:5e:97:aa:ae:ec:d2:ca:ba:27:1b.
 Please contact your system administrator.
 Add correct host key in /home/valent/.ssh/known_hosts to get rid of
 this message.
 Offending RSA key in /home/valent/.ssh/known_hosts:8
 
 
 I really miss this feature when I return back to Fedora.
 How hard would be to make this behavior default for Fedora also?

I see the message with Fedora.

David
-- 
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: Protection from merge commits

[David Howells]

Pete Zaitcev zait...@redhat.com wrote:

 Thought I was careful about them, but apparently not enough. So, does
 anyone have a script that can be attached to git hooks, reliably detects
 an attempt to push merge nodes, then bails the push?

I presume that that would prevent valid merging between branches in the repo?

For example, I have a reasonably simple package that I apply patches to in the
master branch and then merge everything back into the last few Fedora version
branches.  Usually merge just fast-forwards the branch, but occasionally there
has been a mass-rebuild that threw an extra commit in that then needs dealing
with.  I presume I would then need to pick all the commits instead?

David
-- 
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: Mission Impossible #1: qt without gtk

[David Howells]

Eugene Pivnev ti.eug...@gmail.com wrote:

 3. rpm -qa | grep gnome | xargs sudo yum remove
 * git (???)

gitk, I imagine.

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

Re: Expanding the list of Hardened Packages

[David Howells]

John Reiser jrei...@bitwagon.com wrote:

 It's also easy to see the mechanism:
 $ cat foo.c
 extern int a[];
 
 void foo(int j) { a[j]=j; }
 $ gcc -m32 -fPIE -O -S foo.c
 $ cat foo.s  # edited for brevity
 foo:  # 25 bytes; about 15 cycles  (incl. 3*3 cycles data cache fetch latency)
   call__x86.get_pc_thunk.cx
   addl$_GLOBAL_OFFSET_TABLE_, %ecx
   movl4(%esp), %eax
   movla@GOT(%ecx), %edx
   movl%eax, (%edx,%eax,4)
   ret

Yes, but...  Am I right in thinking that a page containing the above can be
shared, but...

 $ gcc -m32 -O -S foo.c
 $ cat foo.s  # edited for brevity
 foo:  # 12 bytes; about 6 cycles  (incl. 1*3 cycles data cache fetch latency)
   movl4(%esp), %eax
   movl%eax, a(,%eax,4)
   ret
 $

... a page containing this cannot because it must be relocated prior to
execution?

Admittedly, it is possible that if the address stored by the linker for 'a' is
the same as 'a' is loaded at, then the loader might not need to adjust the
instruction - but if we randomise the load addresses of various binaries, then
that is unlikely to be true.

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

Re: system freezes after loading gdm/gnome

[David Howells]

Jan Dvořák mor...@anilinux.org wrote:

 I am running rawhide for fun and since a few days ago a few seconds
 after starting gdm the whole system freezes. I am sorry that I can't
 really pinpoint the exact update as I suspend and this only manifested
 after a reboot.

Do you see the same problem starting KDE instead?

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

Re: Anything changed on rawhide builders recently? Can't build ladvd

[David Howells]

David Howells dhowe...@redhat.com wrote:

  A better way to do this might be to make the header installation discard the
  _UAPI prefix that got added.
 
 As the attached patch.

Now upstream.

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

Re: Anything changed on rawhide builders recently? Can't build ladvd

[David Howells]

Tomasz Torcz to...@pipebreaker.pl wrote:

 In file included from cli.c:20:0:
 common.h:152:8: error: redefinition of 'struct sysinfo'
 In file included from /usr/include/linux/kernel.h:4:0,
  from /usr/include/linux/sysctl.h:25,
  from /usr/include/sys/sysctl.h:43,
  from common.h:50,
  from cli.c:20:
 /usr/include/linux/sysinfo.h:7:8: note: originally defined here

The attached patch to the kernel should fix this.  The problem is that many of
the userspace API files all got their guards renamed inside of the kernel when
they got split out into separate files (rather than being renamed).

A better way to do this might be to make the header installation discard the
_UAPI prefix that got added.

David
---
commit 24d4756373d825c43c5f5c3cf1fc6737943abf53
Author: David Howells dhowe...@redhat.com
Date:   Wed Nov 7 16:40:14 2012 +

UAPI: The guards on linux/types.h and linxu/kernel.h are used by glibc

The guards on linux/types.h and linux/kernel.h are used by glibc, and so
shouldn't have been changed for the UAPI variants of those headers.  Change
those guards back and alter the ones on the KAPI variants instead.

Interestingly, sys/sysctl.h shows checks on linux/list.h and 
linux/compiler.h,
even though those headers aren't exported.

Signed-off-by: David Howells dhowe...@redhat.com

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index a123b13..e0e6839 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_KERNEL_H
-#define _LINUX_KERNEL_H
+#ifndef _KAPI_LINUX_KERNEL_H
+#define _KAPI_LINUX_KERNEL_H
 
 
 #include stdarg.h
diff --git a/include/linux/types.h b/include/linux/types.h
index 1cc0e4b..1e99075 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_TYPES_H
-#define _LINUX_TYPES_H
+#ifndef _KAPI_LINUX_TYPES_H
+#define _KAPI_LINUX_TYPES_H
 
 #define __EXPORTED_HEADERS__
 #include uapi/linux/types.h
@@ -212,4 +212,4 @@ struct callback_head {
 #define rcu_head callback_head
 
 #endif /*  __ASSEMBLY__ */
-#endif /* _LINUX_TYPES_H */
+#endif /* _KAPI_LINUX_TYPES_H */
diff --git a/include/uapi/linux/kernel.h b/include/uapi/linux/kernel.h
index 321e399..642d1e9 100644
--- a/include/uapi/linux/kernel.h
+++ b/include/uapi/linux/kernel.h
@@ -1,5 +1,5 @@
-#ifndef _UAPI_LINUX_KERNEL_H
-#define _UAPI_LINUX_KERNEL_H
+#ifndef _LINUX_KERNEL_H
+#define _LINUX_KERNEL_H
 
 #include linux/sysinfo.h
 
@@ -10,4 +10,4 @@
 #define __ALIGN_KERNEL_MASK(x, mask)   (((x) + (mask))  ~(mask))
 
 
-#endif /* _UAPI_LINUX_KERNEL_H */
+#endif /* _LINUX_KERNEL_H */
diff --git a/include/uapi/linux/types.h b/include/uapi/linux/types.h
index acf0979..a9b87a8 100644
--- a/include/uapi/linux/types.h
+++ b/include/uapi/linux/types.h
@@ -1,5 +1,5 @@
-#ifndef _UAPI_LINUX_TYPES_H
-#define _UAPI_LINUX_TYPES_H
+#ifndef _LINUX_TYPES_H
+#define _LINUX_TYPES_H
 
 #include asm/types.h
 
@@ -53,4 +53,4 @@ typedef __u32 __bitwise __wsum;
 #define __aligned_le64 __le64 __attribute__((aligned(8)))
 
 #endif /*  __ASSEMBLY__ */
-#endif /* _UAPI_LINUX_TYPES_H */
+#endif /* _LINUX_TYPES_H */

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

Re: Anything changed on rawhide builders recently? Can't build ladvd

[David Howells]

David Howells dhowe...@redhat.com wrote:

 A better way to do this might be to make the header installation discard the
 _UAPI prefix that got added.

As the attached patch.

David
---
commit 75a88e14a97d239a47cbd0fc55fc23416007d733
Author: David Howells dhowe...@redhat.com
Date:   Wed Nov 7 17:14:14 2012 +

UAPI: Strip the _UAPI prefix from header guards during header installation

Strip the _UAPI prefix from header guards during header installation so that
any userspace dependencies aren't affected.  glibc, for example, checks for
linux/types.h, linux/kernel.h, linux/compiler.h and linux/list.h - though 
the
last two aren't actually exported.

Signed-off-by: David Howells dhowe...@redhat.com

diff --git a/scripts/headers_install.pl b/scripts/headers_install.pl
index 239d22d..6c353ae 100644
--- a/scripts/headers_install.pl
+++ b/scripts/headers_install.pl
@@ -42,6 +42,9 @@ foreach my $filename (@files) {
$line =~ s/(^|\s)(inline)\b/$1__$2__/g;
$line =~ s/(^|\s)(asm)\b(\s|[(]|$)/$1__$2__$3/g;
$line =~ s/(^|\s|[(])(volatile)\b(\s|[(]|$)/$1__$2__$3/g;
+   $line =~ s/#ifndef _UAPI/#ifndef /;
+   $line =~ s/#define _UAPI/#define /;
+   $line =~ s!#endif /[*] _UAPI!#endif /* !;
printf {$out} %s, $line;
}
close $out;
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads-up: Kerberos default user credential cache location is changing

[David Howells]

Stephen Gallagher sgall...@redhat.com wrote:

 1) Credential caches are now stored in a tmpfs location. This is a
 security feature, as a stolen laptop may not be booted in single-user
 mode to extract a valid TGT.

Is it?  Can't tmpfs move stuff arbitrarily out to swap?

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

Is it impossible to use the same build override twice with bodhi?

[David Howells]

I need to update my cross-gcc package, but that depends on my cross-binutils
package which is still in updates-testing (should the build process fail, even
though it is pushed to updates-testing?).

To do this I need to add a build override with bodhi for the cross-binutils
package - however, this doesn't work, presumably because I've added it before
and the override has now expired.

If I try adding the override, I see:

warthogbodhi -r F16 -o cross-binutils-2.22.52.0.3-1.fc16 -N Required 
to build cross-gcc
Error: buildroot override for u'cross-binutils-2.22.52.0.3-1.fc16' 
already exists

If I list the overrides I have currently in operation, I see:

warthogbodhi --my-overrides
0 Buildroot Overrides submitted by dhowells
===

I can see the expired override:

warthogbodhi --my-overrides --show-expired
4 Buildroot Overrides submitted by dhowells
===

[ cross-binutils-2.22.52.0.3-1.fc16 ]
 * Notes: Required to build cross-gcc
 * Submitter: dhowells
 * Submitted: 2012-05-31 16:02:34
 * Expiration: 2012-06-03 00:00:00
 * Expired: 2012-06-03 00:06:17
...

but I can't get rid of it.  I've tried:

warthogbodhi -r F16 -E cross-binutils-2.22.52.0.3-1.fc16
Override cross-binutils-2.22.52.0.3-1.fc16 already expired!

but that doesn't work (unsurprisingly).

Any suggestions?  Do I have to either advance the version of the cross-binutils
package or commit it to fedora-updates?

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

Re: Is it impossible to use the same build override twice with bodhi?

[David Howells]

Julio Merino j...@julipedia.org wrote:

 Changing the end date of the expired override will re-enable it.

That works, thanks!

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

How do you use fedpkg chain-build for released Fedorae?

[David Howells]

Hi,

I'm having a problem building my cross-compiler gcc package as it requires a
cross-compiler binutils package to be built first.

I managed to build the rawhide build with:

fedpkg chain-build --target=rawhide cross-binutils :

but chain-build doesn't work for F16 and F17 as far as I can tell.  If I try
building for F17 without specifying a target, I get:

warthogfedpkg chain-build cross-binutils :
Could not execute chainbuild: Packages in destination tag 
f17-updates-candidate are not inherited bybuild tag f17-build

However, it does let me run:

fedpkg build

in the cross-binutils tree and then the cross-gcc tree independently.
However, the cross-gcc build fails because it can't find the cross-binutils
package to install.

DEBUG util.py:257:  Error: No Package found for cross-binutils-common 
= 2.22

I've tried giving chain-build a variety of different --target options to see
if that makes the difference, but it doesn't seem to:

fedpkg chain-build --target=f17 cross-binutils :
Could not execute chainbuild: Packages in destination tag 
f17-updates-candidate are not inherited bybuild tag f17-build

fedpkg chain-build --target=f17-candidate cross-binutils :
Could not execute chainbuild: Packages in destination tag 
f17-updates-candidate are not inherited bybuild tag f17-build

fedpkg chain-build --target=f17-updates cross-binutils :
Could not execute chainbuild: Unknown build target: f17-updates

fedpkg chain-build --target=f17-updates-candidate cross-binutils :
Could not execute chainbuild: Unknown build target: 
f17-updates-candidate

fedpkg chain-build --target=f17-updates-testing cross-binutils :
Could not execute chainbuild: Unknown build target: f17-updates-testing

fedpkg chain-build --target=fedora-17 cross-binutils :
Could not execute chainbuild: Unknown build target: fedora-17

Can anyone suggest how to do it right?

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

Re: How do you use fedpkg chain-build for released Fedorae?

[David Howells]

Jon Ciesla limburg...@gmail.com wrote:

 You can only chain-build on rawhide, you want a buildroot override.
 
 http://fedoraproject.org/wiki/Bodhi/BuildRootOverrides

Ah, yes.  I remember now.  Can fedpkg and koji chain-build --help texts be
updated to note this?

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

Re: Headsup! krb5 ccache defaults are changing in Rawhide

[David Howells]

Stephen Gallagher sgall...@redhat.com wrote:

 with the upcoming Fedora 18 release (currently Rawhide) we are going to
 change the place where krb5 credential cache files are saved by default.
 
 The new default for credential caches will be the /run/user/username
 directory.

Alternatively, you could put them in the kernel keyrings: make a keyring under
the current session keyring and store them in there.  There is code there to
do that.  That then makes them per-login-session and allows local overriding
of the credentials by creating a new session keyring.

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

Re: Need some advice on best packaging practices for a tricky package?

[David Howells]

Kevin Kofler kevin.kof...@chello.at wrote:

 Just ignore rpmlint there. :-) If you have proper Requires in place to 
 ensure the symlink targets will actually be installed, it's fine.

I do, so I'll just ignore them.

 Yes, it's called noarch subpackages and has been supported in Fedora for a 
 while. Just declare the subpackage as:
 BuildArch: noarch
 
 Note that the main package MUST be arch-specific if you have any arch-
 specific subpackages, you cannot have arch-specific subpackages of a noarch 
 package, only noarch subpackages of an arch-specific package.

Ah.  That's where I was going wrong.

 /usr/target is the standard location for cross toolchains, and cross 
 toolchains (and ONLY cross toolchains) are allowed to use such a location 
 (though IIRC it never got officially codified in our guidelines because the 
 cross-compiler guidelines never got formalized; but de facto, the existing 
 cross compiler packages already use this).
 
 /usr/cross/target is entirely non-standard and IMHO a bad idea.

Yeah.  I was trying to avoid clashing with other toolchains, but I guess the
name of the binary in /usr/bin/ is likely to do that anyway.

Can rpmlint be altered to accept apparent target-named directories in /usr/?

 There is no requirement that binaries have manpages in Fedora. Though in 
 this case, just link the manpage.
 
 The purpose of ld.bfd is that this is always the regular BFD-based GNU ld 
 whereas just ld can be e.g. gold.

I see.

   (8) The package installs gpl.7.gz and similar common-looking manpages in
   man7.
   Is this a bad idea, just in case there's a conflict with another
   package wanting to do the same?
 
 Yes. Don't package this. We don't normally ship licenses as manpages. See 
 the next paragraph for what to do instead.
 
   Is there/ should there be a common GPL licence text RPM with these
   files in it that RPMs can be made dependent on?
 
 Ship the license with %doc COPYING, in a package which is required by all 
 the other subpackages. (If given only a file name without a path, %doc 
 automatically creates a unique path for the package to ship the text file 
 in.) For legal reasons, every package MUST carry its license in at least one 
 subpackage, and ALL subpackages must either carry the license or Require one 
 of the subpackages which do. A common license package for the whole 
 distribution (like Debian does it) does NOT comply with the GPL. The 
 packages are not necessarily distributed as part of the distribution, and 
 the GPL explicitly requires every GPLed package to carry a copy of the GPL, 
 no matter whether the distribution already has one.

Fair enough.

Interestingly, the core binutils does not seem to comply with this:

warthogrpm -ql binutils-devel binutils | grep -i gpl
warthog1rpm -ql binutils-devel binutils | grep -i licen[cs]e
warthog1rpm -ql binutils-devel binutils | grep -i COPYING
warthog1

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

Need some advice on best packaging practices for a tricky package?

[David Howells]

Hi,

I've produced a pair of specfiles that I'm aiming to get into Fedora that take
the standard Fedora binutils and gcc SRPM sources and patches and produce a
series of cross-compilation binutils and gcc RPMs for all the Linux kernel
arches that I can manage to get working.

The inclusion request BZs can be found here:

cross-binutils: https://bugzilla.redhat.com/show_bug.cgi?id=761619
cross-gcc: https://bugzilla.redhat.com/show_bug.cgi?id=766166

However, there are a number of warnings that rpmlint produces that I'd like
some advice on.  For cross-binutils:

 (1) As each set of cross-binutils manual pages is the same as every other set
 (and the core set come to that), I've stuffed the base manual pages in
 their own RPM and put symlinks to them from the individual arch RPMs.

 However, this results in lots of dangling-relative-symlink warnings,
 even though the targets are in another RPM passed to rpmlint.

 Can I make rpmlint ignore these?

 (2) The manual pages and translation files RPM gets the warning no-binary -
 which is true.

 Is there any way to make the spec file produce a noarch RPM at the same
 time as a bunch of binary RPMs?

 (3) The binutils installation installs some hard links and these cause rpmlint
 to issue cross-directory-hard-link warnings.  For instance the following
 are hardlinked together:

/usr/cross/alpha-linux-gnu/bin/ar
/usr/bin/alpha-linux-gnu-ar

 Should I manually turn the hardlinked variants into copies?  Or symlink
 between them?

 (4) The binutils installer would like to create /usr/target/.  I'm creating
 /usr/cross/target/ to group all the stuff together into one dir under
 /usr.  However, rpmlint likes neither of these and gives a
 non-standard-dir-in-usr warning.

 Should I put the stuff somewhere else?  /usr/lib/ or /usr/libexec/
 perhaps?  I've tried to persuade the cross-gcc to use the things in
 /usr/bin/, but it really doesn't want to do that.

 (5) The binutils installer creates a supplementary target-ld.bfd that's a
 hardlink to target-ld.  It doesn't, however, supply a manual page for
 this.

 Is there a way to tell rpmlint that this is correct?  Or should I just
 discard the ld.bfd entirely?  What is it for, anyway?  I could even link
 the manual page, I suppose.

And for cross-gcc:

 (6) I see devel-file-in-non-devel-package warnings for bits of gcc's
 internal workings (such as libgcc.a).  These are required by gcc to be
 able to work at all, so can't sensibly be split into a separate package.

 Is there a way to tell rpmlint that these belong here?

 (7) The common manpage and translation RPM triggers a no-binary warning as
 for cross-binutils.

 (8) The package installs gpl.7.gz and similar common-looking manpages in man7.
 Is this a bad idea, just in case there's a conflict with another package
 wanting to do the same?

 Is there/ should there be a common GPL licence text RPM with these files
 in it that RPMs can be made dependent on?

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

Re: How to prevent a binary from being stripped by rpmbuild?

[David Howells]

Josh Boyer jwbo...@gmail.com wrote:

 You might also want to redefine %{__strip} to the appropriate
 cross-strip utility, or /bin/true.  Something like:
 
 %define debug_package %{nil}
 %define __strip /bin/true

Ah, so I can make a shell script to apply the appropriate strip binary...

Jan Kratochvil jan.kratoch...@redhat.com wrote:

 rpmbuild uses eu-strip, not strip.  Therefore elfutils, not binutils.
 See: /usr/lib/rpm/find-debuginfo.sh

Interesting:

+ eu-strip -g 
/data/cross-gcc/cross-gcc/rpmbuild/BUILDROOT/cross-gcc-4.6.2-1.fc16.1.x86_64/usr/lib64/gcc/powerpc64-linux-gnu/4.6.2/libgcov.a
/data/cross-gcc/cross-gcc/rpmbuild/BUILDROOT/cross-gcc-4.6.2-1.fc16.1.x86_64/strip:
 line 9: 28521 Segmentation fault  eu-strip $*

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