Re: Heads-up: ODE soname bump

[Hedayat Vatankhah]

On ۱۴۰۱/۵/۳ ۴:۵۴ قبل‌ازظهر, Robert-André Mauchin wrote:

On 7/24/22 16:40, Hedayat Vatankhah wrote:

<...>


Use (Close: rhbz#1438205) instead of (rhbz#1438205)
or Closes: rhbz#1438205, Fix: rhbz#1438205, Fixes: rhbz#1438205
to automatically close the related nug


Thanks for the tip.



On 7/24/22 19:14, Maxwell G via devel wrote:
> On 22/07/24 06:05PM, Kalev Lember wrote:
>> If ODE 0.16 was only built as part of the mass rebuild and wasn't
>> available in the buildroot during the mass rebuild (and I don't think
>> it was), then all the other packages that depend on it were still
>> built against the older ODE 0.14 version as part of the mass rebuild.
>> Once the mass rebuild is merged back into f37 then all other packages
>> that depend on ODE are going to have broken dependencies.
>
> That indeed appears to be the case. The f37-rebuild build target[1]
> builds against f37-build but tags completed builds into f37-rebuild.
> ode-0.16.2-2.fc37[2] is only tagged into f37-rebuild.
>
> [1]: https://koji.fedoraproject.org/koji/buildtargetinfo?targetID=24581
> [2]: https://koji.fedoraproject.org/koji/buildinfo?buildID=2016899
>
> Also, looking at ompl, one of ode's dependents, you can see that it was
> rebuilt against the old version of ode:
>
>> DEBUG util.py:445: ode-devel  x86_64  
0.14-15.fc36 build   66 k

>
> -- 
https://kojipkgs.fedoraproject.org//packages/ompl/1.5.0/11.fc37/data/logs/x86_64/root.log 
and
> 
https://koji.fedoraproject.org/koji/buildinfo?buildID=2016925https://koji.fedoraproject.org/koji/buildinfo?buildID=2016925

>
> In order to fix this, a provenpackager will need to build all of the
> dependents in a sidetag like normal. Preferably, this could happen
> before the mass rebuild tag is merged back into f37. I am a bit busy
> today, but I suppose I could do this later if nobody beats me to it.
>

It is done: 
https://bodhi.fedoraproject.org/updates/FEDORA-2022-26df2fedba


Had to fixup freewrl though, the java thing on i686.


Thanks a lot for fixing this. And sorry for the trouble.


Thanks,

Hedayat






Best regards,

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

Re: Heads-up: ODE soname bump

[Hedayat Vatankhah]

  
  


On ۱۴۰۱/۵/۲ ۸:۳۵ بعدازظهر, Kalev Lember
  wrote:


  
  
On Sun, Jul 24, 2022 at 4:41 PM Hedayat Vatankhah
  <hedayat@gmail.com>
  wrote:


  

  Hi all,
  As part of building ODE 0.16, ode's soname has been
bumped from libode.so.4/libode-double.so.4  to
libode.so.8/libode-double.so.8. 
  
  This package is now built as part of Fedora 37 Mass
Rebuild, so we expect all dependent packages to be
automatically built again during this process. 
  
  We do not expect to see compilation failures because of
this update.

  
  
  
  Hi Hedayat,
  
  
  No, this is not how mass rebuilds work. If ODE 0.16 was
only built as part of the mass rebuild and wasn't available
in the buildroot during the mass rebuild (and I don't think
it was), then all the other packages that depend on it were
still built against the older ODE 0.14 version as part of
the mass rebuild. Once the mass rebuild is merged back into
f37 then all other packages that depend on ODE are going to
have broken dependencies.
  

  

Hi Kalev,
Oops, I'm really sorry; I didn't know this.


Thanks,
Hedayat


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

Heads-up: ODE soname bump

[Hedayat Vatankhah]

Hi all,

As part of building ODE 0.16, ode's soname has been bumped from 
libode.so.4/libode-double.so.4  to libode.so.8/libode-double.so.8.


This package is now built as part of Fedora 37 Mass Rebuild, so we 
expect all dependent packages to be automatically built again during 
this process.


We do not expect to see compilation failures because of this update.


Regards,

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

Re: F37 proposal: Enhance Persian Font Support (Self-Contained Change proposal)

[Hedayat Vatankhah]

On ۱۴۰۱/۳/۲ ۱۱:۵۵ بعدازظهر, Sebastian Crane wrote:

...
I did notice that the 'How to Test' section of the proposal was empty;
just as a suggestion, please could we have some screenshots of the
main Persian fonts used in Fedora currently? I'm mostly just curious,
but it might be useful for testing to see whether the changes are
successfully reflected in all desktop applications - especially for
people like me, who can't (yet!) read the Persian alphabet.


Done. I've added screenshots of the current and the desired states.


Regards,

Hedayat




Best wishes,

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

Re: F37 proposal: Enhance Persian Font Support (Self-Contained Change proposal)

[Hedayat Vatankhah]

On ۱۴۰۱/۳/۵ ۵:۲۹ بعدازظهر, Zbigniew Jędrzejewski-Szmek wrote:

Hi,
the Scope can be split into parts: 1. packaging the font,
2. making it the default, 3. fixing integration issues, like with Firefox.

I'd encourage you to do 1. as soon as possible. Until that's done,
it's even hard to evaluate if we're ready for 2. And if it's packaged,
and not ready for being the default, some users might still find it useful
and enable it manually.


Hi,

Thanks for the feedback. Actually, 1 is already underway [1]. I've added 
a link to its review request in the change page to make it more clear. 
And if installed, it'll register itself as the default font for Persian. 
What remains for 2 is to make it installed by default. And about 3, yeah 
it is already marked as optional; and to be honest I don't have high 
hopes for it to be fixed; as it seems to be a bug in Firefox/Thunderbird 
and I've seen a number of similar reports (although not exactly similar 
to one reported by me) without much attention.



Thanks,

Hedayat



[1] https://bugzilla.redhat.com/show_bug.cgi?id=2081539



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

Re: F37 proposal: Enhance Persian Font Support (Self-Contained Change proposal)

[Hedayat Vatankhah]

On ۱۴۰۱/۳/۴ ۳:۰۷ بعدازظهر, Jens-Ulrik Petersen wrote:
I am also curious how the Vazirmatn font compares with Noto Naskh 
Arabic, and also the old Dejavu coverage?


If you are referring to the coverage of unicode code points, I've no 
idea. Although the author claims to support 9 languages, all of which 
are based on Arabic script AFAIK; but I'm not aware of the details.



For a more detailed comparison of these fonts, you might see this 
email[1] in which I've talked about other options for the default 
Persian font like Noto Sans Arabic & Noto Naskh fonts.



Regards,

Hedayat


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

Re: F37 proposal: Enhance Persian Font Support (Self-Contained Change proposal)

[Hedayat Vatankhah]

On ۱۴۰۱/۳/۲ ۱۱:۵۵ بعدازظهر, Sebastian Crane wrote:

As something of a typography enthusiast, I'm very much in support of
this. For English, the consistent fonts on Fedora Workstation make a
noticeable and positive effect on the general aesthetic, so anything
that can widen that benefit would be advantageous.


Yeah, inconsistency makes the experience really annoying.



I did notice that the 'How to Test' section of the proposal was empty;
just as a suggestion, please could we have some screenshots of the
main Persian fonts used in Fedora currently? I'm mostly just curious,
but it might be useful for testing to see whether the changes are
successfully reflected in all desktop applications - especially for
people like me, who can't (yet!) read the Persian alphabet.


Sure, I'll add screenshots of the current state in F36 and the target 
state. Although, I'm not sure if I'd be able to do anything for 
Firefox/Thunderbird inconsistency problem [1]; but at least the current 
state will be improved significantly.






Best wishes,

Sebastian


Thanks,

Hedayat


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

Re: F37 proposal: Enhance Persian Font Support (Self-Contained Change proposal)

[Hedayat Vatankhah]

On ۱۴۰۱/۳/۲ ۹:۰۲ بعدازظهر, Michael Catanzaro wrote:
On Mon, May 23 2022 at 11:54:30 AM -0400, Ben Cotton 
 wrote:

Default Persian font will be changed automatically on upgrades.


Good, but how will you achieve this? We finally noticed that noto 
fonts don't get installed when upgrading F35 -> F36 and should avoid 
making the same mistake again. ...




Good point. I should confess that I'm unaware of what happened for Noto 
fonts. And I thought updating langpacks-core-font-fa package dependency 
should suffice for upgrades to automatically install the new font; 
assuming that the user already has it. But now you made me doubt that 
assumption.



Thanks,

Hedayat

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

os-prober updates are blocked by missing grub tool, but the maintainer doesn't respond

[Hedayat Vatankhah]

Dear Peter (which most likely won't read) and all,


I've opened a but more than a year ago about missing grub tool in 
Fedora[1],


and I've even emailed Peter directly, but there is no response. Upstream 
os-prober


now requires grub2-mount to function, and therefore Fedora os-prober is 
effectively


not maintained. It even have started to fail on my own system.


I kindly ask someone to do something about it. Or at least let me know 
to orphan


the package.


Regards,

Hedayat (os-prober maintainer)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1471267

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

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Hedayat Vatankhah]

Hi,
I've fixed all my packages except simspark & rcssserver3d, which seem to 
crash on i686 when generating docs using pdflatex, which will probably 
needs a fix in TeXLive.


Regards,
Hedayat

/*Igor Gnatenko*/ wrote on Sun, 18 Feb 2018 18:09:40 +0100:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Over this weekend I've performed scratch-mass-rebuild without having gcc and
gcc-c++ in buildroot of all Fedora packages, many of which failed due to random
reasons and I grepped all logs for some common errors found by analyzing
hundreds of build logs.

Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire
s_and_Requies

The grep output is located here:
https://ignatenkobrain.fedorapeople.org/gcc-removal.txt

Some packages might be missed due to short koji outage, broken dependencies and
so on, but majority of real failures is below.

If you fixed package(s), found false positive, found missing packages in list
or anything else -- please let me know.

Note to packages which use CMake buildsystem. When you have project(xxx) in
CMakeLists.txt it checks both for C and CXX compilers. So you might encounter
packages where you have BuildRequires: gcc and it fails on CXX compiler (even
you think you don't need it). Solution for this is to send patch to upstream
switching to something like project(xxx C), or if problem is opposite to
project(xxx CXX).

List of packages and respective maintainers:
https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt

- -- 
- -Igor Gnatenko

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJs1QACgkQaVcUvRu8
X0xxkRAAj56QZYSxzDXiMyvM9eLdVS0Qrt9jiNa66rasIbDVciTym7WQoV2CXxM+
ZxaOCYU8eyxOhE1rx36KITJ7SgU6ugLu2dVZlG/QR8vH3RTqJPV/GWhM/WUAgaon
f/SPwTIMk31qvEuKwlqLgNH1rwpRH2NfWVelZChwi1zXOglMvIHakV7sSedYy2i9
bmVvf/1ylj/NbaI6FaLUqg81UQhUulD8RYeZi1cyxSpit/4aysP7ixCb4MLizmwH
uNUO0y//xxL0hMSShmfTlsPXowU+NpkzV+lFQ/k2X4KcCZWMabfCt69TdyTbYlj5
ai8oFGNI94Tv6rrzR/Rirfl/eODtdaaeNqyg/MBze6hYpS2w2oezOEmdYvlpJ7Xo
z0fN/vIus1SeeyIKWo4KYHZYRX6g2nTCUeGYJqvCIRVxS9UJsy45C/HlnIWTtedn
Dyp9O/0aSDhY+ErPQi64+HloZrY7p+KsCzPNc9HdzLbhnfM5IUn2TmO+qHngBSlY
zGNfpOsBmmllSuBftWDfiayh8C9sBUpGT9693iyQYXPIwjZkQSHAclDZa7naN3Oy
NKQaqVOsDmgDDP9xVOyr/Aue3jQk/8QHraM5DgO05L6lXHwdm+rjIdbb7CU2rFF7
Gl14+kSFP7yufRQiS6Gt96eN4ePxSuD7XjiT/9GicztDXypNeX8=
=KRiO
-END PGP SIGNATURE-
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org


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

Re: Packages looking for new maintainers

[Hedayat Vatankhah]

Hi,

/*Ville Skyttä*/ wrote on Wed, 25 Oct 2017 18:54:01 +0300:

On Mon, Oct 23, 2017 at 10:24 PM, Ville Skyttä  wrote:

Hello,

...again, updated lists below. The following packages are looking for
new maintainers, ping me if you're able to help out. When doing so,
please note your FAS account name.

1) No co-maintainers at the moment:

- isrcsubmit
- kid3

If nobody else wants it, I'd take kid3

Thanks
Hedayat



- mbox2eml
- modplugtools
- portecle
- python-flake8-import-order
- vdr-epgfixer
- vdr-ttxtsubs

2) Needs new main admin, co-maintainers pinged some time ago but no
reply received/noticed:

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


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

Re: Packaging Question

[Hedayat Vatankhah]

Hi,

/*Steve Dickson*/ wrote on Thu, 26 Oct 2017 14:10:49 -0400:

Hello,

On 10/26/2017 09:57 AM, Steve Dickson wrote:

Hello,

In an upcoming release the libnfsdimap library
will be rolled into the nfs-utils package.
Meaning nfs-utils will be install libnfsidmap
instead of the libnfsidmap package.

The libnfsidmap name will stay the same
so I'm hoping there will not be any problems.
Just the owner of the library will change.

Questions:

1) What do I do with the old libnfsidmap package
since it will no longer be updated.

2) How do I notify the packages that are dependent
on the libnfsidmap package to change their dependency
to nfs-utils

3) Will this cause any build problems now that nfs-utils
will be installing the new library?

4) What am I missing?

First of all... thanks for all the input!!! Its definitely appreciated!!

Here is what has been added to the nfs-utils spec file.

Provides: libnfsidmap%{_isa} = %{epoch}:%{version}-%{release}
Provides: libnfsidmap-devel%{_isa} = %{epoch}:%{version}-%{release}

Obsoletes: libnfsidmap < %{version}-%{release}
Obsoletes: libnfsidmap-devel < %{version}-%{release}
As you are actually providing libnfsidmap & libnfsidmap-devel RPM 
packages, I think there is no need for the above. They were needed if 
you didn't put libnfsidmap in a separate RPM.
In your case, you are actually providing the same RPM packages, just 
from a different SRPM. So in the RPM repository, almost nothing is 
changed (except the name of SRPM which has produced those RPM packages, 
which has no effect on dependency resolution).





%package -n libnfsidmap
Summary: NFSv4 User and Group ID Mapping Library
Obsoletes: nfs-utils-lib
Group: System Environment/Libraries
BuildRoot: %{_tmppath}/%{name}-%{version}-root
BuildRequires: pkgconfig, openldap-devel
BuildRequires: automake, libtool
Requires(postun): /sbin/ldconfig
Requires(pre): /sbin/ldconfig
Requires: openldap

%description -n libnfsidmap
Library that handles mapping between names and ids for NFSv4.

%package -n libnfsidmap-devel
Summary: Development files for the libnfsidmap library
Group: Development/Libraries
Requires: libnfsidmap = %{version}-%{release}
Requires: pkgconfig

%description -n libnfsidmap-devel
This package includes header files and libraries necessary for
developing programs which use the libnfsidmap library.

A couple things are still not right
1) when I do the update of nfs-utils, libnfsidmap and libnfsidmap-devel
nfs-utils and libnfsidmap are installed correctly but the
libnfsidmap-devel is "replaced" by nfs-utils:

Upgrading:
  libnfsidmap   x86_64   1:2.2.1-0.fc28 @commandline   102 k
  nfs-utils x86_64   1:2.2.1-0.fc28 @commandline   413 k
  replacing  libnfsidmap-devel.x86_64 0.27-3.fc27

which basically ends up remove it.
Because you've said that nfs-utils package provides libnfsidmap-devel 
too. Actually, I would expect it to also remove libnfsidmap!


Regards,
Hedayat




2) 'dnf downgrade nfs-utils' I'm assuming should also downgrade libnfsidmap
 as well... but only nfs-utils is downgraded. BUT... if a
 'dnf downgrade libnfsidmap' is done, both libnfsidmap and nfs-utils are 
downgraded.

3) there no libnfsidmap-debuginfo rpm being built.

any ideas??

tia,

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


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

Re: is anybody using fedora-loadmodules.service and fedora-readonly.service?

[Hedayat Vatankhah]

Hi,

/*Zbigniew Jędrzejewski-szmek*/ wrote on Sat, 7 Oct 2017 07:18:59 +:

Two boot-time services provided by the venerable initscripts package:

<...>

- fedora-readonly.service: this is used to mount parts of the filesystem rw
   in case the system is using read-only root filesystem. To do anything this
   service checks if READONLY=yes is set in /etc/sysconfig/readonly-root.

   Is anybody using this? If yes, would it be OK if the service was not
   enabled by default anymore and would require an explicit 'systemctl enable
   fedora-readonly.service' or creating a custom preset (in addition to
   setting READONLY=yes) to be active?
I do! Yes, I don't care if it should be explicitly enabled, but I really 
hope that it won't vanish. I even don't care if you do not need to 
specify READONLY=yes if it is enabled explicitly (enabling it can mean 
that you really want READONLY=yes).






See https://bugzilla.redhat.com/show_bug.cgi?id=1493479 and
https://pagure.io/fesco/issue/1779 for some more info.

<...>
fedora-readonly.service is based on mounting tmpfs dirs, copying files
around, doing selinux fixups, manually mounting rpcfs and nfs, etc. I have never
seen fedora-readonly.service actually used, but that doesn't mean much.
If people are using them I'd love to hear about their use cases, and
think if we can provide the same functionality using more modern
mechanisms. Without breaking existing setups, I'd like to disable this
by default to simplify the boot process and not encourage the use in
new installations. ]
fedora-readonly.service is actually an advanced utility to let you 
configure the system to be used with fully or partly read-only root 
filesystem. I've used it, and are very likely to use it again and again 
in future, to deploy 'reliable' Fedora instances, which are either fully 
read-only, or let you write in a very specific locations and make sure 
that your / partition will never be corrupted for any reason. It is a 
great feature for using Fedora in embedded devices.


Anyway, I don't see why it can't be disabled by default, but I hope it 
is not removed... at least not until there is a replacement with 100% of 
its features.


Regards,
Hedayat




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

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

Re: Is it possible to upload new sources of a package from a URL?

[Hedayat Vatankhah]

/*Vít Ondruch*/ wrote on Tue, 3 Oct 2017 08:21:57 +0200:


Dne 2.10.2017 v 22:31 Hedayat Vatankhah napsal(a):

/*Björn Persson*/ wrote on Mon, 2 Oct 2017 16:28:02 +0200:

