How to get packager sponsorship

[Michael Schwendt]

Some thoughts:

  http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html
  http://fedoraproject.org/PackageReviewStatus/

  http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

There is a growing number of people in the NEEDSPONSOR queue, who have
submitted a single package only and who don't attempt at doing a review of
a different package in the various queues (not even a review of the own
package).

Many packager sponsors consider that a problem. I'm not the spokesperson
of all packager sponsors, though. ;)

It is not mandatory to hang out on IRC in hope of getting to know packager
sponsors. Not all packager sponsors hang out on IRC either. So, what may
work for some people may be seen as a hindrance by other new packagers.

Following the various options in the HOWTO and searching the Fedora
Account System (FAS) for packager sponsors has worked before, but requires
a minimum amount of activity prior to contacting a packager sponsor
privately.

I highly recommend people in the NEEDSPONSOR queue to attempt at reviewing
other packages in the NEW queue and to show at least some motivation.
Especially if the self-submitted package is not free of packaging mistakes.
Use the help of tools, such as "fedora-review". Mention whether you've
looked at mock and koji already. Please don't sit and wait for a sponsor
for months without even trying to do a self-review of your own package.
-- 
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 get packager sponsorship

[Jochen Schmitt]

On Sun, Jan 12, 2014 at 10:29:54AM +0100, Michael Schwendt wrote:

> There is a growing number of people in the NEEDSPONSOR queue, who have
> submitted a single package only and who don't attempt at doing a review of
> a different package in the various queues (not even a review of the own
> package).

Review your own package?

I think the aim of the review process is, that a second one should have
a look on your package to verify, that your package mmets the package
guidelines and so on.

Most people may be blind against thier onw mistakes, so it makes sense
that anonther one take a look on the package which should introduced 
to Fedora.

Best Regards:

Jochen Schmitt
-- 
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 get packager sponsorship

[Christopher Meng]

Sometimes sponsorship is quite easy, this is unfair to other people around:

https://bugzilla.redhat.com/show_bug.cgi?id=1048966
-- 
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 get packager sponsorship

[पराग़]

Hi,

On Sun, Jan 12, 2014 at 3:46 PM, Jochen Schmitt wrote:

> On Sun, Jan 12, 2014 at 10:29:54AM +0100, Michael Schwendt wrote:
>
> > There is a growing number of people in the NEEDSPONSOR queue, who have
> > submitted a single package only and who don't attempt at doing a review
> of
> > a different package in the various queues (not even a review of the own
> > package).
>
> Review your own package?
>

New contributors can also review their own package and show what things
they found in their package like how they found they have correct upstream
source matching checksum, how they found license tag for their package,
what rpmlint output they found etc. This applies even for other packages
also waiting for review. But, here what Michael want to point out that
people waiting for their package review who are also waiting for
sponsorship should at least look into
http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html and provide
their review findings so that other people will come to know any issues in
their package and they can be updated/progressed further.


> I think the aim of the review process is, that a second one should have
> a look on your package to verify, that your package mmets the package
> guidelines and so on.
>
>
For a new contributor, if he submitted many packages then whichever package
first gets reviewed should get approved by sponsor member.



> Most people may be blind against thier onw mistakes, so it makes sense
> that anonther one take a look on the package which should introduced
> to Fedora.
>


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

rawhide report: 20140112 changes

[Fedora Rawhide Report]

Compose started at Sun Jan 12 05:15:07 UTC 2014

Broken deps for i386
--
[OpenEXR_CTL]
OpenEXR_CTL-1.0.1-16.fc20.i686 requires libImath.so.6
OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmThread.so.6
OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmImf.so.7
OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIexMath.so.6
OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIex.so.6
OpenEXR_CTL-1.0.1-16.fc20.i686 requires libHalf.so.6
OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmThread.so.6
OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmImf.so.7
OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIex.so.6
[OpenEXR_Viewers]
OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libImath-2_0.so.10
OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIlmThread-2_0.so.10
OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIlmImf-Imf_2_0.so.20
OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIexMath-2_0.so.10
OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIex-2_0.so.10
OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libHalf.so.10
[R-maanova]
R-maanova-1.30.0-2.fc20.i686 requires libRlapack.so
R-maanova-1.30.0-2.fc20.i686 requires libRblas.so
[derelict]
derelict-tcod-3-20.20130626gite70c293.fc20.i686 requires tcod
derelict-tcod-devel-3-20.20130626gite70c293.fc20.i686 requires tcod
[gpsdrive]
gpsdrive-2.11-20.fc20.i686 requires libgps.so.20
[gtkd]
gtkd-2.0.0-29.20120815git9ae9181.fc18.i686 requires libphobos-ldc.so.60
[httpdtap]
httpdtap-0.2-2.fc21.noarch requires kernel-debuginfo
httpdtap-0.2-2.fc21.noarch requires httpd-debuginfo
httpdtap-0.2-2.fc21.noarch requires apr-util-debuginfo
httpdtap-0.2-2.fc21.noarch requires apr-debuginfo
[kawa]
1:kawa-1.11-5.fc19.i686 requires servlet25
[koji]
koji-vm-1.8.0-2.fc20.noarch requires python-virtinst
[libghemical]
libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3
libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3
[libopensync-plugin-irmc]
1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1
[mojomojo]
mojomojo-1.10-1.fc20.noarch requires 
perl(HTML::FormFu::Element::reCAPTCHA)
[mpqc]
mpqc-2.3.1-23.fc20.i686 requires libf77blas.so.3
mpqc-2.3.1-23.fc20.i686 requires libatlas.so.3
[netdisco]
netdisco-1.1-6.fc20.noarch requires perl(SNMP::Info::Layer2::Bay)
[nifti2dicom]
nifti2dicom-0.4.6-3.fc20.i686 requires libvtksys.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkWidgets.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkVolumeRendering.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkViews.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkTextAnalysis.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkRendering.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkParallel.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkInfovis.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkImaging.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkIO.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkHybrid.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkGraphics.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkGeovis.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkGenericFiltering.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkFiltering.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkCommon.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libvtkCharts.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libitksys-4.4.so.1
nifti2dicom-0.4.6-3.fc20.i686 requires libitkopenjpeg-4.4.so.1
nifti2dicom-0.4.6-3.fc20.i686 requires libitkdouble-conversion-4.4.so.1
nifti2dicom-0.4.6-3.fc20.i686 requires libitkNetlibSlatec-4.4.so.1
nifti2dicom-0.4.6-3.fc20.i686 requires libgdcmMSFF.so.2.2
nifti2dicom-0.4.6-3.fc20.i686 requires libgdcmDICT.so.2.2
nifti2dicom-0.4.6-3.fc20.i686 requires libQVTK.so.5.10
nifti2dicom-0.4.6-3.fc20.i686 requires libITKznz-4.4.so.1
nifti2dicom-0.4.6-3.fc20.i686 requires libITKniftiio-4.4.so.1
nifti2dicom-0.4.6-3.fc20.i686 requires libITKgiftiio-4.4.so.1
nifti2dicom-0.4.6-3.fc20.i686 requires libITKWatersheds-4.4.so.1
nifti2dicom-0.4.6-3.fc20.i686 requires libITKVtkGlue-4.4.so.1
nifti2dicom-0.4.6-3.fc20.i686 requires libITKVideoIO-4.4.so.1
nifti2dicom-0.4.6-3.fc20.i686 requires libITKVideoCore-4.4.so.1
nifti2dicom-0.4.6-3.fc20.i686 requires libITKVTK-4.4.so.1
nifti2dicom-0.4.6-3.fc20.i686 requires libITKVNLInstantiation-4.4.so.1
nifti2dicom-0.4.6-3.fc20.i686 requires libITKStatistics-4.4.so.1
nifti2dicom-0.4.6-3.fc20.i686 requires libITKSpatialObjects-4.4.

Re: How to get packager sponsorship

[Matthias Runge]

