postr orphaned

[Tim Lauridsen]

I have orphaned postr a flicker uploader, I have not used it for years
Upstream has been stalled for years, but there has been some recent activity

latest upstream release is 0.13.1 not yet in fedora, because of
python-bsddb3 is not in fedora, only python3-bsddb3 is.

Tim
-- 
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: Increasing application icon sizes to 64px

[Tim Lauridsen]

On Fri, Sep 26, 2014 at 12:19 PM, Richard Hughes 
wrote:

> At the moment applications have to provide an icon >= 32x32px in size
> to be included in the AppStream metadata and shown in the software
> center. This is *tiny* on a HiDPI screen, so should I mandate that all
> applications ship a 64x64 (and ideally, 128x128/64x64@2 also) icon for
> the shell and gnome-software, or should I just pad+scale icons for the
> HiDPI case and make them look ridiculous?
>
> I don't think we can, or should, design a software center to accept
> the lowest common denominator when it comes to icon sizes; we're doing
> really well now with AppData coverage[1] and I think we can raise the
> quality of upstream and packaged icons in the same way.
>
> My proposal would make 64x64 the smallest icon size we show in the
> software center, and this will still be slightly blurry[2] in the
> HiDPI case. This would affect 539 (over half of all desktop
> applications) packaged in Fedora. It's clear we can't just do nothing,
> as more and more devices will have HiDPI screens, and more and more
> icons will look crazy small and fuzzy.
>
> I don't think it's a good idea to mass-file 539 bugs, nor do I want to
> contact 539 upstream maintainers. 127 packages only ship a 32x32 icon,
> and that might be a good starting point for contacting upstreams or
> filing bugs.
>
> Ideas? Comments? Affected packages attached as a text file.
>
> Richard
>
> [1]
> http://blogs.gnome.org/hughsie/2014/09/25/appstream-progress-in-september/
> [2] https://ryanlerch.fedorapeople.org/software-blurry2.png
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


Is it only me, that is thinking, that all there rules to make things looks
prettier in Gnome Software or  you package will get excluded if you dont
live up to the rules
is a little hostile for packagers.
It is good to have some guidelines to make your application present itself
in the best possible way if you care, but may people are more interested
in functionality and not so much about eyecandy.
I understand that Richard, want his application to look so good as
possible, but in the end it upstreams project there decides if they want to
ship at buttugly icon in 16x16
and they should not be excluded for that.
Gnome software could workaround it by have some kind of cool frame to put
around the icons  if they are to small to look good in the context of Gnome
software.

Tim
-- 
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: Increasing application icon sizes to 64px

[Tim Lauridsen]

On Thu, Oct 2, 2014 at 11:17 AM, Richard Hughes  wrote:

> Designing an application for the lowest common denominator does not
> give you a high-quality cohesive application that's easy to use and
> nice on the eye. It gives you a miss-mash of ugly noise that's hard to
> use. I think it's fine that we are essentially saying "you have to do
> X, Y, Z to be showcased on the workstation". I've essentially slipped
> into the role of the person making the decisions about the software
> installer on the workstation product, and also upstream maintainer of
> most of this stuff. If anybody wants to refer any of my decisions up
> to the workstation working group, I'd be happy to talk to them, but
> I've a feeling they would be *less* forgiving than I'm currently
> being.
>

I think that is a bad idea to exclude applications from a Software manager,
because they don't live up to some visual quality guidelines.
It don't benfit the endusers, if the software manager only shows 50% of the
gui applications in the Fedora repositories.
What about not showing the icons if they dont have the need size, just show
a default icon based on the application category
they you have both the good look and a lot of applications.

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

Review Swap : dnfdaemon - Dbus daemon for dnf package actions

[Tim Lauridsen]

If someone would review this one and let me know what to review

Review Request: dnfdaemon - Dbus daemon for dnf package actions

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


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

Re: dnf on debuglevel

[Tim Lauridsen]

On Sun, Oct 5, 2014 at 9:03 AM, Balint Szigeti 
wrote:

>
>
p.s.
> Can someone tell me how dnf tells the new (uninstalled packages)
> changelog? I tried to do it with yum but the only way that I found is yum
> changelog plugin which tell the changelog after I downloaded the packages.
> Isn't a way to queries these info?
> by the way, when I really need to know the change log I use rpm
> (--httpproxy HOST --httppport PORT ) -q -changelog 
>
>
DNF has no support for changelog metadata yet
https://bugzilla.redhat.com/show_bug.cgi?id=1066867
-- 
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: Can you help with making fonts awesome in Fedora 21?

[Tim Lauridsen]

On Thu, Oct 16, 2014 at 11:44 AM, Richard Hughes 
wrote:

> If you maintain a font in Fedora, or are a provenpackager, I could
> really need your help this weekend. Basically, we want to implement
> AppStream metadata[1] for all the fonts we want to show in the
> software center. I've already made a good start, and now other people
> are starting to help as well, so I'm pretty sure we can get the
> majority finished for next week when we can submit a mega-update of
> updated fonts.
>
> I've started a shared spreadsheet here:
>
> https://docs.google.com/spreadsheets/d/1o2sPWF7PEe6BKnBeZUI23m51nfFHUMx61IRsdNDozig/edit#gid=0
> with what needs doing -- if you can help, please put your FAS name in
> the second column and get building. If any fonts are missing that you
> think belong in the software center please feel free to add them.
>
> It's really easy to add content for fonts. This is an example with
> multiple subpackages:
>
> http://pkgs.fedoraproject.org/cgit/silkscreen-fonts.git/commit/?id=32acdd5aa900ad732c023a73f7cd269a136f0957
> and fonts with only one package are even easier, e.g.
>
> http://pkgs.fedoraproject.org/cgit/oflb-brett-fonts.git/commit/?id=72ff3099f733949f9526221b47a63eff9b9b969d
>
> If you've got any questions, please grab me on IRC (hughsie on
> FreeNode) or reply to this mail. Thanks!
>
> Richard
>
> [1] http://blogs.gnome.org/hughsie/2014/10/15/gnome-software-and-fonts/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


Mega updates, sound a litlle wrong to me so late in the F21 cycle, Fine for
rawhide (f22)

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

Re: Review swap

[Tim Lauridsen]

> I am still in need of a reviewer.  Who can help me out?  I'm willing
> to review for you in exchange.
> --
>

I will take it later today, if nobody beat me to it :)

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

Re: fedora 21 lets me install packages without root

[Tim Lauridsen]

On Mon, Oct 20, 2014 at 8:03 PM, Richard Hughes  wrote:

> On 20 October 2014 18:00, Reindl Harald  wrote:
> > uninstall anything in context of packagekit and just use yum
>
> Please stop giving advice like this. If you try to remove PackageKit
> you'll end up removing half of GNOME and probably make your system
> unbootable.
>
> 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
>

