Re: how to handle source code from github

[Globe Trotter]

Hi,



  >
> I'm afraid this will not work because (according to the GitHub
> repo) this project has 0 release tags. Also the archive has been
> created only 23 days ago. Isn't it too early to package a project
> which has not yet ever been released upstream?
I am also upstream. I have been using the software and my own rpm for at least 
five years and there has not been a crash. I have also got the software itself 
checked with valgrind so I am quite confident about the stability of the 
software. Of course, one could always have enhancements which Is why I put the 
software up. 

However, if there is going to be an issue with getting it accepted in Fedora 
because it has not been around for a while and because it is likely hardly used 
by people (because it is at best for WM environments), then I don't know if I 
should even proceed.

Ideally, of course, it appears that the best course would be to version the 
software in github itself. I have to figure out how to do this, and would 
appreciate any pointers in this regard. I only know very basic commands in git. 
Thank you again!Best wishes.
   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Test-Announce] openQA test results for critpath updates now shown in Bodhi

[Adam Williamson]

Hi folks! I thought this was worth sending out an announcement about so
as many packagers and testers as possible are aware of it.

With the rollout of Bodhi 2.6.0 to production today, openQA test
results for critpath updates now appear in the Bodhi webUI! Click the
'Automated Tests' tab on any critical path update (from the last two
months or so) and you should see, as well as the 'dist.*' tests you're
probably familiar with that are run by Taskotron, results for several
'update.*' tests. These are the openQA test results.

Clicking any result will take you to the openQA webUI page for that
job. If you're investigating a failure, look for thumbnails with a
*red* border. Usually, the first one of these will be the attempted
image match or console command that did not give the expected result.

If you can't understand a failure, please do come ask on test@ or in
#fedora-qa . Myself and garretraziel (Jan Sedlak) should be able to
explain.

This isn't a perfect test system, yet; there have been and will
continue to be 'false' failures, where something goes wrong in the test
process itself or the test just hits some transient bug that isn't
actually caused by the update. Because of this, we wrote an openQA
plugin that automatically retries all failed update tests one time, but
sometimes we get unlucky and a false failure happens again on the
retry.

This is quite common for Fedora 26 updates; there seem to be several of
these transient bugs in F26 at present, meaning sometimes the test VM
just doesn't boot successfully, sometimes GNOME crashes, and so on. If
you see a 'red' screenshot which is just a partially-completed
bootsplash screen, or the GDM login screen, this may be what happened.

Notably, *any* failure before the _advisory_update step cannot possibly
be a bug in the update, as nothing from the update is actually
installed until near the end of that step.

It's not currently possible for anyone but openQA admins to re-run
individual tests. You can cause *all* the openQA tests for your update
to be re-run by editing the update in any way (*any* edit event
triggers a re-run of the tests, not just changes to the update's
package manifest), but please be a bit sparing with this, as openQA
doesn't have unlimited capacity. For now you can, again, ask Jan or I
to re-run a single test if you'd like this. We will endeavour to set up
some kind of re-run request system in future.

Just like the taskotron results, at present these results are entirely
advisory. They do not have any effect on whether or when you can push
your update stable. But we set up this system to help out packagers, so
I hope you'll find it useful to keep an eye on the results and take a
look at any failures to see if they may indicate a bug in the update.
Once again, please do ask for any help you need in interpreting or
understanding the results. And please do send any suggestions, comments
or complaints our way!

And just to be clear, these tests are currently run only on *critical
path* updates. If your update does not include a critical path package,
the tests will not be run. I'm thinking of implementing some sort of
'whitelist' system for listing or otherwise marking non-critpath
packages for which we want to run some or all of the tests; for
instance, it would make a lot of sense to run the FreeIPA tests for any
package in the FreeIPA stack. But that's not implemented yet. We don't
just run the tests on *all* updates because we simply don't have the
capacity to do so at present.

I have written a blog post about this, with some more information,
including a brief explanation of what the current set of update tests
covers, here:

https://www.happyassassin.net/2017/04/24/automated-critical-path-update-functional-testing-for-fedora/
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: how to handle source code from github

[Nico Kadel-Garcia]

On Mon, Apr 24, 2017 at 7:39 PM, Rafal Luzynski
 wrote:
> 23.04.2017 19:23 Christopher  wrote:
>>
>>  You can set the name of the file via the GitHub API when you download it.
>>
>>  For jQuery (packaged as js-jquery), I use:
>>  https://github.com/jquery/jquery/archive/%{version}/jquery-%{version}.tar.gz
>>
>>  This will work for any GitHub project which tags released versions:
>>
>> https://github.com///archive//.tar.gz
>> [...]
>
> I'm afraid this will not work because (according to the GitHub
> repo) this project has 0 release tags. Also the archive has been
> created only 23 days ago. Isn't it too early to package a project
> which has not yet ever been released upstream?

Been there, done that. It assumes that other people are following your
own model of how source control or product releases work.


> Also:
>
>> [...]
>>  On Sun, Apr 23, 2017 at 11:38 AM Globe Trotter > mailto:itsme_...@yahoo.com > wrote:
>>
>> >I am trying to package the following from github for fedora. (Actually, 
>> > I
>> > have been using my own RPM for years so it is hopefully not a major task).
>> >
>
> If you say you have been using your own RPM file for this project
> for years then maybe the project is not as young as this GitHub
> repo suggests? Maybe it's just been imported incorrectly, without
> the full history and tags, maybe it has another proper source
> repo which should be used instead?

I could believe there's another repo for source code. I personally run
into this all the time with python and various small perl and java
tools.

I'll note that it is not "incorrect" to import a project without full
history and logs. True, it discards history. But when the history has
been in a source control system that does not allow discarding
*anything*, much like Subversion tries, it's quite common to create a
new git repo with an export and import operation and discard confusing
or even copyright violating or internal security burdened content
wholesale. And if the link to the old repository is deliberately
broke, it massively reduces the risks of accidentally re-importing
bulky or inappropriate old material to the new repository.

Again, been there, done that.


> Regards,
>
> Rafal
> ___
> 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: how to handle source code from github

[Christopher]

On Mon, Apr 24, 2017 at 7:47 PM Rafal Luzynski <
digitalfr...@lingonborough.com> wrote:

> 23.04.2017 19:23 Christopher  wrote:
> >
> >  You can set the name of the file via the GitHub API when you download
> it.
> >
> >  For jQuery (packaged as js-jquery), I use:
> >
> https://github.com/jquery/jquery/archive/%{version}/jquery-%{version}.tar.gz
> >
> >  This will work for any GitHub project which tags released versions:
> >
> > https://github.com/
> //archive//.tar.gz
> > [...]
>
> I'm afraid this will not work because (according to the GitHub
> repo) this project has 0 release tags. Also the archive has been
> created only 23 days ago. Isn't it too early to package a project
> which has not yet ever been released upstream?
>
>
This also works for branch names, and commits, not just tags, as my later
examples showed.

Whether or not it's too early to package... that probably depends on the
nature of the software. Some projects work well with continuous delivery,
but others (for example, those with well-defined, evolving APIs), it's
probably better to wait on a release. You may be able to encourage the
upstream project to create releases, if they know there's a downstream
demand for them.

