Re: Clone all packages at once
On Tue, Jul 15, 2014 at 11:19 AM, Kalpa Welivitigoda wrote: > > > > On Tue, Jul 15, 2014 at 1:17 PM, Eduardo Javier Echeverria Alvarado > wrote: >> >> Yes, definitively easier. Copied in the list of the things that make >> easier the packager task. Thanks pingou :) > > > Is this a list you locally maintain? If so shall we put this up in the wiki > that everyone can benefit? It looks trivial enough to maybe be added to fedpkg directly, doesn't it? `fedpkg clone-mine` or something similar maybe? Dridi >> >> El 15/07/2014 03:07, "Kalpa Welivitigoda" escribió: >> >>> Hi, >>> >>> Thanks a lot. >>> >>> Pierre's suggestion worked fine with a slight modification. It should be >>> --user >>> >>> >>> On Tue, Jul 15, 2014 at 12:56 PM, Pierre-Yves Chibon >>> wrote: On Tue, Jul 15, 2014 at 02:40:13AM -0430, Eduardo Javier Echeverria Alvarado wrote: >I think not there any command that do that. But you can take a look > to the >output of the pkgdb api [1] and make your own script > >[1] > > https://admin.fedoraproject.org/pkgdb/api/packager/package/echevemaster > >El 15/07/2014 02:26, "Kalpa Welivitigoda" >escribiA^3: > > Hi, > > Is it possible to clone all the packages I maintain/co-maintain > in a > single command with fedpkg clone? Even easier with pkgdb-cli something like: for pkg in $(pkgdb-cli list --user=>>> do fedpkg clone $pkg done Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct >>> >>> >>> >>> >>> -- >>> Best Regards, >>> >>> Kalpa Welivitigoda >>> +94776509215 >>> http://about.me/callkalpa >>> >>> -- >>> devel mailing list >>> devel@lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/devel >>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct >> >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > > > > -- > Best Regards, > > Kalpa Welivitigoda > +94776509215 > http://about.me/callkalpa > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Running docker in a mock chroot
Hi, I haven't really tried, I only wanted to look at fig 1.0 currently in f21 updates-testing. So I --shell'ed inside my fedora-21-x86_64 mock chroot after installing fig, and tried to start a docker daemon in the background but it failed. # docker -d -H unix:///var/run/docker.sock & 2014/11/05 23:08:33 docker daemon: 1.3.0 c78088f/1.3.0; execdriver: native; graphdriver: [45f3a6fd] +job serveapi(unix:///var/run/docker.sock) [error] attach_loopback.go:42 There are no more loopback devices available. 2014/11/05 23:08:33 loopback mounting failed If I need to use a VM, I will (any news for vagrant?) but I was wondering whether this was actually possible. I haven't looked in detail at how mock creates the chroots, and don't have time to dig at all these days. I was just wondering whether it was actually possible to run docker in a chroot, especially one built with mock! Cheers, Dridi -- 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: late generation of assemble code
On Tue, May 26, 2020 at 12:07 PM Jan Kratochvil wrote: > > On Sun, 24 May 2020 05:21:05 +0200, Paul Dufresne via devel wrote: > > The idea was to push code generation as near as possible of code execution. > > Because at execution time, you know what are the specific features of the > > CPU, and what is used to most often by the user of the program. > > In Free Software you have that already - it is called the source code. > If you want host-specific optimizations use Gentoo Linux. One could implement a DNF plugin that builds packages locally since we have source RPM repositories. > But that approach (incl. the possible LLVM JIT) has its own kind of > disadvantages such as unreproducibility of compilation-specific problems > elsewhere - no way to have meaningful build-ids, ABRT retrace server etc. Another problem is updates of large packages. Last time I had to build LibreOffice from scratch on my $DAYJOB laptop (years ago fortunately) it took 12h to complete. On the other hand that could also clear some legal issues for packages unfit for Fedora, that would be fine as a source-only distribution. Dridi ___ 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: swap-on-ZRAM by default
> Zswap sounds like an excellent idea to look into instead of zram. Not only > that, but it'd allow traditional entry in fstab to configure it, instead of > some systemd magic that nobody knows about. In that case most of everything that happens on my system is magic, I don't have comprehensive knowledge about everything I (possibly indirectly) installed. But I am a happy zram-swap user, and while I don't remember the magic incantation I do know that I found it either in release notes or before the relevant Fedora release on this list as a self-contained or system-wide change. It turns out to be even less magic than I would expect, I can easily inspect the systemd part: $ systemctl cat zram-swap.service It turns out I can break the magic spell even one step further: $ file /usr/sbin/zramstart /usr/sbin/zramstart: Bourne-Again shell script, ASCII text executable So the zram.noarch package is for the opposite of magic, and it is very composable. All I needed to do was to install the package, configure how much RAM I want to allocate for that purpose and enable one service. In my mind fstab isn't composable because it requires concurrent modifications in this scenario, and is (for my limited skills) harder to keep track of who gets to touch it. I can't compare to other solutions, but I insist as someone who is not knowledgeable in this area: following instructions when the zram.noarch package landed and peeping a bit deeper felt like the opposite of messing about with black magic. Now the difficulty for me was to remember how I set it up "back then" (I don't even remember when) but after a quick search I was able to find what I was looking for thanks to a boring straightforward name: $ systemctl | grep zram And with my findings: $ rpm -qf /lib/systemd/system/zram-swap.service zram-0.4-1.fc32.noarch Only then did I realize that it was already mentioned in this thread's first email... But well, my memory is as persistent as my zram. I was also aware of zram-generator but it doesn't look as polished in terms of integration or documentation. Dridi ___ 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: swap-on-ZRAM by default
> Well, that's really the point. The one you're using is one of the (4? 5?) > other zram implementations. It seems a bit more straightforward than the > systemd one for sure. The zram-generator is probably more straightforward (with literally less layers of indirection) than what the zram package provides. I would assume that a generator is also the more idiomatic (and efficient) solution as far as systemd is concerned and I wouldn't mind migrating to that if it looked feature-complete and had decent documentation. There is no manual page[1], only a slightly confusing README that hints at simplicity and incompleteness. I don't see the zram-generator as systemd magic nobody knows about like you claimed. Sure, it's not implemented as a shell script and I'd need to read its source code to understand what it does given the current lack of documentation (which is a shame considering how systemd documentation is often top notch) but as far as the zram package goes I eventually run into the same situation with zramctl. If this thread's initiative converges all implementations towards zram-generator [2] and moves the project forward, then I'm in. Currently it's a mere rust experiment to me, and by that I don't want to downplay it, but it's not mature. Dridi [1] like most rust programs I have used so far [2] shouldn't it be called systemd-zram-generator? ___ 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: swap-on-ZRAM by default
On Tue, Jun 9, 2020 at 5:43 PM Samuel Sieb wrote: > > On 6/9/20 6:49 AM, Dridi Boukelmoune wrote: > >> Well, that's really the point. The one you're using is one of the (4? 5?) > >> other zram implementations. It seems a bit more straightforward than the > >> systemd one for sure. > > > > The zram-generator is probably more straightforward (with literally > > less layers of indirection) than what the zram package provides. I > > would assume that a generator is also the more idiomatic (and > > efficient) solution as far as systemd is concerned and I wouldn't mind > > migrating to that if it looked feature-complete and had decent > > documentation. There is no manual page[1], only a slightly confusing > > README that hints at simplicity and incompleteness. > > There's also an example conf file included that has a lot of explanation > in it. I'm aware, but the explanation doesn't tell me anything I couldn't infer from the README. Regardless, it doesn't come close to what generators shipped with systemd provide in terms of documentation. Open the man page systemd.generator and jump to the SEE ALSO section at the end. You should see reference to several generator manuals, the first one is systemd-cryptsetup-generator(8). Opening the systemd-cryptsetup-generator(8) manual and the systemd-cryptsetup@.service(8) manual mentioned in the DESCRIPTION section, I'm looking at a different level of documentation. Again, I'm well aware thanks to the README and past threads on this list that this was initially a rust experiment, apparently successful, and if anything I'd be happy to see it go that extra mile and squash important items from the TODO file, and add decent documentation. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package
> == How To Test == > Install Fedora 33 (any edition or flavor), check that modular repos > are still installed and enabled by default. > > Update to Fedora 33 (from Fedora 31 or 32), check that modular repos > are still installed and enabled by default. > > Check that you can remove the fedora-repos-modular package (e.g. via > sudo dnf remove fedora-repos-modular) and it removes the > modular repos. > > Check that you can install the fedora-repos-modular package again > (e.g. via sudo dnf install fedora-repos-modular) and it > adds the modular repos, enabled. If someone manually disables the modular repositories prior to this change, uninstalling and reinstalling the package wouldn't make any difference because the files are %config(noreplace) and would be left alone because of the modification. Unless you had plans to deal with that too. > == User Experience == > Users can disable or enable modular repos by removing or installing > fedora-repos-modular. This is significantly better UX than editing > config files. Agreed, I hope this change will follow through. Dridi ___ 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
fedora-minimal container and registry negative feedback
Greetings, I'm not sure whether the minimization effort is still going on but I wanted to report the pitfalls I ran into moving from the fedora Docker container to fedora-minimal. For starters I was surprised by the absence of DNF and I had to find by myself, I don't remember how, that MicroDNF was present instead. So my first bit of feedback concerns the container registry. It looks a bit... out of shape? I get an empty page [1] when I click on the fedora-minimal container and as of today it is by far not the only blank page. I had to keep opening more until I found one [2] with contents. Ironically a docker container for another container runtime... Even when there is content, it doesn't tell much. This is where I would hope to get the information about MicroDNF. The other and more significant pitfall I ran into was the lack of a timezone database. This manifests either as missing tz information or reports of a corrupted tz database, depending on the application I'm trying to run. Installing tzdata was a no-op, it turns out to be installed by default but some of its contents are removed post installation. Again, something trivial to fix, but it should be documented on the registry: microdnf reinstall tzdata By comparison dockerhub, from which I used to pull fedora images before moving to fedora-minimal has a nice landing page [3] and maybe it's also failing to document pitfalls but so far the base image never surprised me. Other than that, it seems to hum along, thanks! Dridi [1] https://registry.fedoraproject.org/repo/fedora-minimal/tags/ [2] https://registry.fedoraproject.org/repo/flatpak-build-base/tags/ [3] https://hub.docker.com/_/fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: fedora-minimal container and registry negative feedback
> > microdnf reinstall tzdata > > There's a bug about this to split out the UTC tzdata into a minimal > tzdata so terrible hacks aren't needed to slim things down. > https://bugzilla.redhat.com/show_bug.cgi?id=1722233 I'll CC myself to this bug but it doesn't look like anything will happen soon. > > By comparison dockerhub, from which I used to pull fedora images > > before moving to fedora-minimal has a nice landing page [3] and > > maybe it's also failing to document pitfalls but so far the base image > > never surprised me. > > Anything that's particularly stripped back will always be a compromise > of size vs functionality, if the stacked image did what you already > needed why change? I needed to deploy more services on a very constrained box, and this has given me enough headroom not to worry for a while. Compromise is fine, but finding out through trial&error is needlessly tedious. Unless of course I missed the red tape with "here be dragons", in which case it would have been totally on me and that's where I think Fedora's container registry could be improved. I'm wondering whether container pages went blank because something went missing during the recent data center move. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: fedora-minimal container and registry negative feedback
> The blank pages are flatpaks. We are using the same registry for containers > and flatpaks and the upstream project[0] used for registry.fp.o does not > support flatpaks so the page is just blank. That can't be right, fedora-minimal is a docker/an OCI image, isn't it? > There has not been much interest in improving registry.fp.o since we looked > at moving stuff to quay.io. Noted, being warned of known gotchas would be nice regardless of where the images are hosted. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: fedora-minimal container and registry negative feedback
> The tag page for fedora-minimal seems to be working > https://registry.fedoraproject.org/repo/fedora-minimal/tags/. Do you have a > link of the page that is blank ? That's the very link from which I get a blank page, and Firefox reports an empty resource (^U to view source). The developer console on the other hand gives me the following warning: > The character encoding of the HTML document was not declared. The > document will render with garbled text in some browser configurations > if the document contains characters from outside the US-ASCII range. > The character encoding of the page must be declared in the document > or in the transfer protocol. Which is logical since the content-type header doesn't give a charset and the response body is empty. Trying with curl -v I see the following response: < HTTP/2 200 < date: Tue, 30 Jun 2020 09:18:47 GMT < server: Apache < strict-transport-security: max-age=31536000; includeSubDomains; preload < x-frame-options: SAMEORIGIN < x-xss-protection: 1; mode=block < x-content-type-options: nosniff < referrer-policy: same-origin < last-modified: Tue, 30 Jun 2020 08:25:07 GMT < etag: "0-5a948e9b307cf" < accept-ranges: bytes < content-length: 0 < apptime: D=193 < x-fedora-proxyserver: proxy10.iad2.fedoraproject.org < x-fedora-requestid: XvsDdwgZ9DOnVuTIdll6NQE < content-type: text/html Note the explicit zero content length. HTH, Dridi ___ 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: Ditch RPM in favor of DPKG
On Tue, Jul 14, 2020 at 8:39 PM Dishant Pandya wrote: > > Its ok to have something that builds deb packages on Fedora, but in my > opinion RPM is far more better then debian packages. Also the Dnf and yum > package manager on Fedora are far more advanced than apt on Ubuntu and other > Debian Based system. > I have been using fedora for over 2 years now and I have never faced the > package installation issues that I faced with apt and dpkg, for whatever > unknown reasons, may be some corruption of package file, installation state > Ubuntu's package manager gets erroneous to an unrecoverable state, and I > being a normal desktop user wasn't able to restore the state, and had to > reinstall the whole OS from scratch. dpkg/apt is good when it works, but when > it breaks its unrecoverable. RPM , dnf/yum are more reliable. That poor joke of mine keeps hitting home :) Fedora remains an RPM-based system using DNF. What this change was about was really to allow using apt with deb packages. It makes it easier to pull more tools from the dpkg ecosystem like mock equivalent sbuild. Nothing to worry about. Cheers, Dridi ___ 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: Ditch RPM in favor of DPKG
> Simply put, "no". Debian and Ubuntu ".deb" packages too often don't > follow the File System Hierarchy, they may have different layouts and > package naming capitalization schemes for matching Fedora packagers > like "PyYAML", they may have overlapping pre-set uids and mismatched > group name conventions, etc., etc, and the grub intigration for new > kernels is likely to be a nightmare. It would be a full-time job for > several competent engineers to do that kind of package impedance > matching. I'm not interested in debating Debian and derivatives packaging guidelines, but I generally prefer how Fedora does things (except notably, modularity). > Just. no.aot abd deb inside a "podman" baswed container? Maybe? > But it seems not worth the pain. The whole point of this change was to allow working with DPKG tooling without leaving the comfort zone of Fedora, without forcing a VM or container indirection. And trust me on this one, I do not inflict Debian packaging on myself by choice so I'm really keen on not adding any needless step, to the point where before submitting this change I had my own homebrew apt package. As a bonus point, this change also retired apt-rpm which had been dead and unmaintained for a decade, and according to the upstream developer himself it had unfixed security issues. So apt-rpm needed to go anyway, and there was no reason not to replace it with regular apt (apt-rpm would otherwise conflict with apt). And by the way, even though I initiated this change I later lost my ability to implement it, but it's been done since f32 thanks to Neal Gompa and Sérgio Basto. I hope it clarifies what was actually implemented. Dridi ___ 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: Ditch RPM in favor of DPKG
> Oddly, the subject of the original post infers getting rid of rpm but > the post itself sounds like it's proposing something different and > that's why I decided to speak up. Yes, poor joke of mine, keeps hitting home though :) Ditching RPM in favor of DPKG was never meant to be a system-wide change, but simply switching Fedora's apt package from apt-rpm to regular apt. The original post was intentionally misleading because I have a particular sense of humor and frankly I didn't think that after months of completion this change would still make my day every once in a while. https://fedoraproject.org/wiki/Changes/Move_apt_package_from_RPM_to_DPKG_backend Seriously, nothing to worry about! Cheers ___ 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: Packages with missing %check
On Tue, Feb 25, 2014 at 2:50 PM, Adam Jackson wrote: > On Tue, 2014-02-25 at 12:45 +0200, Alexander Todorov wrote: > >> 1) Do we consider this a bug and if yes what priority do you give it? From >> last >> week discussions it looks like most people prefer to have tests executed in >> %check. > > I don't consider %check to be an appropriate way to run tests, so no, I > don't consider it a bug. Stating it broadly: we don't have a separate > phase for it in koji, which means we can't adequately set up tests in > general; and adding it to koji would be a mistake, because build > construction and build validation are fundamentally different phases. I'd rather not discard %check when (blind guess) most of the test suites fit well there. Unless you're testing the package from the outside (let's say integration tests), you don't need another hook for the tests. Even for integration tests %check might still be relevant if you manage to keep them self-contained. I'm not saying I'm against a hook for non %check-able test suites :) Dridi > This is an argument against %check, not against testing in general. We > should be relying on rpmbuild less, not more. rpm doesn't even have > anything like Requires(check), does it? > > - ajax > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages with missing %check
On Wed, Feb 26, 2014 at 4:41 AM, Adam Williamson wrote: > On Tue, 2014-02-25 at 18:35 -0800, Andrew Lutomirski wrote: > >> Just to mention: there are probably many packages where the equivalent >> of %check can't be run without access to a source tree, so Taskotron >> can't usefully replace %check. I maintain a package like that. > > How do you get from that premise to that conclusion? We know where the > source tree is... I don't think this would be a good idea to avoid such tests in %check. If you do that you have to later fetch the source code again, build it again and finally you can run the tests. Dridi > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages with missing %check
On Thu, Feb 27, 2014 at 11:18 AM, Alexander Todorov wrote: > На 26.02.2014 15:56, David Howells написа: > >> Alexander Todorov 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. >> > > I does, but not sure to how many. %check is executed during rpmbuild time > right after %build so limitations apply. s/%build/%install/ https://fedoraproject.org/wiki/How_to_create_an_RPM_package#.25check_section > > -- > Alex > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: packages from bitbucket
Hi,
Maybe we should add guidelines for bitbucket. That could be very
similar to github's template:
===
%global owner $OWNER
%global tag $TAG
%global commit $COMMIT
%global shortcommit %(c=%{commit}; echo ${c:0:12})
...
Source0:https://bitbucket.org/%{owner}/%{name}/get/%{tag}.tar.gz
...
%prep
%setup -qn %{owner}-%{name}-%{shortcommit}
===
I have tested this sucessfully with one (mercurial) package where $TAG
is %{version}.
What do you think ?
Dridi
On Wed, Feb 26, 2014 at 11:19 AM, Sandro Mani wrote:
>
> On 26.02.2014 10:16, Nikos Mavrogiannopoulos wrote:
>>
>> Hello,
>> I've submitted a while ago a review-request on a package [0] that is
>> taken from bitbucket.org. Unfortunately there was no reviewer yet, and I
>> suspect that is because unlike github [1] we have no rules on how to
>> handle bitbucket. Have other packagers experienced something similar in
>> other software? Is there a "good" way to handle repository-distributed
>> software? As it is now in [0] I've tried to simulate the github rules on
>> bitbucket.
>>
>> regards,
>> Nikos
>>
>>
>> [0]. https://bugzilla.redhat.com/show_bug.cgi?id=1062282
>> [1]. https://fedoraproject.org/wiki/Packaging:SourceURL#Github
>>
>>
> FWIW, this is how eigen does it:
>
> # Source file is at: http://bitbucket.org/eigen/eigen/get/3.1.3.tar.bz2
> # Renamed source file so it's not just a version number
> Source0:eigen-%{version}.tar.bz2
>
>
> Sandro
>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Self Introduction: Adrien Vergé
Salut ! You can join #fedora-fr and #fedora-devel-fr on freenode if you want to meet other French contributors :) Dridi On Fri, Mar 7, 2014 at 4:51 PM, Adrien Vergé wrote: > Hi everybody, > > I'm a French Fedora user and I'm trying to become a package maintainer for the > system I have been using for years! Usually I write C and Python for personal > stuff, I am also involved in projects (currently, tracing on Linux with > LTTng) and contributed to the Linux kernel. > > I would like to be a package maintainer for PhotoCollage [1], which I also > develop upstream. I submitted the package for review [2], can someone look > at it? :) > > Thanks! > > [1]: https://github.com/adrienverge/PhotoCollage > [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1073978 > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Self Introduction : Marianne Lombard
Hi, All this time I thought you were already maintaining packages :) Cheers, Dridi On Thu, Apr 24, 2014 at 2:20 PM, Marianne Lombard wrote: > Hi, > > I'm writing today because I have submitted my first package for review : > https://bugzilla.redhat.com/show_bug.cgi?id=1090933 > > I'm a sysadmin since a few years in a public research center and we are > using (a lot) of free and open-source software. So I will probably work on > sysadmin / scientific tools. > I will need a sponsor and I hope to find someone soon (probably a french > like me because my english is not perfect) > > Marianne > > -- > Marianne (Jehane) Lombard > Geekfeminist and sysadmin > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Incorrect order of /usr/bin and /usr/sbin in path
On Mon, May 5, 2014 at 4:35 PM, Kaleb S. KEITHLEY wrote: > On 05/05/2014 10:28 AM, Adam Jackson wrote: >> >> On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote: >> >>> however, the semantics of /usr/sbin is to contain superuser >>> binaries which should not be overriden because a binary >>> with the same name exists in /usr/bin >> >> >> My memory is that the "s" was more for "static" not "superuser". >> There's some conceptual overlap, static binaries being there to recover >> even if your shared libraries are hosed which is normally a "superuser" >> kind of operation, but. > > > My recollection is that the "s" in /sbin and /usr/sbin was more "system" > level management. Things an admin would need but would not usually be needed > by an ordinary user. > > Binaries in /bin and /sbin would have been statically linked to aid in > recovering a system in single-user mode when /usr might not be mounted, in > the days when disks were so small that /usr might often be a separate disk. Hi, From the hier(7) man page: /bin This directory contains executable programs which are needed in single user mode and to bring the system up or repair it. /sbin Like /bin, this directory holds commands needed to boot the system, but which are usually not executed by normal users. /usr This directory is usually mounted from a separate partition. It should hold only sharable, read-only data, so that it can be mounted by various machines running Linux. You can take a look at the FHS too: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard Dridi > -- > > Kaleb > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF: why does it refresh metadata all the time
On Fri, Jun 20, 2014 at 8:55 AM, drago01 wrote: > On Thu, Jun 19, 2014 at 8:59 PM, Jared K. Smith > wrote: >> On Thu, Jun 19, 2014 at 2:01 PM, Reindl Harald >> wrote: >>> >>> if *that* is what is supposed to make DNF faster it's just a lie >> >> >> This is not the only thing that DNF does differently to try to make package >> installations and updates go faster (or appear to go faster). Calling the >> developers liers doesn't help the situation any. >> >>> >>> if i am really interested in updates now i do "yum clean metadata && yum >>> upgrade" >>> for many years simply because you don't know how accurat you metadata are >> >> >> Sure, but you have to understand -- you're a power user. You know enough to >> do this in yum for your particular use case, which means you probably know >> enough to change the DNF settings with regards to cron-based metadata >> retrieval. What I think you're missing (and frankly, seem to miss in the >> lot of fedora-devel discussions you take part in) is that Fedora isn't >> engineered around *your* particular needs. We do things mostly by >> consensus, and aim to make it a pleasant experience for the *average* user >> (or whatever we have in the Fedora community that approximates an average >> user), and not just for power users with very specific needs and >> requirements. >> >> Whether you like it or not, one of the most common complaints about yum >> (especially from people coming from another package management system) is >> that it seems slow because of the necessity to download the metadata. The >> DNF developers -- in trying to address this common complaint -- had solved >> it by handling metadata in a different way. They've also added settings so >> that power users like you and I can tune it to better fit our particular >> needs. >> >>> >>> >>> and *no* traffic is not cheap everywhere, by far not >> >> >> I probably understand this better than a lot of people on this list, as I've >> been on a bandwidth-limited connection for the past nine years. Only in the >> past month have I been able to get high speed internet in my home that >> wasn't limited to a few gigabytes per month. So yes, I completely >> understand that traffic isn't cheap (or fast) everywhere. > > It should be at least smart enough to not do it on mobile broadband > (like packagekit does). Funny thing you mention this just when I was about to do the same! For various reasons my "home" internet access is my mobile phone and my first experience last week [1] with dnf on my main laptop was horrible. All this month's bandwidth is gone because I didn't notice dnf was downloading from every mirrors failure after failure. IMHO this feature is not ready to be on by default Dridi [1] I couldn't upgrade to heisenbug because of a fedup bug, and bandwidth limitations :) > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf even allows to uninstall RPM and systemd without warnings
On Tue, Jun 24, 2014 at 11:49 AM, Jon Kent wrote: > Been reading this for a while and I'm getting annoyed by the 'you should > know what you are doing' mob. There can be no reason not to have safe guards > in dnf to save you from the oh sh#t moments. Everyone has those at some time > and those who are learning Linux need these guards to avoid them trashing > their system. Everyone starts from a little knowledge base and we should > (must) take that on-board. > > It's irrelevant whether yum does or doesn't have this. If dnf is the new and > improved then it should have these from the off else what's to gain from an > end SAs point of view. No point in just creating a like-for-like > replication. Make it better and safer or don't bother. I have already added a comment [1] to the bz where I basically suggest that dnf acknowledges package protection, but delegates protection policies to plugins. Because I totally agree with you and IIRC this kind of stuff has been added over time in yum. Also IMHO some of those features are very fedora/el specific, and allows yum to work only on fedora and downstream distros. Yum expects the kernel rpm to be named "kernel", which is tied to how Fedora packages kernels. It's even worse for non-linux rpm-based OSs. But it depends on the project's goals. Do yum/dnf want to target rpm-based systems or fedora-based systems? Dridi [1] https://bugzilla.redhat.com/show_bug.cgi?id=1049310#c37 > Jon > > > On 24 Jun 2014 10:37, "Richard Hughes" wrote: >> >> On 24 June 2014 10:31, Thomas Bendler wrote: >> > you need to unlock the gun before you can shoot in your foot... >> > ...and modern systems ask you up to four, five times >> >> How many different locks does a gun have? Last time I checked there >> was one safety catch -- DNF asks you for 'y/N' confirmation with a >> HUGE list of packages to be removed. If you're not sure whether >> removing systemd or glibc is a bad idea, perhaps having root access >> isn't the best plan in the world. There are _so_ _many_ _ways_ to hose >> your system with root access, I really don't think we can or should >> baby-proof just one low level command. >> >> Richard >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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 even allows to uninstall RPM and systemd without warnings
On Tue, Jun 24, 2014 at 12:11 PM, Reindl Harald wrote: > > > Am 24.06.2014 12:05, schrieb Dridi Boukelmoune: >> Because I totally agree with you and IIRC this kind of stuff has been >> added over time in yum. Also IMHO some of those features are very >> fedora/el specific, and allows yum to work only on fedora and >> downstream distros. Yum expects the kernel rpm to be named "kernel", >> which is tied to how Fedora packages kernels > > that's not entirely true, otherwise it won't work the way it > does on Rawhide with only "kernel-core" installed, it's pretty > sure a matter of rpm-provides and in that case any distribution > cae name the kernel-package "linux" as long it provides kernel > in it's metadata > > [root@rawhide ~]# yum remove kernel > Skipping the running kernel: kernel-core-3.16.0-0.rc1.git4.1.fc21.x86_64 > No Packages marked for removal That is probably related to the "running kernel detection" which is even more distro-specific. What I had in mind is from yum.conf(5): > installonlypkgs > List of package provides that should only ever be installed, never updated. > Kernels in > particular fall into this category. Defaults to kernel, kernel-bigmem, > kernel-enterprise, > kernel-smp, kernel-modules, kernel-debug, kernel-unsupported, kernel-source, > kernel- > devel, kernel-PAE, kernel-PAE-debug. My point was more about fedora-specific assumptions in yum, and I'm not running rawhide so maybe kernel-core is now part of the defaults for `installonlypkgs`. I hope this clarifies what I meant. Dridi > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: delta rpms - can we turn them off
On Fri, Jun 27, 2014 at 6:14 PM, Jon wrote: > I personally tend to agree with Troy. > > We should consider defaulting to disable delta rpm at most, and at > least comment the configs, or make things intelligent. > > For me, it takes longer to process delta rpm files than to download > the actual full rpm, even on high end systems, or low end. > > I suppose in a way this goes back to the flame fest about the package > updater knowing about network conditions. > > * With great network conditions, downloading full rpm might be optimal > to the deltas. You also put more pressure on the mirrors hosts' bandwidth. Dridi > * With poor network conditions, deltas might be nice, but perhaps not > with low end computer. > > > > -Jon > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: delta rpms - can we turn them off
On Fri, Jun 27, 2014 at 7:13 PM, Kevin Fenzi wrote: > On Fri, 27 Jun 2014 19:11:53 +0200 > drago01 wrote: > >> That wasn't about "poor" as in slow vs. "great" as in fast but >> bandwith capped vs. not. >> >> If building deltas are slow the solution is not to disable them but to >> find out why there are slow and fix that. One thing for instance is >> that it insists on generating the original rpm while creating an >> uncompressed rpm would save a compress + uncompressed cycle during >> updates (the former is a bit extensive for xz). > > I think It could avoid doing that if people didn't mind that it couldn't > be gpg checked. It may also be possible to compress-and-sign them on the fly. If the gpg check can be done incrementally, you could compress the rpm to /dev/null and gradually compute the signature. That leaves you a signature to check and a ready-to-install rpm you don't need to uncompress again. > kevin > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Late introduction
Hi everyone, I am new to this list, and I'm a Fedora user for a little less than two years. Recently I've become a full-time Fedora user since I've installed it on my laptop for work. I'm a developer, and I usually work for companies that use RHEL in production. I think Fedora is a great distribution for development, because I love to be provided with latest versions of my favorite tools. Recently I have decided I would package tools I miss :) https://bugzilla.redhat.com/show_bug.cgi?id=953514 https://bugzilla.redhat.com/show_bug.cgi?id=989015 https://bitbucket.org/dridi/fedora_packages/ I'm willing to maintain those packages of course, but I haven't introduced myself yet, simply because I forgot. So here ends my late introduction. Best Regards, Dridi -- 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: Review Swaps: groonga-normalizer-mysql
Hi Christopher, Would you please review this one ? https://bugzilla.redhat.com/show_bug.cgi?id=989015 In exchange I would gladly review your other package: https://bugzilla.redhat.com/show_bug.cgi?id=972860 Dridi On Mon, Jul 29, 2013 at 7:29 AM, HAYASHI Kentaro wrote: > Hi, > > Thank you for your quick response. > > I'll review this one! > > fdm - A simple lightweight tool of fetching, filtering and delivering emails > https://bugzilla.redhat.com/show_bug.cgi?id=989297 > > > 2013/7/29 Christopher Meng >> >> Or this one if you don't like the previous. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=989297 >> >> fdm - A simple lightweight tool of fetching, filtering and delivering >> emails >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > > > > -- > HAYASHI Kentaro > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Late introduction
Hi again, I would like to introduce myself again, now that I've joined the package maintainers. I would like to thank my sponsor (kevin), Chris Roberts for his warm welcome, Christopher Meng and the others who helped me so far. Starting today (at least in my timezone =) the makeself package is available for Fedora 19, and I'll focus on tools for developers. I for instance would like to package tools such as vagrant (that transitively depends on makeself). I have a special interest in Varnish and Java ecosystems, Java and C being my primary languages. I know Linux folks tend to hate Java, so in return I'll hate Ruby[1]. And if sometimes you don't understand my English, please remember : because is French. Et pour les francophones (parce que je pense en avoir repérés), un petit bonjour. En espérant avoir l'occasion de croiser certains d'entre vous. Cheers, Dridi [1] just kidding, and vagrant is written in Ruby AFAIK ;) On Sat, Jul 27, 2013 at 1:22 AM, Chris Roberts wrote: > Hello Dridi Boukelmoune! > > Welcome to the Fedora community! > > - Chris Roberts > >>>> Dridi Boukelmoune 07/26/13 6:38 PM >>> > > Hi everyone, > > I am new to this list, and I'm a Fedora user for a little less than > two years. Recently I've become a full-time Fedora user since I've > installed it on my laptop for work. > > I'm a developer, and I usually work for companies that use RHEL in > production. I think Fedora is a great distribution for development, > because I love to be provided with latest versions of my favorite > tools. > > Recently I have decided I would package tools I miss :) > https://bugzilla.redhat.com/show_bug.cgi?id=953514 > https://bugzilla.redhat.com/show_bug.cgi?id=989015 > https://bitbucket.org/dridi/fedora_packages/ > > I'm willing to maintain those packages of course, but I haven't > introduced myself yet, simply because I forgot. So here ends my late > introduction. > > Best Regards, > Dridi > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Late introduction
Hi Mat, On Mon, Sep 2, 2013 at 11:51 AM, Mat Booth wrote: > Good to see more Java folks! > > Please consider subscribing to the java-devel list too :-) > > https://admin.fedoraproject.org/mailman/listinfo/java-devel Done ! > It is low volume, but it is where most Java-specific things are announced > and discussed. I have to confess I can't read everything on this very list. > Regards, > Mat Booth (mbooth) > > -- > Mat Booth > http://fedoraproject.org/get-fedora > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
numatop: %{optflags} fail the 32bit build
Hi,
I have my first packaging issue on the numatop package[1].
During the review it appeared that I forgot the %{optflags}, and that
adding them breaks the i686 build. The upstream dev is very patient
and willing to help me, but I feel I have wasted enough of his time.
The guilty gcc flag seems to be:
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 [2]
I can (hopefully) easily reproduce the failure with just mock on my
machine, but right now I can't figure out how to solve this. And the
fact that I don't know/understand this flag at all doesn't help.
Does anyone know what could be the cause and how to solve this ?
Dridi
[1] https://bugzilla.redhat.com/show_bug.cgi?id=numatop#c11
[2] it fails regardless of the _hardened_build macro
--
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: numatop: %{optflags} fail the 32bit build
Hi,
On Wed, Sep 11, 2013 at 8:46 AM, Florian Weimer wrote:
> On 09/11/2013 12:31 AM, Dridi Boukelmoune wrote:
>
>> I have my first packaging issue on the numatop package[1].
>>
>> During the review it appeared that I forgot the %{optflags}, and that
>> adding them breaks the i686 build. The upstream dev is very patient
>> and willing to help me, but I feel I have wasted enough of his time.
>>
>> The guilty gcc flag seems to be:
>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 [2]
>
>
> It would be helpful to provide more context and pointers to the analysis so
> far.
>
> The failing build log is here:
>
> http://kojipkgs.fedoraproject.org//work/tasks/1414/5911414/build.log
>
> This is the offending function:
>
> void
> cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
> unsigned int *edx)
> {
> __asm volatile
> ("cpuid\n\t"
> : "=a" (*eax),
>"=b" (*ebx),
>"=c" (*ecx),
>"=d" (*edx)
> : "a" (*eax));
> }
>
> The cryptic GCC error message (inconsistent operand constraints in an ‘asm’)
> refers to the fact that in PIC mode (which is activated by the hardening
> flags), %ebx is a reserved register.
Thanks for the explanation, I could never have figured this out.
> This version should work in 32 bit mode, and only in 32 bit mode:
>
> void
> cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
> unsigned int *edx)
> {
> __asm volatile
> ("push %%ebx\n\t"
> "cpuid\n\t"
> "mov %%ebx, (%1)\n\t"
> "pop %%ebx"
> : "=a" (*eax),
>"=S" (ebx),
>"=c" (*ecx),
>"=d" (*edx)
> : "0" (*eax));
> }
I "kind of" understand what you're doing here, but it's not all clear.
I get the push/pop instructions save and restore the reserved ebx
register, which is needed because apparently the cpuid instruction
would otherwise overwrite it.
I don't understand the mov instruction, but I suppose you're storing
ebx's value from cpuid "somewhere else" before restoring it with the
pop instruction.
I don't understand the last 5 lines of __asm in both functions, I've
never seen this syntax before.
> I have not actually tested this. There are other solutions floating around,
> but they are clearly incorrect and produce wrong code.
It builds, but it segfaults. Probably because the value is written
directly in the ebx variable, which is a pointer. I've added a temp
variable to fix the segfault, but I still need to check whether it
gives the expected value:
void
cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
#ifdef __x86_64
// original version
#else
unsigned int tmp;
__asm volatile
("push %%ebx\n\t"
"cpuid\n\t"
"mov %%ebx, (%1)\n\t"
"pop %%ebx"
: "=a" (*eax),
"=S" (tmp),
"=c" (*ecx),
"=d" (*edx)
: "0" (*eax));
*ebx = tmp;
#endif
}
I don't actually have the code on this computer but I remember doing
something like that, so this is only pseudo code :)
> In 64 bit mode, you should use the original version.
>
> --
> Florian Weimer / Red Hat Product Security Team
Thank you both for your help, I'll find some time this weekend to test
it further before sending it back to the upstream project.
Dridi
--
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: numatop: %{optflags} fail the 32bit build
The issue has been solved by my reviewer, so thank you all because as
usual I've learned interesting things :)
Comments inlined.
On Thu, Sep 12, 2013 at 2:53 PM, Florian Weimer wrote:
> On 09/12/2013 02:11 PM, Dridi Boukelmoune wrote:
>
>>> This version should work in 32 bit mode, and only in 32 bit mode:
>>>
>>> void
>>> cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
>>>unsigned int *edx)
>>> {
>>>__asm volatile
>>> ("push %%ebx\n\t"
>>> "cpuid\n\t"
>>> "mov %%ebx, (%1)\n\t"
>>> "pop %%ebx"
>>> : "=a" (*eax),
>>> "=S" (ebx),
>>> "=c" (*ecx),
>>> "=d" (*edx)
>>> : "0" (*eax));
>>> }
>>
>>
>> I "kind of" understand what you're doing here, but it's not all clear.
>>
>> I get the push/pop instructions save and restore the reserved ebx
>> register, which is needed because apparently the cpuid instruction
>> would otherwise overwrite it.
>>
>> I don't understand the mov instruction, but I suppose you're storing
>> ebx's value from cpuid "somewhere else" before restoring it with the
>> pop instruction.
>
>
> Correct, the intent is to write the %ebx register value to the address in
> the %esi register. "(%1)" is a pointer dereference, as oppose to plain %1.
>
>
>> I don't understand the last 5 lines of __asm in both functions, I've
>> never seen this syntax before.
>
>
> These are register constraints. "a", "c", "d", "S" refer to the %eax, %ecx,
> %edx, %esi registers, respectively. "=" marks output constraints. The
> constraints before the final ":" are output registers, and after colon,
> there are the input registers. There's just one, and "0" means to reuse the
> first output register.
>
> Okay, silly me, I should have listed "S" among the output registers, instead
> the inputs:
Actually, this morning (in the train) I've tested your code with my
tmp variable and it works if I remove the deref!
mov %%ebx, %1
(btw, what do %1 and %4 mean ?)
I could painlessly add a println in my patch since the file already
includes stdio.h. Normal and hardened build provide the same cpuid
values.
> void
> cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
> unsigned int *edx)
> {
> __asm volatile
> ("push %%ebx\n\t"
> "cpuid\n\t"
> "mov %%ebx, (%4)\n\t"
> "pop %%ebx"
> : "=a" (*eax),
>"=c" (*ecx),
>"=d" (*edx)
> : "0" (*eax),
>"S" (ebx));
> }
>
> I also forget that for full correctness, there should now be a "memory"
> clobber as well (in the clobber section after yet another colon):
What would it do ? A compiler memory barrier ?
> void
> cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
> unsigned int *edx)
> {
> __asm volatile
> ("push %%ebx\n\t"
> "cpuid\n\t"
> "mov %%ebx, (%4)\n\t"
> "pop %%ebx"
> : "=a" (*eax),
>"=c" (*ecx),
>"=d" (*edx)
> : "0" (*eax),
>"S" (ebx)
> : "memory");
> }
It's a good thing my reviewer submitted a patch, because I wouldn't
feel that confident with mine :)
> By the way, we could generate much better code if the registers were passed
> as an array or struct, so that they are in consecutive memory:
>
> struct regs {
> unsigned eax, ebx, ecx, edx;
> };
>
> void
> cpuid(struct regs *r)
>
> {
> __asm volatile
> ("push %%ebx\n\t"
> "cpuid\n\t"
> "mov %%eax, (%0)\n\t"
> "mov %%ebx, 4(%0)\n\t"
> "mov %%ecx, 8(%0)\n\t"
> "mov %%edx, 12(%0)\n\t"
> "pop %%ebx"
> :
> : "S" (r)
> : "eax", "ecx", "edx", "memory");
> }
>
> Obviously, this needs adjustments to the callers.
Yup, but for the sake of simplicity, I wouldn't do that.
> --
> Florian Weimer / Red Hat Product Security Team
Dridi
--
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: numatop: %{optflags} fail the 32bit build
On Thu, Sep 12, 2013 at 5:39 PM, Dave Jones wrote:
> On Wed, Sep 11, 2013 at 08:46:33AM +0200, Florian Weimer wrote:
>
> > This is the offending function:
> >
> > void
> > cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
> > unsigned int *edx)
> > {
> > __asm volatile
> > ("cpuid\n\t"
> > : "=a" (*eax),
> >"=b" (*ebx),
> >"=c" (*ecx),
> >"=d" (*edx)
> > : "a" (*eax));
> > }
> >
> > The cryptic GCC error message (inconsistent operand constraints in
> > an ‘asm’) refers to the fact that in PIC mode (which is activated
> > by the hardening flags), %ebx is a reserved register.
> >
> > This version should work in 32 bit mode, and only in 32 bit mode:
> >
> > void
> > cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
> > unsigned int *edx)
> > {
> > __asm volatile
> > ("push %%ebx\n\t"
> > "cpuid\n\t"
> > "mov %%ebx, (%1)\n\t"
> > "pop %%ebx"
> > : "=a" (*eax),
> >"=S" (ebx),
> >"=c" (*ecx),
> >"=d" (*edx)
> > : "0" (*eax));
> > }
> >
> > I have not actually tested this. There are other solutions
> > floating around, but they are clearly incorrect and produce wrong
> > code.
>
> A better fix would be to rip all this out, and use reads from
> /dev/cpu/*/cpuid, which is arch agnostic, and also takes care of cpu affinity
> problems.
>
> Dave
On my ubuntu machine at work, I have this:
$ ls /dev/cpu/
microcode
Also, wouldn't it be a problem on a chrooted environment ?
And during my tests I've noticed that numatop calls cpuid once for
each core on my laptop. It should discard the affinity problem,
shouldn't it ?
Tanks again for your help, it's been very interesting for me !
Dridi
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Self Introduction
Welcome! Ag was on my own TODO-list, I'll happily review it for you (but you'll still need to find a sponsor). Cheers, Dridi On Sat, Sep 14, 2013 at 10:56 AM, Henrik Hodne wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hey everyone! > > My name is Henrik Hodne, and I'm a student at the University of > Illinois at Urbana-Champaign, where I'm currently pursuing a > Bachelor's degree in Computer Engineering. I'm also core team member > at Travis CI (https://travis-ci.com / https://travis-ci.org). > > I first used Fedora a few years ago, and got reintroduced to it by a > friend a few weeks back when I started looking for a Linux distro to > put on my new laptop. I wanted to contribute, so after looking up ways > to do so I decided to join the Norwegian translation team (I was born > and raised in Norway, and only recently moved to the U.S.). I > discovered that some of my favorite tools were not available as Fedora > packages, so I decided to spend some time looking into how to add > them, so now here I am! > > I just posted my first review request here (for > ag/the_silver_searcher, a faster grep/ack replacement): > https://bugzilla.redhat.com/show_bug.cgi?id=1008063. There were a lot > of different things in the guides to go through, and hopefully I > included everything I needed… > > Anyways, I look forward to contributing more to the Fedora Project! > > Best, > Henrik Hodne > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.14 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSNDLIAAoJEBSXlMsKCt+/VlEQAI9/Ll56fq5TCGFcGadiKAXA > lE3M258Z2wljjY4sWZqCkQ+mzDrrfjXvov9BwWGKuqQgjsR3MtHQ4nNRRZM9syJU > W5wVGVj/LE+tPscb91azgA5uJtCNTHJjyq7ZZnAujVF+8ciLWMbfu+JwPuUdPY26 > f6Gol19UZsERuTzuSllAzqHxETiVkA5/Cj5/z0Iw/b8D0zla0UCs4M79F0TsqgpC > NLC8QqyzuPvmf0MVp6FcTcpD52Lz2Gu/tzjVt6cX5gA9yRcuTXWqvrk8reYNJ6yC > LsifLdOFQtcPzh70i6lwMBGPoflerl4DC0IV2y0PSUARjywY0YsILgw4VTwrSMap > iNwGwHLzIlRewK/h2dsS9eltP7nqNuZSBxuviM4icp7VOM7e6D9lpBefCuiWpQYo > AJfoLyD1peGUwQIO826jncj2/LjUjoimQ6Sij+Fx/JSoCrDfomhyLYGml2Q9GYhE > j392H8RY3s0W5uNTHCFq12QvZkkza3cD9pvLD0YEGQDNzQvzCBEJEbo1y6GsS/FC > i5RNnQENj1C44rS/Rl8DAhLCRJp9HTuL/BYzAVFlpAzRETcA7Pif0peEw5fYcFLT > V/W58wuKIPqn0NdA00ZHDWB2iWAVHnwcFnnL2OUC9qVuEGmRmJ+4J3sfICFSqwT9 > sQumlPgRXlqCw6d7sfKf > =ZOFz > -END PGP SIGNATURE- > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Full subpackage (-n type) with different version from main package
Hi, Have you tried to tweak the %setup macro with the -n option ? Best Regards, Dridi On Sun, Sep 15, 2013 at 5:55 PM, Richard Shaw wrote: > I'm working on updating the trustedqsl package and it looks like the > developers have decided to include a new version of tqsllib in the > TrustedQSL main source. So besides having to Obsolete/Provide the old > package, it also has a different version number from the apps. > > Maximum RPM[1] seems to indicate this should be possible using a Version: > tag within the %package -n tqsllib section and it does unpack the source > correctly, but then tries to cd into the source using the version from > tqsllib (2.3) instead of the main package version (1.14.3). > > Any ideas? > > Thanks, > Richard > > [1] > http://www.rpm.org/max-rpm-snapshot/s1-rpm-subpack-spec-file-changes.html > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review swaps: perl-Parse-DebControl, devscripts, debian-keyring, ubuntu-keyring, jetring + question: where to install keyrings?
On Thu, Sep 19, 2013 at 6:41 PM, Sandro Mani wrote:
> Hi,
>
> In the hope to continue the effort of getting pbuilder (and hence an easy
> way to build deb packages from fedora) into the repos (review here: [1]),
> I've packaged devscripts, debian-keyring, ubuntu-keyring and jetring.
> Reviews are here:
>
> - jetring: https://bugzilla.redhat.com/show_bug.cgi?id=1009996
> - debian-keyring: https://bugzilla.redhat.com/show_bug.cgi?id=1009997
> - ubuntu-keyring: https://bugzilla.redhat.com/show_bug.cgi?id=1009998
> - perl-Parse-DebControl: https://bugzilla.redhat.com/show_bug.cgi?id=100
> - devscripts: https://bugzilla.redhat.com/show_bug.cgi?id=101
I can swap devscripts with varnish-agent if you're interested:
https://bugzilla.redhat.com/show_bug.cgi?id=varnish-agent
> A question concerning the keyrings: currently, the only other package
> (afaics) containing distro keyrings is archlinux-keyring. That package
> installs the keyrings in /usr/share/pacman/keyrings. The debian-keyring and
> ubuntu-keyring packages I've posted for review install the keyrings in
> /usr/share/keyrings. This directory is however unowned. I see two options:
> - install {debian,ubuntu} keyrings in /usr/share/{ubuntu,debian}/keyrings,
> and have them own the directories
> - have gnupg own the directory /usr/share/keyrings (and possibly have
> archlinux-keyring also install the keyrings there)
> Suggestions?
>
> Thanks,
> Sandro
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=969718
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Source file audit - 2013-09-30
Hi, In my case, the makeself source tarball is hosted on github. I've seen many people saying that github was down recently (even though it worked fine for me). curl -LI http://github.com/megastep/makeself/archive/release-2.2.0.tar.gz [... redirections stuff ...] HTTP/1.1 200 OK [... headers ...] Other packages might be related to the github outage. Regards, Dridi On Fri, Oct 4, 2013 at 9:15 AM, Alec Leamas wrote: > On 10/03/2013 11:35 PM, Kevin Fenzi wrote: >> >> [cut] >> leamas:BADURL:xlwt-0.7.4.tar.gz:python-xlwt >> [cut] > > These are pypi urls which looks just fine to me (spectool -g works OK) > > --alec > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review swaps: perl-Parse-DebControl, devscripts, debian-keyring, ubuntu-keyring, jetring + question: where to install keyrings?
Hi Sandro, Sorry for the delay, but I've been very busy at work for the past couple weeks. I've only read mails mentioning me, hence the very short answer on the BZ. I also got sick last friday, before the very weekend I wanted to work on fedora (your review, but also my packages). It's only today that I've come back to work and started catching up with mails and I'm glad you found someone for the review. I've quickly tried to run a fedora-review when I was sick, but it failed (I've also tried to tweak the command line to review it on fc21, but I still got the missing dep). So I gave up and came back to bed... Please let me know if there is another package of yours to review. Best Regards, Dridi On Mon, Oct 7, 2013 at 8:46 AM, Ville Skyttä wrote: > On Mon, Oct 7, 2013 at 3:32 AM, Sérgio Basto wrote: >> On Dom, 2013-10-06 at 11:46 +0300, Ville Skyttä wrote: >>> On Sun, Oct 6, 2013 at 7:27 AM, Sérgio Basto wrote: >>> > >>> > we still doesn't have rpmdevtools-8.4 packaged for F21 ... >>> >>> I'll look into it as soon as it starts to look that devscripts will be >>> approved. >> >> haven't we enter in loop here ?, I think we are waiting for >> rpmdevtools-8.4 packaged for F21 , to be able to install devscripts >> without have conflicts with rpmdevtools . > > Don't wait for that, just remove rpmdevtools while reviewing devscripts. > https://bugzilla.redhat.com/show_bug.cgi?id=101#c15 > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fonts rendering and hinting
Hi all, I'm reading a blog called bad concurrency, and I didn't expect a post on Fedora[1] yesterday. Since I'm not really into eye-candy (running xfce since fc16, started with Fedora on a gnome fc15), I've never really tried to tweak my desktop that much (I do a few things though). What really caught my attention here is that he mentions an expired patent, and I was wondering why it's only available on rpm fusion. My guesses: - there are other legal issues - interested parties missed/forgot it - interested parties are working on it Does anyone know about this ? As I said I'm not really into eye-candy but smoother fonts means easier reading, and that would be better for our eyes, wouldn't it ? Dridi [1] http://bad-concurrency.blogspot.co.nz/2013/10/fonts-on-fedora-core-19.html -- 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: Differences between Fakeroot and Mock & Suggested method
Hi Matt,
I believe this is the easiest way to setup your build host:
sudo yum group install "Fedora Packager"
sudo yum install fedora-review
I personally use rpmbuild and then mock before submitting the packages.
Best Regards,
Dridi
On Thu, Oct 10, 2013 at 4:31 PM, Richard W.M. Jones wrote:
> On Wed, Oct 09, 2013 at 12:32:08PM -0700, Matt Eskes wrote:
>> It's taking a bit of time, but I plan to start packaging a couple of
>> packages that are not currently available for either Red Hat nor Fedora.
>> The main reason for it taking a bit longer really has to do with
>> personal infrastructure and setting up my build host, etc.
>>
>> However, that doesn't really pertain to the question at hand. I come
>> from a Debian centric environment, and have "come back" to Red Hat and
>> Fedora after more than a decade. As such, I have quite a bit more
>> experience building my packages with fakeroot, than I do with mock, and
>> I'm wondering what the differences between the two packages/processes are.
>>
>> Will using mock in this environment be more beneficial to using
>> fakeroot? Will it be "harder" for lack of a better word, to build from
>> within the build system using fakeroot , once I get to that point or, is
>> Koji flexible enough so that it really wouldn't matter from an
>> infrastructure point of view as to whether or not I use one or the other?
>>
>> As I am more familiar with fakeroot, I'd like to keep using that, but
>> at the same time, I'd like to do it the "Red Hat way" to ensure that the
>> package conforms to both Red Hat and Fedora packaging standards.
>
> [Incidentally to this, I was the co-maintainer of fakeroot &
> fakechroot in some branches of Fedora (not any longer).]
>
> I would highly recommend *not* trying to use fakeroot. It's not
> necessary to build RPMs either as root or emulating root (as is done
> in Debian). There should be no step that requires root.
>
> The two common things you would think might require root would be:
>
> (1) 'make install'
>
> (2) Setting setuid bits on binaries.
>
> (1) -- make install -- does not need to be run as root by rpmbuild
> because we use a DESTDIR to put the files into a buildroot under your
> $HOME, ie:
>
> make install DESTDIR=%{buildroot}
>
> RPM does the magic of turning the buildroot into the package.
>
> (2) -- setuid -- does not need to be done because you can set
> attributes on files in the %files section. RPM turns these into
> setuid bits at package install time (which does happen as root).
>
> So, forget about fakeroot. Not needed. Don't run rpmbuild as real
> root either.
>
> You don't really need to use mock either. Just use 'rpmbuild -ba'
> directly or 'fedpkg local' which is a wrapper.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: yum picking kernel-debug instead of kernel for 'BuildRequires: kernel'
On Wed, Aug 28, 2013 at 4:53 PM, Richard W.M. Jones wrote: > On Wed, Aug 28, 2013 at 04:13:58PM +0100, Richard W.M. Jones wrote: >> >> If two packages 'provide' the same dependency, isn't yum supposed to >> pick the one with the shortest name? >> >> Anyway, 'BuildRequires: kernel' in Rawhide (on koji) picks >> 'kernel-debug' instead of 'kernel'. Is there a way to make it pick >> 'kernel' instead? > > And a similar story in Fedora 19 (i686) where this requirement > picks up 'kernel-PAEdebug' (instead of 'kernel'). > > Rich. Hi, I've a similar problem with mock, if I create a spec that BuildRequires kernel I end up with kernel-debug in the chroot. Dridi > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. Supports Linux and Windows. > http://people.redhat.com/~rjones/virt-df/ > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: prelink performance gains
Hi, This is one of these passionate threads I enjoy reading because I usually learn something interesting, and I also enjoy people being passionate about stuff. But this time I'm a bit disappointed about the defaults for Fedora. I'm a developer, and I work with production-like systems (and in some cases production systems) on my day job, so integrity of the system is something very important to me. I was startled when I first read that prelink touches binaries. For I'm too lazy to mount /usr as read-only (actually too lazy to mount it read/write for each yum upgrade), I naively expected binaries would be safe with default settings (assuming no attack). I've run the following commands: $ rpm -V varnish S.5T. c /etc/varnish/varnish.params $ rpm -V firefox $ rpm -V libreoffice-core prelink: /tmp/#prelink#.TZlaPL: Recorded 92 dependencies, now seeing -1 S.?../usr/lib64/libreoffice/program/gengal.bin prelink: /tmp/#prelink#.3AZudQ: Recorded 87 dependencies, now seeing -1 S.?../usr/lib64/libreoffice/program/libavmedialo.so prelink: /tmp/#prelink#.9xDUuT: Recorded 16 dependencies, now seeing -1 S.?../usr/lib64/libreoffice/program/libbasegfxlo.so [...] Obviously, I'm ok with varnish being touched, I've changed something in the configuration. I'm also relieved that firefox's clean, because I use it heavily on a day-to-day basis. But this is rather disturbing to see prelink on rpm's output. Does it mean that rpm *itself* has been touched by prelink ? This sounds critical to me, how can I know that my rpmdb hasn't been corrupted ? Of course an attacker that would gain root access to the system could probably alter the rpmdb to "hide" what changed on the filesystem, but that's not my point. I've removed the prelink package: $ rpm -V libreoffice-core S.5../usr/lib64/libreoffice/program/gengal.bin S.5../usr/lib64/libreoffice/program/gnome-open-url.bin S.5../usr/lib64/libreoffice/program/libavmedialo.so S.5../usr/lib64/libreoffice/program/libbasegfxlo.so S.5../usr/lib64/libreoffice/program/libcanvastoolslo.so [...] Now libreoffice still appears to be (differently) tainted, but rpm doesn't output prelink stuff anymore (which isn't less scary). Don't get me wrong, I really enjoy Fedora on my laptops (and before on VMs) but I have a serious trust issue now: - this is part of the distribution *by default* - it is present and already acts at the very first boot AFAIU - removing it doesn't restore the binaries (I didn't expect it would) - apparently it prevents hardened builds in some cases After three reboots, I can't tell the difference between now and before, but to be fair I haven't really paid attention to the start time of the system and applications such as the ones in libreoffice. In my opinion, if there is no perceived latency, it is irrelevant. It all started as a fun thread, with interesting opinions and arguments, but now I have one question: Are there other packages installed by default that would alter my system ? Best Regards, Dridi PS. I'm a total security noob, I'm just aware of basic stuff On Tue, Oct 15, 2013 at 10:35 PM, drago01 wrote: > On Tue, Oct 15, 2013 at 10:27 PM, Reindl Harald > wrote: >> >> >> Am 15.10.2013 22:04, schrieb Florian Weimer: >>> On 10/15/2013 09:10 PM, Chris Adams wrote: Once upon a time, Jan Kratochvil said: > It depends, for example in this case prelink saves 33% of time (and > battery): > i=0;time while [ $i -lt 1000 ];do /usr/bin/gnome-open --help > &>/dev/null;i=$[$i+1];done Do you really run "gnome-open --help" 1000 times per reasonable unit of time (or ever)? Please stop using bogus comparisons and highly contrived tests. They do nothing to help your argument. >>> >>> This isn't totally invalid. I assume that some shell scripts with tight >>> loops are the only thing that actually >>> benefits from prelinking today. People write those, unfortunately. >> >> it is - they are *not* loading a lot of dynmaic linked libraries >> >> [harry@srv-rhsoft:~]$ ldd /usr/bin/bash >> linux-vdso.so.1 => (0x7fffc9764000) >> libtinfo.so.5 => /lib64/libtinfo.so.5 (0x7f99b21aa000) >> libdl.so.2 => /lib64/libdl.so.2 (0x7f99b1fa6000) >> libc.so.6 => /lib64/libc.so.6 (0x7f99b1be4000) >> /lib64/ld-linux-x86-64.so.2 (0x7f99b23ee000) > > Yes because shell is a real programming language that does not have to > start tons of other binaries to do useful stuff ... oh wait. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: prelink performance gains
On Tue, Oct 15, 2013 at 11:31 PM, Matthew Miller wrote: > On Tue, Oct 15, 2013 at 10:51:18PM +0100, Dridi Boukelmoune wrote: >> $ rpm -V varnish >> S.5T. c /etc/varnish/varnish.params >> $ rpm -V firefox >> $ rpm -V libreoffice-core >> prelink: /tmp/#prelink#.TZlaPL: Recorded 92 dependencies, now seeing -1 > > Check out "-y" in the prelink man page. It does a dance where it undoes > prelinking so the original checksum can be calculated. Didn't work, after a quick peep in the man I ended up doing: $ sudo prelink --undo --all A few reboots, and I still don't notice any obvious degradation of the start time of either the OS or programs like writer. I should have read the man in the first place, but I was a bit upset. >> I've removed the prelink package: > > There was a bug referenced earlier in this thread: removing prelink doesn't > undo what it's already done, so this doesn't work. Instead, you have to > configure prelink to disable itself, run it again over all of your files, > and *then* remove. > >> Are there other packages installed by default that would alter my system ? > > Not in this way, no. Thank you for your help, feeling much better :) > -- > Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: prelink performance gains
On Wed, Oct 16, 2013 at 7:57 AM, Panu Matilainen wrote: > On 10/16/2013 12:51 AM, Dridi Boukelmoune wrote: >> >> Hi, >> >> This is one of these passionate threads I enjoy reading because I >> usually learn something interesting, and I also enjoy people being >> passionate about stuff. But this time I'm a bit disappointed about the >> defaults for Fedora. >> >> I'm a developer, and I work with production-like systems (and in some >> cases production systems) on my day job, so integrity of the system is >> something very important to me. I was startled when I first read that >> prelink touches binaries. For I'm too lazy to mount /usr as read-only >> (actually too lazy to mount it read/write for each yum upgrade), I >> naively expected binaries would be safe with default settings >> (assuming no attack). >> >> I've run the following commands: >> >> $ rpm -V varnish >> S.5T. c /etc/varnish/varnish.params >> $ rpm -V firefox >> $ rpm -V libreoffice-core >> prelink: /tmp/#prelink#.TZlaPL: Recorded 92 dependencies, now seeing -1 >> >> S.?../usr/lib64/libreoffice/program/gengal.bin >> prelink: /tmp/#prelink#.3AZudQ: Recorded 87 dependencies, now seeing -1 >> >> S.?../usr/lib64/libreoffice/program/libavmedialo.so >> prelink: /tmp/#prelink#.9xDUuT: Recorded 16 dependencies, now seeing -1 >> >> S.?../usr/lib64/libreoffice/program/libbasegfxlo.so >> [...] >> >> Obviously, I'm ok with varnish being touched, I've changed something >> in the configuration. I'm also relieved that firefox's clean, because I >> use it heavily on a day-to-day basis. But this is rather disturbing to >> see prelink on rpm's output. Does it mean that rpm *itself* has been >> touched by prelink ? This sounds critical to me, how can I know that >> my rpmdb hasn't been corrupted ? > > > Yup, prelink screws up rpm -V pretty badly. Rpm does do know about prelink > and does 'prelink -u' to verify the unprelinked binary matches the original > digest but all too often prelink -u fails, in which case there's nothing rpm > can do about it. As in the above cases and perhaps the more common one: > > [root@localhost ~]# rpm -Va > prelink: /usr/lib/udev/udev-configure-printer: at least one of file's > dependencies has changed since prelinking > S.?../usr/lib/udev/udev-configure-printer > .M.../var/lib/nfs/rpc_pipefs > .M.../var/log/journal > prelink: /usr/bin/eog: at least one of file's dependencies has changed since > prelinking > S.?../usr/bin/eog > [...] > > This might not be *that* much of an issue on a more stable distro, but given > the constant churn of Fedora there's not a day when something hasn't > changed, causing rpm -Va (and other security tools) to come up with > indeterminate results until the prelink cronjob runs. And then more stuff > gets updated etc... > > >> Of course an attacker that would gain root access to the system could >> probably alter the rpmdb to "hide" what changed on the filesystem, but >> that's not my point. > > > Silently changing rpmdb to match what changed on the filesystem is that easy s/is/isn't/ ? > as the file digests are buried within headers guarded with digital > signatures and further digests over the contents. You basically need to > replace the entire package, at which point it will no longer have a Fedora > signature and is quite a clear indication that something is not right. I said probably because I didn't know. I'd assume a tight security on such a critical package. But I have to confess I don't check that all my packages are signed that often. And rpm -V doesn't warn me about home-made packages not being signed. So a package losing its signature in the database could easily stay unnoticed (unless there are other mechanisms). > - Panu - > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: prelink performance gains
On Wed, Oct 16, 2013 at 7:45 AM, Jan Kratochvil wrote: > On Tue, 15 Oct 2013 23:51:18 +0200, Dridi Boukelmoune wrote: >> $ rpm -V libreoffice-core >> prelink: /tmp/#prelink#.TZlaPL: Recorded 92 dependencies, now seeing -1 > > Repeating for the third time in this thread: > This is a known prelink Bug and you can find the single line fix/workaround > there: > -y has false mismatches > https://bugzilla.redhat.com/show_bug.cgi?id=666143 I understand, but what bothers me isn't the prelink bug but prelink itself being installed by default (for what it does regardless of the bug). > The 'rpm -V' output should be also fixed by full prelink of the system: > touch /var/lib/prelink/force; /etc/cron.daily/prelink > > > Jan -- 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: Taking owner ship of mod_scgi: re-review, and rutorrent review swap
I'll review mod_scgi, if you're interested I need a review for this: https://bugzilla.redhat.com/show_bug.cgi?id=vcsh Dridi On Mon, Sep 30, 2013 at 9:16 AM, Ankur Sinha wrote: > Hi, > > mod_scgi was orphaned quite a while back since it wouldn't build on new > releases, with the new apache. I found a set of patches in the suse rpm > that fix the build. I'd like to get mod_scgi back into the repos. It's > required by most rtorrent front ends, like rutorrent that I've just > submitted for review. > > I'll be more than happy to co-maintain this module with someone more > knowledgeable with apache and friends :) > > Bugz: > > https://bugzilla.redhat.com/show_bug.cgi?id=1013485 - mod_scgi re-review > https://bugzilla.redhat.com/show_bug.cgi?id=1013488 - rutorrent > > Review swaps are welcome as always. > -- > Thanks, > Warm regards, > Ankur (FranciscoD) > > http://fedoraproject.org/wiki/User:Ankursinha > > Join Fedora! Come talk to us! > http://fedoraproject.org/wiki/Fedora_Join_SIG > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F25 Self Contained Change: Rust Compiler
On Wed, Jul 13, 2016 at 11:11 AM, Igor Gnatenko wrote: > I meant that rust itself links dynamically to system libraries. But > libraries built by rust are not supposed to be dynamically linked by > programs. Hello, Since 1.10 (the target of this change) it has become possible to create "cdylib" (C dynamic library) crates, basically shared objects that can be linked to by non-Rust programs. It isn't supported by cargo yet, but it's available.. Dridi -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Review swaps
Hi, I have two pending reviews that I believe should be very simple to perform, because both packages are quite small C libraries. I worked upstream to make them packaging-friendly. https://bugzilla.redhat.com/show_bug.cgi?id=vmod-querystring https://bugzilla.redhat.com/show_bug.cgi?id=libslz Thanks, Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: FAS name change
On Tue, Oct 4, 2016 at 8:21 AM, Sylvia wrote: > > Hello Athos! > > Did you solve your problem in Bodhi? > > > Cheers, > Sylvia > > > On Sat, 2016-10-01 at 10:55 -0300, Athos Coimbra Ribeiro wrote: > > Hello, > > [...] Hello Sylvia, Please avoid top-posting when replying on mailing lists. See https://fedoraproject.org/wiki/Mailing_list_guidelines#If_You_Are_Replying_to_a_Message Cheers, Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Many directories without owning packages
Hello,
I was surprised to see /usr/share/texlive on my system although I
remembered very well removing it months ago. It turned out to be
caused by two rpmsave files, although some *empty* directories weren't
removed:
$ find /usr/share/texlive/
/usr/share/texlive/
/usr/share/texlive/texmf-dist
/usr/share/texlive/texmf-dist/web2c
/usr/share/texlive/texmf-dist/web2c/fmtutil.cnf.rpmsave
/usr/share/texlive/texmf-dist/web2c/updmap.cfg.rpmsave
/usr/share/texlive/texmf-dist/tex
/usr/share/texlive/texmf-dist/tex/latex
/usr/share/texlive/texmf-dist/tex/latex/misc
/usr/share/texlive/tlpkg
/usr/share/texlive/tlpkg/TeXLive
/usr/share/texlive/tlpkg/tlpostcode
/usr/share/texlive/tlpkg/translations
But then I decided to check my whole /usr tree and found more orphans
than I expected.
My crude data gathering:
$ find /usr/ -type d -exec rpm -qf {} \; |
grep 'not owned' |
tee not_owned.txt
And the results on my current fc24 laptop:
$ wc -l
Re: F21 downloads repository metadata in 3 places!
On Mon, Dec 15, 2014 at 2:09 PM, Hedayat Vatankhah wrote: > 2. I believe that the use should know, and more importantly be able to > control WHEN the repo data is being updated. At the very least, he should be > able to specify if the updates are automatic or not using a very user > friendly method (probably during/after the installation; or per network > connection). I can only agree with this. Thanks to this thread I understand why I'd get noticeable slowdowns and bandwidth peaks with tethering. I already had an issue once with a DNF bug that took away a month's worth of bandwidth in one hour by repeatedly downloading packages until my data plan was shut down for the rest of the month. I believe that defaults should not aim for the best case but rather the worst. If my memory serves well (don't get me started) you can easily choose with with windows updates how you want to use it (automatically, on demand, etc) and that's something GUIs could provide. And again, you wouldn't just give a choice between different setups, but also explanations. And I don't mind having automatic background updates as the "recommended" strategy, as long as it comes with explanations on what it means. Command-line users like me can instead have a look at the man and system config (I know I should have done that) but I insist on prudent defaults. We should assume that convenient defaults could hurt other users instead, and especially non power users. Cheers, Dridi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
CLI tools in Gnome Software?
Hi, RichiH, author of vcsh (one of my packages) and Debian contributor asked my whether we could upstream Fedora packaging (more precisely any packaging metadata). I simply showed him where the package's git repo and we agreed I would notify him when I commit stuff. Btw, is there a simple way to subscribe without a FAS account? It occurred to me that we are encouraged to upstream Gnome Software app metadata, but I don't use Gnome. Are CLI tools welcome in Gnome Software? I guess I could contribute a French translation, and we could take screenshots of Gnome's terminal. Would it be relevant? Thanks, Dridi -- 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: Remove gcc, gcc-c++ and make from minimal build root
On Mon, Jan 12, 2015 at 2:08 PM, Vít Ondruch wrote: > Dear Fedora developers, > > I'd like to collect some feedback about the $SUBJECT, i.e. making > minimal build root really minimal, explicitly specifying build > dependencies, etc. Hi, I think this is a good idea, because overall I tend to avoid implicit or invisible rules. And the man says "mock - build SRPMs in a chroot" so having a minimal tree in which you can chroot and find tools to build SRPMs sounds like a neat idea :) > The topic originally spring out in this [1] discussion on packaging > list. Interesting FPC discussion on this topic can be find in this > ticket [2] and meeting minutes from last FPC meeting [3]. As a mock user on RHEL and CentOS systems, I haven't seen any mention of EPEL in the FPC ticket and minutes. I may be wrong, but I'm pretty sure I got mock and the @buildsys-build group from the EPEL repos. You might want to enable such a change for the next EPEL too, or at least take it into account. I don't have access to those machines right now. Dridi > Thanks > > > Vít > > > > [1] > https://lists.fedoraproject.org/pipermail/packaging/2014-December/010398.html > [2] https://fedorahosted.org/fpc/ticket/490 > [3] > https://lists.fedoraproject.org/pipermail/packaging/2015-January/010424.html > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Remove gcc, gcc-c++ and make from minimal build root
On Fri, Jan 16, 2015 at 10:08 AM, Marcin Juszkiewicz wrote: > GCC change may affect binaries which will generate other output which > will change noarch packages. It shouldn't change a program's behavior, unless the program itself is relying on undefined behavior. Either way I would call that a bug. The only "output" change that I could understand is something like a `vim --version` (though it doesn't actually show gcc's version, but close enough). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 26 Mass Rebuild - gnutls, µhttpd users
>> > >> systemd failed to rebuild. There were a couple of issues, but it's the >> > >> last one that's interesting. gnutls and µhttpd dependencies are not >> > >> detected properly: >> > >> >> > >> $ rpm -q gnutls-devel >> > >> gnutls-devel-3.5.9-1.fc26.x86_64 >> > >> $ "/usr/bin/pkg-config" "--cflags" "gnutls" || echo "NOT OK" >> > >> Package libidn2 was not found in the pkg-config search path. >> > >> ... >> > >> NOT OK >> > >> >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1422256 >> > >> >> > >> I assume that might impact any package which uses pkg-config >> > >> to detect gnutls or libµhttpd. Confirmed, I get a FTBFS regardless of how I BuildRequires µhttpd: BuildRequires: pkgconfig(libmicrohttpd) # or BuildRequires: libmicrohttpd-devel Except that at configure time I get more complaints than just libidn2: checking for MICROHTTPD... no configure: error: Package requirements (libmicrohttpd) were not met: Package nettle was not found in the pkg-config search path. Perhaps you should add the directory containing `nettle.pc' to the PKG_CONFIG_PATH environment variable Package 'nettle', required by 'gnutls', not found Package 'hogweed', required by 'gnutls', not found Package 'libtasn1', required by 'gnutls', not found Package 'libidn2', required by 'gnutls', not found Package 'p11-kit-1', required by 'gnutls', not found Package 'zlib', required by 'gnutls', not found I will comment on bugzilla too. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Self introduction: David Carlos - Gsoc Student
> The main ideia is to monitor repositories, and when a new package or > a new version of an existent package is released, we download the package > source code, > and run several static analyzers on it. Each monitored distribution will be a > kiskadee > plugin, that implements an interface that we will define. The result of these > analyses, which is parsed using the Fedora Firehose project, will be > stored in a relational database (this idea has been discussed a while ago in > the > devel mailing lists, by the guys in the Static Analysis SIG [2]). With this > database several analyses can be made, and by using several static analyzers > we > want to find heuristics to identify false positives (this is not part of GSoC > though). Having myself recently found a bug in zlib thanks to static analysis I was a bit surprised that such a critical library wouldn't get more "static" eyes on it. > A similar tool exists in the Debian distribution, but it is way > dependent on their infrastructure, and one of our objetives is to keep > kiskadee > simple, and extensible. Naive question, but wouldn't it be interesting to piggyback on release-monitoring.org and fedmsg for the monitoring part? And start static analysis when notified of new upstream releases? Interesting project all the same! Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Self Introduction: Thanos Apostolou
> I've seen many users (especially youtubers) avoiding Fedora because of some > missing packages and because it's not so user friendly. > So, my goal is to contribute to Fedora by creating some simple packages which > I've seen many people ask for. Hello, I will go ahead and make the assumption that missing packages may be related to audio and video, and usually they are not in Fedora for legal reasons (mostly patents?). Have a look at rpmfusion [1] and you will probably find the missing packages there. Dridi [1] https://rpmfusion.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Self Introduction: Thanos Apostolou
> No I'm not talking audio/video packages. There are other packages > missing from Fedora and RPM Fusion, which are available on Ubuntu and on > arch repositories or AUR and they are qualified to included in the > Fedora's repositories. For example I need for my university ns2, nam, > That's cool then. I myself pretend that a piece of software doesn't exist if it's not packaged by Fedora (or RPM Fusion) and that is how I became a package maintainer. Instead of complaining about missing packages, it turned out I had enough skills to do it myself thanks to my previous day job. I have avoided multimedia packages because I don't want to open the legal can of worms, and I don't contribute to RPM Fusion because my spare time is a scarce resource, but I definitely agree with your motivations! Cheers ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Mostly spam on the mips list
Hi there, I'm not sure where it's best to report but today I wanted to probe the progress of Fedora MIPS [1] but since I'm not registered to this list I opted for the web archive. The first non-spam message [2] I could find is from March, everything after that is just noise. I suppose members of the list don't see them in their mail clients, but the archive is a bit encumbered. Looking at the web archives of mailing lists I subscribed to, there doesn't seem to be much noise (I searched a couple classic spammy phrases in each). Maybe the mips list is not monitored? Cheers, Dridi [1] https://fedoraproject.org/wiki/Architectures/MIPS [2] https://lists.fedoraproject.org/archives/list/m...@lists.fedoraproject.org/2017/3/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Mostly spam on the mips list
> I forwarded your post to the list owners... they are at least the first > line of folks to talk to about this. Thanks! I'll try to keep that in mind (no promises=) > If they can't clear things up, then an infrastructure ticket and we can > see what we can do from there. It's gone now. Cheers ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Orphan: mupdf/jbig2dec
On Tue, May 30, 2017 at 1:05 PM, Pavel Zhukov wrote: > Hello. > Due to many CVEs and low quality/security of these packages as well as > Windows oriented upstream I'm going to orphan both jbig2dec and mupdf > packages in Fedora/EPEL. > Sometimes the build doesn't reach stable branch just because it's deprecated > by new build with new CVE. > Feel free to take them. It sounds more like something to retire instead, at least on Fedora... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Duplicate review request for rubygem-vagrant
Hi, I'm on the CC list of the review request for rubygem-vagrant [1] and randomly found a new review request for vagrant [2]. The two packages are AFAICT the same, and the former is stalled due to missing dependencies, the last one being rubygem-log4r [3]. Ironically, the two submitters (CC'ed) met on the rubygem-log4r review request. I think that according to the guidelines vagrant is a duplicate, but I like the name better than rubygem-vagrant (which is used on other distros, and just a matter of renaming). Anyway, from what I can see for rubygem-log4r, it looks like vagrant on fedora is coming soon :) Best Regards, Dridi [1] https://bugzilla.redhat.com/show_bug.cgi?id=905396 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1020456 [3] https://bugzilla.redhat.com/show_bug.cgi?id=905240 -- 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: Duplicate review request for rubygem-vagrant
What prevails between the ruby naming guidelines and the "prior art" rule (other distros package name) in the general naming guidelines ? https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming http://packages.ubuntu.com/raring/vagrant http://packages.debian.org/stable/vagrant My point was more about the fact that two people are working on the same package (one I happen to be waiting for=). Dridi On Wed, Oct 30, 2013 at 10:16 AM, Josef Stribny wrote: > On 10/29/2013 02:13 PM, Dridi Boukelmoune wrote: >> >> Hi, >> >> I'm on the CC list of the review request for rubygem-vagrant [1] and >> randomly found a new review request for vagrant [2]. The two packages >> are AFAICT the same, and the former is stalled due to missing >> dependencies, the last one being rubygem-log4r [3]. >> >> Ironically, the two submitters (CC'ed) met on the rubygem-log4r review >> request. I think that according to the guidelines vagrant is a duplicate, >> but I like the name better than rubygem-vagrant (which is used on other >> distros, and just a matter of renaming). >> >> Anyway, from what I can see for rubygem-log4r, it looks like vagrant >> on fedora is coming soon :) >> >> Best Regards, >> Dridi >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=905396 >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1020456 >> [3] https://bugzilla.redhat.com/show_bug.cgi?id=905240 > > Hi, > > yes, according to guidelines[1], it should be named rubygem-vagrant since > it's convention for all RubyGems. > > Josef > > [1] https://fedoraproject.org/wiki/Packaging:Ruby#Naming_Guidelines > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Duplicate review request for rubygem-vagrant
On Wed, Oct 30, 2013 at 12:04 PM, Josef Stribny wrote: > On 10/30/2013 10:45 AM, Dridi Boukelmoune wrote: >> >> What prevails between the ruby naming guidelines and the "prior art" >> rule (other distros package name) in the general naming guidelines ? >> >> https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming >> http://packages.ubuntu.com/raring/vagrant >> http://packages.debian.org/stable/vagrant >> >> > And how vagrant differs from rhc and other client command line tools that > are distributed as gems and follow this convention? I am wondering if you are being sarcastic. If not, please do not mind this answer. If yes, this was a genuine question. I'm not saying this should be named vagrant, just that I like the name better. It's just that some rules conflict on this matter, and I don't know the answer. I might package ruby stuff in the future though I haven't planned anything so far. As I said in the next sentence, I'm more concerned about the double review. Sincerely, Dridi > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Duplicate review request for rubygem-vagrant
On Wed, Oct 30, 2013 at 1:41 PM, Lukas Zapletal wrote: >> And how vagrant differs from rhc and other client command line tools >> that are distributed as gems and follow this convention? > > What I would like to see in both rhc and vagrant would be: > > Provides: rhc > > respectively > > Provides: vagrant > > It feels natural to me, I have issued "yum install rhc" several times > already. Annoying. Thanks for enlightening me, I understand your previous mail better. And yes I agree with you, ultimately I'm waiting for vagrant and I'd rather install it as "yum install vagrant", regardless of the actual package name. Dridi > -- > Later, > > Lukas "lzap" Zapletal > irc: lzap #theforeman > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Duplicate review request for rubygem-vagrant
On Wed, Oct 30, 2013 at 2:18 PM, Josef Stribny wrote: > > What prevails between the ruby naming guidelines and the "prior art" > rule (other distros package name) in the general naming guidelines ? > > > https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming > http://packages.ubuntu.com/raring/vagrant > http://packages.debian.org/stable/vagrant > > And how vagrant differs from rhc and other client command line tools that are distributed as gems and follow this convention? >>> >>> I am wondering if you are being sarcastic. If not, please do not mind >>> this answer. > > I am indeed very sarcastic person, but this time it's just my genuine > question. > I wrote this as I don't use vagrant, so I don't know. I just want to see > some consistence. Looks like I took Lukas' answer for yours :s >> There is more examples of Ruby packages, such as deltacloud-core, puppet, >> which don't use the rubygem-prefix. The question is if vagrant is >> application or library. >> >> If it is application, then it should be without rubygem- prefix and should >> not install into rubygems directory. If that is library, then it should have >> the rubygem- prefix and install among other rubygems. But the border might >> be fuzzy. > > Many RubyGems are both libs and programs, aren't they? > > > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rpm macro magic help
On Fri, Nov 1, 2013 at 3:59 PM, Sandro Mani wrote:
> Hi,
>
> I'm trying to do some rpm macro magic:
>
> %define do_build() \
> mkdir build_win%{1}_%{2}; \
> (cd build_win%{1}_%{2}; \
> %{mingw%{1}_qmake_%{2}} 'PREFIX=%{mingw%{1}_prefix}' 'TARGET=quazip-%{2}'
> ../libquazip; \
> %{mingw%{1}_make} %{?_smp_mflags}; \
> )\
> %{nil}
According to the guidelines you should use %global instead of %define.
> Problem: when I call i.e. "%do_build 32 qt4", %{mingw%{1}_qmake_%{2}} gets
> expanded to %{mingw32_qmake_qt4} but that macro does then not get expanded
> to /usr/bin/mingw32-qmake-qt4. So basically it ends up trying to call the
> command %{mingw32_qmake_qt4} which does not exist.
>
> So, is there anyway to use macros inside macros and have the resulting thing
> correctly expanded? :)
Have you tried the %{expand:...} macro ? I've seen it in the docs but
never actually used it.
Something like %{expand:%%{mingw%{1}_qmake_%{2}}} I suppose.
Dridi
> Thanks!
> Sandro
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rpm macro magic help
On Fri, Nov 1, 2013 at 6:16 PM, Panu Matilainen
wrote:
> On 11/01/2013 05:12 PM, Sandro Mani wrote:
>>
>>
>> On 01.11.2013 16:09, Sandro Mani wrote:
>>>
>>>
>>> On 01.11.2013 16:07, Dridi Boukelmoune wrote:
>>>>
>>>> On Fri, Nov 1, 2013 at 3:59 PM, Sandro Mani
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm trying to do some rpm macro magic:
>>>>>
>>>>> %define do_build() \
>>>>> mkdir build_win%{1}_%{2}; \
>>>>> (cd build_win%{1}_%{2}; \
>>>>> %{mingw%{1}_qmake_%{2}} 'PREFIX=%{mingw%{1}_prefix}'
>>>>> 'TARGET=quazip-%{2}'
>>>>> ../libquazip; \
>>>>> %{mingw%{1}_make} %{?_smp_mflags}; \
>>>>> )\
>>>>> %{nil}
>>>>
>>>> According to the guidelines you should use %global instead of %define.
>>>>
>>> Oh right, true.
>>>
>> Actually "macro functions" (if that is what one can call them) don't
>> seem to work with %global, only with %define.
>
>
> Yes, because the body of a %global is expanded at the time of definition,
> whereas %define is expanded at time of use. The guideline seems to cause at
> least as much confusion as it was supposed to eliminate, because everybody
> just remembers about the guideline is that "using %define is somehow bad"
> when that's not the case.
That being said, I wish Fedora's rpm documentation were better
referenced at the time I started packaging stuff for my $dayjob. It's
generally much more comprehensive than maximum rpm :)
> - Panu -
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora search
I'm mentioning it just because nobody has so far. Elastic Search[1] which is also lucene-based, was designed from the very beginning to be distributed (in contrast to solr). The product hasn't reached the symbolic 1.0 yet but is production-ready (for instance github[2] uses it). Dridi [1] http://www.elasticsearch.org/ [2] https://github.com/blog/1381-a-whole-new-code-search On Sat, Nov 2, 2013 at 7:02 AM, Frankie Onuonga wrote: > Hi folks, > > I trust all is well. > > I believe this email will spark something so I will cc Kevin in it because > of multiple reasons. > I would like somethings to be clear from the word go. > > I am not too sure where to start with this email. > I have combined emotions of extremely mad and extremely excited at the same > time . > First I would like to thank all those who have been kind enough to offer > their assistance. > I would also like to say thank you to those that have started brainstorming. > I am sure in sometime we will be able to see the fruits of our labor. > > Now in regards to the reason why I am least amused today. I am going to be > straight to the point and clear with this. I do not appreciate a user who is > here to critic and offer no solution. I generally follow open source ethics > but if your job is to come in and critic with a lot of rubbish opinions > (yes I am referring directly to whoever posted that this is not something to > look into and even worse insist on it) then please don't waste your time. > Keep off this thread. > > It does not amuse me to the slightest bit when criticism is given with no > solution. I understand when someone makes a mistake. I also understand when > someone has a valid point. > I do not understand when you give an opinion with a solution being you will > never use the service. > You can not rate something before use. > I would also advice you have a look at the mailing list guidelines so that > you are up to speed. > > > The best of minds are probably here with us, people do not mention who they > work for but trust me they are here. Fine we admit google is miles ahead. I > personally know they took time to get there. > > I also have read their papers and there are open source solutions that have > been mentioned earlier (Apache lucene/sol) that try and mimic this. Seeing > it is for our use , which in my opinion is small I think it is a great > start. > > Third, free and open source is all that is used here. simple. > > I would therefore proceed to mention, if you are not contributing in a > positive way, be kind to the world. We do not have super cow abilities. > > > Kind Regards, > > Onuonga Frankie > > > On Sat, Nov 2, 2013 at 4:57 AM, Alek Paunov wrote: >> >> On 02.11.2013 02:32, Michael Cronenworth wrote: >>> >>> This will be my last mailing on this topic as I will not contribute or >>> use this feature in Fedora, but this reply warranted clarification. >>> >>> On 11/01/2013 06:14 PM, Alek Paunov wrote: Another simple answer: CSE is a low quality search - no facets, no (real) content age restriction. The same is valid also for every other service/application which is solely based on generic web pages crawling. >>> >>> >>> CSE is as full blown as a Google Appliance. More advanced than anything >>> you can write in Perl/Python/Ruby in a month. Site restrictions, keyword >>> restrictions, (real) age restrictions, autocomplete help, synonyms, >>> image search, all of which are provided through a XML API.[1] >>> >> >> Indeed. Don't get me wrong - I like CSE service for what it is good for. >> It seems that I had not been clear enough with my English - Sorry! >> >> Nobody is able to write a good, modern index in a month - lucene/solr, >> xapian, etc, are all evolved in long, long years. Our task is a proper >> deployment of one or combination of them, not inventing a new. >> >> Why e.g. solr instead of CSE or dpsearch (which is opensource, and also >> mentioned in the old tickets)? >> >> Granularity: With CSE/dpsearch the indexed content unit is a crawled and >> automatically processed Web document (I say Web document instead of HTML >> page, because CSE handles many types). Not single BZ comment. Not change >> comment in a spec file. Not Git commit. Or in the reverse direction: Email, >> not thread (because we do not yet have yet archive page displaying the whole >> thread). I.e. there are no concept of document and subdocuments (in which >> most of our content belongs). >> >> Attributes: You can not attach custom scalar/category attributes (the base >> of the faceted search) to the FTS indexed units. >> >> Please correct me if I am wrong about CSE with some of the above. >> >> Fedora has datasources (bugs, wikis, mails, packages, docs, etc,) not just >> sitemaps/pages, and they all talk about same things (common topic >> hierarchies, common tag hierarchies, common authors). They form highly >> interlinked virtual knowledge base. >> >> We should start index the sources in their native struct
Re: bad use of "Dist Tag" in some packages of rawhide
On Sat, Nov 2, 2013 at 9:04 PM, Michael Schwendt wrote:
> On Sat, 02 Nov 2013 19:39:38 +0100, Xose Vazquez Perez wrote:
>
>> Kevin Kofler wrote:
>>
>> > Xose Vazquez Perez wrote:
>> >> BAD use of %{dist} tag(75):
>> >> ==
>> >> afpfs-ng-0.8.1-13.fc21.3.src.rpm 13.fc21.3
>> > [and many similar examples]
>> >
>> > NOTABUG:
>> > https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bumps_for_old_branches
>> > (the next paragraph right after the one you linked to).
>>
>> _rawhide_ is not an *old branch* . And it never was.
>>
>> To have {?dist}.X in rawhide should be impossible.
>>
>> It breaks the laws of thermodynamics!!
>
> It looks ugly, but it's harmless.
>
> It's the package maintainer's responsibility to _reset_ the Release tag in
> Rawhide when upgrading the Version or when touching the package.
>
> With the example of afpfs-ng, look what has happened here:
>
> http://koji.fedoraproject.org/koji/packageinfo?packageID=8023
>
> Two minor release bumps have been kept, have survived several mass-rebuilds,
> because the bump-script does not mess with the Release tag, and even in
> a later update by a packager a week ago, the ".3" has not been dropped.
>
> If anyone feels like adding an option to rpmdev-bumpspec, that one could
> attempt at cleaning up Release tags -- but note that even least-significant
> stuff right of the dist tag could be wanted by the package owner(s), so
> simply dropping it might be wrong. E.g. sometimes it's a patchlevel number,
> with no "pl" prefix.
I took a quick look at the code because I had a related issue, and
found that rpmdev-bumpspec offers a workaround. If the release tag is
too complicated, you can extract the "bumpable" part into a
'baserelease' macro.
This is what I've done [1] for a package to handle the epel '0.'
prefix mentioned in the guidelines.
Dridi
[1] https://bitbucket.org/dridi/fedora_packages/downloads/numatop-el6.spec
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bad use of "Dist Tag" in some packages of rawhide
On Mon, Nov 4, 2013 at 11:29 AM, Michael Schwendt wrote:
> On Mon, 4 Nov 2013 11:09:28 +0100, Dridi Boukelmoune wrote:
>
>> > If anyone feels like adding an option to rpmdev-bumpspec, that one could
>> > attempt at cleaning up Release tags -- but note that even least-significant
>> > stuff right of the dist tag could be wanted by the package owner(s), so
>> > simply dropping it might be wrong. E.g. sometimes it's a patchlevel number,
>> > with no "pl" prefix.
>>
>> I took a quick look at the code because I had a related issue, and
>> found that rpmdev-bumpspec offers a workaround. If the release tag is
>> too complicated, you can extract the "bumpable" part into a
>> 'baserelease' macro.
>
> The linked spec is an example where rpmdev-bumpspec does _not_ know
> what to do because of the %rhel macro in the Release tag. As a result,
> the tag will be bumped at the very right side only.
I've tested it yesterday and the baserelease macro was bumped (not the
actual line with the Release tag). I've done this to fix the previous
%{?rhel:0.}5%{?dist} originally becoming %{?rhel:0.}5%{?dist}.1 (the
".X bumped at the end of the release" behavior as described previously).
>> This is what I've done [1] for a package to handle the epel '0.'
>> prefix mentioned in the guidelines.
>
> Where to find that in the guidelines?
> Such a prefix sounds questionable and is news to me (not being an EPEL dev).
>
>> Dridi
>>
>> [1] https://bitbucket.org/dridi/fedora_packages/downloads/numatop-el6.spec
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bad use of "Dist Tag" in some packages of rawhide
On Mon, Nov 4, 2013 at 12:23 PM, Michael Schwendt wrote:
> On Mon, 4 Nov 2013 11:41:17 +0100, Dridi Boukelmoune wrote:
>
>> > The linked spec is an example where rpmdev-bumpspec does _not_ know
>> > what to do because of the %rhel macro in the Release tag. As a result,
>> > the tag will be bumped at the very right side only.
>>
>> I've tested it yesterday and the baserelease macro was bumped (not the
>> actual line with the Release tag). I've done this to fix the previous
>> %{?rhel:0.}5%{?dist} originally becoming %{?rhel:0.}5%{?dist}.1 (the
>> ".X bumped at the end of the release" behavior as described previously).
>
> On Fedora 20, the script is broken currently. Just believe me. It bumps
> _both_ %baserelease and the Release tag. I think that's a side-effect of
> the attempt at bumping also subpackages with an own Release tag. An older
> version of the script would likely bump only %baserelease.
Now I'm in doubt, I'll double check that this evening. Also, do we
want diverging releases for sub-packages ?
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaing question: need some includes from kernel source
Hi, Is kernel-headers enough ? https://apps.fedoraproject.org/packages/kernel-headers Dridi On Tue, Nov 19, 2013 at 5:47 PM, Chris Adams wrote: > I'm looking at packaing mpt-status (get status info from LSI MPT SAS > RAID controllers) for Fedora and EPEL. However, to build, it needs some > include files from the kernel source, specifically from the > drivers/message/fusion directory. I've built an RPM using an extra > tarball of all the .h files under that directory (using the 3.11.7 > kernel source), and it works (and it also works on an older kernel under > RHEL 6). > > Is this allowed under the packaging guidelines, or is there a better > way? > -- > Chris Adams > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaing question: need some includes from kernel source
Maybe this should be added to an existing package. I forgot to mention that during a review I was told not to have multiple sources. On Tue, Nov 19, 2013 at 5:59 PM, Chris Adams wrote: > Once upon a time, Dridi Boukelmoune said: >> Hi, >> >> Is kernel-headers enough ? >> https://apps.fedoraproject.org/packages/kernel-headers > > I should have mentioned that neither kernel-headers nor kernel-devel has > the necessary headers. > > -- > Chris Adams > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
Hi, For github-hosted upstreams, you can suffix some URLs with '.diff' or '.patch'. I have used it for vcsh [1] (which btw is a tool I'd recommend to anyone who keeps dotfiles in sync on several machines). I did that on a pull request, but you can also do that on a commit (for cherry-picking) [2] and github even allows you to use a shortened sha-1 [3]. Of course this doesn't prevent you from putting the patch files in the package's repository, which seems to be the main issue. But one could write a script to fetch such patches at %prep time. Dridi [1] http://pkgs.fedoraproject.org/cgit/vcsh.git/tree/vcsh.spec [2] https://github.com/RichiH/vcsh/commit/c0d0f80513f26e7b6a485bbd6239191a3fe4be59.diff [3] https://github.com/RichiH/vcsh/commit/c0d0f80.diff On Wed, Nov 20, 2013 at 10:19 AM, Richard W.M. Jones wrote: > On Tue, Nov 19, 2013 at 03:36:54PM -0800, Toshio Kuratomi wrote: >> One note though, I think that in the past one of the discussion points we've >> foundered on is whether we want to be mirroring upstream's git repo or >> (approximately) upstream's releases. I think that's probably where we'd >> need to start discussion. > > From the point of view of patch management, I have a strong view here: > > We should be mirroring upstream's git, if they have one. > > The reason is that it makes it trivial to cherry pick upstream patches > on top of the Fedora branch. > > So I'd arrange it by having a straight mirror of upstream, then have > our own 'fNN-branch' branches which contain the upstream releases > (ideally from upstream tags if they are using git sensibly) + our > cherry picked patches. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Fedora Windows cross-compiler. Compile Windows programs, test, and > build Windows installers. Over 100 libraries supported. > http://fedoraproject.org/wiki/MinGW > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Introduction
On Fri, Nov 22, 2013 at 5:54 PM, Alek Paunov wrote: > On 22.11.2013 14:58, Tako Schotanus wrote: >> >> So I'm completely new to this packaging business, I managed to piece >> together a SPEC file that results in an actually working RPM for our project >> and even Koji seems to accept it, but there's so much information to absorb >> that I'm feeling a bit out of my depth. (Our project being a programming >> language we're dealing with some difficult issues with respect to versioning >> and such, for now I've copied Java's with alternatives and such which might >> or not be a good idea). So if there are some friendly people here that can >> guide me through my first real submission that would be great! > > > I really don't know weather this idea is appropriate [*], but since Ceylon > development is github based anyway and Ceylon is a fresh new development > stack (according to Fedora.next terminology :-) ), what about new github > account: fstack-ceylon (Ceylon related packages for Fedora) containing > something like: > > gh:fstack-ceylon/ceylon/ceylon.spec > gh:fstack-ceylon/ecliplse-ceylon-ide/ecliplse-ceylon-ide.spec > ... etc > > formed in the same shape as the future dist-git repos (being drafts for > them) for all the incoming Ceylon SRPMs. > > You could then clone/commit there your current .spec drafts and receive > issues and pull requests containing packages improvements (e.g. with > pointers to relevant guidelines parts) if it turns out that such style of > community work on the specs seems efficient to the established packagers, > who already offered help. > > I imagine few additional pros: > - Ceylon stack packaging "story" collected under a github account can become > a visible guide for the new stacks Fedora integration (especially for the > potential contributors which are new to the tracking of the bugzilla.rh > packaging bugs and the other Fedora communication channels). > - the whole collection of the specs, when polished could be forked and > tweaked for other RPM based distributions. > > Kind Regards, > Alek > > [*] because 1) it seems that few voices are firmly against Fedora specific > work on github and 2) this would lead to some bug-tracking fragmentation > between github/bugzilla, but I hope the latter is more technical > (synchronization/indexing) issue. The issue tracker is optional on github, that would only leave the pull requests for fragmentation. > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Introduction
On Wed, Nov 27, 2013 at 2:01 PM, Tako Schotanus wrote: > > Sorry for not responding to this before, but lots of other things to do and > this packaging business obviously needs more than just an hour here or there > of reading READMEs. > > I see you want to make things even more difficult for me by giving me > *several* options to choose from, are you *trying* to torture me? ;) > > Is there somewhere I can read up on this way of managing packages? > > And any particular reason why you would suggest making a new gitgub project > for each of the Ceylon SPEC files instead of just putting them together? > Wouldn't that just give us a bunch of 1-file projects otherwise? I would say one spec per upstream repository (or per upstream source tarball...). Of course it makes one-file repositories until you have to patch stuff. In your case, you have binaries in your repositories (jar files in /lib dirs) which goes against the guidelines. You might have to patch the build.properties or build.xml files to "buildrequire" rpms providing those jars in order to comply with the guidelines. I could probably find more issues, but with my limited time I went straight to the obvious :) Dridi PS. congratulations for the 1.0.0 release > Thanks, > -Tako > > > - Original Message - > From: "Alek Paunov" > To: "Development discussions related to Fedora" > > Cc: "Tako Schotanus" > Sent: Friday, November 22, 2013 5:54:53 PM > Subject: Re: Introduction > > On 22.11.2013 14:58, Tako Schotanus wrote: >> So I'm completely new to this packaging business, I managed to piece >> together a SPEC file that results in an actually working RPM for our project >> and even Koji seems to accept it, but there's so much information to absorb >> that I'm feeling a bit out of my depth. (Our project being a programming >> language we're dealing with some difficult issues with respect to versioning >> and such, for now I've copied Java's with alternatives and such which might >> or not be a good idea). So if there are some friendly people here that can >> guide me through my first real submission that would be great! > > I really don't know weather this idea is appropriate [*], but since > Ceylon development is github based anyway and Ceylon is a fresh new > development stack (according to Fedora.next terminology :-) ), what > about new github account: fstack-ceylon (Ceylon related packages for > Fedora) containing something like: > > gh:fstack-ceylon/ceylon/ceylon.spec > gh:fstack-ceylon/ecliplse-ceylon-ide/ecliplse-ceylon-ide.spec > ... etc > > formed in the same shape as the future dist-git repos (being drafts for > them) for all the incoming Ceylon SRPMs. > > You could then clone/commit there your current .spec drafts and receive > issues and pull requests containing packages improvements (e.g. with > pointers to relevant guidelines parts) if it turns out that such style > of community work on the specs seems efficient to the established > packagers, who already offered help. > > I imagine few additional pros: > - Ceylon stack packaging "story" collected under a github account can > become a visible guide for the new stacks Fedora integration (especially > for the potential contributors which are new to the tracking of the > bugzilla.rh packaging bugs and the other Fedora communication channels). > - the whole collection of the specs, when polished could be forked and > tweaked for other RPM based distributions. > > Kind Regards, > Alek > > [*] because 1) it seems that few voices are firmly against Fedora > specific work on github and 2) this would lead to some bug-tracking > fragmentation between github/bugzilla, but I hope the latter is more > technical (synchronization/indexing) issue. > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
review swap: ShellCheck
Hi, Anyone interested in reviewing ShellCheck ? Thanks to the Haskell SIG, it was only a matter of minutes to get a working spec ! https://bugzilla.redhat.com/show_bug.cgi?id=ShellCheck Dridi -- 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: BuildRequires translation/changes during build?!?!?
On Mon, Dec 2, 2013 at 9:14 PM, Richard Shaw wrote: > I'm working on updating the qsstv package for EL6 and ran into a strange > issue. > > Building for x86_64 worked under mock fine, but when I tried the offical > build the ppc64 build couldn't find qmake-qt4. > > Looking through root.log shows that for some reason qt3-devel was installed > rather than qt-devel. Do you have a URL for the build ? > How does this happen? > > Thanks, > Richard > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Help needed with systemd script
Hi, On Sat, Dec 14, 2013 at 12:44 PM, Mattia Verga wrote: > Hello, > I'm trying to give a user access rights to X with xhost command. > I've created a script named '/usr/bin/boincxhost' (chmod 555) like this: > > #!/bin/sh > xhost +SI:localuser:boinc &> /dev/null > exit 0 "exit 0" will hide a non-zero exit status of the previous command. In this case I'm not sure what's happening, but if you're running the command in background, and don't wait for it to complete, you may be facing a race condition. > If I run it from command line it works fine. > But I want to run from a systemd unit at startup. So I added this line to > the unit file: > > ExecStartPre=/usr/bin/boincxhost > > The service starts without errors, but I cannot find the user to have rights > for accessing X. Maybe someone can tell me where I'm wrong in the procedure? > Or is there any other way to give that user access to X? I already tried to > add the user to the 'video' group, but Boinc refuse to see the GPU > available. > Thanks for any hint. > > Mattia > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Help needed with systemd script
On Sat, Dec 14, 2013 at 3:00 PM, Mattia Verga wrote: > Il 14/12/2013 12:55, Dridi Boukelmoune ha scritto: > > Hi, > > On Sat, Dec 14, 2013 at 12:44 PM, Mattia Verga > wrote: > > Hello, > I'm trying to give a user access rights to X with xhost command. > I've created a script named '/usr/bin/boincxhost' (chmod 555) like this: > > #!/bin/sh > xhost +SI:localuser:boinc &> /dev/null > exit 0 > > "exit 0" will hide a non-zero exit status of the previous command. > > In this case I'm not sure what's happening, but if you're running the > command in background, and don't wait for it to complete, you may be > facing a race condition. > > > Ok, I tried to edit the boincxhost script in this way: > > #!/bin/sh > xhost +SI:localuser:boinc > sleep 1 This time it's the sleep command that will override the xhost exit status. Since you're running xhost in foreground, you shoudn't need to sleep at all. In general, if you have several commands in a script, but you want it to abort as soon as one command fail, you can: - run it with sh -e - add set -e in your script This is a one-command script, so you can simply run xhost, and the shell exit status should be xhost's exit status. Btw, do you really need a script ? Can't systemd handle something like: ExecStartPre=/usr/bin/xhost +SI:localuser:boinc > Now if I run the script from console I get: > $ /usr/bin/boincxhost > localuser:boinc being added to access control list > > $ xhost > access control enabled, only authorized clients can connect > SI:localuser:boinc > SI:localuser:marvin > > But if I run it within systemd unit the service is started, but xhost > command "silently" fails: > # systemctl start boinc-client.service > # systemctl status boinc-client.service > boinc-client.service - Berkeley Open Infrastructure Network Computing Client >Loaded: loaded (/usr/lib/systemd/system/boinc-client.service; disabled) >Active: active (running) since sab 2013-12-14 14:52:25 CET; 4s ago > Process: 2843 ExecStopPost=/bin/rm -f /var/lib/boinc/lockfile > (code=exited, status=0/SUCCESS) > Process: 2947 ExecStartPre=/usr/bin/boincxhost (code=exited, > status=0/SUCCESS) > Process: 2944 ExecStartPre=/usr/bin/chown boinc:boinc /var/log/boinc.log > /var/log/boincerr.log (code=exited, status=0/SUCCESS) > Process: 2941 ExecStartPre=/usr/bin/touch /var/log/boinc.log > /var/log/boincerr.log (code=exited, status=0/SUCCESS) > Process: 2938 ExecStartPre=/bin/sleep 1 (code=exited, status=0/SUCCESS) > Main PID: 2952 (boinc) >CGroup: name=systemd:/system/boinc-client.service >├─2952 /bin/bash /usr/bin/boinc --dir /var/lib/boinc >└─2953 /usr/bin/boinc_client --allow_multiple_clients --dir > /var/l... > > dic 14 14:52:23 deneb systemd[1]: Starting Berkeley Open Infrastructure > Net. > dic 14 14:52:24 deneb boincxhost[2947]: xhost: unable to open display "" > dic 14 14:52:25 deneb systemd[1]: Started Berkeley Open Infrastructure > Netw...t. > > # xhost > access control enabled, only authorized clients can connect > SI:localuser:marvin > > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: really stop "really" commits (really!)
On Tue, Dec 17, 2013 at 12:00 PM, Stanislav Ochotnicky wrote: > Quoting Lukas Zapletal (2013-12-17 11:41:29) >> On Mon, Dec 16, 2013 at 03:10:08AM -0700, T.C. Hollingsworth wrote: >> > > I do commit locally >> > > although I probably don't want push the snapshot sources, because I >> > > update >> > > them later, when time comes. >> >> +1 >> >> > This should happen rarely enough that having to use `git commit >> > --no-verify` to bypass it wouldn't be too much trouble? >> >> I am all for these kinds of checks and I appreciate your effort. These >> are all good ideas, but please let's do not do this on the git level. >> This is not appropriate place when we already have a nice layer for this >> kinds of tests: fedpkg. > > I am sure I won't be the only one who doesn't use fedpkg for git manipulation > (commit, push, pull etc). So higher level will not work because by the time I > get to "fedpkg build" it's already too late. I do too use git to switch between branches, commit, push or whatever, but I also wouldn't want such checks at the git level. I find the idea of a "fedpkg check" command appealing, but that would only become really useful if it were *also* part of "fedpkg build". My 2 cents >> Every time a maintainer want to build a package using fedpkg, we can add >> this kind of hooks and verify what is necessary in the similar form you >> recommend (with the option to skip). Let's build a new command fedpkg >> check to do explicit checks as well which can help when fixing those >> mistakes. > > Just out of curiosity: How many times have you run "fedpkg lint"? Zero? Once > to > see what it does? The whole point of the hook was so that you wouldn't forget > to > run appropriate commands. Adding another will make the problem worse, not > better > >> We do not want to get to the state when packages being committed are >> automatically being built in koji (using git hooks). Because what you >> recommend here effectively leads to this "happy" ending - you might >> unintentionally seed this kind of approach. I was already there and >> believe me - this is not what we want to do. :) > > Hold your horses > > -- > Stanislav Ochotnicky > Software Engineer - Developer Experience > > PGP: 7B087241 > Red Hat Inc. http://cz.redhat.com > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
review swap: python-funcparserlib and python-webcolors
Hello, I've recently solved problems *easily* thanks to python (I'm not yet a python person) so I thought I would give it some love and pick a python package from the wish list. I've chosen blockdiag, which I actually might start using (along with its friends seqdiag, actdiag and nwdiag) so first, let's start with blockdiag's dependencies :) https://bugzilla.redhat.com/show_bug.cgi?id=python-webcolors https://bugzilla.redhat.com/show_bug.cgi?id=python-funcparserlib Good news, those packages are already python3-ready, as are blockdiag and its friends. Best Regards, Dridi [1] http://blockdiag.com/en/ -- 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: review swap: python-funcparserlib and python-webcolors
On Tue, Dec 17, 2013 at 2:36 PM, Miro Hrončok wrote: > Út 17. prosinec 2013, 14:13:30 CET, Dridi Boukelmoune napsal: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=python-webcolors >> https://bugzilla.redhat.com/show_bug.cgi?id=python-funcparserlib > > So I take them and you ow me two, ok? Deal ;) > >> Good news, those packages are already python3-ready, as are blockdiag >> and its friends. > > Great :) > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: review swap: python-funcparserlib and python-webcolors
On Tue, Dec 17, 2013 at 2:39 PM, Dridi Boukelmoune wrote: > On Tue, Dec 17, 2013 at 2:36 PM, Miro Hrončok wrote: >> Út 17. prosinec 2013, 14:13:30 CET, Dridi Boukelmoune napsal: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=python-webcolors >>> https://bugzilla.redhat.com/show_bug.cgi?id=python-funcparserlib >> >> So I take them and you ow me two, ok? > > Deal ;) > >> >>> Good news, those packages are already python3-ready, as are blockdiag >>> and its friends. >> >> Great :) Hi, Now that funcparserlib and webcolors are available in rawhide I have submitted blockdiag. https://bugzilla.redhat.com/show_bug.cgi?id=python-blockdiag Best Regards, Dridi >> -- >> Miro Hrončok >> -- >> Phone: +420777974800 >> IRC: mhroncok >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: review swap: python-funcparserlib and python-webcolors
On Sun, Dec 29, 2013 at 5:07 PM, Christopher Meng wrote: > Swap with this one: > > https://bugzilla.redhat.com/show_bug.cgi?id=957347 Thanks for the review, I'll review yours next year ;) > Thanks. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
On Sun, Jan 5, 2014 at 10:27 AM, Lars E. Pettersson wrote:
> On 01/05/2014 09:23 AM, Mattia Verga wrote:
>>
> why did they change remove into erase?
Yum actually offers both erase and remove for the same purpose. I
don't know which is an alias of the other, but rpm uses erase.
From the man page: rpm {-e|--erase}
>
> Lars
> --
> Lars E. Pettersson
> http://www.sm6rpz.se/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
On Mon, Jan 6, 2014 at 3:32 PM, Lars E. Pettersson wrote: > On 01/06/2014 02:06 PM, Vít Ondruch wrote: >> >> Dne 6.1.2014 13:31, Lars E. Pettersson napsal(a): > > ... > >>> What would be the point in removing the running kernel? Is there >>> actually such a use case? >>> >>> Lars >> >> >> Why are you asking? May be you should let your imagination run riot. > > > Why? Isn't that obvious? If there is no use case for removing the running > kernel, well, then there's no reason to let a application do so, isn't it? > > Allowing something that has no, or a minuscules use case, while at the same > time might create huge problems for non technically oriented user, is, in my > opinion, really bad. It has been said before, a "non technically oriented user" will probably never hear about yum. I don't know how GUIs on top of yum behave, but maybe this kind of behavior belongs there. I'm not discarding the possibility of a dnf plugin doing just that, I would probably install and enable it. To me, yum/dnf adds repository/network capabilities to the vanilla rpm. but yum is also opinionated, because for instance it won't let you install several packages with the same name (even though they don't conflict). Unless of course if you configure them as installonly packages. Now about yum's do-not-erase-the-running-kernel opinion, it doesn't bother me that much even though I'd rather not include it. But the fact that it is undocumented behavior according to some does bother me. What happens for instance when you use the --installroot flag ? My 2 cents, Dridi >> Also, I'd like to point out that "yum/dnf remove" by default shows what >> it is going to do and you have to explicitly confirm the action, isn't >> it enough? How much protection do you need? > > > Me? For me personally it dose not matter. The reason I debate this is to > help the unsuspecting ordinary non technical users from debunking their > systems. The user perspective is good to have sometimes, you know. > > > Lars > -- > Lars E. Pettersson > http://www.sm6rpz.se/ > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Package review of the_silver_searcher is stopped.
On Tue, Jan 7, 2014 at 6:06 AM, Kenjiro NAKAYAMA wrote: > Hi, all > (Sorry, Henrik and Dridi, I added you two in cc.) Hi, It's okay, probably the best way to make sure I notice it quickly. > Package review of the_silver_searcher is stopped, and Fedora-review flags is > still "?". > > https://bugzilla.redhat.com/show_bug.cgi?id=1008063 > > Altough It is late for FC 20, it should target to FC 21. I see rawhide, where do you see fc20 ? > Can you please coninue the review? I hope to use it in Fedora. I have other pending open bugs, like one review for Christopher Meng taking time because I'm not familiar with perl packaging. I'm waiting for a sign from Henrik to resume the review, and I hope he is still willing to package it. Not to mention that he needs a sponsor, so I hope he hasn't given up :( I do too want ag in Fedora. Dridi > Kenjiro -- 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: Package review of the_silver_searcher is stopped.
On Tue, Jan 7, 2014 at 8:33 AM, Henrik Hodne wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hey, > > On 01/07/2014 08:22 AM, Dridi Boukelmoune wrote: >> I have other pending open bugs, like one review for Christopher >> Meng taking time because I'm not familiar with perl packaging. I'm >> waiting for a sign from Henrik to resume the review, and I hope he >> is still willing to package it. Not to mention that he needs a >> sponsor, so I hope he hasn't given up :( > > Sorry, I got busy with uni for a while. I'll be coming back from break > this weekend, so I can look into the_silver_searcher again next week. > I'm definitely still up for packaging this, sorry for the delay and > thanks for the reminder. I'll run fedora-review then, and post it on the bz :) > Henrik > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSy625AAoJEBSXlMsKCt+/KEsQAKDQ5FjVWlhCOD/F1DSmD5n9 > 1VbWeBWW4GpVGgUd3dJ4/mu3oun5SlPT1wkdIfqqAUfowhPPlq/sK/h4/4EI8ilu > Ox2Y4/1YwGXdtN4OCG+dodxbhz1RIkn9DyokOrC7w6DmzLJTLvFzeHjtUn3Umil1 > 8p2JgxVMcnlqEca+EStVAu9pFmIFzSfL1DgFeooXfCKdr58qzS081suQjDn5IbsV > oYitfIKL8jcf4p7TwGZs0hNVeutaDf94qbAHR0xWXt8s5yk8Bun3suN+39pphziC > ALb6PH/4iobfDtNnlG+XFGz+52dxJ9MVqDvYzgB0jk4fecVF6YmJMe3SpghBh3la > Ira0UlHS8s4v58B4nenGa0eeh8sbt5S1Lo66V4DtjBoX9BEqpqBh/zYVlwu7ID0S > L1BKZIAsUJ1OGhUzIjOuJDnVMNbhvpPq7nys8Gesv0XtSe6LihSoHvYF3V7FMQbX > 5Fl62AqVBzTl9AMd71KQ7GfiPl3adCPq8qThD1btnQm1juIjFZcCuvTSLnCuuw/d > 6BtIBW7/arPDoIgsTwxEr46h+YvtpapJpT3DjS6vWQl/FtHVytyT4uRC3XWdfORz > +6CF4qS0TSxKQZCvxItg0Jz+W1Spfpt+VtyGf/K14Sl+Vc+17Kjcnt4mB9Rv1kyb > /U1tUYlTqp8FFPcSkahO > =8g0X > -END PGP SIGNATURE- -- 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 versus yum
On Tue, Jan 7, 2014 at 9:53 AM, Frank Murphy wrote: > On Tue, 07 Jan 2014 09:48:16 +0100 > Vít Ondruch wrote: > >> Dne 6.1.2014 23:26, Chris Murphy napsal(a): >> > Since "* remove kernel" appears to be inspecific, removing all >> > kernels isn't what I'd expect. It's not how mv or cp or anything >> > else would work. >> > >> >> So why not turn this around. In case somebody is doing "dnf remove >> kernel" and dnf will figures out that there is more packages, then it >> should fail and ask user to be more specific. That way dnf could >> behave consistently and user would have to go with "dnf remove >> kernel*" to explicitly specify, that (s)he wants to remove all >> kernels. >> >> Vít > > dnf remove kernel --all I assume you're suggestion that `dnf remove kernel` should only remove the latest kernel. It wouldn't change the fact that removing only the latest installonly package could most likely remove the running kernel, which is the main issue here. > > ___ > Regards, > Frank > www.frankly3d.com > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
On Tue, Jan 7, 2014 at 10:29 AM, Frank Murphy wrote: > On Tue, 7 Jan 2014 10:16:16 +0100 > Dridi Boukelmoune wrote: > >> > dnf remove kernel --all >> >> I assume you're suggestion that `dnf remove kernel` should only remove >> the latest kernel. > > How do you make that out. > Have you ever used "yum remove kernel" > > "dnf remove kernel --all" > to remove "all" I'm sorry I don't understand your answer. Dridi > ___ > Regards, > Frank > www.frankly3d.com > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
On Tue, Jan 7, 2014 at 11:06 AM, Frank Murphy wrote: > On Tue, 7 Jan 2014 10:52:52 +0100 > Dridi Boukelmoune wrote: > >> I'm sorry I don't understand your answer. >> >> Dridi >> >> > > I can't make it any simpler. You could maybe explain what you meant in the message I've answered to. You've just said: dnf remove kernel --all I'm sorry for misunderstanding a command that didn't come with a single sentence. Dridi > > ___ > Regards, > Frank > www.frankly3d.com > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
On Tue, Jan 7, 2014 at 11:28 AM, Frank Murphy wrote: > On Tue, 7 Jan 2014 11:12:39 +0100 > Dridi Boukelmoune wrote: > >> I'm sorry for misunderstanding a command that didn't come with a >> single sentence. >> > >>"dnf remove kernel --all" >>to remove "all" > > What's to misunderstand Maybe this time you'll answer my question. What did you mean here ? https://lists.fedoraproject.org/pipermail/devel/2014-January/193568.html > ___ > Regards, > Frank > www.frankly3d.com > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
On Fri, Jan 10, 2014 at 1:04 AM, Kevin Kofler wrote: > Bill Nottingham wrote: > >> Matthew Miller (mat...@fedoraproject.org) said: >>> I'm a little lost in the thread, but do you mean that yum's protected >>> packages functionality is undocumented? If that is what you mean, check >>> the man page. It says: >>> >>> protected_packages This is a list of packages that yum should >>> never completely remove. They are protected via Obsoletes as >>> well as user/plugin removals. >>> >>> The default is: yum glob:/etc/yum/protected.d/*.conf So any >>> packages which should be protected can do so by including a file >>> in /etc/yum/protected.d with their package name in it. >>> >>> Also if this configuration is set to anything, then yum will >>> protect the package corresponding to the running version of the >>> kernel. >> >> While documented, I do find this last bit of behavior extremely odd and >> non-intuitive. (And hardcoded, no less.) > > There should just be a separate protect_running_kernel boolean option, which > would default to the above odd behavior for compatibility if not set (but > explicitly setting it to either 1 or 0 would override that either way). Can't the kernel package itself do that ? I'm thinking about the %preun section (maybe %pretrans ?) where the package would know it's being removed, and could find out whether it's the running kernel. One might also want to build a distribution on top of yum/rpm but choose a different name for the kernel package like "linux" or "linux-kernel". Dridi > Kevin Kofler > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
On Fri, Jan 10, 2014 at 2:50 PM, Dridi Boukelmoune wrote: > On Fri, Jan 10, 2014 at 1:04 AM, Kevin Kofler wrote: >> Bill Nottingham wrote: >> >>> Matthew Miller (mat...@fedoraproject.org) said: >>>> I'm a little lost in the thread, but do you mean that yum's protected >>>> packages functionality is undocumented? If that is what you mean, check >>>> the man page. It says: >>>> >>>> protected_packages This is a list of packages that yum should >>>> never completely remove. They are protected via Obsoletes as >>>> well as user/plugin removals. >>>> >>>> The default is: yum glob:/etc/yum/protected.d/*.conf So any >>>> packages which should be protected can do so by including a file >>>> in /etc/yum/protected.d with their package name in it. >>>> >>>> Also if this configuration is set to anything, then yum will >>>> protect the package corresponding to the running version of the >>>> kernel. >>> >>> While documented, I do find this last bit of behavior extremely odd and >>> non-intuitive. (And hardcoded, no less.) >> >> There should just be a separate protect_running_kernel boolean option, which >> would default to the above odd behavior for compatibility if not set (but >> explicitly setting it to either 1 or 0 would override that either way). > > Can't the kernel package itself do that ? > > I'm thinking about the %preun section (maybe %pretrans ?) where the > package would know it's being removed, and could find out whether it's > the running kernel. > > One might also want to build a distribution on top of yum/rpm but > choose a different name for the kernel package like "linux" or > "linux-kernel". This reminds me that yum is built on top of rpm, and rpm doesn't mean linux. I remember my first time on AIX, and the surprising (yet unpleasant) fact that I had to use (a very old version of) rpm. From rpm.org: > RPM is a core component of many Linux distributions, such as Red Hat > Enterprise Linux, the Fedora Project, SUSE Linux Enterprise, openSUSE, > CentOS, Meego, Mageia and many others. > > It is also used on many other operating systems as well From rpm5.org: > But RPM is also used for software packaging on many other Unix operating > systems like FreeBSD, Sun OpenSolaris, IBM AIX and Apple Mac OS X > through the cross-platform Unix software distribution OpenPKG. I actually remember a comparison matrix of OpenSolaris forks, some of them chose /rpm5?/ for package management, but I can't find a link. I do understand why people would want such features built-in, but it seems a bit short-sighted. And by short-sighted I don't mean a bad idea, I mean restricted to Fedora/RHEL and very close distributions. I don't know yum's goals, but the man page yum(8) and the faq don''t seem to mention any tight coupling to rhel-like linux distribution. Again, I'm not saying this would be a bad thing. AFAICT yum is tied *by essence* to rhel, but I'm also wondering what upstream thinks about portability, because the whole kernel issue is a portability no-no. > Dridi > >> Kevin Kofler >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GIT development branches for packagers?
On Wed, Jan 15, 2014 at 2:16 PM, Vít Ondruch wrote: > Dne 14.1.2014 21:41, Andrew Lutomirski napsal(a): >> I have some trivial cleanups I want to make to a package a maintain. >> These cleanups are trivial enough that I don't think they're worth a >> new build. Should I commit them to the master branch? If so, I can >> imagine a couple of issues: >> >> - A provenpackager could kick off a rebuild for whatever reason (e.g. >> dependency soname bump). That will (I think) inadvertently include my >> changes. >> - I need to think about whether to add a changelog entry or not. If >> not, those changes might be included silently. If yes, then I need to >> think about what to do about the revision number. >> >> The normal GIT approach would be to develop on another branch and to >> merge when I want to build a new revision (the Fedora equivalent of >> tagging a new release). Should Fedora provide branches like >> master-devel, f20-devel, etc that store pending changes? >> >> Am I missing something really obvious here? >> >> --Andy > > Actually I'd really love to see some possibility for private branches. > Now, it is possible to push whatever branch (take it literally) you have > in your local git repo into dist-git, but there is no way how to delete > it by myself. > > For example, I am using branches to keep my .spec file aligned with > upstream development and I'd like to share it with other maintainers. > But this .spec file should never build in Rawhide unless it is approved > by FESCo. > > Could you please add support for private branches? I.e. the branch which > starts by private- prefix could be pushed and deleted as well, non ff > commit should be allowed. Actually, better would be if only master, fxx > and elx are protected and others are unrestricted, but I am probably > asking too much. For private branches I'd rather see something along fas/branch. With the '/' separator you can glob refspecs, and using your fas as a prefix could enable automatic acls with less pain on the infrastructure side (eg. allow anyone to manage and own private branches at will). Dridi > Vít > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review swap or Sponser request: the_silver_searcher
On Sun, Jan 26, 2014 at 11:39 AM, Matthias Runge wrote: > On 01/26/2014 09:09 AM, Kenjiro Nakayama wrote: >> Hi, List >> >> Can anyone swap review or take it as sponsor? >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1008063 >> > > Kenjiro, > > in order to get a package approved, you must be the reporter of a review > request. When looking for a sponsor, it definitely helps, if you review > other packages as well. Hi Kenjiro, I would have happily reviewed the package but I've been swamped for a few weeks, and I didn't know how to handle the takeover. Also as Christopher mentioned, I'm not a sponsor, so I can't approve the submission (I'm aware of that). I've stepped down and removed the review flag because I don't know whether I can review it and let a sponsor then approve it. Now once a new review request is submitted, and if I can review it and let the sponsor handle the rest, you can count on me. Best Regards, Dridi > Matthias > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Large number of packages to be orphaned on Feb 26
On Fri, Feb 19, 2016 at 8:15 PM, Fabio Alessandro Locati wrote: > If Christopher will not respond, I can take care of: > snip > - rpms/tiptop -- Performance monitoring tool based on hardware counters Hi Fabio, I'm already a co-maintainer on this one, I can take tiptop. Cheers, Dridi -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