Yes, you need to leave PackageKit-glib installed on a gnome system, but the
rest can be removed, if you dont want use it
you while loose gnome-software too, but if you are only using yum/dnf on
cli, that not a problem.


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

Re: dnf vs yum

[Tim Lauridsen]

On Fri Oct 24 2014 at 12:46:41 PM Rahul Sundaram  wrote:

> Hi
>
> On Fri, Oct 24, 2014 at 3:51 AM, Michael Simacek  wrote:
>
>>
>> Mock-1.2 no longer depends on yum API and has been ported to use DNF.
>> So if you use the new version and set config_opts['package_manager']='dnf'
>> and also install dnf-plugins-core, you should be able to use it without
>> any problems.
>> But the dnf-yum (/usr/bin/yum being symlink to dnf) scenario is not
>> supported yet,
>> you have to explicitly tell it to use dnf, otherwise it won't work.
>> dnf and yum don't always behave the same and mock has to treat them a bit
>> differently. But the package itself still needs to depend on yum, because
>> even
>> if dnf-yum was supported, it doesn't pull in dnf-plugins-core package
>> which
>> contains builddep command.
>>
>
> I don't quite understand that explanation.  For rawhide, why doesn't mock
> drop the dependency on yum and add a dependency on dnf *and*
> dnf-plugins-core?
>
>
Mock still defaults to yum, but supports dnf also using
config_opts['package_manager']='dnf'

So it makes sense to have a hard requirement on yum

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

Re: dnf vs yum

[Tim Lauridsen]

On Fri Oct 24 2014 at 1:23:27 PM Rahul Sundaram  wrote:

> Hi
>
> On Fri, Oct 24, 2014 at 6:51 AM, Tim Lauridsen  wrote:
>
>>
>> Mock still defaults to yum, but supports dnf also using
>> config_opts['package_manager']='dnf'
>>
>> So it makes sense to have a hard requirement on yum
>>
>
> Well the question is, why doesn't it default to dnf in Rawhide?
>
>
>
Proberly because dnf support is very new, so it will need some more real
time use before the default is switched

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

Re: dnf vs yum

[Tim Lauridsen]

On Fri Oct 24 2014 at 4:01:20 PM Stanislav Ochotnicky <
sochotni...@redhat.com> wrote:

> On Fri 24 Oct 2014 02:26:37 PM CEST Rahul Sundaram wrote:
>
> > Hi
> >
> > On Fri, Oct 24, 2014 at 7:58 AM, Vít Ondruch wrote:
> >
> >>
> >> Yes, switch the defaults ASAP. Thanks
> >>
> >
> > FWIW,   there is still considerable work left is switching over to dnf
> > completely.
> >
> > Filtering out some minor details (based on my system),
> >
> > Bodhi-client,  fedpkg, python-meh, libreport-python, yum-utils depends on
> > yum and yum-utils itself is a dependency for fedora-review, lpf and
> > mock.
>
> FWIW fedora-review only requires yum-utils and that's only for
> repoquery. Based on a quick glance at dnf repoquery module there are a
> few things missing that we are using with repoquery:
>  * -C (use cache only)
>

dnf repoquery can use standard dnf cmd option, so -C/--cacheonly can be
used.


>  * --resolve (resolves to packages that provide required symbols)
>

Not implemented in dnf repoquery yet, please open an RFE against
dnf-plugins-core, with your usecase and I will look into it.


> We also run 'yum makecache' so before all actual repoquery commands (that's
> why we then use cache). This might not be needed with dnf since it
> usually caches yum metadata and doesn't redownload on every query.
>
> Dnf repoquery also behaves differently than yum-utils repoquery. For
> example:
> $ repoquery --requires python
> libc.so.6(GLIBC_2.0)
> libdl.so.2
> libm.so.6
> libpthread.so.0
> libpython2.7.so.1.0
> libutil.so.1
> python-libs(x86-32) = 2.7.5-14.fc20
> rtld(GNU_HASH)
> libc.so.6(GLIBC_2.2.5)(64bit)
> libdl.so.2()(64bit)
> libm.so.6()(64bit)
> libpthread.so.0()(64bit)
> libpython2.7.so.1.0()(64bit)
> libutil.so.1()(64bit)
> python-libs(x86-64) = 2.7.5-14.fc20
> rtld(GNU_HASH)
>
> $ dnf repoquery --requires python
> rtld(GNU_HASH)
> libm.so.6
> libpthread.so.0
> libdl.so.2
> libutil.so.1
> libpython2.7.so.1.0
> libc.so.6(GLIBC_2.0)
> python-libs(x86-32) = 2.7.5-9.fc20
> rtld(GNU_HASH)
> libm.so.6()(64bit)
> libpthread.so.0()(64bit)
> libdl.so.2()(64bit)
> libc.so.6(GLIBC_2.2.5)(64bit)
> libpython2.7.so.1.0()(64bit)
> libutil.so.1()(64bit)
> python-libs(x86-64) = 2.7.5-9.fc20
> rtld(GNU_HASH)
> libm.so.6
> libpthread.so.0
> libdl.so.2
> libutil.so.1
> libpython2.7.so.1.0
> libc.so.6(GLIBC_2.0)
> python-libs(x86-32) = 2.7.5-14.fc20
> rtld(GNU_HASH)
> libm.so.6()(64bit)
> libpthread.so.0()(64bit)
> libdl.so.2()(64bit)
> libc.so.6(GLIBC_2.2.5)(64bit)
> libutil.so.1()(64bit)
> libpython2.7.so.1.0()(64bit)
> python-libs(x86-64) = 2.7.5-14.fc20
>
>
Can reproduce this repoquery and dnf repoquery show the same for me

https://docs.google.com/spreadsheets/d/1WwlO3Is0psbBuJrIY_fVOjWeF5Pi5PI5Ekiy1raUjbs/edit?usp=sharing

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

Re: dnf vs yum

[Tim Lauridsen]

>
> > "Drop" as in "use yum for that, but dnf for the new versions"? That
> > sounds reasonable.
>
> Well reality is f-r is mostly for checking *current* Fedora
> guidelines that in some cases apply only to rawhide. If someone is
> running f-r on a system from 4 years ago to verify current packaging
> guidelines I'd question their knowledge of the guidelines :-)
>
> It's not impossible to do...I just wonder about cost/value proposition
> of keeping the support and spending even more time on it.
>
>
f-r should proberly be working in current Fedora releases, F20, F21 &
Rawhide, some kind of compability wrapper could be need, some f-r check
code is the same and the wrapper can support yum-utils and dnf 5.x (F20)
and 6.x API (F21 & F22) (The cache setup is different)

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

Re: dnf debug-info-install

[Tim Lauridsen]

On Tue, 7 Apr 2015 at 14:10 Michael Catanzaro  wrote:

