1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
|
From vondruch at redhat.com Tue Jul 10 11:29:44 2012
From: vondruch at redhat.com (=?ISO-8859-2?Q?V=EDt_Ondruch?=)
Date: Tue, 10 Jul 2012 13:29:44 +0200
Subject: [Fedora-packaging] RPM macros
Message-ID: <4FFC1228.3060409@redhat.com>
Hi,
I noticed that in revised haskell guidelines [1], there is mentioned the
ghc-rpm-macros package, which provides macros.ghc file, which in turns
provides some useful macros for packaging of Haskell packages. In Ruby,
we provide similar macro files in ruby-devel and rubygems-devel
subpackages respectively. Perl has their macros directly in the rpm
package itself.
This seems to be a bit inconsistent to me. So my question is: shouldn't
we standardize some best practices with regards of RPM macros? For
example for Ruby, we placed the macros into -devel subpackages, because
we believe that it is just development dependency. Any opinions?
Vit
[1] http://lists.fedoraproject.org/pipermail/packaging/2012-July/008527.html
From vondruch at redhat.com Tue Jul 10 12:11:53 2012
From: vondruch at redhat.com (=?UTF-8?B?VsOtdCBPbmRydWNo?=)
Date: Tue, 10 Jul 2012 14:11:53 +0200
Subject: [Fedora-packaging] RPM macros
In-Reply-To: <4FFC1688.7090907@city-fan.org>
References: <4FFC1228.3060409@redhat.com> <4FFC1688.7090907@city-fan.org>
Message-ID: <4FFC1C09.6030907@redhat.com>
Dne 10.7.2012 13:48, Paul Howarth napsal(a):
> On 07/10/2012 12:29 PM, Vít Ondruch wrote:
>> Hi,
>>
>> I noticed that in revised haskell guidelines [1], there is mentioned the
>> ghc-rpm-macros package, which provides macros.ghc file, which in turns
>> provides some useful macros for packaging of Haskell packages. In Ruby,
>> we provide similar macro files in ruby-devel and rubygems-devel
>> subpackages respectively. Perl has their macros directly in the rpm
>> package itself.
>>
>> This seems to be a bit inconsistent to me. So my question is: shouldn't
>> we standardize some best practices with regards of RPM macros? For
>> example for Ruby, we placed the macros into -devel subpackages, because
>> we believe that it is just development dependency. Any opinions?
>
> Perl has the macros in the main perl package rather than the
> perl-devel package because arch-independent perl module builds often
> don't need perl-devel - the packaging split is more fine-grained for
> perl and tends to become finer with each release as more and more bits
> are split out into their own subpackages since they have their own
> lives upstream.
Thank you for your clarification. Actually, it is similar for Ruby.
Arch-independent packages do not require -devel package because of
build, but because of macros. And I find it more reasonable then to have
/etc/rpm/macros.ruby in my runtime system, where I have no use for this
file.
Vit
From bjorn at xn--rombobjrn-67a.se Thu Jul 12 23:49:23 2012
From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=)
Date: Fri, 13 Jul 2012 01:49:23 +0200
Subject: [Fedora-packaging] Script-Tools, which location?
In-Reply-To: <CACyNwR1VLMm019JTnju9gbXVq4=p2y+=NP8NuOh1XShtRVG+Nw@mail.gmail.com>
References: <CACyNwR1VLMm019JTnju9gbXVq4=p2y+=NP8NuOh1XShtRVG+Nw@mail.gmail.com>
Message-ID: <201207130149.23771.bjorn@xn--rombobjrn-67a.se>
Simon A. Erat wrote:
> First of all, whats the acronym FHS standing for?
The Filesystem Hierarchy Standard:
http://www.pathname.com/fhs/pub/fhs-2.3.html
It's linked from the Packaging Guidelines, which I hope you read before you
made your package:
https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout
> 1) At first it was designed to be distributed as tarball, i want to keep
> this option, as this allows an easy port/install to any other linux distro.
> (just extract anywhere of your choice and run from there)
It's easier to do that if you give your relocatable directory tree an FHS-like
structure, with a prefix that can be set to "/usr", "/usr/local",
"/opt/Simon's-script-tools" or anything else, and place scripts in $prefix/bin,
read-only data in $prefix/share et cetera.
You may still find that you need to make your scripts capable of adapting a bit
to different directory layouts.
> i currently save any data in $HOME/bin/$USER-libs, and offering
> $HOME/bin/$USER-scripts to be used for custom scripts using the functions
> which Script-Tools provides.
You shouldn't make subdirectories under $HOME/bin any more than under
/usr/bin. Although users' home directories are less standardized than system
directories, $HOME/bin is typically used for the users' own programs that they
want to be able to run from a command prompt. Programs in subdirectories
wouldn't be found unless the users added the subdirectories to PATH.
Also, anything that ends with "libs" seems like a bad name for a directory to
save data in.
Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20120713/2377d1ee/attachment.sig>
From mmaslano at redhat.com Wed Jul 18 07:41:37 2012
From: mmaslano at redhat.com (=?UTF-8?B?TWFyY2VsYSBNYcWhbMOhxYhvdsOh?=)
Date: Wed, 18 Jul 2012 09:41:37 +0200
Subject: [Fedora-packaging] RPM macros
In-Reply-To: <4FFC1228.3060409@redhat.com>
References: <4FFC1228.3060409@redhat.com>
Message-ID: <500668B1.8090904@redhat.com>
On 07/10/2012 01:29 PM, Vít Ondruch wrote:
> Hi,
>
> I noticed that in revised haskell guidelines [1], there is mentioned the
> ghc-rpm-macros package, which provides macros.ghc file, which in turns
> provides some useful macros for packaging of Haskell packages. In Ruby,
> we provide similar macro files in ruby-devel and rubygems-devel
> subpackages respectively. Perl has their macros directly in the rpm
> package itself.
>
> This seems to be a bit inconsistent to me. So my question is: shouldn't
> we standardize some best practices with regards of RPM macros? For
> example for Ruby, we placed the macros into -devel subpackages, because
> we believe that it is just development dependency. Any opinions?
>
>
> Vit
>
>
>
> [1]
> http://lists.fedoraproject.org/pipermail/packaging/2012-July/008527.html
It depends what you need to do. Part of Perl macros is in a special
package perl-srpm-macros, which is required by redhat-rpm-config. We
should have all macros defined in perl-srpm-macros in buildroot
everytime, which was one of our issues during annual rebuild.
Marcela
From dan at danny.cz Tue Jul 24 20:24:38 2012
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 24 Jul 2012 22:24:38 +0200
Subject: [Fedora-packaging] Distributing prebuilt bios roms with QEMU
In-Reply-To: <20120724194842.GA5959@amd.home.annexia.org>
References: <500EF313.4060800@redhat.com> <500EF6E0.1050300@redhat.com>
<20120724194842.GA5959@amd.home.annexia.org>
Message-ID: <1343161478.3005.55.camel@eagle.danny.cz>
Richard W.M. Jones píše v Út 24. 07. 2012 v 20:48 +0100:
> On Tue, Jul 24, 2012 at 03:26:24PM -0400, Tom Callaway wrote:
> > I really do wish we could come up with a clever way to build these on
> > the native platforms, but I also understand how difficult that is, and I
> > really don't want to stonewall on that.
>
> On the BZ we discussed cross-compiling them. It would require
> approx. 2 extra packages per architecture, ie. a cross gcc and a cross
> binutils (since it's firmware, no libc is required of course).
the cross-gcc and cross-binutils all(?) Linux kernel arches are already
there, no libgcc yet, but it shouldn't be an issue for firmwares
Dan
From bjorn at xn--rombobjrn-67a.se Sun Jul 29 18:57:00 2012
From: bjorn at xn--rombobjrn-67a.se (=?ISO-8859-1?Q?Bj=F6rn?= Persson)
Date: Sun, 29 Jul 2012 20:57 +0200
Subject: [Fedora-packaging] May binaries be built from generated "source"
code?
Message-ID: <1575009.Hf8WqyK1vx@hactar.xn--rombobjrn-67a.se>
The Packaging Guidelines require that all binary programs and libraries be
built from source code. How should this requirement be interpreted when some
of the "source code" is itself automatically generated from other sources?
GTKada is an Ada binding to GTK+. In the latest version, some of the Ada files
in the source tarball have been generated by a program that is included in the
tarball. Future versions will have even more generated code. The input to the
code generator is a GIR file, which as far as I understand is some kind of XML
representation of the GTK+ API. The GIR file has in turn been generated from
the C source code of GTK+. The GIR file is included in the GTKada tarball, but
the GTK+ source is not.
Now I'm trying to figure out whether I can build the GTKada package from the
distributed generated Ada code, or whether I have to run the code generation
as a part of the build, possibly using the GIR file from the GTK+ package
instead of the one in the GTKada tarball.
There are two reasons for the requirement listed in the guidelines:
· "Security: Pre-packaged program binaries and program libraries not built
from the source code could contain parts that are malicious, dangerous, or
just broken. Also, these are functionally impossible to patch."
The generated Ada code is nicely formatted and legible, and no harder to
review than hand-written source code. It would be possible to patch it,
although such a patch would of course not be upstreamable.
· "Compiler Flags: Pre-packaged program binaries and program libraries not
built from the source code were probably not compiled with standard Fedora
compiler flags for security and optimization."
This obviously doesn't apply to generated code that hasn't yet been through a
compiler.
Thus, none of the stated reasons seem to be relevant to this case, and I can
see only one thing that could mean that I have to run the code generation as a
part of the build, namely the term "source code". My question is: Is it
required that all the steps in the process from the actual source code to
binary code take place on Fedora's build servers, or is it sufficient that
binaries are built from human-readable code even if that code isn't the actual
source code?
In other words: Should I read "source code" literally, as "the ultimate source
code written by human programmers", or is it OK, for the purpose of this
requirement, to read it as "human-readable code in a textual programming
language"?
Björn Persson
|
