Agenda for today's Env-and-Stacks WG meeting (2013-12-10)
WG meeting will be today at 13:00 UTC in #fedora-meeting on Freenode. == Next Steps == - PRD - based on discussion on env-and-stacks mailing list (some discussion on pad: http://piratepad.net/PwUiH4MEPR) == Open Floor == -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1039708] perl-DateTime-1.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1039708 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppi...@redhat.com Assignee|st...@silug.org |ppi...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=zYUWrqzHD2&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: FTBFS if "-Werror=format-security" flag is used
On Mon, Dec 09, 2013 at 03:01:55PM -0800, Les Howell wrote: > unless something has changed recently fputs and puts just like gets and > fgets have been deprecated and are discouraged due to potential security > issues. That is wrong. Only gets is deprecated (removed in C11, obsolescent in POSIX 2008, etc.), because it fills in a buffer without telling the library the size of the buffer, so it is pretty much always a security issue to use gets. All other functions you've listed aren't deprecated at all. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unresponsive package maintainer policy change proposal
On Sat, 2013-12-07 at 13:20 +0100, Jochen Schmitt wrote: > On Sat, Dec 07, 2013 at 11:44:47AM +0100, Mattia Verga wrote: > > Hello all, > > > I think this kind of bug should not be filled against the single > > package, but something like against infrastructure. Also it should > > block all bugs assigned to that user. > > > > This can be useful if a user maintains several packages. This way > > all bugs receive a notification that the "unresponsive package > > maintainer" policy was started for that maintainer. > > > > For an example, I've just opened such a bug [2] for boinc-client > > maintainer that owns several other packages with open bugs and no > > activity since May. > > What should happens, if the reporter of the nune-responsive maintainer bug > only > want to takeover a single package, but the unresponsive maintainer owns > several packages? They should be orphaned; it's not good from any angle for packages to be 'maintained' by someone who has been established to be non-responsive. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if "-Werror=format-security" flag is used
Adam Jackson wrote: > Allow me to suggest something that really shouldn't be controversial, > but probably is, because this is the internet: standards compliance for > its own sake is not actually worthwhile. Tell that to the GCC (especially g++) developers who keep breaking backwards compatibility in the name of standards compliance. ;-) The reason I don't like this proposed -Werror=format-security change is that it breaks compatibility and removes functionality, not just standards compliance for the sake of it. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Claiming ownership of fish (and sponsor needed)
Hi all- I'd like to claim ownership of the 'fish' package (i.e. the fish shell). The (re-)review request is here: https://bugzilla.redhat.com/show_bug.cgi?id=974852 This is my first package, so I'll need a sponsor, too. Thanks, Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mass rebuild miss-tagged?
Ignore that it was due to something I was looking at. it needs no action from anyone. Dennis -- Sent from my Android device with K-9 Mail. Please excuse my brevity.-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if "-Werror=format-security" flag is used
Les Howell wrote:
>> printf("%s", string) is inefficient. In
>> this case, it would be better to use puts/fputs.
>>
>unless something has changed recently fputs and puts just like gets
>and fgets have been deprecated and are discouraged due to potential
>security issues.
gets is horribly insecure because it doesn't care how long the buffer
it's writing to is.
fgets is better because it has a size parameter, but you have to take
care to pass the correct size to it. It's more risky than a real array
with bounds checking, but it's about as secure as it gets in the
standard C library.
puts and fputs aren't any more dangerous than any other handling of
null-terminated strings. There is definitely no security to be gained
by using printf instead of puts or fputs.
Björn Persson
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if "-Werror=format-security" flag is used
On 09/12/13 23:01, Les Howell wrote: unless something has changed recently fputs and puts just like gets and fgets have been deprecated and are discouraged due to potential security issues. Nonsense. The reason gets is dangerous is because it doesn't take a buffer size so will continue reading until it sees a newline even if it has long since overflowed the buffer - there is literally no way to use it safely unless you can guarantee the maximum length of a line in the input stream. That does not apply to fgets, which takes a buffer length and is therefore safe as it will not overflow the buffer. It also doesn't apply to put or fputs, which are output routines so read from the buffer rather than writing to it, stopping at a nul. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if "-Werror=format-security" flag is used
On 10.12.2013 00:01, Les Howell wrote:
> On Mon, 2013-12-09 at 15:59 -0700, Rich Megginson wrote:
>> On 12/09/2013 03:33 PM, Przemek Klosowski wrote:
>>
>>> On 12/06/2013 09:21 AM, Ralf Corsepius wrote:
>>>
printf(string) is legitimate C, forcing "printf("%s", string) is
just silly.
>>> My apologies for being repetitive, but the original point is that
>>> printf(string) is insecure unless you can guarantee that you control
>>> 'string' now and forever. Also, %s is the format for printing
>>> strings, so I just can't agree that coding printf("%s", string) is
>>> silly.
>>
>> Silly is not the right word. printf("%s", string) is inefficient. In
>> this case, it would be better to use puts/fputs.
>>
> unless something has changed recently fputs and puts just like gets and
> fgets have been deprecated and are discouraged due to potential security
> issues.
>
>
Something must have changed. GCC uses puts instead of printf in some
cases. Please, see below:
$ cat p.c
#include
int main()
{
printf("Hello world!\n");
return 0;
}
$ gcc -S p.c
$ cat p.s
.file "p.c"
.section.rodata
.LC0:
.string "Hello world!"
.text
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movl$.LC0, %edi
callputs
movl$0, %eax
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size main, .-main
.ident "GCC: (GNU) 4.8.2 20131017 (Red Hat 4.8.2-1)"
.section.note.GNU-stack,"",@progbits
Mateusz Marzantowicz
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if "-Werror=format-security" flag is used
On Mon, 2013-12-09 at 15:59 -0700, Rich Megginson wrote:
> On 12/09/2013 03:33 PM, Przemek Klosowski wrote:
>
> > On 12/06/2013 09:21 AM, Ralf Corsepius wrote:
> >
> > >
> > > printf(string) is legitimate C, forcing "printf("%s", string) is
> > > just silly.
> > >
> > My apologies for being repetitive, but the original point is that
> > printf(string) is insecure unless you can guarantee that you control
> > 'string' now and forever. Also, %s is the format for printing
> > strings, so I just can't agree that coding printf("%s", string) is
> > silly.
>
> Silly is not the right word. printf("%s", string) is inefficient. In
> this case, it would be better to use puts/fputs.
>
unless something has changed recently fputs and puts just like gets and
fgets have been deprecated and are discouraged due to potential security
issues.
> >
> >
>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if "-Werror=format-security" flag is used
On 12/09/2013 03:33 PM, Przemek Klosowski wrote:
On 12/06/2013 09:21 AM, Ralf Corsepius wrote:
printf(string) is legitimate C, forcing "printf("%s", string) is just
silly.
My apologies for being repetitive, but the original point is that
printf(string) is insecure unless you can guarantee that you control
'string' now and forever. Also, %s is the format for printing
strings, so I just can't agree that coding printf("%s", string) is silly.
Silly is not the right word. printf("%s", string) is inefficient. In
this case, it would be better to use puts/fputs.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if "-Werror=format-security" flag is used
On Sun, 2013-12-08 at 01:17 +0100, Kevin Kofler wrote: > Michael scherer wrote: > > There is enough software not building anymore and dropped after mass > > rebuild to show that such problem are not really so uncommon. > > … the difference is that in this case, the offending code is actually > perfectly compliant to the C or C++ standard, and rejecting it is a > violation of the relevant standard (in addition to being backwards- > incompatible). Allow me to suggest something that really shouldn't be controversial, but probably is, because this is the internet: standards compliance for its own sake is not actually worthwhile. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[389-devel] please review: Ticket 47622 - Automember betxnpreoperation - transaction not aborted when group entry does not exist
https://fedorahosted.org/389/ticket/47622 https://fedorahosted.org/389/attachment/ticket/47622/0001-Ticket-47622-Automember-betxnpreoperation-transactio.patch -- Mark Reynolds 389 Development Team Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: FTBFS if "-Werror=format-security" flag is used
On 12/06/2013 09:21 AM, Ralf Corsepius wrote:
printf(string) is legitimate C, forcing "printf("%s", string) is just
silly.
My apologies for being repetitive, but the original point is that
printf(string) is insecure unless you can guarantee that you control
'string' now and forever. Also, %s is the format for printing strings,
so I just can't agree that coding printf("%s", string) is silly.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Owner-change] Fedora packages ownership change
Change in ownership over the last 168 hours === 1 packages were orphaned giflib [devel,f18,f19,f20] was orphaned by robert Library for manipulating GIF format image files https://admin.fedoraproject.org/pkgdb/acls/name/giflib 2 packages unorphaned - ooprala unorphaned : mtools [devel,f18,f19,f20] ausil unorphaned : uboot-tools [devel,f19,f20] 30 packages were retired - php-symfony2-HttpKernel [EL-6,devel,f19,f20] was retired by siwinski Symfony2 HttpKernel Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-HttpKernel qt5-qtjsbackend [devel,f20] was retired by rdieter Qt5 - QtJSBackend component https://admin.fedoraproject.org/pkgdb/acls/name/qt5-qtjsbackend python-django-lint [devel,f20] was retired by mrunge Analyzes Django code looking for bugs and signs of poor quality https://admin.fedoraproject.org/pkgdb/acls/name/python-django-lint php-symfony2-Console [EL-6,devel,f19,f20] was retired by siwinski Symfony2 Console Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-Console php-symfony2-Serializer [EL-6,devel,f19,f20] was retired by siwinski Symfony2 Serializer Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-Serializer sysvinit [devel] was retired by lnykryn Programs which control basic system processes https://admin.fedoraproject.org/pkgdb/acls/name/sysvinit php-symfony2-Filesystem [EL-6,devel,f19,f20] was retired by siwinski Symfony2 Filesystem Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-Filesystem objectweb-asm4 [devel] was retired by gil A code manipulation tool to implement adaptable systems https://admin.fedoraproject.org/pkgdb/acls/name/objectweb-asm4 php-symfony2-Validator [EL-6,devel,f19,f20] was retired by siwinski Symfony2 Validator Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-Validator php-symfony2-ClassLoader [EL-6,devel,f19,f20] was retired by siwinski Symfony2 ClassLoader Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-ClassLoader php-symfony2-OptionsResolver [EL-6,devel,f19,f20] was retired by siwinski Symfony2 OptionsResolver Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-OptionsResolver php-symfony2-DependencyInjection [EL-6,devel,f19,f20] was retired by siwinski Symfony2 DependencyInjection Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-DependencyInjection php-symfony2-Finder [EL-6,devel,f19,f20] was retired by siwinski Symfony2 Finder Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-Finder php-symfony2-Routing [EL-6,devel,f19,f20] was retired by siwinski Symfony2 Routing Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-Routing php-symfony2-Translation [EL-6,devel,f19,f20] was retired by siwinski Symfony2 Translation Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-Translation php-symfony2-PropertyAccess [EL-6,devel,f19,f20] was retired by siwinski Symfony2 PropertyAccess Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-PropertyAccess python-setuptools [EL-5] was retired by till Easily build and distribute Python packages https://admin.fedoraproject.org/pkgdb/acls/name/python-setuptools php-symfony2-Config [EL-6,devel,f19,f20] was retired by siwinski Symfony2 Config Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-Config php-symfony2-BrowserKit [EL-6,devel,f19,f20] was retired by siwinski Symfony2 BrowserKit Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-BrowserKit php-symfony2-HttpFoundation [EL-6,devel,f19,f20] was retired by siwinski Symfony2 HttpFoundation Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-HttpFoundation php-symfony2-Yaml [EL-6,devel,f19,f20] was retired by siwinski Symfony2 Yaml Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-Yaml php-symfony2-Security [EL-6,devel,f19,f20] was retired by siwinski Symfony2 Security Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-Security php-symfony2-Locale [EL-6,devel,f19,f20] was retired by siwinski Symfony2 Locale Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-Locale php-symfony2-Form [EL-6,devel,f19,f20] was retired by siwinski Symfony2 Form Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-Form php-symfony2-EventDispatcher [EL-6,devel,f19,f20] was retired by siwinski Symfony2 EventDispatcher Component https://admin.fedoraproject.org/pkgdb/acls/name/php-symfony2-EventDispatcher libmatekeyring [devel,f20] was retired b
Re: Mass rebuild miss-tagged?
Peter Robinson venit, vidit, dixit 09.12.2013 14:19: > Was it from koji.fedoraproject, or arm.koji.fedoraproject? > > Peter There were two mails with identical content: the first from buildsys@fp.o to ausil@fp.o and myself the second from buildsys@fp.o to probinso@fp.o, arm-bu...@lists.fp.o and myself The srpm builds in scratch: http://koji.fedoraproject.org/koji/taskinfo?taskID=6271675 Michael > On Mon, Dec 9, 2013 at 1:10 PM, Michael J Gruber > wrote: >> I got a message from buildsys about an unsuccessful tag which I hadn't >> initiated - probably left over bits from the F20 mass rebuild. >> >> Should I simply (re)build on master to try abd deal with that? >> >> Since fedpkg has no "scratch-head" command I'll settle for >> "scratch-build" next... >> >> Michael >> >> BibTool-2.55-4.fc20 unsuccessfully tagged into f21 by ausil >> >> Package: BibTool >> NVR: BibTool-2.55-4.fc20 >> User: ausil >> Status: failed >> Tag Operation: tagged >> Into Tag: f21 >> >> BibTool-2.55-4.fc20 unsuccessfully tagged into f21 by ausil >> Operation failed with the error: >> : build BibTool-2.55-4.fc20 already tagged (f21) >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mass rebuild miss-tagged?
Was it from koji.fedoraproject, or arm.koji.fedoraproject? Peter On Mon, Dec 9, 2013 at 1:10 PM, Michael J Gruber wrote: > I got a message from buildsys about an unsuccessful tag which I hadn't > initiated - probably left over bits from the F20 mass rebuild. > > Should I simply (re)build on master to try abd deal with that? > > Since fedpkg has no "scratch-head" command I'll settle for > "scratch-build" next... > > Michael > > BibTool-2.55-4.fc20 unsuccessfully tagged into f21 by ausil > > Package: BibTool > NVR: BibTool-2.55-4.fc20 > User: ausil > Status: failed > Tag Operation: tagged > Into Tag: f21 > > BibTool-2.55-4.fc20 unsuccessfully tagged into f21 by ausil > Operation failed with the error: > : build BibTool-2.55-4.fc20 already tagged (f21) > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Mass rebuild miss-tagged?
I got a message from buildsys about an unsuccessful tag which I hadn't initiated - probably left over bits from the F20 mass rebuild. Should I simply (re)build on master to try abd deal with that? Since fedpkg has no "scratch-head" command I'll settle for "scratch-build" next... Michael BibTool-2.55-4.fc20 unsuccessfully tagged into f21 by ausil Package: BibTool NVR: BibTool-2.55-4.fc20 User: ausil Status: failed Tag Operation: tagged Into Tag: f21 BibTool-2.55-4.fc20 unsuccessfully tagged into f21 by ausil Operation failed with the error: : build BibTool-2.55-4.fc20 already tagged (f21) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20131209 changes
Compose started at Mon Dec 9 05:15:07 UTC 2013 Broken deps for i386 -- [LuxRender] LuxRender-1.0-16.fc21.i686 requires libImath-2_0.so.10 LuxRender-1.0-16.fc21.i686 requires libIlmThread-2_0.so.10 LuxRender-1.0-16.fc21.i686 requires libIlmImf-Imf_2_0.so.20 LuxRender-1.0-16.fc21.i686 requires libIex-2_0.so.10 LuxRender-1.0-16.fc21.i686 requires libHalf.so.10 LuxRender-core-1.0-16.fc21.i686 requires libImath-2_0.so.10 LuxRender-core-1.0-16.fc21.i686 requires libIlmThread-2_0.so.10 LuxRender-core-1.0-16.fc21.i686 requires libIlmImf-Imf_2_0.so.20 LuxRender-core-1.0-16.fc21.i686 requires libIex-2_0.so.10 LuxRender-core-1.0-16.fc21.i686 requires libHalf.so.10 LuxRender-lib-1.0-16.fc21.i686 requires libImath-2_0.so.10 LuxRender-lib-1.0-16.fc21.i686 requires libIlmThread-2_0.so.10 LuxRender-lib-1.0-16.fc21.i686 requires libIlmImf-Imf_2_0.so.20 LuxRender-lib-1.0-16.fc21.i686 requires libIex-2_0.so.10 LuxRender-lib-1.0-16.fc21.i686 requires libHalf.so.10 [OpenEXR_CTL] OpenEXR_CTL-1.0.1-16.fc20.i686 requires libImath.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmThread.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmImf.so.7 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIexMath.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIex.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libHalf.so.6 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmThread.so.6 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmImf.so.7 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIex.so.6 [OpenEXR_Viewers] OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libImath-2_0.so.10 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIlmThread-2_0.so.10 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIlmImf-Imf_2_0.so.20 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIexMath-2_0.so.10 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIex-2_0.so.10 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libHalf.so.10 [R-RScaLAPACK] R-RScaLAPACK-0.6.1-13.fc20.i686 requires libatlas.so.3 [blueman] blueman-1.23-7.fc20.i686 requires obex-data-server >= 0:0.4.3 blueman-1.23-7.fc20.i686 requires gvfs-obexftp [converseen] converseen-0.6.2-2.fc20.i686 requires libMagick++-6.Q16.so.1 [derelict] derelict-tcod-3-20.20130626gite70c293.fc20.i686 requires tcod derelict-tcod-devel-3-20.20130626gite70c293.fc20.i686 requires tcod [dmapd] dmapd-0.0.55-5.fc21.i686 requires libImath-2_0.so.10 dmapd-0.0.55-5.fc21.i686 requires libIlmThread-2_0.so.10 dmapd-0.0.55-5.fc21.i686 requires libIlmImf-Imf_2_0.so.20 dmapd-0.0.55-5.fc21.i686 requires libIexMath-2_0.so.10 dmapd-0.0.55-5.fc21.i686 requires libIex-2_0.so.10 dmapd-0.0.55-5.fc21.i686 requires libHalf.so.10 [dragonegg] dragonegg-3.3-11.fc21.i686 requires gcc = 0:4.8.2-1.fc21 [drawtiming] drawtiming-0.7.1-11.fc20.i686 requires libMagick++-6.Q16.so.1 [evolution-rss] 1:evolution-rss-0.3.94-2.fc21.i686 requires libcamel-1.2.so.46 [gpsdrive] gpsdrive-2.11-20.fc20.i686 requires libgps.so.20 [gtkd] gtkd-2.0.0-29.20120815git9ae9181.fc18.i686 requires libphobos-ldc.so.60 [httpdtap] httpdtap-0.2-2.fc21.noarch requires kernel-debuginfo httpdtap-0.2-2.fc21.noarch requires httpd-debuginfo httpdtap-0.2-2.fc21.noarch requires apr-util-debuginfo httpdtap-0.2-2.fc21.noarch requires apr-debuginfo [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [libghemical] libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3 libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [licq] licq-1.8.1-1.fc21.i686 requires libgloox.so.8 [mpqc] mpqc-2.3.1-23.fc20.i686 requires libf77blas.so.3 mpqc-2.3.1-23.fc20.i686 requires libatlas.so.3 [netdisco] netdisco-1.1-6.fc20.noarch requires perl(SNMP::Info::Layer2::Bay) [nifti2dicom] nifti2dicom-0.4.6-3.fc20.i686 requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkIO.so.5
F-20 Branched report: 20131209 changes
Compose started at Mon Dec 9 07:15:02 UTC 2013 Broken deps for armhfp -- [avro] avro-mapred-1.7.5-1.fc20.noarch requires hadoop-mapreduce avro-mapred-1.7.5-1.fc20.noarch requires hadoop-client [blueman] blueman-1.23-7.fc20.armv7hl requires obex-data-server >= 0:0.4.3 blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp [cloud-init] cloud-init-0.7.2-7.fc20.noarch requires dmidecode [cobbler] cobbler-2.4.0-2.fc20.noarch requires syslinux [fts] fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14 [ghc-hjsmin] ghc-hjsmin-devel-0.1.4.3-2.fc20.armv7hl requires ghc-devel(language-javascript-0.5.8-28fa88554adf134b03284de53334e91d) [gofer] ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) >= 0:0.16.0 [gtkd] gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 0:2.0.0-29.20120815git9ae9181.fc18 [kawa] 1:kawa-1.11-5.fc19.armv7hl requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0 [msp430-libc] msp430-libc-20120224-2.fc19.noarch requires msp430-gcc >= 0:4.6.3 [nifti2dicom] nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10 [nocpulse-common] nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI) [openbox] gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel [openpts] openpts-0.2.6-7.fc20.armv7hl requires tboot [owncloud] owncloud-5.0.13-1.fc20.noarch requires php-pear(pear.symfony.com/Routing) [perl-Language-Expr] perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [php-Assetic] php-Assetic-1.1.2-1.fc20.noarch requires php-pear(pear.symfony.com/Process) < 0:3.0 php-Assetic-1.1.2-1.fc20.noarch requires php-pear(pear.symfony.com/Process) >= 0:2.1 [php-Metadata] php-Metadata-1.5.0-1.fc20.noarch requires php-pear(pear.symfony.com/DependencyInjection) [php-SymfonyCmfRouting] php-SymfonyCmfRouting-1.1.0-1.fc20.noarch requires php-pear(pear.symfony.com/Routing) < 0:3.0 php-SymfonyCmfRouting-1.1.0-1.fc20.noarch requires php-pear(pear.symfony.com/Routing) >= 0:2.2 php-SymfonyCmfRouting-1.1.0-1.fc20.noarch requires php-pear(pear.symfony.com/HttpKernel) < 0:3.0 php-SymfonyCmfRouting-1.1.0-1.fc20.noarch requires php-pear(pear.symfony.com/HttpKernel) >= 0:2.2 php-SymfonyCmfRouting-1.1.0-1.fc20.noarch requires php-pear(pear.symfony.com/EventDispatcher) < 0:3.0 php-SymfonyCmfRouting-1.1.0-1.fc20.noarch requires php-pear(pear.symfony.com/EventDispatcher) >= 0:2.2 [php-doctrine-DoctrineDBAL] php-doctrine-DoctrineDBAL-2.3.4-4.fc20.noarch requires php-pear(pear.symfony.com/Console) < 0:3.0 php-doctrine-DoctrineDBAL-2.3.4-4.fc20.noarch requires php-pear(pear.symfony.com/Console) >= 0:2.0 [php-doctrine-DoctrineORM] php-doctrine-DoctrineORM-2.3.3-2.fc20.noarch requires php-pear(pear.symfony.com/Yaml) < 0:3.0 php-doctrine-DoctrineORM-2.3.3-2.fc20.noarch requires php-pear(pear.symfony.com/Yaml) >= 0:2.0 php-doctrine-DoctrineORM-2.3.3-2.fc20.noarch requires php-pear(pear.symfony.com/Console) < 0:3.0 php-doctrine-DoctrineORM-2.3.3-2.fc20.noarch requires php-pear(pear.symfony.com/Console) >= 0:2.0 [php-guzzle-Guzzle] php-guzzle-Guzzle-3.7.4-2.fc20.noarch requires php-pear(pear.symfony.com/EventDispatcher) >= 0:2.1.0 [php-phpunit-DbUnit] php-phpunit-DbUnit-1.3.0-1.fc20.noarch require
Unresponsive maintainers of dependent packages
Hi. Before my question, little bit of introduction: --- I'm the maintainer of 'openobex' package (library) which was rebased to the latest version in rawhide on the end of September this year. The rebase was announced 2 weeks in advance on fedora-devel and I also CC-ed all maintainers of dependent packages about the change. There was an API change, so more work than just rebuilding dependent packages is needed. I emailed maintainers of dependent packages and also created Bug [1] for each component, to track those rebuilds. So far some dependent packages has been deprecated, but there are still three that have broken dependencies and their maintainers seem to not care. Question: - The main problem for me is that the buildsystem (koji) emails me every day and for every dependent package that their dependencies are broken. Can I ask these packages to be deprecated in rawhide, or what can I do with them? I don't want to take maintenance of those packages. Dependent packages I have problem with are: - obexfs - obexftp - libopensync-plugin-irmc Thanks in advance for any help/opinion. Regards, Tomas Hozza [1] https://bugzilla.redhat.com/show_bug.cgi?id=1014160 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora ARM Status Meeting 2013-12-04
On Mon, Dec 9, 2013 at 7:18 AM, Pavel Zhukov wrote:
> On Wednesday, December 04, 2013 07:28:09 PM Peter Robinson wrote:
>> On Wed, Dec 4, 2013 at 7:21 PM, Pavel Zhukov wrote:
>> > On Wednesday, December 04, 2013 07:11:40 PM Peter Robinson wrote:
>> >> On Wed, Dec 4, 2013 at 5:17 PM, Pavel Zhukov wrote:
>> >> > Hi list(s),
>> >> >
>> >> > We still doesn't have gnat compiler for %{arm} in Fedora. We (Ada
>> >> > community) have compiled gcc with ada support using gcc-4.8.2 src.rpm
>> >> > and tested in. It seems workable. At least we were able to compile most
>> >> > of the
>> >> > packages from the stack with it.
>> >> > I'd like to discuss way how to get it in Fedora (chicken-egg problem
>> >> > should be solved).
>> >>
>> >> That's relatively straight forward. We need a documented process to
>> >> get it done. Once we have that I can sort it out with rel-eng but we
>> >> would need the gcc maintainer to review/approve it.
>> >>
>> >> Generally what happens is that it would be built (or imported) into a
>> >> side tag build. I suspect it'll be using something like a cross
>> >> compiled version of ada which is then used to compile a native built
>> >> version of ada which is then tagged into rawhide at which point the
>> >> rest of the ada stack would be rebuilt.
>> >
>> > Yes. We cross-compiled bootstrap and compiled native version using it.
>> > It's
>> > original Fedora gcc without any modifications (just added arm to the gnat
>> > arches list) and applied short patch [1]
>> > It was the long process [2] in qemu with all tests performed. I'm going to
>> > recompile it once more time using Cubieboard and move to documentation
>> > step
>> > after.
>>
>> If you document it first I can test it on decent physical HW which
>> should be a lot faster to save you some time.
> I've documented it
> https://fedoraproject.org/wiki/User:Landgraf/Building_Gnat_ARM
> Can you please verify the build?
You don't have instructions for how I would cross compile.
Can you also start a new thread, it shouldn't have hijacked the meeting thread
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: pl license change
On 2013-12-06, Kevin Kofler wrote: > Petr Pisar wrote: > >> On 2013-12-04, Kevin Kofler wrote: >>> Petr Pisar wrote: [snip] and GPLv2 and GPLv3+. >>> >>> Huh? WTF is upstream smoking there? >>> >> Upstream releases a tar ball bundling a lot of subprojects. Thus the >> complicated license. I do a licence review each new release and I always >> find new licenses. This time I had to drop two files because of >> non-commercial requirement. > > My main complaint there was about the mix of incompatible GPL versions. > If they are two separate executables, there is no problem. But still you need to declare the licenses at the RPM level in one line. Having conflicting license conjuction does not imply a conflict. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