> Hi,
>
> I want 'dnf debug-info-install' to be available by default on
> Workstation. Right now it lives in the dnf-plugins-extras package,
> which depends on snapper, which we can't install by default.
>
> Can this plugin please move to dnf-plugins-core?
>
> Michael
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


debug-info-install is in dnf-plugins-core 

http://dnf-plugins-core.readthedocs.org/en/latest/debuginfo-install.html

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

Re: dnf replacing yum and dnf-yum

[Tim Lauridsen]

On Tue, 7 Apr 2015 at 17:54 Bruno Wolff III  wrote:

> On Tue, Apr 07, 2015 at 09:07:08 -0600,
>   Kevin Fenzi  wrote:
> >
> >dnf's default behavior is like yum with --skip-broken already.
>
> Not when installing packages.
>
> >
> >If thats not working and you need to find out more, add '--best' to see
> >things without 'skip-broken'.
>
> My understanding is that --best can erase stuff (outside of obsoletes)
> and I don't want to do that in scripts.
>
>
>
afaik, --best don't erase stuff, you need --allowerasing for that

--bestTry the best available package versions in transactions. Specifically
during dnf upgrade, which by default skips over updates that can not be
installed for dependency reasons, the switch forces DNF to only consider
the latest packages and possibly fail giving a reason why the latest
version can not be installed.

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

Re: dnf replacing yum and dnf-yum

[Tim Lauridsen]

On Wed, 8 Apr 2015 at 11:05 drago01  wrote:

> On Tue, Apr 7, 2015 at 6:37 PM, Adam Williamson
>  wrote:
> > On Tue, 2015-04-07 at 18:33 +0200, drago01 wrote:
> >> On Tue, Apr 7, 2015 at 6:00 PM, Reindl Harald  >> > wrote:
> >> >
> >> >
> >> > Am 07.04.2015 um 17:53 schrieb Ralf Corsepius:
> >> > >
> >> > > On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
> >> > > >
> >> > > > dnf's default behavior is like yum with --skip-broken already.
> >> > >
> >> > >
> >> > > WHAT?
> >> > >
> >> > > --skip-broken is a band-aid to work around packaging mistakes
> >> > > and bugs
> >> > > and NOT be the default.
> >> > >
> >> > > IMO, this kind of behavior is not helpful and therefore should
> >> > > be reverted
> >> >
> >> >
> >> > +1
> >> >
> >> > that's unacceptable and leads in burry *real* problems resulting
> >> > in sonner
> >> > or later security updates are broken and nobody take snotice soon
> >> > enough
> >>
> >> The bug is elsewhere though ... i.e. that is even possible to push
> >> updates with broken deps.
> >> Rawhide is a different story but everything that goes through bodhi
> >> (stable releases and branched) should simply refuse pushes with
> >> broken
> >> deps.
> >
> > This is easier said than done. We don't have a perfect dependency
> > checker and it's not at all easy to write one. tflink and John Dulaney
> > have more details if you're interested, but yes, this is not a trivial
> > thing we can just wave a wand and make happen.
>
> We do have dep solvers otherwise no one would notice that a dep is
> broken ever. (like libsolv + hawkey).
> So what bodhi should do is to ask "has this package all dependencies
> satisfied with base + updates + other packages in this push" for every
> package in the push.
> If the answer is "no" for a package cancel the push; remove it;
> restart and only push the once that has satisfied deps.
> Report the failed once to the maintainers so that they can fix it.
>
>
It is not so simple, you have to test all combinations for packages
requiring an updated package and all the packages there requires someting
provided by previous version of the package, with thousend of packages and
multiple packages providing the same stuff, it is an almost impossible task.

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

review swap : yumex-dnf

[Tim Lauridsen]

Hi.

I have submitted yumex-dnf for inclusion into fedora

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

yumex-dnf is a rewritten version of yumex, based on dnf instead of yum

you can check it out here
https://copr.fedoraproject.org/coprs/timlau/yumex-dnf

If you want to review it, then please grab it and let me know want to review

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

Re: dnf replacing yum and dnf-yum

[Tim Lauridsen]

On Mon, 13 Apr 2015 at 10:22 Reindl Harald 
>
> > Now, I admit that the second half is limping a bit. The information is
> > available but it's not as easily accessible as you want it to be. If you
> want
> > to help us, I invite you to write a plugin that will show the
> information you
> > seek in a way you see fit
>
> and i invite you to just take the existing code in YUM and re-implement
> it because DNF was originally a fork of YUM and somebody has taken
> things away to later ask users re-implement them - that's not how the
> world works
>
>
Yes, this is how the world works in open source development, you can
request all the changes you want, but it up to the upstream project to
select what they want to prioritize and implement.
It is much better if you make some contribution yourself, instead of
complaining, if you want something to change.
DNF is not YUM, it implement mostly the same features, but it is a totally
different codebase, it started as fork og yum many years ago, but they have
moved i differnt directions since then.
You has it owns depsolver written in python, dnf uses a 3 party sat solver.
So it is not possible to take code from the yum delsolver and put it into
dnf, it don't make any sense at all.
I coded the --skip-broken feature in yum and it took many years to get it
right and caused me many gray hairs, the depsolver used in dnf has support
for removing packages from the transaction there is causing problems, but
it is not easy to get information from the solver and present then to the
user in a good way, so I understand that the dnf developers prioritize
there limited time on other things, there matter for more people.
The world is changing al the time, and so does thing in Fedora, mayor parts
is ripped out and replaced all the time, with new stuff there is not
working as the old part. So you have to move on and learn how the new beast
is working for good and bad.

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

Re: Fedora 22 and missing applications

[Tim Lauridsen]

On Wed, 27 May 2015 at 17:19 Matthew Miller 
wrote:

> On Wed, May 27, 2015 at 05:07:52PM +0200, Michael Schwendt wrote:
> > > Having keywords makes the search functionality much
> > > better, but isn't actually required for your application to be shown
> > > in the software center.
> > What would they add that's not found within the RPM package %description
> > and %summary already?
>
> Often, synonyms — terms that should apply, but for whatever reason
> isn't in the description.
>
> Richard, sorry for the dumb question, but is there a path to pull in
> keywords from ? Or, going the
> other way, can we get the Fedora apps team to highlight/prioritize
> packages which match applications on your list within Tagger?
>
>
>
The fedora repository contains -pkgtags.sqlite.gz metadata, they was
used by yum, but IFAIK not supported in dnf/hawkey/librepo but the
information exist in the repositories.

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

Re: packages from bitbucket

[Tim Lauridsen]

Seems like bitbucket uses unversioned tar ball, not the best approch

https://bitbucket.org/yarosla/httpress/get/tip.tar.gz

I would make my own tarball from the git checkout and document in the
spec how to make it

