Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl
On Sun, Jul 13, 2014 at 12:59 PM, hasufell hasuf...@gentoo.org wrote: Dirkjan Ochtman: On Sat, Jul 12, 2014 at 2:37 PM, hasufell hasuf...@gentoo.org wrote: So libressl is meant as a drop-in replacement for openssl. Some caveats have already been discovered: So, libressl is really nowhere near ready for prime time or even late night TV (perhaps the day time talk shows, but that is a stretch given the PRNG situation). I think preparing a virtual and updating dependent ebuilds for the explosion of replacements is grand, however we should make it _very_ clear to everyone that issues exist that make libressl unsafe for anything other than play time. Thanks, Matthew Summers Gentoo Foundation Inc. GPG: 111B C438 35FA EDB5 B5D3 736F 45EE 5DC0 0878 9D46
Re: [gentoo-dev] Protecting config files of webapps
On Wed, Apr 2, 2014 at 3:18 PM, Thomas Kahle to...@gentoo.org wrote: Hi, www-apps/tt-rss is configured through a file config.php sitting in its install directory. At the moment the file is overwritten when upgrading with webapp-config. Who is responsible for config-protecting this file? a) the ebuild should install an env file (www-apps/otrs does this) b) the user can be informed with einfo but needs to do it herself c) This is a bug in webapp-config c) seems strange to me, but a user has reported this in bug 496788 and it was closed as a duplicate implying c). Cheers, Thomas -- Thomas Kahle http://dev.gentoo.org/~tomka/ It depends. webapp-config is designed to keep a pristine copy in /usr/share/webapps/$PN/$PV/ so when you write its install directory I'm not sure which one you mean. Is it that one in /usr/share OR is it the directory, likely withinin /var/www/, that the cli invocation of webapp-config placed it's files? If the latter, then it's a bug. webapp-config is supposed to keep track of modified files across multiple installations of the same webapp, even differing versions of the same webapp. If it's not doing that, its a bug in webapp-config. I'm adding blueness@g.o to CC since he is working on this package some. Thanks, Matt Matthew Summers Gentoo Foundation Inc. GPG: 111B C438 35FA EDB5 B5D3 736F 45EE 5DC0 0878 9D46
Re: [gentoo-dev] Default USE changes for fortran and mudflap?
On Sun, Jan 12, 2014 at 1:53 AM, Ryan Hill dirtye...@gentoo.org wrote: fortran: Do we want to keep enabling fortran by default? The majority of users will never get the urge to install a fortran package, and the fortran eclass handles those that do. I think it should be treated as all the other optional languages and disabled by default, but I'd like to know if there are other opinions. If you do disable fortran by default, please make a news item, if you don't mind. I know this will effect some percentage of our scientific user base (including myself). Thanks! Matt Matthew Summers Gentoo Foundation Inc. GPG: 111B C438 35FA EDB5 B5D3 736F 45EE 5DC0 0878 9D46
Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
On Mon, Jul 1, 2013 at 1:56 PM, Tom Wijsman tom...@gentoo.org wrote: On Mon, 1 Jul 2013 19:38:48 +0100 Markos Chandras hwoar...@gentoo.org wrote: I certainly don't feel safe anymore running non-upstream code in production boxes. You don't run it unless you explicitly tick on that you want experimental functionality _as well as_ the optional features in question; as I said earlier on chat, I don't understand your point here. If you don't enable them, genpatches is just like it is before; I'm not sure why the recommendations should change here, especially with vanilla-sources taking a further step away from Gentoo Security and QA. Tom, I think the point was well-made by grehkh. If the patchset patches the kernel's core, it doesn't matter what CONFIG_* option is set the core kernel code _has_now_been_changed_. This is the crux of the argument, I believe. AUFS simply being one example of this. I'm sure there are others. -- Matthew W. Summers Gentoo Foundation Inc. GPG: 111B C438 35FA EDB5 B5D3 736F 45EE 5DC0 0878 9D46
Re: [gentoo-dev] UTF-8 locale by default
On Thu, Aug 2, 2012 at 1:32 PM, Mike Gilbert flop...@gentoo.org wrote: On Thu, Aug 2, 2012 at 2:21 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 01/08/2012 23:42, Fabian Groffen wrote: Honestly, if some asian person has whatever charset that I often find in spam messages, but is not UTF-8, are you then going to tell that person to switch to UTF-8 to get those python packages emerged? I hope not. Tell that to the Python team I guess. My tinderbox _has_ utf8 locales available, but doesn't set in by default - Python stuff fails to build or test - not going to be fixed with change your locale reasoning. Is it mental? Yes. Would I like that to change? Yes. Do I care ẃhether that's through the use of cluebyfour on the Python team or by setting an utf-8 locale by default? Not in the least. Please apply the cluebyfour to the upstream developers of python and python modules. :-) I do try to fix unicode problems if I run into them. However, sometimes it just isn't worth the effort. Python upstream is doing what they think is best in using unicode. That said, what if we just temporarily set a locale in the ebuild for running tests and elsewhere? Is this unreasonable or impossible? It might not be a great solution, this method, since users' stuff will still break. Further, I support the use of C.UTF-8 when it is ready. It seems like the lowest common denominator to me. -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Thu, Jun 14, 2012 at 11:28 PM, Greg KH gre...@gentoo.org wrote: So, anyone been thinking about this? I have, and it's not pretty. Should I worry about this and how it affects Gentoo, or not worry about Gentoo right now and just focus on the other issues? Minor details like, do we have a 'company' that can pay Microsoft to sign our bootloader? is one aspect from the non-technical side that I've been wondering about. thanks, greg k-h Pardon my ignorance, but will we be requires to sign the boot loader/kernel on our install media for a Win8 machine to boot the iso? -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 10:22 AM, Greg KH gre...@gentoo.org wrote: On Wed, Mar 14, 2012 at 03:08:27PM +, Ciaran McCreesh wrote: On Wed, 14 Mar 2012 08:04:31 -0700 Greg KH gre...@gentoo.org wrote: Not always, no, it isn't obvious that something didn't start up correctly, or that it didn't fully load properly. Some programs later on recover and handle things better. So why not work on fixing those things, since they're clearly symptoms of a larger oops, we have too much coupling problem, instead of forcing a workaround onto large numbers of users? I seriously doubt there are a large number of users here that have this issue. The majority of users should not encounter any difficulty due to this issue. Those that are doing special things that require careful mounting, etc should be sufficiently competent to deal with this issue without any trouble at all, especially given the various solution paths. And even if there is, again, there is a simple solution that Gentoo provides for this issue, see the earlier initrd solution that we support today. Gentoo provides a solution with genkernel, dracut provides a solution, even the linux kernel itself provides a solution (in my view the easiest solution at that). I'll go back to lurking now, and getting stuff done, like everyone else on this thread should be doing, instead of complaining (this is -dev, not -users...) greg k-h Oh, please Greg, do continue to stay engaged, I enjoy your perspective very much. I just wanted to drop this simple fact in there. This has been coming for several years now AND the linux kernel has been using an initramfs for every boot, every time for a long time now, all 2.6 and up as I understand it. If the initramfs is empty, well the kernel is smart enough to fall back on legacy boot process. If you care to read about it, its all contained locally if your kernel source in the file linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt Its a great read, sure to entertain and enlighten. It saved my bacon a few times when mdadm switched to the new metadata format. Once I began to learn about what the initramfs made possible, entire new worlds of possibility appeared (and I was not even on drugs!). It's actually something of a surprise to me that there are people upset about this change, since it cleans things up a bit while also giving people that want and/or need it, a great deal of power and control over the boot process that was not nearly as easy before. I do believe Gentoo, as a community/volunteer-run and super-power-user distribution, should be careful, a bit wary, and seriously consider the decisions made by our corporate colleagues (we do have the mandate to maintain our independence). However, simply because RHEL, SUSE, etc are corporation controlled distributions does not mean they are bad or trying to control/ruin the rest of the distros. Anyway, I merely thought I would place my commentary on this situation here for posterity. Since I have an opinion, I thought I would share it for better or worse. -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] Lastrite: lilypond and reverse dependencies
On Mon, Mar 12, 2012 at 11:29 AM, Samuli Suominen ssuomi...@gentoo.org wrote: # Samuli Suominen ssuomi...@gentoo.org (12 Mar 2012) # Severely broken wrt bugs #179178, #331181, #334835, #350059, # #372839, #380155, #380627, #381055, #383515, #383553, #384687, # and #403399. Search bugzilla with keyword lilypond. Nothing # left in tree that builds. Removal in 30 days. media-sound/lilypond-2.12.4 media-sound/denemo media-sound/frescobaldi # Samuli Suominen ssuomi...@gentoo.org (12 Mar 2012) # media-sound/lilypond required for this is masked in ../package.mask # for removal app-text/asciidoc test Just curious, but is there no one interested in this, lilypond, package anymore? The latest stable is 2.14.2 and the project is pretty active. Seems like a shame to get rid of it entirely. -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] RFC patch for subversion.eclass (bug 401737)
On Tue, Feb 21, 2012 at 4:14 PM, Gilles Dartiguelongue e...@gentoo.org wrote:
Le dimanche 19 février 2012 à 12:06 +0100, Justin a écrit :
Hi,
any objections against following patch for subversion.eclass?
Fixes bug 401737. Basically respects ESVN_{USER,PASSWORD} during
reemerge of a package.
--- subversion.eclass 2012-02-07 11:56:27.0 +0200
+++ subversion.eclass 2012-02-07 11:59:38.0 +0200
@@ -469,7 +469,9 @@
local target=${1}
local key=${2}
- env LC_ALL=C svn info ${target} | grep -i ^${key} | cut -d -f2-
+ env LC_ALL=C svn info \
+ ${options} --username ${ESVN_USER} --password
${ESVN_PASSWORD} \
+ ${target} | grep -i ^${key} | cut -d -f2-
}
## -- subversion__get_repository_uri()
--- #
I'm not an expert of the subversion eclass, but the diff looks good.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
Why would you want a password in an ebuild? The var ESVN_PASSWORD
seems like trouble to me.
--
Matthew W. Summers
Gentoo Foundation Inc.
Re: [gentoo-dev] have portage be quiet by default
On Sun, Nov 13, 2011 at 9:59 AM, Rich Freeman ri...@gentoo.org wrote: this seems like a bit of a tempest in a teapot It cracks me up, this colloquialism. Please don't change this back. /$0.02 In theory, this should make Portage slightly more efficient since it won't be performing the simultaneous operation of spewing to a file and stdout. considering that the change is trivial to undo. Perhaps this will entice our most excellent user base to read the man page from time to time to see what new features might crop up. Had I known this option existed I would have set it a long time ago. Although, now I am concerned that my IQ may be caused to decline since I will not be soaking up learning via the osmotic process of blankly staring at builds screaming by on my machine. For those that want to see the build output in real time, for development purposes or otherwise, it is trivial to change on a more permanent basis via EMERGE_DEFAULT_OPTS or on a case by case basis by adding --quiet-build=n to the command invocation. Change is hard, but this one yields some boost in efficiency and noise reduction. So cheerio. Many thanks, quantum -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
On Fri, Oct 14, 2011 at 4:20 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 10/14/11 12:39 PM, Brian Harring wrote: On Fri, Oct 14, 2011 at 03:29:19PM -0400, Matt Turner wrote: On Sat, Oct 1, 2011 at 3:16 PM, Pawe?? Hajdan, Jr. phajdan...@gentoo.org wrote: OK, so what are the _blocking_ reasons for no EAPI 4 support in python.eclass yet? I understand you have some complicated patches in flight etc etc, but are they _required_ for the eclass not to break with EAPI 4? My point is that I'd like to use pkg_pretend in packages that use python.eclass and I can't (for a long time). Unless there are really important reasons like breakages I think we should really make python.eclass support EAPI=4. Two weeks and no response from python@? You probably should've cc'd them. CC-ing python@ then (but I expect the developers to follow gentoo-dev anyway). In case of no response, I plan to submit the thing to the council agenda. I think the parts of python eclass that I use should work with EAPI 4. Its being worked on currently. There are many fairly difficult issues to be worked through here. Your patience and/or contribution is welcome. -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] Re: [gentoo-dev-announce] Bugzilla maintenance outage 2011/09/26 06:30 UTC
On Tue, Sep 27, 2011 at 12:51 PM, Robin H. Johnson robb...@gentoo.orgwrote: On Tue, Sep 27, 2011 at 07:33:14PM +0200, Jeroen Roovers wrote: I'm going to be doing a minor bit of Bugzilla maintenance later tonight that will need 10-15 minutes of downtime. ... I'm planning on starting around 2011/09/26 06:30 UTC, and it should take me 10-15 minutes overall. This is ambiguous. By tonight I guess you mean your night. The only perceivable ambiguity is that I called 06:30 UTC 'tonight'. It was 2011/09/25 23:30 PDT (GMT-0700) for me when I did the maintenance. The time specified was accurate. Next time, I'll just specify the epoch time. +1 ;) -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] package graveyard
On Wed, Aug 17, 2011 at 11:56 AM, Alex Alexander wi...@gentoo.org wrote: On Wed, Aug 17, 2011 at 19:45, Thomas Kahle to...@gentoo.org wrote: Hi, I'm forking from a thread on gentoo-project: On 17:26 Wed 17 Aug 2011, Markos Chandras wrote: Personally, I want to shrink portage. There is no way for 250 listed developers ( I would be glad if 100 of us were really active ) to maintain thousands of ebuilds. [...] We need to support only the packages that we can *really* support and lets hope that more people will join in when they see their packages going away. I like the idea of shrinking portage, but here's a scenario I'd like to avoid: 1) package A is unmainted, but has a sophistacted ebuild that evolved over some time. 2) A has an open bug that nobody cares to fix, treecleaners come around and remove A. 3) New dev X joines Gentoo and cares for A and startes to rewrite the ebuild from scratch. Is there a way for X to easily query the portage history and dig up the ebuild that was there at some point. She could then use the old ebuild for their new version, but without efficient search she would probably start from scratch. Some packages are treecleaned in the state 'working but with a single bug (and nobody cares)', it would be good if that state is somehow retained after the removal. Then you can get a fully working package while fixing only one bug. Searching through mailing list archives with automatted removal mails would be my hack, what would be yours? Cheers, Thomas We could try removing all keywords and masking ebuilds that are abandoned with bugs but upstream is still active, instead of removing them completely. That way the ebuild will be there when/if someone else decides to take care of the package and it will even show in tools like eix. -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com +1 on this. It saves the ebuild for posterity AND prevents users hitting nasty bits. This seems to me to beg for a proper well-defined policy, in any case. -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] /usr vs. initramfs redux
On Fri, Aug 5, 2011 at 7:42 AM, Rich Freeman ri...@gentoo.org wrote: On Fri, Aug 5, 2011 at 6:16 AM, Marc Schiffbauer msch...@gentoo.org wrote: * Robin H. Johnson schrieb am 05.08.11 um 02:46 Uhr: [...] That leaves the only reasonable solution as #2. In terms of minimal impact, I propose that we offer users with a static system an absolutely minimal initramfs, that _just_ mounts the required directories. No modules, no LVM, no MD, no crypto etc - if you want that functionality, go and use genkernel or dracut. If your fstab contains a line like: /dev/sdXN /usr ... Then this initramfs is for you. The minimal initramfs would do the following. 1. Mount devtmpfs/sysfs/procfs as needed to access devices. 2. Mount real_root to /newroot 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab 4.1. If /newroot/etc/initramfs.mount does not exist Assume it contains only: /usr /var 5. Mount the combined items from said files 6. pivot_root. That sounds like a good compromise to me! Why would we build yet another initramfs vs just making dracut work reliably? You can already build dracut without support for lvm+raid+luks/etc. If we're going to require an initramfs then we should make sure that ALL gentoo-provided solutions work before we expand the need for a mounted /usr. The genkernel team already mentioned that they plan to switch to dracut, so we really just need to get dracut working properly. That said, nobody is preventing anybody from re-inventing the wheel if they wish to do so. I just wouldn't just offer it up as an example of a perfectly acceptable migration strategy, when we've had a lvm+raid howto for years that wouldn't be compatible with it. Rich In point of fact all modern Linux kernels have an initramfs built in now, that when empty is effectively bypassed, so there is no wheel reinvention. To quote the docs [1] All 2.6 Linux kernels contain a gzipped cpio format archive, which is extracted into rootfs when the kernel boots up. After extracting, the kernel checks to see if rootfs contains a file init, and if so it executes it as PID 1. If found, this init process is responsible for bringing the system the rest of the way up, including locating and mounting the real root device (if any). If rootfs does not contain an init program after the embedded cpio archive is extracted into it, the kernel will fall through to the older code to locate and mount a root partition, then exec some variant of /sbin/init out of that. [1] /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt While dracut may help with the process of creating the initramfs, its really not a terribly complicated endeavor, and from further reading (specifically as related to the desired removal of md autodetection), it is the full intention of the kernel upstream that initramfs be the new path forward in handling things such as separate /usr, raid volumes, and so on. Further, dracut will introduce yet another dep in base-system (I am guessing here), that is not more than perhaps a convenience. I note here, that I have not used dracut as the well documented method of creating an initramfs is straight forward enough that I did not require anything too fancy to handle mounting raid1 volumes, and providing a recovery environment with networking and ssh. This, at least to me, seems like an excellent opportunity to nicely document what can be done with an initramfs (in basic and advanced forms, as there are some really fancy things one can do with initramfs's), and how Gentoo is recommending their usage in the cases outlined by Robin and others. So, I am +1 on robbat2's solution and -1 on dracut. That said, I am fully willing to alter my position when presented with a better argument. Lastly, I do have a few minor concerns about how this default initramfs will be dealt with, however those can wait. Mainly, I simply desire the flexibility to replace the Gentoo-shipped version with a custom version easily. Thanks and kind regards, Matt -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] RFC Remove USE=fortran in default profile
On Wed, Jun 22, 2011 at 3:01 AM, justin j...@gentoo.org wrote: On 22/06/11 09:55, Michał Górny wrote: On Wed, 22 Jun 2011 09:15:35 +0200 justin j...@gentoo.org wrote: On 21/06/11 16:18, Matt Turner wrote: On Tue, Jun 21, 2011 at 7:17 AM, justin j...@gentoo.org wrote: HI, with the addition of the fortran-2.eclass, it is possible to remove the USE=fortran from the default profiles. Any objections? justin Nope, I actually suggested this back in December, and no one bothered to respond. Sounds good to me, Matt Removing fortran and adding an dependency on virtual/fortran lets portage select dev-lang/ifc as the fortran compiler of choice. That's because portage doesn't suggest USE changes for one-of deps, and just falls back to first USE-clean option. In my tests it does. if there only gcc[-fortra] present, it asks me to change the USE. I reverted it back temporarily, so everything should be fine now again. As said on IRC, if you really intend to do a thing like that, you should re-enable fortfran on the gcc package by default. I reverted to where we came from. Every further proceeding will be coordinated with the toolchain guys. Generally I would like to remove USE=fortran from default, as nearly solely science packages are written in fortran and I doubt that nearly half of the user base do science. I will come up with a plan. jusitn Hey Justin, One thing to note is that a few various python modules, like numpy, really benefit from fortran. While many people using numpy are scientists, many are not and further there are various modules that depend on numpy that non-science folks use. I, for one, care little about where that flag is set, since I have manually set that USE for years now in make.conf. I am simply hoping to make you aware of the fact that there are potential cases that could be easily overlooked. Thanks! Matt -- Matthew W. Summers Gentoo Foundation
Re: [gentoo-dev] Reviving webapp-config
On Fri, Jun 10, 2011 at 6:49 AM, Sebastian Pipping sp...@gentoo.org wrote: Questions: - What does reviving mean in detail? A re-write? A somewhat compatible re-write? I am not necessarily interested in a complete re-write unless its really warranted due to support for new features. First things first, webapp-config needs to have the open bugs addressed and current functionality should be supported. Getting back to maintaining the current code? There is some good code in there, so I think at minimum some of that will be maintained moving forward. Regardless, the current codebase should be audited, bugs fixed, and a new design spec incorporating the new features desired needs to be written in collaboration with various stake holders. Why did you choose how you did? I do not understand this sentence, but will try to explain the choices a bit. Having used webapp-config for 7 years or so, I had grown fond of it for managing things like drupal (back in the day) and for handling static media for my company projects. As time progressed, it seemed reasonable to extend the functionality of w-c to do fancier things like change tracking or byte-compiling python modules outside of site-packages for multi-instance and potentially multi-versioned deployments of the various pythonic webapps I manage. It seems reasonable to roll this sort of functionality into the existing tool. I am not intending to make this something specific to python webapps, just to be clear, but include tools to handle webapps written in ruby/rails, perl, etc. Additionally, Gentoo's infra team uses w-c for a few things and its a nice tool that mostly integrates well into cfengine (afaik). Whatever the case with automation, it does make management tasks easier (perhaps IMO). Further, there are substantial applications, like Moodle, that would benefit from a more robust deployment toolkit within Gentoo. So, in general, from both a distribution and a professional perspective its quite clear (at least to me), that this tool has an important role in Gentoo and therefore needs to be revived. - Have you spoken to Andreas Nüsslein who worked on a re-write in context of an earlier GSoC? I have not. I was unaware of this project until it was mentioned in replies to this thread. I have started reading the code. Perhaps there are some elements of Andreas' code we can incorporate into the w-c codebase. I need to dig into the code far more than my cursory glance. Best, Sebastian Good questions Sebastian, thanks. Matthew W. Summers Gentoo Foundation Inc.
[gentoo-dev] Reviving webapp-config
Ladies and Gentlemen, After consultation and discussion at length with several developers, I am writing to announce the impending revival of the tool known as app-admin/webapp-config effective immediately. If any fellow developers or motivated users from our superb community wish to join in this effort, please don't hesitate to assert your voice in the process by responding to this thread. We are aware of several bugs that need attention and towards their resolution as well as to facilitate a more pleasant development experience we have moved the repository to git.overlays.g.o proj/webapp-config.git which is also easily viewable via the web for those that want to follow along. While I may prefer to paint the bike shed purple and adorn it with Larry's beautiful head, I'm certain others have different ideas. It has under discussion that a fairly substantial refactor and extension in functionality is needed for webapp-config to bring it into the current era of web application frameworks (i.e. django, rails, erlyweb, lift, etc) while also supporting the existing functionality. I hope that this email serves to invite and stimulate conversation towards the revival of an excellent tool for Gentoo. Please let us know your thoughts and interest! Kind Regards, Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] Re: [rfc] Rendering the official Gentoo logo / Blender 2.04, Python 2.2
On Thu, May 5, 2011 at 11:47 AM, Sebastian Pipping sp...@gentoo.org wrote: On 05/05/2011 03:44 PM, Marijn wrote: I confess I know next to nothing about Blender, but what exactly makes it so hard to port the logo to a recent version? My experience modelling in Blender is zero, so it's hard to tell to right now me. From a few cases of remaking vector art from raster images in Inkscape, I can imagine that it's difficult to get very close in Blender too, if not more. I hope to have a better answer soon. Best, Sebastian This may be a nice opportunity to reach out to the blender community and ask for assistance and/or training. The information from such interaction could easily be documented to form a corpus for use in the future. -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] Git migration?
On Wed, May 4, 2011 at 9:23 AM, Andreas K. Huettel dilfri...@gentoo.org wrote: Am Mittwoch 04 Mai 2011, 00:18:08 schrieb Alec Warner: ask on the gentoo-scm list? -A I'd say this is of enough general interest, and the relevant people are for sure also subscribed here... -A -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ Andreas, While what you say is likely true, what occurs with your request is fragmentation of the information. That said, I think the majority of the information you seek is available in the gentoo-scm archives. From what I know about this, I think the issue is time and the ancillary utilities, like repoman, that will need to be updated. Beyond that documentation is required. See this thread for more info. http://archives.gentoo.org/gentoo-scm/msg_98932c55ec10fcc5445ab950e62b12dc.xml I know we are all pretty excited to migrate to git, but there is little reason to rush something this monumental. It seems far better to take the time to get it absolutely correct, technically (the best kind), the first time. I am certain, in any case, that your interest and involvement in this effort would be appreciated. Thanks, Matthew -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] Re: openrc portage news item
Hi, I have a few suggestions regarding this major change to Gentoo systems. 1. We should determine and then announce the precise date (appears to be in May) and time that baselayout-2 will be stabilized via: 1.1 A front page News item on www.g.o (PR team assemble!), 1.2 The main MLs (gentoo-announce, gentoo-users, etc), 1.3 Add a link to the www news item to /topic in #gentoo, and 1.4 Post a sticky topic in the Forum. all in addition to the eselect news item under discussion here. The above would link to the migration guide too. The rationale for this effort at getting the word out is to prevent users from hosing their system(s). While I tend to agree that users should read these eselect news items, its often not the case. Therefore I recommend shooting for the widest possible distribution of this information. Also, this gives PR a chance to let the world know about openrc and its benefits to Gentoo. 2. We should prepare a quick recover-your-system guide (could also create a script too) that can be quickly linked to for user support. This will save time for people providing support via IRC, email, etc, and give people a reasonable means of system recovery without huge pain. 3. Update the handbook to reflect these changes as soon as possible, and have that all go public simultaneously with the stabilization. 4. I have attached an edited and unfinished version of the original news item for review. I attempted to be succinct. This is a really exciting and potentially also rather anxiety-provoking change for our user base and Gentoo. We all know that the new baselayout is awesome, and users will find out soon enough. We simply need to make our best effort at easing the transition so we minimize the number of casualties. Thank you, Matt -- Matthew W. Summers Title: Baselayout update Author: Christian Faulhammer fa...@gentoo.org Author: William Hubbs willi...@gentoo.org Content-Type: text/plain Posted: 2011-05-01 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-apps/baselayout-2 On May XX 2011, you will see an update for sys-apps/baselayout to 2.x and a new package, sys-apps/openrc. It is recommended that you perform this update as soon as possible. Please note, it is __Absolutely_Critical__ that you follow the steps outlined in the migration guide located at the following URL. http://www.gentoo.org/doc/en/openrc-migration.xml FAILURE TO FOLLOW THE MIGRATION GUIDE CAN RESULT IN AN UNBOOTABLE SYSTEM! For more information or supprt regarding this change please see the following: - link to news item (should contain info regarding where to obtain support) - link to recover-system guide - link to handbook
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
On Wed, Apr 13, 2011 at 1:47 AM, Corentin Chary corentin.ch...@gmail.com wrote: On Sun, Apr 10, 2011 at 8:43 AM, Hans de Graaff gra...@gentoo.org wrote: On Sun, 2011-04-03 at 17:20 +, Corentin Chary wrote: misc: - automatic bug report - automatic email report for maintainer/herds I'm not sure if this makes sense. For example, it gets dev-lang/ruby wrong, thinking that our old patch files are missing versions. Also, for exiftool I only add production releases, so there will almost always be newer upstream intermediate releases. My point here is that there are often additional considerations in considering new releases, so fully automating this is going to be hard. Perhaps a weekly/monthly opt-in mail to the herd/maintainer with an overview would be useful? Better, what about a per-herd/per-maintainer rss feed ? The website is nice to have as another source of scanning for updates, bookmarked. The current site won't be updated, I'm working on a new django-based website that should be up and running next week. The url will probably be euscan.iksaif.net, but I'll post it here. -- Corentin Chary http://xf.iksaif.net Hi Corentin, Do you have a public repo for your django code/site available? I would really enjoy taking a look at what you have here, sounds cool. Thanks, Matt -- Matthew W. Summers
Re: [gentoo-dev] libgphoto2-2.4.10 news item
On Sun, Feb 13, 2011 at 1:34 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Why not specify all the CAMERAS you know about as being on by default in the profile? Users who care enough can override this with an explicit subset. -- Ciaran McCreesh This is how ALSA_CARDS and LCD_DEVICES are handled now. Its likely that there are other examples too. It does provide for nice defaults and easy user choice by override. How many CAMERAs are we talking here, like 20 or 200? -- Matthew W. Summers
Re: [gentoo-dev] Private SVN repository for live-ebuild
On Thu, Jan 27, 2011 at 9:16 AM, Natanael Olaiz nol...@gmail.com wrote: Hi all, I want to make a live-ebuild for a private subversion repository. I see in the developers manual [1] that CVS have the vars ECVS_USER and ECVS_PASS, but cannot found equivalent ones for SVN [2]. Anyone knows what would be the prefered way to do that? Is safe to include the login in the ebuild? Can it have only read permissions to root? And a similar case: a .tar.gz source package which is on a private web URL. What is the best way to download it from the ebuild? Thanks in advance, Natanael. [1] http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html [2] http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/svn-sources/index.html Hi Natanael, I just took a quick look at the eclass that determines the behavior you are interested in, and the short answer is yes that is supported via ESVN_USER and ESVN_PASSWORD. I would strongly encourage you to read the actual eclass though, as it details other handy functionality too. That file is generally located in /usr/portage/eclass/subversion.eclass Now, as to whether to include the value ESVN_PASSWORD in the ebuild, I would not do that. Personally, I would setup svn+ssh and use an ssh key to access the repo. I do this with git using the git eclass. I am prompted for a password/key by portage in this case. To automate this using an ssh key, you can just use a passwordless key or setup ssh-agent. Also note, the key will be sought out first in /root/.ssh (I think it looks there first anyway). Regarding your final question, I think that portage will ask you to enter the password if it tries to access something over HTTPS requiring authentication, but I am not 100% certain at the moment. Regards, Matthew W. Summers
Re: [gentoo-dev] Private SVN repository for live-ebuild
On Thu, Jan 27, 2011 at 11:24 AM, Zac Medico zmed...@gentoo.org wrote: On 01/27/2011 09:05 AM, Matthew Summers wrote: Now, as to whether to include the value ESVN_PASSWORD in the ebuild, I would not do that. Personally, I would setup svn+ssh and use an ssh key to access the repo. I do this with git using the git eclass. I am prompted for a password/key by portage in this case. To automate this using an ssh key, you can just use a passwordless key or setup ssh-agent. Also note, the key will be sought out first in /root/.ssh (I think it looks there first anyway). In this case, you could potentially have a problem if you have FEATURES=userpriv enabled, since that would cause src_unpack to execute as the portage user. Regarding your final question, I think that portage will ask you to enter the password if it tries to access something over HTTPS requiring authentication, but I am not 100% certain at the moment. In this case, depending on the FETCHCOMMAND behavior, you could have a problem with FEATURES=parallel-fetch since it launches fetches in the background. So, if background fetch doesn't fail gracefully, you might want to set FEATURES=-parallel-fetch in /etc/make.conf. Also, you could set PROPERTIES=interactive in the ebuild, in order ensure that the fetcher is executed in the foreground. -- Thanks Zac These are excellent points Zac, thank you for illuminating this functionality. One question though. Since the 'portage' user has its $home set by default to /var/tmp/portage how would you recommend handling the ssh key situation since that directory is somewhat special? Thanks! Matthew W. Summers
[gentoo-dev] Re: [Volunteers needed] Communicating use (and existence) of USE_PYTHON
On Fri, Dec 3, 2010 at 4:35 AM, Sebastian Pipping sp...@gentoo.org wrote: Hello, to better communicate USE_PYTHON we could use: - a portage news entry - notifications from within ebuilds - a users guide counterpart of http://www.gentoo.org/proj/en/Python/developersguide.xml - mentioning in 'man make.conf' This is overdue and has some urgency. Are you volunteering to get this going? Feel free to derive from http://blog.hartwork.org/?p=972. As it involves a GLEP and GuideXML maybe that's perfect for involving people being recruited at the moment. Thanks for your consideration. Best, Sebastian I have started a GuideXML doc for this. You can find it in my devspace [1]. Its really just a base bones doc at the moment, as I am no overly fond of pomp and circumstance when writing. Thus it is rather terse (like Mr Twain said Eschew surplusage). I welcome any comments and/or contrib. However, once this is ready for prime time, we can bring in docs-team for any further refinements. [1] http://dev.gentoo.org/~quantumsummers/use_python_guide.xml Thanks, Matt -- quantumsummers | Matthew W. Summers
Re: [gentoo-dev] News item for restructuring of hardened profiles.
On Wed, Nov 10, 2010 at 3:22 PM, Anthony G. Basile bluen...@gentoo.orgwrote: On 11/10/2010 10:29 AM, Petteri Räty wrote: On 11/10/2010 02:42 PM, Peter Volkov wrote: В Втр, 09/11/2010 в 18:20 -0500, Anthony G. Basile пишет: Title: Restructuring of Hardened profiles [...] Display-If-Profile: hardened/linux Is it possible to restrict this news item to be shown on affected profiles only? Yeah it shouldn't show up in new installs that are already using the migrated profiles. Regards, Petteri I'm not sure how to address this concern. I reread GLEP-42 and all I see is Display-If-Installed: eg. net-www/apache Display-If-Keyword: eg. amd64 Display-If-Profile: eg linux/hardened If someone knows how, I'll be happy to address this concern. -- Anthony G. Basile, Ph.D. Gentoo Developer I suspect it should be the following. Display-If-Profile: hardened/linux/amd64/10.0 Display-If-Profile: hardened/linux/amd64/10.0/no-multilib . . . etc. Now, I have no clear indication that Display-If-Profile can be used more than once or if it accepts an expression that would allow us to catch both the multilib and no-multilib examples, as well as the x86 profile, etc. Cheers, -- Matthew W. Summers
Re: [gentoo-dev] News item for restructuring of hardened profiles.
On Wed, Nov 10, 2010 at 3:39 PM, Matthew Summers quantumsumm...@gentoo.orgwrote: On Wed, Nov 10, 2010 at 3:22 PM, Anthony G. Basile bluen...@gentoo.orgwrote: On 11/10/2010 10:29 AM, Petteri Räty wrote: On 11/10/2010 02:42 PM, Peter Volkov wrote: В Втр, 09/11/2010 в 18:20 -0500, Anthony G. Basile пишет: Title: Restructuring of Hardened profiles [...] Display-If-Profile: hardened/linux Is it possible to restrict this news item to be shown on affected profiles only? Yeah it shouldn't show up in new installs that are already using the migrated profiles. Regards, Petteri I'm not sure how to address this concern. I reread GLEP-42 and all I see is Display-If-Installed: eg. net-www/apache Display-If-Keyword: eg. amd64 Display-If-Profile: eg linux/hardened If someone knows how, I'll be happy to address this concern. -- Anthony G. Basile, Ph.D. Gentoo Developer I suspect it should be the following. Display-If-Profile: hardened/linux/amd64/10.0 Display-If-Profile: hardened/linux/amd64/10.0/no-multilib . . . etc. Now, I have no clear indication that Display-If-Profile can be used more than once or if it accepts an expression that would allow us to catch both the multilib and no-multilib examples, as well as the x86 profile, etc. Cheers, -- Matthew W. Summers So, I re-read GLEP 42 and this snippet makes it clear that we will need one Display-If-Profile header element for each profile we are migrating. The algorithm used to determine whether a news item is 'relevant' is as follows: For each Display-If- header type which occurs at least once: The news item is not relevant if none of the headers of this type are successfully matched. Otherwise the news item is relevant. Regards -- Matthew W. Summers
[gentoo-dev] Gentoo at PyCon 2008 in Chicago
Greetings Gentoo Devs, I'm writing to let everyone know about a Gentoo Birds of a Feather at PyCon 2008 in Chicago. We have room Love Int'l A scheduled for Saturday, March 15, from 6PM to (PM (or later). Please post to this forum if you have a moment, and you are planning on attending PyCon. http://forums.gentoo.org/viewtopic-t-659597.html For more information on the conference see this site: http://us.pycon.org/2008/about/ And for other Open Spaces meetings see here: http://wiki.python.org/moin/Open_Space Early registration ends on 20 Feb. so be sure to get the discounted rate if you are planning on attending! Hope to see you there! Best Regards, QuantumSummers -- Matthew W. Summers Chief Executive Officer Systems Engineer Liquidus Tech, LLC 309 N. Jefferson Ave. Suite 378 Springfield, MO 65806 (417) 894-2607 [EMAIL PROTECTED] www.liquidustech.com -- gentoo-dev@lists.gentoo.org mailing list