Dennis Gilmore <den...@ausil.us> wrote:

Today We rely on you as a packager
verifying the sources, and by uploading them directly you are saying
this is really what I intended to send you and I have ensured that it
is good.  You would need to work with release engineering and
infrastucture to come up with some way to sign off on the code being
used.

Like maybe writing a hash of the tarball in the sources file (with some
help from fedpkg perhaps) and checking that in? Then a server in the
Fedora Project infrastructure could fetch the tarball from the Source
URL in the spec and verify that it matches the hash.

I think it should work & it should be easy enough.

Also, instead of 'pulling down from random machines', it'd be enough
if it is not a random machine, but packager's fedorapeople space. It'd
be enough if there is a way to upload sources from there (and possibly
remove them automatically after that).

If the sources were downloaded from somewhere, then it should be the
SourceX URL, nothing else makes sense IMHO. I know that you can create
the source archive by yourself for various reasons, but that should be
exception, not the rule ...
I'd love that, which is what COPR is already doing (AFAIK) when you 
upload a SPEC. I suggested fedorapeople space if the packager is 
expected to hand the sources himself.


Hedayat





Vít
___



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

Re: Is it possible to upload new sources of a package from a URL?

[Hedayat Vatankhah]

/*Björn Persson*/ wrote on Mon, 2 Oct 2017 16:28:02 +0200:

Dennis Gilmore  wrote:

Today We rely on you as a packager
verifying the sources, and by uploading them directly you are saying
this is really what I intended to send you and I have ensured that it
is good.  You would need to work with release engineering and
infrastucture to come up with some way to sign off on the code being
used.

Like maybe writing a hash of the tarball in the sources file (with some
help from fedpkg perhaps) and checking that in? Then a server in the
Fedora Project infrastructure could fetch the tarball from the Source
URL in the spec and verify that it matches the hash.

I think it should work & it should be easy enough.

Also, instead of 'pulling down from random machines', it'd be enough if 
it is not a random machine, but packager's fedorapeople space. It'd be 
enough if there is a way to upload sources from there (and possibly 
remove them automatically after that).



Having a mirror of upstream SCM or something like it might also work 
too. (But some upstreams might not have any (public?) SCM).


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

Re: Bodhi doesn't recognize new packages when creating a new update

[Hedayat Vatankhah]

/*Randy Barlow*/ wrote on Fri, 29 Sep 2017 15:04:07 -0400:

On 09/29/2017 03:54 AM, Hedayat Vatankhah wrote:

I've recently added 2 new packages, but when I tried to add them to
F27/F26 updates, it doesn't recognize them in the "Packages" box and
says: "Unable to find any packages that match the current query". BTW, I
can create the desired update, the only inconvenience is that Bodhi
doesn't provide any auto-completion assists.

I guess it is not the expected behaviour. You can try
'golang-github-dchest-siphash' as an example.


I took a look into this - it seems that Bodhi's JavaScript is querying
this URL, which is the packages app:

https://apps.fedoraproject.org/packages/fcomm_connector/xapian/query/search_packages/{"filters":{"search":"golang-github-dche"},"rows_per_page":10,"start_row":0}

I believe the packages app has not been updated to work with all the new
sources of truth now that pkgdb is gone.

In any case, that is just a convenience method to aid in autocompleting
that form, so the workaround as you found is just to type the nvrs into
the builds box and things will work as expected from there. You may also
use the bodhi CLI to do the same.


Thanks for the comments and looking into the problem.

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

Bodhi doesn't recognize new packages when creating a new update

[Hedayat Vatankhah]

Dear all,
I've recently added 2 new packages, but when I tried to add them to 
F27/F26 updates, it doesn't recognize them in the "Packages" box and 
says: "Unable to find any packages that match the current query". BTW, I 
can create the desired update, the only inconvenience is that Bodhi 
doesn't provide any auto-completion assists.


I guess it is not the expected behaviour. You can try 
'golang-github-dchest-siphash' as an example.


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

Re: Package add request

[Hedayat Vatankhah]

/*Jason L Tibbitts Iii*/ wrote on Tue, 26 Sep 2017 22:49:18 -0500:

"HV" == Hedayat Vatankhah <hedayat@gmail.com> writes:

HV> I'd say to stick with upstream naming, which is the Fedora
HV> way. Changing the names to lower case is a must in Debian, they
HV> simply don't allow upper case letters to be in package names. The
HV> developer clearly prefers ZeGrapher, so I think according to Fedora
HV> naming guidelines, ZeGrapher is preferred.

Well, those guidelines do say:

"Package names should be in lower case and use dashes in preference to
underscores."

https://fedoraproject.org/wiki/Packaging:Naming, under "General Naming".

Upper case names aren't forbidden, of course, but there is a definite
and clearly-stated preference for lower case names.

What about this:
https://fedoraproject.org/wiki/Packaging:Naming#Case_Sensitivity

Keep in mind to respect the wishes of the upstream maintainers. If they 
refer to their application as "ORBit", you should use "ORBit" as the 
package name, and not "orbit". However, if they do not express any 
preference of case, you should default to lowercase naming.





  - J<

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

Re: Package add request

[Hedayat Vatankhah]

/*Samuel Rakitničan*/ wrote on Mon, 25 Sep 2017 23:15:25 -:

Here it is: 
https://copr.fedorainfracloud.org/coprs/srakitnican/default/build/607839/

Still not sure about naming issue, package wants to name files ZeGrapher, I 
called the package zegrapher, debian maintainers go a step further and call 
package files zegrapher also.
I'd say to stick with upstream naming, which is the Fedora way. Changing 
the names to lower case is a must in Debian, they simply don't allow 
upper case letters to be in package names. The developer clearly prefers 
ZeGrapher, so I think according to Fedora naming guidelines, ZeGrapher 
is preferred.


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

Re: Package add request

[Hedayat Vatankhah]

/*Samuel Rakitničan*/ wrote on Mon, 25 Sep 2017 23:15:25 -:

Here it is: 
https://copr.fedorainfracloud.org/coprs/srakitnican/default/build/607839/

Still not sure about naming issue, package wants to name files ZeGrapher, I 
called the package zegrapher, debian maintainers go a step further and call 
package files zegrapher also.
I'd say to stick with upstream naming, which is the Fedora way. Changing 
the names to lower case is a must in Debian, they simply don't allow 
upper case letters to be in package names. The developer clearly prefers 
ZeGrapher, so I think according to Fedora naming guidelines, ZeGrapher 
is preferred.


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

Re: Is it possible to upload new sources of a package from a URL?

[Hedayat Vatankhah]

/*Matthew Miller*/ wrote on Tue, 26 Sep 2017 09:28:07 -0400:

On Mon, Sep 25, 2017 at 11:38:07PM +, Tim Landscheidt wrote:

If data volume is expensive or difficult for you, you could
look into renting a (virtual) private server and then devel-
oping there via ssh.  Offers usually start at less than
$ 5,-/month.  (I'm not aware of free solutions; it's proba-
bly easier to solicit donations for one's own server than to
get access on someone else's.)
Thanks. Doesn't look expensive, but if it is only used for occasional 
package builds, it is probably still a waste.




There is a thing called "DPLY" which gives free access to a Digital
Ocean-based droplet for 2 hours (you can pay for more).

Here's the link to deploy Fedora 26: https://dply.co/b/f4BVCJuS

It's only a small instance and not suitable for a lot of things, but
might be good enough to validate and upload your large sources.

Thanks, it looks more promising for such tasks, I'll bookmark it.


However, is it really that hard/problematic/.. for Fedora to support 
such a use case? Certainly it'd be much more convenient for packagers if 
such a small (at least, this is how I look at it!) enhancement is made.


If yes, then apparently using a third-party system is the only option.

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

Re: Is it possible to upload new sources of a package from a URL?

[Hedayat Vatankhah]

/*Richard W.m. Jones*/ wrote on Mon, 25 Sep 2017 10:11:55 +0100:

On Sun, Sep 24, 2017 at 10:56:45AM +0330, Hedayat Vatankhah wrote:

Dear all,
Currently, AFAIK, the suggested method to upload new sources for a
package is using 'fedpkg new-sources' which uploads new sources from
your local system. I wonder if there is a method to upload new
sources from a URL rather than your local filesystem? It is
specially useful for large packages.

I wanted that, especially back in the day when I was managing mingw-qt
(IIRC ~ 100 GB of sources, requiring me to download and upload it all).
But no, AFAIK it's not possible.
:O Great! Currently, I can't even imagine maintaining any packages over 
few megabytes (maybe 100MiB tops, which will be a pain!), but not much 
long before, I had a hard time uploading a 21MiB data... specially since 
there is no way to resume uploading a source to look-aside cash (AFAIK). 
I was forced to retry a few times and pray so that it can be completed! :)


Bye,
Hedayat




Rich.



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

Re: Is it possible to upload new sources of a package from a URL?

[Hedayat Vatankhah]

/*Pierre-yves Chibon*/ wrote on Mon, 25 Sep 2017 09:38:39 +0200:

On Sun, Sep 24, 2017 at 10:56:45AM +0330, Hedayat Vatankhah wrote:

Dear all,
Currently, AFAIK, the suggested method to upload new sources for a package
is using 'fedpkg new-sources' which uploads new sources from your local
system. I wonder if there is a method to upload new sources from a URL
rather than your local filesystem? It is specially useful for large
packages.

It's an interesting idea but then it would become quite hard to check if there
is a mitm attack of some sort. With the current process, at least the packager
has the possibility to check the sources locally before uploading them into
Fedora.
The solution would be to provide the sha + the url and let the down be server
side but that won't save you from downloading the sources locally first.
Yes, but even if I'm forced to download locally, it is much better than 
being forced to upload it again. (Also, note that the current process 
doesn't prevent MITM if it happens when I download the source).
Also, it is easier to schedule the download for a time when it is 
cheaper (or free), but it'd be harder to do it for an upload since it 
requires authentication.


I wonder where I can fill an RFE for this feature. The current situation 
is a blocker for people like me to maintain any package with large 
source/data archives. I saw COPR supports a similar thing, and I hope 
Fedora will support it too.


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

Is it possible to upload new sources of a package from a URL?

[Hedayat Vatankhah]

Dear all,
Currently, AFAIK, the suggested method to upload new sources for a 
package is using 'fedpkg new-sources' which uploads new sources from 
your local system. I wonder if there is a method to upload new sources 
from a URL rather than your local filesystem? It is specially useful for 
large packages.


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

Re: getting kernel-devel added

[Hedayat Vatankhah]

 Hi,


/*Ben Williams*/ wrote on Tue, 12 Sep 2017 11:35:08 -0400:

hello

This is an issue i am seeing with new users:

I was at a University installfest this weekend and this was the major 
issues for Endusers.


case A) Students are using Fedora on windows in a VM (Vbox in this 
case) for a class. they are required for said class to install the 
guest additions. they are constantly running into errors that the 
guest addidions will not build  (there install does not have 
kernel-devel install.  They used the F26 release so now have the 
release kernel and so they install sudo dnf install kernel-devel and 
still have issues (kernel and kernel-devel versions do not match).


Case B) third party video or wireless driver same issue no 
kernel-devel, no wireless no internet == fix by sneakernet



Both of these issues can be easily fixed by including kernel-devel in 
a group or by adding kernel-devel to all the Desktop Environment 
kickstarts.
Including kernel-devel will add lots of stuff (e.g. gcc) which are 
needed to compile something. Which, I think won't happen. kernel - 
kernel-devel version mismatch is something that happens a lot, so maybe 
something should be done for that.






To me this simple fix will help our new users and will not leave such 
a unfriendly feeling (and hopeful increase our contributor base down 
the road)


Ben

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


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

Re: Splitting AppStream data into Workstation/Server

[Hedayat Vatankhah]

/*Igor Gnatenko*/ wrote on Fri, 01 Sep 2017 15:19:34 +0200:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2017-09-01 at 16:01 +0300, Marius Vollmer wrote:

Neal Gompa  writes:


Implement your AppStream filter at the application level, rather
than
messing with appstream-data package.

Yes, of course.  Cockpit will do the right thing even with the full
appstream-data package.  This is only about not having 15 MiB of
useless
data installed.

Just check how much data you download for repository metadata.. 


15MiB can be important if you want to have a cockpit container (in which 
you won't store repo metadata too).


And I still hope Fedora repository metadata madness (which has become 
even worse as tools evolved!) will be fixed/improved one day...



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

Re: RFC: retiring yum

[Hedayat Vatankhah]

Hi,

/*Igor Gnatenko*/ wrote on Fri, 01 Sep 2017 19:01:49 +0200:

<..>
Do you still have some critical missing functionality in DNF? And let
us know reasons why would you like to keep YUM available (hopefully
there are no)!
I've not tried 'dnf  remove --duplicates' yet, but if it behaves similar 
to 'dnf  remove --assumeno $(dnf -C repoquery --duplicated 
--latest-limit -1 -q)', then there is still no 'sane' way to remove 
duplicated packages, which might be needed if 'dnf upgrade' is 
terminated half-way. There is also a RFE at [1] for such scenarios, but 
it would be enough is 'dnf remove --duplicates' doesn't try to remove 
other packages as dependencies of duplicated packages, or even better, 
if 'dnf upgrade' is able to 'sanely' continue a terminated 'dnf upgrade' 
operation instead of complaining about conflicts and being unable to 
proceed. Currently, the user must know that the problem is duplicated 
packages, and learn how to safely remove them without removing other 
required stuff.



[1] https://bugzilla.redhat.com/show_bug.cgi?id=1091702

___
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

[Hedayat Vatankhah]

/*Colin Walters*/ wrote on Tue, 18 Jul 2017 15:43:12 -0400:

On Tue, Jul 18, 2017, at 02:58 PM, Chris Murphy wrote:


But if I've understood correctly, any changes to the base will be discarded
when you update the base image. right?

No; `rpm-ostree install` is persistent, and so are other changes like
`rpm-ostree initramfs --enable` and so is the recently added `ex override`:
https://github.com/projectatomic/rpm-ostree/pull/852

A bit more information about layering and live changes:
http://www.projectatomic.io/blog/2017/06/rpm-ostree-v2017.6-released/

Thanks. But, is it also true for package removals? e.g. If I remove 
package foo, it won't appear again when the base image is updated, 
correct? (If correct, will it be downloaded and discarded, or it won't 
be downloaded in the first place?).


Regards,
Hedayat

___
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

[Hedayat Vatankhah]

/*Richard Hughes*/ wrote on Thu, 20 Jul 2017 09:24:10 +0100:

On 20 July 2017 at 04:10, Kevin Kofler  wrote:

It's even required. There is no support for unbundling anything beyond the
runtime at all, nor can runtimes share files without duplicating them.

Sure they can. If you install the KDE runtime and the GNOME runtime,
these are both built upon the Freedesktop runtime and share a huge
number of files. Any duplicate files get deduplicated on disk -- you
don't even download the duplicates when you update either or both of
them.


As Fedora is going to use (IIRC) Flatpack's in OCI format rather than 
ostree, does it also work with OCI images? Both deduplication on disk, 
and also delta-downloads?

___
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

[Hedayat Vatankhah]

/*Chris Murphy*/ wrote on Tue, 18 Jul 2017 09:28:53 -0600:

On Tue, Jul 18, 2017 at 8:19 AM, Dominik 'Rathann' Mierzejewski
 wrote:

...


"One size fits everyone" approach can be dangerous. It never does, in
fact, fit everyone, and often sacrifices flexibility and resource usage
for the convenience of a single image.

I, for one, like to keep my installations minimal and I often uninstall
optional (weak) dependencies manually. With Atomic base I wouldn't
be able to modify the base easily on my system(s).

It's a layered approach. rpm-ostree does let you unlock the base and
install and remove RPMs. You could also run the server side component
that turns RPMs into ostrees yourself (locally or in cloud) and have
however many trees you want, and establish your own rebase policy for
your workstations.
But if I've understood correctly, any changes to the base will be 
discarded when you update the base image. right?


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

Re: Issues with Recovery and Documentation

[Hedayat Vatankhah]

/*Gerald B. Cox*/ wrote on Fri, 7 Jul 2017 12:04:23 -0700:

<...>
the process was able to find my installation and mount it under 
/mnt/sysimage


Then it says:  If you would like to make your system the root 
environment, run the command:


chroot /mnt/sysimage

I then get the response:
chroot:  failed to run command '/bin/bash':  Input/output error

I checked and it is there.  What's going on?


Using a 32-bit CD with a 64-bit system or the other way around; I guess.

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

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Hedayat Vatankhah]

/*Adam Williamson*/ wrote on Fri, 23 Jun 2017 12:45:07 -0700:

On Fri, 2017-06-23 at 09:06 -0400, Neal Gompa wrote:

You have run into the purest form of open source, the "scratch your
own itch" case.  You want to be able to do things that cannot be done
today, and nobody else is working on it.  It seems like you have a
really good foundation for what needs to be done, so perhaps you could
start a project to work towards what you need?  If you publicize it,
you might even get some contributors to join you.


I'll be honest, I have been thinking about it... Maybe I'll have
something soonish. ;)

Did you actually check yet whether virt-builder is sufficient for your
purposes?
I'd say the difference is comparable to the difference of containers vs 
VMs: sometimes you need user-land of another arch, but do not want to 
run a full VM. For example, it can be used to compile for another arch. 
So, you might want to build a rootfs with compiler &  libraries (but not 
a complete system image with kernel & ...).
As an example, you might refer to rootfs tarballs used for scratchbox to 
compile for different architectures.


Actually, as Fedora does NOT provide cross compilers (e.g. to build user 
land ARM applications under x86_64), it can be used to provide 'The 
Fedora Approach to Cross Compiling'. To create a minimal rootfs with ARM 
compilers & libraries which can be used using qemu to run ARM GCC in the 
rootfs to build your packages.


This is actually how I do cross-compiling in Fedora: I grab a Fedora ARM 
image, install qmeu-user binaries on the host, copy qemu ARM binary into 
the rootfs (even bind-mounting /lib64 before I know we have qemu static 
binaries in Fedora!), patch its DNF to work fine under qemu, install 
required software using 'chroot dnf install ...', bind mounting the 
source directory, chrooting to the rootfs and build the software.


I've always preferred using scratchbox or the above method to compile 
ARM binaries rather than using a full VM, which plays much nicer on my 
pretty-old laptop! :)


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

Re: Modularity and packagers [was Re: PkgDB and the ArbitraryBranching Change]

[Hedayat Vatankhah]

/*Adam Samalik*/ wrote on Fri, 9 Jun 2017 08:50:58 +0200:



On Thu, Jun 8, 2017 at 10:49 PM, Randy Barlow 
> 
wrote:


On Thu, 2017-06-08 at 22:17 +0200, Adam Samalik wrote:
> You add the package and other people start to use it. That's great
> until you need to change the version, but can't, because other
people
> started to use it as a dependency and it would break their stuff.