https://fedoraproject.org/wiki/Packaging:SourceURL#Using_Revision_Control


Tim



On Wed, Feb 26, 2014 at 10:16 AM, Nikos Mavrogiannopoulos
wrote:

> Hello,
>  I've submitted a while ago a review-request on a package [0] that is
> taken from bitbucket.org. Unfortunately there was no reviewer yet, and I
> suspect that is because unlike github [1] we have no rules on how to
> handle bitbucket. Have other packagers experienced something similar in
> other software? Is there a "good" way to handle repository-distributed
> software? As it is now in [0] I've tried to simulate the github rules on
> bitbucket.
>
> regards,
> Nikos
>
>
> [0]. https://bugzilla.redhat.com/show_bug.cgi?id=1062282
> [1]. https://fedoraproject.org/wiki/Packaging:SourceURL#Github
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: packages from bitbucket

[Tim Lauridsen]

On Wed, Feb 26, 2014 at 11:21 AM, Christopher Meng wrote:

> Bitbucket has downloads support.
>
> Also you can get the tarball from the tags.
>
> What's the problem?
>
>
>
The problem with this project is that there is no release tags, so you cant
get a specific version, just download the current master
this is not very usefull for a fedora package.

Tim
-- 
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: Don't show applications in the software center with XPM icons

[Tim Lauridsen]

Not showing app, because they have bad looking icons, seems like a bad idea
to me.

what about using some cairo magic to merge the .xpm icon with some other
.png frame to make it look better

http://stackoverflow.com/questions/10983739/how-to-composite-multiple-png-into-a-single-png-using-gtk-cairo

cairo should be able to load XPM, as far as I know

Or just show some standard icon base on the app category

Tim


On Thu, Mar 6, 2014 at 4:41 PM, Richard Hughes  wrote:

> XPM is an old standard for icons used by a very small number of
> desktop packages in Fedora. The XPM icons are normally small, mostly 8
> bit, and usually without an alpha channel and look very bad in the
> software center.
>
> I'm going to propose for F21 that we drop support for XPM in the
> metadata extractor and only show apps with GIF, PNG and SVG icons. The
> list of affected GUI applications is here:
>
> TeXmacs
> cycle
> flamerobin
> gnurobots
> linsmith
> mup
> pari-gp
> pgadmin3
> qtel
> qucs
> xsensors
>
> As usual, I'd like to push packagers to get upstream to ship a more
> modern (and high resolution, *with* alpha channel) icon in PNG or SVG
> format, but packagers can also just replace the icon referenced in the
> .desktop file if upstream is unwilling / dead and a good replacement
> is available.
>
> Comments welcome,
>
> Richard
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: Don't show applications in the software center with XPM icons

[Tim Lauridsen]

On Fri, Mar 7, 2014 at 6:50 AM, Satyajit Sahoo wrote:

> Apps with ugly icons and ugly design results in bad user experience
> IMO. They should not be displayed in the software center
>

The quaility of an application has nothing todo, with at fancy icon, not
showning the icon is ok, but don't show the application is not IMO
what will be the next ?  qt apps ? gtk2 apps
I agree with Richard that it would be very bad to set the bar to high, no
user want a software center there only shows 5% of the available apps
no matter, how slick it looks

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

What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Tim Lauridsen]

What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next ?

The Workstation WG, looks like a Gnome only thing, will there be at place
of users of other DE's in Fedora.next ?

Best Regards

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

Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Tim Lauridsen]

On Thu, Mar 20, 2014 at 12:40 PM, Bastien Nocera  wrote:

> - Original Message -
> > Workstation might implement easy installation of alternative desktops in
> > the GNOME Software app at some point.
>
> Urgh. This is just moving the problem from the installer/media selection
> to the
> software installer. Just what would we gain by doing that given that there
> will
> still be other desktops in the repos, and other spins?


The most common user case would to install a spin with DE you want to use.
I dont think it matter much if Gnome software support installation of
evironments.
most other DE spins uses LightDM, so if you want a more lightweight DE, you
don't
install the Gnome Desktop first and then install ex. XCFE.

It would ofcause be nice if you can make a netinstall of LXDE, XFCE, Mate,
Cinnemon, KDE etc using anaconda netinst

Tim
-- 
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: Copr and Playground plugin part of dnf-plugins-core?

[Tim Lauridsen]

If you want people to vote for something, It would be a good idea to say
why and what the pro/cons is for
having copr as a separate package.

Tim


On Thu, Apr 24, 2014 at 11:29 AM, Miroslav Suchý  wrote:

> In https://bugzilla.redhat.com/show_bug.cgi?id=1090516
> Jiri asked for removing Copr (and Playground) DNF plugin out of
> dnf-plugins-core.
>
> Since this is not technical but merely political question I would like to
> ask wider audience:
> Put your voice here please:
>http://www.easypolls.net/poll.html?p=5358d77de4b06a67c5b08e05
> If there will be significant votes for one option, I would do what most of
> you wish.
> Otherwise I will forward it to Fesco for decision.
> --
> Miroslav Suchy, RHCE, RHCDS
> Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Copr and Playground plugin part of dnf-plugins-core?

[Tim Lauridsen]

I have started a new dnf-utils project for commuty plugins/addons there is
not maintain by the core dnf team

https://github.com/timlau/dnf-utils

copr / playground is welcome here is the core dnf developers, think its
dont fit into dnf-plugins.core

It is not submitted as a fedora package yet, but that will happen soon

Tim


On Thu, Apr 24, 2014 at 11:29 AM, Miroslav Suchý  wrote:

> In https://bugzilla.redhat.com/show_bug.cgi?id=1090516
> Jiri asked for removing Copr (and Playground) DNF plugin out of
> dnf-plugins-core.
>
> Since this is not technical but merely political question I would like to
> ask wider audience:
> Put your voice here please:
>http://www.easypolls.net/poll.html?p=5358d77de4b06a67c5b08e05
> If there will be significant votes for one option, I would do what most of
> you wish.
> Otherwise I will forward it to Fesco for decision.
> --
> Miroslav Suchy, RHCE, RHCDS
> Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Replace Yum With DNF

[Tim Lauridsen]

It alredy has, it is called dnf-plugins-core all tools in dnf is
implemented as plugins there is extending the dnf command line

Tim


On Thu, Jun 12, 2014 at 11:11 PM, David  wrote:

> Excuse me.
>
> To whom, or to where, should I write to request that dnf has a tools
> package like yum has. "Yum-utils".
> --
>
>   David
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Replace Yum With DNF

[Tim Lauridsen]

On Fri, Jun 13, 2014 at 2:30 PM, Lukas Zapletal  wrote:

> Is there a "migration for users and developers" document? A page with
> yum commands on the left and corresponding commands with dnf on the
> right. Including developer things like scripts from yum-utils
> (yum-builddep etc).
>
> Thanks.
>

