Re: howto not strip .so on install
On Wed, 2011-07-27 at 11:48 -0400, Neal Becker wrote: Trying to help packaging dmtcp. There are 2 shared libs installed. They are stripped by the rpm install, and then fail when attempting to dlopen them (or 1 of them). 1. Is that normal behaviour? No, the strip performed by the rpm install should not break normal usage of dlopen or dlsym. X's input and video drivers, for example, have no problem with it. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide should take turns with F-16 Branched
On 8/1/11 10:55 AM, John Reiser wrote: On 07/31/2011 01:37 PM, Josh Boyer wrote: On Sun, Jul 31, 2011 at 3:22 PM, John Reiserjrei...@bitwagon.com wrote: The nightly build mash for Fedora-16 Branched should go first, before Rawhide, on a few days per week ... You should open a ticket with rel-eng to see if this could be implemented. https://fedorahosted.org/fesco/ticket/658 That's not rel-eng. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intel HD 3000 video blank screen during install of F15
On 8/3/11 8:58 AM, Ric Wheeler wrote: I have a shiny new laptop (HP Pavilion dm4) with the Sandy Bridge video (HD 3000). Installing F15 or the nightly F16 build causes a blank screen during the install. Installing/running basic video works but is annoying. I have spent a few days poking around, looking for known issues. Is this unique to me? If not fedora-devel, what is the right forum to post to with details? The upstream list for issues with Intel graphics chips is intel-...@lists.freedesktop.org, but there's probably a fair bit of information we should get first. I've been chasing a pile of Sandybridge issues for RHEL6 anyway, so we might as well start here. The standard reference page for information to collect for debugging KMS problems is here: http://fedoraproject.org/wiki/How_to_debug_Xorg_problems#KMS-related_issues Ignore the bits about testing the non-KMS environment and the X log, they're not going to be relevant for you. But the video ROM, register dump, and dmesg output will all be informative. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20110803 changes
On 8/3/11 9:48 AM, Peter Robinson wrote: We would love to build all PCI drivers for all platforms if the drivers compiled for all secondary arches :-) See bug 713609 as an example. https://bugzilla.redhat.com/show_bug.cgi?id=713609 I would debug this problem on an arm builder, if I could initialize a buildroot: http://arm.koji.fedoraproject.org/koji/getfile?taskID=140952name=root.log - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Meeting minutes/summary for 2011-08-08 fesco meeting
=== #fedora-meeting: FESCO (2011-08-07) === Meeting started by ajax at 17:01:26 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-08-08/fesco.2011-08-08-17.01.log.html . Meeting summary --- * init process (ajax, 17:01:27) * #563 suggested policy: all daemons must set RELRO and PIE flags (ajax, 17:03:27) * LINK: http://lists.fedoraproject.org/pipermail/devel/2011-August/155358.html (ajax, 17:03:54) * ACTION: ajax to update the draft page for FPC to create guidelines (ajax, 17:07:57) * ACTION: ajax to forward summary email to devel-announce (ajax, 17:09:23) * ACTION: ajax to email lists when all updates in place (ajax, 17:09:32) * #615 Strategy for services that do not have systemd native unit (ajax, 17:12:25) * LINK: https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd (Viking-Ice, 17:15:15) * ACTION: sgallagh to talk to virt people about dnsmasq (ajax, 17:17:45) * ACTION: remaining four packages (iscsi, dnsmasq, openvpn, wpa_supplicant) targeted for conversion by beta (ajax, 17:30:49) * AGREED: try for converting all services on the dvd by beta. (ajax, 17:43:08) * #654 Proven packager request (ajax, 17:43:32) * LINK: https://fedorahosted.org/fedora-infrastructure/ticket/2514 (should see if that can be closed) (nirik, 17:49:09) * AGREED: ppisar's provenpackager request is accepted (ajax, 17:50:19) * fesco members as sponsors (ajax, 17:51:06) * ACTION: nirik to dig in archives for fesco-as-sponsor background and report next week (ajax, 17:54:17) * Next week's chair (ajax, 17:54:28) * t8m to chair next week * Open Floor (ajax, 17:55:48) Meeting ended at 18:01:30 UTC. Action Items * ajax to update the draft page for FPC to create guidelines * ajax to forward summary email to devel-announce * ajax to email lists when all updates in place * sgallagh to talk to virt people about dnsmasq * remaining four packages (iscsi, dnsmasq, openvpn, wpa_supplicant) targeted for conversion by beta * nirik to dig in archives for fesco-as-sponsor background and report next week Action Items, by person --- * ajax * ajax to update the draft page for FPC to create guidelines * ajax to forward summary email to devel-announce * ajax to email lists when all updates in place * nirik * nirik to dig in archives for fesco-as-sponsor background and report next week * sgallagh * sgallagh to talk to virt people about dnsmasq * **UNASSIGNED** * remaining four packages (iscsi, dnsmasq, openvpn, wpa_supplicant) targeted for conversion by beta People Present (lines said) --- * ajax (81) * nirik (59) * Viking-Ice (47) * sgallagh (28) * notting (26) * pjones (23) * mjg59 (17) * mmaslano (15) * zodbot (7) * t8m (0) * cwickert (0) --- 17:01:26 ajax #startmeeting FESCO (2011-08-07) 17:01:26 zodbot Meeting started Mon Aug 8 17:01:26 2011 UTC. The chair is ajax. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:26 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:26 ajax #meetingname fesco 17:01:26 zodbot The meeting name has been set to 'fesco' 17:01:27 ajax #chair ajax notting nirik cwickert mjg59 mmaslano t8m pjones sgallagh 17:01:27 zodbot Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m 17:01:27 ajax #topic init process 17:01:36 mmaslano hello 17:01:36 * nirik waves. Morning folks. 17:01:37 * sgallagh waves 17:02:00 ajax only people missing by my count are cwickert and t8m, assuming people aren't just idling 17:02:14 mmaslano t8m is on vacation 17:02:47 notting i'm here. have to leave a few minutes before 2pm, though 17:02:55 ajax no worries, should be quite quick today 17:03:22 ajax well, we've got quorum, let's dive in. 17:03:27 ajax #topic #563 suggested policy: all daemons must set RELRO and PIE flags 17:03:27 ajax .fesco 563 17:03:28 zodbot ajax: #563 (suggested policy: all daemons must set RELRO and PIE flags) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/563 17:03:51 ajax i just sent a small novel to devel@ outlining how this will all work 17:03:54 ajax http://lists.fedoraproject.org/pipermail/devel/2011-August/155358.html 17:04:02 * pjones is here 17:04:06 nirik great work ajax. 17:04:16 nirik clear and nice. ;) You might also send a copy to devel-announce? 17:04:31 ajax i got to learn far too much about two different languages, both called spec. i would like to forget. 17:04:36 sgallagh ajax: One thing just occurred to me about that. There's a lot of combined requirement between rpm, redhat-rpm-config and gcc. Might it not be wise to get them all into the same bodhi update? 17:04:53 ajax nirik: good idea, will do 17:05:20 notting any plans to backport? 17:05:34 pjones please no. 17:05:35 *
New hardened build support (coming) in F16
tl;dr version: If you have a security-sensitive package, and wish to
enable some gcc-level hardening features with a modest performance
impact, you will soon be able to enable them (nearly) automagically by
rebuilding with this line in your spec file:
%define _hardened_build 1
Now for the details.
* 1: what are we trying to do?
There are three somewhat-overlapping build features in play here. The
first one is called relro, which instructs the linker to emit some
relocations in a special segment that can be marked read-only after
relocation processing is finished but before you call into main(). Or
in English: more things that you've asked to be const, will actually be
const. This on its own is quite cheap, and so it has been enabled
globally as of redhat-rpm-config-9.1.0-13.fc16.
By default, not all symbols are resolved that early in program
execution. In particular, functions are resolved lazily the first time
they're called. This makes startup faster, and since not all functions
are actually called in typical program execution, usually makes total
execution time faster. However, if all symbols were resolved early, the
relro feature could do a better job, and virtually all relocations could
be made read-only. The '-z now' flag to the linker makes this happen,
and an app so linked is said to be Full RELRO instead of Partial RELRO.
Finally, applications may be built as position-independent executables,
by passing -fPIC or -fPIE at build time and -pie at link time. This
allows the runtime linker to randomize the placement of the executable
at runtime, which makes it more difficult for an attacker to guess the
address of writeable memory.
* 2: how do we go about doing it?
The non-PIE parts of this are trivial, just pass the appropriate flags
to the linker and you're done. PIE is more difficult, both at build
time and at link time. Although both -fPIC and -fPIE produce
position-independent code at the assembly level, -fPIE will (at least on
amd64) produce relocation types that are only valid in an executable.
This means you can't just say -fPIE in CFLAGS: your libraries will fail
to link. (PIC objects in a PIE executable are fine; PIE objects in a
PIC library are not. When in doubt, -fPIC.)
Likewise, at link time, the -pie and -shared options are mutually
exclusive. ld.gold will simply refuse to execute if you specify both.
ld.bfd will (afaict) let whichever one comes last win, and if that
happens to be -pie when you're building a shared library it will fail to
link because it won't be able to find a _start symbol.
All of this is only an issue because most build systems don't let you
say different CFLAGS or LDFLAGS for shared libraries and executables. Sigh.
So instead, we'll teach gcc to figure it out. To do this we'll use the
-specs flag to pass some rewrite rules to the compiler driver. At
compile time, if we don't see -fPIC or -fPIE on the command line, we'll
add -fPIC. At link time, if we don't see -shared, we'll add -pie. This
way we build relocatable objects that are always suitable for either
type of final link object, and we'll only attempt to build a PIE if we
know we're not building a shared library. Victory!
* 3: what does this mean for you?
The link-time bit of the last paragraph required a bit of gcc magic to
get right (previously specs rules could only add strings to the command
line of the program to invoke; they could not rewrite gcc's notion of
which flags had been passed in the first place). Thanks to a patch from
Jakub Jelinek, this is now fixed in gcc-4.6.1-7.fc16, and will be in gcc
4.7 and later. As a result, %defined _hardened_build 1 will not work
until that gcc update has gone through.
Once that's done (and redhat-rpm-config-9.1.0-15.fc16 has been gone
through updates), if you're using a %configure-style spec file, defining
the magic macro is all you have to do. The rpm macros will notice the
macro, and put the right magic into CFLAGS and LDFLAGS, and everything
is great and wonderful.
If you're _not_ using %configure, then you have to do whatever is
conventional for your build system to get CFLAGS and LDFLAGS inherited
properly. For CFLAGS, this will be $RPM_OPT_FLAGS or %{optflags} as
before. As of rpm-4.9.1-3.fc16, you will be able to say $RPM_LD_FLAGS
for the corresponding LDFLAGS values. Until then, there is no such
shell variable, but you can get the same effect from
%{?__global_ldflags}. Yes, that's ugly, sorry.
If you are the owner of one of the packages listed here:
https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_flags
Then I have locally built (though not extensively tested) your package
with the appropriate specfile modifications, and the results do indeed
appear to be fully hardened. If you would like to handle the rebuilds
yourself, please let me know. Otherwise I will submit them myself once
the relevant updates have gone through.
If you've
Re: New hardened build support (coming) in F16
On 8/8/11 3:52 PM, Till Maas wrote: On Mon, Aug 08, 2011 at 12:23:43PM -0400, Adam Jackson wrote: %define _hardened_build 1 just wondering: Is %define really correct here or does it need to be %global? I've been using %define out of habit, but either one works. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Tue, 2011-08-09 at 08:47 -0400, Steve Grubb wrote: My main concern is that the macro will be misapplied and overall performance will take a hit. That's a valid concern, but any hardened build would have this problem. I'm happy to talk about how the performance impact can be mitigated, but it seems unfair to blame a convenience macro for being convenient. I don't know how a macro can tell the intent of an application as it links it. There has not been a chmod so that it knows this is setuid and needs more protection. Sure, but you can't possibly know suid-ness until %files time anyway. I was not attempting to enforce a policy here. I was attempting to make applying hardened build flags easy in the common case. This isn't an excuse for not using one's brain as a packager. I had hoped I had made that clear, and I did not intend to imply that this was the _only_ way to get a hardened build, but I apologize for being insufficiently precise. For example, if coreutils was built with this (and coreutils seems to be correct as is) because it has setuid programs, then would all apps get the PIE/Full RELRO treatment? If so, many of coreutils apps are called constantly by shell scripts. Yes, they would. coreutils might not be a suitable target for this flag. That's okay, coreutils is welcome to customize its build using something other than this convenience macro. If this were used on tcpdump, would full relro leak to the libpcap? I'm not sure why you raise this concern in this particular context, since the semantics would be the same regardless of this macro. But since this detail is worth expanding on, let's ask the dynamic linker what happens. Prelink makes this harder than you might hope, but if I'm reading the scrolls right, LD_USE_LOAD_BIAS=0 effectively turns it off, and LD_DEBUG=reloc will show us the steps in relocation processing. So what does a normal execution look like? % LD_USE_LOAD_BIAS=0 LD_DEBUG=reloc /bin/ls /dev/null | grep reloc 6762: relocation processing: /lib64/libattr.so.1 (lazy) 6762: relocation processing: /lib64/libpthread.so.0 (lazy) 6762: relocation processing: /lib64/libdl.so.2 (lazy) 6762: relocation processing: /lib64/libc.so.6 6762: relocation processing: /lib64/libacl.so.1 (lazy) 6762: relocation processing: /lib64/libcap.so.2 (lazy) 6762: relocation processing: /lib64/librt.so.1 (lazy) 6762: relocation processing: /lib64/libselinux.so.1 (lazy) 6762: relocation processing: /bin/ls (lazy) 6762: relocation processing: /lib64/ld-linux-x86-64.so.2 Note that libc and ld.so are not described as lazy. This is because they have been linked with -z now: % eu-readelf -a /lib64/libc.so.6 | grep BIND_NOW FLAGS BIND_NOW STATIC_TLS % eu-readelf -a /lib64/ld-linux-x86-64.so.2 | grep BIND_NOW BIND_NOW What if we were to force the issue? % LD_BIND_NOW=1 LD_USE_LOAD_BIAS=0 LD_DEBUG=reloc /bin/ls /dev/null | grep reloc 6766: relocation processing: /lib64/libattr.so.1 6766: relocation processing: /lib64/libpthread.so.0 6766: relocation processing: /lib64/libdl.so.2 6766: relocation processing: /lib64/libc.so.6 6766: relocation processing: /lib64/libacl.so.1 6766: relocation processing: /lib64/libcap.so.2 6766: relocation processing: /lib64/librt.so.1 6766: relocation processing: /lib64/libselinux.so.1 6766: relocation processing: /bin/ls 6766: relocation processing: /lib64/ld-linux-x86-64.so.2 Cool, looks like that does what we would expect. But does the environment variable have a different effect than if the executable itself were marked DT_BIND_NOW? Well, let's try with a program that _is_ already -z now: % eu-readelf -a /usr/bin/ssh | grep BIND_NOW BIND_NOW % LD_USE_LOAD_BIAS=0 LD_DEBUG=reloc /usr/bin/ssh -V | grep reloc 6790: relocation processing: /lib64/libpthread.so.0 (lazy) 6790: relocation processing: /lib64/libkeyutils.so.1 (lazy) 6790: relocation processing: /lib64/libkrb5support.so.0 (lazy) 6790: relocation processing: /lib64/libfreebl3.so (lazy) 6790: relocation processing: /usr/lib64/libsasl2.so.2 (lazy) 6790: relocation processing: /lib64/libnspr4.so (lazy) 6790: relocation processing: /lib64/libplc4.so (lazy) 6790: relocation processing: /lib64/libplds4.so (lazy) 6790: relocation processing: /usr/lib64/libnssutil3.so (lazy) 6790: relocation processing: /usr/lib64/libnss3.so (lazy) 6790: relocation processing: /usr/lib64/libsmime3.so (lazy) 6790: relocation processing: /usr/lib64/libssl3.so (lazy) 6790: relocation processing: /lib64/libc.so.6 6790: relocation processing: /lib64/libcom_err.so.2 (lazy) 6790: relocation processing: /lib64/libk5crypto.so.3 (lazy) 6790:
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, 2011-08-09 at 10:44 -0400, Colin Walters wrote: See attached. Looks fine to me. The only reason I have to dislike it is the temptation for people to inspect build logs as a proof of what flags a package was built with (since the only sane thing is to store that in the binary itself, which the tools team is working on). But for debugging build failures this is great. You appear to be in provenpackagers, as far as I'm concerned feel free to commit. Also, props for using the devel list as a development list. I've had an off-list request for exposing just the hardening bits of the rpm macros as their own variables (to make it easier to build part of a package hardened, ie the coreutils case), so I'll probably be spinning another update to redhat-rpm-macros soon anyway. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, 2011-08-09 at 19:19 +0200, Jan Kratochvil wrote: On Tue, 09 Aug 2011 19:14:27 +0200, Adam Jackson wrote: If you're volunteering to fix and/or paper over all the spurious warnings gcc and glibc introduce with every phase of the moon, then sure. Yes, I do it for my component, GDB has -Werror default in development phases upstream. It cleans up the code, it finds various minor bugs etc. I didn't say for your component. Otherwise -Werror would essentially mean never shipping anything ever again. So the maintainers either care about the warnings - and then they should use -Werror - or they do not care about the warnings - and then it does not matter regarding warning messages which and how many of them can be found on the Koji server in the log files. Please decide. I wasn't arguing for or against finding warnings. I was commenting on the ability to see build failures. Admittedly, you were initially responding to Colin, not myself. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
On 8/12/11 12:28 PM, Matthew Garrett wrote: On Fri, Aug 12, 2011 at 05:25:17PM +0100, Bryn M. Reeves wrote: Third party code built against -devel and depending only on the SONAME is fine in this situation as it sticks to the published ABI. In-tree code that plays with non-ABI symbols will break and so may need a stricter dep. It is in this situation, but there are other situations where depending on the SONAME will cause breakage. If libfoo 1.1 adds a new symbol, anything built against it may fail to run against libfoo 1.0. But how will you know that in advance if all you have in your dependencies is the SONAME? In fairness, this is why rpm elaborates soname dependencies to also include symbol versions. It's a pity that symbol versions are so painful to use that really only glibc makes any effort to do it. Hilariously gcc _does_ let you specify symbol version in a __attribute__ tag, but only on HP/UX on ia64. Thanks for that. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On 8/13/11 2:23 PM, Jim Meyering wrote: I'd start with -O2 -D_FORTIFY_SOURCE=2 and something like this subset of -Wall: -Warray-bounds -Wchar-subscripts -Wsequence-point gcc now has: -Werror= Make the specified warning into an error. The specifier for a warning is appended, for example -Werror=switch turns the warnings controlled by -Wswitch into errors. This switch takes a negative form, to be used to negate -Werror for specific warnings, for example -Wno-error=switch makes -Wswitch warnings not be errors, even when -Werror is in effect. There's quite a few warnings we could reasonably promote to errors like this. FESCO would be happy to listen to a proposal for such, if anyone feels like doing the research. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Attention: F16 packages needing rebuilds due to the trailing slash bug of rpm-4.9.1
On 8/17/11 5:51 AM, Panu Matilainen wrote:
Hi all,
Due to the brown paperbag bug of rpm-4.9.1 causing unwanted trailing
slashes on directories (with various nasty side-effects), the following
packages in F16 require rebuilding. The sooner the better to stop
spreading the damage but at any rate, before F16 final:
Of the affected packages, the following already have a newer build in
f16-updates-pending, meaning they've been through bodhi and are just
waiting for the alpha to be pushed out:
filesystem-2.4.44-1.fc16
freetype-2.4.6-1.fc16
ibus-1.3.99.20110419-14.fc16
quagga-0.99.18-8.fc16
rb_libtorrent-0.15.7-1.fc16
rubygem-foreigner-1.1.1-1.fc16
soprano-2.7.0-1.fc16
squid-3.2.0.10-1.fc16
sugar-turtleart-113-1.fc16
volumeicon-0.4.1-3.fc16
The following have a newer build in f16-updates-testing, meaning an
update is in bodhi but (if not also in the list above) has not yet been
pushed to stable:
accountsservice-0.6.13-2.fc16
akonadi-1.6.0-4.fc16
askbot-0.7.17-1.fc16
audacious-3.0.1-1.fc16
audacious-plugins-3.0.1-1.fc16
BackupPC-3.2.1-1.fc16.1
chkconfig-1.3.54-2.fc16
couchdb-1.0.3-2.fc16
cvs-1.11.23-21.fc16
device-mapper-multipath-0.4.9-18.fc16
ecryptfs-utils-90-1.fc16
filesystem-2.4.44-1.fc16
freetype-2.4.6-1.fc16
ibus-1.3.99.20110419-14.fc16
isdn4k-utils-3.2-79.fc16
libgcrypt-1.5.0-2.fc16
libibverbs-1.1.5-5.fc16
matahari-0.4.2-1.fc16.1
ntp-4.2.6p3-5.fc16.1
openldap-2.4.26-1.fc16.1
openpts-0.2.5-2.fc16
opensm-3.3.9-2.fc16
qemu-0.15.0-0.3.201108040af4922.fc16
qpid-cpp-0.10-4.fc16.1
qt3-3.3.8b-36.fc16.1
quagga-0.99.18-8.fc16
rb_libtorrent-0.15.7-1.fc16
rubygem-foreigner-1.1.1-1.fc16
soprano-2.7.0-1.fc16
squid-3.2.0.10-1.fc16
sugar-turtleart-113-1.fc16
thunderbird-5.0-3.fc16
transmission-2.33-1.fc16.1
volumeicon-0.4.1-3.fc16
xen-4.1.1-3.fc16
xine-ui-0.99.6-27.fc16.1
Note, however, that I've not checked which version of rpm these were
built with.
For reference, to build these lists, copy Panu's original list to a file
and (for updates-testing):
for i in $(cat panu-list) ; do
j=$(koji -q latest-pkg f16-updates-testing $(rpmname $i) | \
awk '{ print $1 }')
rpmdev-vercmp $i $j /dev/null
[ $? == 12 ] echo $j
done
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Attention: F16 packages needing rebuilds due to the trailing slash bug of rpm-4.9.1
On 8/17/11 10:41 AM, Adam Jackson wrote:
for i in $(cat panu-list) ; do
j=$(koji -q latest-pkg f16-updates-testing $(rpmname $i) | \
awk '{ print $1 }')
rpmdev-vercmp $i $j /dev/null
[ $? == 12 ] echo $j
done
I left out an important step here:
rpmname() {
echo $1 | rev | cut -f 3- -d - | rev
}
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Attention: F16 packages needing rebuilds due to the trailing slash bug of rpm-4.9.1
On Wed, 2011-08-17 at 15:50 -0500, Jeffrey Ollie wrote: On Wed, Aug 17, 2011 at 10:50 AM, Eric Sandeen sand...@redhat.com wrote: (aside: when sending lists of rpms like this, it sure would be nice to also include the maintainer name, so I could just search for me and know if I have an issue) ;) This seems to happen a lot - does someone have a script that could be fed a list of packages and would then do the necessary magic to reformat the list to include the packager names? Having something like that in the Fedora packaging tools would be awesome. You're in luck! % pkgdb-cli acl bash devel Fedora Package Database -- bash The GNU Bourne Again shell 29 bugs open (new, assigned, needinfo) devel Owner: rrakus watchbugzilla watchcommitscommit approveacls Group: provenpackagerApproved Comaintainer(s): maxamillion ApprovedApproved kasal Approved rrakusApprovedApprovedApprovedApproved Last build: 2011-07-29 by rrakus for bash-4.2.10-5.fc17 in dist-rawhide % rpm -qf `which pkgdb-cli` packagedb-cli-1.1.0-1.fc15.noarch - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Attention: F16 packages needing rebuilds due to the trailing slash bug of rpm-4.9.1
On Thu, 2011-08-18 at 07:37 -0400, Kaleb S. KEITHLEY wrote: On 08/17/2011 05:51 AM, Panu Matilainen wrote: Hi all, Due to the brown paperbag bug of rpm-4.9.1 causing unwanted trailing slashes on directories (with various nasty side-effects), the following packages in F16 require rebuilding. The sooner the better to stop spreading the damage but at any rate, before F16 final: ... cloudfs-0.7-4.fc16.src.rpm I'm not really sure what's being asked for here. cloudfs was obsoleted and removed from Fedora SCM two days before this email, so I'm not sure it's warranted, or even possible to rebuild it; not without jumping though a lot of hoops. No problem, just ignore this then. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to debug X lockup (advice from gurus wanted)
On 9/1/11 5:05 PM, Roberto Ragusa wrote: Hmmm, turning off SMP is not realistic, as this laptop has a Core 2 Duo. Sure it is. Boot with maxcpus=1 on the kernel command line. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Best practices for patch management on RPM based packages?
On Tue, 2011-09-06 at 09:16 -0500, Richard Shaw wrote: Most of the packages I work with have very few patches so it's not all that difficult, but there are a couple of packages I'm working with that have a lot of patches and one of them has a very active upstream (which is a good thing!) but that also means that the patches need frequent adjustment. I like the idea of quilt but I can't seem to find the magic recipe to get it to integrate with rpmbuild. If your upstream is using git, there's some boilerplate for automating this with git-am in xorg-x11-server.spec. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum-builddep (Re: Compiling 32bit on 64bit Fedora)
On Thu, 2011-09-08 at 10:44 +1000, Tony Breeds wrote: Hi All, On a related but different note. How hard would it be to get yum-builddep to take an --arch arg to that we can esily get the 32-bit builddeps on a 64-bit system? Is 'setarch i686 yum-builddep foo' not enough? - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On 9/20/11 9:19 AM, Ralf Corsepius wrote: Currently I only see mails of maintainers who plan updating the library, but the rest of it pretty much depends on the maintainers of the depending components rebuilding them quickly enough, and the original maintainer to include them in the F-16 branched update. I'd like to see a discussion about how we can ensure -- within reasonable limits -- that e.g. bumping a library's SONAME is followed by dependent components being rebuilt and included with the providing component in one update. I'd like to see a discussion on the proceedures currently being applied by QA, esp. during freezes. IMO, they are unsuitable and harmful. I'd like to see a rationale for jamming a soname-changing update into the OS so close to a release. In the absence of a very good motivation, that's not good engineering practice, and it's not consistent with the feature process. Perhaps you're not clear on what the word freeze means. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On 9/20/11 10:13 AM, Ralf Corsepius wrote: On 09/20/2011 04:03 PM, Adam Jackson wrote: I'd like to see a rationale for jamming a soname-changing update into the OS so close to a release. Maintainers on vacation, non-trivial changes? In my case, a major change was introduced into rawhide many weeks ago, which had caused breakage in rawhide. One maintainer being involved was in vacation, another one was non-responsive. That sounds like the kind of upheaval I'd want to keep out of a release that's in its stabilization phase. Ca. 4 weeks later the issues were resolved in rawhide and we started to propagate these changes to f16 and where caught by the delay queues. Of course, you had the option of not pulling the new OpenSceneGraph back to F16, or simply not doing so yet. Particularly during a phase where people are trying to keep change to a minimum so we know what we're working with. I'm sorry that you don't understand release engineering, but since you insist on not understanding it I don't really have any sympathy for your packages being so visibly at fault for breakages. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On 9/20/11 11:43 AM, Nils Philippsen wrote: On Tue, 2011-09-20 at 11:33 -0400, Adam Jackson wrote: Of course, the accounts system _still_ doesn't have groups, five years later, so provenpackager is the big hammer we have. We could get groups any day now, that'd be just fine. Do you mean groups of groups, like in provenpackager-kde, provenpackager-gnome, and provenpackager means all of these? I don't see any real reason to do that instead of just unix-style groups, but either one would be an improvement. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On Thu, 2011-09-22 at 20:05 +0200, Jakub Jelinek wrote:
%rename cc1_options rh_cc1_options_old
*cc1_options:
%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIC} %(rh_cc1_options_old)
That looks just wrong. -fpie/-fPIE is in general faster than -fpic/-fPIC,
because it can assume (non-weak) symbols defined in the object can't be
overridden. Without hardening, objects compiled without
-fpie/-fPIE/-fpic/-fPIC assume that too (and additionally are position
dependent), so I fail to see why you'd want to default to -fPIC. You
certainly want to default to -fPIE.
You can't default to -fPIE because at cc1 time you don't know whether
the object is destined for a DSO or not, -fPIE will produce relocations
that aren't legal in DSOs, and ld isn't awesome enough to convert them
for you.
Although, one could probably argue that if it were going to be in a DSO,
it'd have -fPIC already present. If we're willing to accept that, then
sure.
- ajax
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On Thu, 2011-09-22 at 20:22 +0200, Jakub Jelinek wrote: Such packages would be broken and would fail to link without hardening or at least have text relocations too. Packagers shouldn't rely on this spec hack to fix up their packaging bugs (or upstream bugs), the hack should be just about changing position dependent binaries in the executable into position independent binaries. Entirely fair. I'll rebuild r-r-c to reflect this. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FESCO meeting agenda for 2011 Oct 3
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #663 Late F16 Feature Java7 .fesco 663 #topic #667 Request to fix CRITPATH update process .fesco 667 #topic #671 Packages packaging yum repo files? .fesco 671 = New business = None. = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 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/fesco, 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. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 - font point sizes now scaled?
On 10/3/11 11:43 AM, Jan Kratochvil wrote: On Mon, 03 Oct 2011 17:34:45 +0200, Bastien Nocera wrote: I'm not sure how we can make DPI magically be correct in gazillions of broken displays' EDID. If not blacklisting then whitelisting them, you have the community. This is X.org's task, though. Speaking as Xorg: No, we don't. You have _no_ idea how many displays there are. There's nothing like effective coverage to be had here. More to the point, your DPI numbers would be per-output anyway, so there's no picking a single point size preference, the same size in pixels would be different sizes in millimeters on each output. You can't win at this. Don't try. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes from today's FESCO meeting (2011-10-03)
=== #fedora-meeting: FESCO (2011-10-03) === Meeting started by ajax at 17:00:30 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-10-03/fesco.2011-10-03-17.00.log.html . Meeting summary --- * init process (ajax, 17:00:30) * #663 Late F16 Feature Java7 (ajax, 17:01:51) * ACTION: ajax to follow up with rel-eng (ajax, 17:05:04) * #667 Request to fix CRITPATH update process (ajax, 17:06:03) * AGREED: critpath package rules to be modified per sgallagh's proposal above (ajax, 17:14:09) * ACTION: nirik to file bodhi ticket for critpath change (ajax, 17:15:45) * #671 Packages packaging yum repo files? (ajax, 17:16:18) * ACTION: mjg59 to close out #671 per last week's discussion (ajax, 17:17:31) * Next week's chair (ajax, 17:18:18) * ACTION: t8m to chair next week's meeting (ajax, 17:19:00) * Open Floor (ajax, 17:19:05) * ACTION: mjg59 to get data on proven/normal karma on updates (ajax, 17:38:24) Meeting ended at 17:43:37 UTC. Action Items * ajax to follow up with rel-eng * nirik to file bodhi ticket for critpath change * mjg59 to close out #671 per last week's discussion * t8m to chair next week's meeting * mjg59 to get data on proven/normal karma on updates Action Items, by person --- * ajax * ajax to follow up with rel-eng * mjg59 * mjg59 to close out #671 per last week's discussion * mjg59 to get data on proven/normal karma on updates * nirik * nirik to file bodhi ticket for critpath change * t8m * t8m to chair next week's meeting * **UNASSIGNED** * (none) People Present (lines said) --- * ajax (54) * mjg59 (41) * nirik (36) * t8m (32) * sgallagh (27) * pjones (14) * drago01 (13) * notting (13) * dledford (11) * zodbot (8) * mmaslano (6) * gholms (3) * cwickert (0) --- 17:00:30 ajax #startmeeting FESCO (2011-10-03) 17:00:30 zodbot Meeting started Mon Oct 3 17:00:30 2011 UTC. The chair is ajax. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:30 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:30 ajax #meetingname fesco 17:00:30 ajax #chair ajax notting nirik cwickert mjg59 mmaslano t8m pjones sgallagh 17:00:30 ajax #topic init process 17:00:30 zodbot The meeting name has been set to 'fesco' 17:00:30 zodbot Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m 17:00:40 * nirik is around. 17:00:44 pjones hello. 17:01:13 * notting is here 17:01:14 * sgallagh is here more or less (busy day) 17:01:17 mjg59 Here (obv) 17:01:22 mmaslano hi 17:01:46 ajax right, that's enough for quota, let's dive in. 17:01:51 ajax #topic #663 Late F16 Feature Java7 17:01:53 ajax .fesco 663 17:01:54 zodbot ajax: #663 (Late F16 Feature Java7) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/663 17:02:22 nirik this is pending the rebuild of some packages. 17:02:27 mjg59 Yeah 17:02:39 mjg59 Given there's a rel-eng ticket I guess it'll be done 17:02:41 nirik Hopefully dgilmore can get to it later this week... he's been traveling/at fucon/getting beta done. 17:03:28 ajax do we need someone to keep an eye on this or shall we assume rel-eng is on the job? 17:03:56 mmaslano did rel-eng promised to do it? 17:03:58 nirik we can leave it on the agenda but defer? 17:04:34 ajax mmaslano: well, no, but nobody promises to do anything. 17:04:47 ajax i'll poke rel-eng on the ticket, we'll come back next week. 17:05:04 ajax #action ajax to follow up with rel-eng 17:05:18 ajax anything else on this? 17:05:33 t8m Hi, I'm sorry for being late 17:05:49 * nirik has nothing more on this topic 17:05:52 ajax t8m: np, didn't miss much yet 17:05:59 ajax next up 17:06:03 ajax #topic #667 Request to fix CRITPATH update process 17:06:03 ajax .fesco 667 17:06:05 zodbot ajax: #667 (Request to fix CRITPATH update process) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/667 17:06:22 t8m heh, now the fun begins :) 17:06:23 nirik so, should we revisit the timeout proposal? or is everyone set on their votes? 17:06:30 * sgallagh continues to be in favor of the Allow it after two weeks if there is no negative karma 17:06:44 * t8m too 17:06:49 * mmaslano too 17:06:55 * nirik is also +1 for that. I think toshio's reasoning made sense. 17:07:11 mjg59 I don't think there's any new reasoning 17:07:22 ajax mjg59: i don't think there is either 17:07:43 pjones no reason to think anything has changed. 17:07:47 ajax i'm going to +1 that as well just so i can stop hearing about this 17:07:50 mjg59 If this needs to be fixed then we need to fix it properly 17:08:15 t8m If I count right this means +5 now? 17:08:15 nirik mjg59: yes, but in the mean time we are frustrating maintainers and our users... 17:08:15 ajax i don't disagree 17:08:17 mjg59 Rather than just satisfying the noisiest (and I don't mean that in a bad way) people without
Why EDID is not trustworthy for DPI
On Tue, 2011-10-04 at 11:46 -0400, Kaleb S. KEITHLEY wrote:
Grovelling around in the F15 xorg-server sources and reviewing the Xorg
log file on my F15 box, I see, with _modern hardware_ at least, that we
do have the monitor geometry available from DDC or EDIC, and obviously
it is trivial to compute the actual, correct DPI for each screen.
I am clearly going to have to explain this one more time, forever.
Let's see if I can't write it authoritatively once and simply answer
with a URL from here out. (As always, use of the second person you
herein is plural, not singular.)
EDID does not reliably give you the size of the display.
Base EDID has at least two different places where you can give a
physical size (before considering extensions that aren't widely deployed
so whatever). The first is a global property, measured in centimeters,
of the physical size of the glass. The second is attached to your (zero
or more) detailed timing specifications, and reflects the size of the
mode, in millimeters.
So, how does this screw you?
a) Glass size is too coarse. On a large display that cm roundoff isn't
a big deal, but on subnotebooks it's a different game. The 11 MBA is
25.68x14.44 cm, so that gives you a range of 52.54-54.64 dpcm horizontal
and 51.20-54.86 dpcm vertical (133.4-138.8 dpi h and 130.0-139.3 dpi v).
Which is optimistic, because that's doing the math forward from knowing
the actual size, and you as the EDID parser can't know which way the
manufacturer rounded.
b) Glass size need not be non-zero. This is in fact the usual case for
projectors, which don't have a fixed display size since it's a function
of how far away the wall is from the lens.
c) Glass size could be partially non-zero. Yes, really. EDID 1.4
defines a method of using these two bytes to encode aspect ratio, where
if vertical size is 0 then the aspect ratio is computed as (horizontal
value + 99) / 100 in portrait mode (and the obvious reverse thing if
horizontal is zero). Admittedly, unlike every other item in this list,
I've never seen this in the wild. But it's legal.
d) Glass size could be a direct encoding of the aspect ratio. Base EDID
doesn't condone this behaviour, but the CEA spec (to which all HDMI
monitors must conform) does allow-but-not-require it, which means your
1920x1080 TV could claim to be 16 cm by 9 cm. So of course that's
what TV manufacturers do because that way they don't have to modify the
EDID info when physical construction changes, and that's cheaper.
e) You could use mode size to get size in millimeters, but you might not
have any detailed timings.
f) You could use mode size, but mode size is explicitly _not_ glass
size. It's the size that the display chooses to present that mode.
Sometimes those are the same, and sometimes they're not. You could be
scaled or {letter,pillar}boxed, and that's not necessarily something you
can control from the host side.
g) You could use mode size, but it could be an encoded aspect ratio, as
in case d above, because CEA says that's okay.
h) You could use mode size, but it could be the aspect ratio from case d
multiplied by 10 in each direction (because, of course, you gave size in
centimeters and so your authoring tool just multiplied it up).
i) Any or all of the above could be complete and utter garbage, because
- and I really, really need you to understand this - there is no
requirements program for any commercial OS or industry standard that
requires honesty here, as far as I'm aware. There is every incentive
for there to _never_ be one, because it would make the manufacturing
process more expensive.
So from this point the suggestion is usually well come up with some
heuristic to make a good guess assuming there's some correlation between
the various numbers you're given. I have in fact written heuristics
for this, and they're in your kernel and your X server, and they still
encounter a huge number of cases where we simply _cannot_ know from EDID
anything like a physical size, because - to pick only one example - the
consumer electronics industry are cheap bastards, because you the
consumer demanded that they be cheap.
And then your only recourse is to an external database, and now you're
up the creek again because the identifying information here is a
vendor/model/serial tuple, and the vendor can and does change physical
construction without changing model number. Now you get to play the
guessing game of how big the serial number range is for each subvariant,
assuming they bothered to encode a serial number - and they didn't. Or,
if they bothered to encode week/year of manufacturer correctly - and
they didn't - which weeks meant which models. And then you still have
to go out and buy one of every TV at Fry's, and that covers you for one
market, for three months.
If someone wants to write something better, please, by all means. If
it's kernel code, send it to dri-de...@lists.freedesktop.org and cc me
and I will happily review it.
Re: Why EDID is not trustworthy for DPI
On Tue, 2011-10-04 at 21:03 +0100, Camilo Mesias wrote: Hi, On Tue, Oct 4, 2011 at 6:54 PM, Adam Jackson a...@redhat.com wrote: I am clearly going to have to explain this one more time, forever. Let's see if I can't write it authoritatively once and simply answer with a URL from here out. (As always, use of the second person you herein is plural, not singular.) Thanks for the explanation... There is an alternative to endless explanation - roll out your best effort at a heuristic and let the crowd contribute to an ever growing set of exceptions. I think you missed the part where I said I already had done so, that you're already running them, and that I take patches. I think building the giant database for DPI is a losing battle, and I don't intend to work on it myself. The bright line for the kernel's current quirks list has so far been that we take quirks for fixing mode setup, only. Ancillary data like physical size just isn't something the kernel needs to know. But if people do insist on it, there's some points of implementation that really should be considered, and I'm happy to discuss them. Overriding EDID is a subtle problem once you get past wanting to make just one permanently-connected display work on one machine. If the future being designed looks like play with this complicated expert tool until it works for you then that's not really finished solving the problem. The next person who uses a sufficiently similar monitor with the same set of EDID problems should never have to touch that tool. How people use that information is entirely not my concern. I have an opinion and it's probably wrong in some cases and I am neither advocating nor defending any such choices here. I'm just here to tell you that the hardware _is_ out to get you, and that the current behaviour is in fact a considered choice and not simply willful malice. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 beta vice Knoppix
On Tue, 2011-10-04 at 23:45 +0200, Lennart Poettering wrote: Another bigger source of slowness at boot is currently Plymouth which also requires synchronous settling of devices (tough it's not as bad as LVM in that regard though, but costs too since EDID probing is apparently quite slow, and has every right to, but right now we delay the boot processes for that but we shoudl really do that in the background). It's much slower than it needs to be. As of last time I looked there's still cases where a) we're using full EDID fetch as a proxy for connected-or-not, instead of just a zero-length I2C read, and b) we're not prefetching and caching EDID on hotplug interrupts, instead fetching it every time it's asked for. Even given all that, we should try the faster I2C speeds first and fall back to slower. And we're not. Might or might not be able to fix all that up for F16 gold, but it's on the todo list somewhere. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Tue, 2011-10-04 at 19:05 -0700, Adam Williamson wrote: 96dpi, however, is almost *never* correct, is it? So just taking a hardcoded number that Microsoft happened to pick a decade ago is hardly improving matters. The X default used to be 72dpi. Maybe it'll be something else in the future, and then I can get bitched at more for having changed it yet again by people still using a fundamentally unreliable API. It still seems to me that taking the EDID number if it seems reasonably plausible and falling back to 96dpi otherwise is likely a better option. I reiterate: X gives you the actual sizes (as best as we can guess) on the RANDR outputs. The global size that we default to 96dpi is broken to rely on in any event, because X simply has no mechanism for updating it besides reconnecting to the display. We could add a request to re-fetch the connection handshake block, but if you're going to update all your apps to use that request, you might as well update all your apps to use the existing RANDR's geometry information instead. If the UI wants to be sensitive to DPI, then do me the favor of using the DPI numbers that map 1:1 to actual monitors, instead of a single number that can never be an accurate reflection of reality. Your examples lean a lot on TVs and projectors, but are those really the key use cases we have to consider? What about laptops and especially tablets, whose resolutions are gradually moving upwards (in the laptop case despite the underlying software problems, in the tablet case because the underlying software doesn't have such a problem)? Is it really a great idea, for instance, if we put Fedora 17 on a 1024x600, 7 tablet and it comes up with zonking huge fonts all over the place? I'm going to not mention the traditional monitors I've seen with bad EDID. I'm going to not mention the laptops I've seen that report 0x0 physical size, or something non-zero and fictitious. I'm going to not mention the laptops where you simply don't get EDID, you get some subset buried in the video ROM, and you get to hope that it might have physical size encoded in it. I'm going to not mention that DPI is only approximately what you want anyway, and that you actually need to know dots per unit arc, which is a function of both display size and view distance. I'm going to simply quote myself from another message in this thread: How people use this information is entirely not my concern. My job is to get the pixels on the screen; it might be to try valiantly to tell you how big they are; it is not to decide if they're big enough. I think it's worth considering that, even though Microsoft's crappiness with resolution independence has probably hindered the market artificially for a while, the 96dpi number which comes from the capabilities of CRT tubes circa 1995 bears increasingly little resemblance to the capabilities of modern displays, and assuming we can just keep hardcoding 96dpi and monitor technology will remain artificially retarded forever is likely not a great thing to do. I don't believe that was a position I was defending. I would caution you against thinking that there's some DPI revolution right around the corner. That's the same fallacy that rages against the TV industry for stalling at 1080p. Linear increases in DPI are quadratic increases in link bandwidth, and maxed-out single-link DVI (the source of the 1080p limit) is already a higher symbol rate than gigabit ethernet. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Wed, 2011-10-05 at 23:11 +0200, Benny Amorsen wrote: Matthew Garrett mj...@srcf.ucam.org writes: We have no technological solution for dealing with the fact that applications may move from one DPI to another at runtime, and may even be displaying on both displays at once. From a technology viewpoint, that is actually theoretically easy to handle on modern hardware: Render everything as 3D objects and let the graphics hardware scale as appropriate. Your use of the word theoretically reveals much. You would almost certainly be appalled by just how much geometry information is necessary to render a single glyph. Which is why we - and Windows, and OSX - don't do that. When you ask for a glyph at a given transformation matrix, it gets rasterized down to an A8 mask, and we reuse those from then on. (Okay, it's A8R8G8B8 if you're doing subpixel antialiasing). That's the only way you get anything like acceptable performance. If it were easy, we'd already be doing it. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, 2011-10-06 at 11:14 -0400, Jon Masters wrote: On Tue, 2011-10-04 at 13:54 -0400, Adam Jackson wrote: EDID does not reliably give you the size of the display. How about EDID as it exists today. Since you're able to so beautifully explain what the pitfalls are, I'd assume you've raised this with the VESA and asked that they revisit this in the future to accurately provide DPI information that Operating Systems can rely on? Given that successive revisions of the spec have gone out of their way to make it acceptable for displays to provide _less_ useful information, on the grounds of manufacturing cost reduction, I think the momentum is quite in the other direction. More pragmatically, VESA are not the people with any influence here. The only thing that matters to a monitor vendor is what Windows does when you plug it in. Linux can stamp its little foot all it wants. No one will care. If you want to be a big enough player in that market to have some influence, you have to start by playing in the sandbox that's already built, and in that sandbox physical dimensions are just not reliable and never will be. Cope. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BEWARE: a problematic glibc made it to stable (F16)
On Wed, 2011-10-19 at 20:35 -0400, Josh Boyer wrote: Except that Fedora _has_ been glibc's development platform for as long as I can remember. The Fedora project might not think so, but it's exactly what upstream glibc does. Indeed, this has been the case since it was still called Red Hat Linux. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: convert init.d to systemd, how to determine which python is installed
On Thu, 2011-11-03 at 10:10 -0400, Kaleb S. KEITHLEY wrote:
HekaFS runs a daemon from init. It's a Bottle (python-based) http server.
In order to work on, e.g. RHEL6 in addition to Fedora, the old init
script has:
...
vercmd=from distutils.sysconfig import get_python_lib; print
get_python_lib()
py_dir=$(python -c ${vercmd})
exe=${py_dir}/hekafsd.py
...
I'd kinda like to preserve that in some fashion in the new systemd
service file. Not to run on RHEL6 obviously, but to be future-proof
against the day when python2.8 or python3.x ships in F17 or later or
RHEL7, e.g.
Generate the actual systemd service file at rpmbuild time. Something
like this maybe, if you're using the standard magic for
%{python_sitelib}:
Source1: hekafs.service.in
...
sed s/@PYTHON_SITELIB@/%{python_sitelib}/ %{SOURCE1}
$RPM_BUILD_ROOT/lib/systemd/system/hekafs.service
- ajax
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Buildroot override problem
On Thu, 2011-11-03 at 09:14 -0600, Jerry James wrote: I have 2 new packages. The first one, flocq, has been in F16 testing for 5 days. It is needed to build the second one, gappalib-coq. I go to the BuildRoot override page to submit an override for flocq. After typing in flocq, it offers me flocq-1.4.0-2.fc16, which is wrong. That version had a mistake in the spec file that renders it unusable. Why doesn't it offer me flocq-1.4.0-3.fc16, which is the version in testing? I would guess because it's only considering packages in -updates-candidate as buildroot override candidates, and -3 is in -updates-testing. No matter. I manually edit the requested override to -3 instead of -2. After pushing the button to submit, I get this message: Error: buildroot override for u'flocq-1.4.0-3.fc16' already exists What's with the u before the package name? That's just Python letting you know that Unicode is a thing it does badly. And what does it mean that a buildroot override already exists? I'd guess that's a cascade failure from above: it's not going to create a BR-override if it thinks that a newer package already exists in the buildroot. It certainly sounds like a series of bugs in bodhi though. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F17 heads up: gnome-shell for everyone!
As of tomorrow's rawhide [1], gnome-session will no longer treat llvmpipe as an unsupported driver. This means gnome-shell will run even on hardware without a native 3D driver, including virt guests. There are probably bugs! I've done some quick tests on the hardware I have handy and in kvm, and things do appear to work. You, lucky contestant, might have a different experience. If you do, bugzilla is standing by and ready to take your call; please file against the 'mesa' component and set me as the assignee. In the meantime you can still get to fallback mode through the Graphics section of the System Info control panel. Very little performance work has been done on this yet - like, literally, none - though there are some things you can do [2]. Outside of virt you will probably want to tell your driver to use ShadowFB in xorg.conf. This will disable hardware acceleration, but in exchange you won't be doing very slow GetImages all the time to get textures loaded into the compositor. In virt, however, the double-buffering done by ShadowFB just slows you down, so you're probably best off switching your driver to NoAccel instead. The vesa driver should get this right for you already, as should cirrus under virt. Beyond that, most of the performance work is going to require new kernel and Mesa features. For details, please see: https://fedoraproject.org/wiki/Features/Gnome_shell_software_rendering If you're interested in contributing to this effort, please follow up on dri-de...@lists.freedesktop.org. [1] - In particular, you'll need these packages or newer for things to work: mesa-*-7.11-9.fc17 cogl-1.8.2-4.fc17 gnome-session-3.3.1-2.fc17 [2] - It's something of a policy decision to get some of these things right by default, because you're deciding to throw away hardware accel on old chips, and some people who aren't using gnome-shell might think that's worth keeping. We'll figure something out, I'm sure, but contributions are most welcome. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
On 10/26/11 12:32 PM, Jared K. Smith wrote: On Wed, Oct 26, 2011 at 11:47 AM, Richard W.M. Jonesrjo...@redhat.com wrote: https://fedorahosted.org/fesco/ticket/682 I've made another attempt to reach out the the glibc maintainer directly again this morning to hopefully answer the questions in that ticket as soon as possible, and remind him of the seriousness of the situation. I'll update the ticket if I hear anything. So, how's that coming along? - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 heads up: gnome-shell for everyone!
On Mon, 2011-11-07 at 10:11 -0500, Martin Langhoff wrote: For now let's say yes, but that's more like implementation detail than fundamental property. Clutter'd be perfectly happy atop a GLES renderer, we just don't have that wired up. Ok -- that doesn't sound so terrible. Are there concrete plans to wire it up? I guess? It sort of depends what the support story for those chips looks like: who provides the GLES and EGL libraries, what their ABI looks like, whether it's feasible to compile against Mesa's implementation but use another at runtime... None of which has a real answer just yet, I don't think. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 heads up: gnome-shell for everyone!
On Mon, 2011-11-07 at 14:55 +, Peter Robinson wrote: Details of rawhide builds for them here[1], the XO-1 build isn't tested but the XO 1.5 one works fine, I'll be testing further and likely the next build I do I'll add all the components to test the llvmpipe feature on them. Don't freak out if it doesn't seem like it works. Somehow between F16 and rawhide we're managing to change LLVM's behaviour for allocating memory in the JIT, such that selinux puts the smack down. I'm working on it, but in the meantime, enforcing=0 if you want to try it. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: why do I need colord?
On 11/8/11 12:09 PM, Michał Piotrowski wrote: 2011/11/8 Richard Hugheshughsi...@gmail.com: 2011/11/7 Michał Piotrowskimkkp...@gmail.com: Out of curiosity I wanted to ask, why do I need colord on my system? Checkout http://www.freedesktop.org/software/colord/ for details about the project. I know what colord is intended for and I think this is really cool for desktop. I began to wonder why do I need it on my machine, because this system has no lcd panel attached - I'm accessing it through ssh. Printers and scanners have color spaces too. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: why do I need colord?
On 11/8/11 1:08 PM, Peter Robinson wrote: Yea, but a lot of people don't have those either. I have around 5K servers in DCs with not a single printer or scanner in site. The vast majority of the 4 million odd XOs out there while they have a screen don't have a printer or scanner anywhere in sight. On a server like that, you won't have cups installed, so nothing will be pulling in colord. Whereas if you _do_ have cups installed, because it's a print server, then you might like very much for the colors in the image on the screen to match the colors deposited on the paper. On an XO all colord pulls over baseline Gnome is sane-backends-libs and lcms2, and even that's guessing, I'd be a little surprised if those didn't end up in the image already. I guess there's an argument to be had over whether that 1M of disk space is really worth spending on enabling color-accurate image editing on an XO, but that's really for OLPC to decide for their image. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: why do I need colord?
On 11/8/11 1:59 PM, Peter Robinson wrote:
On Tue, Nov 8, 2011 at 6:53 PM, Adam Jackson a...@redhat.com wrote:
On a server like that, you won't have cups installed, so nothing will be
pulling in colord. Whereas if you _do_ have cups installed, because it's a
print server, then you might like very much for the colors in the image on
the screen to match the colors deposited on the paper.
Until LSB gets updated you often do get it pulled in though (and a lot
of GUI stuff as well) unfortunately.
I assume don't install LSB compatibility crap isn't an option for some
reason. Sigh. Bad standards sure are bad, aren't they.
Its a lot more than 1Mb, and its something we constantly have to fight
to keep the dependencies sane.
$ rpm -q --qf=%{size}\n colord lcms2 sane-backends-libs | awk 'BEGIN {
i=0 } { i += $1 } END { print i }'
1049219
As ARM ramps up and people get more and
more interested in running gnome on fedora on all sorts of tablet and
similar devices with small amounts of storage it will receive more and
more attention I suspect.
My frustration with the small footprint crowd in general is that (and
I mean no personal offense, this is an imprecise gun I'm shooting with)
they seem unwilling or unable to do more work to achieve their footprint
targets than can be accomplished with configure flags.
To pick a favorite whipping boy, the 'pth' library is one of those
wonderful false-economy-of-portability things to give you something
vaguely like a thread library on OSes that don't have threads. You
would think there'd be no reason for this on Linux. But no, gnupg2
links against it instead of pthreads because that's More Portable, in
the clever definition of the phrase that means equally burdensome
everywhere. So now it's on every machine, because yum requires gnupg2.
Why would you argue against 1M of useful functionality but not attempt
to excise 250k of dead weight?
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New build of fedpkg (fedora-packager) coming to updates-testing / rawhide
On Tue, 2011-11-01 at 17:04 -0700, Jesse Keating wrote: Please test these updates and let me know if all is good, or if you have other issues. Bodhi karma, email, IRC, smoke signal, just let me know. [ajax@f17 fedora]$ fedpkg co xorg-x11-server Could not execute clone: must be type, not classobj [ajax@f17 fedora]$ rpm -q fedpkg fedpkg-1.5-1.fc17.noarch - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F17 heads up: X server git snapshots
I'm currently rebuilding the X stack for F17, and we'll be tracking git snapshots of the X server and drivers until xserver 1.12 comes out. I don't know yet how many of the drivers will ftbfs now, so --skip-broken might be your friend for a while. Binary and out-of-tree driver users will want to configure yum.conf to exclude xorg-x11-\* until their drug of choice catches up. I've changed the way we expose ABI versions in rpm. Builds of upstream releases will look like this: $ rpm -q --provides xorg-x11-server-Xorg | grep abi xserver-abi(ansic-0) = 4 xserver-abi(extension-6) = 0 xserver-abi(videodrv-11) = 0 xserver-abi(xinput-13) = 0 But git snapshots will look like: $ rpm -qp --provides xorg-x11-server-Xorg-1.11.99.1-1.2009.fc17.x86_64.rpm | grep abi xserver-abi(ansic-2009) = 0 xserver-abi(extension-2009) = 0 xserver-abi(videodrv-2009) = 0 xserver-abi(xinput-2009) = 0 This is a bit excessive - essentially binding drivers to exactly the server they were built against - but it should prevent the problems we had in the F16 cycle of silent ABI changes between xserver builds causing drivers to crash. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 heads up: X server git snapshots
On Wed, 2011-11-09 at 16:14 -0500, Adam Jackson wrote: I'm currently rebuilding the X stack for F17, and we'll be tracking git snapshots of the X server and drivers until xserver 1.12 comes out. I don't know yet how many of the drivers will ftbfs now, so --skip-broken might be your friend for a while. Binary and out-of-tree driver users will want to configure yum.conf to exclude xorg-x11-\* until their drug of choice catches up. I've also changed the default driver set in comps for F17, we now install a common set of drivers by default and the -drivers metapackage is moved to optional. For details: http://git.fedorahosted.org/git/?p=comps.git;a=blobdiff;f=comps-f17.xml.in;h=ebec67888172bcc0adda3746e9c66112a1924d8c;hp=68f5af988ffb1893e500659e81753a40448adcb9;hb=ef08f6af6c48745c5028ed1432ce81833842c97a;hpb=03c1ae7d6479da7f6941b763498bcb4fea648870 - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 heads up: X server git snapshots
On Mon, 2011-11-14 at 06:48 -0500, Mystilleef wrote:
Hello,
Wow, I read this a little too late. I did an update, using
--skip-broken, today and now Xorg is broken. I use the open source ati
drivers. The Xorg log indicates a version mismatch between Xorg and
the drivers. Is there a way to reverse or fix this?
Get the list of X packages you have installed, download the F16 builds
of same from koji, and downgrade to them. Something like this perhaps:
$ rpm -qa --qf=%{name}\n xorg-x11-\* | xargs -n 1 koji download-build
--latestfrom=f16-updates --arch=$(arch)
$ sudo rpm -Uvh --oldpackage xorg-x11-*$(arch).rpm
Probably there's a way to achieve the same thing that won't end with yum
complaining about the rpmdb being modified behind its back, but meh.
- ajax
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A small request
On Mon, 2011-11-14 at 16:44 +, Paul Johnson wrote: What I'm thinking is that if (say) xorg-x11 is built, the drivers also get built to ensure the likes of the ABI problem I've hit doesn't happen I understand the desire, yes. I was expressing surprise that I hadn't adequately guarded you from desiring it. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gdbm license change
On Mon, 2011-11-14 at 18:18 +0100, Honza Horak wrote: Hi, GNU database indexing library (gdbm) has changed its license to GPLv3+. A quick scan says this affects: avahi-ui-tools (LGPLv2) gnu-smalltalk (GPLv2+ with exceptions) jpilot-backup (GPLv2+) libguestfs (LGPLv2+) librep (GPLv2+) man-db (GPLv2+ and GPLv3+) perl (unholy) perl-XML-LibXSLT (GPL+ or Artistic) q (GPLv2+) ruby-libs ((Ruby or GPLv2) and (GPL+ or Artistic)) ypserv (GPLv2) - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gdbm license change
On Mon, 2011-11-14 at 20:46 +0200, Ville Skyttä wrote: On 11/14/2011 07:57 PM, Adam Jackson wrote: On Mon, 2011-11-14 at 18:18 +0100, Honza Horak wrote: Hi, GNU database indexing library (gdbm) has changed its license to GPLv3+. A quick scan says this affects: [...] ypserv (GPLv2) This one looks like an incompatibility. Without going into details (in that I haven't read the source or the licenses in detail, just the GPL compatibility matrix) those are _all_ likely incompatibilities. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Unannounced ABI bump in rawhide: quvi
quvi 0.4.0 is both an ABI and API break. See the rawhide report for details. Nicoleau, please remember to announce changes that may affect others: https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaned packages
On Tue, 2011-11-29 at 11:28 +0100, Michal Nowak wrote: I've just orphaned following packages: * xcb-util Taken. Thanks for looking after it! - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: updating xcb-util to 0.3.8 in rawhide?
On Mon, 2011-11-28 at 23:38 +0100, Lars Seipel wrote: Hi there, is it possible to update rawhide's xcb-util to the current version which was released earlier this year? I've taken ownership of xcb-util, and submitted a build for 0.3.8. The following packages depend on it in F17: boinc-manager-0:6.12.35-1.r24014svn.fc17.i686 i3-0:4.0.1-2.fc17.i686 startup-notification-0:0.12-1.fc16.i686 xorg-x11-drv-intel-0:2.17.0-2.fc17.i686 xorg-x11-utils-0:7.5-4.fc17.i686 I'll kick rebuilds for these momentarily. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for today's FESCo meeting (2011-12-05)
Following is the list of topics that will be discussed in the FESCo meeting today at 18:00UTC (1:00pm EST) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #689 Consider including bash-completion package by default (base, not core) .fesco 689 #topic #699 Proposal to remove the package tzdata from Critical Path .fesco 699 = New business = #topic #711 F17 Feature: virtio-scsi - http://fedoraproject.org/wiki/Features/virtio-scsi .fesco 711 #topic #712 need update kBuild on F15 .fesco 712 #topic #713 F17 Feature: KDE Plasma Dependency Generation and PackageKit Integration - http://fedoraproject.org/wiki/Features/Plasma_PackageKit_Integration .fesco 713 = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 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/fesco, 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. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?
On Fri, 2011-11-04 at 13:12 -0400, Tom Lane wrote: I did test rebuilds in mock of all rawhide packages that are reported to be dependent on libpng. Out of 964 packages with dependencies on libpng, we have: Packages that rebuilt successfully with 1.5 658 Packages that FTBFS for non-libpng reasons186 Packages that rebuilt with 1.4, but not 1.5 74 Packages that need help even with 1.4 46 I've been doing driveby rebuilds for some of these that happen to have been in a default install on my machine, but we still have a huge pile of things built against the old libpng in rawhide: [ajax@f17 cairomm]$ repoquery --whatrequires libpng-compat | wc -l 786 Does anyone object to me just kicking a mass rebuild for this? I'll happily follow up with the list of build failures. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes from today's FESCO meeting (2011-12-05 at 1800 UTC)
=== #fedora-meeting: FESCO (2011-12-05) === Meeting started by ajax at 18:01:03 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-12-05/fesco.2011-12-05-18.01.log.html . Meeting summary --- * init process (ajax, 18:01:11) * #689 Consider including bash-completion package by default (base, (ajax, 18:03:40) * AGREED: No action needed on bash-completion ticket, follow up in bugzilla with any remaining issues. (ajax, 18:05:43) * #699 Proposal to remove the package tzdata from Critical Path (ajax, 18:06:08) * ACTION: notting to follow up on pkgdb changes (ajax, 18:08:08) * #711 F17 Feature: virtio-scsi - http://fedoraproject.org/wiki/Features/virtio-scsi (ajax, 18:09:02) * AGREED: virtio-scsi feature is approved (ajax, 18:09:58) * #712 need update kBuild on F15 (ajax, 18:10:18) * LINK: http://fpaste.org/F0wh/ lkundrak recent activity (pingou, 18:17:56) * AGREED: attempt to follow up with lkundrak on the ticket; if no response by next week have a provenpackager do it (ajax, 18:18:38) * #713 F17 Feature: KDE Plasma Dependency Generation and PackageKit Integration - http://fedoraproject.org/wiki/Features/Plasma_PackageKit_Integration (ajax, 18:19:05) * AGREED: plasma packagekit integration feature is approved (ajax, 18:20:00) * FES tickets (ajax, 18:20:22) * #713 F17 Feature: KDE Plasma Dependency Generation and PackageKit Integration - http://fedoraproject.org/wiki/Features/Plasma_PackageKit_Integration (ajax, 18:20:23) * FES tickets (ajax, 18:20:36) * LINK: https://fedorahosted.org/fedora-engineering-services/report/6 (ajax, 18:20:47) * open floor (ajax, 18:23:21) * ACTION: ajax to mass-rebuild for libpng (ajax, 18:30:01) * next meeting's chair (ajax, 18:32:32) * ACTION: notting to chair next week's meeting (ajax, 18:33:07) Meeting ended at 18:34:43 UTC. Action Items * notting to follow up on pkgdb changes * ajax to mass-rebuild for libpng * notting to chair next week's meeting Action Items, by person --- * ajax * ajax to mass-rebuild for libpng * notting * notting to follow up on pkgdb changes * notting to chair next week's meeting * **UNASSIGNED** * (none) People Present (lines said) --- * ajax (68) * notting (21) * nirik (17) * mmaslano (12) * mjg59 (11) * cwickert (11) * zodbot (10) * t8m (10) * pjones (8) * sgallagh (7) * abadger1999 (6) * pingou (2) --- 18:01:03 ajax #startmeeting FESCO (2011-12-05) 18:01:03 zodbot Meeting started Mon Dec 5 18:01:03 2011 UTC. The chair is ajax. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:03 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:11 ajax #meetingname fesco 18:01:11 zodbot The meeting name has been set to 'fesco' 18:01:11 ajax #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones sgallagh 18:01:11 zodbot Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m 18:01:11 ajax #topic init process 18:01:16 * notting is here 18:01:19 mjg59 Here 18:01:19 * sgallagh is here 18:01:22 mmaslano hi 18:01:24 t8m Hello 18:01:28 * pjones is here 18:01:36 * nirik is here 18:01:37 * cwickert is here 18:01:55 ajax hey, that's all of us! 18:01:59 cwickert is this the last meeting of this FESCo? 18:02:16 ajax i believe so. the current elections end today. 18:02:21 nirik yep. 18:02:52 sgallagh So... last chance to make bad decisions that the new guys have to deal with :) 18:03:13 notting all in favor of switching to netbsd? 18:03:26 pjones sgallagh: we have a(n un)fortunate amount of continuity to avoid that happening 18:03:31 ajax notting: no way, man. plan9 is the future. 18:03:39 ajax let's dive in then 18:03:40 ajax #topic #689 Consider including bash-completion package by default (base, 18:03:40 ajax not core) 18:03:40 ajax .fesco 689 18:03:41 zodbot ajax: #689 (Consider including bash-completion package by default (base, not core)) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/689 18:04:14 nirik we already decided this, and It seems it was in fact already done before then. 18:04:27 nirik proposal: close? 18:04:28 ajax yeah, this looks like it's just a bugzilla issue at this point. 18:04:36 sgallagh +1 to close 18:04:36 t8m yeah 18:04:41 t8m +1 to close 18:04:49 notting please do close. 18:04:53 mmaslano +1 18:05:08 cwickert t+1 18:05:14 ajax #action No action needed on bash-completion ticket, follow up in bugzilla with any remaining issues. 18:05:18 ajax er 18:05:27 ajax what's the undo verb? 18:05:32 nirik #undo 18:05:32 zodbot Removing item from minutes: MeetBot.items.Action object at 0x2bb74a10 18:05:38 ajax thx 18:05:43 ajax #agreed No action needed on bash-completion ticket, follow up in bugzilla with any remaining issues. 18:06:08 ajax #topic #699 Proposal to remove the package tzdata from Critical
Re: cgit instead of gitweb?
On Fri, 2010-07-30 at 12:41 +0530, Rahul Sundaram wrote: Hi Any particular reason we are using gitweb at http://pkgs.fedoraproject.org/gitweb/. Cgit is used in freedesktop.org is much more faster and resource efficient. With my fd.o hat on: Our experience with cgit hasn't been completely trouble-free either, it seems to get stuck sometimes feeding you old cached data. If we insist on running gitweb we should at least consider running warthog's branch (the version that kernel.org uses): http://git.kernel.org/?p=git/warthog9/gitweb.git;a=summary - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: local / scratch builds with fedpkg
On Tue, 2010-08-03 at 15:06 +0100, David Woodhouse wrote:
$ i386 fedpkg local --arch=i686
...
+ ./configure --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --program-prefix=
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib
--mandir=/usr/share/man --infodir=/usr/share/info --disable-gtk-doc
--enable-static --with-runtime-libdir=../../lib
'i386 fedpkg mockbuild' should work, although that's not what you asked
for.
$ fedpkg scratch-build
Traceback (most recent call last):
File /usr/bin/fedpkg, line 959, in module
args.command(args)
File /usr/bin/fedpkg, line 573, in scratchbuild
build(args)
File /usr/bin/fedpkg, line 319, in build
url, chain)
File /usr/lib/python2.6/site-packages/pyfedpkg/__init__.py, line
797, in build
raise FedpkgError('There are unpushed changes in your repo')
pyfedpkg.FedpkgError: There are unpushed changes in your repo
% fedpkg scratch-build --help
usage: fedpkg scratch-build [-h] [--nowait] [--background]
[--arches [ARCHES [ARCHES ...]]] [--srpm SRPM]
optional arguments:
-h, --helpshow this help message and exit
--nowait Don't wait on build
--background Run the build at a lower priority
--arches [ARCHES [ARCHES ...]]
Build for specific arches
--srpm SRPM Build from srpm
I suspect --srpm is what you're looking for.
- ajax
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intel 82Q35 / framebuffer problem
On Fri, 2010-08-06 at 22:18 +0200, Jos Vos wrote: On Fri, Aug 06, 2010 at 03:26:16PM -0400, Adam Jackson wrote: intel-...@lists.freedesktop.org would be the place to go for this. As a guess, you've got LVDS attached over SDVO and we screwed that up again. I'm happy to do that, but I hope you don't mind that in the meantime I'll also file a bug against RHEL6 (and there dmesg output looks even more scary). Should such a bug then be filed against xorg-x11-drv-intel? Yeah. Furthermore, given your guess, would there be a workaround? Not really. FWIW, I also see: [drm] set up 7M of stolen space [drm:intel_init_bios] *ERROR* VBT signature missing [drm] failed to find VBIOS tables This is almost certainly the root of the problem. We don't try to set up SDVO devices if they're not listed in the VBT, but not having a VBT means nothing's gonna be listed. We'll need the output from: # dd if=/dev/mem of=/tmp/rom bs=64k skip=12 count=1 - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intel 82Q35 / framebuffer problem
On Fri, 2010-08-06 at 23:12 +0200, Jos Vos wrote: On Fri, Aug 06, 2010 at 04:41:33PM -0400, Adam Jackson wrote: This is almost certainly the root of the problem. We don't try to set up SDVO devices if they're not listed in the VBT, but not having a VBT means nothing's gonna be listed. We'll need the output from: # dd if=/dev/mem of=/tmp/rom bs=64k skip=12 count=1 Should I attach it to the bug? In what format? Preferably as a series of bytes. (To be clear, the output from that command is the resulting /tmp/rom file, not the 1+0 records in/out message on stdout.) - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vesa-mode Anaconda install
On Wed, 2010-08-11 at 08:20 -0700, Bob Arendt wrote: If support for text mode installation is dead (or dying), recent traffic on the test develop list indicates that there's still a strong need to have a fall-back installation mode. Just in case the your particular version of Radeon, NVidia, (.. whatever) hardware is recognized but doesn't run correctly. Perhaps having a simple vesa arg to anaconda to force a vesa Xserver would provide a quick and simple work-around. It seems like this might be a simple hack to add to anaconda. A short-hand for xdriver=vesa nomodeset should do this. The KMS X driver should fail to bind and then we should fall back to vesa naturally. If we don't it's an X driver bug. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14/F13 - system-config-display - should it work?
On Thu, 2010-08-12 at 15:00 -0400, Felix Miata wrote: EDID DDC are mere conveniences unnecessary to the function of the device. I really couldn't care less whether EDID/DDC exists, much less works. What matters (works just fine) from a display, which may have been manufactured before the invention of DDC or EDID, is its output qualities. DDC1 was spec'd in 1994. Version 3.0 of the DDC standard, which included the I²C-based DDC2 protocol that most drivers implement, was released in 1997; I'm reasonably sure it was also documented in Version 2 of that standard, which appears to have been 1995 or so according to light googling for press releases. (DDC1 was a remarkable botch that involved overclocking the vertical sync pulse and using that to transfer data. Ek.) The oldest (instance of the minimal) CPU architecture we support is the Pentium Pro, which was also 1995. I'm touched by your concern for such antiquarian hardware, but I'm quite comfortable saying it's not a design goal to work on hardware that's now old enough to get a driver's license. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14/F13 - system-config-display - should it work?
On Thu, 2010-08-12 at 15:13 -0400, Felix Miata wrote: For the benefit of those few, and there will likely always be some, for whom automatic isn't, some tool is needed upstream in Xorg, possibly SaX2 or SCD at least as a starting point. A wider call for a maintainer of SaX2 or SCD or some equivalent is needed. But how and where? X believes this to be the job of the DE. We're not in the business of making sample applications beyond the server itself. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Fri, 2010-08-13 at 12:43 -0500, Chris Adams wrote: Once upon a time, Kevin Kofler kevin.kof...@chello.at said: I tried many things, even running for FESCo and getting voted in. As you can see, it didn't achieve anything either. Is it impossible for you to accept the fact that not everybody agrees with you on the direction of Fedora, and that maybe (just maybe) you are in the minority? Yes. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
On Fri, 1994-08-19 at 16:22 +0200, Kevin Kofler wrote: I want none of that useless crap, thank you very much! Applications should be written as applications, delivered through our package repository, in a compiled language. Web sites should just be web sites and have as little code as possible (ideally none). The web is a medium for information, not code. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Javascript JIT in web browsers
On Thu, 2010-08-19 at 15:01 -0400, Brandon Lozza wrote: If we tolerate any non free software then what's the point? Why not just run Windows or OSX? Received: from mail-fx0-f45.google.com (mail-fx0-f45.google.com [209.85.161.45]) by smtp-mm1.fedoraproject.org (Postfix) with ESMTP id B7DB887E64 for devel@lists.fedoraproject.org; Thu, 19 Aug 2010 19:01:22 + (UTC) Message-id: aanlktimahm2rzxx47g1furnm=tzuzutxjfrw5kvus...@mail.gmail.com - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Mon, 2010-08-23 at 15:48 -0400, Jon Masters wrote: On Mon, 2010-08-23 at 20:37 +0100, Matthew Garrett wrote: Given the degree to which sysadmins are religious about MTA choice, I'd suspect that a large proportion of people who run an MTA on Fedora are probably already swapping it out with their own preference. I don't think it's realistic to expect us to provide a product that requires no further configuration for server admins, so adding Install an MTA to the list of things they have to do is entirely reasonable. I agree that most admins do swap out the MTA (I always install exim). I just wanted to share that I consider there is some value in providing one by default, even if it is one that won't please everyone. I /think/ I'd rather have to remove sendmail and replace it than have none at all. Current experience with VM images seems to indicate that server people ideally have a system that comes with very little more than coreutils, and build a kickstart for anything more complicated than that. If you want to provide an I don't care pick one template for mailserver images, awesome. But in general, if you _intend_ to send mail, you're opinionated enough to pick your own, at which point all that providing a default does is make the post-install transaction slower. Put another way: I don't think you really think that. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase OK on Fedora git branches?
On Tue, 2010-08-24 at 14:43 +0100, Richard W.M. Jones wrote: Is it OK to use 'git rebase -i' to compress my mistakes together into a single working Fedora git commit? (Provided I don't push things in between or otherwise try to rewrite public history) Yes. I'm a bit confused by whether 'fedpkg commit', 'fedpkg build', 'fedpkg push' etc are doing magic that will be broken by this. Not really. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Tue, 2010-08-24 at 08:45 -0400, Matthias Clasen wrote: On Mon, 2010-08-23 at 23:06 -0400, Bill Nottingham wrote: BOOTUP - System boots successfully to GUI, when configured. - System boots successfully to text mode, when configured. - System properly handles being passed [1-5], 'single', 'S', 's', '-s', booting to the appropriate 'runlevel' (0 and 6 can still work, but they're sort of pointless anyway) When booted in this manner, '5' will bring up a GUI, and '3' will not. You mean 'being passed on the kernel cmdline', I assume ? Do we consider interactive boot essential (I think not) ? Should mention something about forced fsck, maybe. What about selinux relabeling ? I can't remember interactive boot ever working. PLYMOUTH - plymouth is shown on startup. - plymouth is quit correctly. - plymouth is shown on shutdown. - 'esc' to show details still functions in plymouth. - an equivalent to /var/log/boot.log still exists, and is populated (can be normal syslog) - plymouth transition from grub - boot - X is seamless for KMS cards, similar to Fedora 13. Note that this is currently broken (somewhere in X, not systemd's fault at all). Depends on the driver, but yeah. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaned package: system-config-display
I don't have time for it, and I think it's fundamentally misguided. If someone else feels like owning it, go wild. This will probably also require access to the upstream repo, so, do speak up if you take it so we can sort that out. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaned package: system-config-display
On Thu, 2010-08-26 at 01:43 +0530, Rahul Sundaram wrote: On 08/26/2010 01:22 AM, Adam Jackson wrote: I don't have time for it, and I think it's fundamentally misguided. If someone else feels like owning it, go wild. This will probably also require access to the upstream repo, so, do speak up if you take it so we can sort that out. Assuming noone picks it up, we will have to document this in the release notes. Can you give a brief explanation on why you believe it is misguided for the sake of documentation? Static configuration should be something you can do from the dynamic configuration tool. gnome-display-properties should have a set as default button. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaned package: system-config-display
On Thu, 2010-08-26 at 19:59 +0200, Kevin Kofler wrote: Adam Jackson wrote: Static configuration should be something you can do from the dynamic configuration tool. gnome-display-properties should have a set as default button. Uh… 1. Not everyone uses GNOME. Demonstrably true, but I don't see how it's relevant. 2. What about systemwide settings? (system-config-display did those.) That's what static configuration means. 3. What if you can't bring up X in the first place? (You can't run gnome- display-properties if you can't get into X. system-config-display --reconfig was a way to fix such problems.) That sometimes worked and mostly didn't. Seems like a better use of time would be in making X not fail to launch in the first place. Sounds like you enjoy working on bandaids though! Perhaps you'd like to take over s-c-d maintainership? - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaned package: system-config-display
On Thu, 2010-08-26 at 15:59 -0400, Arthur Pemberton wrote: On Thu, Aug 26, 2010 at 3:49 PM, Adam Jackson a...@redhat.com wrote: On Thu, 2010-08-26 at 19:59 +0200, Kevin Kofler wrote: Adam Jackson wrote: Static configuration should be something you can do from the dynamic configuration tool. gnome-display-properties should have a set as default button. Uh… 1. Not everyone uses GNOME. Demonstrably true, but I don't see how it's relevant. You suggested `gnome-display-properties`, which is a gnome tool with gnome package dependencies. I can respond to this on at least two levels. I guess I'll do both. (Throughout, I'm using you in the second person, and am not referring to Arthur or anyone else in particular.) So on the one level, you can feel free to read gnome-display-properties there as a placeholder for whatever the equivalent tool is in your DE of choice. lxrandr or krandrtray or whatever. I mean, that's the tool that one uses to configure display settings memory within the session, so it makes sense to serialize from that - from the state of okay I got it the way I want it - to xorg.conf. But on the other level, the implication is that Fedora as a project is somehow compelled to provide generic, desktop-agnostic ways of accomplishing this kind of task. Which is a futile endeavor, philosophically, since s-c-d involved pulling in all of pygtk to begin with, and if you've got a toolkit phobia up front then I don't really see why gtk would be acceptable but libgnome-desktop wouldn't. And moreover it's inevitably wasted effort since every DE of any worth _will_ eventually have a competent display config tool. Now maybe you disagree with that second point. Maybe you _do_ think Fedora has that obligation. Great! By all means, please pick up s-c-d and run with it. I'm just saying, I'm done with it, and I think it's a bad solution regardless of which DE you're using. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaned package: system-config-display
On Mon, 2010-08-30 at 22:13 -0700, Adam Williamson wrote: (Is it actually impossible for the vesa driver to work after KMS has kicked in, btw, or is it just something that doesn't work at present?) Right now, it may work or it may not. Typically the vesa bios assumes it's the only thing that's ever touched the card [1]. Loading a KMS driver usually changes some hardware settings that the bios treats as invariants. So, you could load vesa, and it might appear to work for a while, but it might also not work at all, or anything in between. It might work better if you unloaded the KMS driver and had it program the hardware back to its initial state on unload. But even then you're hoping you reset everything the bios cares about correctly. So to be safe, we just don't let you do that. [1] - Windows XP and earlier only ever use vesa services to set the mode for the initial boot splash. So that's typically _exactly_ as reliable as vesa services ever are: one modeset, probably to 1024x768 or 800x600, iff you've never loaded a native driver, and anything after that is a gamble. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: font dependency packaging question
On Tue, 2010-08-31 at 20:58 -0700, Carl Byington wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a package (ghemical) which requires a courier 12 font for use in its xwindow gui. I clearly need some dependency that will drag in xorg-x11-fonts-ISO8859-1-100dpi or xorg-x11-fonts-ISO8859-1-75dpi but those probably depend on the actual user's display resolution. What is the appropriate 'requires' for the .spec file? Just do 100dpi. The 75dpi fonts are a mistake. The renderer assumes 96dpi for the most part anyway. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-09-14)
On Mon, 2010-09-13 at 13:42 -0600, Kevin Fenzi wrote: Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 19:30UTC (3:30pm EDT) in #fedora-meeting on irc.freenode.net. Apologies, I won't be able to make this, I'll be on a plane headed to France for XDS. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, 2010-09-22 at 22:21 +0200, Till Maas wrote: This here sounds strange: | The update rate for any given release should drop off over time, | approaching zero near release end-of-life; since updates are primarily | bugfixes, fewer and fewer should be needed over time. This essentially says that after 12 or 18 months all software in Fedora is bug free and does not need any updates. This is a very strange assumption. E.g. why do we stop supporting the software after it became totally stable? IMHO this claim cannot reasonably be made. There is a difference between stable and bug free. Known limitations are preferable to moving targets. Again: if we kept updating everything to the very latest thing all the time, why even bother doing releases. Everyone would just run rawhide. Right? - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Thu, 2010-09-23 at 08:39 +0200, Till Maas wrote: On Wed, Sep 22, 2010 at 04:45:30PM -0400, Adam Jackson wrote: On Wed, 2010-09-22 at 22:21 +0200, Till Maas wrote: This here sounds strange: | The update rate for any given release should drop off over time, | approaching zero near release end-of-life; since updates are primarily | bugfixes, fewer and fewer should be needed over time. This essentially says that after 12 or 18 months all software in Fedora is bug free and does not need any updates. This is a very strange assumption. E.g. why do we stop supporting the software after it became totally stable? IMHO this claim cannot reasonably be made. There is a difference between stable and bug free. Known limitations are preferable to moving targets. It says updates are primarily bugfixes, fewer and fewer should be needed over time, why are less bugfixes needed unless because there are less bugs? It does not say anything about packages becoming stable. I have real trouble parsing this paragraph. Say you ship with 50 bugs in a package. As you update it through the lifetime of a release, that number should decrease more or less monotonically. The bugs that take longest to fix are presumably the hardest ones to fix, and thus the ones that either require significant rewrites (and become out of scope for an update release), or won't get fixed at all. So it's really just describing what _happens_ naturally if you don't rebase all the time. I mean, imagine if it said the reverse: Updates within a release should be very rare initially, and become more frequent as the OS approaches end of life. That's pretty clearly insane. That would imply that the older a release got, the less predictable it would become. That's exactly what we don't want. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Thu, 2010-09-23 at 12:18 +0200, Thorsten Leemhuis wrote: On 22.09.2010 22:45, Adam Jackson wrote: Again: if we kept updating everything to the very latest thing all the time, why even bother doing releases. Everyone would just run rawhide. Right? No, because with rawhide you get alpha and beta code. But updating everything to the very latest thing all the time would mean: User get what those that know the software best (upstream developers) suggest their users to use(¹) -- that sounds like a really good idea to me ;-) No, that's not what the words very latest mean. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Sat, 2010-09-25 at 15:13 +0200, Till Maas wrote: On Thu, Sep 23, 2010 at 09:48:34AM -0400, Adam Jackson wrote: Say you ship with 50 bugs in a package. As you update it through the lifetime of a release, that number should decrease more or less monotonically. The bugs that take longest to fix are presumably the hardest ones to fix, and thus the ones that either require significant rewrites (and become out of scope for an update release), or won't get fixed at all. So it's really just describing what _happens_ naturally if you don't rebase all the time. The bug number will probably decrease, but this does not meant that the lifetime of a release is long enough to fix them all or even to find them all. E.g. if 5 bugs are fixed every month, you will still have the same rate of updates for 10 months, unless you just delay updates even if the bugs could already be fixed. And also usually not all bugs are known when at the beginning of the release. Those are things that could happen. All my experience says that's not what actually happens. The update rate graphs lmacken does every once in a while certainly look like the update rate _does_ slow. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Tue, 2010-10-05 at 11:46 -0400, Brandon Lozza wrote: I don't blanket label everything with open code as free software. Some stuff bundles things which make it non-free. Code open-ness != free. You can call Firefox open source if you want, but it's not free software. You certainly have the right to interpret those words however you like, but over here in consensus reality, that's not what they mean. I would request that you limit your discussions on the development list to topics relevant to Fedora development. You seem instead to be talking about a rather well-hashed point of international trademark law that's not going to get resolved anytime soon, regardless of how fervently you might wish it. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Mon, 2010-10-11 at 15:21 +0100, Richard W.M. Jones wrote: On Mon, Oct 11, 2010 at 09:51:41AM -0400, Josh Boyer wrote: I would like to see you create a Fedora Remix spin with this change to illustrate the benefits. That way we can evaluate feasibility and overall value add before we dive head first into it across the whole project. Proving what? You can just imagine what a rebranded Ubuntu installer that installed Fedora would look like. My point anyway is that we could look at Ubuntu for ideas, because the first point of contact with users is now very smooth and (maybe) first impressions matter. We do. Porting Fedora to the Ubuntu installer would be rather more work than just adding those features to anaconda. You might get a more favorable reaction by phrasing your RFEs positively (this is a neat thing that these guys are doing, we should look into it) rather than negatively (we should throw away what we're currently using and switch). - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Thu, 2010-10-14 at 01:39 +0200, Kevin Kofler wrote: Adam Williamson wrote: Er, really? I don't see where I offered any insult or un-excellent-ness. I just meant it as a vaguely humorous way of wondering why Kevin was replying to an email I sent over a week ago in a discussion which I thought had pretty much finished already. Because I don't have the time to sit on mailing lists 24/7. I guess the logical conclusion, given your output level, is that you have time to write email but not read it. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up: libOSMesa soname bump and etc
We've been carrying a patch to libOSMesa for far too long now to fix the soname at .6, since there was no actual ABI change between .6 and .7. I'm tired of porting the patch so it'll be libOSMesa.so.7 in the next Mesa build in F15. The only affected packages seem to be vtk and paraview, so I'll kick off rebuilds for them as well. In related news, nothing seems to be using libOSMesa16 or libOSMesa32, so they're getting dropped. If they're being used in an external repo please let me know, and if they are then we should probably figure out alternate packaging for them since it doesn't make sense to upgrade them at the same rate as the DRI drivers. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: unowned dirs
On Wed, 2010-10-20 at 17:07 -0400, Neal Becker wrote: BTW, it's annoying that rpm allows only 1 %files -f. http://rpm.org/wiki/Releases/4.8.0 %files now accepts multiple filelists through -f (ticket #70, RhBug:475359) - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libOSMesa soname bump and etc
On Wed, 2010-10-20 at 12:12 -0600, Orion Poplawski wrote: Please fix https://bugzilla.redhat.com/show_bug.cgi?id=635865 while you're at it, or paraview won't build. Thanks! Done (upstream, even), thanks! - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: coming libnotify bump
On Tue, 2010-11-02 at 11:33 -0400, Tom spot Callaway wrote:
On 11/01/2010 09:12 PM, Matthias Clasen wrote:
I am planning to push libnotify 0.7.0 into rawhide by the end of this
week; this is going to be a little painful, since there are some api
changes that will require minor adjustment of all users. And there's
quite a few of them (see below). I will hopefully be able to handle most
of the GNOME dependencies, for the rest I need to ask for some help.
Scratch builds of libnotify 0.7.0 rpms can be found here:
http://mclasen.fedorapeople.org/libnotify/
Here is an overview of the api changes:
notify_notification_new_with_status_icon is gone
notify_notification_attach_to_status_icon is gone
notify_notification_attach_to_widget is gone
notify_notification_set_geometry_hints is gone
notify_notification_newhas lost its widget argument
Matthias, this seems like it will break the python bindings... will you
be fixing them at the same time?
python-notify exposes only the attach_to_{status_icon,widget} methods
and implicitly exposes the new method through the constructor. The
constructor allows you to pass a GtkWidget* as an optional named
argument, so we need only look for ctors that say attach=something.
Of the packages mentioned:
coda-gcodacon-0:6.9.5-3.fc14.x86_64
emesene-0:1.6.3-2.fc14.x86_64
genesis-0:0.4.3-3.fc14.noarch
gget-0:0.0.4-13.fc14.x86_64
ibus-0:1.3.7-11.fc14.x86_64
nicotine+-0:1.2.15-3.fc14.noarch
setroubleshoot-0:2.2.102-1.fc14.x86_64
system-config-printer-0:1.2.4-2.fc14.x86_64
call attach_to_status_icon; coda however goes out of its way to check
that the method exists first.
gajim-0:0.14-4.fc14.noarch
nicotine+-0:1.2.15-3.fc14.noarch
wuja-0:0.0.8-8.fc14.noarch
call attach_to_widget; nicotine+ does so in a (non-PEP-8-conformant) try
block so it's harmless.
As far as I can tell, none of the callers to pynotify.init() pass any
named arguments, so nothing should notice the lack of attach=. I only
searched for explicit calls to pynotify.init, if someone's doing like
foo = pynotify
foo.init(I'm far too clever, attach=my_bar_widget)
then they get what they deserve.
Everything else should be unaffected by any pynotify changes.
- ajax
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: coming libnotify bump
On Tue, 2010-11-02 at 12:11 -0400, Adam Jackson wrote: As far as I can tell, none of the callers to pynotify.init() pass any named arguments, so nothing should notice the lack of attach=. I only searched for explicit calls to pynotify.init, if someone's doing like foo = pynotify foo.init(I'm far too clever, attach=my_bar_widget) then they get what they deserve. I got the API wrong here, it's actually pynotify.Notification(), but it still appears that callers never set attach-widget to anything. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-11-03)
On Tue, 2010-11-02 at 14:30 -0600, Kevin Fenzi wrote: Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 18:30UTC (2:30pm EDT) in #fedora-meeting on irc.freenode.net. NOTE: Matthew Garrett, Steven Parrish, Bill Nottingham and Matthias Clasen are all unable to attend this week. And me. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compile with -fno-omit-frame-pointer on x86_64?
On Wed, 2010-11-03 at 19:58 +0100, Jakub Jelinek wrote: On Wed, Nov 03, 2010 at 02:48:12PM -0400, Owen Taylor wrote: Basically summarizes the situation, and as far as I know nothing has changed ... with default compilation options, getting callgraph profiling on x86_64 really requires a DWARF unwinder in the kernel. Which seems unlikely to happen. But that's the right thing to do. Sure, but so is a kernel debugger, and it's taken us over ten years to get one. I'm pretty okay with doing something wrong now if it gets me something usable for long enough to get something right later. I'll take 4% across the board if it helps me find the 20% that matters. There is always callgrind if you don't want to recompile anything and need to profile something even when kernel doesn't support it. I don't want to know how callgrinded X performs, I want to know how X performs. callgrind means operations that would be one millisecond become half a second, and that's thirty frames instead of a sixteenth of a frame. That means I end up optimizing for function call cycle counts instead of fixing my algorithms to not starve the hardware. If wall time matters, callgrind is the wrong tool, and you need a live profiler. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning a few packages
I've got some stuff that I can't really give proper attention to, and I'd rather not even get the bugmail. I just packaged them because I wanted to consume them, not because I wanted to own them. So, free to a good home: bing bootchart powertop wdfs Already orphaned in pkgdb for rawhide, first come first served. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: request for intel driver update in rawhide
On Tue, 2010-11-09 at 08:00 -0600, Jason L Tibbitts III wrote: RK == Rudolf Kastl che...@gmail.com writes: RK http://koji.fedoraproject.org/koji/packageinfo?packageID=7794 RK guess you pulled that somewhere else. fedpkg co xorg-x11-drv-intel; less xorg-x11-drv-intel/*spec 2.13.901 wasn't built yet because it required waiting for a libdrm update. Should have that pushed out today. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 04:05 -0500, Jon Masters wrote: +1 for bringing these points up. No offense to krh (because it's nice technology) but you can pull my genuine networked applications from my cold dead hands. I agree that I see this ongoing trend to move toward things that are fluffy and pretty at the cost of flexibility. No. You see the system you know and understand being replaced by one you don't. You have an emotional attachment to the old system because it gives you a feature you like and the dozens of problems with it aren't important to you. And you claim that the replacement is less flexible because you don't understand or don't want to learn the new thing. You are, in short, scared. It's well established by now that the problems of window system, rendering system, input system, and application remoting are in fact pretty dang separate, and that the more you conflate them the worse your solution ends up being. You can thank X for being ~24 years of research into just how badly you can conflate them and get away with it, but it's just about reached the limits of what it can do. I'm sad to see it go too, but I've been working to knock X out of hegemony for the last six years, and I'm quite sure that the sooner that happens the better for all concerned. Remoting a wayland application is _trivial_. Either to an X or to a wayland view system. It's hard to make wayland remoting less flexible than X over the network, since the natural remoting level (surface updates) is basically stateless unlike X's sixteen complete IPC interfaces, and unlike X you're actually guaranteed that the window surfaces exist and have meaningful content. So you get the long-lusted-for screen for X almost for free. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Tue, 2010-11-09 at 11:44 -0500, Gregory Maxwell wrote: I think we'd like to see the Fedora community figure out its position on the subject— so that it can tell the Wayland developers If you continue on this track, then as things stand, Fedora will not be making it a part of the default Fedora install. Well, the Fedora graphics cabal is basically me, Kevin Martin, and Dave Airlie, and since we were hanging out at Plumbers last week and talked about this, here's the rough consensus I think we reached: Wayland's not a usable default yet. It'll probably be packaged in F15 as something you can play with. We don't even have a complete list of transition criteria yet, let alone a timeframe for switching the default. But it's likely to happen eventually because it's a serious win for a lot of things, and the downsides are pretty negligible despite the fear from the peanut gallery. Feel free to quote me. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
minimal install set tuning [was Re: systemd requires HTTP server and serves QR codes]
On 10/9/12 9:18 AM, Lennart Poettering wrote:
From the list of packages this minimal set still installs, that I'd
really like to see gone:
chkconfig
gamin
info
systemd-sysv
chkconfig seems like it could have the 'alternatives' bit split off.
I've not investigated this in detail.
gamin is glib2's fault. Strictly it's an implementation detail, it's
not like the glib headers expose gamin types. It's a little irritating
that you end up with both libfam.so and libgamin-1.so installed, with
literally identical APIs.
info looks like it's only getting pulled in for /sbin/install-info in
%post. There are several cats to skin here. The stanza for this in
coreutils.spec looks suspiciously like something we could fix at build
time instead, though this might not be the only thing in the transaction
wanting info I suppose. We could split install-info to its own
subpackage if we wanted, it's tiny. And anybody doing minimal images
like this could run a second pass of package cleanup that removes things
that were only needed for Requires({pre,post}).
As for systemd-sysv, pretty sure you know more about that than I do.
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Small heads-up: Mesa packaging change for F18
Mesa 9.0 no longer includes a copy of libGLU, it is instead available as a separate tarball. To reflect this the packaging has been changed to build mesa-libGLU as its own srpm; likewise for the GL manpages, since both libGL-devel and libGLU-devel want to depend on them. This change has already been built in F19, but for F18 that's this errata right here: https://admin.fedoraproject.org/updates/mesa-libGLU-9.0.0-1.fc18,gl-manpages-1.1-2.20121009.fc18,mesa-9.0-1.fc18 - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: minimal install set tuning [was Re: systemd requires HTTP server and serves QR codes]
On 10/9/12 12:34 PM, Adam Jackson wrote: On 10/9/12 9:18 AM, Lennart Poettering wrote: From the list of packages this minimal set still installs, that I'd really like to see gone: chkconfig gamin info systemd-sysv chkconfig seems like it could have the 'alternatives' bit split off. I've not investigated this in detail. Took a look this morning, it appears alternatives is almost completely orthogonal to the rest of the package. Naturally the bit that ruins everything is translations since the locale data is all mushed together among alternatives chkconfig and ntsysv, but that's straightforward to detangle. (Not that I've done so.) That'd drop the size on disk from ~700k for chkconfig to probably around 400k for just alternatives. Not a huge win, but not terrible either, and certainly Correct for a systemd world. Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=865496 Better, though, is looking at what's pulling it in, a Requires(post) in openssh-server (actually for %triggerun and %triggerpostun, but rpm doesn't know how to Requires for those), and in particular for upgrading from versions of openssh-server older than what shipped in F16 Gold. And, the scriptlets are properly immunized against /sbin/chkconfig not existing, which means strictly we could drop the Requires(post) for it already. Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=865498 - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Coordinating libffi upgrade
On 11/2/12 3:18 PM, Anthony Green wrote: Several months ago I attempted to upgrade libffi 3.0.10 to 3.0.11. The change was reverted because the soname change in this version of the library broke the build environment. I would still like to get 3.0.11 in Fedora. I don't anticipate any future ABI-breaking changes, and 3.0.12 will include additional ports like Aarch64, which is likely of interest to some Fedora developers. How do we coordinate a rebuild for dependent packages? Also, I assume this will have to wait 'til F18 is out (fine by me), but I'd like to deal with it early in the F19 cycle. It looks like libffi is emitted into the minimal buildroot (rpm-build - pkg-config - glib2 - libffi), so during the transition we'll need to build both sonames of libffi. It might be worth keeping a compat-libffi around for a release or two anyway, the current soname has a _long_ history. After that, though, the rebuilds should be pretty straightforward, it looks like all affected source packages are provenpackager+. The caveat might be things like ghc which generate their prov/reqs based on a sha hash of, well, something; if that something includes the list of DT_NEEDED then we might be looking at a rebuild of many more things. But even that should be straightforward if tedious. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The GNOME 3.6.2 Megaupdate
On 11/15/12 2:11 PM, John Reiser wrote: # yum install bodhi Loaded plugins: langpacks, presto, refresh-packagekit fedora/18/x86_64/metalink | 12 kB 00:00:00 updates/18/x86_64/metalink | 18 kB 00:00:00 No package bodhi available. % sudo yum install /usr/bin/bodhi HTH. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Backporting LLVM 3.1 for Fedora 17
On Fri, 2012-11-16 at 16:13 +0700, Michel Alexandre Salim wrote: Sending this to the relevant package owners as well as the development list - if there's too much pushback, I'll look at backporting the patches instead, though given that LLVM 3.2 is scheduled for release next month, if we agree, going forward, that occasional stack rebuilds are acceptable, it would really lower the maintenance burden, instead of having to support 3 LLVM releases. This would actually make it easier to keep updated Mesa in older releases. Right now if we backport Mesa 9 to F17 we'd have to disable the radeonsi driver as it requires = llvm 3.1. That said, llvm consumers are difficult to keep in sync with llvm anyway. Many llvm projects seem like they pick a point release to build against and then never get updated when the ABI changes. If we do this we might want to start by building compat-llvm30 for the libraries and migrating the consumers independently afterwards. It'd be fine if that compat package only lived for the one release that needs it (ie no compat-llvm30 in F18 or later, apps that aren't ported get deadpackaged), but at least that way we could avoid breaking llvm apps in F17 updates that worked in F17 gold. I'm aware that this isn't quite in line with the Fedora updates policy, but I consider that a bug in the policy. I'd be happy to help draft policy amendments for this so we have a standard process. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