I recently heard that it will be impossible to install two packages
that depend on different versions of a dependency at the same
time. For
example, if package A depends on C < 2.0 and package B depends on C >=
2.0, it will be impossible to install A and B on the same system. Is
this true? If so, I worry that we will see fracturing in Fedora as
packages drift apart in their dependencies. If not so, I apologize for
the noise ☺


I would say it's "half truth" right now. :-)

There has been no extra work on changing RPMs. If something conflicts 
now, it will keep conflicting. But!






So, not everything will probably be installable as RPMs on the same 
system at the same time. But I see the world is going to containers, 
and I'm thinking if not being to install all RPMs next to each other 
on a single system is still a real problem. Thoughts?



Actually, I think the Modularity work can (potentially) provide a 
solution for installing multiple versions of the same package for RPM 
(assuming that the packages are properly packaged so that different 
versions don't conflict with each other, e.g. two versions of a library 
like boost).
For example, library versioning makes it possible to install multiple 
versions of the same library in a system. However, RPM doesn't allow it 
(except that you use a different package name for them, so they are NOT 
the same package in RPM's view) except for kernel as an exception. IIRC, 
one of the reasons for this is that RPM doesn't know how to handle 
updates of that package. (e.g. there are foo-1 & foo-2 installed, and 
now foo-3 is available. What happen when you try to update foo?). For 
kernel, it is never updated. New versions are just installed.


However, if Modularity becomes a first class citizen for RPM/DNF, it is 
possible to solve this problem too. You know that you should install (if 
possible!) different versions of the same package simultaneously if they 
are required by different modules, and you know that a new version of 
the package in a module should update the previous version of the 
package from that module.


But, well, using containers and things like FlatPack/Snappy, such 
complexity might seem not necessary. But going that way, the Modularity 
itself maybe also can be replaced largely with them too (the only 
missing peace I can think of right now is when you need an Apache 
version which is newer than that of CentOS/EPEL, but older than that of 
not EOL-ed Fedora releases).


Regards,
Hedayat


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

Re: [RFC] delta-repository-metadata

[Hedayat Vatankhah]

Hi!

I'm trying it under F25. First, thanks for working on it! It'd be a 
great feature. However:


1. I run it, and it was running for too long (probably 10 minutes!) with 
absolutely no log. I found that it is working on a 200M 
filelists.xml.gz.part file in DNF cache (which is apparently an 
uncompressed filelists file). And I guess it also downloads some data 
(at least the .zsync file, and probably also the new data) again without 
any reports to the user.


2. Finally, it finished, and this is the result:

dnf update -vvv --disablerepo="rpmfusion*" --disablerepo=fedora
cachedir: /var/cache/dnf
Loaded plugins: local, noroot, needs-restarting, debuginfo-install, 
zsync, protected_packages, copr, playground, builddep, repomanage, 
Query, reposync, download, config-manager, generate_completion_cache

DNF version: 1.1.10
repo: using cache for: localfedora
not found deltainfo for: Local Fedora 25 - x86_64
not found updateinfo for: Local Fedora 25 - x86_64
repo: using cache for: group_rpm-software-management-deltamd
not found deltainfo for: Copr repo for deltamd owned by 
@rpm-software-management
not found updateinfo for: Copr repo for deltamd owned by 
@rpm-software-management

repo: using cache for: _dnf_local
not found deltainfo for: _dnf_local
not found updateinfo for: _dnf_local
Error: Cache-only enabled but no cache for 'updates'


3. I have not used -C option with DNF, so I wonder why it is 
complaining! Also, the filelists.xml.gz.part file is still there, so I 
guess zsync has not completed its task completely.



Note: I've interrupted the command once the first time after installing 
the plugin, and run it again. I wonder if the interruption has anything 
to do with the problem.



And I think if it is going to always take so much time for filelists 
file, maybe it is better to make zsync use the compressed file instead 
of uncompressed data for big files.



Regards,

Hedayat



/*Igor Gnatenko*/ wrote on Thu, 27 Apr 2017 19:02:02 +0200:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello users and developers,

We had presented deltametadata project at DevConf.CZ 2017[0], goal of
this project is to minimize bandwidth required on clients to update
repository metadata (repomd.xml, primary.xml, etc.) which would improve
user experience with DNF.

So, we have DNF plugin which acts

How to try it?
1. dnf -y copr enable @rpm-software-management/deltamd
2. dnf -y install dnf-plugin-zsync

If something doesn't work, look into /var/log/dnf.log.


We would like you to try it out and give feedback, it is very important
for us! Just send it as reply to this message..

P.S. F25 and above are supported


[0] https://www.youtube.com/watch?v=l6uWxg3yMmw
- -- 
Regards,

lab-q Red Hat
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlkCJAoACgkQaVcUvRu8
X0wrGg/+Lvb/up8swQR6Nd9BacvrubhgELvOcOIsv/69aMPqe9cDqmAKUr33AWik
zUWbAwpkS79BLLKjoxHTxR379Ubmj5mCWyuufg/HCgeCHOZwIBEQzqrBjwKMsIN+
ts6Qk7mo1bsgS3xozx/tRH+N1xhx1O+UInsDxS1qKQ5KIBntf/e8ZrgFL/fbjHYx
/JVlz2p44tZxMHCsZP/hJv+DKV+AaY9/NcvLh2KBvpj75h8cVA3RkSE85YgNFNyD
GJRjkzv+swmwWXVZMd0XNiCKKXn+qGooMsrrjAmbousG/Gd/DmTQekuO/hIkGZ+g
rjSCPRjLXe+utD2lnqK5aWm1nJvaEUTjTAWKYAhV0mAAT/Y4Y8S2XcsdY6EXxiW6
iSYmXa4Rz4rTYiZ+K2XXYoEIGDVSN8C5lQyYy4Qqg2lnAyKDZ1567s/4fCz/IYpB
rpDv+4jX1o3C8RY0XUuCYkt+/IpVH+1/DfkhWJCG2rNLDpnq5R7N4cryJg0MClW1
PUw24GJFbIwWnl6he0n+ShJ6wzZvd2jHwFBVj5a/718wech3YnIfSHf/xJeIE6Nn
dK716wgmHUPyjCwk/cWQWdj5x99lMiDZJIXXFTu0zGLxXcHzz9MnZjDCv219u6XU
Vj0dCKWa3SoLml+zmRkqb+T4acyyXlwPBahRFXN3qBhFpqoA/MY=
=5ar8
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora

[Hedayat Vatankhah]

/*Mikolaj Izdebski mizde...@redhat.com*/ wrote on Wed, 25 Feb 2015 
10:07:28 +0100:

On 02/25/2015 06:39 AM, Hedayat Vatankhah wrote:

However, if there are JAR files which are useful
for a developer, they can have a -legacy version too!

There is no technical reason to suffix anything - you can put JARs that
depend on old version of JDK in /usr/{share,lib}/java-x.y.z, for example
/usr/share/java-1.7.0/ for JARs that require JDK 7.

There is: I'm talking about rpm packages, and you can't install multiple 
rpm packages with the same name simultaneously. So, you'll need to 
change the name. BTW, -legacy was just an example. I'd prefer 'versioned 
package names' as in my proposal for libraries.


Hedayat
-- 
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: Legacy implementations of the Java platform in Fedora

[Hedayat Vatankhah]

/*Kevin Kofler*/ wrote on Wed, 25 Feb 2015 01:31:59 +0100:

Jaroslav Reznik wrote:

= Proposed System Wide Change: Legacy implementations of the Java platform
in Fedora =
https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora

Change owner(s): Jiri Vanek jva...@redhat.com

IMHO, this is not implementable for a simple practical reason: All the JARs
we ship are built from source with our default JDK. They will in general NOT
work on any JRE that's older than the default JDK. (A JRE/JDK that's NEWER
than the default JDK can work though, e.g., the java-1.8.0-openjdk packages
in Fedora 19 and 20. But we were already providing those.)

 Kevin Kofler

I'd say this proposal is very similar to my proposal[1] for libraries: 
the legacy JDKs can be useful for the user when facing with non-Fedora 
development. IMHO, it is fine, and even great, that no Fedora JARs will 
depend on legacy JDK. However, if there are JAR files which are useful 
for a developer, they can have a -legacy version too!


Regards,
Hedayat


[1] Proposal to (formally/easily) allowing multiple versions of the 
same library installable thread
-- 
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 to (formally/easily) allowing multiple versions of the same library installable

[Hedayat Vatankhah]

/*Ralf Corsepius rc040...@freenet.de*/ wrote on Mon, 16 Feb 2015 
17:17:32 +0100:

On 02/16/2015 05:10 PM, Martyn Foster wrote:



On 16 February 2015 at 15:12, Kevin Kofler kevin.kof...@chello.at
mailto:kevin.kof...@chello.at wrote:

Christopher Meng wrote:
 Maintaining several version of the same library is not easy as 
you think,
 basically once a developer wants to install version X while 
then another
 people want to deploy things based on version Y, how to crack 
this nut?

 You can't just care about runtime.

Then you need to patch one or the other package to work with the 
same
version. Only if that is not possible, a compatibility library 
can be

considered. But we should always first try to make everything work
with the
same version (if possible, the newer one).


The requirement to work with multiple versions of a package come up in
the scientific/HPC community very frequently. Its not always about API
compatibility, sometimes exact numerical reproduction is required which
isn't preserved even between minor versions (i.e. an OS update).

I don't buy this argument wrt. Fedora.

Fedora is a rapid moving, forward looking distro, in which such 
regressions should be fixed and not be worked around by compat-libs.


Ralf




I guess the main point is missed completely. The main proposal is not 
mainly about compatibility. It's about providing latest development 
libraries in stable releases for *user* consumption (not for distro 
one). Also, the compatibility package is solely provided for user 
consumption; *no* Fedora package should be built against it (unless it 
happens already).


There are some arguments against providing such thing in Fedora, but if 
someone wants to install two versions of the same library (e.g. 
installing the latest version for development while having default 
version for Fedora packages); he'll do it anyway. So, if such packages 
are not provided by Fedora, he will install from source. So, the user 
will install multiple versions anyway. Do you want to support him, or not?


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

Proposal to (formally/easily) allowing multiple versions of the same library installable

[Hedayat Vatankhah]

Dear all,
I don't know if this has been discussed before, but I didn't find any.

Summary: I have a proposal to make it easier for maintainers to have 
multiple versions of the same library in distro (by making it 
*naturally* possible) (and with minimal maintenance overhead), and for 
users/developers to get their desired version(s) installed. Proposal in 
brief: instead of packaging libfoo as libfoo, the maintainer *can* 
package it as libfooVER (e.g. libfoo2) and create libfoo/libfoo-devel 
package which depends on libfoo2/libfoo2-devel. Now, libfoo-3 package 
can be packaged as libfoo3, and both can be installed simultaneously 
(assuming that they provide different .so versions, otherwise it could 
be provided as an update to libfoo2). Notice that once libfoo2 is in the 
repos, newer versions (libfoo3/libfoo4)  should not require a package 
review.


Introduction: As a developer, it happened to me a lot to *wish* my 
Fedora version could also have a newer version of libfoo, and I'm not 
forced to either upgrade to/wait for the next Fedora release or install 
the package just to get a newer version. Also, I've seen many situations 
in which I or another user wanted to have multiple versions of the same 
library installed (e.g. to run some third party programs).
Currently, this is not possible in Fedora because RPM doesn't allow you 
to install multiple versions of the same package (e.g. libfoo). But, 
this has been workaround from time to time for some libraries; a good 
example is Qt. Qt can't be easily upgraded to version 5 since many 
fundamental packages (e.g. KDE) depend on it, but if Fedora didn't 
provide Qt5 packages it would be left behind considerably. So, you can 
see qt5-* packages in Fedora repository (IIRC, a similar situation has 
happened for Qt3-Qt4 upgrade). However, they certainly had to review 
all such qt5 packages, and also this is a temporary solution for this 
library.


Proposal: let's make it possible to have multiple versions of the same 
library installed, as far as their .so version permits that.


1. Include the base version of the library into its package name. So, 
instead of libfoo we can have libfoo2, libfoo3, libfoo4.
2. No reviews are required for new libfooX packages (as it is not 
required right now when you update your libfoo package).
3. For each Fedora release, there is libfoo/libfoo-devel packages which 
Require the default version of libfoo packages for that release. For 
example, libfoo.fc20/libfoo-devel.fc20 will Require 
libfoo2/libfoo2-devel; for F21 libfoo3/libfoo3-devel and for F22/Rawhide 
libfoo4/libfoo4-devel.
4. Each Fedora release can provide at least 3 versions of libfoo. e.g. 
F21 provides libfoo3 as default libfoo, libfoo2 as compat package, and 
libfoo3 as 'latest stable version'. This should not create much burden 
for the maintainer, since he is already maintaining these 3 versions for 
different Fedora release versions. Now, he can provide all of them in 
all active Fedora releases.
5. Packages should either built against the 'default version' (build 
requiring libfoo-devel), or the next version if strictly needed. 
Building against 'old' version should be discouraged/forbidden. So, in 
above example, no F21 packages are allowed to be built against libfoo2, 
which is the compatibility libfoo package in F21.


For -devel packages, two methods can be allowed:
1. Simple: -devel packages conflict with each other, so while you can 
have multiple versions of libfoo installed, you can have only a single 
version of libfoo-devel installed
2. Flexible: Provide the possibility of installing multiple -devel 
versions, and a method to select the default one, like the 
alternatives system.


More details can be discussed, but I think it's enough for now. I want 
to see what others think about the whole idea. Details can be worked out 
if the idea seems interesting.


Q: Can't a packager do it already? Why propose it as a 'proposal'?
A: Yes, he can, but it'll be hard; mainly because he'll need to put new 
versions of the library for review. Also, I suggest it as a 'recommended 
practice' for packaging libraries.


IMHO, this method will have many advantages, and can make it much easier 
to provide COPR repositories or similar to experiment with new things on 
a stable Fedora release without affecting other installed software. 
Also, it might make it possible to install and experiment with some 
packages from Rawhide/next Fedora release directly on your current release.
As a developer, it makes the version of available libraries for 
development less bounded to Fedora version.


Regards,
Hedayat
-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Hedayat Vatankhah]

/*Bill Nottingham nott...@splat.cc*/ wrote on Wed, 7 Jan 2015 10:56:31 
-0500:

Hedayat Vatankhah (hedayat@gmail.com) said:

/*Bill Nottingham nott...@splat.cc*/ wrote on Tue, 6 Jan 2015 11:39:27
-0500:

...
- Even searching for -devel packages implies a target == host build
   sensibility that is relevant mostly to those developing Fedora, and
   not to most of those developers that I run into on a day-to-day basis
   (and likely not the developers we're targeting.) They're interested
   in using mock along with system libraries for RHEL/CentOS, using
   pip/npm/rubygems, etc.

So you mean that Fedora target developers are either using dynamic
languages, or they develop native software for RHEL/CentOS?! So you believe
that target == rhel/centos? And native software developers for *modern*
distros are not targets? This is really offending. RHEL/CentOS themselves
should mainly target their developers. I guess that most of the developers
you run into are working for RedHat.

... Not at Red Hat now, but what I'm saying is that the developers I
interact with are targeting mainly Ubuntu LTS and CentOS/RHEL, even if their
devel platform is Fedora.  It goes back to uses of Fedora in production -
while Fedora Server certainly wants to change this, most all of the
*deployed* server systems that people are targeting for their code aren't
Fedora.  Once you assume that you want to support the use case of developers
using Fedora to develop for things that aren't Fedora, I just feel
that worrying about a package tool for installing -devel packages pales in
trying to streamline the workflows the developers needs around using things
like mock and jenkins as build tools, and test environments that aren't even
local to the machine at all, whether they involve virtualization,
containers, or remote cloud services.
Well, I agree completely that solving the issue of installing -devel 
packages is not enough to make Fedora suitable for developers; but it is 
certainly needed. However, it would be even better if Fedora can be a 
great general purpose development platform supporting development for 
other targets such as RHEL/CentOS, Ubuntu and even Windows (using mingw 
toolchain + wine, and then maybe virtual environments/remote access to 
run/test/debug on real Windows OS); which could expand to development 
for embedded devices/OSes like Android. But, IMHO, support for none of 
these should be more important than native Fedora development; specially 
since targeting OSes like RHEL/CentOS/Ubuntu LTS is usually important 
for developers for commercial software. Someone who is developing 
free(open source) software usually prefers to use 'latest and greatest', 
for which usually Fedora and it's -devel packages are one of the best 
things available out there. And I think free software developers should 
be top priority for Fedora compared to others. There is nothing wrong 
with supporting others, but the main target developers should be free 
software developers, and they are less likely to need using mock or RHEL 
system libraries.


Regards,
Hedayat






Bill


-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Hedayat Vatankhah]

/*Michael Catanzaro mcatanz...@gnome.org*/ wrote on Tue, 06 Jan 2015 
13:51:24 -0600:
On Tue, Jan 6, 2015 at 1:28 PM, Stephen John Smoogen 
smo...@gmail.com wrote:


So you mean that Fedora target developers are either using
dynamic languages, or they develop native software for
RHEL/CentOS?! So you believe that target == rhel/centos?



No, you misread his comment, he's actually saying the opposite. You 
both agree on that point. Happy Tuesday.




If that's the case as you and Stephen J Smoogen say, I'm sorry.

Regards,
Hedayat
-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Hedayat Vatankhah]

/*Bill Nottingham nott...@splat.cc*/ wrote on Tue, 6 Jan 2015 11:39:27 
-0500:

...
- Even searching for -devel packages implies a target == host build
   sensibility that is relevant mostly to those developing Fedora, and
   not to most of those developers that I run into on a day-to-day basis
   (and likely not the developers we're targeting.) They're interested
   in using mock along with system libraries for RHEL/CentOS, using
   pip/npm/rubygems, etc.
So you mean that Fedora target developers are either using dynamic 
languages, or they develop native software for RHEL/CentOS?! So you 
believe that target == rhel/centos? And native software developers for 
*modern* distros are not targets? This is really offending. RHEL/CentOS 
themselves should mainly target their developers. I guess that most of 
the developers you run into are working for RedHat.


Notice that -devel packages are not useful only for developing Fedora. I 
work in a company in which everyone else is using Ubuntu, and that is 
their target OS for their software. However, I use Fedora and its -devel 
packages (unless they doesn't exist or too old), but my code compiles 
fine on their Ubuntu too. And it should compile on any other distro 
which have packages with comparable versions.  So, Fedora -devel 
packages are useful for developing software for any modern distro, but 
you want to target specific distributions?!


Regards,
Hedayat

-- 
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: Yet another frustration with Fedora package management

[Hedayat Vatankhah]

/*Radek Holy rh...@redhat.com*/ wrote on Mon, 5 Jan 2015 03:03:30 
-0500 (EST):



*From: *Hedayat Vatankhah hedayat@gmail.com
*To: *Development discussions related to Fedora
devel@lists.fedoraproject.org
*Sent: *Saturday, January 3, 2015 9:42:01 PM
*Subject: *Yet another frustration with Fedora package management

Hi!
Summary: Try to prevent a package from being updated/installed
from repositories regardless of the package management tool you
use. As it seems, then only way you can do this is to exclude it
from the repositories themselves inside their configuration file
in /etc/yum.repos.d/, because these are the only common settings
between all three (yum/dnf/PackageKit). TBH, I'm not sure about
PackageKit, but I feel that it don't read /etc/dnf/dnf.conf as it
doesn't use DNF but its backends. This is fine if the package is
in a single known repository, but what if it is in 3 repositories
that you might not be aware of all of them?

More details:
As you might already know, nvidia drivers in RPMFusion F21
repositories doesn't work for all nvidia cards. In one system, I
finally installed akmod-nvidia from RPMFusion F20 repositories
which worked fine. Soon after I realized that I should exclude
akmod-nvidia and dependencies from F21 repositories. I added
exclude=*nvidia* to /etc/yum.conf as I was lazy to check which
repository these packages come from. But then I noticed that dnf
doesn't consider it excluded. Then I thought that probably
PackageKit doesn't use dnf.conf too. So, how should I excluded
these packages? Well, these were in rpmfusion-nonfree-updates
repository, so I added the exclude directive there. Then I found
that I should add it to rpmfusion-nonfree repository too. However,
since I use yum-plugin-local I also have a local repository (I
actually copied the repository from another system, so it was
enabled on this system so that I could install software from it)
which also included these packages. Therefore, I should exclude
*nvidia* in 3 repository configuration files to make sure
(hopefully!) that these will not be installed by any package
manager I know.

Suggestion: Please add a single configuration file to configure
common package manager options (Specially between DNF and
PackageKit, which are there to stay). As I mentioned in F21
downloads repository metadata in 3 places! thread, Fedora package
management should be consistent and integrated; and the current
situation is really frustrating. If I want to exclude some
packages, I should be able to do it once for all. If I want to
disable automatic download of metadata/packages, there should be a
single place where I can define my desired package management
policy. If I want to specify default metadata_expire timeout for
all repositories, there should be one place to do it. There really
should be a single package management policy that must be
respected by every package manager in Fedora, specially the main
ones: DNF and PackageKit (and currently Yum).

Hi, I understand the frustration. On the other hand, I personally hate 
anything that is centralized. Just an idea: what about a simple 
modular tool (maybe installed by default) which would be able to set 
options like this at all the places? Potentially it could be able to 
synchronize a subset of settings between given programs.
While I prefer the centralized approach (and also consider your approach 
still a centralized one), but whatever works is fine with me.




--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech



-- 
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: Yet another frustration with Fedora package management

[Hedayat Vatankhah]

/*Rex Dieter rdie...@math.unl.edu*/ wrote on Sat, 03 Jan 2015 16:58:32 
-0600:

Hedayat Vatankhah wrote:


...
Suggestion: Please add a single configuration file to configure common
package manager options

I think you answered your own question = modify the .repo files


Thank you!!! Yes, I know that I can do it, but its nothing but 
ridiculous. And, as I said, this is an unsafe approach: first I excluded 
it from one repo, then I discovered that I should add another 
repository, and then another one. What if this package is in 50 repos? 
Or you want to set metadata_expire for 50 repos?

I wonder if having a single packages.conf is THAT hard!!!

Hedayat
-- 
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: Yet another frustration with Fedora package management

[Hedayat Vatankhah]

/*Reindl Harald h.rei...@thelounge.net*/ wrote on Sun, 04 Jan 2015 
19:11:01 +0100:


Am 04.01.2015 um 19:02 schrieb Hedayat Vatankhah:

/*Rex Dieter rdie...@math.unl.edu*/ wrote on Sat, 03 Jan 2015 16:58:32
-0600:

Hedayat Vatankhah wrote:


...
Suggestion: Please add a single configuration file to configure common
package manager options

I think you answered your own question = modify the .repo files


Thank you!!! Yes, I know that I can do it, but its nothing but
ridiculous. And, as I said, this is an unsafe approach: first I excluded
it from one repo, then I discovered that I should add another
repository, and then another one. What if this package is in 50 repos?
Or you want to set metadata_expire for 50 repos?
I wonder if having a single packages.conf is THAT hard!!!


WTF don't you read other answers before continue to rant?
just edit yum.conf instead demand a useless packages.conf 
duplicating what is already there
Have you read my first email carefully? yum.conf is only used by yum, 
DNF and PackageKit/Gnome software don't care about it.


-- 
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: Yet another frustration with Fedora package management

[Hedayat Vatankhah]

/*Reindl Harald h.rei...@thelounge.net*/ wrote on Sun, 04 Jan 2015 
19:19:20 +0100:


Am 04.01.2015 um 19:13 schrieb Hedayat Vatankhah:
...
DNF is using /etc/dnf/dnf.conf which is one reason more to finally 
rename it back to YUM when it starts to replace it instead demand 
users all over the world change working configs, but that's a 
different topic nobody cares about


if other sofwtare like Packagekit ignore that global options of the 
package manager just file bugreport for them


 I wonder if having a single packages.conf is THAT hard!!!

for DNF, YUM, Packagekit and what not else?
surely, the same way hard to just proceed the configuration of 
yum.conf, they all would needed to be changed


I'm fine with using yum.conf if everybody respects it, but I didn't 
propose it because:

1) There are some options in yum.conf that DNF/PK doesn't recognize
2) DNF has some specific options in dnf.conf which yum doesn't support
3) PK/GNOME Software have ... well I'm yet to completely discover but at 
least they have some options controlled by gsettings! and some in 
/etc/PackageKit/ which is completely unique to itself!


So, I thought that maybe every package *likes* to have its specific 
settings method; and therefore I proposed to have a global configuration 
which configures main package manager policy.


Regards,
Hedayat
-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Hedayat Vatankhah]

/*Aleksandar Kurtakov akurt...@redhat.com*/ wrote on Sun, 4 Jan 2015 
02:55:17 -0500 (EST):

- Original Message -

From: Hedayat Vatankhah hedayat@gmail.com
To: Development discussions related to Fedora devel@lists.fedoraproject.org
Sent: Friday, January 2, 2015 11:15:58 PM
Subject: Re: Ramblings and questions regarding Fedora,  but stemming from 
gnome-software and desktop environments

...

GNOME Software is not that useful for a developer. As Rechard himself said,
he'll need a package manager anyway. So, If Workstation product really
targets developers, specially the ones who don't want to use terminal, it
MUST include a graphical package manager.

There are developers unaware of the concept of package manager which does not
help. Gnome Software is actually useful once the add-ons functionality is
fully expanded on applications. Works need to be done allowing a seamless
integration.
Add-ons cannot cover development libraries, unless every library is an add-on
for all IDEs!

It can be done dynamic aka install devel packages on request by IDEs - see 
https://rgrunber.fedorapeople.org/eclipse_packagekit_1.ogv

It's great, but it is not address my concerns, because:
1) If its going to be the only method for installing -devel packages, it 
should always work: it should be able to install a missing library or 
header file (consider a makefile only project). Also, not everybody uses 
correct package name in their configure script, some people use 
corresponding Debian package name (with a lib prefix and even sometimes 
full debian package name: libfoo-dev); so partial/non-exact matching 
should be also implemented.


2) More importantly, it doesn't address my main concern at all: what if 
I want to create a new project, and I'm looking for a good XML library, 
or would like to see what Fedora has to offer in this area? Even if I've 
found a great library in Internet, I should create a test in my 
configure/cmake checks for that library and see if PK will find it. It 
doesn't look like a user friendly way to search for a development 
library! It's a workaround around a missing UI.


Looking for development libraries, see their ranking and even reading 
user's reviews is all completely useful for a developer, which aligns 
perfectly with what Software offers for applications.


Regards,
Hedayat





Alexander Kurtakov
Red Hat Eclipse team



-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Hedayat Vatankhah]

/*Alec Leamas leamas.a...@gmail.com*/ wrote on Sat, 03 Jan 2015 
14:57:10 +0100:

On 02/01/15 11:42, Richard Hughes wrote:

That said, my gut feeling is that the balance between simplicity and 
functionality is quite different for a novice user and a developer 
and that this needs to be handled with different modes, views or so 
(if gnome-software should handle it). Adding things like random CLI 
applications, -devel packages etc. to the search result for a  novice 
user is just not an option, agreed. But IMHO a developer probably 
needs it in some form.
Search results can be presented in groups (same as groups already used 
in the main screen): Sound/Graphics/Fonts/Development Libraries/etc...


Usually, when a user search for some terms, he already know its 
category. In fact, I think grouping search results is useful even in the 
current state without any CLI tools or development libraries. It needs a 
good UI design though. Maybe search results can be 'tagged' with their 
category, and a list of categories (of the results) is presented 
somewhere at the top/side so that the user can select one or some tags 
so that only packages from those categories will be shown. Or, the UI 
might ask the user (ouch, frowned upon!) some questions (if results were 
scattered in many categories) so that it can fine tune the results.


Thanks,
Hedayat



Cheers!

--alec



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

Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Hedayat Vatankhah]

/*Luya Tshimbalanga*/ wrote on Fri, 02 Jan 2015 17:29:14 -0800:

On 02/01/15 01:15 PM, Hedayat Vatankhah wrote:



Probably true, but it already includes fonts and input sources. So, 
someone has felt that 'front-end applications only' is too narrow. 
Now, where you can draw the line?



I exaggerated.
Did you try that? The problem with searching for C++ is that it 
will list almost all applications (probably it searches for C). So 
it has nothing to do with DevAssistant.
I just searched C++ resulting a freeze of Gnome Software due to 
handling of ++ character. That is a bug I already submitted 
https://bugzilla.redhat.com/show_bug.cgi?id=1178199
Normally, Gnome Software should list DevAssistant on the first list as 
I have no problem typing python or ruby keyword on the search field.

Thanks for filling the bug. :P I was thinking when I'll report it.




So, every IDE should have a 'clang' addon? and also a gcc addon? At 
least, if 'shared' add-ons are available things will be much easier.

In this case, why not?
I was actually suggesting a solution which could fit in the current 
design. I'm not against the latter (while I still prefer having them as 
independent applications, in case you really don't need an IDE. However, 
if it is also available as a DevAssistent add-on, it'd be good; but 
actually I'm mis-using DevAssistant as 'Development Tools' category!)





I wonder why people want to split developers into two categories: 
GUI-only and Terminal-only? Why there couldn't be a GUI as much as 
possible developer? Such a developer will prefer to install 
autotools and clang/gcc using a GUI application, then open a terminal 
and run ./configure  make  sudo make install in shell? Why do 
people think that a developer which wants (actually, since currently 
there are no(?) GUI ways to do configure, make and make install, he 
is forced) to use terminal should be 'punished' to use command line 
for installing the tools he need?
They were attempt of create a frontend for that purpose and most of 
them were poorly implemented. Take a look of how Microsoft and Apple 
do their development. it is a matter of finding a better way of 
implementing the tool.
If you mean finding a replacement for autotools, I disagree. While 
having better ways is great (and actually, there are many 'autotools 
replacements' and some of them are GUI friendly. A good example is 
CMake), but there is a fact that there are many packages using autotools.
I don't know how Apple does it (but I think I remember some of my 
friends actually being *forced* to use command line to install an 
auto-tools based library), but I wonder if you know about a 'better way' 
Microsoft provides. As far as I know, installing and using third-party 
development libraries under Windows is nearly Terrible. And, the last 
time I tried to use Boost under Windows it certainly needed using 
command line to use boost build system. I used several other libraries 
under Windows, none of them provided any *good* means for installation 
and usage. Most importantly, Windows doesn't (or at least, didn't!) have 
any Software Center like tools at all. So, there are no means in Windows 
for finding and installing development libraries; and hence it can't be 
better or worse than ours!





(Well, hopefully in future there will be a tool (DevAssistant?) which 
can help you to configure, compile and install a package from source. 
Then, it can have gcc/clang/... compilers as its addons too; so it's 
become more practical to have GUI-only developers who don't need to 
install a compiler directly).


DevAssistant is a start. Next step will be adding packaging guideline 
and other stuff. It takes time but it can be done.




Add-ons cannot cover development libraries, unless every library is 
an add-on for all IDEs!
Then is IDE packaging issue. When it comes of using a development 
applications, the software should suggest installing the missing 
library. If Gnome Video is able to prompt uses to install missing 
component, then why shouldn't be possible for IDE application to do 
the same?
Granted I don't know well the functionality but the logic is 
application should detect and suggest adding the missing function.
Hmm... that's weird, I can't understand what you mean. Gnome Video's job 
is very easy: a video has a special format, and there are specific 
plugins to enable playing that. However, assume that I need an XML 
library for C++:

1. How can I tell the IDE that I need an XML library?
2. What should IDE do if there are 5 different XML libraries for C++? 
How should I tell it which one I want, specially if I don't know what 
should I use already, and want to see what is available out there?


To me, it seems like implementing a special purpose software manager 
inside IDE with almost all functionality GNOME Software provides. As I 
said in another post, user reviews/rating for development libraries 
(like what GNOME Software provides for applications) can be really

Yet another frustration with Fedora package management

[Hedayat Vatankhah]

Hi!
Summary: Try to prevent a package from being updated/installed from 
repositories regardless of the package management tool you use. As it 
seems, then only way you can do this is to exclude it from the 
repositories themselves inside their configuration file in 
/etc/yum.repos.d/, because these are the only common settings between 
all three (yum/dnf/PackageKit). TBH, I'm not sure about PackageKit, but 
I feel that it don't read /etc/dnf/dnf.conf as it doesn't use DNF but 
its backends. This is fine if the package is in a single known 
repository, but what if it is in 3 repositories that you might not be 
aware of all of them?


More details:
As you might already know, nvidia drivers in RPMFusion F21 repositories 
doesn't work for all nvidia cards. In one system, I finally installed 
akmod-nvidia from RPMFusion F20 repositories which worked fine. Soon 
after I realized that I should exclude akmod-nvidia and dependencies 
from F21 repositories. I added exclude=*nvidia* to /etc/yum.conf as I 
was lazy to check which repository these packages come from. But then I 
noticed that dnf doesn't consider it excluded. Then I thought that 
probably PackageKit doesn't use dnf.conf too. So, how should I excluded 
these packages? Well, these were in rpmfusion-nonfree-updates 
repository, so I added the exclude directive there. Then I found that I 
should add it to rpmfusion-nonfree repository too. However, since I use 
yum-plugin-local I also have a local repository (I actually copied the 
repository from another system, so it was enabled on this system so that 
I could install software from it) which also included these packages. 
Therefore, I should exclude *nvidia* in 3 repository configuration 
files to make sure (hopefully!) that these will not be installed by any 
package manager I know.


Suggestion: Please add a single configuration file to configure common 
package manager options (Specially between DNF and PackageKit, which are 
there to stay). As I mentioned in F21 downloads repository metadata in 
3 places! thread, Fedora package management should be consistent and 
integrated; and the current situation is really frustrating. If I want 
to exclude some packages, I should be able to do it once for all. If I 
want to disable automatic download of metadata/packages, there should be 
a single place where I can define my desired package management policy. 
If I want to specify default metadata_expire timeout for all 
repositories, there should be one place to do it. There really should be 
a single package management policy that must be respected by every 
package manager in Fedora, specially the main ones: DNF and PackageKit 
(and currently Yum).


Regards,
Hedayat
-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Hedayat Vatankhah]

/*Kevin Fenzi*/ wrote on Sat, 3 Jan 2015 14:09:11 -0700:

On Sat, 3 Jan 2015 15:56:55 -0500
Gary Scarborough gscarboro...@gmail.com wrote:

...

Instead of hiding the CLI from new users, why not simply give them the
option of avoiding it?  Instead of only showing gui apps, why not
show all with packages being tagged as either cli or gui.  Then the
user can decide whether or not they want to install the package.

Well, the current state of things is that the GUI software manager
shows only GUI apps and users need to use a cli software manager to
install and manage cli apps. I'm not sure there's advantage to showing
cli apps in the GUI software manager.
It has advantage for a user who prefers GUI, but sometimes needs to 
install and use a CLI application. Such a user, which can easily include 
many GNU/Linux new users who might happen to need to use a specific CLI 
application, might know about the cli application usage (e.g. using a 
app specific manual) but doesn't know anything about dnf/yum, and is not 
interested to learn them. Does anybody really think that there should be 
any relation between the UI of your package manager and the UI of the 
packages you install with it? If so, maybe dnf/yum should be also unable 
to install GUI apps. :P


Hedayat

-- 
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: CLI tools in Gnome Software?

[Hedayat Vatankhah]

/*Richard Hughes hughsi...@gmail.com*/ wrote on Fri, 2 Jan 2015 
10:47:21 +:

On 1 January 2015 at 22:25, Hedayat Vatankhah hedayat@gmail.com wrote:

it's just funny that something like gedit and
Windows notepad can be considered 'applications' but GCC can't!

We're using this definition here:
https://github.com/hughsie/appstream-glib#what-is-an-application
Yes, I know. And I say that it might be OK for a GNOME Application, 
but doesn't seem to be OK for Fedora application.


Edit: I didn't know. I thought it is the same as the other one given in 
a previous email. I see it doesn't require things like a 'primary 
window'. It seems that many command line utilities in Security spin can 
be considered applications since security spin provides .desktop files 
and icons for many of them! But, should people start working around the 
limitation of your definition by providing icons/.desktop files for 
command line apps?


Also, you already include non-application software such as Fonts. And 
I'd bet that there are some non-GUI software which are much more useful 
to be included than fonts which will be rarely used. How many times a 
user might need to install fonts after installing Fedora? Specially 
after the initial setup, I don't think its very likely that (s)he will 
need to install new fonts. But, in case of developers, they might 
require new -devel packages, profiling tools, etc. every now and then. 
And a developer certainly appreciates user reviews when he wants to 
select a library between many different libraries providing a similar 
functionality.


BTW, input methods, codecs and fonts are already included. Why such a 
hard position against things such as console applications, and -devel 
packages? Yes, regular libraries are *usually* not installed directly, 
but on the other hand, -devel packages are almost always installed 
directly, or as a dependency of another -devel (or toolchain) package.




Certainly, the concept of 'console applications' is a widely recognized concept

It's really not.

Sure?
Wikipedia has a page about it, one of the application types you can 
create in Qt Creator is Qt Console Application, Microsoft Visual 
Studio also provides a Console Application type. Yes, none of these 
are authoritative, but I wonder if there is any reference backing your 
claim.