On 01/12/2014 10:29 AM, Michael Schwendt wrote:
> Some thoughts:
> 
>   http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html
>   http://fedoraproject.org/PackageReviewStatus/
> 
>   http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
> 
> There is a growing number of people in the NEEDSPONSOR queue, who have
> submitted a single package only and who don't attempt at doing a review of
> a different package in the various queues (not even a review of the own
> package).
> 
> Many packager sponsors consider that a problem. I'm not the spokesperson
> of all packager sponsors, though. ;)
> 
Yes, I share this concern. Doing informal reviews is a significant part
of getting sponsored. I'd expect packagers to review their own review
requests (just to be sure, the first review doesn't fail for quite
obvious reasons).

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

Why authconfig create -ac files

[Miroslav Suchy]

I just wonder why `authconfig` creates:
  /etc/pam.d/system-auth -> system-auth-ac
  /etc/pam.d/postlogin -> postlogin-ac
  /etc/pam.d/password-auth -> password-auth-ac
  etc.

Why those links and why -ac suffix? Why it does not modify original 
files directly?

Is there some story behind?

Mirek
--
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 get packager sponsorship

[Michael Schwendt]

On Sun, 12 Jan 2014 11:16:42 +0100, Jochen Schmitt wrote:

> > There is a growing number of people in the NEEDSPONSOR queue, who have
> > submitted a single package only and who don't attempt at doing a review of
> > a different package in the various queues (not even a review of the own
> > package).
> 
> Review your own package?

Of course! Everybody may review packages and even post the results.
Approving packages is something else.
 
> I think the aim of the review process is, that a second one should have
> a look on your package to verify, that your package mmets the package
> guidelines and so on.

Sure. That's the requirement for approval. You can only submit packages,
which meet the guidelines, if you review your own package. ;)
 
> Most people may be blind against thier onw mistakes, so it makes sense
> that anonther one take a look on the package which should introduced 
> to Fedora.

According to that theory, they would introduce the same mistakes once the
package has entered the collection, ... because there is no review process
for updates/upgrades anymore.
-- 
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-0.4.11

[Garry T. Williams]

On 1-9-14 15:43:50 Ales Kozumplik wrote:
> New DNF release is out. See the blog [1], the release notes [2] and
> the F20 update [3]. Rawhide build went smooth this time too!

I see this using 0.4.11.  What am I doing wrong?

garry@vfr$ sudo dnf --enablerepo=updates-testing update kernel\*
[sudo] password for garry:
Resolving dependencies
--> Starting dependency resolution
--> Finished dependency resolution
Dependencies resolved.
Nothing to do.
garry@vfr$ sudo yum --enablerepo=updates-testing update kernel\*
Loaded plugins: langpacks, refresh-packagekit
[snip]
Resolving Dependencies
--> Running transaction check
---> Package kernel.x86_64 0:3.12.7-300.fc20 will be installed
---> Package kernel-devel.x86_64 0:3.12.7-300.fc20 will be installed
---> Package kernel-headers.x86_64 0:3.12.6-300.fc20 will be updated
---> Package kernel-headers.x86_64 0:3.12.7-300.fc20 will be an update
--> Finished Dependency Resolution
--> Finding unneeded leftover dependencies
Found and removing 0 unneeded dependencies
--> Running transaction check
---> Package kernel.x86_64 0:3.11.8-200.fc19 will be erased
---> Package kernel-devel.x86_64 0:3.11.8-200.fc19 will be erased
--> Finished Dependency Resolution

Dependencies Resolved


 PackageArch   VersionRepository   Size

Installing:
 kernel x86_64 3.12.7-300.fc20updates-testing  30 M
 kernel-devel   x86_64 3.12.7-300.fc20updates-testing 8.5 M
Updating:
 kernel-headers x86_64 3.12.7-300.fc20updates-testing 913 k
Removing:
 kernel x86_64 3.11.8-200.fc19@updates/19 128 M
 kernel-devel   x86_64 3.11.8-200.fc19@updates/19  31 M

Transaction Summary

Install  2 Packages
Upgrade  1 Package
Remove   2 Packages

Total download size: 40 M
Is this ok [y/d/N]: n
Exiting on user command
Your transaction was saved, rerun it with:
 yum load-transaction /tmp/yum_save_tx.2014-01-12.11-20.aiCKeH.yumtx
garry@vfr$ sudo dnf clean all
Cleaning repos: fedora rpmfusion-free-updates adobe-linux-x86_64
  : rpmfusion-nonfree-updates rpmfusion-free updates google-chrome
  : rpmfusion-nonfree
Cleaning up Everything
garry@vfr$ sudo dnf --enablerepo=updates-testing upgrade kernel\*
Fedora 20 - x86_64  144 kB/s |  36 MB 04:14
RPM Fusion for Fedora 20 - Free - Updates97 kB/s |  72 kB 00:00
Adobe Systems Incorporated  8.7 kB/s | 1.8 kB 00:00
RPM Fusion for Fedora 20 - Nonfree - Updates 29 kB/s |  13 kB 00:00
RPM Fusion for Fedora 20 - Free 124 kB/s | 487 kB 00:03
Fedora 20 - x86_64 - Updates125 kB/s |  12 MB 01:38
google-chrome26 kB/s | 3.1 kB 00:00
RPM Fusion for Fedora 20 - Nonfree  113 kB/s | 289 kB 00:02
Resolving dependencies
--> Starting dependency resolution
--> Finished dependency resolution
Dependencies resolved.
Nothing to do.
garry@vfr$

-- 
Garry T. Williams

-- 
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-0.4.11

[Rahul Sundaram]

Hi


On Sun, Jan 12, 2014 at 11:30 AM, Garry T. Williams  wrote:

> On 1-9-14 15:43:50 Ales Kozumplik wrote:
> > New DNF release is out. See the blog [1], the release notes [2] and
> > the F20 update [3]. Rawhide build went smooth this time too!
>
> I see this using 0.4.11.  What am I doing wrong?
>

http://dnf.baseurl.org/2014/01/02/dnf-update-and-yum-update-produce-different-output/

Rahul
-- 
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-0.4.11

[Garry T. Williams]

On 1-12-14 11:39:35 Rahul Sundaram wrote:
> On Sun, Jan 12, 2014 at 11:30 AM, Garry T. Williams  wrote:
> > On 1-9-14 15:43:50 Ales Kozumplik wrote:
> > > New DNF release is out. See the blog [1], the release notes [2] and
> > > the F20 update [3]. Rawhide build went smooth this time too!
> >
> > I see this using 0.4.11.  What am I doing wrong?
> 
> http://dnf.baseurl.org/2014/01/02/dnf-update-and-yum-update-produce-different-output/

Yes, I have reviewed all that.  That reference says,

The bottom line is: unless a real update problem occurs (i.e. DNF
refuses to update a package that Yum updates) with the same set of
metadata (dnf clean all; yum clean all), this is not an issue.

I did dnf clean all and the updates-testing package is still not found
by dnf.

Hey, I'm just testing.  It looks like a bug, but I wanted to see if I
was overlooking something.

-- 
Garry T. Williams

-- 
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-0.4.11

[Reindl Harald]

Am 12.01.2014 18:43, schrieb Garry T. Williams:
> On 1-12-14 11:39:35 Rahul Sundaram wrote:
>> On Sun, Jan 12, 2014 at 11:30 AM, Garry T. Williams  wrote:
>>> On 1-9-14 15:43:50 Ales Kozumplik wrote:
 New DNF release is out. See the blog [1], the release notes [2] and
 the F20 update [3]. Rawhide build went smooth this time too!
>>>
>>> I see this using 0.4.11.  What am I doing wrong?
>>
>> http://dnf.baseurl.org/2014/01/02/dnf-update-and-yum-update-produce-different-output/
> 
> Yes, I have reviewed all that.  That reference says,
> 
> The bottom line is: unless a real update problem occurs (i.e. DNF
> refuses to update a package that Yum updates) with the same set of
> metadata (dnf clean all; yum clean all), this is not an issue.
> 
> I did dnf clean all and the updates-testing package is still not found
> by dnf.
> 
> Hey, I'm just testing.  It looks like a bug, but I wanted to see if I
> was overlooking something

if DNF for whatever reason is chosing a different mirror than
YUM you have exactly this - the same may happen with only YUM
and repeatly "rpm -rf /var/cache/yum/*; yum upgrade" by get
a different mirror each time



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Inter-WG coordination: Stable application runtimes

[Kevin Kofler]

