Re: os-prober updates are blocked by missing grub tool, but the maintainer doesn't respond
Hello, Hedayat Vatankhah. Sat, 4 May 2019 03:40:57 +0430 you wrote: > I've even emailed Peter directly, but there is no response You can start non-responsive maintainer procedure. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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?
> 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 use of /afs as the default location to mount a cell's root volume "root.afs" dates back at least as far as 1989. Throughout the 90s /afs became the root of the public global AFS file namespace. Organizations that deployed AFS for private namespaces did use other top-level mounts but all of the worldwide public namespace paths are rooted at /afs regardless of operating system; even AFS on Windows uses the \\AFS UNC path that is canonically equivalent to /afs. I believe that /afs should be added to the FHS as the standard mount for the public AFS and AuriStorFS file namespace. All recent AFS-family clients will interpret the path component below /afs/ as a cell name and search for the cell's location servers in DNS using SRV or AFSDB records. This permits any individual or organization that controls a domain to standup storage that can be accessed from any internet connected device with close to zero configuration provided the required access requirements are met. Sincerely, Jeffrey Altman ___ 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?
> On Fri, May 03, 2019 at 03:25:25PM -0400, Nico Kadel-Garcia wrote: > > (I put all your comments into one block) > > None of the problems you've described sound familiar to me at all, > however I've only been using AFS since 1999. Unsurprisingly, there > have been improvements in the code, and the in-kernel AFS client is a > completely different client than the Transarc client from your era and > also different from a modern OpenAFS client. The AFS kernel modules of the IBM era are known to have suffered from the following limitations and implementation flaws: 1. distributed lock hierarchy violations resulting in distributed dead locks 2. /afs was backed by the configured cell's "root.afs" volume. If there were connectivity issues or the fileservers failed to serve the volume, then there could be extended timeouts 3. most afs servers were configured to restart every Sunday morning and required the equivalent of "fsck" on every afs volume before restarting which would result in volumes becoming unavailable for an extended period of time. 4. all location server address information was stored in local configuration files. If IP address changes were not reflected in local configuration updates, cache managers would experience timeouts or loss of access. These are just a few of the many issues that have been addressed over the decades. kafs is a 100% clean room implementation specifically designed for and integrated with the Linux kernel. kafs does not mount "root.afs" volumes instead it follows the "dynamic root" model whereby /afs/ directory entries are evaluated on demand as cell names using a combination of DNS and local configuration files. OpenAFS and AuriStorFS servers are rarely configured for weekly restarts and when they do restart the startup time is in fractions of a second instead of hours. kafs attempts to be as "zero config" as possible. I'm not sure if there is anything more than specifying the name of the top-level mount point. In any case, these implementation defects from the 90s should have no bearing on the packaging of kafs-client for Fedora. The AF_RXRPC and AFS kernel features have been shipping in Fedora kernels distributed with F28, F29, and F30. The kafs-client package is the final piece required to permit end users to choose the native Linux implementation over third-party, out-of-tree, GPL2 license incompatible implementations. Sincerely, Jeffrey Altman ___ 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: os-prober updates are blocked by missing grub tool, but the maintainer doesn't respond
On Fri, May 3, 2019 at 7:11 PM Hedayat Vatankhah wrote: > > Dear Peter (which most likely won't read) and all, > > > I've opened a but more than a year ago about missing grub tool in > Fedora[1], > > and I've even emailed Peter directly, but there is no response. Upstream > os-prober > > now requires grub2-mount to function, and therefore Fedora os-prober is > effectively > > not maintained. It even have started to fail on my own system. > > > I kindly ask someone to do something about it. Or at least let me know > to orphan > > the package. > > > Regards, > > Hedayat (os-prober maintainer) > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1471267 > I've proposed a Dist-Git patch to resolve the issue in the bug report. But when I attached my patch, Bugzilla did not indicate Peter was emailed about it. It would not surprise me if he never knew this bug was filed because it's not emailing him. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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
os-prober updates are blocked by missing grub tool, but the maintainer doesn't respond
Dear Peter (which most likely won't read) and all, I've opened a but more than a year ago about missing grub tool in Fedora[1], and I've even emailed Peter directly, but there is no response. Upstream os-prober now requires grub2-mount to function, and therefore Fedora os-prober is effectively not maintained. It even have started to fail on my own system. I kindly ask someone to do something about it. Or at least let me know to orphan the package. Regards, Hedayat (os-prober maintainer) [1] https://bugzilla.redhat.com/show_bug.cgi?id=1471267 ___ 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?
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: Is possible to use caching for livemedia-creator
On Fri, May 03, 2019 at 09:57:51PM +0530, Danishka Navin wrote: > Hi, > > Is it possible to enable caching for livemedia-creator? > Similar to the --cache option in livecd-creator. Neal is correct, there is no way to share a cache between runs. But you can use --proxy to use a caching proxy which can speed things up. If you do that, make sure your kickstarts are using baseurl instead of mirrors so that the requests are consistent and can be cached. -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted ___ 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
module load inside rpmbuild inside docker
Hi,
I wanted to bump the legion package to 19.04.0
(https://bugzilla.redhat.com/show_bug.cgi?id=1705033), however for
some reason all tests segfault with openmpi
(https://koji.fedoraproject.org/koji/taskinfo?taskID=34577005), so I
reported this upstream
(https://github.com/StanfordLegion/legion/issues/533) and included a
minimal dockerfile to reproduce this issue:
FROM fedora:rawhide
RUN dnf install -y spectool wget rpm-build dnf-plugins-core
RUN wget
https://src.fedoraproject.org/fork/junghans/rpms/legion/raw/master/f/legion.spec
RUN spectool -g legion.spec
RUN dnf builddep -y legion.spec
RUN dnf install -y make
RUN rpmbuild -D"_sourcedir ${PWD}" -D"_srcrpmdir ${PWD}" -ba legion.spec
This worked fine on Thursday(?) to reproduce the failing tests in
%check, but now rpmbuild fails at an earlier stage with:
+ module load mpi/mpich-x86_64
++ /usr/share/lmod/lmod/libexec/lmod sh load mpi/mpich-x86_64
Lmod has detected the following error: The following module(s) are unknown:
"mpi/mpich-x86_64"
If I jump into the container interactively (docker run -it ..
/bin/bash), "module load" as well as rpmbuild (and "module load"
inside) works.
If know this is a convoluted case, but any ideas how fix this?
Christoph
--
Christoph Junghans
Web: http://www.compphys.de
___
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?
On Fri, May 3, 2019 at 5:02 PM David Howells wrote: > > 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. > 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? > 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? > 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'm curious what AFS is providing over NFSv4 and autofs based mounts? ___ 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?
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 wr
Re: How to install a mountpoint directory from an rpm?
On Fri, May 03, 2019 at 03:25:25PM -0400, Nico Kadel-Garcia wrote: > On Fri, May 3, 2019 at 5:22 AM David Howells wrote: > > 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. > > 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? > > 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. (I put all your comments into one block) None of the problems you've described sound familiar to me at all, however I've only been using AFS since 1999. Unsurprisingly, there have been improvements in the code, and the in-kernel AFS client is a completely different client than the Transarc client from your era and also different from a modern OpenAFS client. There are legacy isssues with runaway updatedb or find processes getting lost in /afs, but you'd get that in any sufficiently large complex NFS shares with hard mounts. And as with autofs, the dynamic AFS mounting with the kAFS module would not show any subdirectories to be traversed by an automated process. > 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 writing. > (*) Automounting. > (*) Local caching (via fscache). > It does not yet support the following AFS features: > (*) pioctl() system call. > > Does this sound ready for general Fedora use? It looks like the documentation describing the features was last updated in 2009. There's been significant effort in the past year to improve the in-kernel AFS code. I'll ask if maybe we can get that file updated with more recent features. I know that I've been using it exclusively with krb5 tickets for months for read and write. I also know that the pioctl() system call support will never happen, and is being replaced with other methods. -- Jonathan Billings ___ 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?
On Fri, 3 May 2019 at 15:26, Nico Kadel-Garcia wrote: > On Fri, May 3, 2019 at 5:22 AM David Howells wrote: > > > "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 writing. > (*) Automounting. > (*) Local caching (via fscache). > It does not yet support the following AFS features: > (*) pioctl() system call. > > Does this sound ready for general Fedora use? > Sounds more stable than other features we already have in general use. If a large portion of your rant sounds like 'I ate brocolli when I was a kid and it was awful then and I am sure it is awful now.' asking if 'does serving brocolli sound like something Fedora should do?' is not going to get much weight.. especially when we have been serving brocolli in some form for years. Yes, AFS could lock up your system 30 years ago and even 20 years ago. It might even do so now.. but we can do so in at least 10 different ways with containers, virtual machines, or half a dozen other packaged up applications. The whole arguments for or against AFS have not changed in the last 30 years.. And rarely do they go past: did you or your professor go to MIT or CMU? And which was better Andrew or Athena.. -- Stephen J Smoogen. ___ 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?
On Fri, May 3, 2019 at 5:22 AM David Howells 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. > > \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. > 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? 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. > "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 writing. (*) Automounting. (*) Local caching (via fscache). It does not yet support the following AFS features: (*) pioctl() system call. Does this sound ready for general Fedora use? ___ 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: dropping autogenerated dependency on pkg-config
On Fri, May 3, 2019 at 8:18 PM Nicolas Mailhot via devel wrote: > > Le vendredi 03 mai 2019 à 19:59 +0200, Dridi Boukelmoune a écrit : > > On Fri, May 3, 2019 at 1:45 PM Nicolas Mailhot via devel > > wrote: > > > Le vendredi 03 mai 2019 à 12:04 +0100, Tomasz Kłoczko a écrit : > > > > On Fri, 3 May 2019 at 11:04, Nicolas Mailhot via devel > > > > wrote: > > > > [..] > > > > > You're assuming the only use is roolback. It's not > > > > > > > > Point taken. Can you shortly describe other use cases? > > > > > > You use apps in one of those languages that static build by > > > default. > > > There is a security alert in one code component. You want to know > > > which > > > packages in your repo/mirror have been build using the broken piece > > > of > > > source code > > > > Last time we disagreed on this topic my opinion was that static > > linking should imply bundled provides: > > > > Provides: bundled() = > > > > Hopefully something that could be automated for some stacks. > > That makes it stack-specific Bundling in general is very package-specific anyway. > And anyway, the classical compiler attack (compiler that inserts > backdoor while compiling) shows that special-casing some packages for > special tracking does not work, pretty much anything that existed in > the build root need to be tracked because it may be exploited one way > or another, and spead the exploit to everything that used it. I definitely agree with that part, but I have no opinion on where that information should live. Dridi ___ 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: Is possible to use caching for livemedia-creator
On Fri, May 3, 2019 at 1:23 PM Martin Kolman wrote: > > On Fri, 2019-05-03 at 12:40 -0400, Neal Gompa wrote: > > On Fri, May 3, 2019 at 12:28 PM Danishka Navin wrote: > > > Hi, > > > > > > Is it possible to enable caching for livemedia-creator? > > > Similar to the --cache option in livecd-creator. > > > > > > > No. Anaconda (the installer engine) does not support caching, so > > nothing built on top of it can either. > What is caching in this context ? > > Caching the RPMs used to create the image > or caching some intermediate states of image creation, so you don't > have to rerun the whole process for different customizations ? > At the minimum, caching RPMs used to create the image. LiveCD Creator and KIWI both support this, since they use DNF directly. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: HEADS UP: gdb-minimal has replaced gdb-headless in buildroot
- Original Message - > From: "Igor Gnatenko" > To: "Development discussions related to Fedora" > > Cc: "Sergio Durigan Junior" > Sent: Friday, May 3, 2019 6:41:21 PM > Subject: HEADS UP: gdb-minimal has replaced gdb-headless in buildroot > Hello, > https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot has been > implemented just few minutes ago. > Before: > Install 151 Packages > Total download size: 77 M > Installed size: 339 M > After: > Install 139 Packages > Total download size: 54 M > Installed size: 249 M > It should not affect anything (apart from making buildroot composition faster > and smaller size), but let us know if anything breaks :) > -- > -Igor Gnatenko > ___ > 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 That's a nice reduction, as well as a welcome removal of a bootstraping step for python3. Thanks for that! -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: I plan to remove python2-pep8
On Fri, May 03, 2019 at 20:25:01 +0200, Miro Hrončok wrote:
> Bump.
>
> $ dnf repoquery --repo=compose{,-source} --whatrequires python2-pep8
> cachedir-0:1.4-3.fc28.src
I'll retire this. Upstream doesn't want to deal with Python3 and rather
than just removing the testing and dealing with Python2 package
deprecation/removal later too, it's easier to just end it now.
--Ben
___
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: dropping autogenerated dependency on pkg-config
On Tue, Apr 30, 2019, at 10:14 PM, Neal Gompa wrote: > > Second, do you not even know that Mock passes --nodeps to rpmbuild > because the rpmdb in the chroot isn't necessarily compatible with rpm > in the chroot? We currently don't allow rpmbuild to evaluate > dependencies at all. We may change this if Koji switches to producing > bootstrap chroots before producing the build chroot. So right now, > that lookup is not even happening. > Awesome! I love learning how these things work! Thanks for sharing! V/r, James Cassell ___ 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: I plan to remove python2-pep8
On 22. 04. 19 17:53, Miro Hrončok wrote:
Hey. pep8 is no longer released upstream and its successor is called
pycodestyle.
I plan to retire python-pep8, as tracked in [1], however there are still too
many consumers of python3-pep8. On the other hand, python2-pep8 is only
buildrequired by:
cachedir - already FTBFS, not dependent upon
genbackupdata - already FTBFS, fails to install, not dependent upon
ovirt-guest-agent - already FTBFS, not dependent upon outside of subpackages
pylast - python2-pylast is not dependent upon
python-cliapp - python2-cliapp is required by:
cachedir
cmdtest - FTBFS, fails to install, required by:
cachedir
genbackupdata
python-larch - FTBFS, not dependent upon outside of subpackages
genbackupdata
python-larch
Maintainers by package:
cachedir mathstuf
cmdtest salimma
genbackupdata salimma
ovirt-guest-agent evilissimo nyoxi
pylast peter
python-cliapp salimma
python-larch salimma
Packages by maintainer:
evilissimo ovirt-guest-agent
mathstuf cachedir
nyoxi ovirt-guest-agent
peter pylast
salimma cmdtest genbackupdata python-cliapp python-larch
Would you like to take python2-pep8? I'd advice against, please update to Python
3 and/or pycodestyle instead.
This is my attempt to follow [2].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1667200
[2]
https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Process_for_abandoning_Python_2_subpackages
Bump.
$ dnf repoquery --repo=compose{,-source} --whatrequires python2-pep8
cachedir-0:1.4-3.fc28.src
genbackupdata-0:1.9-9.fc30.src
ovirt-guest-agent-0:1.0.14-1.fc29.3.src
python-cliapp-0:1.20180121-1.fc30.src
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: dropping autogenerated dependency on pkg-config
Le vendredi 03 mai 2019 à 19:59 +0200, Dridi Boukelmoune a écrit : > On Fri, May 3, 2019 at 1:45 PM Nicolas Mailhot via devel > wrote: > > Le vendredi 03 mai 2019 à 12:04 +0100, Tomasz Kłoczko a écrit : > > > On Fri, 3 May 2019 at 11:04, Nicolas Mailhot via devel > > > wrote: > > > [..] > > > > You're assuming the only use is roolback. It's not > > > > > > Point taken. Can you shortly describe other use cases? > > > > You use apps in one of those languages that static build by > > default. > > There is a security alert in one code component. You want to know > > which > > packages in your repo/mirror have been build using the broken piece > > of > > source code > > Last time we disagreed on this topic my opinion was that static > linking should imply bundled provides: > > Provides: bundled() = > > Hopefully something that could be automated for some stacks. That makes it stack-specific And anyway, the classical compiler attack (compiler that inserts backdoor while compiling) shows that special-casing some packages for special tracking does not work, pretty much anything that existed in the build root need to be tracked because it may be exploited one way or another, and spead the exploit to everything that used it. -- Nicolas Mailhot ___ 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: dropping autogenerated dependency on pkg-config
On Fri, May 3, 2019 at 1:45 PM Nicolas Mailhot via devel wrote: > > Le vendredi 03 mai 2019 à 12:04 +0100, Tomasz Kłoczko a écrit : > > On Fri, 3 May 2019 at 11:04, Nicolas Mailhot via devel > > wrote: > > [..] > > > You're assuming the only use is roolback. It's not > > > > Point taken. Can you shortly describe other use cases? > > You use apps in one of those languages that static build by default. > There is a security alert in one code component. You want to know which > packages in your repo/mirror have been build using the broken piece of > source code Last time we disagreed on this topic my opinion was that static linking should imply bundled provides: Provides: bundled() = Hopefully something that could be automated for some stacks. To me there is no difference between bundling source code and bundling arch code, since most of the time I have seen it in action it was more a feat of vendoring for internal usage rather than actually providing a duplicate something to be consumed by others. And it would solve the post-CVE system inspection problem. Dridi ___ 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?
On Tue, Apr 30, 2019 at 09:40:13PM +0100, David Howells wrote: > > 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 In addition to SELinux rules, the default configuration for mlocate specifically mentions /afs, see: https://src.fedoraproject.org/rpms/mlocate/blob/master/f/updatedb.conf It'll ignore AFS mounted elsewhere because 'afs' is included in PRUNEFS, but this is just more evidence that Fedora already expects an /afs mountpoint, historically. There's really no question of where AFS will be mounted. It will be /afs. It's mostly a question of whether a Fedora package can set up that mountpoint, or if it should be left as a partial implementation that requires the user to run 'mkdir /afs' before starting the service. -- Jonathan Billings ___ 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: Is possible to use caching for livemedia-creator
On Fri, 2019-05-03 at 12:40 -0400, Neal Gompa wrote: > On Fri, May 3, 2019 at 12:28 PM Danishka Navin wrote: > > Hi, > > > > Is it possible to enable caching for livemedia-creator? > > Similar to the --cache option in livecd-creator. > > > > No. Anaconda (the installer engine) does not support caching, so > nothing built on top of it can either. What is caching in this context ? Caching the RPMs used to create the image or caching some intermediate states of image creation, so you don't have to rerun the whole process for different customizations ? > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > 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 ___ 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: HEADS UP: gdb-minimal has replaced gdb-headless in buildroot
Koji already picked up the change. COPR and local mock chroots (unless they use F31 build repo, which they don't by default) have to wait for compose. On Fri, May 3, 2019, 19:14 Miro Hrončok wrote: > On 03. 05. 19 18:41, Igor Gnatenko wrote: > > Hello, > > > > https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot has > been > > implemented just few minutes ago. > > This is now affecting f31 Koji immediately? Or do we need to wait for a > compose? > > What about Copr or local mock chroots? > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > 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 > ___ 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: HEADS UP: gdb-minimal has replaced gdb-headless in buildroot
On 03. 05. 19 18:41, Igor Gnatenko wrote: Hello, https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot has been implemented just few minutes ago. This is now affecting f31 Koji immediately? Or do we need to wait for a compose? What about Copr or local mock chroots? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Orphaning python-ripozo
I plan to orphan python-ripozo next week. I don't need it. Nothing depends on it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Is possible to use caching for livemedia-creator
On Fri, May 3, 2019 at 12:28 PM Danishka Navin wrote: > > Hi, > > Is it possible to enable caching for livemedia-creator? > Similar to the --cache option in livecd-creator. > No. Anaconda (the installer engine) does not support caching, so nothing built on top of it can either. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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
HEADS UP: gdb-minimal has replaced gdb-headless in buildroot
Hello, https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot has been implemented just few minutes ago. Before: Install 151 Packages Total download size: 77 M Installed size: 339 M After: Install 139 Packages Total download size: 54 M Installed size: 249 M It should not affect anything (apart from making buildroot composition faster and smaller size), but let us know if anything breaks :) -- -Igor Gnatenko ___ 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 possible to use caching for livemedia-creator
Hi, Is it possible to enable caching for livemedia-creator? Similar to the --cache option in livecd-creator. Regards, -- Danishka Navin ___ 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
Summary/Minutes from today's FESCo Meeting (2019-05-06)
=== #fedora-meeting: FESCO (2019-05-06) === Meeting started by jforbes at 15:00:05 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2019-05-03/fesco.2019-05-03-15.00.log.html . Meeting summary --- * init process (jforbes, 15:00:05) * #2088 F31 Change – “dnf --best” as default behavior (jforbes, 15:04:00) * LINK: https://pagure.io/fesco/issue/2088 (jforbes, 15:04:00) * ACTION: bowlofeggs will document how to get him to vote +1 (bowlofeggs, 15:38:57) * AGREED: bowlofeggs will update the ticket with concerns that need to be addressed before we vote (jforbes, 15:40:45) * #2125 F31 System-Wide Change: Set skip_if_unavailable default to false (jforbes, 15:41:37) * LINK: https://pagure.io/fesco/issue/2125 (jforbes, 15:41:38) * AGREED: F31 System-Wide Change: Set skip_if_unavailable default to false is approved (+7,0,-1) (jforbes, 16:01:42) * #2126 F31 Change: Minimal GDB in buildroot (jforbes, 16:03:27) * LINK: https://pagure.io/fesco/issue/2126 (jforbes, 16:03:27) * AGREED: F31 Change: Minimal GDB in buildroot is approved (+6,0,0) (jforbes, 16:06:47) * Next week's chair (jforbes, 16:07:54) * ACTION: mhroncok will chair the next meeting (jforbes, 16:08:11) * Open Floor (jforbes, 16:08:20) * FESCo elections are coming soon! (bowlofeggs, 16:08:30) Meeting ended at 16:15:39 UTC. Action Items * bowlofeggs will document how to get him to vote +1 * mhroncok will chair the next meeting Action Items, by person --- * bowlofeggs * bowlofeggs will document how to get him to vote +1 * mhroncok * mhroncok will chair the next meeting * **UNASSIGNED** * (none) ___ 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
Fedora Rawhide-20190503.n.0 compose check report
Missing expected images: Atomichost raw-xz x86_64 Atomichost qcow2 x86_64 Compose FAILS proposed Rawhide gating check! 5 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 18/146 (x86_64), 1/2 (arm) ID: 395465 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/395465 ID: 395466 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/395466 ID: 395469 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/395469 ID: 395470 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/395470 ID: 395471 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/395471 ID: 395472 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/395472 ID: 395473 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/395473 ID: 395479 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/395479 ID: 395509 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/395509 ID: 395522 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/395522 ID: 395532 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/395532 ID: 395534 Test: x86_64 universal install_anaconda_text **GATING** URL: https://openqa.fedoraproject.org/tests/395534 ID: 395552 Test: x86_64 universal install_btrfs URL: https://openqa.fedoraproject.org/tests/395552 ID: 395570 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/395570 ID: 395582 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/395582 ID: 395588 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/395588 ID: 395591 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/395591 ID: 395597 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/395597 ID: 395605 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/395605 Soft failed openQA tests: 3/24 (i386), 6/146 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 395482 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/395482 ID: 395483 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/395483 ID: 395494 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/395494 ID: 395501 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/395501 ID: 395502 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/395502 ID: 395506 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/395506 ID: 395589 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/395589 ID: 395590 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/395590 ID: 395592 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/395592 Passed openQA tests: 122/146 (x86_64), 21/24 (i386) Skipped non-gating openQA tests: 1 of 172 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
module testing files?
Seeing current modules/* 's files. Some of the modules have testing files in the directory. Are the testing files still actually used for the modules? I assume that only modules/foo/foo.yaml file is required. Other files like "sources" are meaningless, right? I think "sources" file is wrongly there. I just checked my local downloaded modules/* directories. $ ls */Dockerfile memcached/Dockerfile mongodb/Dockerfile php/Dockerfile ruby/Dockerfile $ ls */Makefile flatpak-runtime/Makefile memcached/Makefile mongodb/Makefile php/Makefile platform/Makefile ruby/Makefile $ ls -d */tests memcached/tests/ mongodb/tests/ php/tests/ ruby/tests/ $ ls -d */sources eog/sources mariadb/sourcesmongodb/sources perl/sources platform/sourcespython2/sources ruby/sources flatpak-runtime/sources memcached/sources nodejs/sources php/sources postgresql/sources python3/sources varnish/sources I like to see the file structure and testing module is documented or linked in below page https://docs.fedoraproject.org/en-US/modularity/making-modules/ -- Jun Aruga jar...@redhat.com ___ 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: Boost python3 auto-generated Requires are wrong
On 03. 05. 19 17:46, Michael Cronenworth wrote:
On 5/3/19 10:29 AM, Miro Hrončok wrote:
--with-boost-python=boost_python%{python3_version_nodots}
That seems to fix it. Thanks!
Don't forget to do this with Python 2 as well. I think you are getting python27
by accident, not explicitly (and it happens to works for Python 2).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Boost python3 auto-generated Requires are wrong
On 5/3/19 10:29 AM, Miro Hrončok wrote:
--with-boost-python=boost_python%{python3_version_nodots}
That seems to fix it. Thanks!
___
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: Boost python3 auto-generated Requires are wrong
On 03. 05. 19 17:23, Michael Cronenworth wrote:
Starting with Fedora 30 the automatically generated Requires for
rb_libtorrent-python3 is pulling in Boost for Python 2 instead of for 3. What
could be doing that?
Fedora 29: https://koji.fedoraproject.org/koji/rpminfo?rpmID=16322406
Fedora 30: https://koji.fedoraproject.org/koji/rpminfo?rpmID=16328261
Today I upgraded the package and that build is still showing this problem.
Fedora 31: https://koji.fedoraproject.org/koji/rpminfo?rpmID=17466145
Is it possible that the build is picking boost_python27 when it cannot find
boost_python3?
Try replacing:
--with-boost-python=boost_python3
with
--with-boost-python=boost_python%{python3_version_nodots}
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Boost python3 auto-generated Requires are wrong
Starting with Fedora 30 the automatically generated Requires for rb_libtorrent-python3 is pulling in Boost for Python 2 instead of for 3. What could be doing that? Fedora 29: https://koji.fedoraproject.org/koji/rpminfo?rpmID=16322406 Fedora 30: https://koji.fedoraproject.org/koji/rpminfo?rpmID=16328261 Today I upgraded the package and that build is still showing this problem. Fedora 31: https://koji.fedoraproject.org/koji/rpminfo?rpmID=17466145 Thanks, Michael ___ 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
Fedora rawhide compose report: 20190503.n.0 changes
OLD: Fedora-Rawhide-20190502.n.0 NEW: Fedora-Rawhide-20190503.n.0 = SUMMARY = Added images:5 Dropped images: 3 Added packages: 11 Dropped packages:3 Upgraded packages: 95 Downgraded packages: 0 Size of added packages: 291.33 MiB Size of dropped packages:14.35 MiB Size of upgraded packages: 10.58 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -423.17 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Workstation live i386 Path: Workstation/i386/iso/Fedora-Workstation-Live-i386-Rawhide-20190503.n.0.iso Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20190503.n.0.s390x.tar.xz Image: Cloud_Base vmdk s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190503.n.0.s390x.vmdk Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190503.n.0.s390x.raw.xz Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190503.n.0.s390x.qcow2 = DROPPED IMAGES = Image: Python_Classroom raw-xz armhfp Path: Labs/armhfp/images/Fedora-Python-Classroom-armhfp-Rawhide-20190502.n.0-sda.raw.xz Image: Security live i386 Path: Labs/i386/iso/Fedora-Security-Live-i386-Rawhide-20190502.n.0.iso Image: Python_Classroom live x86_64 Path: Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20190502.n.0.iso = ADDED PACKAGES = Package: openkim-models-2019.03.31-2.fc31 Summary: Open Knowledgebase of Interatomic Models RPMs:openkim-models Size:259.01 MiB Package: perl-HTTP-Link-Parser-0.200-1.fc31 Summary: Parse HTTP Link headers RPMs:perl-HTTP-Link-Parser Size:18.81 KiB Package: py-spidev-3.4-1.fc31 Summary: A python library for manipulating SPI via spidev RPMs:python3-spidev Size:124.00 KiB Package: python-mitogen-0.2.6-2.fc31 Summary: Distributed self-replicating programs in Python RPMs:python3-mitogen Size:307.49 KiB Package: ruby-2.5.5-105.module_f31+4124+d9096b83 Summary: An interpreter of object-oriented scripting language RPMs:ruby ruby-devel ruby-doc ruby-irb ruby-libs rubygem-bigdecimal rubygem-did_you_mean rubygem-io-console rubygem-json rubygem-minitest rubygem-net-telnet rubygem-openssl rubygem-power_assert rubygem-psych rubygem-rake rubygem-rdoc rubygem-test-unit rubygem-xmlrpc rubygems rubygems-devel Size:26.09 MiB Package: rubygem-abrt-0.3.0-6.module_f31+4124+d9096b83 Summary: ABRT support for Ruby RPMs:rubygem-abrt rubygem-abrt-doc Size:239.45 KiB Package: rubygem-bson-4.3.0-6.module_f31+4124+d9096b83 Summary: Ruby Implementation of the BSON specification RPMs:rubygem-bson rubygem-bson-doc Size:709.25 KiB Package: rubygem-bundler-1.16.1-5.module_f31+4124+d9096b83 Summary: Library and utilities to manage a Ruby application's gem dependencies RPMs:rubygem-bundler rubygem-bundler-doc Size:1.59 MiB Package: rubygem-mongo-2.6.2-3.module_f31+4124+d9096b83 Summary: Ruby driver for MongoDB RPMs:rubygem-mongo rubygem-mongo-doc Size:1.60 MiB Package: rubygem-mysql2-0.5.2-3.module_f31+4124+d9096b83 Summary: A simple, fast Mysql library for Ruby, binding to libmysql RPMs:rubygem-mysql2 rubygem-mysql2-doc Size:570.62 KiB Package: rubygem-pg-1.1.4-3.module_f31+4124+d9096b83 Summary: A Ruby interface to the PostgreSQL RDBMS RPMs:rubygem-pg rubygem-pg-doc Size:1.12 MiB = DROPPED PACKAGES = Package: fedora-productimg-atomic-28-2.fc28 Summary: Installer branding and configuration for Fedora Atomic RPMs:fedora-productimg-atomic Size:12.54 KiB Package: gofed-1.0.0-0.22.rc1.fc30 Summary: Tool for development of golang devel packages RPMs:gofed gofed-base gofed-build gofed-cmd-dnfs-base gofed-cmd-dnfs-build gofed-cmd-dnfs-scan gofed-docker gofed-gofedlib gofed-infra gofed-resources gofed-scan python2-cmdsignature Size:14.32 MiB Package: php-mediawiki-at-ease-1.1.0-7.fc30 Summary: Safe replacement to @ for suppressing warnings RPMs:php-mediawiki-at-ease Size:16.97 KiB = UPGRADED PACKAGES = Package: R-Bessel-0.6.0-1.fc31 Old package: R-Bessel-0.5.5-1.fc30 Summary: Computations and Approximations for Bessel Functions RPMs: R-Bessel Size: 1.38 MiB Size change: 313.86 KiB Changelog: * Thu May 02 2019 Elliott Sales de Andrade - 0.6.0-1 - Update to latest version Package: R-IRkernel-1.0.1-1.fc31 Old package: R-IRkernel-1.0.0-1.fc31 Summary: Native R Kernel for the 'Jupyter Notebook' RPMs: R-IRkernel Size: 200.92 KiB Size change: 1.15 KiB Changelog: * Thu May 02 2019 Elliott Sales de Andrade - 1.0.1-1 - Update to latest version Package: adcli-0.8.2-5.fc31 Old package: adcli-0.8.2-4.fc31 Summary: Active Directory enrollment RPMs: adcli adcli-doc Size: 654.51 KiB Size change: 28.20 KiB Changelog: * Tue Apr 30 2019 Sumit Bose - 0.8.2-5 - addition patch for rhbz#
Re: dropping autogenerated dependency on pkg-config
On Fri, May 3, 2019 at 8:26 AM Tomasz Kłoczko wrote: > > On Fri, 3 May 2019 at 12:44, Nicolas Mailhot > wrote: > [..] > > > Point taken. Can you shortly describe other use cases? > > > > You use apps in one of those languages that static build by default. > > There is a security alert in one code component. You want to know which > > packages in your repo/mirror have been build using the broken piece of > > source code > > OK. Some time ago I've successfully removed all static libraries on my > all build systems. > Good to know that I will never have such dilemmas :o) > Nope. Between Go and Rust, you have literally thousands of static linked dependencies, so it does matter in that case. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: dropping autogenerated dependency on pkg-config
On Fri, 3 May 2019 at 12:44, Nicolas Mailhot wrote: [..] > > Point taken. Can you shortly describe other use cases? > > You use apps in one of those languages that static build by default. > There is a security alert in one code component. You want to know which > packages in your repo/mirror have been build using the broken piece of > source code OK. Some time ago I've successfully removed all static libraries on my all build systems. Good to know that I will never have such dilemmas :o) Do you have maybe other examples of the use cases? :p kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: vsync in VM?
On Thu, May 2, 2019 at 6:19 PM Adam Jackson wrote: > On Thu, 2019-05-02 at 17:05 +0200, Kamil Paral wrote: > > Hello, > > > > I wonder whether it's expected that vsync doesn't work in VMs. I've > > tested Fedora 28/29/30 Workstation and Fedora 30 KDE guests on Fedora > > 30 host, with virtio GPU (3D acceleration on and off) or QXL GPU, and > > in all cases, I'm seeing hundreds or thousands of FPS in glxgears, > > implying that vsync is not working. > > > > Is that an expected state? Is there a simple way to force vsync on > > inside a VM? (using virt-manager + libvirt) > > Short answer: yes it's expected, no there's no way to do that, probably > there should be. > > Long answer: > > The concept of "vsync" in a virtual machine is a bit fuzzy. What > monitor's timings do you think you're syncing to? What do you do when > there's more than one host process watching the framebuffer (think both > gtk and vnc views on the same device)? But, assuming you manage to > answer those questions... > > At least in qemu's implementation neither qxl nor bochs has any > "hardware" concept of a vertical retrace interrupt. And for both of > those you'll end up with llvmpipe for the 3D driver, which doesn't have > any concept of vsync either. The latter we could maybe fix in a few > ways, but I wouldn't expect the former to ever change. > > virtio looks like it has _some_ internal notion of interrupts, but if > that's supposed to be implementing vsync it's not obvious to me how > it's accomplishing that. vmwgfx I suspect does have synthetic vsync > events, but I think you'd need to be using an actual vmware vm to make > that happen and not qemu. > Thanks, Adam, for a detailed answer. ___ 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: dropping autogenerated dependency on pkg-config
Le vendredi 03 mai 2019 à 12:04 +0100, Tomasz Kłoczko a écrit : > On Fri, 3 May 2019 at 11:04, Nicolas Mailhot via devel > wrote: > [..] > > You're assuming the only use is roolback. It's not > > Point taken. Can you shortly describe other use cases? You use apps in one of those languages that static build by default. There is a security alert in one code component. You want to know which packages in your repo/mirror have been build using the broken piece of source code -- Nicolas Mailhot ___ 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: dropping autogenerated dependency on pkg-config
On Fri, 3 May 2019 at 11:04, Nicolas Mailhot via devel wrote: [..] > You're assuming the only use is roolback. It's not Point taken. Can you shortly describe other use cases? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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
Orphaning rubygem-commander
Hi everybody, I've orphaned rubygem-commander. It is only required by rubygem-rhc, which upstream is dead I doubt it is really useful, since this package was used to control OpenShift 2.x which I doubt anybody uses nowadays. Also, it blocks me from updating rubygem-commander, so I actually hope to get rid of rubygem-commander as well as unmaintained rubygem-rhc from Fedora. Vít ___ 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: dropping autogenerated dependency on pkg-config
Le vendredi 03 mai 2019 à 09:46 +0100, Tomasz Kłoczko a écrit : > ial today, because the storage part has not been streamlined. > > As I wrote problem only is that without possibility really rollback > to > the full state described in set of exact N-E:V-Rs packages recorded > data such auditing data in case if something starts going wrong such > data could be used only as kind of murky vector where possible cause > really is. There's nothing murky or wrong in beiang able to answer "which static builds have used this rotten package" without needing to contact a centralised system like koji or IPS. You're assuming the only use is roolback. It's not -- Nicolas Mailhot ___ 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: get gnome-shell-extension-media-player-indicator not working on F30
> On Thu, 2 May 2019, 15:43 Martin Gansser, wrote: > > > You could try looking at the similar but more limited > https://github.com/JasonLG1979/gnome-shell-extension-mpris-indicator-button, > from the same author. Thanks for your answer. I'm aware of that, but I asked if anyone got the original version up and running. Regards Martin ___ 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?
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: dropping autogenerated dependency on pkg-config
On Thu, 2 May 2019 at 20:29, Nicolas Mailhot via devel wrote: [..] > > IMO maintainer in this case is 100% right because all properties of > > the build env already can be described in with enough precision. > > Providing more details about build env will be duplicating current > > build dependencies. > > You're confusing constrains (build dependencies) with actual build env > composition (exact constrains resolution, which has been known to > change even with the same package set, just by switching dependency > resolution engines from yum to dnf to whatever). > > Build env composition information is generally useful for audits, > reproducibility, and debugging. It's useful enough to have been > reimplemented over the years in multiple places (elfutils spec, koji, > whatever). It's even more useful with the recent tendency to static > build. > > What is missing is a mecanism to record in in a generic way package- > side, so one does not have to rely on build farm logs (that may or may > not be retained over time) to access this basic info. > > Computing this info is trivial. It’s just a rpm -qa at the end of > buildrequires resolution. Accessing this info reliably, however, it not > trivial today, because the storage part has not been streamlined. As I wrote problem only is that without possibility really rollback to the full state described in set of exact N-E:V-Rs packages recorded data such auditing data in case if something starts going wrong such data could be used only as kind of murky vector where possible cause really is. It is nothing wrong with keeping only latest versions of the packages but with that assumption to have enough effectiveness of catching errors/issues needs to be added more test units fired straight after package build is done or during that process. Just look on some numbers below: [tkloczko@domek SPECS.fedora]$ grep ^%check *| wc -l; ls -1| wc -l 11692 21300 and the same stats on results of my own work: [tkloczko@domek SPECS.g2v]$ grep ^%check *| wc -l; ls -1| wc -l 426 498 Do you see where my thoughts are heading? With that only in last 3-4 months I've been able to catch maybe even few tenths of new issues just right on build packages (you can check stat of my accounts on gitlab and github to be able spot that part of my activity). I fully understand why Fedora keeps only latest versions of the packages and it is nothing wrong with that. Problems only is that if that small bit must be kind of assumption other parts around needs to be readjusted to create kind of strategy catching and dealing with new issues. And again .. with assumption that during packages development process never would be possible to fully rollback to the same N-E:V-Rs state storing build time metadata is kind of pointless (IMO). In other words reproducibility of those N-E:V-Rs metadata in case of Fedora are very close to *null*. BTW: storing all N-E:V-Rs of the *packages* could be easily solved by move away from rpm to IPS and I know that in case of the Fedora that kind of change is unrealistic. Adapting rpm to use packages repository like it is in case of IPS is unrealistic as well .. because to many things around needs to be changed (not only on packaging and distribution layer). You can observe this kind of effect on for example Sol 11.4 packages http://pkg.oracle.com/solaris/release/en/ The same web interface which immanent part of the IPS provides very long list of all version of the packages if you would be able to observe all Solaris SRUs (Service Recommended Updates) data. On Solaris 10 with IPS is possible even rollback to the state ~10 years old. Full rollback to the system state of all packages from the past is sometimes really important and this is why in OL repositories are never deleted older packages (yum/dnf repo allows keep multiple E:VRs of the same package in single repository). kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: dropping autogenerated dependency on pkg-config
On Fri, 3 May 2019 at 09:46, Tomasz Kłoczko wrote: [..] > http://pkg.oracle.com/solaris/release/en/ URL correction: http://pkg.oracle.com/solaris/release/ kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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
Release rpkg-1.58 fedpkg-1.37
Hi all, a new version rpkg-1.58 and fedpkg-1.37 is released. Currently, Fedora 30 packages are in the stable repository, feel free to try other waiting distributions in Bodhi. Numerous features and improvements (as well as bugfixes) includes: (For "rpkg") - Improvements for scratch module builds - Allow passing arguments to “mbs-manager build_module_locally” - Remove the ability to parse a module’s branch - Permit setting arbitrary rpm macros during build - Ignore specific files in a cloned repository - Pass specific arguments to “mock” - Added “depth” argument to "git clone" - Watch multiple module builds - Show module build links in output from command module-build - Add the ability to configure multiple regex expressions - Add “retire” command supporting both packages and modules - Import srpm without uploading sources - Ignore any specified profile when finding the Flatpak build target - Added update-docs script - And other fixes and small improvements (For "fedpkg") - Ignore files in a cloned repository - Enable shell completion for module scratch builds - Show hint when Pagure token expires - Include possible distprefix in “–define dist” for Forge-based packages - Other small fixes More specific changelog (web documentation): https://docs.pagure.org/rpkg/releases/1.58.html https://docs.pagure.org/fedpkg/releases/1.37.html Updates: https://bodhi.fedoraproject.org/updates/?builds=rpkg-1.58-1.el6&builds=rpkg-1.58-1.el7&builds=rpkg-1.58-1.fc28&builds=rpkg-1.58-1.fc29&builds=rpkg-1.58-1.fc30 Alternative link: https://bodhi.fedoraproject.org/updates/?packages=rpkg&page=1 rpkg is available from PyPI. Thanks to all contributors. Regards ___ 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: Nextcloud-client testers wanted
Hi Radka, could you please try using a new ~/.config/Nextcloud/ folder and see if this happens again? ___ 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