It doesn't fit my 1024x768 screen which is really annoying

Is this F21? If so, sounds like you need to file a bug upstream.

Yes. Done already: https://bugzilla.gnome.org/show_bug.cgi?id=742211




Richard


Regards,
Hedayat
-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Hedayat Vatankhah]

/*Luya Tshimbalanga*/ wrote on Fri, 02 Jan 2015 12:25:49 -0800:

On 01/01/15 04:21 PM, Hedayat Vatankhah wrote:




Well, I was really surprised that developers are considered a target 
audience here. GNOME Software *might* be considered good enough for 
normal users, but its far from usable for a developer; even a 
developer who don't want to touch the terminal. Actually, it is 
*terrible* for such a developer. Why?


From what I understand, Gnome Software is intended for front-end 
applications only.
Probably true, but it already includes fonts and input sources. So, 
someone has felt that 'front-end applications only' is too narrow. Now, 
where you can draw the line?





1. He search for C++ and  (I doubt that it tries to interpret 
it as a regular expression or something. Probably it thinks that the 
user is an idiot and removes + signs on behalf of him).
DevAssistant application available by default on Fedora Workstation is 
designed for that purpose.
Did you try that? The problem with searching for C++ is that it will 
list almost all applications (probably it searches for C). So it has 
nothing to do with DevAssistant.







2. He has installed Eclipse + CDT and hopefully he can compile his 
C++ programs with GCC. Now, he learns about Clang and would like to 
try it.
Clang is a compiler that be installed as an add-ons for Eclipse. That 
is very much an request of enhancement for IDEs installation in Gnome 
Software.
So, every IDE should have a 'clang' addon? and also a gcc addon? At 
least, if 'shared' add-ons are available things will be much easier.


I wonder why people want to split developers into two categories: 
GUI-only and Terminal-only? Why there couldn't be a GUI as much as 
possible developer? Such a developer will prefer to install autotools 
and clang/gcc using a GUI application, then open a terminal and run 
./configure  make  sudo make install in shell? Why do people think 
that a developer which wants (actually, since currently there are no(?) 
GUI ways to do configure, make and make install, he is forced) to use 
terminal should be 'punished' to use command line for installing the 
tools he need?


(Well, hopefully in future there will be a tool (DevAssistant?) which 
can help you to configure, compile and install a package from source. 
Then, it can have gcc/clang/... compilers as its addons too; so it's 
become more practical to have GUI-only developers who don't need to 
install a compiler directly).







GNOME Software is not that useful for a developer. As Rechard himself 
said, he'll need a package manager anyway. So, If Workstation product 
really targets developers, specially the ones who don't want to use 
terminal, it MUST include a graphical package manager.


There are developers unaware of the concept of package manager which 
does not help. Gnome Software is actually useful once the add-ons 
functionality is fully expanded on applications. Works need to be done 
allowing a seamless integration.
Add-ons cannot cover development libraries, unless every library is an 
add-on for all IDEs!


Regards,
Hedayat



--
Luya Tshimbalanga
Graphic  Web Designer
E:l...@fedoraproject.org
W:http://www.coolest-storm.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: CLI tools in Gnome Software?

[Hedayat Vatankhah]

/*Richard Hughes hughsi...@gmail.com*/ wrote on Fri, 2 Jan 2015 
13:48:51 +:

On 2 January 2015 at 11:45, Hedayat Vatankhah hedayat@gmail.com wrote:

Yes, I know. And I say that it might be OK for a GNOME Application, but
doesn't seem to be OK for Fedora application.

There's no such thing as a Fedora application.

Maybe it should! :P




It seems that many command line utilities in Security spin can be considered
applications since security spin provides .desktop files and icons for many
of them!

No, we ignore any with the ConsoleOnly hint.

Thanks!!



Wikipedia has a page about it, one of the application types you can create
in Qt Creator is Qt Console Application, Microsoft Visual Studio also
provides a Console Application type. Yes, none of these are authoritative,
but I wonder if there is any reference backing your claim.

Okay, lets do a thought experiment. Is a console application anything
that exists in /usr/bin? If not, what additional rules are required
for a sane set? Are all files in /usr/bin applications?
Probably no. Good examples for things which are probably not considered 
applications by users can be 'utilities' such as 'test', 'ls', and the 
like. However, I'm not sure if I can come up with a set of strict rules. 
Maybe it can be up to the packager? However, I think any binary which is 
useful on its own can be considered a good candidate for being an 
'application' to be presented in a software center application. 
Conceptually, I see no difference between a GUI web browser and a TUI 
one. Both of them can have windows in which you can see web pages. TUI 
can have menus, buttons and whatever you can find in a GUI. I think I 
can say that every software with a UI(Text based/curses based), which 
can be easily (conceptually, not technically) replaced with a GUI, is 
certainly an application.


But I wont limit it here. I think that compilers also should be 
considered applications. While your idea of installing them as part of 
an IDE's addons work, it can be problematic unless add-ons can be shared 
between multiple packages. If not, every IDE which supports different 
compilers should have addons for each one of them (so every C/C++ IDE 
would need an addon for GCC, and another one for Clang). If addons can 
be shared among multiple applications, then things will be slightly 
better. So, there will be one GCC addon, and one Clang addon, which 
multiple IDEs might present. But personally, I'd prefer to be able to 
install GCC/clang when searching for C++ compiler in a software center 
application.


Apart from the Application discussion, I really like to see a new 
Development Libraries concept in Gnome software just like Fonts and 
Input sources, which lets a developer to look for libraries and rate 
them. Some of them can even have screenshots: GUI libraries (Qt, GTK) 
and graphic/game engines are good examples.


Thanks




Richard.


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

Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Hedayat Vatankhah]

/*Michael Catanzaro mcatanz...@gnome.org*/ wrote on Sun, 28 Dec 2014 
11:05:00 -0600:
On Sun, Dec 28, 2014 at 9:48 AM, Alec Leamas leamas.a...@gmail.com 
wrote:
Possibly. But isn't there quite a difference between the novice 
user and the Fedora Workstation target user i. e., developers?


Not necessarily. I wrote:

Yes, Workstation targets developers, but not exclusively, and also 
developers who use fancy IDEs and who don't work with the terminal. I 
just don't want this thread to degenerate into a discussion of this 
lousy definition [of normal/novice users], since it's not important. 
What's important is that we want Workstation to be excellent for users 
who never touch the terminal.


Fedora currently suffers from the impression that it is a complicated 
OS for advanced users only, and that novices (including novice 
developers) should use Ubuntu instead.




Well, I was really surprised that developers are considered a target 
audience here. GNOME Software *might* be considered good enough for 
normal users, but its far from usable for a developer; even a developer 
who don't want to touch the terminal. Actually, it is *terrible* for 
such a developer. Why?


1. He search for C++ and  (I doubt that it tries to interpret it 
as a regular expression or something. Probably it thinks that the user 
is an idiot and removes + signs on behalf of him).
2. He has installed Eclipse + CDT and hopefully he can compile his C++ 
programs with GCC. Now, he learns about Clang and would like to try it.
3. He is using an x86_64 system, but he happen to need to compile his 
program for 32bit systems. or even cross-compile for ARM.

4. He needs a networking library, or want to use Boost, or 

GNOME Software is not that useful for a developer. As Rechard himself 
said, he'll need a package manager anyway. So, If Workstation product 
really targets developers, specially the ones who don't want to use 
terminal, it MUST include a graphical package manager.


Regards,
Hedayat

-- 
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: CLI tools in Gnome Software?

[Hedayat Vatankhah]

/*Michael Catanzaro mcatanz...@gnome.org*/ wrote on Tue, 23 Dec 2014 
12:43:40 -0600:

On Tue, 2014-12-23 at 17:12 +0100, Dridi Boukelmoune wrote:

Are CLI tools welcome in Gnome
Software?

No, we don't consider CLI tools to be applications, and only
applications should be displayed in GNOME Software.

See also:
https://developer.gnome.org/hig/stable/application-basics.html.en

It's fine if you don't consider them 'GNOME applications', but I'd 
suggest to consider them 'Console applications'. And, if you are really 
interested in only GNOME applications, I'd suggest removing all 
non-GNOME applications from GNOME Software too. IMHO, it's just funny 
that something like gedit and Windows notepad can be considered 
'applications' but GCC can't!


I don't mind if GNOME doesn't consider console applications as 
applications; but I really think that Fedora should not go that route. 
Certainly, the concept of 'console applications' is a widely recognized 
concept; and I find associating
'applications' with .desktop files, icons and windows just ridiculous 
and confusing.


Personally, I won't suggest anybody trying GNOME Software as a serious 
software management application for Fedora, as it is simply misleading. 
I'd suggest it as a good looking software which needs a resolution wider 
than 1024 (I really don't see why it needs to be that wide! It doesn't 
fit my 1024x768 screen which is really annoying) and can present a few 
GUI applications you can find in Fedora repositories. It's certainly not 
a 'software management' tool, and also not a 'Fedora application 
management' tool. I would tell them to use a proper software management 
tool, and consider GNOME Software mostly as a toy or a tool to find out 
about some software that they might not notice normally. It's actually a 
'Do you know that Fedora has Foo software?' tool.


Regards,
Hedayat
-- 
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: F21 downloads repository metadata in 3 places!

[Hedayat Vatankhah]

/*Richard Hughes hughsi...@gmail.com*/ wrote on Wed, 17 Dec 2014 
09:14:38 +:

On 17 December 2014 at 00:00, Michael Catanzaro mcatanz...@gnome.org wrote:

This particular setting is
frequently-requested and extremely important for users in the developing
world and users who tether, so I think it would be good to provide it
somewhere in the UI. (But where?)

I'm erring on the network panel in gnome-control-center; but I agree
there's no really good place for this kind of thing.

Richard.
I've suggested at least a single selection during/after install once, 
because I knew that there is a 'strong' resistance against adding new 
configurations/features at least in GNOME (And I don't have much hope 
that I can convince them to do so, like what happened at [1]).


Anyway, the ideal solution which I'd like to see (or someday implement 
somewhere!) is what I've proposed at [2] or [3]: network profiles for 
different connections, which include all network connection dependent 
settings: proxy settings, firewall settings (like firewall zones which 
(surprisingly!) has been added), background connection permission, 
sharing, etc. Yes, it should be implemented to be as simple as possible, 
but it should be there! Personally, I prefer Complicated UI to No 
UI; but I agree that Good UI is better than both.


Regards,
Hedayat

[1] https://bugzilla.gnome.org/show_bug.cgi?id=705721
[2] https://bugzilla.gnome.org/show_bug.cgi?id=727580#c15
[3] 
https://fedoraproject.org/wiki/Summer_coding_ideas_for_2014#Integrate_Proxy_Settings_and_Network_Connections.28Locations.29


--
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: F21 downloads repository metadata in 3 places!

[Hedayat Vatankhah]

/*Chris Murphy li...@colorremedies.com*/ wrote on Tue, 16 Dec 2014 
13:09:47 -0700:

Fresh installation of Fedora 21 Workstation, accepting defaults, I
then reboot and notice the following contents of /var/cache, filtering
out things not relevant for this discussion (which also happen to not
change between the three states).

Starting point right after installation:

[root@localhost cache]# du -sh *
16K dnf
85M PackageKit
4.0K yum


Login, wait for ~ 1/2 hour:

[root@localhost cache]# du -sh *
94M dnf
446M PackageKit
4.0K yum

That's 455MB of silently downloaded data, by default. Upon doing a yum
upgrade, but rejecting the actual upgrade:

[root@localhost cache]# du -sh *
94M dnf
446M PackageKit
137M yum

Ummm, that's a metric shit ton of data to download for a brand new OS.
No doubt this is bigger by now for Fedora 20 since most every package
will have been touched by an update, and likely is well over 1GB to
silently download.

I suggest the following short term change:

1. dnf should not be downloading its metadata in the blind by default;
yum doesn't, why is dnf doing this? And there's the hourly refresh it
does by default also. I like this behavior for me, but I think it's
simply an inappropriate default considering various bandwidth
limitations that still exist in the world.

2. PackageKit very aggressively starts downloading both metadata and
updated packages upon first login. I think this should be delayed so
the user has an opportunity to disable it; and then Software or
Settings needs a UI so that it can be disabled. The UI could
differentiate between automatic checks for updates (metadata) vs
automatic package downloads; or even between application vs OS
downloads.

But backing this up, the OS needs to ask for permission before
additionally downloading 50% to 100+% of the install media size. I
don't really care if this permission is conveyed in the installer UI;
or g-i-s or a notification; but the current behavior is really
presumptuous.

Thank you for providing real data. I'm really happy that I've disabled 
both PK and DNF auto-downloading right after installation :)


Thinking a little more about the whole situation, I was thinking if 
there should be a general packaging policy: no packages should be 
permitted to generate 'considerable' or any network traffic if not 
explicitly requested by the user.


Regards,
Hedayat
--
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: F21 downloads repository metadata in 3 places!

[Hedayat Vatankhah]

/*Colin Walters walt...@verbum.org*/ wrote on Mon, 15 Dec 2014 
15:32:09 -0500:

On Mon, Dec 15, 2014, at 02:17 PM, Hedayat Vatankhah wrote:

and then a
'systemctl mask ...' command to mask dnf makecache timer/service using
sudo/su;

This one should help with that one:

https://github.com/rpm-software-management/dnf/pull/186

Thanks, this certainly helps... until you decide to use DNF even once.
I really appreciate this, as it helps people who never use DNF. But if 
there is a distribution level policy about internet access, it'd really 
help. For example, you can decide if you'd use deltarpms or not. And 
certainly, if you should update DNF cache aggressively.


Thanks,
Hedayat
-- 
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: F21 downloads repository metadata in 3 places!

[Hedayat Vatankhah]

/*Richard Hughes hughsi...@gmail.com*/ wrote on Mon, 15 Dec 2014 
09:37:27 +:

On 13 December 2014 at 21:10, Hedayat Vatankhahhedayat@gmail.com  wrote:

Surprisingly, PackageKit uses its own separate cache.

Not surprising at all, when you're familiar with how PackageKit works.
PackageKit has to accept transactions from clients and return results
very quickly. Just something as simple as SHA'ing a metadata file
destroys our latency, which is one of the biggest reasons nobody liked
the command-not-found functionality when it was introduced: it was
SLOW. This interactive command had to return results in ~100ms, not
tens of seconds.

By having 100% complete control of a copy of the cache we can keep
certain files locked in memory, and we can be aggressive about caching
pools of packages. This allows us to achieve the low-latency design
required by gnome-software, which is firing off tons of transactions
in parallel at startup with expected latency guarantees. Another thing
it allows us to do is atomically update the cache, so if we're
updating the cache in the background and we get interrupted or the
transaction is cancelled to make room for a user-requester
interactive transaction, we can just continue to use the old cache,
and then atomically rename the new location to the proper location and
update pools when done. You just can't do this when there are three
things fiddling with files behind your back without any co-ordination.
...

Note, if yum or DNF wanted to use the PK cache, it's guaranteed to be
valid, complete and up to date, although I'm not sure a dependency
from the package manager CLI to PK would be acceptable for their
maintainers.

Richard.
What I think about this (I'm looking at the distribution level, rather 
than specific packages):
1. If PK really needs its own *copy* of the cache, that's OK (well, not 
OK but acceptable), but IMHO it should not download it independently 
too. I think it should just copy the DNF(librepo) cache if it is 
considered valid and up-to-date, or ask it to bring its cache up-to-date 
and then copy the cache atomically to its own cache (preferably using 
hardlinks if possible).


2. I believe that the use should know, and more importantly be able to 
control WHEN the repo data is being updated. At the very least, he 
should be able to specify if the updates are automatic or not using a 
very user friendly method (probably during/after the installation; or 
per network connection).


3. I think the repository data management backend should be separate 
from the frontends (including PK, and dnf cli). Also, I like the idea of 
having a working cache even when new repodata is being downloaded, and I 
think it is something that DNF/Yum/... should also do. There were many 
times that I ended up with a half-updated repo cache which prevented me 
from using Yum as I didn't want/can let it download whole repodata. 
Probably this should be filled as a feature request against DNF.


Regards,
Hedayat
--
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: F21 downloads repository metadata in 3 places!

[Hedayat Vatankhah]

/*Matthias Clasen*/ wrote on Mon, 15 Dec 2014 12:38:54 -0500:

On Mon, 2014-12-15 at 18:01 +0100, Kevin Kofler wrote:

Robert Marcano wrote:

I don't know why the time to rebuild rpms is important, updates are now
applied at boot time, so rpms can be rebuilt with smaller nice/ionice
before the user reboots (on Workstation product).

Offline updates are only a (mis)feature of the GNOME Workstation product.
The tools shipped by all the other spins (Apper, Yumex) do immediate updates
as always.

...which brings this thread to the end of its useful life.

If you have constructive suggestions for how to improve detection of
'metered' connections, please direct them to the desktop list, or send
patches to the gnome-software component in bugzilla.
Just wanted to remind that I would like to see an 'integrated' approach. 
It doesn't help if PK decides to not download anything but DNF starts to 
refresh its cache when I'm on a 'metered' connection.


Also, any non-user-friendly approach is a no-go. If a first time 
GNU/Linux user which happens to use Fedora (which is rare these days, at 
least around me), come and tell me that Fedora has ate his 1 month 
internet credit, I'd prefer to tell him Oh, sorry, you should use 
something like Ubuntu instead rather than You should open an 
application called 'Terminal', run a gsettings  command, and then a 
'systemctl mask ...' command to mask dnf makecache timer/service using 
sudo/su; which will most probably cause him to run away from Fedora 
anyway (maybe back to Windows)!


Regards,
Hedayat
--
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: F21 downloads repository metadata in 3 places!

[Hedayat Vatankhah]

/*Samuel Sieb sam...@sieb.net*/ wrote on Sat, 13 Dec 2014 23:32:23 -0800:

On 12/13/2014 01:10 PM, Hedayat Vatankhah wrote:

Hi!
I noticed that F21 can potentially download repository metadata 3 times:
1. Yum cache 2. DNF cache 3. PackageKit cache! It really hurts to see


I'm not aware of the PackageKit cache, where is it?

/var/cache/PackageKit



I did accidentally discover about dnf recently on some F20 systems.  I 
don't remember if it was network traffic or disk space that tipped me 
off, but I discovered that dnf was downloading stuff when I didn't 
even know it was installed.  I immediately disabled it, but that does 
seem like rather unfriendly behaviour...
I'd call it evil. Apparently, nobody around here cares. I think I should 
start thinking about my own Fedora for Poor product.


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

F21 downloads repository metadata in 3 places!

[Hedayat Vatankhah]

