Re: Applications with AppData and not visible in the software center
On 01/05/2017 12:56 PM, Richard Hughes wrote: > * nextcloud-client (maybe fixed in distgit) > * owncloud-client I just pushed fixes for nextcloud-client and owncloud-client. They had the same issue where the desktop file and appdata file names didn't match up. -- Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 System Wide Change: GCC7
On Wed, Jan 11, 2017 at 04:17:56AM +, Richard W.M. Jones wrote: > On Tue, Jan 10, 2017 at 10:28:37AM +0100, Jan Kurik wrote: > > * Other developers: > > First few days/weeks just voluntary rebuilds using the new system gcc, > > if things fail, look at http://gcc.gnu.org/gcc-7/porting_to.html and > > fix bugs in packages or, if there is a gcc bug or suspected gcc bug, > > analyze and report. > > It seems like this link is broken. It is where the porting to will appear when it is written. So far just the gcc-7/changes.html link works (but is still very incomplete). porting_to.html is usually written in second half of January. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Fedora-packaging] tag-invalid not allowed in appdata
On 10 January 2017 at 23:29, Gerald B. Cox wrote: > I checked in /usr/share/appdata and did a random check on > org.kde.plasma.colorpicker.appdata.xml among others and they also have the > tag and also now fail. I think appstream-util has always forbidden in appdata files, although that should have been restricted to desktop-type appdata components, not the 'generic' type that plasma uses. I've fixed that in https://github.com/hughsie/appstream-glib/commit/5b6fd6c9c90e5dc4533388183fcb5c114791569e > So it appears that we have an error in either the process which is > autogenerating the appdata file or the validation program has a bug. Note: this is still a valid validation failure: • tag-invalid : stock icon is not valid [color-picker] ...color-picker is not a stock icon name. I think removing the "type=stock" upstream will make the validator pass, and also the appstream-builder happier. Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: BuildRequires on obsoleted packages provided by Python
On 2017-01-10, Adam Williamson wrote: > Please be careful with such 'fixes'. Some specs are also built for EPEL > 6; in EPEL 6, some of these (e.g. python-argparse) are still separate > packages. > Following this rule, do not break EPEL, would effectivelly freeze Fedora forever. If you don't update Fedora, you will not get any new RHEL and hence EPEL updated, thus you will be unable to update Fedora because the rule will apply indefinitely. In other words the rule is nonsence. -- Petr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: BuildRequires on obsoleted packages provided by Python
On Wed, Jan 11, 2017 at 12:46 AM, Adam Williamson
wrote:
> On Fri, 2016-09-02 at 12:44 +0200, Kalev Lember wrote:
>> On 08/31/2016 02:10 PM, Charalampos Stratakis wrote:
>> > Hello all,
>> >
>> > While checking out the SPEC file of python, it seems there were some
>> > packages that, while separate at some point, they got included in python's
>> > stdlib and then obsoleted as standalone packages (thus to cope with the
>> > change, python was obsoleting these packages and providing them as well in
>> > the SPEC). So every package that currently (Build)Requires any of these
>> > packages will essentially drag python with it.
>> >
>> > I will remove these provides soon, since the packages were orphaned long
>> > time ago, but the packages that still require them, will need to be fixed
>> > and (Build)Require python instead.
>>
>> My suggestion would be to request provenpackager access and just fix all
>> those packages yourself in rawhide. If you file bugs, these are probably
>> going to take quite a bit of time to get fixed and you won't be able to
>> drop the compatibility provides for several Fedora releases.
>
> Please be careful with such 'fixes'. Some specs are also built for EPEL
> 6; in EPEL 6, some of these (e.g. python-argparse) are still separate
> packages.
>
> I kind of agree with Neal / Kevin that removing these is pointless and
> unnecessary. Now I will have to conditionalize my affected specs
> somehow in order to keep using them to do builds both for EPEL 6 (where
> I *must* include Requires: python-argparse) and Rawhide (where I now
> *cannot* include Requires: python-argparse)...which is a pain.
Python stack is derived too much from EL to Fedora. Just maintain 2
different specs. Even EL7 is always painful since you have to do
%if 0%{?rhel} && 0%{?rhel} <= 7
BuildRequires: python-setuptools
%else
BuildRequires: python2-setuptools
%endif
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
--
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
mock error on armv7hl koji
Hello, When rebuilding 'nss' package, I got the following failure on the armv7hl machine in koji: Task 17179597 on arm04-builder19.arm.fedoraproject.org Task Type: build (noarch) Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=17179597 file removal failed (code 9) for /var/tmp/koji/tasks/9610/17179610 I initially thought that it was an intermittent failure, but after re-submitting the task twice, I still get: error building package (arch armv7hl), mock was killed by signal 9; see root.log for more information I suspect this might be specific to the nss package. Does anyone have any idea how to fix (or investigate) this? The relevant task is: https://koji.fedoraproject.org/koji/taskinfo?taskID=17230493 Thank you, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide
> Hi, > > A while back Debian has switched to using the modesetting Xorg driver > rather then the intel Xorg driver for Intel GPUs. > Hello, Is it possible to configure xserver to use "intel" driver without recompiling it? Best regards, Samuel > Regards, > > Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mock error on armv7hl koji
On Wednesday, January 11, 2017 11:53:21 AM CET Daiki Ueno wrote: > Hello, > > When rebuilding 'nss' package, I got the following failure on the > armv7hl machine in koji: > > Task 17179597 on arm04-builder19.arm.fedoraproject.org > Task Type: build (noarch) > Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=17179597 > > file removal failed (code 9) for /var/tmp/koji/tasks/9610/17179610 > > I initially thought that it was an intermittent failure, but after > re-submitting the task twice, I still get: > > error building package (arch armv7hl), mock was killed by signal 9; see > root.log for more information > > I suspect this might be specific to the nss package. Does anyone have > any idea how to fix (or investigate) this? > > The relevant task is: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=17230493 > > Thank you, Could the build go OOM? Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mock error on armv7hl koji
On Wed, 2017-01-11 at 12:16 +0100, Pavel Raiskup wrote: > > The relevant task is: > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=17230493 > > > > Thank you, > > Could the build go OOM? mock_output.log doesn't report anything after rpmbuild is started, it seems the task gets interrupted. build.log shows the build completes, and the test suite execution has started, which takes a rather long time, with many individual tests, which includes starting and termination of background processes. That log also stops reporting progress somewhere in the middle of the expected tests. Exhausted resources (like OOM) seems like a plausible explanation for the unexpected interruption of the task. Could someone with administrator access on the arm builder machine please check if that theory is correct? Are there known limitations? Thanks Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide
Hi, On 11-01-17 12:15, Samuel Rakitničan wrote: Hi, A while back Debian has switched to using the modesetting Xorg driver rather then the intel Xorg driver for Intel GPUs. Hello, Is it possible to configure xserver to use "intel" driver without recompiling it? Yes, we're just changing the default, if you drop a 99-local.conf file in /etc/X11/xorg.conf.d with the following contents: Section "OutputClass" Identifier "intel" MatchDriver "i915" Driver "intel" EndSection Then you should get the intel driver used for any GPUs using the i915 kernel driver. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
> > > Idea #2: Do not block on optical media issues for Final release for > > > certain > > > flavors/image types (Server, netinst) > > > ~~~ > > The outcome seems to be we should block on Workstation Live and Everything > netinst. Stephen confirmed his "remote DVD drive" installation was not > affected by the firmware issue causing some optical disks failing to boot. > Also just testing one Live and one netinst should give us a high probability > to detect all such issues, because all the Live and DVD+netinst images are > created the same way. I'll again propose a criterion adjustment on the test > list. > > Thanks everyone for providing valuable feedback. > Sigh, I found a minor setback. We agreed Everything netinst is the best candidate for release blocking as an optical medium, but today I found out Everything netinst is marked as *not* release blocking at all [1]. Which some somewhat funny, because I always considered it as such (and I think more of us did), and this is quite a surprise for me. And if we don't block on it, we can't obviously block on it when it's burned to a spinning disc. One solution here is to make Everything netinst release blocking. There is a good use case for that, it's the most universal install medium we have (you can install anything from it). A different solution is to mark e.g. Server netinst as blocking for optical media, but that will cover only Server (so no Workstation or KDE support in case optical boot is really broken). Thoughts? [1] https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fedora25#Other_Deliverables ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On 07/01/17 22:53 +, Richard W.M. Jones wrote: On Thu, Jan 05, 2017 at 05:38:58PM +0100, Thorsten Leemhuis wrote: Lo! On 05.01.2017 17:03, Stephen Gallagher wrote: > [...] > ## Advantages > > * Simplification of build-tree creation. We wouldn't have to maintain the lists > and hacks that are required to make sure that multilib packages land in the > correct repositories. > [...] Just wondering: Why don't we switch to a multilib/multiarch solution similar to the one that Debian/Ubuntu uses? They put libs in directories like /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu (https://wiki.debian.org/Multiarch/Implementation https://wiki.ubuntu.com/MultiarchSpec ). If we'd switch to a similar solution a new (de facto) standard might evolve and in the end nobody would have to deal with hacks any more, because all major distros would put libs in the same directories. Iirc their model has benefits for cross-compilation, too. IMHO this is a much better idea. Also being closer to Debian means less hacking required to build GCC (or at least, it's the same hacking as Debian needs). How's that? To build GCC on Debian needs an entire new configure option that isn't needed at all on Fedora: --enable-multiarch There's *more* hacking needed to build GCC on Debian. So yes, if we copy them we'll need the same hacking as Debian needs, but that's not less hacking than we have now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F26 System Wide Change: Parallel Installable Debuginfo
= System Wide Change: Parallel Installable Debuginfo = https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo Change owner(s): * Mark Wielaard debuginfo packages can be installed in parallel to make it easier to trace, profile and observe what programs are doing or to debug when they have crashed. That way debugging, tracing or profiling programs can be done independent of whether they are 32bit, 64bit, a slightly newer or older version than currently installed or even from a different architecture. == Detailed Description == Currently only one version of a debuginfo package can be installed for a given package. Even on a multi-lib system you cannot install the 64-bit and 32-bit versions of a debuginfo package in parallel (technically you sometimes can, because of RPM file coloring, the 64bit version of the .debug files win over the 32bit version - causing lots of confusion). But there are various situation where having multiple versions of the debuginfo package installed help with tracing, profiling, debugging and/or crash analysis (see the Benefit to Fedora section below). There are various things provided by a debuginfo file that might conflict preventing parallel installation of different versions: * build-id file /usr/lib/debug/.build-id/xx/...yyy which is a symlink to the main ELF file. * build-id.debug file /usr/lib/debug/.build-id/xx/...yyy.debug which is a symlink to the .debug ELF file. * The .debug files under /usr/lib/debug/ with file path names mirroring the main ELF file paths under / with .debug added. * The source files under /usr/src/debug/-/ They can be made non-conflicting in the following ways: * The main build-id file should not be in the debuginfo file, but in the main package (this was always a problem since the package and debuginfo package installed might not match). If we want to make usr/lib/debug/ a network resource then we will need to move the symlink to another location (maybe /usr/lib/.build-id). Unfortunately this means a change will be necessary for debuginfo consumers to that depend on the old location. We could keep the old symlink and point it to the new location to work around it. But I will audit the consumers to see which depend on it and discuss if we can have a new standard location. * build-ids are globally unique identifiers. They will be different across arches. But might match between minor releases if the exact same ELF image is produced. The linker will get an option to hash in the full nvr to make sure all build-ids are always fully unique. * The .debug file names will be changed to main ELF file name-vr.debug. This name will also be set in the .gnu_debuglink section of the main file by changing the options given to eu-strip in the rpm find-debuginfo.sh script. * The source files will be moved under /usr/src/debug/--./. This needs changes to the rpm debugedit program which rewrites the DWARF source file information. These changes will make all files in any debuginfo file unique so they don't conflict when installed in parallel. There should be no changes necessary to programs (gdb, perf, valgrind, systemtap, systemd-coredump, eu-stack, abrt-hook-ccpp, etc.) that use build-ids or .gnu_debuglink to lookup DWARF debug information and source references for tracing, profiling and debugging. It would be good to tweak dnf debuginfo-install to know about parallel installable debuginfo packages and maybe have an easy option to install the debuginfo for a core file or for the packages running in a container. Alternative solutions currently rejected: * Move main ELF image build-id file under /usr/lib/.build-id/xx/...yyy when moving into main pages. Because existing programs probably depend on the link being under /usr/lib/debug/. * Since when the build-id is identifical also the ELF file is identical we could mark all build-id.debug files as replacable in the rpm. It isn't clear that works for symlinks though (but we could reverse the symlink direction from debug file to build-id file). And currently you can identify the exact package nvr installed given just one build-id. That would be impossible if multiple packages could contain the same build-id/ELF image file. * Do away with the old .gnu_debuglink way of accessing files under /usr/lib/debug and just not install .debug files and only support build-id based debug lookups. Because it isn't clear build-ids are 100% available and all programs work with build-id lookups instead through .gnu_debuglink names. * Move the .debug files under a subdir like the sources. /usr/lib/debug/--./. This cannot easily be expressed in .gnu_debuglink, which officially only allows a basename. == Scope == * Proposal owners: Patches have been developed against rpm debugedit to accept a hash value to seed the build-id calculation, rewrite source paths (currently source paths can only be smaller, this change might create larger paths) and the rpm find-debuginfo.sh script to change the paths, symlinks and
Re: F26 System Wide Change: Parallel Installable Debuginfo
On Wed, Jan 11, 2017 at 9:31 AM, Jan Kurik wrote: > = System Wide Change: Parallel Installable Debuginfo = > https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo > > Change owner(s): > * Mark Wielaard > > debuginfo packages can be installed in parallel to make it easier to > trace, profile and observe what programs are doing or to debug when > they have crashed. That way debugging, tracing or profiling programs > can be done independent of whether they are 32bit, 64bit, a slightly > newer or older version than currently installed or even from a > different architecture. > > > == Detailed Description == > Currently only one version of a debuginfo package can be installed for > a given package. Even on a multi-lib system you cannot install the > 64-bit and 32-bit versions of a debuginfo package in parallel > (technically you sometimes can, because of RPM file coloring, the > 64bit version of the .debug files win over the 32bit version - causing > lots of confusion). But there are various situation where having > multiple versions of the debuginfo package installed help with > tracing, profiling, debugging and/or crash analysis (see the Benefit > to Fedora section below). There are various things provided by a > debuginfo file that might conflict preventing parallel installation of > different versions: > > * build-id file /usr/lib/debug/.build-id/xx/...yyy which is a > symlink to the main ELF file. > * build-id.debug file /usr/lib/debug/.build-id/xx/...yyy.debug > which is a symlink to the .debug ELF file. > * The .debug files under /usr/lib/debug/ with file path names > mirroring the main ELF file paths under / with .debug added. > * The source files under /usr/src/debug/-/ > > They can be made non-conflicting in the following ways: > > * The main build-id file should not be in the debuginfo file, but in > the main package (this was always a problem since the package and > debuginfo package installed might not match). If we want to make > usr/lib/debug/ a network resource then we will need to move the > symlink to another location (maybe /usr/lib/.build-id). Unfortunately > this means a change will be necessary for debuginfo consumers to that > depend on the old location. We could keep the old symlink and point it > to the new location to work around it. But I will audit the consumers > to see which depend on it and discuss if we can have a new standard > location. > * build-ids are globally unique identifiers. They will be different > across arches. But might match between minor releases if the exact > same ELF image is produced. The linker will get an option to hash in > the full nvr to make sure all build-ids are always fully unique. > * The .debug file names will be changed to main ELF file > name-vr.debug. This name will also be set in the .gnu_debuglink > section of the main file by changing the options given to eu-strip in > the rpm find-debuginfo.sh script. > * The source files will be moved under > /usr/src/debug/--./. This needs changes > to the rpm debugedit program which rewrites the DWARF source file > information. > > These changes will make all files in any debuginfo file unique so they > don't conflict when installed in parallel. There should be no changes > necessary to programs (gdb, perf, valgrind, systemtap, > systemd-coredump, eu-stack, abrt-hook-ccpp, etc.) that use build-ids > or .gnu_debuglink to lookup DWARF debug information and source > references for tracing, profiling and debugging. > > It would be good to tweak dnf debuginfo-install to know about parallel > installable debuginfo packages and maybe have an easy option to > install the debuginfo for a core file or for the packages running in a > container. This also necessitates that we split sources out into a debugsource subpackage, and ideally this should be able to be optionally disabled, as downstream package builders may not want sources included for debugging purposes (I've seen complaints from people about being forced to disable debuginfo generation entirely because there's no way to disable including sources). I believe the SUSE guys have already done both of these things, and it would be worth it to talk to the SUSE guys about their approach and pull it in to this. -- 真実はいつも一つ！/ 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: F26 System Wide Change: Parallel Installable Debuginfo
On Wed, 2017-01-11 at 09:38 -0500, Neal Gompa wrote: > > These changes will make all files in any debuginfo file unique so they > > don't conflict when installed in parallel. There should be no changes > > necessary to programs (gdb, perf, valgrind, systemtap, > > systemd-coredump, eu-stack, abrt-hook-ccpp, etc.) that use build-ids > > or .gnu_debuglink to lookup DWARF debug information and source > > references for tracing, profiling and debugging. > > > > It would be good to tweak dnf debuginfo-install to know about parallel > > installable debuginfo packages and maybe have an easy option to > > install the debuginfo for a core file or for the packages running in a > > container. > > This also necessitates that we split sources out into a debugsource > subpackage, and ideally this should be able to be optionally disabled, > as downstream package builders may not want sources included for > debugging purposes (I've seen complaints from people about being > forced to disable debuginfo generation entirely because there's no way > to disable including sources). I believe the SUSE guys have already > done both of these things, and it would be worth it to talk to the > SUSE guys about their approach and pull it in to this. Yes. I am looking at integrating that idea into upstream rpm. But I wanted to split that proposal from this one which "simply" enables parallel installable debuginfo. I originally proposed this change for F25 but it took too much time to get all patches accepted upstream before the deadline. I am trying to avoid growing this specific change proposal and risk missing the deadline again. Shall we work on a separate change proposal (on top of this one) that introduces debugsource and debuginfo subpackages? I think that could still make it for F26. But it would be good to do it as a separate step/proposal IMHO. Thanks, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 System Wide Change: Parallel Installable Debuginfo
On Wed, Jan 11, 2017 at 9:53 AM, Mark Wielaard wrote: > On Wed, 2017-01-11 at 09:38 -0500, Neal Gompa wrote: >> > These changes will make all files in any debuginfo file unique so they >> > don't conflict when installed in parallel. There should be no changes >> > necessary to programs (gdb, perf, valgrind, systemtap, >> > systemd-coredump, eu-stack, abrt-hook-ccpp, etc.) that use build-ids >> > or .gnu_debuglink to lookup DWARF debug information and source >> > references for tracing, profiling and debugging. >> > >> > It would be good to tweak dnf debuginfo-install to know about parallel >> > installable debuginfo packages and maybe have an easy option to >> > install the debuginfo for a core file or for the packages running in a >> > container. >> >> This also necessitates that we split sources out into a debugsource >> subpackage, and ideally this should be able to be optionally disabled, >> as downstream package builders may not want sources included for >> debugging purposes (I've seen complaints from people about being >> forced to disable debuginfo generation entirely because there's no way >> to disable including sources). I believe the SUSE guys have already >> done both of these things, and it would be worth it to talk to the >> SUSE guys about their approach and pull it in to this. > > Yes. I am looking at integrating that idea into upstream rpm. > But I wanted to split that proposal from this one which "simply" enables > parallel installable debuginfo. > > I originally proposed this change for F25 but it took too much time to > get all patches accepted upstream before the deadline. I am trying to > avoid growing this specific change proposal and risk missing the > deadline again. > > Shall we work on a separate change proposal (on top of this one) that > introduces debugsource and debuginfo subpackages? I think that could > still make it for F26. But it would be good to do it as a separate > step/proposal IMHO. > I suppose a separate proposal would be fine, but it seems like it would be intertwined with this one anyway... -- 真実はいつも一つ！/ 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: Proposal: Rethink Fedora multilib support
On Thu, 2017-01-05 at 11:03 -0500, Stephen Gallagher wrote: > # Overview > > For many years, Fedora has supported multilib by carrying parallel-installable > libraries in /usr/lib[64]. This was necessary for a very long time in order to > support 32-bit applications running on a 64-bit deployment. However, in > today's > new container world, there is a whole new option. > > I'd like to propose that we consider moving away from our traditional approach > to multilib in favor of recommending the use of a 32-bit container runtime > when > needed on a 64-bit host. I think this is missing the developer story. I maintain a couple of tools that currently need to handle 32-on-64-bit setups and it is a bit of a pain. So getting rid of multilib certainly would make my life easier. But some of those tools really do work better because they are 64-bit themselves but target 32-bit applications/libraries. It means they can use the full 64-bit address space while reading/writing 32-bit files/datastructures. I believe gcc and binutils/ld are in the same category. Some applications targeting 32-bit architectures are so big that you need 64-bit tools to just build them. Maybe this is a small enough development story that it doesn't really matter. But it would be good to know if developers are comfortable with a pure/native 32bit-only development toolchain. Thanks, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora rawhide compose report: 20170111.n.0 changes
OLD: Fedora-Rawhide-20170110.n.0 NEW: Fedora-Rawhide-20170111.n.0 = SUMMARY = Added images:7 Dropped images: 0 Added packages: 6 Dropped packages:24 Upgraded packages: 119 Downgraded packages: 0 Size of added packages: 94.65 MiB Size of dropped packages:160.61 MiB Size of upgraded packages: 5.70 GiB Size of downgraded packages: 0.00 B Size change of upgraded packages: -119.96 MiB Size change of downgraded packages: 0.00 B = ADDED IMAGES = Image: SoaS raw-xz armhfp Path: Spins/armhfp/images/Fedora-SoaS-armhfp-Rawhide-20170111.n.0-sda.raw.xz Image: KDE live i386 Path: Spins/i386/iso/Fedora-KDE-Live-i386-Rawhide-20170111.n.0.iso Image: Design_suite live i386 Path: Labs/i386/iso/Fedora-Design_suite-Live-i386-Rawhide-20170111.n.0.iso Image: Design_suite live x86_64 Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20170111.n.0.iso Image: KDE live x86_64 Path: Spins/x86_64/iso/Fedora-KDE-Live-x86_64-Rawhide-20170111.n.0.iso Image: Cloud boot i386 Path: Cloud/i386/iso/Fedora-Cloud-netinst-i386-Rawhide-20170111.n.0.iso Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20170111.n.0-sda.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: arc-theme-20161119-1.fc26 Summary: Flat theme with transparent elements RPMs:arc-theme arc-theme-plank Size:573064 bytes Package: fegistry-0.0.0-1.fc26 Summary: The Fedora registry endpoint RPMs:python3-fegistry Size:173690 bytes Package: gplugin-0.27.0-2.fc26 Summary: GObject based library that implements a reusable plugin system RPMs:gplugin gplugin-devel gplugin-gtk gplugin-gtk-devel gplugin-gtk-libs gplugin-libs gplugin-loader-lua gplugin-loader-python Size:876004 bytes Package: hdfview-2.13.0-1.fc26 Summary: Java HDF5 Object viewer RPMs:hdfview hdfview-doc hdfview-javadoc jhdfobj Size:4199124 bytes Package: log4cxx-0.10.0-22.fc26 Summary: A port to C++ of the Log4j project RPMs:log4cxx log4cxx-devel log4cxx-doc Size:4210754 bytes Package: python2-2.7.12-9.fc26 Summary: An interpreted, interactive, object-oriented programming language RPMs:python2 python2-debug python2-devel python2-libs python2-test python2-tkinter python2-tools Size:89214596 bytes = DROPPED PACKAGES = Package: ascend-0.9.10-14.20151003svn3100.fc26 Summary: ASCEND modelling environment RPMs:ascend ascend-data ascend-devel ascend-tcltk Size:14867384 bytes Package: firehol-2.0.1-3.fc24 Summary: Simple and powerful firewall and traffic shaping languages RPMs:firehol Size:927694 bytes Package: freesteam-2.1-17.20150903svn761.fc26 Summary: Calculate the properties of water and steam RPMs:freesteam freesteam-ascend freesteam-devel freesteam-gtk python2-freesteam Size:724220 bytes Package: gnome-web-photo-0.10.5-9.fc24 Summary: HTML pages thumbnailer RPMs:gnome-web-photo Size:433808 bytes Package: gphpedit-0.9.98-0.11.RC1.fc24 Summary: A PHP source editor for GNOME 2 RPMs:gphpedit Size:447 bytes Package: jboss-classpool-scoped-1.0.0-11.fc24 Summary: A custom class pool for several JBoss products RPMs:jboss-classpool-scoped jboss-classpool-scoped-javadoc Size:51544 bytes Package: jboss-reflect-2.0.2-10.fc24 Summary: JBoss Reflection RPMs:jboss-reflect jboss-reflect-javadoc Size:485180 bytes Package: jbossxb-2.0.3-10.fc24 Summary: JBoss XML Binding RPMs:jbossxb jbossxb-javadoc Size:947620 bytes Package: jdf-stacks-client-1.0.2-5.fc24 Summary: JBoss Stacks Parser RPMs:jdf-stacks-client jdf-stacks-client-javadoc Size:100244 bytes Package: librfm-5.3.16-11.fc24 Summary: Rodent file manager basic library functionality RPMs:librfm librfm-devel Size:15290644 bytes Package: mingw-openjpeg-1.5.2-5.fc24 Summary: MinGW Windows OpenJPEG library RPMs:mingw32-openjpeg mingw32-openjpeg-static mingw64-openjpeg mingw64-openjpeg-static Size:370560 bytes Package: perl-Data-Alias-1.20-2.fc24 Summary: Comprehensive set of aliasing operations RPMs:perl-Data-Alias Size:303464 bytes Package: python-2.7.12-8.fc26 Summary: An interpreted, interactive, object-oriented programming language RPMs:python python-debug python-devel python-libs python-test python-tools tkinter Size:89192156 bytes Package: python-django-dajax-0.9.2-6.fc25 Summary: Library to create asynchronous presentation logic with Django and dajaxice RPMs:python-django-dajax Size:15106 bytes Package: python-django-dajaxice-0.6-4.fc25 Summary: Agnostic and easy to use AJAX library for Django RPMs:python-django-dajaxice Size:29582 bytes Package: python-sphinx-theme-better-0.1.5-9.fc26 Summary: A Better Sphinx Theme RPMs:python-sphinx-theme-better python3-sphinx-theme-better Size:35144 bytes Package: rodent-5.3.16-9.fc24 Summary: Advanced user file manager for Linux/BSD systems RPMs:rodent rodent-diff rodent-fgr rodent-iconmgr Size:23248404 bytes
Re: Applications with AppData and not visible in the software center
This amount of breakage (65 packages, *despite* validation), is a sign
of a bigger problem. The "validation" is weak, and the filtering
applied in gnome-software, i.e. the user interface, is strong and
unexpected and silent. IMHO things should be reversed: validation
should be proactive and warn about things which are wrong now or will
be considered wrong in the future, and no filtering should be done
during display.
If there are some issues with an appdata entry, both users and the
package maintainers would be much better served if it is displayed,
even imperfect and ugly, than not at all. It would be much easier to
diagnose things, and would probably encourage more people to fix those
visual issues. Currently it's just too easy to never see the problem.
Filtering in this final "user" stage just seems to be in the wrong
place, and goes against the principle of gentle degradation.
Zbyszek
On Fri, Jan 06, 2017 at 07:26:52PM +, Richard Hughes wrote:
> On 6 January 2017 at 02:16, Ben Rosser wrote:
> > It turns out that I am very silly, and, when writing the appstream
> > file for tilp2, never changed "comical.desktop" in the template here
> > [1] to "tilp.desktop".
> > ...whoops! I can, uh, fix that.
>
> :)
>
> > However, interestingly, it seems that "appstream-util validate-relax
> > --nonet" doesn't seem to care. It happily validates tilp2's appstream
> > information [2], which is why I never noticed this at the time. I
> > would think that "referenced desktop file doesn't exist on system"
> > should at least be a warning or something when validating?
>
> Well, to do a full validation we need to search for the icon, look for
> the desktop file and validate the appdata file. This is what you can
> do with:
>
> $ appstream-util check-root
>
> Although it's best used in the package build system, e.g. for RPM you can do:
>
> DESTDIR=%{buildroot} appstream-util check-root
>
> It's lightly tested, so it if works or breaks please let me know.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Applications with AppData and not visible in the software center
On 11 January 2017 at 15:52, Zbigniew Jędrzejewski-Szmek wrote: > This amount of breakage (65 packages, *despite* validation) Most of those packages don't validate the AppData file... > and no filtering should be done during display. It isn't -- that status page is for apps that don't even get into the metadata. > If there are some issues with an appdata entry, both users and the > package maintainers would be much better served if it is displayed, > even imperfect and ugly, than not at all. You mean just display a stock broken image for the application icon? No description for markup problems? > It would be much easier to > diagnose things, and would probably encourage more people to fix those > visual issues. Currently it's just too easy to never see the problem. > Filtering in this final "user" stage just seems to be in the wrong > place, and goes against the principle of gentle degradation. I think the opposite might be the solution; fail the rpmbuild if the appdata is invalid. Then the packager knows at build time rather than having to check some random status page. Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Applications with AppData and not visible in the software center
On Wed, Jan 11, 2017 at 04:03:36PM +, Richard Hughes wrote: > On 11 January 2017 at 15:52, Zbigniew Jędrzejewski-Szmek > wrote: > > This amount of breakage (65 packages, *despite* validation) > > Most of those packages don't validate the AppData file... > > > and no filtering should be done during display. > > It isn't -- that status page is for apps that don't even get into the > metadata. > > > If there are some issues with an appdata entry, both users and the > > package maintainers would be much better served if it is displayed, > > even imperfect and ugly, than not at all. > > You mean just display a stock broken image for the application icon? > No description for markup problems? Yeah, I do think that this would be better. > > It would be much easier to > > diagnose things, and would probably encourage more people to fix those > > visual issues. Currently it's just too easy to never see the problem. > > Filtering in this final "user" stage just seems to be in the wrong > > place, and goes against the principle of gentle degradation. > > I think the opposite might be the solution; fail the rpmbuild if the > appdata is invalid. Then the packager knows at build time rather than > having to check some random status page. Exactly. Make this check the most stringent, to catch the errors in a verbose way. But if it passes, even with warnings, don't filter the application out in later steps. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
Dne 11.1.2017 v 15:25 Jonathan Wakely napsal(a): > On 07/01/17 22:53 +, Richard W.M. Jones wrote: >> On Thu, Jan 05, 2017 at 05:38:58PM +0100, Thorsten Leemhuis wrote: >>> Lo! On 05.01.2017 17:03, Stephen Gallagher wrote: >>> > [...] >>> > ## Advantages >>> > >>> > * Simplification of build-tree creation. We wouldn't have to >>> maintain the lists >>> > and hacks that are required to make sure that multilib packages >>> land in the >>> > correct repositories. >>> > [...] >>> >>> Just wondering: Why don't we switch to a multilib/multiarch solution >>> similar to the one that Debian/Ubuntu uses? They put libs in >>> directories >>> like /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu >>> (https://wiki.debian.org/Multiarch/Implementation >>> https://wiki.ubuntu.com/MultiarchSpec ). If we'd switch to a similar >>> solution a new (de facto) standard might evolve and in the end nobody >>> would have to deal with hacks any more, because all major distros would >>> put libs in the same directories. Iirc their model has benefits for >>> cross-compilation, too. >> >> IMHO this is a much better idea. Also being closer to Debian means >> less hacking required to build GCC (or at least, it's the same hacking >> as Debian needs). > > How's that? To build GCC on Debian needs an entire new configure > option that isn't needed at all on Fedora: --enable-multiarch > > There's *more* hacking needed to build GCC on Debian. So yes, if we > copy them we'll need the same hacking as Debian needs, but that's not > less hacking than we have now. > And yet the configuration is wrong and does not support the current needs of packages on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=979403 Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide
On Tue, 2017-01-10 at 11:59 -0600, Michael Cronenworth wrote: > Are performance regressions covered under this clause? > > Iris 5100 (Haswell) > gtkperf - Intel = ~29 seconds > gtkperf - Modeset = ~35 seconds > > Fairly significant change. On a benchmark that doesn't reflect real usage very well, but sure. Can you drill down on this a bit? Which subtests get most worse? - ajax ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: BuildRequires on obsoleted packages provided by Python
On Wed, 2017-01-11 at 10:37 +0100, Igor Gnatenko wrote:
> On Wed, Jan 11, 2017 at 12:46 AM, Adam Williamson
> wrote:
> > On Fri, 2016-09-02 at 12:44 +0200, Kalev Lember wrote:
> > > On 08/31/2016 02:10 PM, Charalampos Stratakis wrote:
> > > > Hello all,
> > > >
> > > > While checking out the SPEC file of python, it seems there were some
> > > > packages that, while separate at some point, they got included in
> > > > python's stdlib and then obsoleted as standalone packages (thus to cope
> > > > with the change, python was obsoleting these packages and providing
> > > > them as well in the SPEC). So every package that currently
> > > > (Build)Requires any of these packages will essentially drag python with
> > > > it.
> > > >
> > > > I will remove these provides soon, since the packages were orphaned
> > > > long time ago, but the packages that still require them, will need to
> > > > be fixed and (Build)Require python instead.
> > >
> > > My suggestion would be to request provenpackager access and just fix all
> > > those packages yourself in rawhide. If you file bugs, these are probably
> > > going to take quite a bit of time to get fixed and you won't be able to
> > > drop the compatibility provides for several Fedora releases.
> >
> > Please be careful with such 'fixes'. Some specs are also built for EPEL
> > 6; in EPEL 6, some of these (e.g. python-argparse) are still separate
> > packages.
> >
> > I kind of agree with Neal / Kevin that removing these is pointless and
> > unnecessary. Now I will have to conditionalize my affected specs
> > somehow in order to keep using them to do builds both for EPEL 6 (where
> > I *must* include Requires: python-argparse) and Rawhide (where I now
> > *cannot* include Requires: python-argparse)...which is a pain.
>
> Python stack is derived too much from EL to Fedora. Just maintain 2
> different specs. Even EL7 is always painful since you have to do
> %if 0%{?rhel} && 0%{?rhel} <= 7
> BuildRequires: python-setuptools
> %else
> BuildRequires: python2-setuptools
> %endif
Um. No you don't. Just make it unconditionally `python-setuptools`. All
branches provide that.
No, I'm not maintaining two separate specs. That's far more work than
conditionalizing one spec. There's one package where I have to do it,
and I hate it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Renaming livereload to python-liverload
Hello I have asked about unretire the python-livereload package in the master branch of pkgdb and, after that I will be retiring the livereload package a part of a request to remane this library to follow the current naming guidelines for python packages, there is more info in this releng ticket: https://pagure.io/releng/issue/6584 Bug link: https://bugzilla.redhat.com/show_bug.cgi?id=1308681 Also the livereload python library is now available as BSD License and not MIT License. Best regards William Moreno Reyes ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mock error on armv7hl koji
On Wed, 11 Jan 2017 12:39:12 +0100 Kai Engert wrote: > On Wed, 2017-01-11 at 12:16 +0100, Pavel Raiskup wrote: > > > The relevant task is: > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=17230493 > > > > > > Thank you, > > > > Could the build go OOM? > > mock_output.log doesn't report anything after rpmbuild is started, it > seems the task gets interrupted. > > build.log shows the build completes, and the test suite execution has > started, which takes a rather long time, with many individual tests, > which includes starting and termination of background processes. That > log also stops reporting progress somewhere in the middle of the > expected tests. > > Exhausted resources (like OOM) seems like a plausible explanation for > the unexpected interruption of the task. > > Could someone with administrator access on the arm builder machine > please check if that theory is correct? Are there known limitations? Yes, it seems that is the case: [Tue Jan 10 10:13:13 2017] Out of memory: Kill process 22877 (kojid) score 4 or sacrifice child [Tue Jan 10 10:13:13 2017] Killed process 23210 (mock) total-vm:28592kB, anon-rss:8060kB, file-rss:10016kB, shmem-rss:0k B kevin pgp2pTpXEHTa0.pgp Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 25 Respin 20170111 compose check report
Missing expected images: Xfce live x86_64 Workstation live x86_64 Failed openQA tests: 7/11 (x86_64) ID: 54662 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/54662 ID: 54663 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/54663 ID: 54664 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/54664 ID: 54668 Test: x86_64 KDE-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/54668 ID: 54669 Test: x86_64 KDE-live-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/54669 ID: 54670 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/54670 ID: 54673 Test: x86_64 KDE-live-iso base_update_cli URL: https://openqa.fedoraproject.org/tests/54673 Skipped openQA tests: 4 of 11 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 25 Respin 20170111 compose check report
Missing expected images: Xfce live x86_64 Workstation live x86_64 Failed openQA tests: 7/11 (x86_64) ID: 54662 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/54662 ID: 54663 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/54663 ID: 54664 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/54664 ID: 54668 Test: x86_64 KDE-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/54668 ID: 54669 Test: x86_64 KDE-live-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/54669 ID: 54670 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/54670 ID: 54673 Test: x86_64 KDE-live-iso base_update_cli URL: https://openqa.fedoraproject.org/tests/54673 Skipped openQA tests: 4 of 11 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora 25 Respin 20170111 compose check report
On Wed, 2017-01-11 at 20:08 +, Fedora compose checker wrote: > Missing expected images: > > Xfce live x86_64 > Workstation live x86_64 > > Failed openQA tests: 7/11 (x86_64) > > ID: 54662 Test: x86_64 KDE-live-iso install_default@uefi > URL: https://openqa.fedoraproject.org/tests/54662 > ID: 54663 Test: x86_64 KDE-live-iso desktop_notifications_live > URL: https://openqa.fedoraproject.org/tests/54663 > ID: 54664 Test: x86_64 KDE-live-iso install_default_upload > URL: https://openqa.fedoraproject.org/tests/54664 > ID: 54668 Test: x86_64 KDE-live-iso desktop_browser > URL: https://openqa.fedoraproject.org/tests/54668 > ID: 54669 Test: x86_64 KDE-live-iso desktop_terminal > URL: https://openqa.fedoraproject.org/tests/54669 > ID: 54670 Test: x86_64 KDE-live-iso desktop_notifications_postinstall > URL: https://openqa.fedoraproject.org/tests/54670 > ID: 54673 Test: x86_64 KDE-live-iso base_update_cli > URL: https://openqa.fedoraproject.org/tests/54673 > > Skipped openQA tests: 4 of 11 Agh, sorry about this, folks. This is openQA testing the 'live respins' that are built by Ben Williams (southern_gentlem): https://dl.fedoraproject.org/pub/alt/live-respins/ it's the first time the 'fully automated' process for testing these has kicked in, and it still has teething problems; it looks like fedfind found the images before Ben had actually finished uploading them, so some were 'missing', and the one it did find to test wasn't completely uploaded and the download attempt failed, hence the test failures. I'll re-trigger the tests once the image upload is completed, and send out a corrected report. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Orphaning two rubygems, co-maintainters wanted for others
I've just orphaned: rpms/rubygem-pathspec -- Use to match path patterns such as gitignore ( master f25 f24 epel7 ) rpms/rubygem-semantic -- Utility class for parsing, storing, and comparing versions ( master f25 f24 epel7 ) Also, I'm a maintainer on far too many packages and am stretched thin. I'd love to have help with any of mine: https://admin.fedoraproject.org/pkgdb/packager/orion/ They are mostly scientific and python focused. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Orphaning two rubygems, co-maintainters wanted for others
On Wed, Jan 11, 2017 at 01:33:13PM -0700, Orion Poplawski wrote: > I've just orphaned: > > rpms/rubygem-pathspec -- Use to match path patterns such as gitignore ( > master f25 f24 epel7 ) > rpms/rubygem-semantic -- Utility class for parsing, storing, and comparing > versions ( master f25 f24 epel7 ) I am taking both rubygems -- Athos Ribeiro http://www.ime.usp.br/~athoscr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 25 Respin 20170111 compose check report
No missing expected images. Passed openQA tests: 22/22 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20170107.n.0 compose check report
On Sat, 2017-01-07 at 15:36 +, Fedora compose checker wrote: > Missing expected images: > > Cloud_base qcow2 x86_64 > Atomic qcow2 x86_64 > Cloud_base raw-xz x86_64 > Atomic raw-xz x86_64 > > Failed openQA tests: 16/103 (x86_64), 1/2 (arm) So in case anyone's wondering what's been going on for the last few days... In the next compose (201707.n.1) a new systemd build landed - systemd- 232-6.fc26 - which had two effects. First, it broke a lot of the tests; 70+ tests have failed in every run since then. I dug into that today, and it turns out to be because of a service that got removed between 231 and 232. In systemd %post we run `systemctl preset (awholebunchofservices)` to load the preset configurations for a whole bunch of services. Unfortunately, one of the services in the list is the one that was removed between 231 and 232, so now the command just fails. That meant none of the presets actually got applied, and among other things, that resulted in there being no tty on vt1 by default, which breaks every test that expects a tty on vt1 (which is lots of them). Zbigniew has just sent through a new systemd build with a fix for that (232-7), so a lot more tests should pass tomorrow. Second, it caused a couple of services to start failing on the Workstation install, which had a rather unexpected knock-on consequence. Remember I added that feature to check-compose lately where a few of the tests upload various bits of info about the installed system and check-compose analyzes them? Well, one of those bits of info is a list of running services. Because of how I was producing that list, when any of the services have failed, the text file winds up with some unicode characters in it, and it turns out that check-compose wasn't reading the downloaded files in a unicode-safe way, and so it's just been crashing on every compose since then. Which is why there haven't been any compose reports! I've now fixed check-compose to handle unicode in the downloaded files, but I also tweaked the way we generate the list of services in the first place (because the extra column that appears in the list when any of the services have failed was messing with the parsing in other ways too). So I'm hoping tomorrow we'll both get a compose check report, and it'll have fewer failed tests than we've had for the last few days. This has been your Rawhide update! /me out -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support (Take Two!)
Neal Gompa wrote: > It's not true that we need to change anything (as Kevin Kofler > suggested earlier in the thread) for this to be useful. There is no > policy change required for this to be an improvement over the > situation today. This is wrong, because, as you wrote: > Binaries are not duplicated with the "Debian multiarch". So to support the one use case that multiarch supports and multilib does not: > enabling larger scale cross-compiling, and supporting loading binaries > intended for different architectures or kernels you must absolutely split the binaries (which would conflict with the native binaries) and the libraries (which you need to do your cross-compilation or to run your non-native binaries) into separate subpackages wherever packages currently ship both, or modify RPM's ELF coloring heuristics to be a lot more complex and also to take the system's actual native architecture into account. FHS multilib is designed only for binaries that can be natively executed, where there is a clear, fixed preference on one architecture over another. (If you can run both i686 and x86_64 binaries, you automatically want the x86_64 one in case of conflicts.) Debian multiarch attempts to support use cases that fail that assumption hardcoded deep into RPM and into Fedora packaging practices. Those use cases are much better served by full GNU sysroots (/usr/target, not /usr/lib/target). Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Schedule for Thursday's FPC Meeting (2017-01-12 17:00 UTC) (old: 11)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2017-01-05 17:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2017-01-12 09:00 Thu US/Pacific PST 2017-01-12 12:00 Thu US/Eastern EST 2017-01-12 17:00 Thu UTC <- 2017-01-12 17:00 Thu Europe/London <- 2017-01-12 18:00 Thu Europe/Paris CET 2017 -01-12 18:00 Thu Europe/Berlin CET 2017-01-12 22:30 Thu Asia/Calcutta IST --new day-- 2017-01-13 01:00 Fri Asia/Singapore SGT 2017-01-13 01:00 Fri Asia/Hong_Kong HKT 2017-01-13 02:00 Fri Asia/Tokyo JST 2017-01-13 03:00 Fri Australia/BrisbaneAEST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/13 = Followups = #topic #398 Tilde in version .fpc 398 https://fedorahosted.org/fpc/ticket/398 #topic #558 Application/Library distinction and package splitting .fpc 558 https://fedorahosted.org/fpc/ticket/558 #topic #610 Packaging guidelines: Check upstream tarball signatures .fpc 610 https://fedorahosted.org/fpc/ticket/610 #topic #650 Python Guidelines about Alternate Interpreters .fpc 650 https://fedorahosted.org/fpc/ticket/650 #topic #654 glibc file triggers .fpc 654 https://fedorahosted.org/fpc/ticket/654 #topic #655 meson buildsystem guidelines .fpc 655 https://fedorahosted.org/fpc/ticket/655 #topic #656 pre/post-release versioning, major simplification .fpc 656 https://fedorahosted.org/fpc/ticket/656 #topic #657 Keeping packager tooling in sync with our guidelines .fpc 657 https://fedorahosted.org/fpc/ticket/657 #topic #661 Formalize/standardize %check-optional packaging .fpc 661 https://fedorahosted.org/fpc/ticket/661 #topic #662 Migration of FPC trac to pagure .fpc 662 https://fedorahosted.org/fpc/ticket/662 #topic #665 SSLCertificateHandling policy update .fpc 665 https://fedorahosted.org/fpc/ticket/665 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/13 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Transdiff
On 10 January 2017 at 14:39, Tom Hughes wrote: > On 10/01/17 08:39, Jan Kurik wrote: > > Often even after 100% translation in Zanata, few packages do not get >> build with latest translations in Fedora. This result in poor >> localization experience. >> > > I don't really understand the logic here... > > I would expect anything in Fedora to be built with whatever translations > are provided in the upstream release - are you saying that packagers are > routinely removing such translations for some reason? or just forgetting to > package the extra translations? > Yes, forgetting to pull translation is one of the problem. Also other problem is packages updating strings after translation is completed. This also result in loss of translation. > > Or are you proposing that packagers should be pulling translations from > some additional source above and beyond what upstream provides? > No, not this. > > Zanata appears to be a web based translation platform that developers can > use so I would expect the workflow for a package that uses Zanata to be > that upstream pulls the latest translations from it at regular intervals > and incorporates them in the releases they make which then get packaged in > Fedora. > > I'm not saying we should package a tool for analysing translation status > as I'm sure it will be useful to upstream developers but it's not clear how > you envisage it fitting into the Fedora development process. > In Fedora development process, i think such a script/project will be helpful like. After Beta release, one can simply run this script on fully installed translation machine and verify whether all latest translation from upstream are available in Fedora or is there any specific string breakage (i.e. New English words in package ). At the present still exploring ideas, once we have basic script ready we can further think how can we use it for more benefits to Fedora translation quality. - Pravin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Transdiff
On 10 January 2017 at 16:31, Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Tuesday, 10 January 2017 at 09:39, Jan Kurik wrote: > > = Proposed Self Contained Change: Transdiff = > > https://fedoraproject.org/wiki/Changes/Transdiff > > > > Change owner(s): > > *Sundeep Anand > > > > Often even after 100% translation in Zanata, few packages do not get > > build with latest translations in Fedora. This result in poor > > localization experience. Transdiff is a python program to run on > > products installations for tracking translations with project upstream > > and generate diff reports. > > Nice. On the wiki page, you (Sundeep) also mention automation. > Where do you see this in our packaging pipeline? > > As a taskotron check? A regular report mailed to the devel list? > Good point. While discussing on string breakage monitoring we discussed this idea as well. Yeah, taskotron is good fit for uses of transdiff, so rather than post installation of translation, we will have this check in Bodhi itself. - Pravin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