You can check the docs for dnf-plugins-core

http://dnf-plugins-core.readthedocs.org/en/latest/index.html

If you are missing something, then make a bugzilla report against
dnf-plugins-core, with a usecase for the tool your are missing.

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

Re: F22 System Wide Change: Replace Yum With DNF

[Tim Lauridsen]

Come on, every thing in Fedora changes all the time, It is hard for me to
see the fuzz about

having to type 'dnf install foobar', instead of 'yum install foobar'

If you uses a tool like yum at the command line, you should be able to
handle that.

more novice users will use gui tool and don't care how the command line
tool is named.

Having contributed and tracked yum development for many years, I have heard
a lot of BS about how bad and slow yum is and some other tool is much
better.

Now the dnf team has done a lot of work to clean things up and make a more
maintainable codebase and an documented API, that makes it much easier to
build other tools.
some more exotic features will go away, but if there are good use cases,
they can be added as plugins.

Instead of complaining, try to be constructive and test dnf and make a RFE
if something vital is missing.

In my work on make yumex work with the dnf API, the DNF team has be very
helpful to extending API, if there is a solid usecase

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

Re: dnf replacement for yum-cron

[Tim Lauridsen]

Bugzilla is the right place for a an RFE, not fdl :)

Tim


On Mon, Jun 16, 2014 at 2:50 PM, Neal Becker  wrote:

> Been using yum-cron for years with good results.
>
> If yum is being phased out, I'll want a dnf-cron replacement
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf replacement for yum-cron

[Tim Lauridsen]

On Mon, Jun 16, 2014 at 2:50 PM, Neal Becker  wrote:

> Been using yum-cron for years with good results.
>
> If yum is being phased out, I'll want a dnf-cron replacement
>
>
dnf's cache is updated by by a systemd service, not dynamic when executed
like yum.
so if yum-cron is only used to update the cache, no changes is needed.
there min periode between updates is controlled by metadata_timer_sync

http://akozumpl.github.io/dnf/conf_ref.html#main-options

The default is 3 hours.

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

Re: F22 System Wide Change: Replace Yum With DNF

[Tim Lauridsen]

On Mon, Jun 16, 2014 at 11:04 PM, Zing  wrote:

>
> Does yum have current developers/maintainers?  If so, actually obsoleting
> yum seems kind of rude to me.  If that's the case why not just leave yum
> as is?  Those that want to use yum use yum and dnf use dnf.


I don't know the plans, but yum is in rhel7, so it will properly be there
for many years, but it will properly only be bug fixes, no new feature and
no support for soft requirements and other stuff to come.

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

Re: DNF: why does it refresh metadata all the time

[Tim Lauridsen]

On Thu, Jun 19, 2014 at 8:47 PM, Dennis Gilmore  wrote:

> In testing dnf on rawhide I nearly always do "dnf clean metadata && dnf
> update" purely because I found most of the time dnfs metadata was out of
> date. To me dnf fetching the metadata behind the scenes just doesn't work
> right. But I'm not sure that me or rawhide fits into the experience dnf is
> trying to give.
>
> Dennis
>

Dnf-0.5.2 has a --refresh option, there will a check if the repo metadata
is newer than the cached one.

so.

dnf update --refresh will check and update metadata if needed.

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

Re: DNF: why does it refresh metadata all the time

[Tim Lauridsen]

On Fri, Jun 20, 2014 at 4:01 PM, Zdenek Kabelac  wrote:

> Also for years Debian supplies short update 'diffs' - so user doesn't have
> to download multiple MB sized files - just couple short small files - again
> something much nicer then running a daemon to download tens of MB on
> background daily...


dnf/yum don't download metadata if it is not changed, the download a small
repod.xml file with checksum and other stuff, metadata is only updated when
the metadata in cache don't
match the ones in the remoted repositories.

Updates are only push once a day, and have to sync out to the mirrors, so
there is no reason to check for metadata every 10 min og every time dnf is
run.
both yum/dnf has settings to control how often the remote repos is checked
for changes, so it can be configured by the user is they don't like tge
default setting.
delta metadata is on the wishlist for dnf, but it is hard to get it to work
in good way.

Tim
-- 
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: repodata - xz

[Tim Lauridsen]

On Fri, Jun 20, 2014 at 3:44 PM, Dennis Gilmore  wrote:

> because thats how createrepo works. the gzipped files are not ones you
> download. yum and dnf use the sqlite files.
>

yum is using the sqlite files, dnf uses the .xml.gz files
-- 
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: comps categories: are they any use to anyone any more?

[Tim Lauridsen]

On Sun, Jun 22, 2014 at 3:10 AM, Bill Nottingham  wrote:

>
> Check the post-install tools; I believe at least one of apper or yumex
> still
> uses them.


Yes, Yumex is still using categories to organize groups, both in the
current stable release and in nextgen release based on the dnf api.

Removing the will be a very bad idea IMHO, it it will be very messy to
present groups in a ui, if they are not orded in some way

Tim
-- 
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: repodata - xz

[Tim Lauridsen]

On Sat, Jun 21, 2014 at 8:28 PM, Jon  wrote:

> Would it be too much trouble to use the sqlite data in DNF?
> I suppose it would be a step backwards to have our primary (future)
> tool using gzip metadata.
>

the information in the sqlite files is orded i a way the yum is using the
data, dnf parses the .xml files into another format used by libsolv.
the sqlite was invented because the yum .xml to sqlite format was slow and
has to happen on every client out there, so it was moved serverside to
speed up things.

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

Re: dnf even allows to uninstall RPM and systemd without warnings

[Tim Lauridsen]

On Sat, Jun 21, 2014 at 6:29 PM, Rahul Sundaram  wrote:

>
> Tim,
>
> Is there anyone working on a protected packages plugin for Dnf?  In the
> past, it has helped users avoid trashing their systems due to bugs in
> package-cleanup and so on.  So it is not just the command line users of the
> direct tools we need to be concerned about.
>

Don't think so, Don't even remember if anyone has even made an RFE for such
a plugin, if not somebody should proberly make one :)

Tim
-- 
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: comps categories: are they any use to anyone any more?

[Tim Lauridsen]

On Sun, Jun 22, 2014 at 6:33 PM, Adam Williamson 
wrote:

> on the other hand, there's a clear overlap with 'environment groups'. it
> seems like we kinda have one type of group too many. :P
>

environments is something you can install, categories is not, they fit
different a purpose

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

Re: dnf even allows to uninstall RPM and systemd without warnings

[Tim Lauridsen]

On Sun, Jun 22, 2014 at 5:18 PM, Stephen John Smoogen 
wrote:

> Where should the RFE be filed?


Bugzilla againt dnf or dnf-plugins-core

Tim
-- 
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: comps categories: are they any use to anyone any more?

[Tim Lauridsen]

