Re: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
On Tue, Jul 16, 2013 at 12:24:17PM +0200, Jaroslav Reznik wrote: = Proposed System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin = https://fedoraproject.org/wiki/Changes/NoBinDeps == Scope == Proposal owners: None Other developers: replace all explicit /bin/foo requires with /usr/bin/foo. IMHO it would be nicer if there was a rough estimate about how many packages are affected. Also it might be more efficient to just let provenpackagers do this for everyone who does not want to do it. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 01:43:04PM +0200, Lennart Poettering wrote: On Tue, 16.07.13 09:42, Till Maas (opensou...@till.name) wrote: journalctl only supports local time specifications when you specify calendar times. Unfortunately there's no nice API to map calendar times that include time zone specifications back to UTC, in particular because the time zone names are not unique... While it will be hard to support arbitrary timezone specs in --since= it should be relatively easy to support UTC in addition to the local timezone. Added this to the TODO list. You only need to add or subtract hours and minutes from the local time, because ISO 8601 dates contain the UTC offset: | $ date --iso-8601=seconds | 2013-07-15T22:37:04+0200 Well, we can certainly add support for such numeric timezone specs (added to the TODO list), but I have my doubts that this is actually what people want to use in their day-to-day use, given that the numbers are hard to remember. Thank you. I am pretty sure that most folks would like to specify symbolic timezone names, but that's hard to do due to lack of APIs for that, and the non-uniqueness of the names. I guess for most use cases using the local time zone is enough. Btw. can journalctl output ISO 8601 dates instead of the US formated date without a year? I really expected journalctl to cleanup this as well. Note that the journal actually knows a concept called cursors. The cursors are a way to refer to a specific log line (or the closest available one) in a stable way. by using this you can make a logic like the above work nicely, and even remove any inaccuracy regarding timestamps... The manpage only mentions how to specify which cursor to use but not how to get the cursor of the last read line. journalctl -o verbose will give you that (and so will -o json, -o export and others), but the rest of the output is very low-level then. Maybe we can add a switch that prints the final cursor as last line if you specify some switch. The extra switch sounds useful. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 01:31:44PM +0200, Lennart Poettering wrote: On Mon, 15.07.13 12:44, Jan Synacek (jsyna...@redhat.com) wrote: On 07/15/2013 11:22 AM, Frank Murphy wrote: No, logwatch works only with traditional text-based logs. There is this RFE filed [1], but that will probably not happen as it would require a total rewrite. It would make more sense to write a new logwatch-like utility from scratch, that handles only the journal. It's somewhere on my todo list, but has quite a low priority:( [1] https://bugzilla.redhat.com/show_bug.cgi?id=864872 Such a change should be relatively easy. journalctl provides you with an output that is pretty much identical to what /var/log/messages contains. Hence, you can replace this: f = fopen(/var/log/messages, r); by this: f = popen(journalctl, r); And everything should just continue to work, the stream you read from that is pretty much identical. At least for logcheck this won't work, because needs to get access to only the log entries that changed since the last run. For this it uses logtail whick keeps track for the inode and line offset on each invocation. Therefore it seems like it would somehow like this: previous_run = $(cat last_run.txt) current_run = $(date --iso-8601=seconds --date '1 second ago' | head -c 19 | tr T ) $log_data = $(journalctl --since $last_run --until $current_run) echo $current_run last_run.txt But there seems to be the problem that journalctl does not support timezones/UTC time for since/until according to journalctl(1), therefore there does not seem to be a safe way to specify since/until that will even work when the current local UTC offset changes (daylight saving time). Also it is sad that journalctl does not directly accept ISO 8601 time specifications (I can open a bug if there is a changes it will be implemented). Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, Jul 15, 2013 at 01:57:37PM -0400, Matthew Miller wrote: On Mon, Jul 15, 2013 at 01:50:47PM -0400, DJ Delorie wrote: I worry about the security implications of mail that would have gone to root@ being either silently discarded or unknowingly ignored. That *is* the current case on these systems. The mail happens to live in /var/spool/mail/root, where it accumulates silenty, but the difference between that and /dev/null is practically small. Bash usually tells you when there is mail in the spool, which is IMHO a big difference to /dev/null. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, Jul 15, 2013 at 04:14:35PM +0200, Lennart Poettering wrote: This feature is about not doign local mail delivery by default, by not installing any MTA. Instead you find the log output of cronjobs at the same place as you find any other log output, the journal/syslog, for example accessible via: journalctl -u crond But the information cron sends via email is usually more important than the regular log entries, because output in cron jobs usually means there is an error. It seems wrong to store the important data hidden among less important data. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, Jul 15, 2013 at 03:15:54PM -0600, Eric Smith wrote: On Mon, Jul 15, 2013 at 3:12 PM, Till Maas opensou...@till.name wrote: Bash usually tells you when there is mail in the spool, which is IMHO a big difference to /dev/null. Funny, I just ssh'd into my machine, and it didn't tell me anything about mail being in the spool, but when I do an ls on the spool directory, there it is. Maybe it has something to do with that users don't often log in as root. Oh, sorry, I was imprecise. Bash actually tells you when new mail is put into the spool. E.g. if you log in as root, touch /var/spool/root and wait up to 60 seconds and run e.g. ls, bash should tell you that there is new mail before the next prompt. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Fri, Jul 12, 2013 at 02:06:12PM -0500, Dennis Gilmore wrote: we have a kernel and initramfs, that can be pxe booted or you can boot and load, however we have not made it the primary mathod of install for boards because they generally can only boot and run from a sdcard you would need to install to the boot media. it quite possibly works just fine other than not installing uboot to the sdcard in the way needed, however for non omap systems that copy the file into a partition it will likely work ok. so cubieboard since you need to dd u-boot into a particular location of the sdcard it should still be there post install. Its not tested at all however. I cannot completely follow here. However, I guess the images you mean are the following: http://ftp-stud.hs-esslingen.de/pub/fedora-secondary/releases/19/Fedora/armhfp/os/images/pxeboot/ Is there any particular reason, why there is no signed CHECKSUM file for these? What is required for these images to be able to run anaconda and install packages? I assume that anaconda won't verify package signatures, therefore I guess a copy of manual verified RPMs is required? And what can be done with the live image: http://ftp-stud.hs-esslingen.de/pub/fedora-secondary/releases/19/Fedora/armhfp/os/LiveOS/ (It is also not signed) The raw disk images seem to be signed: http://ftp-stud.hs-esslingen.de/pub/fedora-secondary/releases/19/Images/armhfp/Fedora-Images-armhfp-19-CHECKSUM But I noticed that here SHA1 is used instead of SHA256 for the GPG signature and the comment about sha256sum being used to generate the hashes is missing, e.g. the primary archs have files like these: https://fedoraproject.org/static/checksums/Fedora-19-x86_64-CHECKSUM Here is a ticket for this: https://fedorahosted.org/fedora-infrastructure/ticket/3888 Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Sat, Jul 13, 2013 at 11:50:40AM -0500, Dennis Gilmore wrote: On Sat, 13 Jul 2013 11:36:00 +0200 Till Maas opensou...@till.name wrote: On Fri, Jul 12, 2013 at 02:06:12PM -0500, Dennis Gilmore wrote: we have a kernel and initramfs, that can be pxe booted or you can boot and load, however we have not made it the primary mathod of install for boards because they generally can only boot and run from a sdcard you would need to install to the boot media. it quite possibly works just fine other than not installing uboot to the sdcard in the way needed, however for non omap systems that copy the file into a partition it will likely work ok. so cubieboard since you need to dd u-boot into a particular location of the sdcard it should still be there post install. Its not tested at all however. I cannot completely follow here. However, I guess the images you mean are the following: http://ftp-stud.hs-esslingen.de/pub/fedora-secondary/releases/19/Fedora/armhfp/os/images/pxeboot/ Is there any particular reason, why there is no signed CHECKSUM file for these? What is required for these images to be able to run anaconda and install packages? I assume that anaconda won't verify package signatures, therefore I guess a copy of manual verified RPMs is required? We don't make and sign CHECKSUMS for the equivalent bits on any arch. to have anaconda run you need to boot the kernel and initramfs. and pass to it options to find the rest of the bits. exactly as is done on primary. though you likely need to instrall u-boot to the sdcard then setup a boot.scr that loads things for you. and hopefully anaconda will let you destroy it when running. since you will be booting from the target media. And what can be done with the live image: http://ftp-stud.hs-esslingen.de/pub/fedora-secondary/releases/19/Fedora/armhfp/os/LiveOS/ (It is also not signed) Also true of all arches, we don't make CHECKSUMS or sign them At least a while ago these files were available in signed iso images for the primary arch. Nevertheless, what is (supposed to be) possible with the LiveOS image for ARM? The raw disk images seem to be signed: http://ftp-stud.hs-esslingen.de/pub/fedora-secondary/releases/19/Images/armhfp/Fedora-Images-armhfp-19-CHECKSUM But I noticed that here SHA1 is used instead of SHA256 for the GPG signature and the comment about sha256sum being used to generate the hashes is missing, e.g. the primary archs have files like these: https://fedoraproject.org/static/checksums/Fedora-19-x86_64-CHECKSUM probably a difference in the setup of the sigul between primary and secondary arches. the comment about sha256sum only ever exists in pungi generated CHECKSUMS all the manually generated ones which includes Live and Spins trees do not have it. if you want to change things i suggest you join Release engineering and help me to make things better rather than just complain that how I do things doesn't suit your needs. Release Engineering is me with a lot of help from Kevin Fenzi and over the last few releases a lot more has been asked from me which means many things that could have been done have not been. as is Both Kevin and I work a lot more than 40 hours. Thank you, I will gladly help. I believe I already helped with releng tasks in the past, back then when buildroot overrides had to be done manually. If you give me any pointers to what I can do to get the things signed, I will take a look. I found so far https://fedoraproject.org/wiki/Stage_final_release_for_mirrors https://fedoraproject.org/wiki/Create_release_signing_key but they are not up-to-date and only show the user POV for the sigul system not the admin POV. So how do we proceed here? If you give me access to the respective system, I can start with updating the documentation and you can review them to verify I understand the process. I guess this probably also helps to identify the reason for the different hash algorithms used. Here is a ticket for this: https://fedorahosted.org/fedora-infrastructure/ticket/3888 the ticket is for nothing mentioned in this email It mentions the different hash method of the CHECKSUM files. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Getting koji access for some Perl tools
On Sat, Jul 13, 2013 at 07:00:14PM -0400, Nico Kadel-Garcia wrote: If it should be fedoraproject.org in general, good. But if one is going to host a website with a different top level domain, it really needs a different SSL key. What's present on fedoraproject.net seems to be simply the content of fedoraproject.org: this kind of duplication of sharing of a single website for multiple URL's is quite commonplace, but SSL creates a real certificate problem if they're in different domains. I'll certainly accept I should have been using fedoraprojects.org, and that's cool. But why did you try fedoraproject.net? It should not be promoted anywhere as far as I know. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 11:50:00AM -0700, Brendan Conoboy wrote: On 07/11/2013 11:38 AM, Till Maas wrote: https://bugzilla.redhat.com/show_bug.cgi?id=865022 It is currently closed, because I did not re-test anymore after it was announced that the device won't be supported anymore soon. Thanks. Since the last update we have added a dedicated ARM kernel maintainer. Fedora 18 on armv5tel is still supported. If you would like to pursue the issue further we will assist. Thank you, but since the device will not be supported by Fedora in about 6 months, I do not see much use in this. Never been supported by Fedora ARM for lack of upstream kernel and firmware license issues. It's a Seneca College remix, but AFAIK it works great: http://pidora.ca/ Yes, but this is probably also a reason why there was little Fedora related outcome from the Hardware summer of fun. Not sure I follow. Before Pidora Seneca still supported the Pi on armv5tel, as early as F13. The possibility to use a Remix is not that big promoted, therefore it was not clear to me that I could run Pidora on it with at least packages similar to Fedora. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Fri, Jul 12, 2013 at 09:03:24AM +0200, Hans de Goede wrote: As for the anaconda install support, my images will be a copy of: Fedora-XFCE-armhfp-19-1-sda.raw.xz with the kernel and uboot replaced + some other tweaks, but otherwise unmodified. So if that image can do anaconda installs, my images should be able to do it too (assuming there is no model specific code in anaconda which quite likely is wrong). The image name does not really sound like something that can be run headless to install Fedora. I was expecting something more like a kernel, a initrd and a pool of verifiable RPMs that can be used as installation source. For example for x86 an installation iso image would do, because it is GPG signed and contains everything to setup a Fedora system that can install packages with package signature verification. Is there something like this for ARM? The installation page does not seem to mention this: https://fedoraproject.org/wiki/Architectures/ARM/F19/Installation Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPG verification in SPECs
On Wed, Jul 10, 2013 at 03:01:07PM -0700, Brian C. Lane wrote:
On Mon, Jul 08, 2013 at 11:15:05PM +0200, Till Maas wrote:
Hi,
upstream of pam_mount pointed me to OpenSUSE's gpg-offline RPM macros at
https://build.opensuse.org/package/show/Base:System/gpg-offline
They allow to use a keyring and detached signature as additional source
in SPECs to get both verified. Since gpg-offline's upstream is willing
to create a proper release to allow easy packaging for Fedora, I wonder
if I will find any obstacles when I package it. The packaging guidelines
allow packaging RPM macros, therefore this should be fine.
Also I am interested whether there are better options available.
In parted we have a signed upstream package and a detached signature. In
the pkg git we have the signer's public key and in %prep it runs gpg.
Source0: ftp://ftp.gnu.org/gnu/%{name}/%{name}-%{version}.tar.xz
Source1: ftp://ftp.gnu.org/gnu/%{name}/%{name}-%{version}.tar.xz.sig
Source2: pubkey.jim.meyering
gpg --import %{SOURCE2}
gpg --verify %{SOURCE1} %{SOURCE0}
What does gpg-offline add to this?
I did not yet read it, but your code has several flaws:
- It modifies the users default GPG keyring, which might be considered
rude (if it is not run on Koji or in mock)
- It does not ensure that the signature is actually from the key that is
provided as Source2
- It either does not work if the key is not trusted or allows signatures
from untrusted keys, because the provided key is not especially marked
as trusted
I hope that gpg-offline does not have these flaws but since addressing
this needs a little mit more code, a macro seems to be the right way to
do this for me.
Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 07:48:50AM -0400, Jonathan Masters wrote: And following the legitimate concerns about stack-protector this was raised by ARM into core Linaro as an urgent action for which engineering resource is being assigned to correct this deficiency ASAP. Thus within a day an issue has been noted that we were unaware of and is being worked through a process to correct it, as would be the case with any deficiency on x86. The stack protection stuff will be fixed. Let's bike shed over the next nitpick nuance that the anti-ARM crowd want to throw in the way ;) Was the flag ignored previously or why was this missing feature not announced? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 12:35:36PM +0100, Peter Robinson wrote: On Thu, Jul 11, 2013 at 12:00 PM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Jul 11, 2013 at 6:25 AM, Jaroslav Reznik jrez...@redhat.com wrote: Speaking about hardware - and that's more a question for Spot - could be possible to organize another round of HW give away as we did with Raspberries? With a different HW, that's supported in Fedora and it seems like there are pretty cheap options either. With some metrics, like commits/packages/packages that need significant effort to make it working on ARM... The sentiment is nice, but I don't think that last hardware give away went all that well. Also, to get something competent is going to cost money. I have no idea what the Fedora budget looks like, but frankly I'd rather use money on something more beneficial than buying hardware for a bunch of people that aren't already working on ARM. It will likely have a shiny factor of about 1 week, and then it will sit on their desk collecting dust. I agree, not sure what the contribution to the RPi stuff was like but for the XOs that were given away I'm not aware of a single contribution to any of the Fedora/OLPC/Sugar projects as a result of it. IMHO it is also not that easy to get something going with ARM on Fedora. For example I bought a Sheeva-ARM devices to get upstream release monitoring running on it . But even when I got it installed, the device crashed with a kernel soft lockup. Now the devices are no longer supported. I got a RPi (from the hardware summer of fun) with the same intent, but until today it is not properly supported and won't. In the meantime I bought a Cubieboard, no luck here as well. Since the Cubieboard remix even requires HDMI output and does not work headless, I did not try it because if missing HDMI hardware. Also all the Fedora ARM efforts usually require to dd some images instead of just allowing to run a textmode anaconda via serial or some other installer, which just feels quirky. So now I gave up and bought a x86_64 microserver, which will then do the release monitoring among other things. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Thu, Jul 11, 2013 at 08:58:11AM -0700, Brendan Conoboy wrote: On 07/11/2013 08:47 AM, Till Maas wrote: IMHO it is also not that easy to get something going with ARM on Fedora. For example I bought a Sheeva-ARM devices to get upstream release monitoring running on it . But even when I got it installed, the device crashed with a kernel soft lockup. BZ#? https://bugzilla.redhat.com/show_bug.cgi?id=865022 It is currently closed, because I did not re-test anymore after it was announced that the device won't be supported anymore soon. Now the devices are no longer supported. I got a RPi (from the hardware summer of fun) with the same intent, but until today it is not properly supported and won't. Never been supported by Fedora ARM for lack of upstream kernel and firmware license issues. It's a Seneca College remix, but AFAIK it works great: http://pidora.ca/ Yes, but this is probably also a reason why there was little Fedora related outcome from the Hardware summer of fun. In the meantime I bought a Cubieboard, no luck here as well. Since the Cubieboard remix even requires HDMI output and does not work headless, I did not try it because if missing HDMI hardware. Never been supported by Fedora ARM for lack of upstream kernel. That might change in the next release as the upstream is coming along. Also all the Fedora ARM efforts usually require to dd some images instead of just allowing to run a textmode anaconda via serial or some other installer, which just feels quirky. F19 on ARM supports interactive anaconda installs over serial. Or vnc installs if you want graphics. Or kickstart installs if you want automation. This sounds promising. Are there remix-anaconda images that can be used to test this on a Cubieboard? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide: glibc, ldconfig, and community-mysql-libs, oh my
On Thu, Jul 11, 2013 at 01:46:26PM -0700, Adam Williamson wrote: On Thu, 2013-07-11 at 22:43 +0200, Tomasz Torcz wrote: On Thu, Jul 11, 2013 at 01:37:45PM -0700, Adam Williamson wrote: Would anyone care to take a guess at what the hell is going on here? [adamw@adam ~]$ sudo yum update (snip) Error: Package: community-mysql-libs-5.5.32-6.fc20.x86_64 (@rawhide) Requires: /usr/sbin/ldconfig Removing: glibc-2.17.90-3.fc20.x86_64 (@fedora/rawhide) Not found Updated By: glibc-2.17.90-4.fc20.x86_64 (rawhide) Not found What the fracking hell? Why is yum apparently okay with -3 but not okay with -4 even though their provides are identical? And why is this suddenly popping up now? Answer to the second part: because 3 days ago commynity-mysql was fixed to require ldconfig in /usr: http://pkgs.fedoraproject.org/cgit/community-mysql.git/commit/?id=56c556f1555b88c391e70632184018e31852e884 And glibc somehow only provides ldconfig in /sbin. I got bitten by this few weeks ago (had to revert to running /sbin/ldconfig instead of /usr/sbin/ldconfig) But then why does yum check not apparently perceive a problem with the current state - where glibc -3 is installed, which differs in its provides/requires *not at all* from -4? Why did that community-mysql-libs package install just fine here? It is the incomplete UsrMove again. When glibc is installed, both /sbin/ldconfig and /usr/sbin/ldconfig exist, because of the /sbin - /usr/sbin symlink. Therefore the /usr/sbin/ldconfig dependency is fulfilled. If you update glibc, the file would be removed temporarily and I guess yum notices that this affects both paths, but it does not know that the update will provide both paths (due to UsrMove) again, therefore the dependency is not fulfilled from yum's POV. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 09, 2013 at 10:36:39PM +0100, Peter Robinson wrote: On Tue, Jul 9, 2013 at 10:11 PM, Till Maas opensou...@till.name wrote: Which hardware is supported by ARMv7 hfp 32bit builds? Will there be http://fedoraproject.org/wiki/Architectures/ARM The list is expanding regularly and there's a lot of other hardware currently supported by remix primarily because the complete kernel support isn't upstream. So eventually Raspberry Pi and Cubieboard devices will be supported when their kernel patches are upstreamed? test instances for maintainers as described here: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers I've never seen the above before. Oh. I thought the ARM device was maintained in coordination with the ARM SIG, but this has been cleared up in Kevin's mail. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Getting koji access for some Perl tools
Hi Nico, On Tue, Jul 09, 2013 at 06:06:38AM -0400, Nico Kadel-Garcia wrote: I've been active enough that an intro probably isn't needed, but I've not successfully worked my way through the Fedora access to manage particular packages nor have I gotten koji access. I'd particularly like to get the old mkrdns tool into Fedora and EPEL, since it's a personal favorite for auto-managing reverse DNS and it's very stable. Is there someone who can walk me through the Fedora koji access procedures? I've got Fedora 19 running in a VM, with access to my github repositories. I normally build my tools with mock for testing, but I'm happy to work with other build systems. to get koji build access you need to become a package maintainer as described here: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers Essentially you need to create a spec/SRPM for the package, upload it to Bugzilla and find a sponsor that reviews the files. Then you will become a package maintainer and get koji access as well. To find a sponsor it is usually helpful to show your knowledge to the process and the packaging guidelines by preliminary reviewing other peoples specs/SRPMs on Bugzilla. I hope the complex procedure does not repel you and you still like to get the package into Fedora. :-) If you have further questions, please ask. If you did some preliminary reviews and do not find a sponsor, you can write me directly and I will see what I can do as time permits. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Owner-change] Fedora packages ownership change
On Mon, Jul 08, 2013 at 10:00:04AM +, nob...@fedoraproject.org wrote: Change in ownership over the last 168 hours === To whoever is creating these messages: Please add a message about who is responsible for these reports, where to report bugs and where the sources of the script can be found. Thank you Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Owner-change] Fedora packages ownership change
On Mon, Jul 08, 2013 at 10:00:04AM +, nob...@fedoraproject.org wrote: Change in ownership over the last 168 hours How about changing the report time to to last 48-216 hours, then ongoing ownership transfers would be recognised as long as they happen within 48 hours. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Owner-change] Fedora packages ownership change
On Tue, Jul 09, 2013 at 07:01:12PM +0200, Pierre-Yves Chibon wrote: On Tue, 2013-07-09 at 18:23 +0200, Till Maas wrote: On Mon, Jul 08, 2013 at 10:00:04AM +, nob...@fedoraproject.org wrote: Change in ownership over the last 168 hours How about changing the report time to to last 48-216 hours, then ongoing ownership transfers would be recognised as long as they happen within 48 hours. 168 hours is a week, so ownership transfer should be picked if they happen within a week. You would like to have it down to 48h or up to 216h? Actually I was incorrect. I would like it to report orphaned packages in the time frame from 48 hours ago until 216 hours ago (which is again a week), but report packages that have been picked up again in between today to 48 hours ago as transfered from one owner to another. With the current setup, if a package was orphaned shortly before the script ran and claimed shortly afterwards, this will not be shown as a simple transfer but as orphaning and adopting. It irritated me that mstmp was reported as being orphaned, because I noticed that its ownership was transfered recently. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Owner-change] Fedora packages ownership change
On Tue, Jul 09, 2013 at 06:56:03PM +0200, Pierre-Yves Chibon wrote: On Tue, 2013-07-09 at 18:06 +0200, Till Maas wrote: and where the sources of the script can be found. That would be there: https://github.com/pypingou/fedora-owner-change Thank you. Have you considered moving this to the fedoraproject infrastructure github project? See: https://github.com/fedora-infra Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 09, 2013 at 03:00:05PM +0200, Jaroslav Reznik wrote: = Proposed System Wide Change: ARM as primary Architecture = https://fedoraproject.org/wiki/Changes/ARM_as_Primary Change owner(s): Dennis Gilmore den...@ausil.us, Peter Robinson pbrobin...@gmail.com Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches that we build and support. This will mean that all packages supported by the ARM architecture must build for ARM to be released. With the release of Fedora 19 we have deprecated support for software floating support (ARMv5tel sfp) so the only proposed addition to primary architectures is currently ARMv7 hardware floating point 32 bit support (ARMv7 hfp 32bit). Which hardware is supported by ARMv7 hfp 32bit builds? Will there be test instances for maintainers as described here: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers f17-arm-test.scrye.com is currently not reachable for me. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GPG verification in SPECs
Hi, upstream of pam_mount pointed me to OpenSUSE's gpg-offline RPM macros at https://build.opensuse.org/package/show/Base:System/gpg-offline They allow to use a keyring and detached signature as additional source in SPECs to get both verified. Since gpg-offline's upstream is willing to create a proper release to allow easy packaging for Fedora, I wonder if I will find any obstacles when I package it. The packaging guidelines allow packaging RPM macros, therefore this should be fine. Also I am interested whether there are better options available. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Tue, Jul 02, 2013 at 09:39:47PM -0700, Adam Williamson wrote: most updates get submitted with the default +3 auto-push, even though it's perhaps not appropriate for all updates. So can we please get a sane default value then that is good for most updates and can be adjusted for special cases (and later per-package)? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Gooey Karma as GSOC project
Hi, On Wed, Jun 05, 2013 at 06:48:55PM +0200, Branislav Blaskovic wrote: My proposal [1] is available on fedoraproject wiki page where you can find main features of this new tool. If you have any questions, please feel free to contact me here on mailing list, off-list or br...@freenode.org. [1] https://fedoraproject.org/wiki/GSOC_2013/Student_Application_Blaskovic/Fedora_Gooey_Karma%284111%29 is this planned to be a replacement or an alternative to the command line tool? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Fri, Jun 28, 2013 at 07:44:22PM -0500, Michael Catanzaro wrote: We need written policy on update descriptions, since despite the last discussion on this list [1], poor update descriptions continue to blemish the otherwise-professional image of the distro. A starting point suggestion: Every update should have at least a one sentence description. If the update is not worth writing one sentence about, it is not worth pushing out. If the update fixes a bug which is properly mentioned in the bugs field, why does this fact need to be mentioned again in the update notes? It should be obvious that an update fixing a bug is worth pushing out. Also instead of writing policy, better make Bodhi allow to easier write good update notes, e.g. by using/including the upstream, RPM or GIT changelog, so it can be easily used if it already contains the necessary information. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On Sat, Jun 29, 2013 at 01:07:29PM -0700, Adam Williamson wrote: The upstream, RPM or git changelog is never a good update description. An update description should be a very clear high-level description of what the update does. The audience is a normal end-user who has 300 updates to apply and wants to know what they do. This person is not going to spend six hours reading changelogs. This update simply fixes the bugs listed is an okay description - it tells the reader what they need to know and re-assures them that the update doesn't do anything *else*. Of course, if it does, you need to explain that: This update includes a new upstream release which fixes the bugs listed. You can find other changes in the upstream description at http://www.blahblah.foo;. For this update description, no human intervention is required, because it can be created automatically. If the person reading the notice wants to know what the update does, there is no way around reading changelogs, because they contain this information. If he or she just wants some comforting words, then the GUI or update framework can generate them just automatically. I can't personally conceive of a case in which it would make sense to simply have some kind of changelog as the update description. That is not what the description is for. I only read update changelogs if I want to provide karma and am wondering if there is anything special that I should test, therefore I do not see any value at all in the update description. Maybe more examples of good update description would help. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
On Fri, Jun 21, 2013 at 12:09:57PM -0500, Dan Williams wrote: On the other hand, having NetworkManager available all the time enables things like management tools to use its API to query system status, instead of guessing it from kernel information and heuristic analysis of some files under /etc. Exactly. And that's why we want to enhance NetworkManager to make people *want* to use it instead of turning it off. Features I am missing are: - A possibility to make NM ignore an interface from the management tools, which would allow to normally use NM but disable it if one wants to configure a device on the command line. Having to disable interfaces from /etc/sysconfig to be able to use them without NM interfering makes it more cumbersome to use NM at all. - Support NM not interfering with Wi-Fi attack tools such as aircrack-ng, which might only be possible by ignoring the device completely or by adding support to change devices into monitor mode and select static of changing frequencies etc. Probably the features airmon-ng provides would be necessary. - Allow to create tun/tap devices, especially persisted ones with permissions for users Should I file RFEs for these in Red Hat Bugzilla or is there a better place to communicate them to? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On Thu, May 23, 2013 at 03:13:30PM +0200, Jan Zelený wrote: On 23. 5. 2013 at 13:52:39, Simone Caronni wrote: I fiddle around with a new Nagios installation, then something stops working. I'm pretty sure it is some modifications in /etc/nagios/nagios.cfg but I cannot track it down. As an example I could do: mv /etc/nagios/nagios.cfg /etc/nagios/nagios.cfg.mine yum reinstall nagios --onlyfile /etc/nagios/nagios.cfg Thanks for the explanation. I will mark the email and make sure to put the use case to the updated list of RFEs. I would like it even more if RPM keeps a backup copy of every %config file somewhere protected to allow to restore config files even without having the original RPM available, because the RPM might not be available anymore. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [heads-up] kbd using converted xkb layouts landing in Rawhide
On Tue, May 21, 2013 at 04:42:10PM +0200, Vitezslav Crhonek wrote: - there are symlinks from the old keymap names to the matching entries of the X11 keymaps (pairs taken from 'kbd-model-map' file in localed sources) The symlinks seem to be broken, because bot the deadkeys and the nondeadkeys variant link to the same files: | croat.map.gz - /lib/kbd/keymaps/xkb/hr-us.map.gz | cz-us-qwertz.map.gz - /lib/kbd/keymaps/xkb/cz-ucw.map.gz | de-latin1.map.gz - /lib/kbd/keymaps/xkb/de-nodeadkeys.map.gz | de-latin1-nodeadkeys.map.gz - /lib/kbd/keymaps/xkb/de-nodeadkeys.map.gz | de.map.gz - /lib/kbd/keymaps/xkb/de-nodeadkeys.map.gz | fr_CH-latin1.map.gz - /lib/kbd/keymaps/xkb/ch-fr.map.gz | fr_CH.map.gz - /lib/kbd/keymaps/xkb/ch-fr.map.gz | hu.map.gz - /lib/kbd/keymaps/xkb/hu-standard.map.gz | sg-latin1.map.gz - /lib/kbd/keymaps/xkb/ch-de_nodeadkeys.map.gz | sg.map.gz - /lib/kbd/keymaps/xkb/ch-de_nodeadkeys.map.gz | slovene.map.gz - /lib/kbd/keymaps/xkb/si-us.map.gz Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Fedora openid provider (fas-openid) in service
Hi, On Tue, Mar 05, 2013 at 05:19:50PM -0700, Kevin Fenzi wrote: More information is available at: https://fedoraproject.org/wiki/OpenID I hope that nobody used that until now, otherwise I am disappointed that nobody noticed before me that Firefox does not properly validate https://id.fedoraproject.org/ saying your connection to the site is only partially encrypted and does not prevent eavesdropping. I assume the problem is this entry from the CSS file: @import url(http://fonts.googleapis.com/css?family=Cantarell:400,700); And this opens the question why a central Fedora service is using third party, probably non-FOSS services leading only to less security. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Wednesday's FESCo Meeting (2013-05-01)
On Tue, Apr 30, 2013 at 07:37:03AM -0700, Toshio Kuratomi wrote: 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. Please clarify the Guidelines for release names: https://fedoraproject.org/wiki/Guidelines_for_release_names | Names must not contain any shell metacharacters. This does not match the definition from man bash(1): |metacharacter | A character that, when unquoted, separates words. | One of the following: || ; ( ) space tab IMHO best would be to just write Names must not contain any of the following characters: to be completed to avoid any inaccuracies. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Smock successor?
Hi everyone, I have been using smock.pl regularly and since it was not developed recently. I wonder what everyone else is using, e.g. does something better exist? If not, I am planning to give it a proper new home, currently I am trying out gitorious: https://gitorious.org/smock/smock/ References: http://www.redhat.com/archives/rhl-devel-list/2008-November/msg01229.html Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Smock successor?
On Thu, Apr 04, 2013 at 08:50:43AM -0600, Nathanael D. Noblet wrote: On 04/04/2013 06:44 AM, Till Maas wrote: Hi everyone, I have been using smock.pl regularly and since it was not developed recently. I wonder what everyone else is using, e.g. does something better exist? If not, I am planning to give it a proper new home, currently I am trying out gitorious: https://gitorious.org/smock/smock/ Hello, I still use smock with some modifications (patched to build different distro/arches in threads). I think I also modified it to sign the packages it builds (asks for the key when I kick off a build)... Can you provide the patches? Adding support to sign packages is something I want to look into as well. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Smock successor?
On Thu, Apr 04, 2013 at 09:34:22AM -0400, seth vidal wrote: On Thu, 4 Apr 2013 14:47:12 +0200 Johannes Lips johannes.l...@gmail.com wrote: On Thu, Apr 4, 2013 at 2:44 PM, Till Maas opensou...@till.name wrote: I have been using smock.pl regularly and since it was not developed recently. I wonder what everyone else is using, e.g. does something better exist? If not, I am planning to give it a proper new home, currently I am trying out gitorious: https://gitorious.org/smock/smock/ I think there is mockchain, which should do the same thing, or? https://skvidal.wordpress.com/2012/04/20/mockchain-use-cases-and-examples/ Yes - mockchain exists and is already in the mock package. So you should be able to just use it for that end. Is it intended to be feature complete? Smock looks more like a simple build system, because it supports to build multiple archs/distros at once and uses deterministic repositories and mockchain only supports a subset of it. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Smock successor?
On Thu, Apr 04, 2013 at 12:34:51PM -0400, seth vidal wrote: On Thu, 4 Apr 2013 18:30:02 +0200 Till Maas opensou...@till.name wrote: Is it intended to be feature complete? Smock looks more like a simple build system, because it supports to build multiple archs/distros at once and uses deterministic repositories and mockchain only supports a subset of it. what does 'deterministic repositories' mean? smock uses ~/public_html/smock/$DISTRO/$ARCH by default and mockchain some random temp dir. As to multiple archs/distros at once: It's a for loop, right? Actually two loops, one for the arch and one for the distro. If you want to add that to mockchain I don't really see a big problem - just felt unnecessary since it can be done with more flexibility at the shell and since mock chroots are not strictly distro+arch but can be a myriad of things. Yes, mockchain is more flexible but smock is more user friendly for it's use case, e.g. the command line is much simpler for this use case. Even if mock chroot are not distro+arch, smock makes a useful assumption/has assumes a useful convention for mock config files. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: well!
On Tue, Mar 12, 2013 at 12:47:07AM -0400, Digimer wrote: On 03/12/2013 12:41 AM, Charles Zeitler wrote: i don't like giving up control over my machine (partitioning), so i won't be upgrading to Fedora 18. i'll watch the web site for a return to sanity. charles zeitler Setting aside the drama, you can manually partition F18. Unless anaconda crashes (live image) or does not recognise the partitions (DVD image). :-/ Reference: https://bugzilla.redhat.com/show_bug.cgi?id=905669 Btw.: Ideas how to install F18 anyhow are welcome. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, Mar 11, 2013 at 09:09:46PM +0100, Lennart Poettering wrote: We are working on this in the systemd context. We will provide a tiny mechanism, similar to localed/timedated/hostnamed that can be used by desktop UIs to choose boot into firmware, and boot into other OS features, which can then be exposed on the shutdown button in the UI, or in some configuration applet thingy or wherever the desktop UI wants to put it. Would the systemd feature also allow to for example boot the default kernel but allow to display a menu in parallel that can be used to boot a different kernel by reconfiguring the boot loader and initiating a reboot? Then it is possible to get both, nearly zero boot delay and a boot menu. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On Fri, Feb 15, 2013 at 01:03:50PM +0100, Alec Leamas wrote: Thanks for reply... Still, I'm puzzled about 45 packages owning /usr/lib/debug, none of them the filesystem package. This looks weird, although I don't grasp the consequences (if any). A normal review rule says that a package should not own a directory owned by another package. Does this apply to /usr/lib/debug (as well as /usr/src/debug, used occasionally)? If so, who is the rightful owner of these directories? Still confused, but on a higher level... If you file a bug against filesystem, it will probably be included. Then the other packages can be fixed to not own it. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On Fri, Feb 15, 2013 at 11:24:31AM -0800, Adam Williamson wrote: On 15/02/13 05:44 AM, Tom Hughes wrote: You're both kind of right - the README.RPM file that comes in the mediawiki package tells you to run mw-createinstance path to create an instance and that sets up a document root in the specified path by both copying some files, like LocalSettings.php, and symlinking others to the /usr/share code. Huh. That sounds...interesting. I haven't run mediawiki itself, so I wasn't aware of that, I was just referring to my general knowledge of how webapps are packaged in Fedora (e.g. wordpress, which I do run). Thanks. Trac behaves similarly. There is also some environment setup and deployment involved that creates/copies files, which are usually not common to all instances. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On Fri, Feb 15, 2013 at 10:50:28AM -0700, Kevin Fenzi wrote: - make a script to identify all the packages that are broken and shipping debug stuff. AT least for the directory a simple yum call should suffice: yum --disablerepo '*' --enablerepo fedora\* whatprovides /usr/lib/debug But it shows that a lot (all?) debuginfo packages own the directory which probably needs to be fixed in rpm itself. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Wed, Jan 23, 2013 at 10:38:30PM +0100, Lennart Poettering wrote: On Wed, 23.01.13 14:20, Kevin Fenzi (ke...@scrye.com) wrote: I know we have discussed this before, but I've filed a FESCo ticket to ask them one way or another about the issue: https://fedorahosted.org/fesco/ticket/1005 Feedback welcome. If you are a maintainer who doesn't have a minute to do a rawhide build during the branched cycle, would you be open to someone else doing those builds for you? Oh, yeah, let's make it even more work to update a package. Because we have so much free time, let's let humans do what computers could do better. Except that doing an update for rawhide does cost nearly nothing compared to the other branches (no bodhi update needs to be created). If you just update the master branch you can easily let the computer do all the work to also build for e.g. f18: for b in master f18; do fedpkg switch-branch $b; git merge master; git push; fedpkg build --nowait; done Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Package Signature Checking During Installation
On Wed, Jan 09, 2013 at 10:09:21AM -0500, Peter Jones wrote: As it stands you still need to verify that your netinst.iso (or whatever) boot image is what you mean to be using. There are ways we can address that, but it's not the problem I'm trying to solve with this particular feature. I'm not claiming to solve every integrity or authenticity problem we've got. I'm just making it so that anaconda can verify packages are okay to install. I'm not solving the greater problem of trusting anaconda. I've found that it's often useful to work on one engineering problem at a time. But why should anaconda not verify packages if secure boot is disabled? You need to implement package verification anyhow in anaconda to get your complete feature to work and this does not have to do anything with ensuring that anaconda uses the correct key to verify packages. But then it also does not matter whether you use secure boot to verify the key (from anacondas perspective) or trust the user to have verified the key. Especially since it is required for a user to verify the boot image even with your feature to be secure, also checking for secure boot does not seem to provide any benefit. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Package Signature Checking During Installation
On Thu, Jan 10, 2013 at 02:41:54PM -0500, Adam Jackson wrote: On Thu, 2013-01-10 at 17:56 +0100, Till Maas wrote: But why should anaconda not verify packages if secure boot is disabled? For the same reason Firefox doesn't automatically accept self-signed SSL certs, and the same reason that ssh doesn't automatically accept new host keys: it'd be creating trust from thin air. With secure boot disabled there's no root of trust for verification. You could verify that the signatures were _valid_, but you'd have no grounds to conclude from their validity that the signatures were the ones put there by The Fedora Project, and therefore that the package contains the data that The Fedora Project intended it to contain. You'd only know that the key the repo says signed the packages did in fact sign the packages. That's not security. That's theatre. It has already been shown in this thread that the boot image needs to be verified manually by the user to ensure that really an anaconda is running that verifies certificates with secure boot enabled and not for example the F18 anaconda. Therefore your argument does not hold. If we assume that Firefox equals anaconda, then the rpm packages are not self signed but signed by the root ca (rpm key) that could be included in the boot image, which needs to be verified by the user as always described in https://fedoraproject.org/en/verify This whole secure boot seems to be more theatre than security with respect to package signature checking during installation. It changes the attack vector from someone trojaned some random repository on the internet to someone managed to root this machine's firmware before it even shipped. And Microsoft is the party with most This is not true. Actually it only ensures that who controlled the initial boot image controls which packages will be installed. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Package Signature Checking During Installation
On Thu, Jan 10, 2013 at 04:25:18PM -0600, Michael Cronenworth wrote: Problem 1: Root trust Currently this process is manually performed by checking a mental checkbox when a user downloads a Fedora image from fp.o. Having SecureBoot perform this process automatically is a +1, but not a requirement. If we cannot trust our end users then how can we trust ourselves. SecureBoot does not do this automatically, as it would allow to run a F18 install image that does no signature checking on packages. Therefore users still need to verify the image that they are going to boot with this feature enabled. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Package Signature Checking During Installation
On Thu, Jan 10, 2013 at 04:42:36PM -0600, Michael Cronenworth wrote: Till Maas wrote: SecureBoot does not do this automatically, as it would allow to run a F18 install image that does no signature checking on packages. Therefore users still need to verify the image that they are going to boot with this feature enabled. ... you rolled problem 2 into problem 1. Keep them separate! :) I did not. I only told you that secure boot does not solve problem 1. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Package Signature Checking During Installation
On Thu, Jan 10, 2013 at 03:53:04PM -0700, Stephen John Smoogen wrote: Then write the patch. That is all that this is going to take... even if it doesn't get incorporated it will be there for some probably large group that does want it (I would use it myself.) Because the current approach of trying to shame the developer into writing it for you is NOT working. The problem is more, that a patch for a process and not an individual program is required. Even if a patch for anaconda existed (which is probably trivial, because it would only require to no disable the signature checking), one would still need to create custom boot images for it to be useful. And getting processes changed regarding signed packages seems to me to be at least impossible for me. I failed at least four times (buildgroups for EPEL5, RPM keys included in mock, get a chain of trust between Fedora gpg keys/get old gpg keys revoked, get packages signed in koji/for rawhide). At least for fedup there is hope that the required data will be produced to be able to write a patch for it. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Package Signature Checking During Installation
On Tue, Jan 08, 2013 at 03:20:41PM -0500, Peter Jones wrote: On Tue, Jan 08, 2013 at 08:28:03PM +0100, Björn Persson wrote: I'll agree that most users probably don't verify their DVD images as it takes some manual work to do it properly, so that's another weak link, but the possibility does exist for those of us who care enough about our security. It's like Ronald Reagan said: trust, but verify. In this scenario, there's no way for anaconda to verify it. As such, I'm not planning to work on it for this feature. I do not see the difference from anaconda's perspective. With secure boot enabled, UEFI(?) verified the boot medium/the environment anaconda runs in and with the manual process a human did. How does it help anaconda if the environment has been verified by UEFI? Nevertheless, once anaconda is capable of installing only proper packages from a verified environment, a patch do also do this if the environment has been verified by a human should be trivial. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream release monitoring script gone awry?
Hi, On Mon, Jan 07, 2013 at 08:53:15PM +1100, Ankur Sinha wrote: I've received new bugs in the form: bibus-1...5...2 is available. There's already a bug for 1.5.2. Is something faulty with the script? yes, there was an incomplete patch added unintentionally to the script. All faulty bugs should be closed and new bugs created if appropriate. Sorry for the trouble. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rationalizing X and console keymaps and configuration (was Re: Fedora 18 issues with translations and keymaps)
On Thu, Jan 03, 2013 at 09:59:52AM -0800, Adam Williamson wrote: Oh sure. I guess I need to draw a distinction between what I see as two different cases. Which I'm sure you understand but I'm having trouble describing clearly. I guess what I'm saying is, if there's /etc/keyboard.conf specifying 'KEYBOARD=foo', I should never have to pass 'KEYBOARD=foo' as a cmdline to make foo my keyboard layout in some case. As things stand I believe I do, for passphrase entry during dracut. It should also be made the other way round, i.e. if a keyboard layout is specified at the kernel command line, it should not be necessary to specify one in a local config file. Then if everything should use the same keyboard layout, there is only one place to set this instead of several ones that might diverge unintended. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Sat, Dec 08, 2012 at 12:10:36AM -0800, Adam Williamson wrote: On Fri, 2012-12-07 at 20:11 +0100, Till Maas wrote: On Wed, Dec 05, 2012 at 03:20:14PM -0500, Bill Nottingham wrote: * 960 - F18 schedule + the holidays (notting, 18:50:29) * LINK: https://fedoraproject.org/wiki/JaroslavReznik/FedupF18Final - not updated yet (jreznik, 18:58:15) * AGREED: Do not block on fedup signature checking (not a regression) (+:7, -:0, 0:0) (notting, 19:08:47) how is not providing a supported way to do secure upgrade of Fedora not a regression? If you read the IRC logs and not just the summary, this was all laid out there. It is part of the background in the bug: https://bugzilla.redhat.com/show_bug.cgi?id=877623#c13 There it is only mentioned, that there were possibilities to do insecure updates. The big change is, that now only insecure updates are possible. And what is even worse, the whole problem of not verifying packages on upgrade or the upgrade image itself is not even prominently communicated. There is nothing in the release notes about this: http://docs.fedoraproject.org/en-US/Fedora/18/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html#idm32350976 It would have been premature to put it in the release notes before this decision was made, obviously. What would've been the point of writing it into the release notes if FESCo had said 'this has to be fixed before we release F18'? Since the release notes for the Beta release point to the final release notes (as of yesterday they did actually point to the release notes for Fedora 13 in the wiki), it should be mentioned there already. It can still be removed if it is to be fixed. You nominated the bug as requiring a release note on 29th November, then complained that it wasn't in the release notes on 7th December - basically you gave the docs team about a week of turnaround time, which isn't a heck of a lot with a release with as many changes as F18. The whole update process and procedure using fedup is afaik not even properly designed or communicated. If I remember correctly for a long time only vague information about a new update tool to be written were posted to the devel list. And even now it is totally unclear how it will work. On the other hand the Beta should be used for upgrade testing. Publishing it before it is ready and all information is available is the problem. If more time is needed to properly document it, then the time should be taken instead of releasing the Beta without proper documentation. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Wed, Dec 05, 2012 at 03:20:14PM -0500, Bill Nottingham wrote: * 960 - F18 schedule + the holidays (notting, 18:50:29) * LINK: https://fedoraproject.org/wiki/JaroslavReznik/FedupF18Final - not updated yet (jreznik, 18:58:15) * AGREED: Do not block on fedup signature checking (not a regression) (+:7, -:0, 0:0) (notting, 19:08:47) how is not providing a supported way to do secure upgrade of Fedora not a regression? It is a big disappointment that Fedora is more and more turning its back on security. If I remember correctly, Fedora was one of the leading distributions providing and using signed packages. But with time this is more and more invalidated and people are more and more expected to install unsigned packages or not to verify them. At least back in 2010 malicious mirrors were still acknowledged as a security risk for Fedora users and signed packages were mentioned as a counter measure: https://fedoraproject.org/wiki/Mirror_manager_security_risks How come it became less important now? Actually it is even easier to attack users as more and more mobile devices are used. And what is even worse, the whole problem of not verifying packages on upgrade or the upgrade image itself is not even prominently communicated. There is nothing in the release notes about this: http://docs.fedoraproject.org/en-US/Fedora/18/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html#idm32350976 I am very disappointed about this and I think this this a bad decission. :-( Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)
On Fri, Dec 07, 2012 at 02:28:16PM -0500, Matthew Miller wrote: On Fri, Dec 07, 2012 at 08:11:08PM +0100, Till Maas wrote: * 960 - F18 schedule + the holidays (notting, 18:50:29) * LINK: https://fedoraproject.org/wiki/JaroslavReznik/FedupF18Final - not updated yet (jreznik, 18:58:15) * AGREED: Do not block on fedup signature checking (not a regression) (+:7, -:0, 0:0) (notting, 19:08:47) how is not providing a supported way to do secure upgrade of Fedora not a regression? It is a big disappointment that Fedora is more and more I assume because Anaconda has never done this. (Our dear old friend bug #998.) Anaconda only needs to do this, if it is used for network installs. But it was always possible to verify the DVD image and use the verified packages from there: https://fedoraproject.org/verify Some people even bothered to change the process from using MD5 or SHA1 to using SHA256 in the past. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide
On Sat, Nov 03, 2012 at 06:32:20PM -0600, Kevin Fenzi wrote: So, I have been thinking about rawhide. I agree identifying the problems/issues would be good, and I think there's something we can do to help with that: Get a nice group of at least 10 or so folks who are active on this list to agree to run it full time on their main machine. Rawhide is not intended to be used for anything important and with any security sensitive data because the used packages are not signed. Whenever I asked to get Rawhide packages signed I was also told that it is, because of Rawhide's use case. Everybody using Rawhide for example to maintainer Fedora packages is endangering the Fedora project. Nevertheless, I still believe it would be better if Fedora started to provide signed packages directly from Koji including Rawhide to end this problem. But looking at the current fedup code it seems that Fedora is going to be the first distribution that abandons package security more and more instead of trying to improve it. As far as I know starting with preupgrade doing insecure updates were promoted and now they are going to be made mandatory (except for the unsupported yum update method). Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revamping the non responsive maintainer process
On Fri, Nov 02, 2012 at 06:12:02PM +, Jóhann B. Guðmundsson wrote: On 11/02/2012 06:05 PM, Jon Ciesla wrote: No, they might simply have had nothing to do. Sometimes applications are stable, have no releases, and have no bugs files against them. sigh Then those individuals would simply respond to the email that that was the case and they are still alive and active within the project and they might even have to take an step and simply login to prevent them from being ping next time the cron-job runs . Seriously we can just cross that bridge if and when that case happens that surely beats doing nothing as things stand now Have fun bringing up all the hypothetical issue in the world, I however got better things to do with my time than trying to convince people that is extremely necessary and deal with any hypothetical issue that might arise should we try to automate that process... The easiest thing to convince people is to propose a concrete proposal for the time frame and show numbers of how many false positives this would lead to. Some information about how many packagers were inactive for how long would be helpful, too. All this information would be easy to get with the cron job script, which needs to be written anyway. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps for Fedora Security Lab
Hi, On Sun, Oct 21, 2012 at 02:36:49PM +0200, Fabian Affolter wrote: The Fedora Security Lab is an official spin since Fedora 13. So far all packages are handled direct in the kickstart file which is not very handy if you want to install the packages from a running Fedora installation. I would like to include the Security Lab tools into comps for F19. This way the FSL can stand shoulder-to-shoulder with the Fedora Electronic Lab, the Robotics Spin, and others. Objections, comments? I tried to put security related tools into useful comps categories a while ago and it was highly objected by Bill Nottingham iirc. Before you put any work into it, it might be better to first make sure that he (or whoever now overviews comps) noticed your attempt. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On Tue, Oct 09, 2012 at 07:51:30PM +0200, Lennart Poettering wrote: To summarize: Previously: /var/log/secure readable only for root, /var/log/messages readable for everybody and including data from everybody. Currently (Fedora 17 and before) /var/log/message is only readably by root. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Unresponsive maintainer Jef Spaleta - Unpushed security update for 91 days
Hi, I noticed that the revelation security update was not pushed to stable. It is now 91 days old, which makes me suspect that Jef is somehow hindered to take care of it: https://admin.fedoraproject.org/updates/FEDORA-2012-10269/revelation-0.4.14-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-10314/revelation-0.4.14-1.fc16 I remember he was very eager to push it in a timely manner. I already wrote an e-mail to revelation-owner at 21 August. Can someone with the appropriate permissions please push the updates to stable? It might also be a good idea to look after his 18 other packages: https://admin.fedoraproject.org/pkgdb/users/packages/jspaleta?acls=owner Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why is not enabled TapButton of touchpad on Fedora by default?
On Thu, Sep 27, 2012 at 02:47:47PM +0200, drago01 wrote: On Thu, Sep 27, 2012 at 2:34 PM, Tomas Radej tra...@redhat.com wrote: I don't expect much of a consensus to arise around this point, so I suggest we check if in the main environments, the tap-to-click setting is easily accessible and user-friendly. This state won't bother people who have problems with tap-to-click, and won't pose problems for people who want to have it on. I think that it's safe to assume that if the user installed Fedora successfully, they realize that to enable clicking with their touchpad, they need to go to Mouse/Touchpad settings and set it there in a checkbox. The problem with your argument is that it can go with both directions. We can have it enabled by default and in case the user is annoyed by it he/she can turn it off. It is easier to enable something that is missing than to disable some annoying behaviour whose cause is unknown. For example if you miss tap-to-click, you know what you need to search for to enable it. If the touchpad behaves strange because of accidental clicks, it is not that clear whether this is a bad setting or a hardware or software defect. This has already manifested for me with the slow keys feature that GDM enables and makes one believe that the keyboard died. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why is not enabled TapButton of touchpad on Fedora by default?
On Thu, Sep 27, 2012 at 05:42:47PM +0200, drago01 wrote: Not buying that. If you tap and nothing happens you may also think that something is broken why does my touchpad not work ... this is even more likely then your scenario. So this argument is flawed as well. You know more that it is broken. You know then the tap-to-click feature is missing and have a clear and reproducible error report I tap on the touchpad and the click is not noticed. It is a lot easier to notice that something is missing and to describe it than to notice that something is there that is sometimes causing trouble. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bohdi AutoQA: depcheck test FAILED
Aloas, On Tue, Aug 21, 2012 at 10:22:10AM -0400, Kamil Paral wrote: hi, i need help, because the AutoQA DepCheck fails on the package speed-dreams,but the package was pushed anyway. AutoQA DepCheck log: http://autoqa.fedoraproject.org/results/418027-autotest/virt04.qa/depcheck/results/speed-dreams-2.1.0-1.html the problem was already discussed on http://forums.fedoraforum.org/showthread.php?t=283254page=2 Depcheck fails, because your x86_64 package requires a dependency that is not available: $ yum provides 'libenet-1.3.3.so' Loaded plugins: changelog, langpacks, refresh-packagekit, remove-with-leaves, show-leaves No Matches found actually speed-dreams requires libenet-1.3.3.so()(64bit) according to http://koji.fedoraproject.org/koji/rpminfo?rpmID=3307869 which is provided by enet-1.3.3-1.fc17.x86_64 as yum shows: yum provides 'libenet-1.3.3.so()(64bit)' Loaded plugins: etckeeper, langpacks, presto, refresh-packagekit enet-1.3.3-1.fc17.x86_64 : Thin, simple and robust network layer on top of UDP Repo: fedora Matched from: Provides: libenet-1.3.3.so()(64bit) In conclusion there seems to be a bug in AutoQA. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Updated list (was: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18)
Here is an updated list: Package boolstuff (orphan) Package cmucl (orphan) comaintained by: green Package globalplatform (orphan) Package gpshell (orphan) Package gtkmm-utils (orphan) Package hamster-applet (orphan) Package hartke-aurulent-sans-fonts (orphan) Package json (orphan) Package k12linux-quick-start-guide (orphan) Package krecipes (orphan) Package libsoup22 (orphan) Package luakit (orphan) Package man-pages-it (orphan) Package mingw-libp11 (orphan) comaintained by: rjones Package mingw-opensc (orphan) comaintained by: rjones Package nzbget (orphan) Package perl-Nagios-Plugin-Beanstalk (orphan) Package pfqueue (orphan) Package polyester (orphan) Package polyester3 (orphan) Package python-chm (orphan) Package rubygem-archivist (orphan) comaintained by: vondruch jzigmund Package typepad-motion (orphan) Package upstart (orphan) List of deps left behind by packages which are orphaned or fail to build: Removing: libsoup22 libopensync-plugin-syncml requires libsoup22-devel = 2.2.105-9.fc15 libsyncml requires libsoup-2.2.so.8 libsyncml requires libsoup22-devel = 2.2.105-9.fc15 Removing: python-chm archmage requires python-chm = 0.8.4-12.fc18 chm2pdf requires python-chm = 0.8.4-12.fc18 Removing: upstart clamav-milter-upstart requires /sbin/initctl clamav-scanner-upstart requires /sbin/initctl dhcp-forwarder-upstart requires /sbin/initctl ip-sentinel-upstart requires /sbin/initctl milter-greylist-upstart requires /sbin/initctl tor-upstart requires /sbin/initctl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Going to orphan: tritonus
On Fri, Jul 27, 2012 at 05:37:44PM +0200, Lukas Zapletal wrote: I'm going to orphan tritonus package, it's an old java audio api that does not build anymore on Rawhide and getting it working would require too much time on OpenJDK 1.7. This sounds more that it should be retired instead: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass rebuild for Fedora 18 Complete
On Wed, Jul 25, 2012 at 06:09:12PM +0200, Marcela Mašláňová wrote: On 07/25/2012 06:03 PM, Adam Jackson wrote: On Tue, 2012-07-24 at 18:11 -0500, Dennis Gilmore wrote: http://ausil.fedorapeople.org/f18-needsbuilt.html I found different problem. My packages at and cronie weren't build, there is no changelog about mass rebuild in their git. It looks like the list of packages for rebuild is not complete or something failed during mass rebuild. The script seems to be buggy. The rebuild of fwbuilder was also not catched (it happened on Mon, 23 Jul 2012 21:51:52 UTC and was still reported on 2012-07-25 00:30:38.680350 UTC). Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
wyrd/ocaml problem (was: Re: Mass rebuild for Fedora 18 Complete)
Hi, can someone tell me what is wrong with wyrd? build.log says (http://kojipkgs.fedoraproject.org//work/tasks/8809/4318809/build.log): | ocaml version is 4.00.0+beta2 | ocaml library path is /usr/lib/ocaml | configure: error: Wyrd requires OCaml version 3.08 or greater. The configure scripts uses the following code: 1781 # we extract Ocaml version number and library path 1782 OCAMLVERSION=`$OCAMLC -v | sed -n -e 's|.*version *\(.*\)$|\1|p' ` 1783 echo ocaml version is $OCAMLVERSION 1784 OCAMLLIB=`$OCAMLC -v | tail -n 1 | cut -f 4 -d ` 1785 echo ocaml library path is $OCAMLLIB 1786 1787 1788 # check for sufficient OCAMLVERSION 1789 OCAMLMAJORVERSION=`echo $OCAMLVERSION | cut -d '.' -f 1` 1790 OCAMLMINORVERSION=`echo $OCAMLVERSION | cut -d '.' -f 2` 1791 if test $OCAMLMAJORVERSION -lt 3 ; then 1792as_fn_error Wyrd requires OCaml version 3.08 or greater. $LINENO 5 1793 else 1794if test $OCAMLMINORVERSION -lt 8 ; then 1795 as_fn_error Wyrd requires OCaml version 3.08 or greater. $LINENO 5 1796fi 1797 fi As far as I can see it should test in line 1791 whether 4 is less than 3, which is not the case and therefore it should not fail. If you know how to fix this, you are welcome to fix it directly in the git repo. :-) Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wyrd/ocaml problem (was: Re: Mass rebuild for Fedora 18 Complete)
On Mon, Jul 23, 2012 at 08:03:42PM +0200, Michael Schwendt wrote: Hint: Focus on line 1794. Thank you, I somehow read it as it was meant. :-( Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Upstream Release Monitoring status posting
Hi, I was asked to send to send the status of the last run of the Upstream Release Monitoring tool to this list. It would consist of all lines in http://till.fedorapeople.org/tmp/cnucnu-last.log that mention that a package is outdated. Would you welcome this or find it disturbing? I think it would be too noisy, because currently it will contain about 500 packages where some are bogus. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
On Mon, Jul 09, 2012 at 08:40:23AM -0600, Kevin Fenzi wrote: On Mon, 09 Jul 2012 09:54:38 +0200 Matej Cepl mc...@redhat.com wrote: On 06/07/12 22:55, Bill Nottingham wrote: Package html401-dtds (orphan) comaintained by: gnat Does it mean, we won't have HTML 4.01 DTDs packaged in Fedora? That sounds bad. Also, how can orphan be comaintained? Won't comaintainer be automatically elevated to a maintainer? There's no setup to do that automatically, it's up to the comaintainer to note that the maintainer orphaned the package and take ownership. Normally you would think if you were co-maintaining something you would notice if it was orphaned I would think... Except that not everyone is perfect and it is easy to miss such pkgdb mails in case someone returns from vacation. Therefore I would like it more if these procedures would be adjusted to make it harder to fail, i.e. by explicitly addressing all co-maintainers when the retiring of orphaned packages is due. I believe I proposed this already at least once. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitoring temporary down
Hello, On Wed, May 30, 2012 at 09:43:48PM +0200, Till Maas wrote: due to the recent Bugzilla update Upstream Release Monitoring[0] cannot report bugs currently. I noticed that there has been some recent activity in python-bugzilla[1] that might fix this. [0] https://fedoraproject.org/wiki/Upstream_release_monitoring [1] https://fedorahosted.org/python-bugzilla/timeline python-bugzilla has been updated and the monitoring tool was adjusted to work again. But I noticed that monitoring fails for about 197 packages due to bad regular expressions, wrong URLs or unreachable upstream website. So please check if any of your packages are affected and fix the URL or regex. Here is a list sorted by package name in the second column with maintainers in the first and co-maintainers in the third column (generated with https://fedorahosted.org/fedora-packager/browser/src/fedoradev-pkgowners): sochotni aether mizdebsk mizdebsk apache-commons-csv java-sig,spike gil apache-commons-vfs java-sig,mizdebsk pschiffe aspell-af (none) pschiffe aspell-br (none) pschiffe aspell-cy (none) pschiffe aspell-el (none) pschiffe aspell-fr (none) pschiffe aspell-hr (none) pschiffe aspell-is (none) pschiffe aspell-nl (none) pschiffe aspell-no (none) pschiffe aspell-sv (none) sochotni async-http-client java-sig,mizdebsk mpreisle atlascpp atorkhov,bruno fabiand auto-nng (none) plautrba awstats timj verdurin BEDTools (none) ixs bitbake (none) thias blackbox (none) rishi bouml (none) rishi bouml-doc (none) josef btrfs-progs mmahut akurtakov byaccj dbhole mattdm calc mattdm mmahut cdk (none) volter clusterPy (none) rjones coccinelle (none) (orphan) compiz (none) sundaram cowsay ndim mlichvar dialog (none) pfrields drupal6-filefield pfrields asrob drupal7-workbench sdodson (orphan) ds9 mmahut karlik ekg2 (none) ueno emacs-common-ddskk i18n-team michich epdfview (none) peter erlang ndim,peter volter esniper (none) deji exaile (none) vcrhonek fetchmail pertusus tagoh fontconfig fonts-sig,pnemade,tagoh athimm freenx-server limb,scop lkundrak fusecompress lmacken rathann gabedit itamarjp sundaram ghasher (none) petersen ghc-hashtables haskell-sig twaugh ghostscript (none) limb giggle (none) (orphan) gimmage (none) (orphan) gnome-applet-netspeed belegdol huzaifas gnome-applet-sensors huzaifas,lucilanga rathann gnomeradio itamarjp hadess gstreamer-rtsp fabiand sandeen guilt (none) twaugh gutenprint jpopelka tagoh hanazono-fonts fonts-sig kevin heartbeat beekhof,lon jorton httpd hubbitus,jkaluza salimma ikarus (none) mjg impressive (none) psabata iproute jpopelka,rvokal,twoerner npajkovs iptraf (none) tomspur ipython mrunge,shahms,tomspur rakesh jed (none) davidcl jhdf5 (none) jussilehtola jmol (none) fnasser junit4 dwalluck,java-sig radekl kadu gajownik,radekl hannes keybinder (none) michich latencytop (none) jmoyer libaio (none) karsten libcap (none) jnovy libdb (none) elwell libfap (none) konradm libfplll (none) ankursinha libgexiv2 (none) ueno libhangul i18n-team,phuang,psabata,pwu jussilehtola libint (none) limb libmodelfile (none) pbrobinson libmx fabiand ensc libtasn1 tmraz bruno libwfut bruno,mpreisle,wart veillard libxml2 davidcl salimma lua-moonscript (none) orion maven-ant-tasks java-sig sgros mdk sgros melmorabity monochrome-icon-theme (none) sharkcz mtx (none) scop mysqltuner mhayden,wolfy omajid netbeans (none) jskarvad netsniff-ng fab (orphan) ntfsprogs (none) drago01 numlockx (none) (orphan) ocfs2-tools fabbione,mfasheh rakesh octave alexlan,jussilehtola,mmahut,orion,rakesh sailer octave-audio (none) jussilehtola octave-gsl (none) sailer octave-symbolic (none) olea OmegaT mtasaka (orphan) opencdk (none) vvitek openobex holtmann xavierb perl-App-SVN-Bisect perl-sig mmaslano perl-ExtUtils-MakeMaker-Coverage mmaslano,perl-sig,ppisar mmaslano perl-LDAP mmaslano,ppisar,psabata cheeselee perl-Linux-Inotify2 mmaslano,perl-sig,psabata xavierb perl-Linux-Pid (none) psabata perl-List-Compare mmaslano,perl-sig,psabata xavierb perl-Log-LogLite perl-sig xavierb perl-MIME-Charset perl-sig corsepiu perl-Module-Versions-Report mmaslano,perl-sig,psabata,xavierb (orphan) perl-MooseX-GlobRef-Object mmaslano,perl-sig ppisar perl-Perl-Critic-Compatibility mmaslano,perl-sig ppisar perl-RPM-VersionCompare perl-sig ppisar perl-smartmatch mmaslano,perl-sig ppisar perl-smartmatch-engine-core mmaslano,perl-sig corsepiu perl-Test-Email perl-sig xavierb perl-Test-Unit perl-sig xavierb perl-Text-Format (none) psabata perl-WWW-Curl perl-sig psabata perl-XML-Stream mmaslano,perl-sig itamarjp pg_top atorkhov cdamian php-symfony-symfony (none) alexlan picard (none) pfrields pioneers (none) limb pitivi company,hicham akurtakov pmd (none) fkooman proguard (none) jcapik psacct jcapik ivazquez purple-plugin_pack nushio sergiopr pyfits (none) jcollie pyflakes scop jussilehtola pygrace (none) tomspur pynac (none) tomspur python3-chardet (none) kylev python-beaker fschwarz,lmacken lmacken python
Re: Upstream Release Monitoring temporary down
On Thu, Jul 05, 2012 at 08:37:06AM -0700, Toshio Kuratomi wrote: On Thu, Jul 05, 2012 at 12:02:49AM +0200, Till Maas wrote: toshio python-docutils (none) toshio python-unicodenazi dmalcolm toshio trac-bazaar-plugin (none) At least these three seem to be working fine from cnucnu --shell. Perhaps it's a transient network timeout? This is strange, because I had to add the proper upstream name to the regex alias: https://fedoraproject.org/w/index.php?title=Upstream_release_monitoringaction=historysubmitdiff=294599oldid=294595 How did you test it? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitoring temporary down
On Thu, Jul 05, 2012 at 10:24:17AM -0600, Orion Poplawski wrote: On 07/04/2012 04:02 PM, Till Maas wrote: orion maven-ant-tasks java-sig This looks good to me and seems to work from cnucnu but I do get: Upstream Versions: ['2.0.10', '2.0.10', '2.0.6', '2.0.6', '2.0.7', '2.0.7', '2.0.8', '2.0.8', '2.0.9', '2.0.9', '2.1.0', '2.1.0', '2.1.1', '2.1.1', '2.1.2', '2.1.2', '2.1.3', '2.1.3'] Latest: 2.1.3 Fedora Rawhide Version: 2.1.1 9.fc17 (outdated) Actually there was trailing whitespace in the URL in the wiki: https://fedoraproject.org/w/index.php?title=Upstream_release_monitoringaction=historysubmitdiff=294600oldid=294599 You can use the data from the wiki in the cnucnu shell with inspect: | None None URL: inspect maven-ant-tasks But it might not work, if you do not do this as the first command. pycurl.error: (77, 'Problem with the SSL CA cert (path? access rights?)') never used cnucnu before so I don't know if this is normal. This happens, because it expects the Fedora Server CA file in the file fedora-server-ca.cert in the current directory to verify the SSL certificate of the git web interface. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitoring temporary down
Hi, To ease the debugging, I uploaded the output of the last run: http://till.fedorapeople.org/tmp/cnucnu-last.log Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitoring temporary down
Hello, On Wed, May 30, 2012 at 09:43:48PM +0200, Till Maas wrote: due to the recent Bugzilla update Upstream Release Monitoring[0] cannot report bugs currently. I noticed that there has been some recent activity in python-bugzilla[1] that might fix this. [0] https://fedoraproject.org/wiki/Upstream_release_monitoring [1] https://fedorahosted.org/python-bugzilla/timeline python-bugzilla has been updated and the monitoring tool was adjusted to work again. But I noticed that monitoring fails for about 197 packages due to bad regular expressions, wrong URLs or unreachable upstream website. So please check if any of your packages are affected and fix the URL or regex. Here is a list sorted by package name in the second column with maintainers in the first and co-maintainers in the third column (generated with https://fedorahosted.org/fedora-packager/browser/src/fedoradev-pkgowners): sochotni aether mizdebsk mizdebsk apache-commons-csv java-sig,spike gil apache-commons-vfs java-sig,mizdebsk pschiffe aspell-af (none) pschiffe aspell-br (none) pschiffe aspell-cy (none) pschiffe aspell-el (none) pschiffe aspell-fr (none) pschiffe aspell-hr (none) pschiffe aspell-is (none) pschiffe aspell-nl (none) pschiffe aspell-no (none) pschiffe aspell-sv (none) sochotni async-http-client java-sig,mizdebsk mpreisle atlascpp atorkhov,bruno fabiand auto-nng (none) plautrba awstats timj verdurin BEDTools (none) ixs bitbake (none) thias blackbox (none) rishi bouml (none) rishi bouml-doc (none) josef btrfs-progs mmahut akurtakov byaccj dbhole mattdm calc mattdm mmahut cdk (none) volter clusterPy (none) rjones coccinelle (none) (orphan) compiz (none) sundaram cowsay ndim mlichvar dialog (none) pfrields drupal6-filefield pfrields asrob drupal7-workbench sdodson (orphan) ds9 mmahut karlik ekg2 (none) ueno emacs-common-ddskk i18n-team michich epdfview (none) peter erlang ndim,peter volter esniper (none) deji exaile (none) vcrhonek fetchmail pertusus tagoh fontconfig fonts-sig,pnemade,tagoh athimm freenx-server limb,scop lkundrak fusecompress lmacken rathann gabedit itamarjp sundaram ghasher (none) petersen ghc-hashtables haskell-sig twaugh ghostscript (none) limb giggle (none) (orphan) gimmage (none) (orphan) gnome-applet-netspeed belegdol huzaifas gnome-applet-sensors huzaifas,lucilanga rathann gnomeradio itamarjp hadess gstreamer-rtsp fabiand sandeen guilt (none) twaugh gutenprint jpopelka tagoh hanazono-fonts fonts-sig kevin heartbeat beekhof,lon jorton httpd hubbitus,jkaluza salimma ikarus (none) mjg impressive (none) psabata iproute jpopelka,rvokal,twoerner npajkovs iptraf (none) tomspur ipython mrunge,shahms,tomspur rakesh jed (none) davidcl jhdf5 (none) jussilehtola jmol (none) fnasser junit4 dwalluck,java-sig radekl kadu gajownik,radekl hannes keybinder (none) michich latencytop (none) jmoyer libaio (none) karsten libcap (none) jnovy libdb (none) elwell libfap (none) konradm libfplll (none) ankursinha libgexiv2 (none) ueno libhangul i18n-team,phuang,psabata,pwu jussilehtola libint (none) limb libmodelfile (none) pbrobinson libmx fabiand ensc libtasn1 tmraz bruno libwfut bruno,mpreisle,wart veillard libxml2 davidcl salimma lua-moonscript (none) orion maven-ant-tasks java-sig sgros mdk sgros melmorabity monochrome-icon-theme (none) sharkcz mtx (none) scop mysqltuner mhayden,wolfy omajid netbeans (none) jskarvad netsniff-ng fab (orphan) ntfsprogs (none) drago01 numlockx (none) (orphan) ocfs2-tools fabbione,mfasheh rakesh octave alexlan,jussilehtola,mmahut,orion,rakesh sailer octave-audio (none) jussilehtola octave-gsl (none) sailer octave-symbolic (none) olea OmegaT mtasaka (orphan) opencdk (none) vvitek openobex holtmann xavierb perl-App-SVN-Bisect perl-sig mmaslano perl-ExtUtils-MakeMaker-Coverage mmaslano,perl-sig,ppisar mmaslano perl-LDAP mmaslano,ppisar,psabata cheeselee perl-Linux-Inotify2 mmaslano,perl-sig,psabata xavierb perl-Linux-Pid (none) psabata perl-List-Compare mmaslano,perl-sig,psabata xavierb perl-Log-LogLite perl-sig xavierb perl-MIME-Charset perl-sig corsepiu perl-Module-Versions-Report mmaslano,perl-sig,psabata,xavierb (orphan) perl-MooseX-GlobRef-Object mmaslano,perl-sig ppisar perl-Perl-Critic-Compatibility mmaslano,perl-sig ppisar perl-RPM-VersionCompare perl-sig ppisar perl-smartmatch mmaslano,perl-sig ppisar perl-smartmatch-engine-core mmaslano,perl-sig corsepiu perl-Test-Email perl-sig xavierb perl-Test-Unit perl-sig xavierb perl-Text-Format (none) psabata perl-WWW-Curl perl-sig psabata perl-XML-Stream mmaslano,perl-sig itamarjp pg_top atorkhov cdamian php-symfony-symfony (none) alexlan picard (none) pfrields pioneers (none) limb pitivi company,hicham akurtakov pmd (none) fkooman proguard (none) jcapik psacct jcapik ivazquez purple-plugin_pack nushio sergiopr pyfits (none) jcollie pyflakes scop jussilehtola pygrace (none) tomspur pynac (none) tomspur python3-chardet (none) kylev python-beaker fschwarz,lmacken lmacken python
Re: Support for legacy init script actions for systemd services
On Tue, Jun 26, 2012 at 04:11:19PM -0400, Bill Nottingham wrote: BEST PRACTICES 1) A legacy action of this sort should print to stderr the preferred way to accomplish the task, if one is supported. 2) Don't package a legacy action for new scripts or actions that were not supported by the prior init script; this is intended for compatibility with existing scripts and/or administrator brains. It would be nice to have a good plan about how to implement the preferred new way to accomplish such tasks to avoid that every package does this differently. Regards Till pgpc0j74AAVh9.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)
On Mon, Jun 18, 2012 at 01:10:34PM -0600, Kevin Fenzi wrote: * ticket 864 F18 Feature: DNF - https://fedoraproject.org/wiki/Features/DNF (nirik, 17:44:17) * AGREED: Feature is approved (+8/0) (nirik, 17:56:59) It would help a lot if a features are only approved, when they have descriptive names. From the message above it is completely unclear what was approved. But if the feature was named like for example DNF package manager preview there would be at least some information about what the DNF features is supposed to be. This is just an example, the other features could mostly be better named as well imho, for example the Clojure Feature as Full Clojure Stack. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)
On Tue, Jun 19, 2012 at 08:36:31AM -0400, Josh Boyer wrote: On Tue, Jun 19, 2012 at 8:30 AM, Thorsten Leemhuis fed...@leemhuis.info wrote: Josh Boyer wrote on 19.06.2012 13:42: Because you can't click on the link and read about the feature where it describes this in detail? You can, but immediately getting the most relevant information makes life a bit easier for those on the receiving side. That is a nice gesture and shows that you value the time and interest of the readers. For afaics similar reasons most people here (you including) trim email replies and reply inline, as that makes communication a little bit easier, which is nice in these hectic times. That's fine. I don't consider it something required for approval though. It's at best a filter so people don't click links they don't find interesting. A proper name also avoids confusion, for example when people usually use a three letter acronym like DNF for something else. Or as shown with the Clojure feature it creates confusion, because Clojure is already included in Fedora, but the feature is about including the full stack. Same with DNF if it will become the default, then using DNF again as a feature name would not work. The approval by FESCo is afaics the first time a feature gets properly announced. Therfore the title should be well chosen at that time already to avoid confusion by renaming the feature afterwards. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Upstream Release Monitoring temporary down
Hi everyone, due to the recent Bugzilla update Upstream Release Monitoring[0] cannot report bugs currently. I noticed that there has been some recent activity in python-bugzilla[1] that might fix this. Regards Till [0] https://fedoraproject.org/wiki/Upstream_release_monitoring [1] https://fedorahosted.org/python-bugzilla/timeline pgpJ3wBvtx2pd.pgp Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Upstream Release Monitoring temporary down
Hi everyone, due to the recent Bugzilla update Upstream Release Monitoring[0] cannot report bugs currently. I noticed that there has been some recent activity in python-bugzilla[1] that might fix this. Regards Till [0] https://fedoraproject.org/wiki/Upstream_release_monitoring [1] https://fedorahosted.org/python-bugzilla/timeline pgpOAEJqERwFt.pgp Description: PGP signature ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Re: /usr/sbin/validate clash with /usr/bin/validate
On Wed, May 23, 2012 at 02:33:11PM -0400, Adam Jackson wrote:
We're (sort of) trying to phase out /usr/libexec in favor of
%{_libdir}/%{name}/foo, but otherwise that sounds good.
But then the location if a command will depend on whether the system is
a 64 or 32 bit system, which makes it more error prone to write software that
uses such commands on both kind of systems.
Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/sbin/validate clash with /usr/bin/validate
On Thu, May 24, 2012 at 09:13:51AM -0400, Adam Jackson wrote:
On 5/24/12 7:50 AM, Till Maas wrote:
But then the location if a command will depend on whether the system is
a 64 or 32 bit system, which makes it more error prone to write software that
uses such commands on both kind of systems.
libexecdir is already a macro expanded at build time. If you were
hardcoding /usr/libexec you were already broken on non-Red-Hat-like
Linuxes. Don't let already being broken be an excuse for continuing
to be broken.
Using /usr/libexec in a noarch Fedora package did always work. But if
binaries are in %{_libdir}, a noarch package cannot always contain the
correct path, because the noarch package is the same for both 32 and 64
bit systems. I did not know that debian or other distros do not use
/usr/libexec, but I believe that debian uses /usr/lib for both 32 and 64
bit systems, so using /usr/lib/name/ will work on both archs.
Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On Thu, Apr 12, 2012 at 04:57:29PM -0400, Tom Callaway wrote: Packages which have SysV initscripts that contain 'non-standard service commands' (commands besides start, stop, reload, restart, or try-restart) must convert those commands into standalone helper scripts. Systemd does not support non-standard unit commands. https://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files The guideline for SysV initscripts[0] also specifies the commands force-reload, status and usage. Why are these dropped? Also how should new helper scripts be named after the conversion? A best practice naming schema would make it a lot easier for a user to find the matching helper script for removed commands. Regards Till [0] http://fedoraproject.org/wiki/Packaging:SysVInitScript#Required_Actions -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Repost] What is Error: Protected multilib versions
On Thu, Apr 05, 2012 at 06:54:36PM +0100, Richard W.M. Jones wrote: Is there any information about when this should be used? I don't think I've ever written a spec file that uses it. I think it is whenever a package containing a library (i.e. a multilib package) is required via the package's name, then it needs to be used due to multilib. Btw. is there an easy way to get a list of all packages that are multilib? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION NO LONGER REQUIRED] Retired packages for F-17
On Mon, Mar 05, 2012 at 06:36:23PM +, Peter Robinson wrote: On Mon, Mar 5, 2012 at 4:13 PM, Bill Nottingham nott...@redhat.com wrote: Peter Robinson (pbrobin...@gmail.com) said: It was my understanding that packages that are FTBFS prior to F-15 (ie not had a successful build in F-15 or later) It's done off the F15FTBFS bug. If these don't have bugs blocking that, they won't get picked up. Right, I did that from koji, not sure how the ftbfs bug was done. At least for aircrack-ng from your list no FTBFS bug has been filed, therefore I do not see any reason to remove it from Fedora. And in case it really does not build, I expect a bug report. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION NO LONGER REQUIRED] Retired packages for F-17
On Wed, Mar 07, 2012 at 06:19:39PM +, Peter Robinson wrote: There hasn't been FTBFS bug reports since Matt stopped doing them due to lack of time, the maintainer would have got failed builds for the mass rebuild and should have investigated as part of maintaining the package. Is this official? Then it should be announced and mentioned in the wiki: https://fedoraproject.org/wiki/Fails_to_build_from_source From what I understand from this thread and the wiki, it does not all fit, because there is for example a F16FTBFS tracker bug, therefore a bug for aircrack-ng should have existed. Nevertheless, missing one mail can easily happen, especially when one was not regularly online at the time of the mass rebuild. Therefore I still think it should be mandatory to first file a bug before a package is removed due to FTBFS issues. And as long as it is possible to create a list of affected packages to remove them, it is only little harder to report bugs for them first. Something like this would work: for package in $(cat packages.txt); do bugzilla new --component $package --product Fedora --version RAWHIDE --summary $package fails to build from source --comment $package fails to build from source. Please fix this, otherwise the package is going to be removed on 2012-04-01. See http://example.com/ for more information Btw. I just re-built aircrack-ng. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On Tue, Jan 24, 2012 at 07:13:03AM -0500, Josh Boyer wrote: Or perhaps better asked, what about rawhide makes it unsuitable for use as a rolling Fedora release? The rpm packages in Rawhide are not signed. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: %bcond_with is backwards?
On Thu, Dec 08, 2011 at 06:10:17PM +, Richard W.M. Jones wrote:
# conditionalize Ocaml support
%ifarch sparc64 s390 s390x
%bcond_with ocaml
%else
%bcond_without ocaml
%endif
#...
%if %{with ocaml}
BuildRequires: ocaml
BuildRequires: ocaml-findlib-devel
%endif
This code correctly disables OCaml support on architectures where we
don't bother to compile OCaml (sparc64 s390 s390x). But the
conditional code looks backwards to me. Does this make sense to
anyone?
It makes sense when you read %bcond_with ocaml as 'add a
--with-ocaml build condition flag' to the spec.
Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Tue, Nov 22, 2011 at 05:32:56PM +0100, Vít Ondruch wrote: It would be reasonable, on the beginning of each development cycle, to publish a list of packages which were not touched by it maintainer in previous release. For all these packages, new co-maintainer could stepped up and they would be granted the co-maintainers privileges automatically. There are several packages I am the main maintainer of, but do not need any work from my side during a new release. Iirc at least for one package the co-maintainer usually updates it. So what is broken here? Imho the focus should be on untouched important bugs. If they pile up, then the maintainer needs help. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Tue, Nov 22, 2011 at 11:05:37AM -0600, Richard Shaw wrote: 2011/11/22 Bruno Wolff III br...@wolff.to: One area where we could probably do more advertising for is getting new packagers via the co-maintainer route. I think most of the new packagers still come in by packaging a new package. I think we really want most of the new packagers coming in as co-maintainers. Yes, this seems to be an chicken-or-the-egg issue. There seems to be permanent resource shortages with package maintenance which means we need more contributors, and then at the same time there are hundreds of package reviews languishing, many of which need sponsors. I don't want to get too far off topic but being short handed is directly related... Does the sponsor processes need to be more formalized? Currently you must be nominated (either by someone or yourself) but there's no concrete requirements on a knowledge or skill level required to be a sponsor. To bring it to a more personal level, I have no idea if I've done or proven myself enough to become a sponsor or not. If I am deficient in an area, there's currently no formal feedback mechanism for me to know in what areas I need to improve. What helped me was first to find someone I wanted to sponsor. I would like to sponsor someone else, but looking through the review tickets I hardly find any potential new contributor that performed informal reviews as stated in the wiki. Or at least there was not trace of the informal reviews in the review ticket. Back to the question: I guess the main skill needed is to be able to monitor the sponsoree's activities and to identify bad behaviour. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 01:21:40PM -0500, Josh Boyer wrote: We have considered it. A really long time ago. At that time, it was decided that we consider out-of-tree modules to be something we don't support, don't care about, and won't hold up updates for because of the aforementioned heavier considerations of fixing bugs. So, with that phrasing in mind, everything is compliant with what you're saying about the updates policy. Nevertheless it would have been nice to mention that the kernel update will actually break the VirtualBox kernel module in it's update notes as it seems to me that a lot of people knew it and even the problematic change was mentioned in the update's feedback. Maybe now this thread can end, because it's really not accomplishing anything at all. If we wanted to sit around and practice wordsmithing, there are much better places and topics to do it with. What about this suggestion by Josh Stone? This seems to be a good result from the discussion: http://lists.fedoraproject.org/pipermail/devel/2011-November/159818.html | On 11/22/2011 09:51 AM, Michael Cronenworth wrote: | -#if LINUX_VERSION_CODE KERNEL_VERSION(3, 1, 0) | | It may have be helpful for the faked 2.6.4x kernels to still present a | 3ish LINUX_VERSION_CODE. AFAIK, faking the number is for the benefit of | userspace, not any kernel module. Perhaps it's not too late? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Tue, Nov 22, 2011 at 11:51:52AM -0700, Kevin Fenzi wrote: On Mon, 21 Nov 2011 23:40:52 +0100 Till Maas opensou...@till.name wrote: On Mon, Nov 21, 2011 at 02:03:43PM -0800, Jesse Keating wrote: This has come up nearly every release cycle. Problem is that nobody can seem to agree on what an appropriate sign of life would be, no has made a serious FESCo proposal for a contrived sign of life. I remember that there has been a script that checked the health status of packages in Fedora by examining when the last build happened and maybe other facts. What happened to it? I came up with the idea, but have had no time to implement it. Folks who wish to actually commit to time to work on this, please let me know and I would be happy to help out as my time permits. But I remember reports that contained similar information. Therefore some kind of script must have existed. Maybe it was related to some FTBFS reports where someone else reported that his script would have reported certain packages to be unmaintained as well. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A Glorious Vision of Our Shared Update Feedback Future (bodhi, karma, and proventesters, oh my)
On Tue, Nov 22, 2011 at 01:03:05PM -0800, Adam Williamson wrote: * The list of test cases associated with the package, with a PASS / FAIL choice for each A Did not test choice is missing here. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Mon, Nov 21, 2011 at 02:03:43PM -0800, Jesse Keating wrote: This has come up nearly every release cycle. Problem is that nobody can seem to agree on what an appropriate sign of life would be, no has made a serious FESCo proposal for a contrived sign of life. I remember that there has been a script that checked the health status of packages in Fedora by examining when the last build happened and maybe other facts. What happened to it? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swap
Hi, I want to offer a review swap for hxtools: https://bugzilla.redhat.com/show_bug.cgi?id=683610 It is a dependency I need to update and probably fix several bugs in pam_mount. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On Tue, Oct 25, 2011 at 01:45:45PM +0200, Christoph Trassl wrote: On 10/25/2011 09:33 AM, Michal Hlavinka wrote: On 10/25/2011 09:30 AM, Harald Hoyer wrote: On 10/25/2011 09:15 AM, Harald Hoyer wrote: It's not only an aesthetic issue. This enables possibilities, which were not doable before. ... - mount rootfs encrypted - mount /usr not encrypted (no secrets here) this is already possible, I use this setup for a long time. Does not seem to make any sense to me, unless you verify that no one has messed with your binaries/libraries in /usr. Does not seem to make any sense to me, unless you verify that no one has messed with your kernel/bootloader in /boot or /dev/sda. Kind regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On Tue, Oct 25, 2011 at 06:41:21PM +0200, Christoph Trassl wrote: On 10/25/2011 05:30 PM, Till Maas wrote: On Tue, Oct 25, 2011 at 01:45:45PM +0200, Christoph Trassl wrote: On 10/25/2011 09:33 AM, Michal Hlavinka wrote: On 10/25/2011 09:30 AM, Harald Hoyer wrote: On 10/25/2011 09:15 AM, Harald Hoyer wrote: It's not only an aesthetic issue. This enables possibilities, which were not doable before. ... - mount rootfs encrypted - mount /usr not encrypted (no secrets here) this is already possible, I use this setup for a long time. Does not seem to make any sense to me, unless you verify that no one has messed with your binaries/libraries in /usr. Does not seem to make any sense to me, unless you verify that no one has messed with your kernel/bootloader in /boot or /dev/sda. Correct. Verifying the kernel/bootloader could easily been done within seconds - at every boot. Yet as long as it is not done, encrypting /usr is no improvement. And even if it is done, you would also need to verify that nobody installed a keyboard logger on your device if your fear attackers that have easily physical access to the device in question. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitor
On Wed, Oct 12, 2011 at 03:06:46PM +1000, Peter Hutterer wrote: out of interest - are there any plans to auto-close bugs once the new version hits rawhide? No, this is not planned. But you do not need to close bugs, because old bugs are re-used unless they changed status. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox on Fedora: No longer funny
On Tue, Oct 11, 2011 at 10:49:54AM -0700, Adam Williamson wrote: There obviously is a _legitimate_ question as to whether you ought to be able to add your package into anyone else's update if you aren't a provenpackager; it's not necessarily something we'd want to do. But I think provenpackagers probably should be allowed to edit any update. There is an easy to answer question whether package maintainers should be able to specify that a certain build needs to be pushed to stable when some other build is pushed to stable. It is a different question whether the current model of grouping builds together as an update is a good idea. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitor
Hi, On Tue, Oct 11, 2011 at 09:35:33AM -0500, Nathan O. wrote: I am curious or maybe giving an idea, but I have my package listed there and currently there is an update for the package I have added to the list. Well I have the package in bodhi, which I believe is in testing right now. The problem is that the URM(Upstream release monitoring) keeps opening a new bug saying there is a new version available, so I have to keep closing them as duplicates. I think that it should only report it once for each new version or until maybe the previous bug report says ON_QA. usually only one bug report per version is created. I did not find the reason why several bugs were reported for worker. Nevertheless I noticed that an old version of the reporting tool was running that did not abort bug reporting when the upstream version was found in the sources file in Fedora's SCM. This is now fixed. If you note that more than one bug per upstream version is reported again, please tell me. Kind regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitor
On Tue, Oct 11, 2011 at 03:07:11PM -0500, Nathan O. wrote: Thanks for all the help, and glad it seemed to help you find a issue with URM, Till Thank you for the report. I dug a little deeper and identified and fixed the bug that was responsible for the multiple bug reports. Kind regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