Adam Williamson wrote:
> I'm coming to the conclusion that at some point distros have to give up
> swimming against the tide and just say, look, if this is the way this
> ecosystem wants to go, then it's your problem. Fedora's job for such
> ecosystems would simply be to make sure their distribution mechanism
> works on top of Fedora - if it's one we care about - and then butt out.
> I'm not sure we're achieving anything practical for anyone by bending
> PHP / Java / nodejs / Ruby packages 120 degrees out of shape to conform
> to Fedora's packaging guidelines (often at the cost that we have to turn
> stuff off, or break stuff, or be months or years behind upstream, or be
> massively incomplete), and I say this as someone who's spent the last
> couple of weeks whacking on a PHPland stack (Owncloud) with a wrench to
> achieve precisely that.

At that point, we can just close shop, we are no longer fulfilling our role 
as a distribution. I also agree completely with Nicolas Mailhot's reply: 
That is NOT what our users want!

Making the software conform to packaging best practices is exactly what we 
packagers are for. It is the only way to deploy software in a reliable, 
well-integrated, secure and space-efficient way. Having multiple competing 
deployment systems on the same machine invariably leads to integration 
issues (where the ones stacked on top can get surprised when a lower-level 
system changes or removes something like a system library, say because the 
user accidentally removed it, not knowing that something outside of the 
system package management requires it). And the security and disk space 
implications of bundling have been discussed many times already.

So, like Matthew Miller, I think we cannot possibly punt on this issue, but 
I totally DISAGREE with his proposed solution of endorsing those bundling 
systems officially. Instead, we need to continue packaging things properly.

Kevin Kofler

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

Re: dnf-0.4.11

[M A Young]

On Sun, 12 Jan 2014, Garry T. Williams wrote:


On 1-9-14 15:43:50 Ales Kozumplik wrote:

New DNF release is out. See the blog [1], the release notes [2] and
the F20 update [3]. Rawhide build went smooth this time too!


I see this using 0.4.11.  What am I doing wrong?

garry@vfr$ sudo dnf --enablerepo=updates-testing update kernel\*
[sudo] password for garry:
Resolving dependencies
--> Starting dependency resolution
--> Finished dependency resolution
Dependencies resolved.
Nothing to do.


Try
dnf clean expire-cache
first. I don't think dnf checks whether its metadata is up to date as 
frequently as yum does.


Michael Young
--
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: Inter-WG coordination: Stable application runtimes

[Adam Williamson]

On Sun, 2014-01-12 at 18:55 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > I'm coming to the conclusion that at some point distros have to give up
> > swimming against the tide and just say, look, if this is the way this
> > ecosystem wants to go, then it's your problem. Fedora's job for such
> > ecosystems would simply be to make sure their distribution mechanism
> > works on top of Fedora - if it's one we care about - and then butt out.
> > I'm not sure we're achieving anything practical for anyone by bending
> > PHP / Java / nodejs / Ruby packages 120 degrees out of shape to conform
> > to Fedora's packaging guidelines (often at the cost that we have to turn
> > stuff off, or break stuff, or be months or years behind upstream, or be
> > massively incomplete), and I say this as someone who's spent the last
> > couple of weeks whacking on a PHPland stack (Owncloud) with a wrench to
> > achieve precisely that.
> 
> At that point, we can just close shop, we are no longer fulfilling our role 
> as a distribution. I also agree completely with Nicolas Mailhot's reply: 
> That is NOT what our users want!
> 
> Making the software conform to packaging best practices is exactly what we 
> packagers are for. It is the only way to deploy software in a reliable, 
> well-integrated, secure and space-efficient way. Having multiple competing 
> deployment systems on the same machine invariably leads to integration 
> issues (where the ones stacked on top can get surprised when a lower-level 
> system changes or removes something like a system library, say because the 
> user accidentally removed it, not knowing that something outside of the 
> system package management requires it). And the security and disk space 
> implications of bundling have been discussed many times already.
> 
> So, like Matthew Miller, I think we cannot possibly punt on this issue, but 
> I totally DISAGREE with his proposed solution of endorsing those bundling 
> systems officially. Instead, we need to continue packaging things properly.

Have you looked at what people are installing on Fedora lately? Have you
looked at how much PHP stuff there is out there vs. what we have
packaged 'properly'? Java? Ruby? Do you know anyone who deploys
Wordpress plugins via distribution packages?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

Re: Inter-WG coordination: Stable application runtimes

[Reindl Harald]

Am 12.01.2014 19:39, schrieb Adam Williamson:
> Have you looked at what people are installing on Fedora lately? Have you
> looked at how much PHP stuff there is out there vs. what we have
> packaged 'properly'? Java? Ruby? Do you know anyone who deploys
> Wordpress plugins via distribution packages?

that has other reasons

on a typical webserver you have not *the* wordpress and *the* wordpress
plugins - you have 10,20,30,100,500 *independent* wordpress setups

for production the only case where you can use distribution packages
is if you have a dedicated machines / VM serving only one website



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf-0.4.11

[Garry T. Williams]

On 1-12-14 18:18:00 M A Young wrote:
> On Sun, 12 Jan 2014, Garry T. Williams wrote:
> > On 1-9-14 15:43:50 Ales Kozumplik wrote:
> >> New DNF release is out. See the blog [1], the release notes [2] and
> >> the F20 update [3]. Rawhide build went smooth this time too!
> >
> > I see this using 0.4.11.  What am I doing wrong?
> >
> > garry@vfr$ sudo dnf --enablerepo=updates-testing update kernel\*
> > [sudo] password for garry:
> > Resolving dependencies
> > --> Starting dependency resolution
> > --> Finished dependency resolution
> > Dependencies resolved.
> > Nothing to do.
>
> Try
> dnf clean expire-cache
> first. I don't think dnf checks whether its metadata is up to date as
> frequently as yum does.

Ha!  That was it.

sudo dnf --enablerepo=updates-testing clean expire-cache
sudo dnf --enablerepo=updates-testing upgrade kernel\*

did the trick.

-- 
Garry T. Williams

-- 
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-0.4.11

[Ahmad Samir]

On 12 January 2014 21:06, Garry T. Williams  wrote:
> On 1-12-14 18:18:00 M A Young wrote:
>> On Sun, 12 Jan 2014, Garry T. Williams wrote:
>> > On 1-9-14 15:43:50 Ales Kozumplik wrote:
>> >> New DNF release is out. See the blog [1], the release notes [2] and
>> >> the F20 update [3]. Rawhide build went smooth this time too!
>> >
>> > I see this using 0.4.11.  What am I doing wrong?
>> >
>> > garry@vfr$ sudo dnf --enablerepo=updates-testing update kernel\*
>> > [sudo] password for garry:
>> > Resolving dependencies
>> > --> Starting dependency resolution
>> > --> Finished dependency resolution
>> > Dependencies resolved.
>> > Nothing to do.
>>
>> Try
>> dnf clean expire-cache
>> first. I don't think dnf checks whether its metadata is up to date as
>> frequently as yum does.
>
> Ha!  That was it.
>
> sudo dnf --enablerepo=updates-testing clean expire-cache
> sudo dnf --enablerepo=updates-testing upgrade kernel\*
>
> did the trick.
>

'dnf clean all' does what 'clean expire-cache' does, and more. (check
the man page)

It could be that dnf picked another mirror this time, or it used the
same mirror and that mirror has synced with the master mirror(s).

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



-- 
Ahmad Samir
-- 
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-0.4.11

[Reindl Harald]

Am 12.01.2014 20:24, schrieb Ahmad Samir:
> On 12 January 2014 21:06, Garry T. Williams  wrote:
>> On 1-12-14 18:18:00 M A Young wrote:
>>> On Sun, 12 Jan 2014, Garry T. Williams wrote:
 On 1-9-14 15:43:50 Ales Kozumplik wrote:
> New DNF release is out. See the blog [1], the release notes [2] and
> the F20 update [3]. Rawhide build went smooth this time too!

 I see this using 0.4.11.  What am I doing wrong?

 garry@vfr$ sudo dnf --enablerepo=updates-testing update kernel\*
 [sudo] password for garry:
 Resolving dependencies
 --> Starting dependency resolution
 --> Finished dependency resolution
 Dependencies resolved.
 Nothing to do.