Hi!
I noticed that F21 can potentially download repository metadata 3 times: 
1. Yum cache 2. DNF cache 3. PackageKit cache! It really hurts to see 
how Fedora ignorance towards different kind of users is being increased 
as time passes. If Fedora is an international distro, it should try to 
consider condition of different users, not just a portion of them.
Fedora repository metadata format was already hostile, it wastes 
bandwidth considerably downloading mostly useless data repeatedly. 
Things got worse for DNF as it decides to also always download filelists.


Now, Fedora 21 contains yum, dnf and PackageKit (software center) with 
new backend. Surprisingly, PackageKit uses its own separate cache. DNF 
refreshes its cache automatically (without user's consent) every 3 hours 
by default (according to 'man dnf.conf'). PackageKit also does the same, 
but I don't know when it does (also without user's consent).


Now, if you are exclusively a 'yum' user, you'll end up with 3 
repository metadata downloads, two of which you are unaware of. 
Probably, it is OK for most of you having access to cheap, fast internet 
access. But not everybody in the world has such access. It was not long 
ago that dial-up internet access was a norm in my area (there are still 
some using it!). I'm not using dial-up, but still can't afford such a 
waste of bandwidth. I'm using a 'fast' internet access, which is 
512Kb/sec, and have 6GiB for 3 months (with free access at nights, which 
I use to update/install Fedora packages). As I've described at [1], DNF 
alone can potentially consume all my internet credit very soon; even if 
I don't want to use any package manager at all. This will make many 
users with conditions like me very angry when they realize that Fedora 
has eaten their money silently.


Another side of the story is how Fedora lacks any integration in this 
area. There are separate caches. Fedora doesn't tell you that it'll eat 
your internet. Also, there is nowhere you can tell Fedora 'Please don't 
eat my internet without my permission'. Even there is no single 
configuration option for it. You should manually disable automatic 
downloading for DNF, and then separately for gnome software using some 
obscure gsettings commands you should look for. Well, I've not tried 
other desktops, each one might have each own settings for that too! 
(though usually such ignorance is the worst in GNOME).


It's so unfortunate to see how Fedora lacks any integration (one of the 
main things that a distro is expected to provide) in its package 
management software (one of the main distro specific software, where you 
fairly expect an integrated experience as an 'internal' software).


As I was expecting, I've already seen how a user in our local community 
cried about Fedora 21 consuming his Internet credit the day after the 
release. The number of Fedora users around me were already low, and I 
expect it to become less if Fedora continues its ignorance trend.  I'm 
not annoyed that much yet, as I'm just considering switching to a 
different DE after suffering GNOMEs decisions for a long time hoping 
that 'things will be better soon'; and finding out that my needs are 
something that 'THEY see no reasons to support'.


P.S. sorry for the somewhat long email. I'm a little bit angry! :P

Regards,
Hedayat

[1] 
https://hedayatvk.wordpress.com/2014/07/26/the-shiny-new-dnf-and-why-i-prefer-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

Re: F21 downloads repository metadata in 3 places!

[Hedayat Vatankhah]

/*Reindl Harald h.rei...@thelounge.net*/ wrote on Sat, 13 Dec 2014 
22:19:25 +0100:


Am 13.12.2014 um 22:10 schrieb Hedayat Vatankhah:

I noticed that F21 can potentially download repository metadata 3 times:
1. Yum cache 2. DNF cache 3. PackageKit cache! It really hurts to see
how Fedora ignorance towards different kind of users is being increased
as time passes. If Fedora is an international distro, it should try to
consider condition of different users, not just a portion of them.
Fedora repository metadata format was already hostile, it wastes
bandwidth considerably downloading mostly useless data repeatedly.
Things got worse for DNF as it decides to also always download 
filelists.


Now, Fedora 21 contains yum, dnf and PackageKit (software center) with
new backend. Surprisingly, PackageKit uses its own separate cache. DNF
refreshes its cache automatically (without user's consent) every 3 hours
by default (according to 'man dnf.conf'). PackageKit also does the same,
but I don't know when it does (also without user's consent).


the automatic metadata refresh is a no-go

frankly in the meantime only the metadata are half as large as some of 
my server setups at all (our asterisk PBX needs 850 MB with F20)



Now, if you are exclusively a 'yum' user, you'll end up with 3
repository metadata downloads


systemctl mask dnf-makecache.timer stops the new nosense

if you are not using GNOME and YUM from CLI you can remove package kit 
at all and frankly my typical command is rm -rf /var/cache/yum*; yum 
upgrade because when i look for updates i want the *now* recent 
metadata and don't need them refreshed one hour ago
*I* know how to disable them (or at least, I hope so! Maybe there 
is/will be a foo package who decides to download its own copy too!), but 
that's not the point of my post. What I expect is either: 1. disable all 
kinds of potentially demanding internet access by default and let people 
enable if they like; or 2. add an option to anaconda, or a post 
installation option, so that the user can decide if he wants automatic 
metadata/package updates for *Fedora* (not a specific DE/application) or 
not. And the options should be applied to the whole distribution 
consistently, even if you use multiple DEs.
(And hey, you might find 'yum clean expire-cache' a better alternative 
for the 'rm -rf' command you use!)




[harry@srv-rhsoft:~]$ rpm -qa | grep -i packagekit
[harry@srv-rhsoft:~]$

sarcasmmaybe someone should place a bandwidh-limiting of 0.5 Mbit 
and a onhtly limit of 1 GB per month in front of developers to wake 
them up/sarcasm
That would be great! ;) I think even 1 month of such experience should 
be more than enough!

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

Re: Poll: How users use DNF

[Hedayat Vatankhah]

/*Radek Holy rh...@redhat.com*/ wrote on Tue, 9 Dec 2014 12:28:54 
-0500 (EST):

Dear users of YUM and DNF,

I'm writing to you regarding a request for your feedback. I would be very grateful if you could 
send me a brief description of how you use YUM or DNF currently or how would you like to use it. I 
am particularly interested in the occurrences of dnf/yum install calls in your scripts. 
What does these scripts do and what do they expect when they call the install command 
in different situations?

Please share with me the use cases, not the description of the install 
command. Think twice before you share something because I believe it's not as easy as it 
might seem. As an example I think it might be something like:

- I call YUM install, because I want to get given packages into my system and I 
don't care whether it requires an upgrade or downgrade or what. or
- I want to get them there but it should protect me against dangerous operations 
like downgrades or
- I often make typos, so I expect that the program knows what I mean or
- it would be nice if it would literally perform the installation; if any of the 
packages cannot be installed because of any reason, it should fail.

Not something like: that's obvious that the install command should never downgrade 
packages.

Please focus on *use cases*. The *real* (non-hypothetical) use cases. Not on 
the command's name as it might also result in a new command (while preserving 
the well-known install command together with an appropriate behaviour).

I don't mind if you send it offlist (or to another list). I think there is no 
need to comment on anyone's use case. Every case is valid. Just not every case 
can be supported.

Thank you very much in advance.
1. There are many cases that I want to install a package, but I don't 
care if it is the latest version available in the repos. So, I use '-C' 
regularly (currently doesn't work with yum, so I use dnf when I want to 
use -C to install a package without updating metadata).
2. I don't want dnf/yum/(any other software) to download data from 
internet at random times. If it wants to do it, it should do it on the 
networks I allowed, at the times I allowed. Not just when 'it can'.
3. When I want to install a package, I usually 'want' it. So, if it 
requires downgrade, I might be OK with it. I'd love to see a proposal 
with downgrades rather than saying that sorry, this package cannot be 
installed.
4. When I ask it to install some packages, I usually want it to do it 
with minimal downloads. I don't want it to update its dependencies if 
they are already installed, unless it is strictly necessary to install 
the package. Even in that case, I'd love to be able to tell the package 
manager (e.g. using a new command, or using an option to the install 
command) to install an older version of the package so that its 
dependencies doesn't need updating (instead of updating the dependencies 
to install the latest version, install an older version which matches 
the dependencies I've already got installed).


Regards,
Hedayat

-- 
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: Add Gparted into Live's

[Hedayat Vatankhah]

/*Michael Catanzaro mcatanz...@gnome.org*/ wrote on Fri, 08 Aug 2014 
19:07:11 -0500:

On Sat, 2014-08-09 at 02:33 +0430, Hedayat Vatankhah wrote:

GParted provides a number of essential features users might need, some
of which are not provided even by any command line tools in Fedora
repositories: resizing and moving partitions/filesystems. And
something like resizing FAT partitions is what I have not seen in any
other tools in Fedora repositories except kde-partitionmanager.
Anaconda provides resizing facility, but not move. Also, I'm not sure
if Anaconda can resize FAT partitions.

Hi Hedayat,

gparted should not be included because it's an advanced tool for
technical users, whereas Fedora Workstation needs to contain only tools
that are easy for everyone to use. Keep in mind that programs included
in the live image will also wind up on the installed system.

Michael

I actually don't insist on including gparted itself, but some of its 
features. Having a second thought, I think it is actually better to add 
such missing features to Anaconda itself, so it would benefit 
installation media too.


I didn't talk about GParted just because it is useful. I talked about 
it since sometimes it is needed for successful installation. Yes, if 
you already have installed any kind of GNU/Linux OS, you would rarely 
need to resize/move any partitions. But I've seen this being needed for 
many 'first time' installs.


Well, as I said, I think missing features should be added to Anaconda, 
rather than including gparted in live media. You might say moving 
partitions is 'too much' for Anaconda, but IMHO resizing FAT partitions 
isn't (unless you think that Anaconda should remove the ability to 
shrink NTFS partitions too!).


Regards,
Hedayat



-- 
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: Add Gparted into Live's

[Hedayat Vatankhah]

/*Christopher Meng cicku...@gmail.com*/ wrote on Fri, 1 Aug 2014 
07:08:52 +0800:



On Jul 31, 2014 7:44 PM, Álvaro Castillo net...@fedoraproject.org 
mailto:net...@fedoraproject.org wrote:


 Dear Fedora Team,

 I pray to God. Could Fedora live have CD/DVD/USB Gparted by default?

 Could add Gparted please?

You should provide us a reasonable explanation as the essential 
precondition for the request.






GParted provides a number of essential features users might need, some 
of which are not provided even by any command line tools in Fedora 
repositories: resizing and moving partitions/filesystems. And something 
like resizing FAT partitions is what I have not seen in any other tools 
in Fedora repositories except kde-partitionmanager. Anaconda provides 
resizing facility, but not move. Also, I'm not sure if Anaconda can 
resize FAT partitions.







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

Review Swaps

[Hedayat Vatankhah]

  
  
Hi all,
I'd like to swap these reviews with some other
  (not-so-complicated) ones:
Saaghar[1]- A Cross-Platform Persian
  Poetry Software
This is a Qt based application, and should not be complicated. 
  
jcal[2] - Unix cal-like
  interface to libjalali

A small C application  library with almost zero dependency.
  Should be fairly easy to review.


Thanks!
Hedayat


  [1] https://bugzilla.redhat.com/show_bug.cgi?id=678634
[2] https://bugzilla.redhat.com/show_bug.cgi?id=755358

  

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

Re: Review Swaps

[Hedayat Vatankhah]

* Sorry, it was supposed to be in both HTML and text formats *


Hi all,

I'd like to swap these reviews with some other (not-so-complicated) ones:

Saaghar[1]- A Cross-Platform Persian Poetry Software

This is a Qt based application, and should not be complicated.

jcal[2] - Unix cal-like interface to libjalali

A small C application  library with almost zero dependency. Should be 
fairly easy to review.


Thanks!

Hedayat


[1] https://bugzilla.redhat.com/show_bug.cgi?id=678634

[2] https://bugzilla.redhat.com/show_bug.cgi?id=755358



On ۱۱/۱۱/۲۱  02:00, Petr Šabata wrote:

 On Mon, Nov 21, 2011 at 01:45:25PM +0330, Hedayat Vatankhah wrote:
 html style=direction: ltr;
head

  meta http-equiv=content-type content=text/html; 
 charset=UTF-8stylebody
p { margin-bottom: 0cm; margin-top: 0pt; }/style
/head
body style=direction: ltr;
  bidimailui-detected-decoding-type=UTF-8 bgcolor=#FF
  text=#00
  pHi all,/p
  pI'd like to swap these reviews with some other
(not-so-complicated) ones:/p
  pSaaghar[1]-span id=summary_alias_containerspan
id=short_desc_nonedit_displayA Cross-Platform Persian
Poetry Software/span/span/p
  pThis is a Qt based application, and should not be complicated.br
span id=summary_alias_containerspan
id=short_desc_nonedit_display/span/spanspan
  id=summary_alias_containerspan
id=short_desc_nonedit_display/span/span/p
  pspan id=summary_alias_containerspan
id=short_desc_nonedit_displayjcal[2] - Unix cal-like
interface to libjalalibr
  /span/spanspan id=summary_alias_containerspan
id=short_desc_nonedit_display/span/span/p
  pA small C applicationamp; library with almost zero dependency.
Should be fairly easy to review./p
  pbr
  /p
  pThanks!/p
  pHedayatbr
  /p
  pbr
[1]a class=moz-txt-link-freetext 
 href=https://bugzilla.redhat.com/show_bug.cgi?id=678634;https://bugzilla.redhat.com/show_bug.cgi?id=678634/a/p
  p[2]a class=moz-txt-link-freetext 
 href=https://bugzilla.redhat.com/show_bug.cgi?id=755358;https://bugzilla.redhat.com/show_bug.cgi?id=755358/abr
  /p
/body
 /html
 Ugh, please don't send HTML-only emails to the list...

 -- Petr


 N�n�r)em�h�yhiם�w^��

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

Re: Review Swaps

[Hedayat Vatankhah]

On ۱۱/۱۱/۲۱  03:06, Jiri Popelka wrote:

 I've taken them.

 Here is mine (SpliX - Driver for QPDL/SPL2 printers)
 https://bugzilla.redhat.com/show_bug.cgi?id=755069

 Thanks,

 Jiri

Thanks, I took yours.

Hedayat



 On 11/21/2011 11:15 AM, Hedayat Vatankhah wrote:

 Hi all,

 I'd like to swap these reviews with some other (not-so-complicated) ones:

 Saaghar[1]- A Cross-Platform Persian Poetry Software

 This is a Qt based application, and should not be complicated.

 jcal[2] - Unix cal-like interface to libjalali

 A small C application  library with almost zero dependency. Should 
 be fairly easy to review.


 Thanks!

 Hedayat


 [1] https://bugzilla.redhat.com/show_bug.cgi?id=678634

 [2] https://bugzilla.redhat.com/show_bug.cgi?id=755358




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

Re: Review swaps

[Hedayat Vatankhah]

Hi Jerry,

/*Jerry James loganje...@gmail.com*/ wrote on 04/28/2011 10:19:39 PM
+0450:
 Hi all,

 I'd like to swap a couple of reviews.  My packages:

 openfst: https://bugzilla.redhat.com/show_bug.cgi?id=681976
 This is the next chunk of a voice recognition stack (CMU Sphinx) I've
 slowly been pushing into Fedora.

 csdp: https://bugzilla.redhat.com/show_bug.cgi?id=689039
 This is used by some theorem provers, namely coq (which is already in
 Fedora, and complains bitterly that csdp is missing if you do certain
 things), and Isabelle (which I hope to see in Fedora sometime before I
 die).

 Both are moderately complex packages.  Let me know what I can review
 for you in exchange.
I'll take csdp.
You can take one of the following (or both ;) ); they should be
relatively easy to review:
os-prober: https://bugzilla.redhat.com/show_bug.cgi?id=678442

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

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

Re: Review Request!

[Hedayat Vatankhah]

Thanks :)

/*lakshminaras2...@gmail.com lakshminaras2...@gmail.com*/ wrote on
04/22/2011 3:13:17 PM +0450:
 I have taken starcal.

 On Fri, Apr 22, 2011 at 3:30 AM, Hedayat Vatankhah
 hedayat@gmail.com mailto:hedayat@gmail.com wrote:

 Hi all,
 I have 3 review requests waiting for someone to take over for about 2
 months. Unfortunately, currently I cannot offer  review swaps, but I
 hope some of you will take them :P

 These are the review requests:
 os-prober - Probes disks on the system for installed operating systems
 URL: https://bugzilla.redhat.com/show_bug.cgi?id=678442
 (This can be used to generate Grub menu entries automatically, and
 should be relatively easy to review (IMHO))

 starcal - A desktop calendar with Gregorian, Jalali and Hijri support
 URL: https://bugzilla.redhat.com/show_bug.cgi?id=679133

 Saaghar - A Cross-Platform Persian Poetry Software
 URL: https://bugzilla.redhat.com/show_bug.cgi?id=678634

 Thanks in advance,
 Hedayat

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




 -- 
 Regards
 Lakshmi Narasimhan T V
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Review Request!

[Hedayat Vatankhah]

Hi all,
I have 3 review requests waiting for someone to take over for about 2
months. Unfortunately, currently I cannot offer  review swaps, but I
hope some of you will take them :P

These are the review requests:
os-prober - Probes disks on the system for installed operating systems
URL: https://bugzilla.redhat.com/show_bug.cgi?id=678442
(This can be used to generate Grub menu entries automatically, and
should be relatively easy to review (IMHO))

starcal - A desktop calendar with Gregorian, Jalali and Hijri support
URL: https://bugzilla.redhat.com/show_bug.cgi?id=679133

Saaghar - A Cross-Platform Persian Poetry Software
URL: https://bugzilla.redhat.com/show_bug.cgi?id=678634

Thanks in advance,
Hedayat

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

Re: Which fonts should be pulled in by desktop environments as dependencies?!

[Hedayat Vatankhah]

/*Kevin Kofler kevin.kof...@chello.at*/ wrote on 02/22/2011 6:49:00 PM
+0350:
 Nicolas Mailhot wrote:

 Le Lun 21 février 2011 22:27, Hedayat Vatankhah a écrit :
 Thanks for the answer. I also thought that it is reasonable, but wanted
 to make sure before calling others for it. I just wonder if it is
 possible to have group dependencies in comps.xml or by packages! What is
 the best way for enforcing such dependencies in Fedora?
 Well that is a question for fedora-devel and the tools people :)
 Well, please do not add hardcoded dependencies on all those packages to 
 desktop environment packages. If I don't need fonts for [insert language 
 here], I should be able to remove them. The fonts group in comps, which is 
 already installed by default, is the right place for those fonts.

Is it possible to depend on a group instead of a package at all? And if
that's possible, what happens if a default package of a group is removed?!

Thanks
Hedayat

 Localized live kickstarts also need to be able to remove fonts for locales 
 they don't support, to make room for packages to support the locales they do 
 support.

 Kevin Kofler

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

Re: Confused with budhi: my package is pushed to stable, but resides in updates-testing!?!

[Hedayat Vatankhah]