There's probably a wiki somewhere which explains how to do versioning in
Fedora for continuous delivery projects, but I can't find it right now.
It's probably something like:
Version: %{oneUpCounter}-%{shortcommit}
where oneUpCounter is incremented every time you update the package to a
newer commit.
An alternative might be date-based:
Version: 20170424-%{shortcommit}
I'm not sure which would be preferred in Fedora. Hopefully somebody can
link to some Wiki guidance.
(Of course, in either case, you'll probably end up having to bump the epoch
if the project ever does start doing versioned releases.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: how to handle source code from github

[Rafal Luzynski]

23.04.2017 19:23 Christopher  wrote:
> 
>  You can set the name of the file via the GitHub API when you download it.
> 
>  For jQuery (packaged as js-jquery), I use:
>  https://github.com/jquery/jquery/archive/%{version}/jquery-%{version}.tar.gz
> 
>  This will work for any GitHub project which tags released versions:
> 
> https://github.com///archive//.tar.gz
> [...]

I'm afraid this will not work because (according to the GitHub
repo) this project has 0 release tags. Also the archive has been
created only 23 days ago. Isn't it too early to package a project
which has not yet ever been released upstream?

Also:

> [...]
>  On Sun, Apr 23, 2017 at 11:38 AM Globe Trotter  mailto:itsme_...@yahoo.com > wrote:
>
> >I am trying to package the following from github for fedora. (Actually, I
> > have been using my own RPM for years so it is hopefully not a major task).
> > 

If you say you have been using your own RPM file for this project
for years then maybe the project is not as young as this GitHub
repo suggests? Maybe it's just been imported incorrectly, without
the full history and tags, maybe it has another proper source
repo which should be used instead?

Regards,

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

Re: Split translations to noarch packages?

[Rafal Luzynski]

24.04.2017 12:47 Milan Crha  wrote:
> [...]
> I know I can do this for packages I maintain, but I though it would
> make sense to think of it globally. Maybe?
>
> Bye,
> Milan

If I may drop my 2¢… this sounds good to me for large packages,
for example LibreOffice, glibc and KDE which do it already and
Evolution as a good candidate to implement this change.

But for small packages which have not so many translatable
messages producing dozens of small RPMs ~1 kilobyte each or even
less would doesn't sound like a good solution. So I suggest to
introduce this feature but not globally and obligatorily for
all packages.

Additionally, I think that for some purposes installing all
languages for some specific applications would be useful so
I also suggest providing something like glibc-all-langpacks.

Regards,

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

[Fedocal] Reminder meeting : Modularity Office Hours

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Office Hours on 2017-04-25 from 10:00:00 to 11:00:00 US/Eastern
   At https://meet.jit.si/fedora-modularity

The meeting will be about:
This is where you ask the Fedora Modularity Team questions (and we try to 
answer them)!

Join us [per video](https://meet.jit.si/fedora-modularity) or on 
[IRC](irc://chat.freenode.net/#fedora-modularity): #fedora-modularity on 
[FreeNode](https://freenode.net)


Source: https://apps.fedoraproject.org/calendar/meeting/5246/

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

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

On 24 April 2017 at 20:37, Stephen Gallagher  wrote:

> These days, I think we divide langpacks (at least at the distro/glibc
> level) by language rather than country.
>
> I have `langpacks-en` on my system, for example.
>

Yep .. "these days" glibc is one of the best anti examples about how to
write specs files.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 26-20170424.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp

Failed openQA tests: 20/111 (x86_64), 4/18 (i386), 1/2 (arm)

New failures (same test did not fail in 26-20170423.n.0):

ID: 85993   Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/85993
ID: 86018   Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/86018
ID: 86048   Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/86048
ID: 86052   Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/86052
ID: 86053   Test: x86_64 universal install_delete_partial
URL: https://openqa.fedoraproject.org/tests/86053
ID: 86060   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/86060

Old failures (same test failed in 26-20170423.n.0):

ID: 85965   Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/85965
ID: 85979   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/85979
ID: 85980   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/85980
ID: 85991   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/85991
ID: 85994   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/85994
ID: 85995   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/85995
ID: 85997   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/85997
ID: 86002   Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/86002
ID: 86009   Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/86009
ID: 86028   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/86028
ID: 86031   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/86031
ID: 86033   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/86033
ID: 86061   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/86061
ID: 86065   Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/86065
ID: 86066   Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/86066
ID: 86067   Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/86067
ID: 86081   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/86081
ID: 86082   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/86082
ID: 86187   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/86187

Soft failed openQA tests: 10/18 (i386)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test did not soft fail in 26-20170423.n.0):

ID: 86076   Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/86076
ID: 86078   Test: i386 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/86078

Old soft failures (same test soft failed in 26-20170423.n.0):

ID: 85974   Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/85974
ID: 85975   Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/85975
ID: 86073   Test: i386 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/86073
ID: 86074   Test: i386 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/86074
ID: 86075   Test: i386 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/86075
ID: 86077   Test: i386 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/86077
ID: 86079   Test: i386 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/86079
ID: 86080   Test: i386 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/86080

Passed openQA tests: 83/111 (x86_64), 4/18 (i386)

New passes (same test did not pass in 26-20170423.n.0):

ID: 85998   Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/85998
ID: 86007   Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/86007
ID: 86015   Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/86015
ID: 86045   Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedo

Fedora Rawhide-20170424.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base qcow2 x86_64
Atomic qcow2 x86_64
Cloud_base raw-xz x86_64
Xfce raw-xz armhfp
Atomic raw-xz x86_64
Minimal raw-xz armhfp

Failed openQA tests: 67/109 (x86_64), 17/18 (i386)

New failures (same test did not fail in Rawhide-20170423.n.0):

ID: 85780   Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/85780

Old failures (same test failed in Rawhide-20170423.n.0):

ID: 85745   Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/85745
ID: 85746   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/85746
ID: 85747   Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/85747
ID: 85748   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/85748
ID: 85754   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/85754
ID: 85755   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/85755
ID: 85764   Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/85764
ID: 85766   Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/85766
ID: 85767   Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/85767
ID: 85768   Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/85768
ID: 85769   Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/85769
ID: 85770   Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/85770
ID: 85771   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/85771
ID: 85772   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/85772
ID: 85783   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/85783
ID: 85784   Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/85784
ID: 85785   Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/85785
ID: 85786   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/85786
ID: 85787   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/85787
ID: 85788   Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/85788
ID: 85789   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/85789
ID: 85794   Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/85794
ID: 85801   Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/85801
ID: 85803   Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/85803
ID: 85804   Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/85804
ID: 85805   Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/85805
ID: 85806   Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/85806
ID: 85807   Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/85807
ID: 85808   Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/85808
ID: 85809   Test: x86_64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/85809
ID: 85810   Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/85810
ID: 85811   Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/85811
ID: 85812   Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/85812
ID: 85813   Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/85813
ID: 85814   Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/85814
ID: 85816   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/85816
ID: 85819   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/85819
ID: 85821   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/85821
ID: 85822   Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/85822
ID: 85823   Test: x86_64 universal install_anaconda_text

Re: Split translations to noarch packages?

[Stephen Gallagher]

On 04/24/2017 12:15 PM, Milan Crha wrote:
> On Mon, 2017-04-24 at 08:18 -0400, Stephen Gallagher wrote:
>> If we went this route, I'd love to see us attempt to solve this
>> generically for all packages if at all possible.
>   Hi,
> right, having this done transparently for the packagers would be ideal.
> You only need to decide from which build/architecture you'll compose
> that noarch package. Evolution package used to remove unused translated
> strings in the past, during the build.
>
> My main issue with libreoffice langpacks divided by country was that
> even I chose my mother language during installation of Fedora, that
> particular langpack wasn't installed, thus libreoffice was not
> localized to my mother language, though other parts, like GNOME Shell,
> were. This is few Fedora's back, on a machine which I keep updating,
> instead of installing from scratch, thus it's possible the behaviour
> changed meanwhile.
>
> I mean, maybe it doesn't make always sense to divide langpacks by
> country.


These days, I think we divide langpacks (at least at the distro/glibc
level) by language rather than country.

I have `langpacks-en` on my system, for example.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Milan Crha]

On Mon, 2017-04-24 at 08:18 -0400, Stephen Gallagher wrote:
> If we went this route, I'd love to see us attempt to solve this
> generically for all packages if at all possible.

Hi,
right, having this done transparently for the packagers would be ideal.
You only need to decide from which build/architecture you'll compose
that noarch package. Evolution package used to remove unused translated
strings in the past, during the build.

My main issue with libreoffice langpacks divided by country was that
even I chose my mother language during installation of Fedora, that
particular langpack wasn't installed, thus libreoffice was not
localized to my mother language, though other parts, like GNOME Shell,
were. This is few Fedora's back, on a machine which I keep updating,
instead of installing from scratch, thus it's possible the behaviour
changed meanwhile.

I mean, maybe it doesn't make always sense to divide langpacks by
country.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Summary/Minutes from Friday's FESCo Meeting (2017-04-21)

[Justin Forbes]

==
#fesco: FESCO (2017-04-21)
==


Meeting started by jforbes at 16:00:16 UTC. The full logs are available
at 
https://meetbot.fedoraproject.org/fedora-meeting/2017-04-21/fesco.2017-04-21-17.00.log.html
.



Meeting summary
---
* init process  (jforbes, 16:00:45)
  * LINK: https://pagure.io/fesco/issue/1653   (jforbes, 16:06:14)
  * LINK: https://pagure.io/fesco/issue/1653   (dgilmore, 16:13:21)
  * AGREED: The updated statement in comments will be added to the FESCo
wiki page (+6,0,-0)  (jforbes, 16:17:27)

* #1695 F27 System Wide Change: Switch libidn-using applications to
  IDNA2008  (jforbes, 16:17:46)
  * LINK: https://pagure.io/fesco/issue/1695   (jforbes, 16:18:12)
  * AGREED: F27 System Wide Change: Switch libidn-using applications to
IDNA2008 is approved (+6,0,-0)  (jforbes, 16:20:55)

* #1697 F27 System Wide Change: Switch libcurl back to OpenSSL
  (jforbes, 16:21:12)
  * LINK: https://pagure.io/fesco/issue/1697   (jforbes, 16:21:41)
  * AGREED: F27 System Wide Change: Switch libcurl back to OpenSSL is
approved (+6,0,-0)  (jforbes, 16:23:41)

* #1698 systemd preset decision: thermald.service  (jforbes, 16:23:59)
  * LINK: https://pagure.io/fesco/issue/1698   (jforbes, 16:24:26)
  * AGREED: Append the Default Services criteria with "Installation of
the package providing the unit auto-started by this preset may not
change the behavior of any other service running on the system.
Exceptions may be granted by FESCo on a case-by-case basis."
(+6,0,-0)  (jforbes, 16:30:25)
  * ACTION: sgallagh to draft the guideline change and add this to the
Bugzilla template  (sgallagh, 16:30:34)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1440479 requests
it be added as default on in presets  (nirik, 16:32:42)
  * AGREED: thermald.service should not be enabled by default (+6,0,-0)
(jforbes, 16:45:30)

* #1699 meeting: xml-security-c new maintainer request  (jforbes,
  16:45:51)
  * LINK: https://pagure.io/fesco/issue/1699   (jforbes, 16:46:14)
  * AGREED: xml-security-c new maintainer request is deferred until
things are online and we have more insight.  (jforbes, 16:54:21)

* #1700 Lulzbot 3d printer firmware  (jforbes, 16:54:35)
  * AGREED: packaging lulzbot prebuilt firmware along with source is
acceptable through the F26 timeframe. If it cannot be built in
Fedora by F27 branch time, an extension must be requested (+5,0,-0)
(jforbes, 17:03:14)

* Next week's chair  (jforbes, 17:03:26)
  * ACTION: maxamillion to chair next weeks meeting  (jforbes, 17:05:46)

* Open Floor  (jforbes, 17:05:56)

Meeting ended at 17:08:49 UTC.




Action Items

* sgallagh to draft the guideline change and add this to the Bugzilla
  template
* maxamillion to chair next weeks meeting




Action Items, by person
---
* maxamillion
  * maxamillion to chair next weeks meeting
* sgallagh
  * sgallagh to draft the guideline change and add this to the Bugzilla
template
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* jforbes (86)
* dgilmore (65)
* nirik (34)
* maxamillion (25)
* sgallagh (22)
* jwb (13)
* spot (4)
* kalev (0)
* Rathann (0)
* jsmith (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reviews Weekly

[nobody]

Start Date: 2017-04-17 10:08:02.237190
End Date: 2017-04-24 10:08:02.237190

Athos Ribeiro : 4

https://bugzilla.redhat.com/show_bug.cgi?id=1431741 
golang-github-cznic-b
https://bugzilla.redhat.com/show_bug.cgi?id=1434421 
golang-github-AudriusButkevicius-pfilter
https://bugzilla.redhat.com/show_bug.cgi?id=1437389 
golang-github-ccding-go-stun
https://bugzilla.redhat.com/show_bug.cgi?id=1431763 
golang-github-oschwald-geoip2-golang


Neal Gompa : 3

https://bugzilla.redhat.com/show_bug.cgi?id=1442547 gsignond
https://bugzilla.redhat.com/show_bug.cgi?id=1442853 libgsignon-glib
https://bugzilla.redhat.com/show_bug.cgi?id=1443932 
switchboard-plug-about


Fabio Valentini : 2

https://bugzilla.redhat.com/show_bug.cgi?id=1375986 
golang-github-klauspost-cpuid
https://bugzilla.redhat.com/show_bug.cgi?id=1411962 
golang-github-milochristiansen-lua


Jonathan Dieter : 2

https://bugzilla.redhat.com/show_bug.cgi?id=1441842 
python-yamlordereddictloader
https://bugzilla.redhat.com/show_bug.cgi?id=1441841 python-camel


Vít Ondruch : 2

https://bugzilla.redhat.com/show_bug.cgi?id=1441816 diorite
https://bugzilla.redhat.com/show_bug.cgi?id=1441831 nuvolasdk


Björn "besser82" Esser : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1444093 python-pymoc


Christian Dersch : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1442743 python-bz2file


Fedora Update System : 1

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


Haïkel Guémar : 1

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


James Hogarth : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1439178 quazip-qt5


Jitka Plesnikova : 1

https://bugzilla.redhat.com/show_bug.cgi?id=163 
perl-Test-Directory


Miroslav Lichvar : 1

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


Randy Barlow : 1

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



Completed Review Requests: 21
This report was generated by bz-review-report.py.
The original source is available at: 
https://git.fedorahosted.org/cgit/triage.git/tree/scripts/bzReviewReport.py
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora packager environment in a docker container

[Stephen Gallagher]

On 04/24/2017 08:47 AM, Daniel Walsh wrote:
> On 04/24/2017 06:29 AM, Michal Minar wrote:
>> Did anyone successfully set up his fedora packaging environment in a
>> docker container?
>> I didn't get past `kinit mimi...@fedoraproject.org
>> ` in a container. It gives me:
>>
>> Invalid UID in persistent keyring name while getting default ccache
>>
>> I'd be very glad for any suggestion or advice. Until then, I'll stick
>> with a VM.
>>
>> Regards,
>> -- 
>>
>> MICHAL MINÁŘ
>>
>> SOFTWARE ENGINEER
>>
>> Red Hat Czech, s.r.o. 
>>
>> mimi...@redhat.com    
>>
>> 
>>
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
> I think this is conflicting with the kernel keyring for the same UID. 
> Attempt to do this without using the kernel keyring.  IE Setup
> kerberos to use a file based cache.
>


FYI, there is work ongoing to resolve issues like this without using the
kernel keyring but instead using a Kerberos KCM server inside of SSSD
which should be container-aware:
https://docs.pagure.org/SSSD.sssd/design_pages/kcm.html




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

fedpkg container-build labels error

[Marek Skalický]

Hi,
I am building container using fedpkg and I am getting this error:

FAILED: BuildError: Required LABELs haven't been found in Dockerfile:
version (or Version).
  0 free  0 open  0 done  1 failed

But in Dockerfile I have

ENV NAME=mongodb \
VERSION=0 \
RELEASE=1 \
ARCH=x86_64

LABEL com.redhat.component = "$NAME" \
  name="$FGC/$NAME" \
  version="$VERSION" \
  release="$RELEASE.$DISTTAG" \
  architecture="$ARCH" \
  usage="docker run -d -e MONGODB_ADMIN_PASSWORD=my_pass
$FGC/$NAME" \
  help="help.1"

Where is a problem?

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

Re: Fedora packager environment in a docker container

[Daniel Walsh]

On 04/24/2017 08:08 AM, Patrick Uiterwijk wrote:

Hi,

On Mon, Apr 24, 2017 at 12:29 PM, Michal Minar  wrote:


Did anyone successfully set up his fedora packaging environment in a
docker container?


I didn't get past `kinit mimi...@fedoraproject.org` in a container. It

gives me:

Invalid UID in persistent keyring name while getting default ccache


This is caused because Docker installs a default seccomp policy that denies
access to the Kernel keyring because this is not namespaced.
You can work around this by "export KRB5CCNAME=/tmp/ticket".

Alternatively, you can allow the container access to your host keyring.
For this, you can start with my policy:
https://github.com/puiterwijk/development-environments/blob/master/docker/koji/policy.json


SELinux would also block this, and if you have multiple containers 
running with the same UID it will not work, even if we took down SELinux 
and SECCOMP blocks.  The bottom line is there is only one kernel keyring 
per UID.  I have asked to make keyrings namespace aware, but right now 
the kernel guys believe usernamespace is the solution to this problem.

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

Re: Fedora packager environment in a docker container

[Daniel Walsh]

On 04/24/2017 06:29 AM, Michal Minar wrote:
Did anyone successfully set up his fedora packaging environment in a 
docker container?
I didn't get past `kinit mimi...@fedoraproject.org 
` in a container. It gives me:


Invalid UID in persistent keyring name while getting default ccache

I'd be very glad for any suggestion or advice. Until then, I'll stick 
with a VM.


Regards,
--

MICHAL MINÁŘ

SOFTWARE ENGINEER

Red Hat Czech, s.r.o. 

mimi...@redhat.com 





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


I think this is conflicting with the kernel keyring for the same UID.  
Attempt to do this without using the kernel keyring.  IE Setup kerberos 
to use a file based cache.


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

Re: Split translations to noarch packages?

[Stephen Gallagher]

On 04/24/2017 06:47 AM, Milan Crha wrote:
>   Hello,
> I've got an idea and I'd like to know an opinion of a wider audience.
>
> Would it make sense to split translations from binary packages to
> a noarch subpackage?
>
> For example libreoffice does that already, it even splits the languages
> by country, which may or may not be applicable to other (larger)
> packages as well.
>
> What this could help with is a save of disk space on the build servers
> and mirrors. There might not be any significant difference for users,
> due to the main package would require the "langs" subpackage [*]. One
> may even avoid multilib issues on translation files (happened in the
> past for Evolution due to it removing unused translation strings during
> the build, to save package size).
>
> To give an example, I tried this with Evolution package and the result
> is that the langs subpackage is ~6MB large, while the main package is
> ~4MB large. Count that the languages are stored for each architecture,
> and koji builds for 6 of them at the moment, then the change of split
> means saving 30MB on disk for each single build of Evolution. When
> searching koji for Evolution packages then there had been done more
> than 70 builds since the first build for Fedora 24 (which is built for
> 3 arches only), which means more than 1GB on disk (roughly, counting 3
> arches only). Multiply this by number of mirrors and so on.
>
> I know I can do this for packages I maintain, but I though it would
> make sense to think of it globally. Maybe?
>
>   Bye,
>   Milan
>
> [*] The only difference for users would be to not download languages
> again when installing two+ architectures in parallel, thus less data to
> download, thus only a benefit for them.


If we went this route, I'd love to see us attempt to solve this
generically for all packages if at all possible. Something like having
the rpmbuild step extract the *.po files automatically into their own
subpackages and set the appropriate `Supplements: langpack-`[1]
values for them. That way the next time we do a mass-rebuild, every
package in the distribution would take advantage of it automatically.


[1] https://fedoraproject.org/wiki/Packaging:Langpacks



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora packager environment in a docker container

[Patrick Uiterwijk]

Hi,

On Mon, Apr 24, 2017 at 12:29 PM, Michal Minar  wrote:

> Did anyone successfully set up his fedora packaging environment in a
> docker container?
>
I didn't get past `kinit mimi...@fedoraproject.org` in a container. It
> gives me:
>
> Invalid UID in persistent keyring name while getting default ccache
>

This is caused because Docker installs a default seccomp policy that denies
access to the Kernel keyring because this is not namespaced.
You can work around this by "export KRB5CCNAME=/tmp/ticket".

Alternatively, you can allow the container access to your host keyring.
For this, you can start with my policy:
https://github.com/puiterwijk/development-environments/blob/master/docker/koji/policy.json
.
This is based on Docker 1.13.
For the 1.12 and earlier version, grab:
https://github.com/puiterwijk/development-environments/blob/ed497fbbd56432eca1b27ce41903ed2c33aaa051/docker/koji/policy.json
.

Then on the docker run command, add: --security-opt
seccomp=$HOME/Documents/Development/Environments/docker/koji/policy.json

Do note that if you want to do kinit, you will want to add the add_key call
as well (I just do kinit on my workstation, and use the seccomp policy to
allow my koji container access to it).


>
> I'd be very glad for any suggestion or advice. Until then, I'll stick with
> a VM.
>
> Regards,
> --
>
> MICHAL MINÁŘ
>
> SOFTWARE ENGINEER
>
> Red Hat Czech, s.r.o. 
>
> mimi...@redhat.com
>
>
Regards,
Patrick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Split translations to noarch packages?

[Milan Crha]

Hello,
I've got an idea and I'd like to know an opinion of a wider audience.

Would it make sense to split translations from binary packages to
a noarch subpackage?

For example libreoffice does that already, it even splits the languages
by country, which may or may not be applicable to other (larger)
packages as well.

What this could help with is a save of disk space on the build servers
and mirrors. There might not be any significant difference for users,
due to the main package would require the "langs" subpackage [*]. One
may even avoid multilib issues on translation files (happened in the
past for Evolution due to it removing unused translation strings during
the build, to save package size).

To give an example, I tried this with Evolution package and the result
is that the langs subpackage is ~6MB large, while the main package is
~4MB large. Count that the languages are stored for each architecture,
and koji builds for 6 of them at the moment, then the change of split
means saving 30MB on disk for each single build of Evolution. When
searching koji for Evolution packages then there had been done more
than 70 builds since the first build for Fedora 24 (which is built for
3 arches only), which means more than 1GB on disk (roughly, counting 3
arches only). Multiply this by number of mirrors and so on.

I know I can do this for packages I maintain, but I though it would
make sense to think of it globally. Maybe?

Bye,
Milan

[*] The only difference for users would be to not download languages
again when installing two+ architectures in parallel, thus less data to
download, thus only a benefit for them.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora packager environment in a docker container

[Michal Minar]

Did anyone successfully set up his fedora packaging environment in a docker
container?
I didn't get past `kinit mimi...@fedoraproject.org` in a container. It
gives me:

Invalid UID in persistent keyring name while getting default ccache

I'd be very glad for any suggestion or advice. Until then, I'll stick with
a VM.

Regards,
-- 

MICHAL MINÁŘ

SOFTWARE ENGINEER

Red Hat Czech, s.r.o. 

mimi...@redhat.com

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