>>>
>>> Try
>>> dnf clean expire-cache
>>> first. I don't think dnf checks whether its metadata is up to date as
>>> frequently as yum does.
>>
>> Ha!  That was it.
>>
>> sudo dnf --enablerepo=updates-testing clean expire-cache
>> sudo dnf --enablerepo=updates-testing upgrade kernel\*
>>
>> did the trick.
>>
> 
> 'dnf clean all' does what 'clean expire-cache' does, and more. (check
> the man page)

"dnf clean all" without "dnf --enablerepo=updates-testing clean all" does
exactly *nothing* in case of "updates-testing", the same for YUM simply
because folders of non-enabled repos are not relevant for any operation



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf-0.4.11

[Garry T. Williams]

On 1-12-14 11:30:31 you wrote:
> On 1-9-14 15:43:50 Ales Kozumplik wrote:
> > New DNF release is out. See the blog [1], the release notes [2] and
> > the F20 update [3]. Rawhide build went smooth this time too!
> 
> I see this using 0.4.11.  What am I doing wrong?

[snip]

> garry@vfr$ sudo dnf clean all
> Cleaning repos: fedora rpmfusion-free-updates adobe-linux-x86_64
>   : rpmfusion-nonfree-updates rpmfusion-free updates google-chrome
>   : rpmfusion-nonfree
> Cleaning up Everything
> garry@vfr$ sudo dnf --enablerepo=updates-testing upgrade kernel\*

The real problem was not including the updates-testing repo in the
clean all command.

And yes, as Michael commented, dnf doesn't expire meta-data as often
as yum.

-- 
Garry T. Williams

-- 
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-0.4.11

[Tom Hughes]

On 12/01/14 19:28, Garry T. Williams wrote:


And yes, as Michael commented, dnf doesn't expire meta-data as often
as yum.


It's quite a big difference as well - yum is 6 hours and dnf is 48 hours 
by default.


So if you're used to running update once a day then you'll find it will 
only work every other day with dnf... At least until you change the 
metadata_expire setting in dnf.conf.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
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: Inter-WG coordination: Stable application runtimes

[Till Maas]

On Sun, Jan 12, 2014 at 10:39:19AM -0800, Adam Williamson wrote:
> On Sun, 2014-01-12 at 18:55 +0100, Kevin Kofler wrote:

> > So, like Matthew Miller, I think we cannot possibly punt on this issue, but 
> > I totally DISAGREE with his proposed solution of endorsing those bundling 
> > systems officially. Instead, we need to continue packaging things properly.
> 
> Have you looked at what people are installing on Fedora lately? Have you
> looked at how much PHP stuff there is out there vs. what we have
> packaged 'properly'? Java? Ruby? Do you know anyone who deploys
> Wordpress plugins via distribution packages?

Even if people do it, it does not meant that it is the best way to do
it. Mixed packaging makes it a lot harder to properly update in case of
security vulnerabilities. E.g. instead of only checking/ensuring proper
RPM updates one need to check each distribution method for regular
updates. Is there even some tooling available to check/update all e.g.
rbenv or virtualenv setups properly?

Also it appears to me that non-Fedora packaged software is typically
less secure. For example, I heard that the upstream nginx packages are
not protected by ASLR but the Fedora packages are.  Additionally I doubt
that upstream usually considers selinux issues. I guess a lot of people
probably install wordpress with chmod 777 and within a webserver's
document root. Does it meant this is the superior way?

However, if multiple software requires different versions, then this
should be made possible e.g. within RPM or a different central packaging
tool to provide proper version tracking, central updates and uniform
build flags.

Regards
Till
-- 
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: Inter-WG coordination: Stable application runtimes

[Alek Paunov]

On 10.01.2014 21:12, Matthew Miller wrote:

On Thu, Jan 09, 2014 at 07:58:44PM -0800, Adam Williamson wrote:

So the question becomes, what is it appropriate for a distribution to do
in this situation? My personal opinion is that what's appropriate for a
distribution to do is also, happily, what's easiest for a distribution
to do: punt on it. Entirely punt on the whole thing.



And, this ultimately makes a better experience for users, because if
Fedora's included tools are aware of the native packaging system, we can do
things like system auditing, security alerts (if not updates), maybe even
integration with selinux policy. Basically, we don't hammer all of the
possible universe into the distribution model, and we don't include all of
the packages of everything in the base Fedora distribution as RPMs, but we
do include those ecosystems in the Fedora _Project_, including the tools and
documentation to make them feel natural.



Your expression " ... tools aware of the native packaging system"
and the Andrew comment about the pip behaviors above in the thread,
encouraged me to share my "big hammer of the DB plumber style" :-)
opinion on the problem.

TL;DR: What follows is SCC: An idea for optional DB and service which
caches bits from YumDB, the local state (RPMDB and /etc) plus the
"native" systems like NPM in the unified way for the purposes of
planning, resolving and performing system state transitions.

Initially I meant to say just few words to mark the possibility, but
obviously my English and talent for easy for reading and well focused
messages are both far from good, so the whole thing become too long and
I am going to split some additional notes into self replays - Excuses!

RPMDB and YumDB are two rich datasets present on every Fedora instance
representing respectively the local state and distribution+ state of the
package universe. '+' because +Fusion*, +COPRs, +LocalOrg, etc.
Unfortunately they are somewhat hidden in the dark, because lack of
interfaces - we even missing SVG or other explorer for the YumDB graph.

The (let think of them as "virtual") Maven DB, PyPI DB, NPM DB, LuaRocks
DB, etc, technically are subsets of YumDB (in sense richness of encoded
logical relations between the DB nodes used in their schemes - e.g. PyPI
DB, before the pip egg, do not knows which file from which module comes,
nor have the concept of higher than package NV granularity of the
requirement points - Provides and Requires in YumDB). Also, the
depsolving of the "native" packaging systems is less sophisticated than
both current yum and hawkey ones.

These observation naturally lead to the idea of SCC: System
Configuration Cache DB representing the merge of RPMDB, YumDB and e.g.
local pip egs, PyPI DB (if e.g. additional python modules/versions are
needed for the given deployment) where the depsolving could be shifted,
somewhat in the same fashion as Data warehouse solutions are used in the
enterprises for merging the significant datasets from various ERP
systems into single DB for interactive time reporting and decision
making.

I am using the term SCC (vs. e.g. UPMC: Unified Package Metadata Cache)
in attempt to cover a (paraphrased) Mirek question from the beginning of
the thread - "OK, we have Fedora and PyPI integrated, at one point of
the time for a given instance, the Fedora packaged module has been
chosen. What happens if we upgrade Fedora along with am incompatible
version this Python module for given installed service" - obviously we
need to register in the SCC the dependencies of the installed machine
roles with the same effect like Require clauses in the our packages, so
the SCC machinery to validate (with negative result in this described
case) the yum upgrade or to resolve the upgrade including installation
of newest available compatible version from PyPI as an alternative
provision during upgrade preparation.

Further, I think that ideally SCC should parse/absorb as much as
possible system object properties and relations from /etc (plus /lib and
/var configuration areas) to allow sysadmins and devops to inject rules
for effective use of these sets latter in the depsolving (and other DB
functionality). That said, the integration with OpenLMI, or even
implementing the whole thing under the OpenLMI umbrella, both seems
natural.

So, finally on that road we have:

- choice for good enough DB engine for SCC, query language, compiler
  [*], etc. design decisions like sync protocol and plugable data
  sources.

- Yum/RPM datasets: optional rpm, yum, hawkey hooks for syncing their
  DBs, alternatively just sync tools.

- optional pip, npm, luarocks, etc. hooks for the same, alternatively
  just sync tools.

- OpenLMI integration for absorbing system configuration, alternatively
  just Augeas import + transformation rules to sync the DB
  representation of the system objects.

- sccd capable to:
  - depsolving (on top of cumulative - YumDB + native managers DBs,
preferably providing interfaces to the

Re: dnf-0.4.11

[Garry T. Williams]

On 1-12-14 20:27:26 Reindl Harald wrote:
> "dnf clean all" without "dnf --enablerepo=updates-testing clean all"
> does exactly *nothing* in case of "updates-testing", the same for
> YUM simply because folders of non-enabled repos are not relevant for
> any operation

Yeah, I feel pretty stupid now.

-- 
Garry T. Williams

-- 
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-0.4.11

[Reindl Harald]

Am 12.01.2014 21:38, schrieb Garry T. Williams:
> On 1-12-14 20:27:26 Reindl Harald wrote:
>> "dnf clean all" without "dnf --enablerepo=updates-testing clean all"
>> does exactly *nothing* in case of "updates-testing", the same for
>> YUM simply because folders of non-enabled repos are not relevant for
>> any operation
> 
> Yeah, I feel pretty stupid now

no - the better question is why "all" does not mean really *all*

however, instead of "yum clean all" i use "rm -rf /var/cache/yum/*"
for al least 7 years because *that* means really all, in case of
DNF most likely "rm -rf /var/cache/dnf/*" would be required





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Inter-WG coordination: Stable application runtimes - SCC

[Alek Paunov]

On 12.01.2014 22:34, Alek Paunov wrote:

So, finally on that road we have:


...


- NTH: remote SCC DB for the instance,

- NTH: SCC local state for multiple instances (e.g. deployment nodes or
   local containers) kept in the same SCC DB

- NTH: SCC local state inheritance between instances



Another closely related topic is the system snapshotting or in other 
words - system "flavors" variants/subvariants tree.


Even before the btrfs magic, we have at hand wonderful snapshot
mechanisms - LVM, qcow2+qemu-nbd-connect, ceph rbd, etc. Probably, LVM
thinp currently is the best for the purpose of supporting tree of system
variants.

Once we apply FS snapshotting, combined with the SCC NTHs above, there
are at least two appealing use-cases:

- reusing one base e.g. F20 server container image for both the host and
  the incompatible containers (e.g. when one application requires nodejs
  0.8 and another nodejs 0.10)

- easy testbed for resolving the upgrade path for an existing, possibly
  non "pure Fedora" server with care about the deployed services.

--
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: Inter-WG coordination: Stable application runtimes

[Alek Paunov]

On 12.01.2014 22:34, Alek Paunov wrote:

[*] Crucial aspect of any sophisticated data management system is the
 data query and manipulation language. Unfortunately the choices are
 rather limited - Imperative approaches (recently resurrected by some
 NoSQL DBs) are weak and error prone; SQL and few more "text prose"
 languages have proven their incompatibility with the vast majority
 of the developers (these without years of specific experience around
 the data volumes processing). The predominant workaround seems to be
 ORMs, but ORMs and "sophisticated/fast" should not be mixed in same
 project :-).



My personal preference leans towards rules approach (which e.g. is also
adopted by at least one of the ERP innovation leaders - LogicBlox) and
especially its variant of visual rules definition UIs, where the user
describes dependencies (relations) between source and result trees of a
operations using blocks and arrows, and then the compiler lowers the the
whole transaction definition to executable (by the DB engine),
procedure.

IMHO, such kind of visual interface would be one of the possible
adequate languages (Adequate to the DB specialization level of our
target audience, including big share of the developers).

My personal preferences for the lower level executable language and DB
engine are LuaJIT procedures on top of SQlite4/LSM C API.

--
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: Grub installation. First potential Fedora killer

[Jean François Martinez]

Installer sees the partitions of other Linuxes.  But when rebooting after 
installation Fedora was the only choice.

Running grub2-mkconfig fixed it, ie other distribution became available.  Sort 
of.  Problems:
1)  Fedora was the default and there is no easy way (that is without reading 
the 150+ pages of Grub documentation to change that)
2)  If user does not know about grub2-mkconfig he will believe he is "trapped" 
in Fedora and will be very, very angry
3)  Every time he runs the other distribution and updates it he needs to 
rebooot into Fedora and run grub2-mkconfig 

On Mon, 6 Jan 2014 15:28:34 -0700
Chris Murphy  wrote:

> 
> On Jan 6, 2014, at 2:35 PM, Jean François Martinez  wrote:
> 
> > Centos 6 wasn't detected at install time.
> 
> This is rather vague. Do you mean the installer doesn't see any of the CentOS 
> partitions/LVs? Or CentOS isn't included as a grub menu item after installing 
> Fedora 20?
> 
> 
> Chris Murphy
> 


-- 
Jean François Martinez 
-- 
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: Inter-WG coordination: Stable application runtimes - SCC: Fedora social

[Alek Paunov]

On 12.01.2014 22:34, Alek Paunov wrote:

- sccd-web: WebUI exposing full functionality, alternatively Cockpit
   (OpenLMI WebUI) extension.


...



- NTH: SCC local state inheritance between instances


Fedora Social: Almost every developer or sysadmins like to demonstrate
how clean and clever is his own design :-).

Currently we do not have a service where Sandra, Joe and George [1]
could:
 - show and share with the others their Fedora based setups
 - conveniently keep the setup for their own reuse in the future

Once we have sccd-web and few NTHs, we will be nearly (at least as code)
equipped to provide something like "github for Fedora setups" for
publishing, referring in the e-mails and forking Fedora users work.

[1] http://fedoraproject.org/wiki/Server/Personas

--
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: Inter-WG coordination: Stable application runtimes - SCC

[Chris Murphy]

On Jan 12, 2014, at 1:51 PM, Alek Paunov  wrote:

> 
> Once we apply FS snapshotting, combined with the SCC NTHs above, there
> are at least two appealing use-cases:
> 
> - reusing one base e.g. F20 server container image for both the host and
>  the incompatible containers (e.g. when one application requires nodejs
>  0.8 and another nodejs 0.10)
> 
> - easy testbed for resolving the upgrade path for an existing, possibly
>  non "pure Fedora" server with care about the deployed services.

I agree, there are quite a few use cases for file system snapshots. Do the 
snapshots need to be bootable? 


Chris Murphy

-- 
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-0.4.11

[Miroslav Suchy]

On 01/12/2014 08:27 PM, Reindl Harald wrote:

"dnf clean all" without "dnf --enablerepo=updates-testing clean all" does
exactly*nothing*  in case of "updates-testing", the same for YUM simply
because folders of non-enabled repos are not relevant for any operation


And is this correct behavior? (and yum behaves same way, so same 
question apply to yum as well).


Man page for yum state:

yum clean metadata
Eliminate  all  of the files which yum uses to determine the remote 
availability of packages. Using this option will force yum to

download all the metadata the next time it is run.

There is no statement that it apply only for *currently enabled* repository.
I would expect that it clean *all* metadata.

I was recently very surprised that when I done :

# rpm -q yum
yum-3.4.3-128.fc20.noarch
# yum clean all
...
# du -sh /var/cache/yum/x86_64/*
225M/var/cache/yum/x86_64/19
111M/var/cache/yum/x86_64/20
406M/var/cache/yum/x86_64/rawhide

that there is a lot of data in /var. To be precise - after this 
operation I would expect that /var/cache/yum/x86_64/ would have zero 
size. And not 730 MB.


DNF is on the same boat:
# rpm -q dnf
dnf-0.4.9-1.fc20.noarch
# dnf clean all
Cleaning repos: fedora rpmfusion-free-updates adobe-linux-x86_64 Dropbox 
rpmfusion-nonfree-updates rpmfusion-free updates rpmfusion-nonfree

Cleaning up Everything
# du -sh /var/cache/dnf/x86_64/*
114M/var/cache/dnf/x86_64/19
34M /var/cache/dnf/x86_64/20

Do others feel that this is correct or incorrect behavior?

Mirek


--
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-0.4.11

[Reindl Harald]

Am 12.01.2014 22:42, schrieb Miroslav Suchy:
> On 01/12/2014 08:27 PM, Reindl Harald wrote:
>> "dnf clean all" without "dnf --enablerepo=updates-testing clean all" does
>> exactly *nothing*  in case of "updates-testing", the same for YUM simply
>> because folders of non-enabled repos are not relevant for any operation
> 
> And is this correct behavior? (and yum behaves same way, so same question 
> apply to yum as well).

no, i only explained the current state of play

looking at the word "all" and it's meaing clearly *no*
looking at the thread and result of the behavior clearely *no*
looking at that people use "updates-testing" with --enablerepo *no*
looking at the fact that i do not trust the word "all" clearly *no*

> Man page for yum state:
> 
> yum clean metadata
> Eliminate  all  of the files which yum uses to determine the remote 
> availability of packages. Using this option
> will force yum to
> download all the metadata the next time it is run.
> 
> There is no statement that it apply only for *currently enabled* repository.
> I would expect that it clean *all* metadata.
> 
> I was recently very surprised that when I done :
> 
> # rpm -q yum
> yum-3.4.3-128.fc20.noarch
> # yum clean all
> ...
> # du -sh /var/cache/yum/x86_64/*
> 225M/var/cache/yum/x86_64/19
> 111M/var/cache/yum/x86_64/20
> 406M/var/cache/yum/x86_64/rawhide
> 
> that there is a lot of data in /var. To be precise - after this operation I 
> would expect that
> /var/cache/yum/x86_64/ would have zero size. And not 730 MB.

and that is why i switched 7 years ago to "rm -rf /var/cache/yum*"



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf-0.4.11

[Alec Leamas]

I have come to understand that for yum, commands like clean only applies to
the actual buildroot. So without a -r argument, the cleaning is done on the
default root, whatever this might be(?).

Actually, there is probably nothing wrong with this - it works fine when
using the -r option. Problems comes without it, when one thinks it applies
to all buildroots. It would perhaps make sense outputting something like
"Using buildroot foo" when there is no -r on the command line(?).



On Sun, Jan 12, 2014 at 10:47 PM, Reindl Harald wrote:

>
> Am 12.01.2014 22:42, schrieb Miroslav Suchy:
> > On 01/12/2014 08:27 PM, Reindl Harald wrote:
> >> "dnf clean all" without "dnf --enablerepo=updates-testing clean all"
> does
> >> exactly *nothing*  in case of "updates-testing", the same for YUM simply
> >> because folders of non-enabled repos are not relevant for any operation
> >
> > And is this correct behavior? (and yum behaves same way, so same
> question apply to yum as well).
>
> no, i only explained the current state of play
>
> looking at the word "all" and it's meaing clearly *no*
> looking at the thread and result of the behavior clearely *no*
> looking at that people use "updates-testing" with --enablerepo *no*
> looking at the fact that i do not trust the word "all" clearly *no*
>
> > Man page for yum state:
> >
> > yum clean metadata
> > Eliminate  all  of the files which yum uses to determine the remote
> availability of packages. Using this option
> > will force yum to
> > download all the metadata the next time it is run.
> >
> > There is no statement that it apply only for *currently enabled*
> repository.
> > I would expect that it clean *all* metadata.
> >
> > I was recently very surprised that when I done :
> >
> > # rpm -q yum
> > yum-3.4.3-128.fc20.noarch
> > # yum clean all
> > ...
> > # du -sh /var/cache/yum/x86_64/*
> > 225M/var/cache/yum/x86_64/19
> > 111M/var/cache/yum/x86_64/20
> > 406M/var/cache/yum/x86_64/rawhide
> >
> > that there is a lot of data in /var. To be precise - after this
> operation I would expect that
> > /var/cache/yum/x86_64/ would have zero size. And not 730 MB.
>
> and that is why i switched 7 years ago to "rm -rf /var/cache/yum*"
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf-0.4.11

[Reindl Harald]

from a developers point of view the current behavior is clear and perfect
"what is not enabled is handeled as it would not exist"

means:
repos with "enabled=0" are completly ignored until --enablrepo with no
but and if - clear and straight logical decision

from a users point of view "all" has a different meaning

well, i can live with both because i am developer and i know
how these things are working, i know that the codebase is much
cleaner the way it works currently

personally i would draw the line in case if it is my code and act
like the user expects it, not in general, but in that case of
"meaningless" data which are refreshed and no bad impact if lost

Am 12.01.2014 22:57, schrieb Alec Leamas:
> I have come to understand that for yum, commands like clean only applies to 
> the actual buildroot. So without a -r
> argument, the cleaning is done on the default root, whatever this might be(?).
> 
> Actually, there is probably nothing wrong with this - it works fine when 
> using the -r option. Problems comes
> without it, when one thinks it applies to all buildroots. It would perhaps 
> make sense outputting something like
> "Using buildroot foo" when there is no -r on the command line(?).
> 
> 
> 
> On Sun, Jan 12, 2014 at 10:47 PM, Reindl Harald  > wrote:
> 
> 
> Am 12.01.2014 22:42, schrieb Miroslav Suchy:
> > On 01/12/2014 08:27 PM, Reindl Harald wrote:
> >> "dnf clean all" without "dnf --enablerepo=updates-testing clean all" 
> does
> >> exactly *nothing*  in case of "updates-testing", the same for YUM 
> simply
> >> because folders of non-enabled repos are not relevant for any operation
> >
> > And is this correct behavior? (and yum behaves same way, so same 
> question apply to yum as well).
> 
> no, i only explained the current state of play
> 
> looking at the word "all" and it's meaing clearly *no*
> looking at the thread and result of the behavior clearely *no*
> looking at that people use "updates-testing" with --enablerepo *no*
> looking at the fact that i do not trust the word "all" clearly *no*
> 
> > Man page for yum state:
> >
> > yum clean metadata
> > Eliminate  all  of the files which yum uses to determine the remote 
> availability of packages. Using this option
> > will force yum to
> > download all the metadata the next time it is run.
> >
> > There is no statement that it apply only for *currently enabled* 
> repository.
> > I would expect that it clean *all* metadata.
> >
> > I was recently very surprised that when I done :
> >
> > # rpm -q yum
> > yum-3.4.3-128.fc20.noarch
> > # yum clean all
> > ...
> > # du -sh /var/cache/yum/x86_64/*
> > 225M/var/cache/yum/x86_64/19
> > 111M/var/cache/yum/x86_64/20
> > 406M/var/cache/yum/x86_64/rawhide
> >
> > that there is a lot of data in /var. To be precise - after this 
> operation I would expect that
> > /var/cache/yum/x86_64/ would have zero size. And not 730 MB.
> 
> and that is why i switched 7 years ago to "rm -rf /var/cache/yum*"



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Grub installation. First potential Fedora killer

[Chris Murphy]

On Jan 12, 2014, at 1:58 PM, Jean François Martinez  wrote:

> Installer sees the partitions of other Linuxes.  But when rebooting after 
> installation Fedora was the only choice.
> 
> Running grub2-mkconfig fixed it, ie other distribution became available.  
> Sort of.  Problems:
> 1)  Fedora was the default and there is no easy way (that is without reading 
> the 150+ pages of Grub documentation to change that)
> 2)  If user does not know about grub2-mkconfig he will believe he is 
> "trapped" in Fedora and will be very, very angry
> 3)  Every time he runs the other distribution and updates it he needs to 
> rebooot into Fedora and run grub2-mkconfig 

Right, I didn't mean to indicate that multiboot on linux doesn't completely 
suck, or that linux distros are friendly to each other rather than behaving in 
a cannibalistic fashion by default. GRUB2 really isn't meant for mortal users, 
just for the members of the lunacy asylum, so this really should work better 
than it does yet here we are.

Is this computer by any chance UEFI firmware based? Or is it BIOS? That matters.

On BIOS what's supposed to happen is anaconda calls grub2-mkconfig which in 
turn uses os-prober to find other OS's and create something sensible in 
grub.cfg. That doesn't always work for various reasons, in particular on UEFI. 
What you're probably better off doing, is editing /etc/grub.d/40_custom to add 
a very basic entry to locate the CentOS grub.conf. Something like this:

menuentry 'CentOS menu'  {
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 
--hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  
d7bc9d0e-7706-44f9-b1a7-ff24b7c360a7
legacyconfigfile $prefix/grub.conf
}


Not all hints are needed. Obviously change hd0,gpt4 with the right hint for the 
hard drive and partition and partition scheme for where CentOS /boot is 
located. The important one, really, is the UUID at the end, which is the file 
system UUID for the CentOS boot partition (or rootfs if /boot is a directory on 
root). The legacyconfigfile command allows GRUB2 to read legacy GRUB 
configuration files. $prefix you should replace with /boot/grub if /boot is a 
directory on rootfs or /grub if it's on its own partition.

Now grub2-mkconfig -o /boot/grub2/grub.cfg and this entry will be added to your 
Fedora 20 grub.cfg. You'll get an entry that points to the CentOS menu. If you 
choose it, the CentOS menu list of kernels should appear. If you want to make 
this a default behavior, you'll need to read about $menuentry_id_option for 
your CentOS menu entry in the Fedora grub.cfg. By giving it a unique ID, you 
can then specify it as the default by that same id in /etc/default/grub.

Yes it's like pulling teeth.


Chris Murphy
-- 
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-0.4.11

[Alec Leamas]

Well, IMHO the docs are actually quite clear on that 'all' refers to all
metadata rather than all repositories.

That said, perhaps enough people has been confused by this to make some
kind of improvement motivated.

-- 
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-0.4.11

[Orcan Ogetbil]

On Sun, Jan 12, 2014 at 5:23 PM, Alec Leamas wrote:
> Well, IMHO the docs are actually quite clear on that 'all' refers to all
> metadata rather than all repositories.
>
> That said, perhaps enough people has been confused by this to make some kind
> of improvement motivated.
>

I am pretty sure if you flip the current behavior and make 'clean all'
act on disabled repos, some other subset of users (e.g. me) will be
confused.

Best,
Orcan
-- 
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-0.4.11

[Reindl Harald]

Am 13.01.2014 00:17, schrieb Orcan Ogetbil:
> On Sun, Jan 12, 2014 at 5:23 PM, Alec Leamas wrote:
>> Well, IMHO the docs are actually quite clear on that 'all' refers to all
>> metadata rather than all repositories.
>>
>> That said, perhaps enough people has been confused by this to make some kind
>> of improvement motivated.
>>
> 
> I am pretty sure if you flip the current behavior and make 'clean all'
> act on disabled repos, some other subset of users (e.g. me) will be
> confused

please explain how you would be confused

"clean all" would only delete metadata which are anyways refreshed
at the next call with whatever repo enabled and "clean all" is there
to make sure that *all* metadata is refreshed instead use maybe outdated



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf-0.4.11

[Alec Leamas]

First of all, this is not, and have never been a question of disabled
repos. Or should not have. "yum clean all" refers to cleaning all metadata,
not all repos. It only operates on one single repo, be it implicit (the
default link) or an explicit -r option.

This is what confuses. I know:  been there done that... Even though the
documents are clear, the behaviour does indeed cause confusion for some
reason even though it's well-defined.

Of course, changing semantics for yum is a bad idea, agreed. I did not have
anything like that in mind. At most, some info on what buildroot which is
used in the output, or similar measures.

For dnf, I guess one could possibly think somewhat more free. Personally, I
tend to think that it's the implicit buildroot which causes much of this
trouble.

What happens if we get rid of the implcit buildroot, forcing us to specify
it every time? With 'default' as a legal option? Personally, I tend to
think this might make things a little clearer.

Just my 5 öre
--alec


On Mon, Jan 13, 2014 at 12:17 AM, Orcan Ogetbil wrote:

> On Sun, Jan 12, 2014 at 5:23 PM, Alec Leamas wrote:
> > Well, IMHO the docs are actually quite clear on that 'all' refers to all
> > metadata rather than all repositories.
> >
> > That said, perhaps enough people has been confused by this to make some
> kind
> > of improvement motivated.
> >
>
> I am pretty sure if you flip the current behavior and make 'clean all'
> act on disabled repos, some other subset of users (e.g. me) will be
> confused.
>
> Best,
> Orcan
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf-0.4.11

[Reindl Harald]

Am 13.01.2014 00:43, schrieb Alec Leamas:
> First of all, this is not, and have never been a question of disabled repos. 
> Or should not have. "yum clean all"
> refers to cleaning all metadata, not all repos. It only operates on one 
> single repo, be it implicit (the default
> link) or an explicit -r option.
> 
> This is what confuses. I know:  been there done that... Even though the 
> documents are clear, the behaviour does
> indeed cause confusion for some reason even though it's well-defined.
> 
> Of course, changing semantics for yum is a bad idea, agreed. I did not have 
> anything like that in mind. At most,
> some info on what buildroot which is used in the output, or similar measures.
> 
> For dnf, I guess one could possibly think somewhat more free. Personally, I 
> tend to think that it's the implicit
> buildroot which causes much of this trouble.
> 
> What happens if we get rid of the implcit buildroot, forcing us to specify it 
> every time? With 'default' as a legal
> option? Personally, I tend to think this might make things a little clearer.

*what* is a "buildroot" in case of YUM/DNF?

in any case nothing relevant for a user and said that i use Fedora and YUM for
many years, the only conetxt of "buildroot" for me is rpmbuild and that has no
context to YUM/DNF at all





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf-0.4.11

[Alec Leamas]

Yes, sorry, forget what I wrote. I messed up mock with yum, that's why.
It's too late for me to chime in here. Sorry for the noise.


On Mon, Jan 13, 2014 at 12:49 AM, Reindl Harald wrote:

>
>
> Am 13.01.2014 00:43, schrieb Alec Leamas:
> > First of all, this is not, and have never been a question of disabled
> repos. Or should not have. "yum clean all"
> > refers to cleaning all metadata, not all repos. It only operates on one
> single repo, be it implicit (the default
> > link) or an explicit -r option.
> >
> > This is what confuses. I know:  been there done that... Even though the
> documents are clear, the behaviour does
> > indeed cause confusion for some reason even though it's well-defined.
> >
> > Of course, changing semantics for yum is a bad idea, agreed. I did not
> have anything like that in mind. At most,
> > some info on what buildroot which is used in the output, or similar
> measures.
> >
> > For dnf, I guess one could possibly think somewhat more free.
> Personally, I tend to think that it's the implicit
> > buildroot which causes much of this trouble.
> >
> > What happens if we get rid of the implcit buildroot, forcing us to
> specify it every time? With 'default' as a legal
> > option? Personally, I tend to think this might make things a little
> clearer.
>
> *what* is a "buildroot" in case of YUM/DNF?
>
> in any case nothing relevant for a user and said that i use Fedora and YUM
> for
> many years, the only conetxt of "buildroot" for me is rpmbuild and that
> has no
> context to YUM/DNF at all
>
>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Inter-WG coordination: Stable application runtimes

[Adam Williamson]

On Sun, 2014-01-12 at 19:43 +0100, Reindl Harald wrote:
> 
> Am 12.01.2014 19:39, schrieb Adam Williamson:
> > Have you looked at what people are installing on Fedora lately? Have you
> > looked at how much PHP stuff there is out there vs. what we have
> > packaged 'properly'? Java? Ruby? Do you know anyone who deploys
> > Wordpress plugins via distribution packages?
> 
> that has other reasons
> 
> on a typical webserver you have not *the* wordpress and *the* wordpress
> plugins - you have 10,20,30,100,500 *independent* wordpress setups
> 
> for production the only case where you can use distribution packages
> is if you have a dedicated machines / VM serving only one website

Sure, but that just backs up my point further. Even in the case where
you have an 'appliance' style setup, you _can_ use distro packages, but
why would you bother? If it's a single-purpose system then you don't get
much benefit from doing so. Does RH base pre-rolled openshift gears on
Fedora or RHEL distribution packages? I don't think so.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

Re: Inter-WG coordination: Stable application runtimes

[Adam Williamson]

On Sun, 2014-01-12 at 20:58 +0100, Till Maas wrote:
> On Sun, Jan 12, 2014 at 10:39:19AM -0800, Adam Williamson wrote:
> > On Sun, 2014-01-12 at 18:55 +0100, Kevin Kofler wrote:
> 
> > > So, like Matthew Miller, I think we cannot possibly punt on this issue, 
> > > but 
> > > I totally DISAGREE with his proposed solution of endorsing those bundling 
> > > systems officially. Instead, we need to continue packaging things 
> > > properly.
> > 
> > Have you looked at what people are installing on Fedora lately? Have you
> > looked at how much PHP stuff there is out there vs. what we have
> > packaged 'properly'? Java? Ruby? Do you know anyone who deploys
> > Wordpress plugins via distribution packages?
> 
> Even if people do it, it does not meant that it is the best way to do
> it. Mixed packaging makes it a lot harder to properly update in case of
> security vulnerabilities. E.g. instead of only checking/ensuring proper
> RPM updates one need to check each distribution method for regular
> updates. Is there even some tooling available to check/update all e.g.
> rbenv or virtualenv setups properly?

You're preaching to the choir. But if in practice people really don't
deploy things via the distribution packages, it doesn't matter how
awesomely secure the distribution packages are. Something that you're
not using is never providing you with any additional security.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

non-responsive maintainer

[Andrew Widdersheim]

I haven't been able to get in touch with Silas Sewell (silas) by email or by 
bugzilla. He is the owner of quite a few packages but I'm primarily only 
interested in two. They are redis and python-redis. They are both out of date 
and I'd like to see them get updated in EPEL. Here links to the bugzilla 
tickets:

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

I have never maintained packages in EPEL before but I wouldn't mind learning 
how. Either way I'd like to see these packages get updated. 
 
-- 
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-0.4.11

[Ahmad Samir]

On 12 January 2014 21:27, Reindl Harald  wrote:
>
> Am 12.01.2014 20:24, schrieb Ahmad Samir:
>> On 12 January 2014 21:06, Garry T. Williams  wrote:
>>> On 1-12-14 18:18:00 M A Young wrote:
 On Sun, 12 Jan 2014, Garry T. Williams wrote:
> On 1-9-14 15:43:50 Ales Kozumplik wrote:
>> New DNF release is out. See the blog [1], the release notes [2] and
>> the F20 update [3]. Rawhide build went smooth this time too!
>
> I see this using 0.4.11.  What am I doing wrong?
>
> garry@vfr$ sudo dnf --enablerepo=updates-testing update kernel\*
> [sudo] password for garry:
> Resolving dependencies
> --> Starting dependency resolution
> --> Finished dependency resolution
> Dependencies resolved.
> Nothing to do.

 Try
 dnf clean expire-cache
 first. I don't think dnf checks whether its metadata is up to date as
 frequently as yum does.
>>>
>>> Ha!  That was it.
>>>
>>> sudo dnf --enablerepo=updates-testing clean expire-cache
>>> sudo dnf --enablerepo=updates-testing upgrade kernel\*
>>>
>>> did the trick.
>>>
>>
>> 'dnf clean all' does what 'clean expire-cache' does, and more. (check
>> the man page)
>
> "dnf clean all" without "dnf --enablerepo=updates-testing clean all" does
> exactly *nothing* in case of "updates-testing", the same for YUM simply
> because folders of non-enabled repos are not relevant for any operation
>

Right, I missed that bit.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



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

where to report bad dracut man page content

[Felix Miata]

https://bugzilla.novell.com/show_bug.cgi?id=858448 is openSUSE bug. Is 
upstream better for a rough parallel for Fedora, or bugzilla.redhat.com, or 
something else? If upstream, where exactly is upstream for reporting poor man 
page content?

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf-0.4.11

[Miroslav Suchy]

On 01/12/2014 11:23 PM, Alec Leamas wrote:

Well, IMHO the docs are actually quite clear on that 'all' refers to all
metadata rather than all repositories.

That said, perhaps enough people has been confused by this to make some
kind of improvement motivated.


Let leave yum as is, but let try to redefine this behavior for dnf:
https://bugzilla.redhat.com/show_bug.cgi?id=1052020

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

rawhide evolution-data-server/libcamel soname version bump

[Milan Crha]

Hello,
I'm just updating evolution-data-server to 3.11.4 in rawhide, which
includes a soname version bump for libcamel (it happened before 3.11.3,
but that version didn't reach Fedora rawhide for some reason).
I'll rebuild all affected packages I have commit rights for.
Bye,
Milan

-- 
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-0.4.11

[Frank Murphy]

On Mon, 13 Jan 2014 07:51:22 +0200
Ahmad Samir  wrote:

> Right, I missed that bit.
> >
>

to be certain you can do "dnf(yum) --enablerepo=* clean all"
if your intention is truly to remove all cache.



___
Regards,
Frank 
www.frankly3d.com

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

Re: Grub installation. First potential Fedora killer

[Jean François Martinez]

On Sun, 12 Jan 2014 15:21:16 -0700
Chris Murphy  wrote:

> 
> On Jan 12, 2014, at 1:58 PM, Jean François Martinez  wrote:
> 
> > Installer sees the partitions of other Linuxes.  But when rebooting after 
> > installation Fedora was the only choice.
> > 
> > Running grub2-mkconfig fixed it, ie other distribution became available.  
> > Sort of.  Problems:
> > 1)  Fedora was the default and there is no easy way (that is without 
> > reading the 150+ pages of Grub documentation to change that)
> > 2)  If user does not know about grub2-mkconfig he will believe he is 
> > "trapped" in Fedora and will be very, very angry
> > 3)  Every time he runs the other distribution and updates it he needs to 
> > rebooot into Fedora and run grub2-mkconfig 
> 
> Right, I didn't mean to indicate that multiboot on linux doesn't completely 
> suck, or that linux distros are friendly to each other rather than behaving 
> in a cannibalistic fashion by default. GRUB2 really isn't meant for mortal 
> users, just for the members of the lunacy asylum, so this really should work 
> better than it does yet here we are.
> 

It is refreshing to see I am not alone.  Grub2 has the syndrome of "developpers 
becaming infatuated and not hiving a hoot about erfs err, I meant users".  A 
major problem in the Free Software field.  Just take a look at this
sentence in the doc "the booter is the most important program in the
computer".  No, it is a means to an end.  


> Is this computer by any chance UEFI firmware based? Or is it BIOS? That 
> matters.
> 

BIOS.  GPT partitionning

> On BIOS what's supposed to happen is anaconda calls grub2-mkconfig which in 
> turn uses os-prober to find other OS's and create something sensible in 
> grub.cfg. That doesn't always work for various reasons, in particular on 
> UEFI. What you're probably better off doing, is editing /etc/grub.d/40_custom 
> to add a very basic entry to locate the CentOS grub.conf. Something like this:
> 
> menuentry 'CentOS menu'  {
> search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 
> --hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  
> d7bc9d0e-7706-44f9-b1a7-ff24b7c360a7
> legacyconfigfile $prefix/grub.conf
> }
> 
> 
> Not all hints are needed. Obviously change hd0,gpt4 with the right hint for 
> the hard drive and partition and partition scheme for where CentOS /boot is 
> located. The important one, really, is the UUID at the end, which is the file 
> system UUID for the CentOS boot partition (or rootfs if /boot is a directory 
> on root). The legacyconfigfile command allows GRUB2 to read legacy GRUB 
> configuration files. $prefix you should replace with /boot/grub if /boot is a 
> directory on rootfs or /grub if it's on its own partition.
> 
> Now grub2-mkconfig -o /boot/grub2/grub.cfg and this entry will be added to 
> your Fedora 20 grub.cfg. You'll get an entry that points to the CentOS menu. 
> If you choose it, the CentOS menu list of kernels should appear. If you want 
> to make this a default behavior, you'll need to read about 
> $menuentry_id_option for your CentOS menu entry in the Fedora grub.cfg. By 
> giving it a unique ID, you can then specify it as the default by that same id 
> in /etc/default/grub.
> 
> Yes it's like pulling teeth.
> 

In fact I was hinting about the need of a boot configurator in Fedora.  If user 
had somethig in the menus named "Boot manager" then the subject would 
just be minor annoyance.  But now a user who doesn't know about Grub2 
intrincacies just sees he is trapped and there is no way to escape.

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

-- 
Jean François Martinez 
-- 
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-0.4.11

[Frank Murphy]

On Mon, 13 Jan 2014 00:43:13 +0100
Alec Leamas  wrote:

> First of all, this is not, and have never been a question of disabled
> repos. Or should not have. "yum clean all" refers to cleaning all
> metadata, not all repos. It only operates on one single repo, be it
> implicit (the default link) or an explicit -r option.
>

man yum
CLEAN OPTIONS
   The following are the ways which you can invoke yum in clean
mode. Note that "all files" in the  commands  below  means  "all
files  in  currently enabled repositories".  If you want to also clean
any (temporarily) disabled repositories you need to use
--enablerepo='*' option."

___
Regards,
Frank 
www.frankly3d.com

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