/*Kevin Fenzi ke...@scrye.com*/ wrote on 11/15/2010 8:22:04 PM +0350:

On Sun, 14 Nov 2010 16:59:17 +0330
Hedayat Vatankhahhedayat@gmail.com  wrote:


As I've mentioned, this update is a simple rebuild and the current
package in stable repositories is simply unusable as it crashes
immediately. So, please push it to stable ASAP.

ok. I think I have tagged it so it should go out in the next push.

I'll ask Luke when he gets back why it might not have gone out.

Thanks


Moving forward, perhaps get someone else to test and +1 the package?
hmmm in fact, it is not easy to find testers for such special-purpose 
packages but I'll try to.


Thanks,
Hedayat


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

Confused with budhi: my package is pushed to stable, but resides in updates-testing!?!

[Hedayat Vatankhah]

Hi all,
According to [1], my updated simspark package has been pushed to stable; 
but it is not! The package is available in updates-testing. I wonder if 
it is expected considering the new updating criteria or it is a bug. 
Anyway, it is confusing. What's happening?

Finally a question: this update is simply a rebuild of the package and I 
wanted it to reside in updates repository ASAP (For whatever reason, the 
previous build causes an application using this library to crash; but it 
is fixed with a rebuild of the packages. I don't know why, but a rebuild 
fixes the problem.).

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

Re: Confused with budhi: my package is pushed to stable, but resides in updates-testing!?!

[Hedayat Vatankhah]

/*Hedayat Vatankhah hedayat@gmail.com*/ wrote on 11/13/2010 
5:28:49 PM +0350:

Hi all,
According to [1], my updated simspark package has been pushed to 
stable; but it is not! The package is available in updates-testing. I 
wonder if it is expected considering the new updating criteria or it 
is a bug. Anyway, it is confusing. What's happening?


Finally a question: this update is simply a rebuild of the package and 
I wanted it to reside in updates repository ASAP (For whatever reason, 
the previous build causes an application using this library to crash; 
but it is fixed with a rebuild of the packages. I don't know why, but 
a rebuild fixes the problem.).


Thanks,
Hedayat

Oops, sorry:
[1] 
https://admin.fedoraproject.org/updates/simspark-0.2.1-3.fc14?_csrf_token=eb47995b995f378b3b59fdc2b2cc12da44330ef9


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

Re: Fedora 15, new and exciting plans

[Hedayat Vatankhah]

/*Kevin Fenzi ke...@scrye.com*/ wrote on 11/12/2010 8:05:54 PM +0350:

Greetings.

Fedora 14 was a pretty relaxing and stable release. I'm thinking that
Fedora 15 may be much more exciting. ;)

Things I know of so far:

* systemd
* gnome3 / gnome-shell default
* removing a bunch of suid stuff in favor of capabilities
* xfce 4.8 (with any luck).

Things that are out there, but no idea if anyone is working on them or
if they might be ready by f15:

* grub2 (no one is driving for this that I know of, but has some
   advantages over our grub1 if someone is willing to run with it, although
   it may be a lot of work to get it to where we need it).

* btrfs (Is this ready to be default? :) If so, would that warrant a
   change in our lvm by default setup?

* Can we finally remove hal? (xfce4.8 shouldn't need it anymore with
   any luck).

* Will NM finally be able to do bridging?

* Some kind of packaged wayland to play with, even if it doesn't do
   much?

Any other exciting work in progress that might land in F15 that people
are actively working on?
We at Fedora Robotics SIG are working on Fedora Robotics Spin for Fedora 
15. It's a bit special purpose but it might look interesting too :)





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

Re: Ubuntu 10.10's installer looks rather nice

[Hedayat Vatankhah]

 Hi,

/*Luya Tshimbalanga l...@fedoraproject.org*/ wrote on 10/15/2010 
6:06:10 AM +0350:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/10/10 03:41 AM, Richard W.M. Jones wrote:

I installed and played with Ubuntu 10.10 over the weekend (in a VM),
and I have to say that their installer is very smooth indeed. It's
starting to make anaconda look distinctly clunky.

Some of the things it does which are IMHO better:

- starts disk formatting / copying / installing in parallel
with asking user questions

- downloads updates in parallel too

- uses IP geolocation to guess the user's timezone and keyboard
settings (it's been 100% correct for me each time)

- suggests a username and hostname based on the user's real name
(Mac OS X's installer also does this -- it's a nice touch)

This is in contrast to anaconda (certainly from the live CD install)
which seems to be a usability no-go area.

Thoughts? Can we switch to their installer?

Rich.


Looking at the installation and the documentation of Ubuntu 10.10, the
outside looks nice but the functionality is very lacking as pointed out
on many posts. AFAIK, Ubuntu installer does not have the ability to
customize installation for use needs as highlighted and can be only done
offline. I don't know if there are installer from live media that
provide more control about package to install other than extracting the
bundled applications.

What anaconda needs is more refinement and polishing as majority of
function are already in place (has the team solved issue about multiple
boot bug  or recognition of other installed distributions).

To answer the question: don't switch to that new installer.
I completely agree. I've never heard any of the users who prefer Ubuntu 
to complain about the mentioned problems with the Fedora's installer. 
While those features are nice to have, but it's not hard for users to 
live with them at all. The only thing that I've seen that some 
(specially novice) users prefer about the Ubuntu installer is the 
ability to install from the Windows environment and it's ability to 
install Ubuntu inside a Windows partition without requiring to change 
hard disks partitioning (IIRC the old RedHat had this feature for 
sometime).
I was also proud of Anaconda's features, and hardly against reducing its 
feature set. Looking for new users should not make us forgetting current 
Fedora users. There is some reason that the current Fedora users has not 
switched to Ubuntu; but if you make things more and more like Ubuntu the 
current users will look somewhere else to find what they want.


For example, I do lots of Fedora installations, but I rarely do a normal 
install. On my own ThinkPad X61 I use hard disk installation (it doesn't 
have any DVD/CD drives), and for others I usually do an HTTP install 
from my laptop. (Installing from live medias or BFO installation methods 
are simply a No-Go for me because of the required during-install or 
after-install bandwidth).
Also, from time to time I do organize some competitions in which I 
should install Linux on many systems, and so I do an HTTP install to 
install in parallel. In my case, being able to do a hard disk install 
from an NTFS partition (which worked fine in F13 but doesn't work in 
F14, and it was never officially supported) is much much more important 
(as I don't have any non-lvm ext partitions and FAT partitions have been 
long gone from hard disks!) than the mentioned features.


Another thing which hits me is being forced to customizing package list 
always: if you select Software Development as the software you need, 
you cannot select any other option in the new Anacondas; and in its 
default selection there is no Office suits, no media applications and 
even it doesn't select Eclipse (I wonder if most of software developers 
do not use office and sound/video applications!). So, I'm forced to 
customize the package selection.


IMHO, the features I mentioned provide more than a little faster 
installation or guessing user's timezone.


Good luck,
Hedayat



- -- 
Luya Tshimbalanga

Graphic  Web Designer
E: l...@fedoraproject.org
W: http://www.thefinalzone.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJMt74WAAoJEGZ+gIukWeEez4UH+wcvdTZBl8TvStVILx2vHGF2
1L1mgvYlfyZqmvTA/B8oFaU5uId3tNCFhoeGAhWEXwhjX2R9mX8MFjI5Gf+aU5Me
A9rI2PGePvcV9jJ7B+Fohc5/61KGAYtitNZhiDq8MlBH1TMEH+HfesX3nzMvn3iV
wjDELf3dzistkprX7ERSBm+pV0auUkYIQuOlr8AapoZzhi9LaRaOW4rBORb92ATf
EfKOxu/ukicaqebrMHaMB3PaDDSXhFb/99opE+pwDG5IcwCymuMfiBT+D1g5+1vr
SYyThPcxmhd1BGmXpO8ChW/wwIYQJ32hTvixvBJCiIVSUp9AIkJSEZdRf1lllUc=
=1O1D
-END PGP SIGNATURE-

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

Re: Does anybody know how to contact David Zeuthen (festival maintainer)?

[Hedayat Vatankhah]

/*Matthias Clasen mcla...@redhat.com*/ wrote on 10/03/2010 6:26:50 AM 
+0350:

On Sat, 2010-10-02 at 20:45 +0330, Hedayat Vatankhah wrote:

Hi,
Considering the fact that the maintainer is not responsible for a long
time, I'd like to ask if anybody knows how to contact David Zeuthen?!
Festival seems to be unmaintained for more than a year. But it has many
commiters which might decide to become its maintainer.

You can reach David by sending him mail (dav...@redhat.com) or finding
him on irc (davidz on GimpNet).

I think I was supposed to CC him on my last email. So, it is done now. 
If he doesn't answer here, I'll try to look him up in IRC.


Thanks,
Hedayat

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

Re: Is this (broken keyboard layouts) a Fedora 14 Blocker bug?!

[Hedayat Vatankhah]

 Hi,

/*Parag N(पराग़) panem...@gmail.com*/ wrote on 10/02/2010 11:59:03 AM 
+0350:

Hi,
On Sat, Oct 2, 2010 at 3:52 AM, Hedayat Vatankhahheda...@grad.com  wrote:

�Hi,
I've tried testing Fedora 14 Beta (RC3, but updated), and soon I come
across this bug[1]. I could discover the initial cause and propose a fix
(which, after reporting to freedesktop bugzilla, I found that is already
fixed in xkbconfig git (but still should be pushed to F14)). Then, I
came across another bug (which is detailed in the end of [1], and is
followed at [2] and [3]) which will affect a number of keyboard layouts
in F14.
In brief, this bug will cause some keyboard layouts to be broken in F14,
which IMHO should not go in Fedora 14 Final.
I wonder if it can be qualified as a blocker bug.

Thanks,
Hedayat

[1]https://bugzilla.redhat.com/show_bug.cgi?id=638244
[2]https://bugs.freedesktop.org/show_bug.cgi?id=30548
[3]https://bugs.freedesktop.org/show_bug.cgi?id=30549
-

  I think xkeyboard-config-2.0 has already got some(or all the
reported) bugs fixed. I too got some problems in 1.9 build and
reported upstream [1]. I am too waiting for 2.0 to be built in F14.
Its already built for F15 and working fine. I have sent a mail to
xkeyboard-config package owner to build it soon in F14 so that we can
have this new build go through bodhi process and reach to stable(GA)
repository.

Parag.

[1]https://bugs.freedesktop.org/show_bug.cgi?id=30233
Thanks for the notice. I've noticed this bug yesterday but I'm not sure 
if this is the same problem. If you can test 2.0 release, would you 
please try pressing d key after enabling the ir layout to see if it 
prints any characters? (This key is defined using unicode hex characters 
rather than corresponding character name. But notice that this has been 
changed in git yesterday, so git source will work. But in 2.0, it is 
defined using character's unicode hex code).


Thanks,
Hedayat

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

Re: Is this (broken keyboard layouts) a Fedora 14 Blocker bug?!

[Hedayat Vatankhah]

/*Nicolas Mailhot nicolas.mail...@laposte.net*/ wrote on 10/02/2010 
10:12:25 AM +0350:

Le samedi 02 octobre 2010 à 01:52 +0330, Hedayat Vatankhah a écrit :


In brief, this bug will cause some keyboard layouts to be broken in F14,
which IMHO should not go in Fedora 14 Final.
I wonder if it can be qualified as a blocker bug.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=638244
[2] https://bugs.freedesktop.org/show_bug.cgi?id=30548
[3] https://bugs.freedesktop.org/show_bug.cgi?id=30549

I suppose

[4] is the same
https://bugzilla.redhat.com/show_bug.cgi?id=617959
Maybe. But in my case, no characters are emitted at all in those cases. 
I've tried some other layouts and in my tests, any characters defined 
using its unicode hex code has stopped working. It is even not shown in 
the gnome's layout preview.


Thanks,
Hedayat

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

No response from festival-speechtools maintainer since 2009-6-24

[Hedayat Vatankhah]

  Hi,
There has been no response from the maintainer since 2009-06-24 as is 
clear in [1]. Also, the package has not been updated since then. I 
wonder what should I do now (?)

Thanks,
Hedayat

[1] https://bugzilla.redhat.com/show_bug.cgi?id=507966
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Does anybody know how to contact David Zeuthen (festival maintainer)?

[Hedayat Vatankhah]

  Hi,
Considering the fact that the maintainer is not responsible for a long 
time, I'd like to ask if anybody knows how to contact David Zeuthen?!
Festival seems to be unmaintained for more than a year. But it has many 
commiters which might decide to become its maintainer.

Thanks,
Hedayat

On ۱۰/۱۰/۰۲  08:37, Hedayat Vatankhah wrote:


 On ۱۰/۱۰/۰۲  03:55, Chen Lei wrote:
 2010/10/2 Hedayat Vatankhahheda...@grad.com:
   Hi,
 There has been no response from the maintainer since 2009-06-24 as is
 clear in [1]. Also, the package has not been updated since then. I
 wonder what should I do now (?)

 Thanks,
 Hedayat

 [1] https://bugzilla.redhat.com/show_bug.cgi?id=507966
 -- 
 See 
 http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

 Chen Lei
 Thanks.

 Well, I've checked pkgdb, and apparently there are many people with 
 commit access on festival. Also, it seems that David maintains many 
 packages, so he is probably not completely unresponsive!
 I wonder what should be done in this case?!

 Thanks,
 Hedayat



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

Is this (broken keyboard layouts) a Fedora 14 Blocker bug?!

[Hedayat Vatankhah]

  Hi,
I've tried testing Fedora 14 Beta (RC3, but updated), and soon I come 
across this bug[1]. I could discover the initial cause and propose a fix 
(which, after reporting to freedesktop bugzilla, I found that is already 
fixed in xkbconfig git (but still should be pushed to F14)). Then, I 
came across another bug (which is detailed in the end of [1], and is 
followed at [2] and [3]) which will affect a number of keyboard layouts 
in F14.
In brief, this bug will cause some keyboard layouts to be broken in F14, 
which IMHO should not go in Fedora 14 Final.
I wonder if it can be qualified as a blocker bug.

Thanks,
Hedayat

[1] https://bugzilla.redhat.com/show_bug.cgi?id=638244
[2] https://bugs.freedesktop.org/show_bug.cgi?id=30548
[3] https://bugs.freedesktop.org/show_bug.cgi?id=30549
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

No Jigdo download available for F-14 Alpha

[Hedayat Vatankhah]

  Hi,
While it is announced at [1] and also in the pre-release download page, 
there is no .jigdo file for F-14 Alpha.

Good luck!
Hedayat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora rawhide FTBFS status 2010-06-01 x86_64

[Hedayat Vatankhah]

/*Mamoru Tasaka mtas...@ioa.s.u-tokyo.ac.jp*/ wrote on 06/04/2010 
12:00:50 PM +0450:

Hedayat Vatankhah wrote, at 06/04/2010 03:07 PM +9:00:
   

Hi,
My packages (rcsslogplayer and rcssmonitor) are being failed because of the 
lack of Qt dependencies (QtNetwork requires ssl and crypto libraries from 
openssl-devel package, and gobject-2.0 from glib2-devel). As these packages are 
required by Qt, I think they should be added to qt-devel dependencies. Should I 
fill a bug against Qt?

Thanks,
Hedayat

 

For now I just checked rcssmonitor and the cause for build failure is that
- While rcssmonitor explicitly uses Libs.private (from m4/qt.m4 in your source
tarball) like
---
$ pkg-config --static --libs-only-l QtNetwork
-lQtNetwork -lssl -lcrypto -lQtCore -lpthread -lz -lm -ldl -lgthread-2.0 -lrt 
-lglib-2.0
---
qt(4)-devel does pull openssl-devel or so in.

However this is Libs.private dependency and man pkg-config says:
---
Libs.private:
 This line should list any private libraries in use.  Private libraries are 
libraries which are not exposed through
 your library, but are needed in the case of static linking. This differs 
from Requires.private in that  it  refer‐
 ences libraries that do not have package files installed.
---
So as we don't do static linking, this should not be needed.

I tried to add
---
sed -i.nostatic \
  -e 's|--static||g' m4/qt.m4
---
and this seems to make build succeed (I just also tried the same fix for
rcsslogplayer and it succeeds)
   

Thanks, I'll try it

Good luck,
Hedayat


http://koji.fedoraproject.org/koji/taskinfo?taskID=2229111
http://koji.fedoraproject.org/koji/taskinfo?taskID=2229126

Regards,
Mamoru


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

Re: DVD as repo

[Hedayat Vatankhah]

/*Frank Murphy frankl...@gmail.com*/ wrote on 05/10/2010 5:11:13 PM +0450:

On 10/05/10 13:28, Rahul Sundaram wrote:

   

PackageKit developers disagree with you.  Since they are the ones doing
the work involved, their opinion has more weight.  Besides a static repo
file is less flexible than the ability for PackageKit to handle media
dynamically.   Meanwhile, you can push for the solution you recommend by
filling a RFE against fedora-release.

Rahul
 

RFE filed against f*release
https://bugzilla.redhat.com/show_bug.cgi?id=590658
   
Thanks for the RFE, and just to make you sure that I am in touch with 
the bug you can see: 
http://hedayatvk.wordpress.com/2009/02/22/using-fedora-dvd-not-a-solution-but-a-bit-better/


But it is still not that good. And the implementation by Muayyad handles 
removable media much better. As it is 99% complete, it is really 
reasonable to get it 100% and make many users happy.


Anyway, thinking about the problem with DeviceKit system policies, I 
really feel that the current situation is flawed: a process running as 
root is able to mount a device either by calling mount system call or by 
running the mount command, but it is unable to mount a device using 
DeviceKit. Why?! This is an inconsistent policy IMHO. And I feel it 
should be fixed anyway. Any comments?


Thanks,
Hedayat

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

Re: Reasons for hall monitoring

[Hedayat Vatankhah]

/*Adam Williamson awill...@redhat.com*/ wrote on 05/10/2010 3:18:06 PM 
+0450:

On Mon, 2010-05-10 at 11:33 +0200, Matěj Cepl wrote:
   

Dne 10.5.2010 11:26, drago01 napsal(a):
 

To have stuff just work.
   

Go to http://senate.gov/ and ask your congressman to fix it. Otherwise
(for example if you don't have your congressman because you are not a
U.S. citizen), you can also try to move Red Hat's headquarters outside
of U.S. (although I am not sure, it would be enough, you would probably
ask its biggest clients to move).
 

That's the wrong argument. We all know why we _can't_ make it just work,
but that doesn't excuse us. Sorry to take a well-worn analogy, but if
two guys are trying to sell you cars, and one doesn't have an engine,
would the fact that the guy selling the car with no engine has a *really
good and inarguable reason* why it doesn't have an engine make you buy
that car? Hell no. You'd buy the car with the engine.

Just because we have a *really good reason* we can't ship this stuff
doesn't mean we are excused from the fact that it's a distinct negative
for the use of our operating system as a general-purpose desktop
operating system.
   
Just my 0.2 cents in this regard: well, we have a car without engine, 
and a suitable engine is built somewhere which we can't use. But, I 
wonder why there is nobody to pick our car and the engine and sell the 
car with engine to people who don't want to do that themselves?
RPMFusion is a very well-known engine builder! While there were/are some 
efforts to ship our car with its engine, there is no well-known Fedora 
remix which contains the extra stuff (it is probably because most of the 
current users have already adopted with using rpmfusion if they want 
it). If we can come up with enough people to provide and maintain a 
Fedora remix for awhile, it can become well-known and something which is 
always there, so we can point beginners to that one instead of other 
distros if they want such a distro.
We (I and a very few others) are going to create a remix, but our 
current target users are a bit more restricted (mostly because of lack 
of manpower) (Also we are currently targeting a DVD installation media 
rather than live media).  But if there are some other interested people 
out there, we can go for the mentioned remix (and we will probably base 
our custom remix on that).


Good luck,
Hedayat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: DVD as repo

[Hedayat Vatankhah]

/*Matthias Clasen mcla...@redhat.com*/ wrote on 05/10/2010 5:59:56 PM 
+0450:

On Mon, 2010-05-10 at 17:58 +0430, Hedayat Vatankhah wrote:

   

Anyway, thinking about the problem with DeviceKit system policies, I
really feel that the current situation is flawed: a process running as
root is able to mount a device either by calling mount system call or
by running the mount command, but it is unable to mount a device using
DeviceKit. Why?! This is an inconsistent policy IMHO. And I feel it
should be fixed anyway. Any comments?

 

Can you explain this or point to a bug ? I'm positive that this is
supposed to work.

   
According to https://bugzilla.redhat.com/show_bug.cgi?id=435625#c21 
policykit doesn't allow the yum backend of PackageKit (which is running 
as root) to mount devices.


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

