Re: DNF: "There are following alternatives to this package"
On Thu, 2018-09-13 at 18:17 +0200, Tomas Orsava wrote:
> We'd like to propose a new functionality for dnf: When a user tries
> to install a package XYZ and dnf doesn't find it, dnf would recommend
> them alternative packages. These offered packages would advertise
> that they are an alternative for XYZ using a specially formatted
> Provides tag.
>
> For example, packages `python2-requests` and `python3-requests`
> would both have the following tag:
>
> Provides: alternative-for(python-requests) = %{version}-
> %{release}
>
> (Possibly via the already existing and widespread %python_provide
> macro in the Python case.)
>
> And when the user would try to install `python-requests`, dnf would
> look for packages with the relevant Provides tag and display them:
>
> # dnf install python-requests
>* There are following alternatives to this package:
> python2-requests python3-requests
> No match for argument: python-requests
> Error: Unable to find a match
>
> This would be very similar to an already existing functionality that
> searches for lowercase package names:
>
> # dnf install python3-REQUESTS
>* Maybe you meant: python3-requests
> No match for argument: python3-REQUESTS
> Error: Unable to find a match
>
> (That functionality is broken in some versions—RHBZ#1628514—so you
> might not see this result at the moment.)
>
> What are your thoughts?
It's neat, but it doesn't help catch typos, which seems like the most
probably case where I'd want such a feature.
How about instead of a scheme based on provides, just quickly check if
a package has a "similar" name?
Basically extend the existing check for lowercase you mention.
$ git stats
git: 'stats' is not a git command. See 'git --help'.
The most similar command is
status
--
Mathieu
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] gcc/gcc-c++ removal from buildroot and more
Hi, On Tue, 2018-07-10 at 12:14 +0200, Vít Ondruch wrote: > One question though. I see that this works in Koji, but trying to > test this locally it does not work. > 1) $ mock -r fedora-rawhide-x86_64 rubygem-abrt-0.3.0-3.fc29.src.rpm > --enablerepo=local > This still installs gcc. > 2) $ mock -r fedora-rawhide-x86_64 rubygem-abrt-0.3.0-3.fc29.src.rpm > --disablerepo=* --enablerepo=local > This fails: > ~~~ > Warning: Module or Group 'buildsys-build' does not exist. > Error: Nothing to do. > ~~~ > Trying to get the latest comps from local repository: > ~~~ > https://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/repoda > ta/db824c6dd6664943bcec0a8fcd3bda7fc855e5a787623c0da6d49deb79438fc7- > comps.xml > ~~~ > This has "build" group which references gcc/gcc-c++ and does not > reference any buildsys-build group. So where is this file coming > from? Why does it differ from regular Fedora repos? The groups in Koji are defined differently from the groups in the Fedora repos. In the repos, you can find them defined in the comps.xml file, for example: http://dl.fedoraproject.org/pub/fedora/linux/releases/28/Everything/x86 _64/os/repodata/b140b2b55e06b7ba6c765d27dd9dbae905745e788a97a390be8b829 80b8c282e-comps-Everything.x86_64.xml This contains a `buildsys-build` group, which mock installs when creating a chroot. In Koji, the groups can be seen with the command: $ koji list-groups f29-build [… snip …] build [f29] bash: None, mandatory [f29] bzip2: None, mandatory [f29] coreutils: None, mandatory [f29] cpio: None, mandatory [f29] diffutils: None, mandatory [f29] fedora-release: None, mandatory [f29] findutils: None, mandatory [f29] gawk: None, mandatory [f29] grep: None, mandatory [f29] gzip: None, mandatory [f29] info: None, mandatory [f29] make: None, mandatory [f29] patch: None, mandatory [f29] redhat-rpm-config: None, mandatory [f29] rpm-build: None, mandatory [f29] sed: None, mandatory [f29] shadow-utils: None, mandatory [f29] tar: None, mandatory [f29] unzip: None, mandatory [f29] util-linux: None, mandatory [f29] which: None, mandatory [f29] xz: None, mandatory [f29] [… snip …] srpm-build [f29] bash: None, mandatory [f29] fedora-release: None, mandatory [f29] fedpkg-minimal: None, mandatory [f29] gnupg2: None, mandatory [f29] redhat-rpm-config: None, mandatory [f29] rpm-build: None, mandatory [f29] shadow-utils: None, mandatory [f29] The `srpm-build` group is what gets installed in the chroot to build the SRPM (see the buildSRPMFromSCM subtask in any build task) and the `build` group is what gets installed when building binary RPMs (see the buildArch subtasks in any build task). I do not know **why** we have this difference between Koji and the main repos, I just know that we do have it. This change needs to be reflected in Comps, so that Mock installs the same thing in its buildroots as Koji. -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TB4YLBIHDCNORB4MHSAUVT2HXXN4MNAQ/
Re: How should I coordinate the package updates with you guys?
On Fri, 2018-04-13 at 15:41 -0500, po...@pouar.net wrote:
> Not sure how to interpret the example email `packagename-owner@alias`
> . Would that be like `brotli-po...@fedoraproject.org` or
> `po...@fedoraproject.org` or something else? Is `fedoraproject.org`
> the right domain for `alias`?
It's ${srpmname}-ow...@fedoraproject.org, so in your case:
brotli-ow...@fedoraproject.org
--
Mathieu
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Gating packages in Rawhide
On Fri, 2018-03-09 at 10:38 +0100, Pierre-Yves Chibon wrote: > On Fri, Mar 09, 2018 at 10:12:37AM +0100, Mathieu Bridon wrote: > > We could take a hint from how we make software upstream these days: > > > > 1. submit a pull request for the package in src.fp.o on the master > >branch > > 2. a CI automatically builds this package in Koji > > 3. merge the pull request into master > > 4. the build (from step 2) is tagged for Rawhide, without a rebuild > > > > Gating is achieved by preventing merges if the build/tests fail. > > This has been discussed but requires a way for koji to "promote" > scratch builds > to real builds and this isn't a small task. > Long term, I do think this is a good idea anyway yes. It doesn't have to be scratch builds, it could be real builds in a side tag. -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Gating packages in Rawhide
On Fri, 2018-03-09 at 10:06 +0100, Pierre-Yves Chibon wrote: > On Thu, Mar 08, 2018 at 08:26:30PM -0800, Kevin Fenzi wrote: > > On 03/08/2018 07:53 PM, Kevin Kofler wrote: > > > Randy Barlow wrote: > > > > It may be possible to automate the process a bit to make it > > > > less heavy > > > > for developers, though there is some complication for multi- > > > > package > > > > updates > > > > > > Some automation would help, sure. But if we are going to do > > > things > > > automatically, why bother with Bodhi at all? > > > > Well, we don't currently have another tool to show results and > > allow > > waving of them. We could come up with another app and have yet a > > different place and workflow from regular releases, but why not > > stick to > > the same workflow and avoid making yet another app. > > > > > > We are already building into a pending tag for the autosigning, > > > from which > > > the packages are moved into the final tag when they are signed. > > > The same > > > process should work for autotesting. Just add it before or after > > > the > > > autosigning in the pipeline, possibly with another intermediate > > > tag. > > > > > > I think that Bodhi is really the wrong tool for the job here. > > > What you are > > > trying to hit with your shiny hammer may look like a nail to you, > > > but it is > > > really a screw. ;-) > > > > I don't think thats the case here, it's more than we don't want to > > build > > another different tool for something that could work with the > > hammer we > > have. > > > > To be fair, there was a suggestion that we show results in > > pagure/src.fedoraproject.org, but to me, that definitely sounds > > like the > > wrong place for such things. We want tests tied to a specific > > update, > > not the entire package as a whole. (Even thought we could fudge > > this by > > having git tags or something to tie results to). > > For regular Fedora releases I definitely agree with you, but for > rawhide where > the only time we bundle package together would be via side-tags, I > think > reporting test results to src.fp.o would be a valid approach. We could take a hint from how we make software upstream these days: 1. submit a pull request for the package in src.fp.o on the master branch 2. a CI automatically builds this package in Koji 3. merge the pull request into master 4. the build (from step 2) is tagged for Rawhide, without a rebuild Gating is achieved by preventing merges if the build/tests fail. -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Wyland is a disaster
On Tue, 2018-02-06 at 08:53 -0800, Howard Howell wrote: > On Mon, 2018-02-05 at 16:39 -0500, Przemek Klosowski wrote: > > On 02/05/2018 01:35 PM, Howard Howell wrote: > > > My eyes hurt > > > after a few hours trying to find the smaller and darker default > > > cursors. > > > > Do you know that you can simply increase the size of the cursors? > > > > dconf write /org/gnome/desktop/interface/cursor-size 48 > > > > I swear I saw it in one of GNOME GUI tools but I can't find it now > > (doesn't seem to be in Settings or Gnome-tweaks) > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > You are on my hero's list. Somebody figure out how to make this part > of gnome-tweak-tool, PLEASE, or on the accessibility menu. In GNOME Settings 3.26.2, go to "Universal Access" then change the "Cursor Size" option. -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: What to I have to do....
On Fri, 2017-12-08 at 12:01 -0500, Steve Dickson wrote: > On 12/08/2017 11:46 AM, Mathieu Bridon wrote: > > You're blowing this way out of proportion, as if this was a > > catastrophe. History shows that it isn't. > > Maybe I am... Would not be the first time! ;-) > > In last couple of months there were a couple of changes > that were non-critical so I'm getting the feeling > people are getting a bit embolden... which is worrisome. > > Then on the other hand I get these pull-requests that > work so well! > > So I just don't understand why for non-massive changes > why is it not required to go through the pull-request > process? This wasn't a trivial change. It certainly was trivial for each package it got applied to, but it got applied to quite a few packages. That's essentially a similar change to mass-rebuilds, just at a smaller scale. It was also announced properly on this list, enough time in advance, so it shouldn't have taken you by surprise. If you really want to insist on the maintainers's responsibilities, start by reading announcements on this list. -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: What to I have to do....
On Fri, 2017-12-08 at 11:40 -0500, Steve Dickson wrote: > > On 12/08/2017 11:12 AM, Zbigniew Jędrzejewski-Szmek wrote: > > Well, I'd say this works great. There's maybe a hundred or two > > hundred proven packagers and somehow none of them decide to mess up > > the kernel any day. In fact, the commits which caused this thread > > are _correct_: > > so far I haven't heard one word to the contrary. I don't see any > > point in discussing hypotheticals. > > You are telling me there hundreds of people that have complete > control over all the packages in fedora with no boundaries??? > They can do anything they what??? Wow... And it's working just fine, because overall people understand their responsibilities and don't abuse their powers. If someone ever does go too far, their probvenpackagers permissions can be revoked and the bad changes they made can be reverted. You're blowing this way out of proportion, as if this was a catastrophe. History shows that it isn't. -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Call for testing - Firefox CSD/titlebar
On Fri, 2017-09-15 at 18:03 +0200, Vít Ondruch wrote: > * Why are there the minimize/maximize buttons? They should not be > there in Gnome. I filed this one this morning: https://bugzilla.redhat.com/show_bug.cgi?id=1491981 -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
On Fri, 2017-09-01 at 15:00 -0500, Ian Pilcher wrote: > On 09/01/2017 02:21 PM, Igor Gnatenko wrote: > > This is true and we have plans to implement this, but problem is > > that > > we don't know how to represent data. When it is about installing > > some > > packages -- it's more or less easy to show, but when upgrades / > > downgrades are involved it becomes way more complicated. > > > > If you have some actual suggestions -- feel free to contact me off > > list > > or post them here. ☺ > > I won't claim to be a huge fan of the way that yum insisted on > spewing detailed dependency information, but it did provide the > information require to answer those "Why does Inkscape require > mdadm?" type questions. The old repoquery had a --tree-requires option which was really great for this. (along with a few other --tree-* options) -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Two more concrete ideas for what a once-yearly+update schedule would look like
On Mon, 2017-07-31 at 22:51 -0400, Randy Barlow wrote: > On Mon, 2017-07-31 at 22:13 -0400, Ben Rosser wrote: > > 2. If we do implement this, could we consider not batching new > > package > > updates in addition to security and "urgent" updates? New package > > updates wouldn't get downloaded onto users systems upon running > > "dnf > > upgrade", so the update process would still *feel* batched from an > > end-user point of view. But we would simultaneously be able to > > deliver > > new software quickly to users, or at least as quickly as we do > > today. > > (I find that people rarely test new package updates, or at least > > rarely test them and give karma, which means that a newpackage > > request > > generally sits the full 7 or 14 days in bodhi-- so I don't think we > > should add up to 7 days to that timetable). > > That's a good suggestion that I hadn't though about. Sure, I think > that's a good idea - care to propose it on the pull request yourself > since it was your idea? This is the line where an "or self.type is > newpackage" would go: > > https://github.com/fedora-infra/bodhi/pull/1678/files#diff-6406e7faaf > 25263056c68009517cf66dR2376 If a new package needs an updated library from another package, then the update in Bodhi would contain both a new package and an update. Should that still go directly to request:stable? Or does the (non- urgent) update make it go to request:batched? -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Finalizing Fedora's Switch to Python 3
On Mon, 2017-07-31 at 00:02 +1000, Nick Coghlan wrote: > On 30 July 2017 at 07:57, Björn Persson wrote: > > Mathieu Bridon wrote: > > > To be honest, given how much energy is spent on this migration > > > for a very low gain, it makes me feel like having an unversioned > > > "python" (whether as package or executable names) was a mistake > > > we should let disappear with Python 2. > > > > I agree. > > > > From an emotional point of view I fully understand the Python > > folks' desire to have "Python" mean Python 3, and that's fine in > > marketing contexts such as websites. > > While I'm a CPython core dev in addition to being a RHEL developer, > it's mainly the latter role that leads me to consider the status quo > in Fedora as being rather problematic :) > > > But filenames and package names are technical > > identifiers. They must be chosen so that they'll fulfil their > > functions, and with consideration for forward and backward > > compatibility. > > Right. Unfortunately, the folks saying "just use /usr/bin/python3 in > your shebang lines" are choosing to ignore systems that don't have, > and *aren't going to get* a Python 3 installation. Even if Red Hat > were to start making a native Python 3 stack available, there would > still be an awful lot of EL6 and EL7 systems around where that stack > isn't going to be installed. Sure, but nobody is telling everybody to use /usr/bin/python3 in their shebang line. I started this subthread saying everybody should just use the versioned executable in their shebang line. Whether that's Python 2 or 3 depends on what's available on their system and what they are targetting. > So that's effectively a hard design constraint for me: folks > targeting EL6 and EL7 *are* going to have to use "/usr/bin/python" in > their shebang lines (since they can't even assume "/usr/bin/python2" > will be present, Wait, what? I see /usr/bin/python2 in the EL7 spec file: https://git.centos.org/blob/rpms!python.git/c7/SPECS!python.spec#L2041 I'm pretty sure I had /usr/bin/python2 back in the days when I was using EL6. (but I have no way to check that now) > let alone "/usr/bin/python3"), so I have to assume that "just tell > Red Hat's customers to change all their Python shebang lines to > require Python 3" isn't one of the design options I have available to > me. And again, nobody in this subthread suggested moving things to Python 3. > That means the only degrees of freedom I/we potentially have are > related to what "/usr/bin/python" means in Fedora. The status quo is > that by default such scripts simply break, and if you want them to > work, you have to install the full Python 2.7 stack. Which, again, is what happens for other shebang lines like /usr/bin/zsh or /usr/bin/ruby. Having to install the stack needed by your custom-built tools seem like a perfectly normal thing to me. > If you want to do anything else, you have to resort to creating > symlinks manually, and as soon as you do, your system is in an > unsupported configuration, so if it breaks, any bugs you file are > just going to be closed as "not a bug". > > Accordingly, my proposal is that we support *3* admin selectable > configurations That seems like a recipe for confusion. How does one know what /usr/bin/python actually is if it can change from one machine to another? > > Providing an unversioned "python" serves only to lure incautious > > programmers into using it where they should use a versioned name. > > My aim is for folks to start thinking of a "/usr/bin/python" shebang > as being akin to writing "/bin/sh" instead of "/bin/bash": as the > author of the script, by deciding not to explicitly qualify your > shebang line you're saying "I'm not writing in either Python 2 *or* > Python 3, I'm writing in the hybrid subset of both of them". There > aren't many good reasons for a script in a distro package to do that > (they should just depend on the stack they want), but there are > plenty of good reasons for multi-distro scripts to be written that > way. > > As time goes by, I'd expect the meaning of the unqualified variant to > shift slightly such that "/usr/bin/python" is taken to mean "written > in the oldest Python dialect that is still actively supported by > upstream and/or commercial vendors (or potentially even older than > that)" while "/usr/bin/python3" retains its current meaning of "run > in the default Python 3 stack" (with the two links thus b
Re: Finalizing Fedora's Switch to Python 3
On Fri, 2017-07-28 at 21:06 +0200, Till Maas wrote: > On Fri, Jul 28, 2017 at 10:29:12PM +1000, Nick Coghlan wrote: > > > It's only /usr/bin/python itself that still presents an unsolved > > problem, since the status quo (not providing it at all) is even > > more user hostile than pointing it at a modern version of Python 3 > > that > > Why is not providing /usr/bin/python more use hostile? Why is it > better for any script to use /usr/bin/python instead of > /usr/bin/python3? Exactly. By default, any script using `#!/usr/bin/zsh` won't work on Fedora, until the admin installs zsh. We could very well consider that /usr/bin/python remains python2, and not have it installed by default. To be honest, given how much energy is spent on this migration for a very low gain, it makes me feel like having an unversioned "python" (whether as package or executable names) was a mistake we should let disappear with Python 2. If everything is a versioned pythonX in the future, moving to a hypothetical Python 4 would only imply building new python4-* packages and changing the (Build)Requires, no gymnastic with unversioned things. -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Graphical Applications as Flatpaks
On Tue, 2017-07-18 at 15:06 +0100, Tom Hughes wrote: > Nobody wants to have to resetup their desktop every day I do. I actually turn off my computer when I'm not using it, and start it again in the morning before I start working. -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Graphical Applications as Flatpaks
On Tue, 2017-07-18 at 13:23 +0200, Dominik 'Rathann' Mierzejewski wrote: > By the way, I can't figure out how to look inside a Flatpak and > review its contents. Could someone provide some pointers? On the repo all you have is an object store (much like Git's .git/objects/ folder), but if you install the app you will also get a checkout: $ ls ~/.local/share/flatpak/app/org.gnome.Calendar/current/active/files/ bin lib manifest.json share (that's because I installed the app with --user, if you install it system-wide then it's under /var/lib/flatpak/app/...) The manifest.json file is a recipe for how the app was built (like a spec file), which helps reproducing builds. The contents of that files/ directory are what gets mounted as /app/ in the sandbox. -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Xulrunner - intent to remove from Fedora 24
On Tue, 2017-06-27 at 10:23 +0100, Tom Hughes wrote: > On 27/06/17 10:11, Dominik 'Rathann' Mierzejewski wrote: > > On Tuesday, 27 June 2017 at 06:40, Truong Anh Tuan wrote: > > > I have just got updates from upstream developers. A new version > > > of pencil has been released [1]. I uses Electron, instead of > > > XULrunner. > > > > > > I am planning to update the package to keep pencil on the next > > > Fedora releases. However, as I have checked on the wiki, Electron > > > package [2] has not been officially put into Fedora repo. > > > What should I do now? Any suggestions? > > > > You can ask Brenton to submit the electron package for review and > > maintain it in Fedora or you can do it yourself. > > I'm guessing you haven't seen the dependency tree for electron if > you think it's that easy ;-) > > To be honest I'm struggling to even make sense of what exactly > constitutes "electron" as such because the npm module of that name > appears to basically be an installer for a prebuilt node and chrome! > > I believe that behind that there are then a zillion other electron-* > npm modules no doubt each with their own crazy dependency hell. And it is likely each app will require different versions of all those modules, those versions being incompatible with each others. At that point, bundling with something like Flatpak becomes more interesting than packaging all those separately. -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F25 Self Contained Change: IBus Emoji Typing
On Tue, 2017-05-09 at 17:17 +0900, Takao Fujiwara wrote: > As I explained in Fedora 25, now the emoji typing is available in > IBus panel menu. > ibus-1.5.15-8.fc26 is now available in koji or copr. > I moved the emoji function in IBusEngineSimple to a panel component. > The UI is designed to work as an extended IBus lookup window which > can commit an emoji without mouse using Space, Enter and Arrow keys > and expected to be useful for both CLI and GUI users. > The shortcut key Ctrl-Shift-e is customizable with ibus-setup > utility. > If this is comfortable for you, I'd like to implement the similar UI > for gnome-shell. Ctrl+shift+e might already be used in applications. (for example in Gimp it fits the image to the window, in the Firefox Tab Groups extension itopens the group management page, etc...) I think for GNOME Shell the shortcuts are usually with the super key, (e.g super+space to switch input sources), to avoid clashing with application shortcuts. -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Emails about new packages
On Thu, 2017-02-16 at 22:48 +, Jeremy Cline wrote: > On 02/16/2017 09:47 PM, Steve Grubb wrote: > > The 3.2.1 version is in koji, why was this email sent to bother me? > > At some time in the past, I tracked it down and found a way to > > "turn this off". But guess what? Now I get 2 emails. The first is > > above, and the second one is this: > > > > the-new-hotness saw an update for suricata, but pkgdb says the > > maintainers are not interested in bugs being filed > > https://release-monitoring.org/project/10925/ > > > > Why? This is really passive aggressive. How do I unsubscribe from > > this unwanted release monitoring service? > > the-new-hotness subscribes to the messages published by > release-monitoring.org and files a Bugzilla bug on the package. Many > packagers find this helpful, but (as you've found) it's possible to > turn off. If you do this, the-new-hotness publishes a message saying > it saw the message from release-monitoring.org, but isn't acting on > it. > > Fedora has a notification system that also subscribes to all these > messages and sends emails or irc messages to you when certain > messages are received. That's not helpful, though. The email basically says "Something happened, but you asked not to be notified about it, so don't worry I won't tell you". Why even send that email in the first place? Anyone who opted out of the release monitoring notifications (note: I didn't opt out, I actually find it great) doesn't want any notification, let alone one that says "I won't notify you". The default setting for notifications really ought to be changed here. -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Making sudo pip Safe (Again)
On Tue, 2017-02-07 at 08:40 -0600, Chris Adams wrote: > However, this is another case where sudo having a different PATH than > the normal shell comes into play as an irritant... installing modules > (or gems, etc.) that include executables puts them in /usr/local/bin, > which works from the shell but not sudo. Unfortunately: https://bugzilla.redhat.com/show_bug.cgi?id=1166185 https://pagure.io/fesco/issue/1646 -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Making sudo pip Safe (Again)
On Tue, 2017-02-07 at 13:08 +0100, Vít Ondruch wrote: > Dne 7.2.2017 v 11:32 Michal Cyprian napsal(a): > > Ruby on Fedora uses /usr/local/share/gems/ for packages installed > > as a root via gem tool for many years. > > Since you refer to Ruby, I just want to highlight that > /usr/local/share/gems/ is for packages installed by *root* via gem > too (as you correctly said) [1]. We assume that root manages the > entire system and wants installed packages to be available system > wide. I don't expect this is widely used practice. Typical user > installed packages goes into $HOME/.gem. Is there any location > similar to this? Yes, under ~/.local/lib/ It's what you get with `pip install --user $module`. > As far as I know, our users very appreciate the possibility to do > "gem install" without administrator privileges. So do Python developers. It's very commonly used. But even more common is to use virtual environments, one per application. --- I strongly feel this feature is a move in the wrong direction. I've never met a Python developer (and I'm one myself) installing modules system-wide with Pip. It seems to me the only people doing that are people who follow bad documentations. IMHO a much better (and simpler) way to fix the (very real) issue of unsuspecting users damaging their systems would be for pip to refuse to run with root permissions. -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ImportError: No module named kivy, when run make html
On Sun, 2017-01-29 at 09:51 +, Martin Gansser wrote:
> thanks for your answer.
>
> my question is, should i build for both python version the html files
> ?
> cd doc && make html PYTHONPATH=../build/lib.linux-%{_arch}-
> %{python2_version}
> cd ..
> cd doc && make html PYTHONPATH=../build/lib.linux-%{_arch}-
> %{python3_version}
Up to you.
Is the documentation going to be different between the python2-kivy and
python3-kivy package?
If yes, then having both python2-kivy-doc and python3-kivy-doc makes
sense.
Otherwise, just build it once as python-kivy-doc (bonus points if you
make it noarch) with whichever version of Python (although python3
being the default now, that's probably the one to use).
There's no need to do more work than necessary.
--
Mathieu
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ImportError: No module named kivy, when run make html
On Sat, 2017-01-28 at 18:40 +, Martin Gansser wrote: > thanks for your feedback, i run this from the doc dir of python-kivi > > [martin@fc25 doc]$ PYTHONPATH=.. python autobuild.py silenced=yes > [INFO ] [Logger ] Record log in > /home/martin/.kivy/logs/kivy_17-01-28_5.txt > [INFO ] [Kivy] v1.9.1 > [INFO ] [Python ] v2.7.13 (default, Jan 12 2017, 17:59:37) > [GCC 6.3.1 20161221 (Red Hat 6.3.1-1)] > Traceback (most recent call last): > File "autobuild.py", line 25, in > import kivy.app > File "/home/martin/rpmbuild/BUILD/kivy-1.9.1/kivy/app.py", line > 319, in > from kivy.base import runTouchApp, stopTouchApp > File "/home/martin/rpmbuild/BUILD/kivy-1.9.1/kivy/base.py", line > 30, in > from kivy.event import EventDispatcher > File "/home/martin/rpmbuild/BUILD/kivy-1.9.1/kivy/event.py", line > 8, in > import kivy._event > ImportError: No module named _event kivi._event needs to be built with Cython, which means you need to build the module before building the doc. If you look at the Makefile at the root of the sources, it uses the following to build the module: python setup.py build_ext --inplace This makes the built files go into the kivi/ folder, instead of the build/ folder. That's what makes the module available for the docs to build correctly. But you probably don't want to build with --inplace, so use this to build the docs: cd doc && make html PYTHONPATH=../build/lib.linux-x86_64-2.7 You'll need to adapt the architecture and Python version of course. -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Making sudo pip Safe (Again)
On Fri, 2017-01-20 at 09:12 -0800, Adam Williamson wrote: > On Fri, 2017-01-20 at 12:07 +0100, Jan Kurik wrote: > > = Proposed Self Contained Change: Making sudo pip Safe (Again) = > > https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe > > > > Change owner(s): > > * Michal Cyprian > > * Petr Viktorin > > * Tomas Orsava > > * Miro Hroncok > > > > > > At the present time, running sudo pip3 in Fedora is not safe. Pip > > shares its installation directory with dnf, can remove dnf-managed > > files and generally break the Python 3 interpreter. We propose a > > series of measures that will make it safe to use. > > > > > > == Detailed Description == > > The danger of using sudo pip3 stems from the fact that both Python > > dnf packages and sudo pip3 install modules to the same location, > > namely /usr/lib/pythonX.Y/site-packages. > > > > We aim to move the working directory for sudo pip3 to a more > > appropriate location: /usr/local/lib/pythonX.Y/site-packages, and > > modify the Python 3 interpreter in Fedora to scan both above > > mentioned locations when importing modules. > > This might also mean that we start using Python modules installed > from self-compiled applications, which might not be intended (we do > not include /usr/local/lib(64) in the default ldconfig path, AFAIK). In addition to that, if someone compiles and installs their own Python, it goes into /usr/local by default. (with the typical ./configure && make && make install) Which means that its modules would go into /usr/local/lib/pythonX.Y/site-packages. The suggested change means that the system Python would use the modules intended for that local Python. (if they are the same version) -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: New sources format
On Tue, 2016-12-20 at 23:30 +, Pádraig Brady wrote: > On 20/12/16 22:28, Christopher wrote: > > > > What's with the new sources format? > > The old format, I could do `md5sum -c sources` > > Why not make the new format with SHA512 follow the same pattern, so > > I could do: `shasum -c sources` or `sha512sum -c sources`? > > > > Is there any standard command-line tool to parse this new format, > > or do I just gotta grep/awk/bash my way through it? > > As far as I can see it's using the BSD tagged format, It is. This is a decision we made when moving to sha512, because we wanted the file to contain the used hash function. (for the future, when we invariably move again to a new hash function) We were starting to talk about our own format, then someone (I think it might have been Peter?) told me about the BSD tagged format, and we just went with that. > which the coreutils sha512sum command can parse. > I.E. the following format is supported since v8.20 (2012-10-23) > > SHA512 (filename) = ... Not only can it parse it, it can also generate it: $ sha512sum --tag some-file SHA512 (some-file) = ... -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F24 GStreamer zero day
On Thu, 2016-11-24 at 12:09 -0500, Matthew Miller wrote: > On Thu, Nov 24, 2016 at 11:02:19AM -, Carlos Garnacho wrote: > > > Question which directories does tracker actually scan / monitor > > > by default ? > > > > XDG folders recursively, $HOME non-recursively. This is all > > configurable in the privacy pane in the control-center fwiw. > > It doesn't seem to be -- I see Screen Lock, Location Services, Usage > & History, Purge Trash, and Problem Reporting. I have to to install > tracker-preferences to get a GUI for these settings, as far as I can > see. It's configurable in the Search panel of the control center. (the gear icon in the bottom right) -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upcoming build and release developer flag day December 12 2016
On Sun, 2016-11-20 at 11:14 -0700, Kevin Fenzi wrote: > On Sun, 20 Nov 2016 11:43:55 +0100 > Mathieu Bridon wrote: > > On Sat, 2016-11-19 at 19:11 -0600, Dennis Gilmore wrote: > > > We are wanting to write to you all about an important date coming > > > up. On the 12th of December 2016 we will be making some important > > > changes that will require changes on every developers machine. In > > > this case developers means every one that interacts with koji > > > using authentication > > > > > > lookaside cache checksum hash. currently packages are stored in > > > lookaside cache using md5sum we will be switching to sha256sum. > > > > I thought the plan was sha512, did that change? > > I thought we ended up on sha256, but it's been so long since this > work was ready to go, I admit I don't recall. ;) sha512 is fine with > me too. Last time I worked on this we were still talking about sha512, but it's possible you (the releng team) changed your mind since it's been a long time indeed and I haven't followed up since. Note that the server code expects sha512, not sha256: https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/di stgit/files/dist-git-upload.cgi#n120 So some more code would need changed to move to sha256, but I'm not sure it's worth the effort. -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upcoming build and release developer flag day December 12 2016
Hi, On Sat, 2016-11-19 at 19:11 -0600, Dennis Gilmore wrote: > We are wanting to write to you all about an important date coming up. > On the 12th of December 2016 we will be making some important changes > that will require changes on every developers machine. In this case > developers means every one that interacts with koji using > authentication > > lookaside cache checksum hash. currently packages are stored in > lookaside cache using md5sum we will be switching to sha256sum. I thought the plan was sha512, did that change? -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: sudo not looking into /usr/local
On Wed, 2016-11-16 at 14:19 +, Samuel Rakitničan wrote: > > Am 16.11.2016 08:08, schrieb Samuel Rakitničan: > > > > You can change the default behaviour in "/etc/sudoers" or (better) > > by adding a file in "/etc/sudoers.d". > > > > If you want to keep the users path, add: > > > > Defaults env_keep += "PATH" > > Defaults !secure_path > > > > or to change the (default) secure path, just add > > > > Defaults secure_path = /your/path/here:/as/usual > > File in /etc/sudoers.d is neat, thanks. But I am hoping we can came > up with a new default setting or is there a reason not to include > anything else? > > I was thinking about it some more, and I think this setting does more > harm then good. It limits what users can do but it doesn't stop them > to bypass it with a simple alias sudo="sudo PATH=$PATH". So in my > opinion the original "If you don't trust the people running sudo to > have a sane PATH environment variable you may want to use this." kind > of defeats its purpose. Note that there's been a ticket in Bugzilla requesting this for two years: https://bugzilla.redhat.com/show_bug.cgi?id=1166185 -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GitPython update blocked by rpkg - how can this be resolved?
On Tue, 2016-11-15 at 16:05 +, Barry wrote: > I was hoping to find out if there is in fact a patch to rpkg is > required. Try, and you'll see? -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 System Wide Change: DNF 2.0
Hi, On Fri, 2016-09-09 at 16:49 +0200, Jan Kurik wrote: > = Proposed System Wide Change: DNF 2.0 = This email says it is a system-wide change. > https://fedoraproject.org/wiki/Changes/DNF-2.0 But this page keeps saying « not a System Wide Change ». Which is? :) -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Why GUI software update tool is broken for me
On Thu, 2016-06-16 at 14:44 +, John Florian wrote: > > From: Jonathan Wakely [mailto:jwak...@fedoraproject.org] > > PackageKit and DNF use separate caches, which are not updated at > > the same time. Try "pkcon refresh" first to update its cache. > > Ok, I tried that but it made no difference. Try: pkcon refresh force > Does pkcon use /etc/yum.repos.d/? Yes. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir
On Thu, 2016-05-12 at 20:54 +1000, Dan Callaghan wrote: > Excerpts from Tom Hughes's message of 2016-05-12 09:15 +01:00: > > > > On 12/05/16 09:07, Tomasz Torcz wrote: > > > > > > Shouldn't that be /usr/lib/distro.repos.d (for > > > distribution-provided > > > data) with usual rules for overriding/masking in > > > /etc/distro.repos.d (for > > > local administrator)? > > Well equally isn't the "distro." prefix all wrong if it includes > > things other than distribution provided repositories... > Agreed... if end users and third-party repos are expected to also put > their configs into this directory, then having "distro" in the name > doesn't really make sense. > > If the objection to yum.repos.d is that they are not just "yum repos" > anymore, since clients other than yum can consume them -- then maybe > we can think of them as "yum-formatted package repos" (that is, > "repositories of RPM packages with metadata in the format originated > by yum"). Agreed. This change seems like a lot of churn (having to preserve compatibility, having to change yum, creating tons out of date documentation, ...) for too little actual benefit. The "Benefit to Fedora" section just isn't convincing: > The former default directory path implies that the repositories are > consumable by Yum only, which is not true. This general path name > would help us define repository configuration path that would not be > bound to a specific package manager name and so be more portable > among package managers. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Checking signatures on package source tarballs
On Tue, 2016-03-22 at 09:12 -0400, Josh Boyer wrote: > On Tue, Mar 22, 2016 at 9:02 AM, David Woodhouse > wrote: > > > > The original draft does raise an interesting question — do we need > > to put the upstream PGP key directly into the package git tree > > instead of the lookaside cache? > > > > I suppose while the lookaside cache is still only using MD5(!) to > > validate what it downloads, the answer to that is an unequivocal > > 'yes'. > As an aside, I think Till has code written to make the lookaside use > sha256. I'm not sure what the next steps are to get that rolled out > though. Code-wise, everything is ready, both on the server-side and on the client-side. The only thing needed now is to flip the switch from md5 to sha512. But doing so would mandate an upgrade for every packager, since enforcing sha512 means older fedpkg versions still using md5 would get their uploads refused. As a result, the Releng team collectively decided to hold off the move, and bundle it with other similarly breaking changes (new Koji certificates, for example) All the details are here: https://fedorahosted.org/rel-eng/ticket/5846 -- Mathieu -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 Self Contained Change: System Python
On Mon, 2016-02-08 at 12:47 -0500, Stephen Gallagher wrote: > On 02/08/2016 12:45 PM, Mathieu Bridon wrote: > > On Mon, 2016-02-08 at 17:21 +0100, Petr Viktorin wrote: > > > Part of the change is defining the exact subset. The idea is that > > > it > > > should be small, to keep cloud images small for apps that don't > > > use > > > Python themselves. > > > > Wouldn't it be a better goal to not have Python at all on Cloud > > images? > > > > So... no dnf? That seems a little unlikely to yield a good long-term > result. Or maybe dnf shouldn't be written in Python? I mean, if a goal is to minimize the size of the deliverables, at some point you need to cut down on dependencies. And removing a whole language and its ecosystem seems like a pretty good win dependency-wise. Lots of dnf deps are already C libs, so it's not like the heavy-lifting is not available in C. And then for plugins, it is certainly possible to have a C apps and let people write plugins in various languages, among which Python. gedit does this for example, through libpeas. So no, I didn't mean to throw dnf out, I meant to consider what is the minimal features (and dnf strikes me as one), and then radically reduce what those depend on. Note that I'm a Python developer by trade as well as by heart. So I'm certainly not saying Python is terrible and should be eliminated. I just think that managing to remove it from the minimum images would lead better results (and much less confusion) than splitting it into various subpackages. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 Self Contained Change: System Python
On Mon, 2016-02-08 at 17:21 +0100, Petr Viktorin wrote: > Part of the change is defining the exact subset. The idea is that it > should be small, to keep cloud images small for apps that don't use > Python themselves. Wouldn't it be a better goal to not have Python at all on Cloud images? -- Mathieu -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: security of the lookaside cache (was: frafra uploaded yumex-dnf-4.1.6.tar.gz for yumex-dnf)
On Wed, 2015-12-30 at 20:09 +0100, Pierre-Yves Chibon wrote: > On Wed, Dec 30, 2015 at 07:38:35PM +0100, Björn Persson wrote: > > But still, why are we still using MD5? > > For the record bochecha has been leading the move away from md5 to > sha, making the changes in such a way that it will give us the > flexibility to later change from sha1 to sha256, sha512 or something > else. > > The problem being that there are quite a number of places to change > (dist-git, fedpkg...) which all have different upstreams and release > cycles. > So all in all, it's in progress but takes some time. That's not the problem any more. All those places have been changed, and should all be ready for the switch now. However, switching means breaking old fedpkg clients: people would have to update their fedpkg as once we switch the old (i.e current) version would fail to be able to handle anything non-md5. The Fedora Releng team decided not to do that breakage at the moment, and instead bundle it with other changes requiring a breakage, so that we break things only once rather than several times. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF could improve messages about package auto-removal
On Fri, 2015-12-04 at 15:43 -0500, DJ Delorie wrote: > > If the package yumdb entry (now dnfdb) says it was installed as a > > dependency > > This is the part I assumed was there. > > Is there a separate dnf command to list all installed-as-dependencies > that nothing depends on any more? You can use "dnf list autoremove" to list the packages dnf thinks it can remove (because they were installed as deps and nothing requires them any more) Then you can use "dnf mark install $pkg" to mark them as installed, and they will disappear from the "autoremove" list. Note that packages installed by PackageKit are not marked as installed, so dnf always thinks it can remove them. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: LibreOffice packaging is a messy dependency graph
On Wed, 2015-12-02 at 15:44 +0100, Roberto Ragusa wrote: > On 12/02/2015 02:42 PM, David Tardon wrote: > > > On Tue, Dec 01, 2015 at 02:20:34AM -0500, Dan Book wrote: > > > I have run into this before and it was very confusing, it really > > > should be > > > a separate command from remove for when you actually want to > > > remove what > > > dnf thinks is now "unused". > > > > Why? Remove is the opposite of install. "dnf install foo" will > > install > > package foo _and_ all its dependencies. So it is only logical that > > "dnf remove foo" should remove package foo _and_ all its (unneeded) > > dependencies. > > Maybe it is not so simple. > There are dependencies with no use apart the main tool (tool requires > tool-libs), > but in some cases the dependency is useful on its own (e.g. fonts). > > So, I counter your reasoning with this: > > - dnf install foo (also installs bar) > - dnf install bar (oops, already installed, good) > - dnf remove foo (wow, why did it remove bar, I explicitly > "installed" it yesterday!) > > Is dnf able to recognize that bar was "wanted" and not "accidental"? There's "dnf mark install bar" for that. And I **think** that it's automatically done when you installed bar in your second command above. (if it isn't it probably should be) -- Mathieu -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [RFC] DistGit Container Image namespacing for Layered Image Build Service
On Tue, 2015-11-10 at 12:08 -0600, Adam Miller wrote: > Hello all, > In the Fedora 24 timeframe the Fedora Release Engineering group > is > aiming to deliver the Layered Image Build Service[0] to allow Fedora > contributors to build containers images. In the first iteration of > this we're targeting Docker layered image support. Part of this will > be to allow Fedora contributors to maintain Dockerfiles much like we > maintain rpm spec files via DistGit. > > However we need to make a couple of decisions about naming > conventions > such that we can distinguish between rpms and container images as > they > are stored in Fedora DistGit. Also, alternatively we could setup a > completely separate DistGit for container images that is disjoint > from the one used for rpms. I would love feedback on everyone's > preferences between those two options. You could set it up in /srv/git/containers, in parallel to the current /srv/git/rpms ? That nicely avoids naming collisions. It also should be quite asy now that dist-git is in ansible, you could probably just factor out the path in the roles as a variable? > Cockpit's Dockerfile repo in DistGit would be stored with a > leading special character: > fedpkg clone -cockpit With the "-" as a leading character, you open yourself to nice errors with the fact that it could be recognized as options. So you'd want to type: fedpkg clone -- -cockpit Alternatively, if you separate the two distgits, you could have a fedcontainer tool, which would just be fedpkg but with its configuration pointing to the container distgit, the container build service, etc... Or maybe just a: fedpkg --container clone cockpit ? Most of the code (at least the one handling dist-git) could probably be reused without any difference. All in all, separating them seems much simpler to me. You'd have a bit of work up front (to adapt the Ansible playbooks and fedpkg slightly), but you pretty much avoid a whole class of issues with naming collisions, cli options, and future surprises. -- Mathieu -- 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 commits&branches mess up
Hi,
On Fri, 2015-11-06 at 14:01 +0100, Germano Massullo wrote:
> I have done some mistakes in [1]
>
> 1) I edited the file once to remove 32 bit CPU support, then I have
> done the push to master
> 2) I saw that I have forgotten to add changelog, so I edited the file
> again, I made a new push to master
> 3) I started merging the F21 branch to the master and I got the
> conflict
>
> I have found a solution like [2], but I am afraid of making things
> get worse...
Assuming you want to have exactly the same thing in F21 and master, and
keep the two branches in sync in the future, here is something that can
get you out of this situation:
First, you need to cleanup the master branch, as you committed some
merge conflict indicators (the << === and >>> lines).
So just remove those lines, as well as the "Release: 2%{?dist}" line
(you bumped the release to 3, you don't want to also keep the line
setting it to 2)
Then commit on master.
At this point, you can do this:
$ git checkout f21
$ git merge master # this causes a merge conflict
$ git checkout master -- darktable.spec # solve the conflict by taking the
file as it is in master
$ git commit
At this point, the changes that were in master are now also in f21.
But you're not finished, if you really want to keep the branches in
sync from now on, here's the trick:
$ git checkout master
$ git merge f21
Now, both master and f21 are pointing to the exact same commit. So just
push and build.
Next time you make a change in master, just merge it in f21 and you
won't have any conflict any more. :)
--
Mathieu
--
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: python: dropping the .py files [was Re: Fedora 23 cloud image (and, for that matter, minimal anything)] bloat
On Fri, 2015-09-25 at 10:04 -0400, Matthew Miller wrote:
> On Thu, Sep 24, 2015 at 10:10:40AM +0200, Vít Ondruch wrote:
> > Also, you might consider to ship the precompiled bytecode just
> > optionally, using recommends.
> >
> > On contrary, if you insist on shipping the bytecode, why you don't
> > drop
> > the .py files? I see a lot of duplication all around python
> > packages
>
> Wait, we can do that? Why don't we?
>
> Everything I see in online discussion is centered on, basically,
> transparency. But we wouldn't be doing it for obfuscation. The srpms
> would still be there, and for that matter we could ship the .py files
> in a subpackage.
Or maybe rpm could have a macro a bit like %{_install_langs} (which
controls what language files are installed, even though they are all in
the packages) to control what gets installed for Python stuff, even
though everything is in the packages.
On Workstation, that macro would be set so that both the byte-code and
the code would be installed (it is invaluable for learning and
debugging purposes to be able to read/edit the code).
And on Cloud, that macro would be set to have only the bytecode
installed, so that you'd save the space.
--
Mathieu
--
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: apitrace-libs.i686 missing in x86_64 repos
On Fri, 2015-09-25 at 13:03 +0200, Sandro Mani wrote: > Is there any other option short of introducing a dummy -devel > package? You could ask releng to add apitrace-libs to the multilib whitelist: https://pagure.io/mash/new_issue However, I have to wonder, why wouldn't the library have a -devel package? Is there no way to link against that library? -- Mathieu -- 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: apitrace-libs.i686 missing in x86_64 repos
On Fri, 2015-09-25 at 12:02 +0200, Sandro Mani wrote: > Hello > > Got bug #1266181 filed about apitrace.i686 missing in the x86_64 > repos. > The reporter probably meant apitrace-libs.i686, which in the past was > indeed installable on x86_64. Any ideas what the reasons can be that > the package disappeared? Suppose something about the "mash" step, but > that's as far as I get. The way multilib works is that mash will get all the *-devel packages from i686 and add them to the x86_64 repository, along with all their dependencies. In your case, you apitrace package doesn't generate any -devel subpackage. If it did, mash would include it for multilib, and as the -devel packages usually depend on the -libs package, the -libs would also get included. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The DevConf.cz 2016 Call For Participation is now open!
Dear Jan, On Fri, 2015-09-11 at 07:30 -0400, Jan Bleha wrote: > Dear Red Hatters, We do not all work for Red Hat on the various Fedora mailing-lists you sent this message to. Should we, non Red Hatters, ignore this message? I'm asking, because your email doesn't contain the typical "this email is confidential" footer that usually accompanies corporate communication. ;) -- Mathieu (ex Red Hatter, if that matters) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning two packages
On Fri, 2015-09-11 at 18:10 +0800, Christopher Meng wrote: > I'd be happy to take bonesi. There, it's yours. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaning two packages
Hi everyone, I'm going to orphan the following packages, as I haven't really been interested any more in any of them for quite some time, now: * bonesi -- The DDoS Botnet Simulator (master, f23, f22, f21) * libhtp -- Security-aware parser for the HTTP protocol and the related bits and pieces (master, f23, f22, f21, el6) Both are up to date and have no known bug reports in Fedora. Nothing seems to depend on them. If anybody wants to take over them, I'd be happy to pass them on. If not, I'm just going to retire both of them in Rawhide. Cheers, -- Mathieu -- 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: Orphaned packages available for new point of contact
On Thu, 2015-09-10 at 11:16 +0200, Matěj Cepl wrote: > On 2015-09-09, 19:37 GMT, Kevin Fenzi wrote: > > pytz > > python-dateutil > > I see these two as too important to let them fall, so I am > taking them. However, I would really really like to have some > co-maintainers, because I don’t feel like I really understand > the matter. Give acls to the python-sig group? -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Glibc locale subpackaging
On Thu, 2015-08-27 at 16:10 +0200, Florian Festi wrote: > On 06/22/2015 12:16 PM, Jan Kurik wrote: > > = Proposed System Wide Change: Glibc locale subpackaging = > > We have to revisit this topic as soon as rich dependencies are in > place. Rich dependencies offer a way to handle locales on a system > wide level. One possible implementation would be having > > langsupport-XX meta packages that enable support for a given > language. > > Locales could be in packages like glibc-lang-de, foo-lang-de, ... > The main package could then have > Requires: (foo-lang-de if langsupport-de) > if we want to enforce the locale package to be installed. > > Otherwise it might be more elegant to have the language package (e.g. > glibc-lang-de) have: > > Supplements: (glibc and langsupport-de) > > As we can assume that glibc is always installed this could already be > done with: > > Supplements: langsupport-de > > The benefit of this approach is that installing a new langsupport-XX > package will bring in the locale packages for all packages making use > of this mechanism. Could that even be done automatically by rpmbuild? Just like rpmbuild automatically generates a -debuginfo with the right files in it, could it generated the -lang-xx packages with the .mo files inside, and add the Supplements dependency you suggest? Because doing it manually for all the languages supported by an application (which might vary from release to release) would be pretty awful. :-/ -- Mathieu -- 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: bodhi 2 now live
On Sun, 2015-08-23 at 22:23 +0200, Kevin Kofler wrote: > Mathieu Bridon wrote: > > In the case of Kevin's update, the problem is that markdown lists > > must > > have an empty new line before them, like so: > > > > A paragraph of text: > > > > * first item > > * second item > > > > Kevin, you used the following, which indeed the Markdown parser > > turns > > into a single paragraph: > > > > A paragraph of text: > > * first item > > * second item > > Thank you for the analysis (and now I know how to work around this > regression), but: > > > Bodhi 1 was already doing the same thing with such an input. > > No, sorry, but that is not true. I wrote those update notes in the > Bodhi 1 web interface, so of course I looked at the resulting > formatting. > Bodhi 1 interpreted that syntax as a list, not as a single paragraph. So it seems I wrote that code so long ago that I misremembered. You are right, I has indeed added some special handling in Bodhi 1 to have lists work even without an empty line before them: https://github.com/fedora-infra/bodhi/blob/bodhi1-develop/bodhi/templat es/show.kid#L47-L48 > This is a change in Bodhi 2 (and IMHO, for the worse, though if > there's some official Markdown spec that says it should be that way, > meh…). Markdown is extremely under-specified, so a lot is left up to implementations. In the case of lists, I can find no mention at all of surrounding text in the "spec", it only talks about lists in complete isolation to other elements, as far as I can see: http://daringfireball.net/projects/markdown/syntax#list Which means that very often, Markdown implementations just do "whatever the original implementation does", bugs and all. And sure enough, if you try using the online demo: http://daringfireball.net/projects/markdown/dingus You'll find it behaves the same way Bodhi 2 does. CommonMark is trying to improve this situation with a complete specification, but it isn't what we use in Bodhi 2 (yet?) If you really feel strongly about that empty newline, open a bug report asking for it. I guess we could just reuse the one-liner I had for Bodhi 1, or completely move to CommonMark, as it seems to allow what you want: http://spec.commonmark.org/0.21/#example-246 In any case, please open bug reports for anything you want in Bodhi 2, to make sure your feedback isn't lost in the archives of the mailing -list. -- Mathieu -- 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: bodhi 2 now live
-- Mathieu On Sat, 2015-08-22 at 19:27 -0500, Michael Catanzaro wrote: > FWIW I think the new version looks much nicer than the old one. > Hopefully the issues will be ironed out. > > On Thu, 2015-08-20 at 17:48 +0200, Kevin Kofler wrote: > > * The formatting of the update notes has changed in some ways (line > > breaks > > gone missing?), breaking my nicely formatted notes, e.g.: > > https://bodhi.fedoraproject.org/updates/calamares-1.1.2-1.fc23 > > (The enumerations were turned into one paragraph with bogus > > italics.) > > This one's a feature I think: updates are already displayed to the > user in markdown -- at least in GNOME Software, and I think even the > obsolete GNOME Package Updater, and I think Muon as well? not sure > about Apper -- so users are going to see your updates in italics no > matter what. You'd be forgiven for not realizing this, since the web > interface did not show this. That was a serious problem. Bodhi 1 did interpret the update notes as Markdown already in the web interface... for at least the past 5 years. Bodhi 2 does have some extended Markdown features, compared to Bodhi 1, but lists and italics were there from the start. In the case of Kevin's update, the problem is that markdown lists must have an empty new line before them, like so: A paragraph of text: * first item * second item Kevin, you used the following, which indeed the Markdown parser turns into a single paragraph: A paragraph of text: * first item * second item Bodhi 1 was already doing the same thing with such an input. -- Mathieu -- 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: Disk quota exceeded
On Thu, 2015-07-23 at 11:39 +0200, gil wrote: > > > Il 23/07/2015 09:00, Marcin Haba ha scritto: > > On 23.07.2015 08:53, gil wrote: > > > hi > > > any ideas? > > > Konsole output > > > [gil@localhost SRPMS]$ scp jamm-0.3.1-1.fc22.src.rpm > > > fedorapeople.org:~/public_html/ > > > scp: /home/fedora/gil/public_html//jamm-0.3.1-1.fc22.src.rpm: > > > Disk quota > > > exceeded > > > regards > > > gil > > Hello, > > > > Please look on first point here: > > > > http://fedoraproject.org/wiki/Infrastructure/fedorapeople.org#Commo > > n_Answers > > > > "Each Fedora contributor has 200 KiB (approximately 1954 MiB) > > of > > quota-controlled space." > > > > Probably you need to remove some files to take place for new upload > > to > > fedorapeople.org. > > > > Best regards. > > Marcin Haba (gani) > > > hi > thanks for your suggestion, but i have already done this operation > (removed unused src rpm ~ 20). but still the problem remain ... Then you're probably still using too much space. To be sure: $ du -sh ~ If that's over the quota, then you should clean up more stuff. Alternatively, you can request more space in your Fedora People home, by asking the Infrastructure team. (which is written in that same page Marcin sent earlier) -- Mathieu -- 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: Proposal: Drop comps
-- Mathieu On Wed, 2015-07-15 at 10:51 +0200, Ralf Corsepius wrote: > On 07/15/2015 10:20 AM, Vít Ondruch wrote: > > > Description and Summary can be localized in .spec file [1], where > > supposedly "names" in comps terminology refers to "summary" in > > .spec > > terminology. Including translations is encouraged in guidelines as > > well > > [2, 3], unfortunately without any further details :/ > > I don't think localized summaries and descriptions are applicable in > distributions like Fedora, where packages are maintained by > individuals. > > IMO, making localized summaries/descrs. helpful would require a > multilingal team of translators/packagers, whose sole task it would > have > to be to add translations for a predefined set of languages to > maintain > them. > > That said, I don't consider random packagers adding random > translations > to packages to be useful and to cause more problems than they solve. One problem with localized summaries/descriptions in packages, is that you need a new build (and a new update in Bodhi, unless you wait 6 months for the next release) for it to reach users. That's a lot of churn, and it's a terrible UX for users to keep receiving "updates" that only add a translation of the summary/description of the package (not the app itself!) in a language they might not even care of. Comps is much better on this point: we edit comps, and at the next compose the change is taken into account. Much less churn, especially for the users. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Is %autosetup another unwanted baby of Fedora?
On Mon, 2015-07-13 at 15:21 -0500, Dennis Gilmore wrote: > On Monday, July 13, 2015 09:13:24 PM Richard W.M. Jones wrote: > > Is anyone maintaining fedpkg now? > > fedpkg has active maintainership and development. does not mean > that every corner case is know about of gets attention. fedpkg might sometimes look like it's not getting any development though, but that's really because most of the work happens in pyrpkg, the library used by fedpkg (and rhpkg, and a couple others) And pyrpkg is probably where patch management should end up in fact, so that it can be shared with other users of pyrpkg. -- Mathieu -- 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 for mock in RHEL 6?
On Mon, 2015-06-15 at 08:56 +0200, Miroslav Suchý wrote: > Dne 12.6.2015 v 00:28 Kevin Kofler napsal(a): > > 1. The software we ship in Fedora (and that includes EPEL) should > > work out of the box. If you cannot provide DNF (with the plugins) > > in EPEL, then defaulting to yum is the only option. > > > > 2. The mock previously in EPEL actually worked for Rawhide (using > > yum there), so you have taken existing user setups that worked and > > broken them, for no practical benefit whatsoever (because all they > > can do to make it work is to make exactly the settings change you > > refuse to make by default, and because mock will just work with > > yum). > > So you are suggesting what? > Let silently use yum on EL hosts? Kevin didn't say anything about it being silent. By all means, do warn people that mock is going to use yum instead of dnf as it should. But an application should never print an error message telling the user what they can do to get the error to go away. That's just bad design. If the application knows what the user should do to get around the error, then the application should just do it itself. Finally, you're basically saying that mock requires dnf to build "proper" Rawhide packages. You're a package maintainer, it is your responsibility to maintain the dependencies for your package in all the Fedora/EPEL branches where your package is. That means if mock requires dnf (and its plugins) to build Rawhide packages, and you maintain mock in EPEL, then it is your responsibility to make sure that dnf (and its plugins) are in EPEL. -- Mathieu -- 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 for mock in RHEL 6?
On Wed, 2015-06-03 at 14:19 +0200, Miroslav Suchý wrote: > Dne 2.6.2015 v 06:56 Dave Johansen napsal(a): > > https://fedoraproject.org/wiki/Mock#Mock_on_EL_6_and_EL_7:_Yum.2C_a > > nd_DNF > > > > I just ran into this issue and I was wondering if it's possible for > > this flag to be add to the default config on RHEL 6/7. > > Technically yes. > > Politically no. > > As stated in refered blog entry: > http://miroslav.suchy.cz/blog/archives/2015/05/20/why_mock_does_not > _work_on_el_6_and_el7_and_how_to_fix_it/index.html > I decided to go with 3rd option. And you must manually acknowledge > that you are creating builds non-standard way and > they may differ from builds made on Fedora. Except that builds made on Fedora Koji all use yum to populate the mock chroot, not dnf. As a result, it is the mock default configuration of using dnf which is non-standard. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaning/retiring 2 packages
Hi, I don't use these 2 packages any more, and don't want to continue maintaining them. If someone want to take over, I'll be happy to pass them. But if nobody express their interest in the next few days, I'll just retire them. # weighttp This package hasn't had any upstream release since 2011. Well, upstream didn't actually release anything, they just tagged the commit with "v0.3", so I was generating the tarball myself. There have been 6 commits in master since the last release, all in 2013. So all in all, upstream is dormant, at best. # docx2txt Last release was in 2014, I guess it works overall, but like I said I don't use it myself any more. Cheers, -- Mathieu -- 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: Naming packages when upstream uses dashes in the release version
On Wed, 2015-05-06 at 10:24 +0200, Ralf Corsepius wrote: > On 05/06/2015 09:21 AM, Petr Pisar wrote: > > On 2015-05-05, Alexander Ploumistos wrote: > >> What irks me the most, is that the version of the source package is > >> 3.80-1 and this is reflected in the spec file macros (Version: 3.80, > >> Release 1), > > > > It depends on the meaning of the upstream's `-1'. Basically, I would > > interpret it as yet another version level, i.e. as `3.80.1'. If the upstream > > tends to release `3.80.1-1', I'd interpret `3.80-1' as `3.80.0.1'. > > This is one common practice. I personally use "_" for local packages in > such occasions (IIRC, rpm doesn't care whether "_" or "." is used). Indeed: $ rpmdev-vercmp 1.0-1 1_0-1 1.0-1 == 1_0-1 Thanks, I had never realized that. :) -- Mathieu -- 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: Contact info for FAS user: anishpatil
On Tue, 2015-04-21 at 15:01 +0200, Robert Mayr wrote: > Maybe his RH address? > apa...@redhat.com Anish just left Red Hat. He is also moving countries, so maybe that's why he hasn't been very responsive lately? -- Mathieu -- 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 replacing yum and dnf-yum
On Mon, 2015-04-13 at 10:43 -0700, Adam Williamson wrote: > On Mon, 2015-04-13 at 08:47 +0200, Mathieu Bridon wrote: > > Le dimanche 12 avril 2015 à 17:06 -0700, Adam Williamson a écrit : > > > > > > It's hard to see how you build a perfect dep check other than > > > trying > > > to solve the deps of *every single package in the distro* against > > > every proposed update. > > > > Can't we run repoclosure on (at the same time) the fedora repo, the > > updates repo, and a temporary repo made of the packages to be pushed? > > > > Repoclosure does check for the deps of every single package in the > > set > > of repos it is provided. > > Not sure offhand if we've looked into using repoclosure to check this, > but one obvious issue I can think of is, what if repoclosure isn't > clean *to start with*? Block all updates push until repoclosure gets cleaned? Of course, Bodhi admins would need to still be able to force pushes, to not block security updates or updates which fix repoclosure. Think of the incentive this would provide to fix broken deps! :) -- Mathieu -- 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 replacing yum and dnf-yum
Le dimanche 12 avril 2015 à 17:06 -0700, Adam Williamson a écrit : > > It's hard to see how you build a perfect dep check other than trying > to solve the deps of *every single package in the distro* against > every proposed update. Can't we run repoclosure on (at the same time) the fedora repo, the updates repo, and a temporary repo made of the packages to be pushed? Repoclosure does check for the deps of every single package in the set of repos it is provided. -- Mathieu -- 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 replacing yum and dnf-yum
On Thu, 2015-04-02 at 14:23 +0200, Jan Kratochvil wrote: > On Thu, 02 Apr 2015 09:50:05 +0200, Jiří Konečný wrote: > rpm/repoquery just do not support wildcards so one has to type: > repoquery --whatprovides 'libnetapi.so.0()(64bit)' > dnf repoquery --whatprovides 'libnetapi.so.0()(64bit)' That's not entirely true: $ repoquery --whatprovides 'libnetapi.so.0*64*' samba-libs-2:4.1.17-1.fc21.x86_64 samba-libs-2:4.1.12-5.fc21.x86_64 DNF however: $ dnf repoquery --whatprovides 'libnetapi.so.0*64*' Using metadata from Thu Apr 2 14:26:05 2015 -- Mathieu -- 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: [Proposal] Ring-based Packaging Policies
Le mardi 17 février 2015 à 17:39 +0100, Ralf Corsepius a écrit : > On 02/17/2015 05:18 PM, Petr Pisar wrote: > > > Why not to create a new repository with reduced policy as > > Stephen proposed with the one-way dependency rule (between current > > Fedora and the new easy-for-beginners repository)? > > Because this would establish a 2-class society, with double > standards standards and so on. > > Also RH and other distros history repeatedly has told the lesson > such will not fly and are doomed to fail. It seems to have been working just fine in RPMFusion, where the free and nonfree repositories have different standards for inclusion, and where packages in nonfree can depend on packages in free, but not the other way. At another scale, it seems to not be working too badly already for Fedora+RPMFusion, where Fedora and RPMFusion have different standards for inclusion, and where packages in RPMFusion can depend on packages in Fedora, but not the other way. If I understand correctly, Ubuntu has a similar setup with main and universe, and so does Debian with main, contrib and nonfree. History doesn't seem to unambiguously prove what you think it does, but then I guess you can always argue that those examples just haven't failed yet. ;) -- Mathieu -- 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: rawhide report: 20150125 changes
Le dimanche 25 janvier 2015 à 08:13 +, Fedora Rawhide Report a écrit : > [python-pygit2] > python-pygit2-0.21.4-1.fc22.i686 requires libgit2.so.21 > python3-pygit2-0.21.4-1.fc22.i686 requires libgit2.so.21 I've tried updating pygit2 to the latest 0.22.0 release, which is made for libgit2 0.22.0. However, it fails on i686: https://github.com/libgit2/pygit2/issues/477 Still trying to figure out what's going on, will update then. -- Mathieu -- 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 as default package manager
On Thu, 2015-01-22 at 17:00 +0100, Vít Ondruch wrote: > Dne 21.1.2015 v 17:12 Dennis Gilmore napsal(a): > > On Wed, 21 Jan 2015 11:13:24 +0100 > > Mathieu Bridon wrote: > > > On Wed, 2015-01-21 at 11:02 +0100, Vít Ondruch wrote: > > >> I am using mock for Fedora development with DNF enabled by default > > >> and it works just fine. May be you want to share what is troubling > > >> you? > > > > > There is a difference between « it works just fine for me » and « it > > > works to build the distro » > > > > and for it works to build the distro it has to work on releases all the > > way back to rhel 5 as we build epel for rhel5 still and need to make > > rhel5 chroots. I have not heard of anybody testing that at all yet. > > Actually, the mock configuration might be different for different releases: > > https://lists.fedoraproject.org/pipermail/buildsys/2014-December/00.html Not in Koji. As Dennis already said, Koji generates its own Mock configs, it doesn't use the ones shipped with Mock itself. -- Mathieu -- 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: amending the new package process
On Thu, 2015-01-22 at 14:49 +0100, Zbigniew Jędrzejewski-Szmek wrote: > Unfortunately review swaps don't work for new packagers, before they are > sponsored. They are encouraged to do informal reviews, but those reviews > don't carry formal weight. I propose to change this, and allow non-sponsored > packagers to do formal reviews, except that an actual packager with review > rights has to ack the review. This is exactly what informal reviews are. -- Mathieu -- 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 as default package manager
On Wed, 2015-01-21 at 11:02 +0100, Vít Ondruch wrote: > Dne 21.1.2015 v 10:35 Peter Robinson napsal(a): > > On Wed, Jan 21, 2015 at 9:22 AM, Miroslav Suchý wrote: > >> On 01/21/2015 09:33 AM, Vít Ondruch wrote: > >>> It is surprising to see so many packges depending on yum. Yes, there is > >>> stuff like rpm-build and mock, > >> And mock can live without yum. If we only had weak deps allowed in Fedora > >> mock.spec would have > >> Recommends: yum > >> > >> But I'm really interested in state of DNF as default too. Should I switch > >> mock to use DNF as default? > >> For me there is still lot of unfinished tasks. E.g. documenting what > >> --installroot should actually do [BZ 1163028] > > I don't think it's ready, it might be useful to have an option to > > switch it over for local use to enable easier wider testing but I > > certainly don't think it's ready to be default for mock yet. > > > > Peter > > I am using mock for Fedora development with DNF enabled by default and > it works just fine. May be you want to share what is troubling you? There is a difference between « it works just fine for me » and « it works to build the distro » The latter needs much more testing and guarantees than the former, although the former is certainly encouraging. -- Mathieu -- 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: Did I mess up? [dcmtk abi change in stable branches]
Hi, On Wed, 2014-12-17 at 10:58 +0100, Mario Ceresa wrote: > Now, simply recompiling them fixes the problem in rawhide, but how can > I avoid breaking things in stable branches? Is there a way to have all > three packages hit the repositories at the same time? They need to be part of the same update in Bodhi. -- Mathieu -- 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: Update to Parole 0.6.x stable series - completed port to GTK+3
Hi, On Mon, 2014-12-01 at 07:39 +0100, poma wrote: > Gentlemen packagers, resting on your laurels? You should try being less snarky in your future communications, it usually leads to better results. > Update to Parole 0.6.x stable series - completed port to GTK+3 > https://bugzilla.redhat.com/show_bug.cgi?id=1169240 Here is the procedure to report a nonresponsive package maintainer: http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers You'll notice that it speaks about delays in order of 7 days, not 7 hours. In addition, here is the procedure to become a packager and help maintain this package, if you care about it: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers Good luck! -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mozilla enabled ads in Firefox and they're active in Fedora
On Tue, 2014-11-18 at 15:12 +0200, Nikos Roussos wrote: > On 11/18/2014 02:55 PM, Benjamin Kreuter wrote: > > On Tue, 2014-11-18 at 11:15 +0200, Nikos Roussos wrote: > I'm talking about the "advertisement" part. Some people seem to be > bothered by this alone. Tiles feature indeed promotes some websites, but > we already do that. > >>> > >>> No, actually we don't. We promote websites because we honestly think > >>> they're useful, not because we're paid to do so. > >> > >> That's irrelevant. Paid or not, promoting websites through tiles or > >> gnome-shell is the same form of advertisement. > > > > Money is not irrelevant. Paid advertising is how we wound up with > > pop-ups, hover ads, etc. The question is whether or not we can trust > > Mozilla to steer clear of such things. So far there seems to be no > > reason to trust Mozilla -- the ads are opt-out, they only sometimes > > respect DNT, and they are being pushed despite the backlash from > > Mozilla's community. > > This is a moral judgment, so it's irrelevant for making a policy > decision (from Fedora's point of view). As a community, we can certainly decide to base our policies on moral judgments we make, just as we can decide to base them on technical judgments. (or even a mix of both) For example, we don't allow nonfree software in Fedora, and I for one certainly hope it is not **entirely** a technical decision. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mozilla enabled ads in Firefox and they're active in Fedora
On Mon, 2014-11-17 at 11:37 +0200, Nikos Roussos wrote: > I don't consider my IP address a call to home. [...] Even Gnome checks my > IP's location to fix my timezone. Not by default, you have to enable this explicitly. > > Second, a user can easily accidentally click on ad, since it is mixed > > among other tiles, with the user's browsing habits. > > And a user may accidentally start searching on the Google search box > before she realizes that she sends data to Google "as she types" (that's > how you get recommendations). Indeed, this is in Firefox though, which is the application people are saying they'd like to change, so it stops doing that without explicit user opt-in. > Again, this thing we discuss is already happening on Gnome Shell. Type > "twitter" on your Gnome's search box. I'm pretty confident that no network query is done when you search for that, and that instead GNOME Software searches in its local metadata cache. Nothing outside of your own computer knows that you searched for "twitter" in the GNOME search box. > And I don't think there is a way > currently to disable this. So please get your facts straight before > start suggesting we change default browser. All examples you have given of such opt-out network calls are either in Firefox or incorrect. So maybe there is a need to change something in the Firefox default configuration after all? :) -- Mathieu -- 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: Improving the offline updates user experience
On Fri, 2014-10-24 at 12:00 +0200, Miroslav Suchý wrote: > I'm not updating daily. I upgraded my machine IIRC 2-3 weeks ago. So lets > benchmark it and provide you real data. > > My machine have classic magnetic disk, however in SW RAID1. > Timing cached reads: 12236 MB in 2.00 seconds = 6124.59 MB/sec > Timing buffered disk reads: 412 MB in 3.00 seconds = 137.12 MB/sec > Fedora 21, 16 GB RAM (2GB free), 8 CPU cores, swap available but none used > > I run "dnf upgrade" and I have been offered 853 packages and 1.3 GB to > download. > Download lasted 3mins 20secs. > Then installation started and since beginning "transaction started" till the > end lasted exactly 53 minutes. > No specific package is blocking the process, dnf was chewing packages one by > one in steady pace. Veryfing phase lasted > ~4 minutes, so it means approximately 3 second per package, which is what I > am seeing on screen. > > And this is nothing exceptional. I see similar times across all machines I > maintain. When I'm updating box of my mother > (old EeeBox, updating aprox every 3 months) then the time is usually 3 hours > (however ~1 hour is just download phase). More than anything, doesn't this just shows that we simply push way too many updates in Fedora? -- Mathieu -- 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: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)
On Thu, 2014-10-16 at 14:40 +0200, Kalev Lember wrote: > Hi all, > > We seem to have a number of broken dependencies in F21 that have gone > unfixed for a quite some time. Not sure what's up with them; the > maintainers are supposed to get daily notifications to make sure these > don't go unnoticed. > > Does anyone have ideas how to deal with these packages? > > I wonder if it would make sense to just drop them before F21. Having > broken dependencies basically means that the packages are completely > broken and cannot be installed at all. Not much point in shipping those > in the repositories ... > > Any ideas how to deal with this? Here's a quick look at some of them. Note that I'm not a provenpackager, so I can't actually do anything about it myself. ## libint soname bump >> [PyQuante] >> PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = >> 0:1.1.6-2.fc21 This can just be rebuilt: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881637 >> [cp2k] >> cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 >> cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = >> 0:1.1.6-2.fc21 >> cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 >> cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = >> 0:1.1.6-2.fc21 This hasn't finished building yet, but it seems ok so far: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881650 ## json-c soname bump >> [authhub] >> authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 This fails to build: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881643 ## rbtorrent soname bump >> [fatrat] >> 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires >> libtorrent-rasterbar.so.7 Seems this will need some upstream work: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881660 >> [flush] >> flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 So does this: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881679 ## ocaml-camlp4 update The dep was updated: $ repoquery --provides ocaml-camlp4 ocaml(Camlp4) = 315363230d084ceb1cc5e85bfe2bfd49 >> [cduce] >> cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = >> 0:ebd368022fd2bc7b305a42902efa4c90 This fails to rebuild: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881630 >> [ocaml-pa-do] >> ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = >> 0:ebd368022fd2bc7b305a42902efa4c90 This fails to rebuild: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881760 ## vala update >> [gedit-valencia] >> gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires >> libvala-0.24.so.0 This fails to build: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881927 However, there's a new upstream release which might fix the problem. >> [monodevelop-vala] >> monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala < 0:0.25.0 This fails to build: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881961 However, there's a new upstream release which might fix the problem. >> [valabind] >> valabind-0.7.4-4.fc21.armv7hl requires libvala-0.24.so.0 This fails to build: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881954 However, there's a new upstream release which might fix the problem. ## Django 1.4 retired >> [django-recaptcha] >> django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 >> [openslides] >> openslides-1.3.1-3.fc21.noarch requires python-django < 0:1.5 >> [pootle] >> pootle-2.1.6-8.fc21.noarch requires python-django14 >> [python-coffin] >> python-coffin-0.3.7-3.fc21.noarch requires python-django14 >> [python-django-addons] >> python-django-addons-0.6.6-2.fc21.noarch requires python-django14 >> [python-django-longerusername] >> python-django-longerusername-0.4-5.20130204gite4e85d7d.fc21.noarch >> requires python-django14 >> [transifex] >> transifex-1.2.1-12.fc21.noarch requires python-django14 Django 1.4 has been retired: https://lists.fedoraproject.org/pipermail/devel/2014-September/202593.html >> [python-askbot-fedmsg] >> python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot Askbot was retired in f21 and master: https://lists.fedoraproject.org/pipermail/devel/2014-September/202687.html >> [audtty] >> audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 Seems libaudclient was part of audacious but has then been removed upstream: http://audacious-media-player.org/download ## Unknown cases >> [edelib] >> edelib-2.1-5.fc21.armv7hl requires libedelib.so >> edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so This is weird, edelib provides libedelib.so.2.1.0, but somehow it requires libedelib.so Could it be the rpmbuild automatic requires generator misbehaved? >> [avro] >> avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce >> avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client >> [spr
Re: man-db without cache update (no cron or systemd *.timer)
On Thu, 2014-10-16 at 13:34 +0200, Jan Chaloupka wrote:
> On 10/16/2014 12:56 PM, Vít Ondruch wrote:
> > Dne 16.10.2014 v 10:35 Jan Chaloupka napsal(a):
> >> Forwarding Colin's response
[... snip ...]
> >> Have you considered installing the timer file, but without the
> >> dependency? If systemd is there, it could use it, otherwise not. That
> >> would make a whole lot more sense to me than creating another package,
> >> and would be my recommendation.
>
> This did not crossed my mind.
>
> > Actually that is good idea IMO. The %post script could silently fail if
> > no systemd is no the system.
>
> Agree with Vita, this sound very good to me. Made a test build and it is
> working fine.
But it's contrary to the guidelines, as you're installing the unit file
in %{_unitdir}, without requiring systemd to own this directory.
Which goes back to the idea of either moving %{_unitdir} to the
filesystem package, or having a systemd-filesystem package...
--
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-EV/f21] Update to 4.18
commit 89cd6ed077a532bec7b4d1a00e4047cdb7d23803
Author: Mathieu Bridon
Date: Sat Sep 6 23:05:55 2014 +0200
Update to 4.18
.gitignore |1 +
perl-EV.spec |8 +---
sources |2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 23d6200..2a892af 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
*.swp
/EV-4.03.tar.gz
/EV-4.11.tar.gz
+/EV-4.18.tar.gz
diff --git a/perl-EV.spec b/perl-EV.spec
index 82d6e56..66fb843 100644
--- a/perl-EV.spec
+++ b/perl-EV.spec
@@ -1,6 +1,6 @@
Name: perl-EV
-Version:4.11
-Release:6%{?dist}
+Version:4.18
+Release:1%{?dist}
Summary:Wrapper for the libev high-performance event loop library
# Note: The source archive includes a libev/ folder which contents are licensed
@@ -68,11 +68,13 @@ make test
%{perl_vendorarch}/auto/*
%{perl_vendorarch}/EV.pm
%{perl_vendorarch}/EV
-%{perl_vendorarch}/EV/*.h
%{_mandir}/man3/*.3*
%changelog
+* Tue Sep 30 2014 Mathieu Bridon - 4.18-1
+- Update to 4.18
+
* Sun Aug 17 2014 Fedora Release Engineering
- 4.11-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild
diff --git a/sources b/sources
index 3370188..15c851f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-405c6d74f9dff12918b12560c1a57877 EV-4.11.tar.gz
+5931d0ba91f93b95723e80d573da606f EV-4.18.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: splitting a subpackage to proper package process
On Thu, 2014-09-11 at 13:54 +0200, Nikos Mavrogiannopoulos wrote: > On Thu, 2014-09-11 at 12:25 +0200, Michael Schwendt wrote: > > On Thu, 11 Sep 2014 12:15:49 +0200, Nikos Mavrogiannopoulos wrote: > > > > > Hello, > > > There is a package which includes a subpackage that I'd like it split > > > as a proper package (possibly with different maintainers). Is there some > > > special process for that or does it have to follow the full process for > > > new packages as in [0]? > > > > > > regards, > > > Nikos > > > > > > [0]. > > > https://fedoraproject.org/wiki/New_package_process_for_existing_contributors > > > > You could/should have given more details, which would make it easier to > > answer. > > I'd like to split vpnc-script from vpnc [0], but I don't maintain the > package, so I omitted the details. Anyway the issue is, that vpnc-script > which has a different upstream [1] than vpnc, is used by both vpnc and > openconnect, and is part of the vpnc package. For that I'd like it split > from vpnc and being a separate package, so I can help maintain it > without maintaining vpnc which I have no idea about (the issue started > when vpnc was not in epel7 and that prevented openconnect from being > there). > > [0]. https://bugzilla.redhat.com/show_bug.cgi?id=1128147 > [1]. > http://git.infradead.org/users/dwmw2/vpnc-scripts.git/blob_plain/HEAD:/vpnc-script > > >Usually, everything from one _source tarball_ is included in a _single_ > > src.rpm, so you split the build into subpackages. Once upstream splits off > > something into a separate tarball, it may be time to create another src.rpm > > for it. There is no strict requirement to do so, however, because RPM can > > handle multiple source archives per src.rpm. It may be more convenient to > > create multiple src.rpm packages depending on how often the individual > > pieces are updated/upgraded/rebuilt. And yes, [0] applies to new packages. > > Ok, but on this case we have both vpnc and vpnc-script from vpnc.spec. > If vpnc-script becomes a separate package (with its own repository), > does it qualify as new package? In this context, « new package » means any new source package, which is equivalent to any new spec file, or any new git module, etc... So yes, that is the very same process. -- Mathieu -- 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: Issue during generating header files
Hi, On Mon, 2014-09-01 at 19:03 +0200, Antonio Trande wrote: > Hi all. > > I don't understand why same code is not compiled with rpmbuild unlike > when I compile in local. > > This is compiled with rpmbuild: http://fpaste.org/130139/ This does: ./configure ... --enable-liblua > This is compiled in local: http://fpaste.org/130141/ This does: ./configure ... --enable-libclua Note "liblua" vs "libclua" Could that be the cause of your problem? -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: are compiler flags being honored?
On Tue, 2014-08-12 at 15:26 +0200, Dhiru Kholia wrote: > Now, I need your feedback and cool ideas to improve this project :-) So first, this is great! However, the results.txt is very hard to use in order to check if maintainers need to do something. How about instead, splitting the results into one file per srpm? Also, maybe in the long-term integrate that somehow with Taskotron, so that the check is run after every build? (or at least for every Bodhi update) -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to restart dbus service?
On Thu, 2014-07-17 at 10:24 -0400, Matthias Clasen wrote: > On Thu, 2014-07-17 at 16:21 +0200, Mathieu Bridon wrote: > > On Thu, 2014-07-17 at 16:11 +0200, Miroslav Suchý wrote: > > > Hi, > > > how can I restart dbus service, registered via systemd unit? > > > > > > To be specific, I have in system: > > > /usr/share/dbus-1/services/org.a11y.atspi.Registry.service > > > with: > > > [D-BUS Service] > > > Name=org.a11y.atspi.Registry > > > Exec=/usr/libexec/at-spi2-registryd --use-gnome-session > > > > That service should instead have a SystemdService= key, with the name of > > the systemd unit as its value. (then Exec= becomes completely unused) > > > > Without this (and the actual systemd unit), the service is completely > > unknown by systemd, so it can't restart it. > > > > This is a session service, so systemd is not in the picture (yet). Ah, right, I misread and read the path as .../system-services/... -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to restart dbus service?
On Thu, 2014-07-17 at 16:11 +0200, Miroslav Suchý wrote: > Hi, > how can I restart dbus service, registered via systemd unit? > > To be specific, I have in system: > /usr/share/dbus-1/services/org.a11y.atspi.Registry.service > with: > [D-BUS Service] > Name=org.a11y.atspi.Registry > Exec=/usr/libexec/at-spi2-registryd --use-gnome-session That service should instead have a SystemdService= key, with the name of the systemd unit as its value. (then Exec= becomes completely unused) Without this (and the actual systemd unit), the service is completely unknown by systemd, so it can't restart it. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Is fedpkg designed to be usable for online only?
On Thu, 2014-07-17 at 10:09 +0800, Christopher Meng wrote: > Hi, > > After using the new pkgdb2 API based fedpkg, I'd like to ask a question here: > > Is fedpkg designed to be usable when online only? > > > > Well.. > > If I cut disable my connection, fedpkg switch-branch doesn't work: > > Could not execute switch_branch: len([]) != len(['ssh: Could not > resolve hostname pkgs.fedoraproject.org: Name or service not known', > '', '', 'and the repository exists.']) > ERROR:rpkg:Could not execute switch_branch: len([]) != len(['ssh: > Could not resolve hostname pkgs.fedoraproject.org: Name or service not > known', '', '', 'and the repository exists.']) Off the top of my head, one thing it needs an online access for, is determining what Fedora release corresponds to the "master" branch. It does that by querying Koji (or maybe pkgdb2 now, not sure) There are probably many things which won't require an internet connection, and we could make these work if they don't already. But for example, how do you propose solving the point I mentioned? -- Mathieu -- 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 Mon, 2014-06-23 at 19:07 +0200, drago01 wrote: > On Mon, Jun 23, 2014 at 7:01 PM, Reindl Harald wrote: > > > > > > Am 23.06.2014 18:47, schrieb Chris Adams: > >> Once upon a time, Bruno Wolff III said: > >>> Try yum update when the oldest installed kernel (and the running > >>> kernel) is the only one that works and there is a new (still broken > >>> for your system) kernel update available. In that case one really > >>> wouldn't expect the running kernel be removed. Having to remove a > >>> specific kernel before doing an update (to make sure the wrong one > >>> wasn't removed) would be a pain. > >> > >> I guess I never considered it a pain. That's exactly what I would do if > >> I knew a particular kernel was broken (remove specifically the broken > >> kernel). I never knew yum/a yum plugin/whatever did "magic" stuff based > >> on the running kernel, trying to remove "special" packages like yum, > >> etc. > > > > be glad that you learned something new :-) > > > > > >> I have no problem with GUI tools having magic protections built in, but > >> I prefer CLI tools that don't try to out-think me. yum/dnf already asks > >> for confirmation (which is more than up2date did); having additional > >> layers of protection/confirmation/whatever built-in seems excessive to > >> me. > > > > in general - agreed > > > > but not if it comes to destory the complete setup > > > >> It looks like there isn't even a way to override this behavior in yum. > >> I haven't wanted to remove all the kernels in a while (I guess since > >> before this was added); is the only way to bypass yum and use rpm? > > > > yes - simply because the chance that soemone wants to uninstall all > > kernels, yum, dnf and finalyl rpm itself is very low > > You still did not give a simple case why someone with some sanity left > would do "yum remove rpm" or "yum remove yum" ... One thing I've seen a few times at the time Yum didn't have that protection was « I don't do development, so I can remove Python » It did lead to a few people not having Yum installed any more. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
On Tue, 2014-06-17 at 16:37 -0400, Peter Jones wrote: > On Tue, Jun 17, 2014 at 02:40:45PM -0500, Dennis Gilmore wrote: > > I am not away of any work to make mock use dnf. dnf will > > need to be able to make mock chroots going all the way back to rhel5 > > since we use mock in the buildsystem and we build epel5 there. > > Wait, why will it need to do that? The chroots appear to be compatible, > unless I've missed something major. So creating them with the RHEL 5 > host's yum should work, I hope. Is there a something I've missed? The host might not be RHEL 5, it could be Fedora 22. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning most of my packages
On Thu, 2014-04-24 at 14:46 +0200, Stanislav Ochotnicky wrote: > I am doing spring cleanup and getting rid of most of my packages. The > full list is a bit too long (mizdebsk agreed to take over all of my Maven > related packages as primary maintainer). Here's the remaining bits that > need a new home: > > * python-gudev Isn't that obsoleted by the GObject-Introspection bindings? >>> from gi.repository import GUdev >>> -- Mathieu -- 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: libreoffice broken again in updates-testing
On Thu, 2014-04-17 at 16:24 +0200, Reindl Harald wrote: > and before you tell me now about outdated mirrors - no, see repo-file below > what you are installing *now* don't matter, *now* 4.2.3.3-4 is in the repo > starting with tuesday evening until today the broken one was > > to make it short: i can handle yum and repos > > [root@rh:~]$ cat /etc/yum.repos.d/fedora-updates.repo > [updates] > name=Fedora $releasever - $basearch - Updates > failovermethod=priority > baseurl=https://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/ Just thought I'd let you know: download.fedoraproject.org is in fact an alias that redirects you to a mirror. That doesn't change anything about your main point (that the update wasn't pushed yet when you were trying but had been before Sergio replied), but it would still be theoretically possible for you to get sent to an outdated mirror, just like using mirrorlist. -- Mathieu -- 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On Wed, 2014-03-26 at 08:27 +0100, Robert Mayr wrote: > > Il 21/mar/2014 12:59 "Matthew Miller" ha > scritto: > > > > On Fri, Mar 21, 2014 at 10:28:26AM +0100, Marcela Mašláňová wrote: > > > I agree with Jaroslav. I was looking forward to have a fourth > > > product to those three. KDE can help define what is needed for new > > > product, what must be done by all teams, how much work it will be > > > ... I guess we should speak more about addition of new product and > > > don't kill the idea at the start. > > > > Like I said, I'm skeptical, but listening. :) > > > > -- > > Matthew Miller-- Fedora Project-- > > > I think the same, if all spins become products we can also keep the > actual way. Fedora.next is a very good idea and I'm sure it will have > success, but it needs to follow his strategy with three different > products, not having 2 different ones and *n* > workstation-similar-products, IMHO. > > I don't think spins are not useful, but they could be under the wing > of Workstation as a sub-product perhaps. Some spins won't be desktop-related. Maybe what we'd need is something like AUR where users contribute packages for Arch Linux which are not "supported" enough to be in the main repositories? We could have the official 3 (for now) products, and a different "place" where the wider community can gather to publish different images, each one with a different focus (e.g a KDE desktop, or a tailor-made cloud image for a new provider, or an arch-specific image for a yet-unsupported device, or...) We could even call that "place" spins.fedoraproject.org ;) It could be more open than the current spins process, allowing a wider community to publish more varied things than we have now (more spins!), and it would be up to each group to ensure the quality of what they produce, have their own release cycle, etc... -- Mathieu -- 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: Retired update still showing in updates-testing
On Thu, 2014-03-13 at 09:41 +0100, Simone Caronni wrote: > On 13 March 2014 09:33, Mathieu Bridon > wrote: > The solution is for you to untag the builds: > > $ koji untag-pkg f19-updates-testing > guacamole-client-0.8.3-5.fc19 > $ koji untag-pkg f20-updates-testing > guacamole-client-0.8.3-5.fc20 > > Then at the next mash, they will be gone. > > I have no idea why they are still tagged, though. Maybe you > removed the > updates while the builds were being pushed, which tends to > trip Bodhi > up. > > Or maybe you hit a Bodhi bug. > > Thanks, I've already tried it but I can't tag/untag packages in Bodhi: > > $ koji untag-pkg f19-updates-testing guacamole-client-0.8.3-5.fc19 > ActionNotAllowed: tag requires admin permission > > I think some admin intervention is needed. Ah, right... Open a rel-eng ticket, then. :) https://fedorahosted.org/rel-eng/newticket -- Mathieu -- 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: Retired update still showing in updates-testing
On Thu, 2014-03-13 at 09:23 +0100, Simone Caronni wrote: > The packages are these two: > > guacamole-client-0.8.3-5.fc20 > guacamole-client-0.8.3-5.fc19 > > Can someone explain what has happened? Should I file a ticket > somewhere? The builds are still tagged as testing, which is why they appear in the repositories: http://koji.fedoraproject.org/koji/buildinfo?buildID=500690 http://koji.fedoraproject.org/koji/buildinfo?buildID=500691 The solution is for you to untag the builds: $ koji untag-pkg f19-updates-testing guacamole-client-0.8.3-5.fc19 $ koji untag-pkg f20-updates-testing guacamole-client-0.8.3-5.fc20 Then at the next mash, they will be gone. I have no idea why they are still tagged, though. Maybe you removed the updates while the builds were being pushed, which tends to trip Bodhi up. Or maybe you hit a Bodhi bug. -- Mathieu -- 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 which require the kernel package
On Mon, 2014-03-10 at 15:22 -0400, Matthew Miller wrote: > ipset Fixed in Rawhide: ipset-6.21.1-2.fc21 -- Mathieu -- 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: fedpkg build failing (due to NSS?)
On Mon, 2014-03-03 at 08:26 +, Peter Robinson wrote: > >>> I've left a negative karma there, they forgot to add the new nss-util > >>> into overrides list. > >> > >> No, it's been added, but then it was expired: > >> https://admin.fedoraproject.org/updates/override/edit?build=nss-util-3.15.5-1.fc20 > >> https://admin.fedoraproject.org/updates/override/edit?build=nss-softokn-3.15.5-1.fc20 > >> > >> That's not the problem at all. > >> > >> The problem is that **some** of these 3 overrides were epired, but not > >> all. > >> > >> The three packages need to always be in overrides together, or none of > >> them. > >> > >> Leaving a negative karma to the update won't help fix the problem > >> either. > > > > At least they can get the news IMO. > > That is completely the wrong way to communicate this and it doesn't > "get them the news" and in fact often stops people getting critical > security or stability fixes for a pathetic little game. The way to > communicate this problem is by the mailing lists/email/IRC etc... IE > proper communication channels. To try to communicate by putting > negative karma on updates that have nothing what so ever to do with > actual update needs to stop. In addition, we've been talking about it on #fedora-admin for the past hour, and Remi already notified via email the nss maintainer. Christopher, remember that you and I are in APAC, which means we are already awake when the nss maintainer (in the US) is still sleeping, so he won't "get the news" instantly. Finally, Pierre-Yves just extended the two already expired buildroot overrides, which should fix the problem soon. This would tell you when it's ready: $ koji wait-repo f20-build --build=nss-softokn-3.15.5-1.fc20 --build=nss-util-3.15.5-1.fc20 -- Mathieu -- 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: fedpkg build failing (due to NSS?)
On Mon, 2014-03-03 at 16:06 +0800, Christopher Meng wrote: > I've left a negative karma there, they forgot to add the new nss-util > into overrides list. No, it's been added, but then it was expired: https://admin.fedoraproject.org/updates/override/edit?build=nss-util-3.15.5-1.fc20 https://admin.fedoraproject.org/updates/override/edit?build=nss-softokn-3.15.5-1.fc20 That's not the problem at all. The problem is that **some** of these 3 overrides were epired, but not all. The three packages need to always be in overrides together, or none of them. Leaving a negative karma to the update won't help fix the problem either. -- Mathieu -- 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: fedpkg build failing (due to NSS?)
On Mon, 2014-03-03 at 08:56 +0100, Nikos Mavrogiannopoulos wrote: > Hello, > I'm trying to make an update for #1071795 using 'fedpkg build' for > gnutls fails consistently for f20 and rawhide with the error: > "BuildrootError: could not init mock buildroot, mock exited with status > 30; see root.log for more information" Remi already reported in #fedora-admin that the F20 buildroot was broken. What seems to have happened is that we still have some buildroot overrides: https://admin.fedoraproject.org/updates/override/list If you look, nss is still tagged as an override for F20, but without nss-util and nss-softokn. Someone with the right permissions (e.g the nss maintainer, or possibly releng) needs to expire this buildroot override. -- Mathieu -- 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: Schedule for Wednesday's FESCo Meeting (2014-02-26)
On Tue, 2014-02-25 at 20:13 -0700, Kevin Fenzi wrote: > If you would like to add something to this agenda, you can reply to > this e-mail, file a new ticket at https://fedorahosted.org/fesco, > e-mail me directly, or bring it up at the end of the meeting, during > the open floor topic. Note that added topics may be deferred until > the following meeting. If there's still time after the other ones, could you discuss ticket 1238? #topic ticket #1238 Should Bodhi reset karma to 0 when builds are changed? .fesco 1238 https://fedorahosted.org/fesco/ticket/1238 Thanks, -- Mathieu -- 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: exclude people from giving karma?
On Sun, 2014-02-23 at 18:36 +0100, drago01 wrote: > On Sun, Feb 23, 2014 at 6:35 PM, Michel Alexandre Salim > wrote: > > One potential workflow bug with this karmic automatic-push-to-stable: under > > the normal time-delayed path, any editing of the build reverts the package > > set to pending. Yet if the package set is being pushed to stable thanks to > > meeting the karma threshold, editing the build seems to have no effect (from > > the log in the link given, bodhi automatically triggers a push within 4 > > seconds, meaning the edited package set is basically never tested) > > > > What would be a good solution here -- invalidate the karma votes? > > Yes because obviously the karma has been given based on testing a > different build. For what is worth, this is exactly what we do at $dayjob with our own Bodhi instance. Which means I already have a patch if we wanted to do that in Fedora too. Does this kind of change need to go through FESCo? -- Mathieu -- 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: Drawing lessons from fatal SELinux bug #1054350
On Mon, 2014-01-27 at 15:11 -0700, Kevin Fenzi wrote: > On Mon, 27 Jan 2014 10:18:56 -0500 > Matthew Miller wrote: > > snip > > > * possibly adding a "what should users test?" field to the update > > info. > > > > I know that there's a "notes" field in the update, but maybe it'd > > help to explicitly include testing instructions? > > > > Each package in the pkgdb (or in git, or wherever) could have > > a standard list included in each update as the default (for > > example, for 'calc', it might be to try `calc -q > > read /usr/share/calc/regress.cal`. That would duplicate a likely > > smoke-test, though, so maybe also "run interactively and make sure > > basic math works". > > > Then, each update could also optionally (and this would be > > presented in bold if it were used) say something like "New release > > adds log() function; please test that it works", or "Severe bug where > > 1+1=3 corrected; please test that the answer now corresponds with > > consensus reality." > > I could have sworn we already had something like this where bodhi would > add a link to a wiki page for test plan on a package if that wiki page > existed. I can't seem to find it now, so perhaps it was just something > we talked about, but never implemented. Nope, you're right. :) https://github.com/fedora-infra/bodhi/blob/develop/bodhi/model.py#L191 For example, the test case pages for the package 'foo' need to be added to the 'Category:Package foo test cases' category. There's also an option in the config file which must be switched on for this to work: 'query_wiki_test_cases' And here is an update where this is, in fact, actually used: https://admin.fedoraproject.org/updates/FEDORA-2014-1465/ -- Mathieu -- 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: Shipping package metadata in a package
Hi, On Fri, 2014-01-24 at 10:01 +, Richard Hughes wrote: > There are two ways to fix the jarring UX. We could either ship the > fedora package metadata pre-prepared in PackageKit, maybe using > something like %ghost so the new metadata is ignored. The other way is > to start the metadata downloading in the initial-start wizard thing, > although in practice the download takes a couple of minutes to > complete, and the wizard typically takes much less than that before > the user has configured everything. The downside to shipping prepared > metadata is that the package size is larger, and that the metadata > would be *very* out of date after a year or so. Rather than during the initial setup thing, why not start it at first boot, much earlier? Another option would be to have it done as the last step of the installer. -- Mathieu -- 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 Mon, 2013-12-16 at 01:47 -0700, T.C. Hollingsworth wrote:
> On Mon, Dec 16, 2013 at 1:11 AM, Martin Stransky wrote:
> > There are some cases when we need it (sources taken as a snapshot from
> > git/cvs)
>
> Huh? The sources have to be either in git or in the lookaside cache
> for koji to find them later. I'm not sure how it could get this
> wrong?
>
> > patches applied by different way.
>
> How else can you apply patches listed on PatchN lines? It already
> covers %patchN, %{patches}, and now %autosetup. If there's something
> else, I'd really like to know.
The kernel package uses a custom-defined ApplyPatch macro, for example.
--
Mathieu
--
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: [pkgdb2] call for testers, bug reports and RFE
On Thu, 2013-12-12 at 09:02 +0100, Matthias Runge wrote: > On 12/12/2013 04:19 AM, Mathieu Bridon wrote: > > On Wed, 2013-12-11 at 17:18 +0100, Matthias Runge wrote: > >> The idea behind is: > >> > >> you have some application with an issue/error. You'll do rpm -qf > >> and will get a package name, not necessarily the source > >> package name. > >> When filing a bug against a package, you'll need to know the source > >> package name. > > > > rpm -qi gives you the source package. > > > > > So, why do we hide it this way? > > How is a new user or a GUI-only person Well, you were talking about someone who had just used rpm -qf, so in that context rpm -qi made a lot of sense. > able to find the right package to > file a bug against? A nasty person might even say: this is by purpose ;-) As far as I know, pkgdb is not targeted at end users but at package maintainers (as it handles the ACLs on packages). /packages is more targeted at users, and it does show what is the base package for a given subpackage. For example: https://apps.fedoraproject.org/packages/libcangjie-devel In case you miss the "Subpackage of XXX", you can just click on the "Bugzilla" link, which will open a bug against the proper base package. You could argue that the two apps should be only one, but that's a different discussion. (and the people actually doing the work to implement and maintain those apps feel that it's better to separate them) -- Mathieu -- 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: [pkgdb2] call for testers, bug reports and RFE
On Wed, 2013-12-11 at 17:18 +0100, Matthias Runge wrote: > The idea behind is: > > you have some application with an issue/error. You'll do rpm -qf > and will get a package name, not necessarily the source > package name. > When filing a bug against a package, you'll need to know the source > package name. rpm -qi gives you the source package. -- Mathieu -- 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: crazy /usr/lib/event.h (was: Packaging changes for libev in Rawhide)
On Tue, 2013-12-03 at 22:13 -0500, Rahul Sundaram wrote: > Hi > On Tue, Dec 3, 2013 at 9:47 PM, Gilles J. Seguin wrote: > > OMG > i do not know what to say here > /usr/lib/event.h > -1 should -1,000,000,000 > > :-) > i need a list of peoples making such uninspired suggestions > > Even with a smiley, you haven't really added anything useful to the > discussion. -1 or -1 million makes no difference whatsoever. The > maintainer making the change has listed out his rationale. If you > want to present yours, feel free to do so (without breaking the thread > unnecessarily). Anything else is just noise. In addition, I feel it's worth mentioning that nobody in this thread ever suggested that /usr/lib/event.h would be a good idea... or even an idea at all. -- Mathieu -- 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: VOB
On Thu, 2013-11-28 at 07:59 +0100, Johannes Lips wrote: > On Thu, Nov 28, 2013 at 12:36 AM, Richard Vickery > wrote: > Being on the test kernel - or, more likely, using a more > stable one from the list that is compiled - is probably the > answer to the issue: how am I to watch a VOB file? > > This has nothing to do with the kernel and especially not with the > -devel list. Please just use the search engine you prefer to find out > how to play VOB files Or alternatively, feel free to ask your question(s) in a more appropriate forum. :) https://ask.fedoraproject.org/ -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