On Mon, Jun 23, 2014 at 6:42 PM, Adam Williamson 
wrote:

> Yeah, you're probably right. In that case we should probably explain the
> difference somewhere - are you aware of anywhere it's currently written
> down? There are no comments in the comps.xml files, no documentation in
> comps.git, and the text on https://fedorahosted.org/comps is extremely
> outdated. I'm happy to update that if someone can give me the necessary
> privileges...
>

I have not seen any docs for comps.xml

Tim
-- 
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: lxqt

[Tim Lauridsen]

This is not a yumex-dnf issue, it works fine in other DE's, Other lxqt
users have had this issue, I don't know what the solution is

Tim

On Wed, 23 Dec 2015 at 10:13 mastaiza  wrote:

> This is not a problem, it is a problem with lxqt, there dont have a
> working polkit gui setup out of the box.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fwd: frafra uploaded yumex-dnf-4.1.6.tar.gz for yumex-dnf

[Tim Lauridsen]

How do i handle a situation where someone, without my knowledge uploads
new sources to one of my projects. It could be a security problem ?

Tim


-- Forwarded message -
From: 
Date: Sun, 27 Dec 2015 at 23:00
Subject: frafra uploaded yumex-dnf-4.1.6.tar.gz for yumex-dnf

0ae84309cbb6781e7acaf2c1a784f59b  yumex-dnf-4.1.6.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/yumex-dnf/yumex-dnf-4.1.6.tar.gz/md5/0ae84309cbb6781e7acaf2c1a784f59b/yumex-dnf-4.1.6.tar.gz

--
You received this message due to your preference settings at
https://apps.fedoraproject.org/notifications/timlau.id.fedoraproject.org/email/24238
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: frafra uploaded yumex-dnf-4.1.6.tar.gz for yumex-dnf

[Tim Lauridsen]

Looks like a false alarm, just a scatch build
https://bugzilla.redhat.com/show_bug.cgi?id=1294377

Tim

On Mon, 28 Dec 2015 at 10:38 Tim Lauridsen  wrote:

> How do i handle a situation where someone, without my knowledge uploads
> new sources to one of my projects. It could be a security problem ?
>
> Tim
>
>
> -- Forwarded message -
> From: 
> Date: Sun, 27 Dec 2015 at 23:00
> Subject: frafra uploaded yumex-dnf-4.1.6.tar.gz for yumex-dnf
>
> 0ae84309cbb6781e7acaf2c1a784f59b  yumex-dnf-4.1.6.tar.gz
>
> http://pkgs.fedoraproject.org/lookaside/pkgs/yumex-dnf/yumex-dnf-4.1.6.tar.gz/md5/0ae84309cbb6781e7acaf2c1a784f59b/yumex-dnf-4.1.6.tar.gz
>
> --
> You received this message due to your preference settings at
>
> https://apps.fedoraproject.org/notifications/timlau.id.fedoraproject.org/email/24238
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: frafra uploaded yumex-dnf-4.1.6.tar.gz for yumex-dnf

[Tim Lauridsen]

On Mon, 28 Dec 2015 at 11:41 Pierre-Yves Chibon  wrote:

> On Mon, Dec 28, 2015 at 09:38:25AM +0000, Tim Lauridsen wrote:
> >Looks like a false alarm, just a scatch buildÂ
> >https://bugzilla.redhat.com/show_bug.cgi?id=1294377
>
> Why uploading sources to dist-git for a scratch build?
>
>
>
Properly a mistake by a user there want to make a scratchbuild of the
latest upstream release
not yet in Fedora.

Tim
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Suspend/resume broken on Lenovo laptops (Fedora 21 beta)

[Tim Lauridsen]

On Tue Nov 11 2014 at 6:25:35 PM valent.turko...@gmail.com <
valent.turko...@gmail.com> wrote:

> Guys and galls,
> if you have Lenovo laptop please install latest Fedora 21 beta and
> provide feedback because there are reported cases that suspend/resume
> doesn't work on Lenovo laptops.
>
> Currently there are reports that Fedora 21 beta fails to resume from
> suspend-to-ram on X1 Carbon, T440s and X240, but there are probably
> also other models.
>
> Fedora has a great reputation on working flawlessly on Lenovo
> hardware, let's try to keep up that reputation!
>
> Best place to report this is on t...@lists.fedoraproject.org list or
> on bugzilla.
>
> Here are two bugs currently open on this topic:
> https://bugzilla.redhat.com/show_bug.cgi?id=1161943
> https://bugzilla.redhat.com/show_bug.cgi?id=1162793
>
> Cheers,
> Valent.
>
>
Work fine on T520

$ uname -r
3.17.2-300.fc21.x86_64

Tim
-- 
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!

[Tim Lauridsen]

On Tue Dec 16 2014 at 9:09:59 PM Chris Murphy 
wrote:

> 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
>
> There  is some problems in your numbes, not everything in cache is
downloaded. In the dnf case only a repomd.xml (one for each repo, <5K) is
download every time metadata cache is expired, and only changed metadata
will be downloaded (repodata/*.xml.gz), the Fedora repo dont change, so it
is only downloaded once, Updates is composed once every day, so it will
only be downloaded one a day.
Rest of the content of cache/dnf is generated from the unpacked metadata,
so the size of the directory don't tell any thing about how much metadata
is downloaded and how often.

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

Orphaning my packages

[Tim Lauridsen]

Hi Guys

Because of work and personal life, I have not been able to find time for
taking care of my Fedora packages, so I have decided to orhan them.

dnfdaemon -- DBus daemon for dnf package actions ( master f26 f25 f24 )
postr -- Flickr uploader ( el6 el5 )
python-iniparse -- Python Module for Accessing and Modifying Configuration
Data in INI files ( master f26 f25 f24 el5 )
yumdaemon -- DBus daemon for yum package actions ( master f26 f25 f24 )
yumex -- Yum Extender graphical package management tool ( epel7 el6 el5 )
yumex-dnf -- Yum Extender graphical package management tool ( master f26
f25 f24 epel7 )

Need someone to take python-iniparse, because dnt, yum has it as
requirement, it is not a big job, because upstream has been gone for many
years.

I will also retire from upstream development of yumex-dnf / dnfdaemon,
because need some love and I dont have the time to give it.

If someone is interested in taking over the project or part of it, then
please contact me and I give access to the repositories on github.

Thanks to all there yumex users over the years and I'm sorry that I can't
continue the project.

Thanks for all the good times under the Fedora umbrella.

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

Re: Orphaning my packages

[Tim Lauridsen]

Thanks a lot, Neal

I have transfered the repository to Conan-Kudo.

Tim

On Wed, 22 Mar 2017 at 11:33 Neal Gompa  wrote:

> Hey Tim,
>
> I'm able to take on dnfdaemon. My GitHub user is Conan-Kudo. You can
> transfer the repository to my GitHub user in the repository settings:
> https://github.com/timlau/dnf-daemon/settings (there will be a
> "transfer repository" button at the bottom of the page).
>
> Thanks.
>
> On Wed, Mar 22, 2017 at 6:28 AM, Tim Lauridsen  wrote:
> > Hi Guys
> >
> > Because of work and personal life, I have not been able to find time for
> > taking care of my Fedora packages, so I have decided to orhan them.
> >
> > dnfdaemon -- DBus daemon for dnf package actions ( master f26 f25 f24 )
> > postr -- Flickr uploader ( el6 el5 )
> > python-iniparse -- Python Module for Accessing and Modifying
> Configuration
> > Data in INI files ( master f26 f25 f24 el5 )
> > yumdaemon -- DBus daemon for yum package actions ( master f26 f25 f24 )
> > yumex -- Yum Extender graphical package management tool ( epel7 el6 el5 )
> > yumex-dnf -- Yum Extender graphical package management tool ( master f26
> f25
> > f24 epel7 )
> >
> > Need someone to take python-iniparse, because dnt, yum has it as
> > requirement, it is not a big job, because upstream has been gone for many
> > years.
> >
> > I will also retire from upstream development of yumex-dnf / dnfdaemon,
> > because need some love and I dont have the time to give it.
> >
> > If someone is interested in taking over the project or part of it, then
> > please contact me and I give access to the repositories on github.
> >
> > Thanks to all there yumex users over the years and I'm sorry that I can't
> > continue the project.
> >
> > Thanks for all the good times under the Fedora umbrella.
> >
> > Tim Lauridsen
> > Yumex developer.
> >
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Could someone help me with writing polkit rule?

[Tim Lauridsen]

Yes, I think so
The policy is to config pkexec to run something as root
The rule is to make the group get permission without having to enter a
root/admin password

Tim


On Fri, Oct 25, 2013 at 2:08 PM, Peter Lemenkov  wrote:

> 2013/10/25 tim.laurid...@gmail.com :
> > It is some time ago it was fighting with polkit, but as far is  I
> remember
> > you have to
> > make a .policy file to get pkexec to work right
> >
> > Like this one I use in yumex.
> >
> https://github.com/timlau/yumex/blob/master/misc/dk.yumex.backend.policy.in
> >
> > It should be installed in /usr/share/polkit-1/actions/
> >
> > When you can make a rule to bypass the polkit password prompt
>
> Do I need both - /usr/share/polkit-1/actions/*.policy and
> /usr/share/polkit-1/rules.d/*.rules ?
>
>
>
> --
> With best regards, Peter Lemenkov.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Is Gnome Software ready for primetime ?

[Tim Lauridsen]

I have tested gnome-software to see the current state, compaired to gpk in
F19, there is a lot stuff there cant be done.

1. You cant install backgrounds / icons
2. Not all application found in the menu, can be found under installed, you
can search for them and find them, but cant remove them (ex. Document
viewer)
3. if you search for 'icons' you get at lot of wrong positives, where there
is no visible relation to icons in the text shown
4. Description is missing from almost every application.

This is just a few of the issues i have made bug reports on, but the main
question is gnome-software ready for the one an only software manager for
the primary
desktop for Fedora ?

I think the current state will make Fedora look limitted for new Fedora
users.

PS. Please dont turn this into a flame war for/against gnome :)

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

Re: Is Gnome Software ready for primetime ?

[Tim Lauridsen]

On Thu, Oct 31, 2013 at 12:50 PM, Matthias Clasen wrote:

> On Thu, 2013-10-31 at 12:13 +0100, Tim Lauridsen wrote:
> > I have tested gnome-software to see the current state, compaired to
> > gpk in F19, there is a lot stuff there cant be done.
> >
> >
> > 1. You cant install backgrounds / icons
>
> It is an application installer, first and foremost. Installing
> backgrounds/icons/themes is not a priority. That being said, 3.11 can
> install fonts and codecs.
>

I know that it is an application installer, but user want to install
content also
and gpk can do that, so it is a regression in my world.

gnome-software cant install extra backgrounds and icons
https://bugzilla.redhat.com/show_bug.cgi?id=1025209



>
> > 2. Not all application found in the menu, can be found under
> > installed, you can search for them and find them, but cant remove them
> > (ex. Document viewer)
>
> What menu ? And what application ?
>
> We have a notion of 'core app' - for things that 'come with the OS'. We
> don't allow to uninstall those.
>
>
It feels inconsitance that i cant remove evince, but it can remove other
gnome apps like boxes and documents

gnome-software dont show all installed applications
https://bugzilla.redhat.com/show_bug.cgi?id=1025250


> > 3. if you search for 'icons' you get at lot of wrong positives, where
> > there is no visible relation to icons in the text shown
>
> Search looks at keywords from desktop files in addition to descriptions
> and names. Would be good to see some concrete examples of the false
> positives you get. I only get gnome-tweak-tool and some icon-related
> font.
>
>
search in package description, but dont show it
https://bugzilla.redhat.com/show_bug.cgi?id=1021889


> > 4. Description is missing from almost every application.
>
> Richard has pushed very hard for getting descriptions upstream - you may
> have seen his repeated posts on this topic. And we have made quite a bit
> of progress. But getting every application equipped with a good
> description, screenshots, and other metadata will take some time, and
> some help from the packagers and maintainers of those applications.
>
>
I know Richard has pushed hard to get appdata for apps, but it do help the
end user, if lot of apps in gnome-software dont have any descriptions.

Look at System -> File Tools -> Caja-actions configuration tool

How should an end user have a clue what this app does ?


> > I think the current state will make Fedora look limitted for new
> > Fedora users.
>
> Compared to Ubuntu, certainly. But compared to gpk-application F19, I
> don't think so.
>

A tool like gnome-software targets novice enduser (IMHO) and more advanced
user will tools like yum, dnf or yumex
So I try to look at it like a novice end user, and they fill see a more
friendly user interface, but they will not be able to find the things they
are look for.
The Fedora art team has done a great job find good extra background images,
but you have to use a command line to install it on the current F10 gnome
desktop, I is not
a good user experiense i my book.
Personal it is not a problem for me, but I would like Fedora to be as good
as possible for new users, so i took some time to install the gnome desktop
and check the state of thing
and report the issues I have found.

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

Re: Is Gnome Software ready for primetime ?

[Tim Lauridsen]

On Fri, Nov 1, 2013 at 4:58 AM, Ankur Sinha  wrote:

> It isn't a *package* management application. It's an *application*
> management application, ie., it only handles packages that are desktop
> applications (and therefore have desktop files associated with them).
>
> I'm guessing power users that want to install other packages will need
> to resort to the command line: yum/dnf/packagekit-cli. I'm not really
> sure about this though. Someone else might know better.
>

All users can use yumex, if they want a package management gui, there can
install every thing they want
but it is not installed by default in the Gnome desktop, so new user need
to find out how to install it or how to
to use yum from the command line.

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

Re: Is Gnome Software ready for primetime ?

[Tim Lauridsen]

On Fri, Nov 1, 2013 at 12:01 PM, Richard Hughes  wrote:

> Packages are not interesting to desktop users, they
> are just an implementation detail of how to get something done. e.g.
> "Play my media file", "Open this document someone sent to me". Anyone
> wanting to do things like "install a mysql server" or "remove evince"
> already knows what they are doing, and is better served using yum/dnf
> on the console.
>

The problem is that these so-called "Desktop Users" dont run Fedora or
other Linux Distros, they will properly run the OS there was preinstalled
on there computer when they bought it.

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

Re: Is Gnome Software ready for primetime ?

[Tim Lauridsen]

On Fri, Nov 1, 2013 at 7:51 AM, Pete Travis  wrote:

> Hmm... It sounds like yumex would be much more discoverable if it included
> an appdata file :)


Done,

https://github.com/timlau/yumex/blob/82198add9daabcfcabe9d8bb7a28ef3190e920d7/misc/yumex-appdata.xml

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

Re: Is Gnome Software ready for primetime ?

[Tim Lauridsen]

On Fri, Nov 1, 2013 at 3:26 PM, Matthias Clasen  wrote:

> Great, thanks for doing that.
>
> Noticed while quickly looking over the file:
>
> - it is not valid xml: & needs to be escaped as &
>
> - 'gui' is not a great term to use. I'd suggest rewording the first
> sentence maybe as 'Yum extender is a graphical package management
> application, ...'
>
> - Instead of 'categories' I would say 'criteria' in 'Browse packages
> by...'. Categories already has (too many) meanings...
>

Cleaned up the appdata xml

https://github.com/timlau/yumex/blob/master/misc/yumex.appdata.xml

but I get errors from  appdata-validate

$ appdata-validate yumex.appdata.xml
yumex.appdata.xml 1 problems detected:
• markup invalid: Error on line 1 char 1: Document must begin with
an element (e.g. )

Can see what the problem is :(

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

Re: Is Gnome Software ready for primetime ?

[Tim Lauridsen]

On Fri, Nov 1, 2013 at 8:30 PM, drago01  wrote:

> On Fri, Nov 1, 2013 at 8:27 PM, Tim Lauridsen 
> wrote:
> >
> > On Fri, Nov 1, 2013 at 3:26 PM, Matthias Clasen 
> wrote:
> >>
> >> Great, thanks for doing that.
> >>
> >> Noticed while quickly looking over the file:
> >>
> >> - it is not valid xml: & needs to be escaped as &
> >>
> >> - 'gui' is not a great term to use. I'd suggest rewording the first
> >> sentence maybe as 'Yum extender is a graphical package management
> >> application, ...'
> >>
> >> - Instead of 'categories' I would say 'criteria' in 'Browse packages
> >> by...'. Categories already has (too many) meanings...
> >
> >
> > Cleaned up the appdata xml
> >
> > https://github.com/timlau/yumex/blob/master/misc/yumex.appdata.xml
> >
> > but I get errors from  appdata-validate
> >
> > $ appdata-validate yumex.appdata.xml
> > yumex.appdata.xml 1 problems detected:
> > • markup invalid: Error on line 1 char 1: Document must begin
> with
> > an element (e.g. )
> >
> > Can see what the problem is :(
>
> That's odd ... have not looked at the code of appdata-validate (where
> is its upstream?) but seems like it complains about the xml header
> (i.e. the " --
>

https://github.com/hughsie/appdata-tools

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

Re: Is Gnome Software ready for primetime ?

[Tim Lauridsen]

On Fri, Nov 1, 2013 at 8:38 PM, Richard Hughes  wrote:

>
> You've got some odd non-utf8 char as the very first byte in the file:
>
>
Looks like the editor has written an Unicode BOM, after removing that it
validates ok

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

Re: Is Gnome Software ready for primetime ?

[Tim Lauridsen]

On Fri, Nov 1, 2013 at 8:57 PM, Ray Strode  wrote:

> Small errors here:
>
>Control want package repositories there is enabled for current
> session
>
> maybe should be:
>
>Control what package repositories are enabled for the current
> session
>

Thanks, fixed upstream

Tim
-- 
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: AppData questions

[Tim Lauridsen]

On Wed, Nov 6, 2013 at 8:43 PM, Richard Hughes  wrote:

> On 6 November 2013 10:41, Michael Schwendt  wrote:
> >   # rpm -qf /usr/share/app-info/xmls/fedora-20.xml.gz
> >   gnome-software-3.10.3-1.fc20.x86_64
> > does.
>
> It's AppStream metadata.


Whould it not be a good idea to have it in a separate package, such kind of
metadata should not be included with the application package IMHO

Tim
-- 
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: Copr

[Tim Lauridsen]

On Thu, Nov 7, 2013 at 1:54 PM, Miroslav Suchý  wrote:

> Dear developers and Fedora contributors,
>
> let me introduce Copr:
>
> http://copr-fe.cloud.fedoraproject.org/
>
> Copr is a build system for third party repositories. It is intended for:
>  * upstream teams - to make nightly and test builds
>  * layered applications - if you build on top of Fedora, but you are not
> part of Fedora
>  * packages not yet ready to be included in official Fedora repositories
>
> How it works? You provide src.rpm, we will provide resulting yum repo for
> RHEL 5,6 and Fedora 18, 19, 20... But see
> WARNING on bottom of this mail.
>
> I prepared quick tutorial for you:
>  https://fedorahosted.org/copr/wiki/ScreenshotsTutorial
> and FAQ:
> https://fedorahosted.org/copr/wiki/UserDocs#FAQ
>
> Everybody with FAS account can build there. If you want to use command
> line client, you should install copr-cli from
> updates-testing.
>
> If you have ideas, questions, comments feel free to use one of our
> communication channels
> https://fedorahosted.org/copr/#Communications
> (mailing list is prefered)
>
> WARNING:
> Please do not rely on this service in production. This is very early
> release (following "release early, release often").
> First of all, this service works in simple set-up, where resulting yum
> repos are *not* backed up. Yet. This is not yet
> officially part of Fedora infrastructure, so when Copr fails, it can take
> several hours to be restored.
> And yes, our WebUI is not perfect. It's work in progress. And since Copr
> can build packages already, I decided to
> publicly announce it, so you can experiment with it.
>
> We are working on Copr on full steam and in upcoming days you can expect:
> * improvements in WebUI
> * ability to build Software Collections there
>
> --
> Miroslav Suchy, RHCE, RHCDS
> Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



Thanks a lot, a great tool, just what i have been looking for

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