Re: [arch-dev-public] providing grsecurity in [community]
In data domenica 20 aprile 2014 18:40:15, Gaetan Bisson ha scritto: What part of do it in a separate repo for the time being didn't you understand and/or like? That solution seemed to make everyone happy... Actually it only made happy the developers/tu that didn't care one bit about grsecurity. I surely am not happy about that solution and others have expressed concerns about this (Bartłomiej Piotrowski and Connor Behan come to mind) so I am not sure who is here that is ignoring feedback... -- Massimiliano mtorromeo Torromeo Arch Linux TU GPG: 0xDA2EE423 signature.asc Description: This is a digitally signed message part.
[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 20 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 4 fully signed off packages * 40 packages missing signoffs * 2 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (20 total) == * syslinux-6.03pre11-1 (i686) * syslinux-6.03pre11-1 (x86_64) * apr-1.5.1-1 (i686) * colord-1.2.0-1 (i686) * colord-gtk-0.1.25-2 (i686) * gnome-color-manager-3.12.1-2 (i686) * gnome-control-center-3.12.1-2 (i686) * gnome-settings-daemon-3.12.1-2 (i686) * gtk3-3.12.1-2 (i686) * refind-efi-0.7.9-1 (i686) * slim-1.3.6-4 (i686) * apr-1.5.1-1 (x86_64) * colord-1.2.0-1 (x86_64) * colord-gtk-0.1.25-2 (x86_64) * gnome-color-manager-3.12.1-2 (x86_64) * gnome-control-center-3.12.1-2 (x86_64) * gnome-settings-daemon-3.12.1-2 (x86_64) * gtk3-3.12.1-2 (x86_64) * refind-efi-0.7.9-1 (x86_64) * slim-1.3.6-4 (x86_64) == Incomplete signoffs for [core] (13 total) == * man-pages-3.65-1 (any) 1/2 signoffs * bash-4.3.011-1 (i686) 0/1 signoffs * btrfs-progs-3.14.1-1 (i686) 0/1 signoffs * gawk-4.1.1-1 (i686) 0/1 signoffs * grub-1:2.02.beta2-3 (i686) 0/1 signoffs * readline-6.3.005-1 (i686) 0/1 signoffs * syslinux-6.03pre11-1 (i686) 0/1 signoffs * btrfs-progs-3.14.1-1 (x86_64) 0/2 signoffs * cronie-1.4.11-2 (x86_64) 1/2 signoffs * gawk-4.1.1-1 (x86_64) 1/2 signoffs * grub-1:2.02.beta2-3 (x86_64) 1/2 signoffs * openssh-6.6p1-2 (x86_64) 1/2 signoffs * syslinux-6.03pre11-1 (x86_64) 0/2 signoffs == Incomplete signoffs for [extra] (27 total) == * flickrnet-3.10.0-1 (any) 0/2 signoffs * apr-1.5.1-1 (i686) 0/1 signoffs * colord-1.2.0-1 (i686) 0/1 signoffs * colord-gtk-0.1.25-2 (i686) 0/1 signoffs * gnome-color-manager-3.12.1-2 (i686) 0/1 signoffs * gnome-control-center-3.12.1-2 (i686) 0/1 signoffs * gnome-settings-daemon-3.12.1-2 (i686) 0/1 signoffs * gtk3-3.12.1-2 (i686) 0/1 signoffs * kdebase-runtime-4.13.0-3 (i686) 0/1 signoffs * libreoffice-4.2.4-0.1 (i686) 0/1 signoffs * libssh-0.6.3-1 (i686) 0/1 signoffs * qemu-2.0.0-2 (i686) 0/1 signoffs * refind-efi-0.7.9-1 (i686) 0/1 signoffs * slim-1.3.6-4 (i686) 0/1 signoffs * apr-1.5.1-1 (x86_64) 0/2 signoffs * colord-1.2.0-1 (x86_64) 0/2 signoffs * colord-gtk-0.1.25-2 (x86_64) 0/2 signoffs * gnome-color-manager-3.12.1-2 (x86_64) 0/2 signoffs * gnome-control-center-3.12.1-2 (x86_64) 0/2 signoffs * gnome-settings-daemon-3.12.1-2 (x86_64) 0/2 signoffs * gtk3-3.12.1-2 (x86_64) 0/2 signoffs * kdebase-runtime-4.13.0-3 (x86_64) 0/2 signoffs * libreoffice-4.2.4-0.1 (x86_64) 0/2 signoffs * libssh-0.6.3-1 (x86_64) 0/2 signoffs * qemu-2.0.0-2 (x86_64) 0/2 signoffs * refind-efi-0.7.9-1 (x86_64) 0/2 signoffs * slim-1.3.6-4 (x86_64) 0/2 signoffs == Completed signoffs (4 total) == * cronie-1.4.11-2 (i686) * openssh-6.6p1-2 (i686) * bash-4.3.011-1 (x86_64) * readline-6.3.005-1 (x86_64) == All packages in [testing] for more than 14 days (2 total) == * grub-1:2.02.beta2-3 (i686), since 2014-04-07 * grub-1:2.02.beta2-3 (x86_64), since 2014-04-07 == Top five in signoffs in last 24 hours ==
Re: [arch-dev-public] providing grsecurity in [community]
[2014-04-22 09:30:34 +0200] Massimiliano Torromeo: I surely am not happy about that solution and others have expressed concerns about this (Bartłomiej Piotrowski and Connor Behan come to mind) so I am not sure who is here that is ignoring feedback... Here on earth, Bartłomiej (who said nothing against separate repos) and the guy who breaks every thread he replies to are just two people out of ten in this discussion. And why didn't you chime in and gave us your arguments against separate repos? How relevant is it whether you are happy or not if you said nothing of it in the discussion?!? You can pull all the excuses you want, but no consensus was reached. Pressing ahead with something so controversial while the discussion is still going on is a plain and simple lack of respect for the opinion and advice of fellow developers and TUs. -- Gaetan pgpVckF0kEFKE.pgp Description: PGP signature
Re: [arch-dev-public] providing grsecurity in [community]
In data lunedì 21 aprile 2014 22:24:26, Gaetan Bisson ha scritto: Here on earth, Bartłomiej (who said nothing against separate repos) and the guy who breaks every thread he replies to are just two people out of ten in this discussion. And why didn't you chime in and gave us your arguments against separate repos? How relevant is it whether you are happy or not if you said nothing of it in the discussion?!? Because I simply agreed with points already expressed by others and I didn't think +1s would help the discussion. In data sabato 19 aprile 2014 11:11:18, Connor Behan ha scritto: Hah. I would just like to add that unofficial repositories are usually a dead end. 1. Maintainer adds kernel to his own repository and tries to advertise it in the forums. 2. Only 10 people install it. 3. Maintainer decides it's not worth the work and takes down the repo. With [community] there is a much higher probability that packages will be popular and maintained for awhile. This is the quote I remembered agreeing with. And looking back at the discussion I have to admit that Bartłomiej didn't really argument against separate repo but expressed his desire for grsec in [community] instead. You can pull all the excuses you want, but no consensus was reached. Pressing ahead with something so controversial while the discussion is still going on is a plain and simple lack of respect for the opinion and advice of fellow developers and TUs. I am not saying that consensus was reached because it definetely was not, but at the same time I also don't feel like there is any need for consensus here as it seems to me that this is a package just like any other. Feedback was requested and taken into consideration, concerns were addressed and, as explained, this ended up being a self-contained package. If this results in problems that have not been considered it can be easily removed. -- Massimiliano mtorromeo Torromeo Arch Linux TU GPG: 0xDA2EE423 signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] providing grsecurity in [community]
On Tue, Apr 22, 2014 at 10:44 AM, Massimiliano Torromeo massimiliano.torro...@gmail.com wrote: In data lunedì 21 aprile 2014 22:24:26, Gaetan Bisson ha scritto: Here on earth, Bartłomiej (who said nothing against separate repos) and the guy who breaks every thread he replies to are just two people out of ten in this discussion. And why didn't you chime in and gave us your arguments against separate repos? How relevant is it whether you are happy or not if you said nothing of it in the discussion?!? Because I simply agreed with points already expressed by others and I didn't think +1s would help the discussion. If that helps I'm giving my +1 for having it community as long as there's no need for additional work from other maintainers. grsecurity is a nice and useful patchset and having it in community reduces the cost of deploying it. What is also important is that it would make it more visible to the users. Nobody ever uses binary repositories apart from the officially supported ones and possibly arch-haskell, which is quite specific in that it is not very useful for an ordinary user, but which is great for devs already using haskell. Lukas
Re: [arch-dev-public] providing grsecurity in [community]
Lets not draw this out too much further. I don't want to have to unsubscribe from another mailing list... But I am still going to have my say! 1) This was different than every other package in [community]. I know this because packages get added to [community] all the time without an email here. And saying discussion about adding PaX extensions was makes it different is naive as anyone who has been around here a short time could tell you that was never going to happen. 2) A few years back we specifically reduced the number of kernels in our repos to one. Then the LTS kernel appeared. Now this. The problem with adding a non-vanilla kernel to the repos is now for kernel bug reports we have to verify which kernel is running. If it is linux-grsec, we then need to figure out if the issue a generic linux one, or with the other patchset. This is a burden to all our the kernel maintainers and not just the packager and is part of the reason the variety of kernels was reduced. 3) Now this is in [community] there will be an expectation of providing all the extras that are supposed to come with this. As decided, this will not be happening, but it will be expected and the question will need to be answered repeatedly. 4) A separate repo would have given actual number for interest in this. We all know the number of votes in the AUR is a crap metric and could have accumulated a long time ago. It would also have allowed us to see how important the above issues are. Despite assertions, many binary repos are well used by the Arch community. 5) There were objections to it being included in our binary repos. This does not happen often, but we usually discuss further and come to a consensus about inclusion. Ignoring those objections is not how our team works. Given the relatively few people who responded to the thread, we have no real idea what the support was (and I can provide unsupported anecdotes for support against or for inclusion of the package as well as the next person can...) In conclusion, this should have waited before being put in the repo. It might have ended up there anyway, it might not have. And I can not be bothered figuring it out as it will not affect me in any way. Allan
Re: [arch-dev-public] providing grsecurity in [community]
In data martedì 22 aprile 2014 20:03:38, Allan McRae ha scritto: Lets not draw this out too much further. I don't want to have to unsubscribe from another mailing list... But I am still going to have my say! Several valid points worth discussion have been raised in this thread, even with the rough last bits I think it was worth evaluating. It's your choice if you want to unsubscribe from here of course... 1) This was different than every other package in [community]. I know this because packages get added to [community] all the time without an email here. And saying discussion about adding PaX extensions was makes it different is naive as anyone who has been around here a short time could tell you that was never going to happen. 2) A few years back we specifically reduced the number of kernels in our repos to one. Then the LTS kernel appeared. Now this. The problem with adding a non-vanilla kernel to the repos is now for kernel bug reports we have to verify which kernel is running. If it is linux-grsec, we then need to figure out if the issue a generic linux one, or with the other patchset. This is a burden to all our the kernel maintainers and not just the packager and is part of the reason the variety of kernels was reduced. This is a very valid concern. Nobody raised it before though and in defence of Daniel I think the discussion was stagnating without such valid arguments having being pointed out. 3) Now this is in [community] there will be an expectation of providing all the extras that are supposed to come with this. As decided, this will not be happening, but it will be expected and the question will need to be answered repeatedly. This is mostly true of every package. I packaged the user-space audit daemon and I was forced to remove it from [community] when audit support was removed from the [core] kernel. The point that support was expected for audit was as much valid as it would be for a different kernel. 4) A separate repo would have given actual number for interest in this. We all know the number of votes in the AUR is a crap metric and could have accumulated a long time ago. It would also have allowed us to see how important the above issues are. Despite assertions, many binary repos are well used by the Arch community. That does not contradict the assertion that by being in [community] the userbase would probably be much larger (debatable of course...) but most importantly having a separate repo does not solve the issue you pointed out. The used kernel will still need to be specified in bug reports. It is also true for kernels compiled from AUR. What changes is the user expectation and on this I agree with you but most of the time that would translate in a simple matter of reassigning bugs to the kernel maintainer. Maybe this is really not so simple and additional kernel will not be accepted in official binary repos but I think it would be a valuable feature for arch to have if we can make it work. -- Massimiliano mtorromeo Torromeo Arch Linux TU GPG: 0xDA2EE423
Re: [arch-dev-public] providing grsecurity in [community]
On 22/04/14 06:03 AM, Allan McRae wrote: Lets not draw this out too much further. I don't want to have to unsubscribe from another mailing list... But I am still going to have my say! 1) This was different than every other package in [community]. I know this because packages get added to [community] all the time without an email here. And saying discussion about adding PaX extensions was makes it different is naive as anyone who has been around here a short time could tell you that was never going to happen. I didn't expect much from that proposal but it was worth trying. It's now clear to me that it's never going to happen. It was less of a pipe dream than enabling SELinux support in many packages + shipping complex policies via labels on files/directories :). 2) A few years back we specifically reduced the number of kernels in our repos to one. Then the LTS kernel appeared. Now this. The problem with adding a non-vanilla kernel to the repos is now for kernel bug reports we have to verify which kernel is running. If it is linux-grsec, we then need to figure out if the issue a generic linux one, or with the other patchset. This is a burden to all our the kernel maintainers and not just the packager and is part of the reason the variety of kernels was reduced. Output from `uname -a` or `dmesg` is a pretty basic requirement for a kernel issue, especially since problems like /boot not being mounted and new upgrades installed to the wrong place often happen. I don't mind being the one who asks for this on any [linux] issues missing it. I'll have to dig up the old discussion because I wasn't around for it. 3) Now this is in [community] there will be an expectation of providing all the extras that are supposed to come with this. As decided, this will not be happening, but it will be expected and the question will need to be answered repeatedly. Whether or not the kernel is in the repositories, I'm going to be maintaining the userspace components in [community] so there is going to an expectation of support (from me). Rather than providing the PaX exceptions via file attributes, it can be done via an RBAC policy. If I didn't think I could provide all of the extras, I wouldn't be taking on the responsibility. https://bugs.archlinux.org/task/39983 The downside of this solution from a user perspective is that it won't work for the PaX subset alone (linux-pax, which I have no interest in) so the hacks in the AUR will stay around. It also means extra pain for me since it's not yet written, but no one else has to worry about that. 4) A separate repo would have given actual number for interest in this. We all know the number of votes in the AUR is a crap metric and could have accumulated a long time ago. It would also have allowed us to see how important the above issues are. Despite assertions, many binary repos are well used by the Arch community. If what ends up happening is that it sees little use and/or causes work for other people, it can be dropped again. I don't think we're ever going to find that out from an unofficial repository. At the very least moving it to [community] is going to make a bunch of people angry about it and we can get to a resolution faster. 5) There were objections to it being included in our binary repos. This does not happen often, but we usually discuss further and come to a consensus about inclusion. Ignoring those objections is not how our team works. Given the relatively few people who responded to the thread, we have no real idea what the support was (and I can provide unsupported anecdotes for support against or for inclusion of the package as well as the next person can...) I know there were objections, but as you said few people felt like voicing their opinion here. A real vote would make sense but I don't see value in arguing in circles with the same few people. I'm not ignoring real issues that are raised, like the added work of distinguishing between which kernel users are using. I'm willing to put in whatever time is required to prevent this from increasing the workload of people who aren't interested in it. If that means stepping up and beginning to help with [linux] bug triage, I can do that. In conclusion, this should have waited before being put in the repo. It might have ended up there anyway, it might not have. And I can not be bothered figuring it out as it will not affect me in any way. If the end result is that it ends up back in the AUR, that's fine. I moved it because I didn't feel this was a productive discussion anymore. Arguing about this on the mailing list for weeks is going to cause much more pain than it simply being in [community]. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Fwd: [arch-general] Java 8
On 6 April 2014 23:10, Guillaume Alaux guilla...@alaux.net wrote: On 31 March 2014 13:38, Guillaume Alaux guilla...@alaux.net wrote: On 30 March 2014 20:46, Guillaume Alaux guilla...@alaux.net wrote: On 30 March 2014 20:39, Andrea Scarpino and...@archlinux.org wrote: On Sun 30, March 20:03:51 Guillaume Alaux wrote: You might be talking about icedtea-web [0], the browser plugin that enables some Java interpretation inside browsers? This is yet another project provided by the IcedTea team. Indeed. Thank you for the clarification. Could you provide an openjdk8 package without IcedTea? Isn't necessary to put that in the repos, just to test what would be missing/broken. Cheers -- Andrea Arch Linux Developer Sure! I will need to finish it first of course and will let you know. Should not be long. I do not expect much breakerage if any. Also I asked on the IcedTea ML to get an idea of when they think this release could happen. Ok so answer from IcedTeam team [0] is they should relase Hopefully in the next month. It depends how involved the security errata is next month. I am thus going to keep on working on a package *without IceTea* in case we want to test/release it and prepare one *with IcedTea* ready when this release is out. [0] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-March/026974.html -- Guillaume So as previously announced, here is an early version of OpenJDK 8 without IcedTea [0]. Sources of the package can be found here [1]. It is currently split into `jre8-openjdk` and `jdk8-openjdk` that currently declare a conflict with other JRE/JDK packages (I am working on an simple way to enable installation of multiple Java environments). Any tests feedback by those of you interested would be appreciated (I have just noticed I forgot man pages for JRE binaries on this package - will be fixed). Thanks [0] https://dev.archlinux.org/~guillaume/openjdk8-noicedtea/ [1] https://github.com/galaux/aurpkgs/tree/444d7df9ad91842fd595f220becddfbaa8894c4b/java8-openjdk -- Guillaume Split versions of JRE/JRE-headless/JDK for both architectures are available here [0] for testing. Sources available here [1]. [0] https://dev.archlinux.org/~guillaume/openjdk8-noicedtea/ [1] https://github.com/galaux/aurpkgs/tree/master/java8-openjdk -- Guillaume
Re: [arch-dev-public] providing grsecurity in [community]
[Including In-reply-to header so as not to break threading] On 22/04/14 10:43 AM, Daniel Micay wrote: 2) A few years back we specifically reduced the number of kernels in our repos to one. Then the LTS kernel appeared. Now this. The problem with adding a non-vanilla kernel to the repos is now for kernel bug reports we have to verify which kernel is running. If it is linux-grsec, we then need to figure out if the issue a generic linux one, or with the other patchset. This is a burden to all our the kernel maintainers and not just the packager and is part of the reason the variety of kernels was reduced. Output from `uname -a` or `dmesg` is a pretty basic requirement for a kernel issue, especially since problems like /boot not being mounted and new upgrades installed to the wrong place often happen. I don't mind being the one who asks for this on any [linux] issues missing it. I'll have to dig up the old discussion because I wasn't around for it. It's not just a matter of asking what kernel are you using. You'll probably have to ask the bug submitter to install linux from [core], wait a day, and start comparing two sets of output. But since you're prepared to do all the work, I don't think there's a reason to drop linux-grsec. That should happen if / when another packager has to work around it. signature.asc Description: OpenPGP digital signature
[arch-dev-public] OT: Re: providing grsecurity in [community]
On 22.04.2014 21:21, Connor Behan wrote: [Including In-reply-to header so as not to break threading] Thanks for trying, but thunderbird still has issues here. Either it's because there are 2 In-Reply-To headers or it's because the message id in the one you added isn't surrounded by . If adding the brackets doesn't help, try using mailman's archive and clicking the links there (email addr link at the top of each post), that should work just fine. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] providing grsecurity in [community]
On 22/04/14 03:21 PM, Connor Behan wrote: It's not just a matter of asking what kernel are you using. You'll probably have to ask the bug submitter to install linux from [core], wait a day, and start comparing two sets of output. Yeah, that's fine. If I'm already looking at them I might as well just be helping with bug triage in general. It's usually as easy as asking a few questions, pointing upstream or finding an existing bugzilla issue to follow upstream progress. The package could include a reminder in the install script to report issues to the [community] issue tracker but I'm not sure it would be any use. signature.asc Description: OpenPGP digital signature