Re: How this bug can come out of its dead-end? Any suggestions?!

[Hedayat Vatankhah]

/*Frank Murphy frankl...@gmail.com*/ wrote on 05/08/2010 10:51:42 PM 
+0450:

On 08/05/10 19:15, Hedayat Vatnakhah wrote:
   
 
   

Please have a look at the last comments of the bug. Most of the
implementation is done, the only missing part is how to mount the CD/DVD
in PackageKit!

Thanks,
Hedayat


 

If you can install gnome-packagekit-extra if using Gnome?

Is houls allow you to choose which sources\repos to use.
   
No, the problem is this: PackageKit does not know how to mount a 
removable media. As noted in the last comment of the mentioned bug, 
Muayyad Alsadi has implemented four methods for mounting a removable 
media: using DeviceKit, using GIO, using HAL and calling the system's 
mount command. The DeviceKit implementation cannot mount the device 
because of default system policies (the backend is running as root), GIO 
has a bug and does not allow mounting, HAL is deprecated, and PackageKit 
developer doesn't like mounting using the system's mount command!


Thanks,
Hedayat

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

Re: How this bug can come out of its dead-end? Any suggestions?!

[Hedayat Vatankhah]

On ۱۰/۰۵/۰۹  11:41, Frank Murphy wrote:
 On 09/05/10 07:52, Hedayat Vatankhah wrote:
 --snip--

 No, the problem is this: PackageKit does not know how to mount a
 removable media.

 It doesn't need to.

 --snip--

 Mount DVD as normal.
 your dvd.repo : baseurl:file://path/to/dvd/(repodata)

 eg: baseurl=file:/media/Fedora 12 i386 DVD
 enabled=1
 gpgcheck=true

 Why fix a bug that doesn't need to be fixed.

 Above method works for me.
Personally I do know how to use DVD as a repository, but that's not 
suitable for users AT ALL. This bug is about OUT OF THE BOX installation 
media support by packagekit.

Thanks,
Hedayat


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

Re: How this bug can come out of its dead-end? Any suggestions?!

[Hedayat Vatankhah]

On ۱۰/۰۵/۰۹  11:43, Ankur Sinha wrote:
 On Sun, 2010-05-09 at 11:22 +0430, Hedayat Vatankhah wrote:

 Frank Murphyfrankl...@gmail.com  wrote on 05/08/2010 10:51:42 PM
 +0450:
  
 On 08/05/10 19:15, Hedayat Vatnakhah wrote:


 Please have a look at the last comments of the bug. Most of the
 implementation is done, the only missing part is how to mount the CD/DVD
 in PackageKit!

 Thanks,
 Hedayat



  
 If you can install gnome-packagekit-extra if using Gnome?

 Is houls allow you to choose which sources\repos to use.


 No, the problem is this: PackageKit does not know how to mount a
 removable media. As noted in the last comment of the mentioned bug,
 Muayyad Alsadi has implemented four methods for mounting a removable
 media: using DeviceKit, using GIO, using HAL and calling the system's
 mount command. The DeviceKit implementation cannot mount the device
 because of default system policies (the backend is running as root),
 GIO has a bug and does not allow mounting, HAL is deprecated, and
 PackageKit developer doesn't like mounting using the system's mount
 command!

 Thanks,
 Hedayat
  
 hey,

 A suggestion.

 Instead of working specifically and trying to mount the dvd/cd, why not
 have an option that says use a custom/local repo

 It could open an explorer window and let you choose the repo directory.
 Since dvds/cds are mounted by default on insertion, the user could
 easily select it and use it as an additional repo. This way, you
 (packagekit devs) don't have to worry about mounting the dvd/cd media,
 and are also providing support for any local repos that people might
 want to use (copied repos using USB hard drives etc). You won't need to
 get the media.repo and configure it to the correct path etc. too.

 Comments?


First of all, such changes should be discussed with the PackageKit 
author. AFAIK, he doesn't agree with such changes. Also, Muayyad's work 
seems to cover USB media support too (you can see this page for more 
information: http://fedoraproject.org/wiki/Features/MediaRepo). And your 
suggestion will not work with split media IMHO.

Personally, I think even the solution to use system's mount command is 
much better than the current situation, but apparently the PackageKit 
author doesn't like it at all!

Thanks,
Hedayat


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

Re: How this bug can come out of its dead-end? Any suggestions?!

[Hedayat Vatankhah]

/*Frank Murphy frankl...@gmail.com*/ wrote on 05/09/2010 4:20:15 PM +0450:

On 09/05/10 12:34, Björn Persson wrote:
   

Frank Murphy wrote:
 

That *should not* be default for most users,
as it will end up breaking quite a lot,
if used with other repos. (updates,updates-tesing, 3rd party)
   

If using the DVD together with the updates repository would break quite a lot,
 

That's just my bad explanation. (not enough coffee)

What I should have said:
If the user does not know how to mount a CD\DVD.
(which is automatic?)
Should they be given usage of PackageKit,
which at the least would require root (p\w) or sudo (within terminal).

If it is a bandwidth $cost,
could not the CD\DVD ~/packages be copied to ~/local/folder,
and shared with a number of users.
along with update\3rd Party repo (as they are downloaded).
using yum*local, hence reducing the $cost.

(also reduces media swapping)

Still no need for a PackageKit rfe fix.

Frank
   
Well, sorry but you simply don't get it! Give a Fedora DVD to a new 
Linux user and tell him to install it on his own system. Then ask him to 
install Eclipse from DVD since he will most probably NOT opt to 
customize his package set in the installation process. Make sure that he 
has no Internet access, and do NOT help him in the process. He will be 
certainly unable to do so. Then do this for him yourself and see how 
frightened is him.


If you get him an Ubuntu DVD, you'll see that he can happily use it 
without your help. And you'll see why he will think that Ubuntu is much 
easier than Fedora. If you have not see this at all, I've seen this 
frequently. Fedora sucks in this area for many years. I've seen it, so 
whatever arguments you bring; I KNOW that this bug IS very important and 
should be fixed.
Excuse me, I'm looking for a solution, not for wiping the problem 
statement.


Thanks,
Hedayat

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

Re: How this bug can come out of its dead-end? Any suggestions?!

[Hedayat Vatankhah]

/*Kevin Kofler kevin.kof...@chello.at*/ wrote on 05/09/2010 9:24:04 PM 
+0450:

Frank Murphy wrote:
   

That *should not* be default for most users,
as it will end up breaking quite a lot,
if used with other repos. (updates,updates-tesing, 3rd party)

as %requires may have changed quite a bit since DVD was released.
 

That shouldn't be a problem as long as updates is enabled.

A more pertinent reason not to enable this by default is that many users
will misplace the DVD and prefer just downloading the packages. Many of them
have updates anyway.
   
For those users, they will receive updated packages from the internet if 
there are any updates. And if there isn't any, yes the packages will be 
installed from DVD. But this doesn't seem to be much inconvenience, and 
also will be the natural thing to happen IMHO. I think the reasons for 
having this enabled by default (while I've never talked about having it 
enabled by default; being able to enable it using the software sources 
selection is much much more convenient than the current workarounds) are 
more acceptable. Anyway, I've never talked about having them enabled by 
default.



And to really suit users with no or a very slow Internet connection, we'd
also have to disable updates by default which we definitely DO NOT want.
   
No. It would suffice if PackageKit disables/discards online repositories 
when there is no network connection and enables them otherwise. 
Interestingly, the latest packagekit in Fedora 13 disables online 
repositories (and print errors) if their connection time out (and so it 
is still usable), but will print errors and stops working if system is 
offline! (it should do the same thing when offline). So, you can have 
the online repositories enabled by default and suit such users at the 
same time.



As I've already said more than once, IMHO we should just add broadband
Internet connection to Fedora's system requirements, it's effectively
already required. Sure, you can get it to work without it with some manual
workarounds, but for Fedora to work properly out of the box, and to get
updates (including security fixes, critical bugfixes etc.), you need a
(reasonably fast) Internet connection.
   
1. Such manual workarounds can be fixed pretty easy; and IMHO they 
should be fixed anyways. Everybody might sometimes be offline, and 
should be able to work reasonably in that cases too (e.g. it is really 
ridiculous to be unable to remove a package from your system when you 
are offline because yum/packagekit cannot update repository metadata!). 
Also I think the ability to install packages from installation media 
(and any removable media containing a repository) is still reasonable 
too (you can get updates as soon as you are online again).


2. Almost all modern OSes provide updates, so do you want to say that a 
user with no or poor internet connection should not use them?!! Also 
notice that most of security fixes are not that important for such users 
anyway! Also, Fedora is not the only Linux distribution who have such 
online repositories; Debian has had them even at the times which 
broadband internet connection was not so common (and this is IMHO why 
its package manager treats such users much better).


Thanks,
Hedayat


 Kevin Kofler

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

Re: F-13 yum in kvm or vmware guests

[Hedayat Vatankhah]

/*Seth Vidal skvi...@fedoraproject.org*/ wrote on 05/06/2010 11:47:39 
PM +0450:



On Thu, 6 May 2010, Hedayat Vatnakhah wrote:


Hi,

Warren Togami war...@togami.com wrote on ‫پنجشنبه ۰۶ مه ۱۰، 
۰۲:۱۰:۴۸‬:On ۱۰/۰۵/۰۶  02:10, Warren Togami

wrote:

(10/12): samba-3.5.2-60.fc13.x86_64.rpm   (71%) 73% 
[-  ]  0.0 B/s | 3.7 MB 
3340883129410265958989882401668816722716705737932:48 ETA


Anyone else seeing this kind of behavior with F-13 yum within kvm or 
vmware guests?  It seems to happen consistently here in the middle of 
downloading multiple packages where I need to kill yum and try again.



It is nothing new if you've tried using yum in a poor internet 
connection. I've seen it regularly in Fedora

12 and IIRC Fedora 11.



Hedayat,
 take the python-urlgrabber pkg from rawhide 0 3.9.1-6.fc14 and give 
it a whirl.
I installed the mentioned package and it seems that the problem is 
solved. The connection properly times out when the speed comes near 
zero. I'll let you know if I could reproduce the bug again.


Good luck,
Hedayat




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

Re: How this bug can come out of its dead-end? Any suggestions?!

[Hedayat Vatankhah]

On ۱۰/۰۵/۰۹  10:43, Alexander � wrote:
 sön 2010-05-09 klockan 11:22 +0430 skrev Hedayat Vatankhah:


 No, the problem is this: PackageKit does not know how to mount a
 removable media.
  
 Why do you even need to mount it? Removable media is of course
 automatically mounted when you insert it (if someone is logged in on the
 console).

You can see comments 25 till end. I've proposed it once, but ... . I'll 
try again!
But I'm just thinking if the problem with DeviceKit is not really a bug: 
a process running as root is able to mount something using the mount 
system call or just by calling the system's mount command, so why should 
it be unable to do so using DeviceKit?! I wonder if it is reasonable!

Thanks,
Hedayat

 /Alexander




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

Re: GCC precompiled headers question

[Hedayat Vatankhah]

Hi,

On ۱۰/۰۵/۰۶  03:34, Christoph � wrote:
 Hi all,

 this is an off topic question, but since I know that some of you are
 familiar with gcc, I am asking it here before signing up somewhere else.

 I have to source-compile one language (Modelica) to C++. Since Modelica
 has a structural subtype system, I'd like to create classes that way:

 //Modelica
 class Foo
   Real x;
 end Foo;

 //C++
 templateFoo_Real  class Foo {
   Foo_Real x;
 }

 That means every generated class (and function for that matter) is
 (parametric) polymorphic and can be reused in other compilation units
 for subtypes. Unfortunately that also means, that I can only generate
 headers and no libraries or object files. Basically g++ plays the role
 of a linker for modelica. But this means that g++ will parse, check and
 compile every header again and again even if it's clear (at least after
 the first pass) that the code is sane.

 I've learned that the C++ standard delivers the export keyword to
 include template symbols in object files, but g++ does not support this.
 The closest thing I've seen to export would be precompiled headers.
 Unfortunately g++ also allows one single precompiled header per
 compilation unit. Does anyone know why? And is there any way to speed up
 the linking process a little (like letting g++ at least preprocess the
 headers or something like this)?

Have a look at gcc info: C++ Extensions-Template Instanciation. You can 
go with the first method: using -frepo but notice that it doesn't work 
when ccache is enabled. So, you can export CCACHE_DISABLE=1 before 
running gcc with -frepo option. Also, I think you can go with a solution 
using export keyword too (the second method).

Good luck,
Hedayat
 thanks for any comments,

 Christoph


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

How this bug can come out of its dead-end? Any suggestions?!

[Hedayat Vatankhah]

Hi all,
There is a bug in Fedora package management since FC4 (except Fedora 8) 
that potentially affects ALL of the Fedora installation DVD users 
(people who are not annoyed by this bug will probably find other 
alternatives more suitable (e.g. Live CD install, Network install or the 
new BFO if I spell correctly!)). The reason that this bug is still open 
is not technical, but almost completely political. And as I see it in 
the current state, it is not going to be fixed anytime soon.


The mentioned bug is this one: 
https://bugzilla.redhat.com/show_bug.cgi?id=435625 (installation media 
support in PackageKit).


While a user can create a repo file for the DVD's mount point and go 
with it, but that is not acceptable for a new user to live with such a 
solution.


It is really annoying that the installation DVD is useless for an 
ordinary user after installation. And this is really unfortunate that 
this bug is still open because of such small issues.


I hope that somebody could suggest something which can make some 
progress in this area.


Good luck,
Hedayat

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

Re: How this bug can come out of its dead-end? Any suggestions?!

[Hedayat Vatankhah]

On ۱۰/۰۵/۰۸  06:01, drago01 wrote:

On Sat, May 8, 2010 at 3:18 PM, Hedayat Vatankhahheda...@grad.com  wrote:
   

Hi all,
There is a bug in Fedora package management since FC4 (except Fedora 8)
that potentially affects ALL of the Fedora installation DVD users
(people who are not annoyed by this bug will probably find other
alternatives more suitable (e.g. Live CD install, Network install or the
new BFO if I spell correctly!)). The reason that this bug is still open
is not technical, but almost completely political. And as I see it in
the current state, it is not going to be fixed anytime soon.


The mentioned bug is this one:
https://bugzilla.redhat.com/show_bug.cgi?id=435625 (installation media
support in PackageKit).


While a user can create a repo file for the DVD's mount point and go
with it, but that is not acceptable for a new user to live with such a
solution.


It is really annoying that the installation DVD is useless for an
ordinary user after installation. And this is really unfortunate that
this bug is still open because of such small issues.
 


Why?

The installation DVD is for installing the system that's it.

Installing software from it afterwards is pointless anyway as updates
might cause dep conflicts and or provide newer/fixed versions anyway.
   
Somebody who have a good internet connection and will install any new 
packages from the internet will not go with installing from DVD at the 
first place. Why should somebody download more than 3GB and use a very 
small amount of it at the installation time and then install any extra 
packages from the internet?! Such a person will probably use LiveCD 
install, or he can happily download the netinst iso (which is just about 
150MB) and then install directly from the internet. Notice that a lot of 
DVD users do not download it themselves and will buy it or receive it 
from another person. And they need to be able to use it as much as 
possible.


If it is still ambiguous, let me bring an example: currently I have only 
a dial-up connection at home. As a result, my Fedora 11 installation is 
not updated at all (maybe only its pidgin, which I have downloaded by 
hand and installed). Even downloading the repository metadata is 
something I try to avoid as much as possible. So, I almost NEVER update 
my Linux installation in home, except if I really need it or it is so 
small (thanks to delta rpm, it is possible to update a little more). 
There are many users which will almost never install any packages from 
the internet except when they really need it, and also you should be 
aware that many prefer to buy DVDs which contain additional software 
rather than downloading that themselves.


Goo luck,
Hedayat

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

Re: [Test-Announce] Fedora 13 Final TC1 Available Now!

[Hedayat Vatankhah]

Hi,
It would be nice if Jigdo downloads could be also provided so that 
people with previous releases (e.g. Beta release) which have downloaded 
(and cached) updates could easily create new installation media without 
downloading much (which will be much less than delta isos).


Good luck,
Hedayat

/*Andre Robatino an...@bwh.harvard.edu*/ wrote on 04/30/2010 12:14:32 
AM +0450:

Fedora 13 Final TC1 is now available [1].  Please refer to the following
pages for download links and testing instructions.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Ideally, all Alpha, Beta, and Final priority test cases for installation
[2] and desktop [3] should pass in order to meet the Final Release
Criteria [4].  Help is available on #fedora-qa on irc.freenode.net [5],
or on the test list [6].

[1] http://poelstra.fedorapeople.org/schedules/f-13/f-13-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[3] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
[4] https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria
[5] irc://irc.freenode.net/fedora-qa
[6] https://admin.fedoraproject.org/mailman/listinfo/test

   



___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel