Re: [gentoo-dev] Deprecate EAPI1?
Ciaran McCreesh schrieb: >> Is there really much of a benefit to this? I guess for anybody who >> runs scripts to mass-manipulate ebuilds it might be helpful, but I >> think all the package managers planned on supporting all the EAPIs for >> quite a while longer. > We have to support them indefinitely. It's not possible to uninstall a > package whose EAPI is unknown. > Would it be feasible to do a pkg_pretend() check and refuse install/upgrade if packages with unsupported EAPI are detected? Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Deprecate EAPI1?
Ciaran McCreesh schrieb: > On Sun, 11 Mar 2012 16:14:33 +0100 > Chí-Thanh Christopher Nguyễn wrote: >> Ciaran McCreesh schrieb: >>>> Is there really much of a benefit to this? I guess for anybody who >>>> runs scripts to mass-manipulate ebuilds it might be helpful, but I >>>> think all the package managers planned on supporting all the EAPIs >>>> for quite a while longer. >>> We have to support them indefinitely. It's not possible to >>> uninstall a package whose EAPI is unknown. >>> >> Would it be feasible to do a pkg_pretend() check and refuse >> install/upgrade if packages with unsupported EAPI are detected? > Uhm. I think your question doesn't make any sense, but maybe I'm just > not understanding it. Rephrase please. > Assume a new version 13.37 of your package manager drops EAPI=1 support. So package-manager-13.37.ebuild checks in pkg_pretend() if any EAPI=1 package is installed on the system. If yes, then it aborts, telling the user to get rid of the package first. That way, the situation where the package manager does not know how to uninstall a package is avoided. Note that I do not suggest that this be done, I only show that it can be possible to drop old EAPI support. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Deprecate EAPI1?
Ciaran McCreesh schrieb: > On Sun, 11 Mar 2012 17:18:45 +0100 > Chí-Thanh Christopher Nguyễn wrote: >> Assume a new version 13.37 of your package manager drops EAPI=1 >> support. So package-manager-13.37.ebuild checks in pkg_pretend() if >> any EAPI=1 package is installed on the system. If yes, then it >> aborts, telling the user to get rid of the package first. > Oh, now I get it. There are two issues there... > > First, doing that is going to screw things up for users who have two > package managers installed, unless you make every package mangler's > package aware of every package mangler. As long as the package managers are installed through ebuilds, they should observe each other's pkg_pretend() > Second, there's not a way of getting the information you need to figure > that out using current EAPIs. That I suspected, that's why I asked about feasibility. "grep 1 $(portageq vdb_path)/*/*/EAPI && die" might work for portage and its current VDB layout. One problem that remains with this approach is what happens if an EAPI=1 package is in the list of packages to be merged along with the new package manager. > It's also not really worth it at the moment. There aren't any major > architectural changes between EAPIs just now, so removing support for > an EAPI won't allow any majorly nasty code to be removed from a package > manager. It might be worth revisiting this if we ever switch to EAPIs > that allow us to kill off VDB, for example. Yes, tommy already told me on IRC that there is no incentive for package managers to drop EAPI support at this time. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Deprecate EAPI1?
Rich Freeman schrieb: > On Sun, Mar 11, 2012 at 12:18 PM, Chí-Thanh Christopher Nguyễn > wrote: >> Assume a new version 13.37 of your package manager drops EAPI=1 support. >> So package-manager-13.37.ebuild checks in pkg_pretend() if any EAPI=1 >> package is installed on the system. If yes, then it aborts, telling the >> user to get rid of the package first. >> >> That way, the situation where the package manager does not know how to >> uninstall a package is avoided. > I take it that removing a package without using a package manager is > left as an exercise to the reader? The user will have to remove the package using his current, EAPI=1 capable package manager. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Deprecate EAPI1?
Richard Yao schrieb: > These must be maintained indefinitely to provide an upgrade path for > older Gentoo Linux installations. It is rare, but people do upgrade > old installs from time to time. Without some EAPI=1 packages, there is > no path for people to use to upgrade. The clean upgrade path from 2008.0 (still popular with some hosting companies) has already been destroyed with the removal of python-2.6.5-r3 a couple of months ago. It is up to the maintainers whether they want to invest time and energy into the old packages, and usually they don't. And it is indeed questionable whether users who update less than once every 6 months are worth this investment. (I tend to say yes, but that may just be because many come to #gentoo IRC with the resulting problems.) Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] RFC: License problem
Justin schrieb: > Hi, > > I need some comments on following License Agreement: > > http://fizz.cmp.uea.ac.uk/dyndom/dyndomDownload.do > > QUOTE > > In downloading this code you agree with the following: This would maybe warrant fetch restriction or inclusion of the license in the EULA group, as agreement to the license is necessary before the user can even download the package. > I will not redistribute the software to others outside of my immediate > research group. I will suggest to other interested research groups to > contact the authors directly. RESTRICT="bindist mirror" should shield us from any claims of wrongdoing here. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] RFC: iotop needs to run as root after kernel change
justin schrieb: > iotop cannot be used as user anymore. > Any suggestions how to proceed? > > Leave it to root (Fedora and Suses way) > suid it (bad in my view) I suggest to have a suid USE flag (disabled by default) so the user can choose between the two. Maybe advertise this change in an elog message. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo
Matt Turner schrieb: > It's not that they're not supported, just that libjpeg-turbo doesn't > have optimized routines for them. It'll still run fine. (Check the > keywords, you'll see that it's stabilized.) And on those platforms it will run equally fast or faster or slower? Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
Ciaran McCreesh schrieb: >> * two new files in profile directories supported, >> package.use.stable.mask and package.use.stable.force >> * syntax is identical to package.use.mask and package.use.force >> * meaning is identical to package.use.mask and package.use.force, >> except that the resulting rules are ONLY applied iff a stable keyword >> is in use > This means that an ebuild will effectively change when moved from ~arch > to arch. The point of ~arch is to test ebuilds before they're moved to > arch. I agree that the ~arch ebuilds should be tested in the same configuration in which they will end up in arch. However in this case, the possible configurations for arch are a subset of those in ~arch, so the testing covers those too. I see a problem where a significant proportion of ~arch users will have this flag enabled (which is obviously the point of package.use.stable.mask) so the arch configurations will see fewer testers. This issue may need to be addressed, e.g. by extending stabilization period or disallowing package.use.stable.mask in default or desktop profile. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Chromium bundled code
Greg KH schrieb: > On Fri, May 04, 2012 at 09:27:05PM -0400, Richard Yao wrote: >> On 05/04/12 20:58, Greg KH wrote: >>> Why do we really care about non-udev and non-dbus users? It's only >>> going to get worse and worse if people don't want to use these core, >>> base libaries of the Linux "stack". >> >> I was under the impression that in order for there to be a Linux stack, >> the Linux tree would need to include a userland in addition to a kernel. > > Huh? Don't you consider the kernel + glibc + xorg today a good "Linux > stack"? Isn't the "Android stack" another example of a good "Linux > stack"? I'd say that Android is an operating system based on Linux. It is not 'the Linux "stack"'. I think he was wondering whether the lock-in between dbus, udev and the Linux kernel will reach proportions where they will be distributed in one source tree. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
Greg KH schrieb: > On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote: >> Please stop throwing lennartware at people. FailAudio has been enough, >> thanks. > The use of these terms is both rude and totally uncalled for. You > should be ashamed of yourself. > > Seriously, that's unacceptable behavior from anyone. You mean as unacceptable as calling C++ proponents "full of bullshit"[1], developers of another operating system "masturbating monkeys"[2] and security researchers as "people wanking around with their opinions"[3]? > No one forces you to use any of this software if you do not want to. > There are lots of other operating systems out there, feel free to switch > to them if you do not like the way this one is working out, no one is > stopping you. But for you to disparage someone who has given immense > bodies of work to the community, and you, for free, is horrible behavior > and needs to stop right now. Insulting other people is indeed not nice. A borderline statement would be the "card-carrying member of the Poettering gang" which was coined by a well-known kernel developer who shall remain unnamed here. But using harsh words to describe other people's software? C'mon. Best regards, Chí-Thanh Christopher Nguyễn [1] http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918 [2] https://lkml.org/lkml/2008/7/15/296 [3] https://lkml.org/lkml/2007/10/1/217
Re: [gentoo-dev] -Werror unwanted?
hasufell schrieb: > https://bugs.gentoo.org/show_bug.cgi?id=260867 > > However, I don't see references to ebuild policy (in devmanual or > howtos) how to handle Werror. > > Is there a common opinion on that. And shouldn't we add that to the > documentation then? > -Werror is basically saying that it is not safe to ship code which produces warnings. I personally think that if an upstream says that no warnings must be produced by the code, and a developer should look at them before declaring any warnings safe, then that is best followed. However this causes a heavy maintenance burden and will frequently break compilation, so the majority opinion is to remove -Werror from compiler flags. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] -Werror unwanted?
Jeroen Roovers schrieb: >> -Werror is basically saying that it is not safe to ship code which >> produces warnings. > > An upstream demanding -Werror should work means upstream would need to > test rather a lot more than their own favourite > distro/architecture/library versions/kernel/userland, which isn't > going to happen. No. -Werror just means that if a warning is encountered, the user should be prevented from installing the software. Then a developer looks at the issue and determines whether it is safe to ignore or needs to be addressed. >> I personally think that if an upstream says that no warnings must be >> produced by the code, and a developer should look at them before >> declaring any warnings safe, then that is best followed. > > Upstream does not need to take into account warnings produced by > compilers for lesser known architectures, as explained above. These warnings could be harmless or introduce silent breakage. The user often can't tell. > As an upstream development aid to check code that has just been added > or changed, -Werror is fine, but not in the wild jungle that is Gentoo. > You might as well just look at the warnings themselves instead of > breaking the build system by making them fatal. In other words, for > upstream development it's convenient, but never for our users out there. -Werror is not convenient for anybody. When the developer has looked at the issue, then the particular warning could be made non-fatal. hasufell mentioned in another post the GTK+ deprecated warnings. Note that I don't propose the current policy to be changed. I can totally live with filtering -Werror in order to reduce maintenance work, at the small cost mentioned above. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Alexey Shvetsov schrieb: >> Shallow clones are also read-only last I checked. > > That isnt true =) you can commit from shallow clone if and only if > original repo doesnt have a branching and merging points before and > after shallow clone point respectively There can also be breakage when someone reverts a commit that it is not part of your shallow clone's history, and then you pull. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] UEFI secure boot and Gentoo
Greg KH schrieb: > 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. For the current crop of hardware, it is probably sufficient to add a paragraph to the handbook which tells the user to disable secure boot. Getting users' self-compiled boot loaders signed with a Gentoo key is probably infeasible. If you have influence on UEFI secure boot spec, you could suggest that they mandate a UI which lists all boot images known to the EFI boot manager, and the user can easily whitelist both individual loaders and the keys used to sign them. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Bugzilla whine mail "spam"
Michael Weber schrieb: > On 06/23/2012 09:59 PM, Christian Ruppert wrote: >> Again: Don't take it too serious, if it helps to remind you that's >> fine but ignore anything else. > > It'd be cool to exclude STABLEREQs, but I support the reminder > characteristic. I think STABLEREQs should not be treated differently from other bugs, as they require attention too. After you CC: arches, you could change the status to IN_PROGRESS in order to not receive future reminders. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] net-libs/libmicrohttpd up for grabs
Hi, as no packages I am interested in depend on net-libs/libmicrohttpd any more, I plan to remove myself from maintainers. You are welcome to take over the package. Else it will become maintainer-needed in a couple of days. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] New herd: radio
Hello all, The new radio herd will maintain packages related to sending and receiving of radio transmissions. Currently, these are GNU Radio and some packages from the Osmocom/SDR project. The initial members are zerochaos, creffett and me, but anybody is free to join. Plans for the near future include packaging parts of the airprobe suite, and importing some interesting ebuilds from Pentoo and betagarden overlay. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Last rites for net-ftp/netkit-tftp
Diego Elio Pettenò schrieb: > I just fixed a (reported) buffer overflow on it (not a security bug), > but the code is very bad and I'm expecting more issues in the future. > > The ebuild wasn't bumped since 2008, the upstream FTP site is entirely > gone (there's no more the _domain_ of it), and net-ftp/tftp-hpa should > replace it in all ways. > > So it'll be removed next month if there are no reasons to keep it around. Please report a removal bug for this, so any issues concerning users of netkit-tftp can be tracked. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] UTF-8 locale by default
Sascha Cunz schrieb: > Is there a reason for not using at least en_US.UTF-8 as a "sane" default > value? It has been discussed some time ago already. Setting LANG="en_US.UTF-8" would mess with collation rules, measurement&paper units etc. which has the potential to make users outside USA unhappy. It might make sense to set LC_CTYPE="en_US.UTF8" but even so, transliteration may give you unexpected results. To illustrate this, try running echo äå | LC_CTYPE=en_US.UTF-8 iconv -t ASCII//TRANSLIT -f UTF-8 echo äå | LC_CTYPE=da_DK.UTF-8 iconv -t ASCII//TRANSLIT -f UTF-8 echo äå | LC_CTYPE=de_DE.UTF-8 iconv -t ASCII//TRANSLIT -f UTF-8 and compare the output. For the previous discussion, see this thread: http://archives.gentoo.org/gentoo-dev/msg_2ffb7ea72e6209439600c371f6fc071d.xml Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] ROMs category suggestion
Kent Fredric schrieb: > On 23 July 2012 08:48, Rick "Zero_Chaos" Farina wrote: >> A fair point, suggestion retracted. I'm on board with sys-firmware as >> well, but I do see some advantage of the current way of putting the >> firmware in the category of what it is for... > > If you wanted, you could do something like x11-drivers/ do , and have > a standard of adding a little subcategorization: Could you be more specific? What does x11-drivers/ do that applies here? > sys-firmware/video-ati If it is really desired to state the firmware purpose in category/package, then I would prefer firmware-gpu/radeon-ucode firmware-video/cx18-firmware firmware-audio/alsa-firmware firmware-net/isdn-firmware or similar. This would be better than deviating from upstream package name. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: ROMs category suggestion
Kent Fredric schrieb: > firmware-video/ati-firmware > firmware-video/ati > > and any category name with "Firmware" in it, will result in lots of > redundant names exposed to users/deps if the package /also/ has > firmware in the name. Indeed, but this redundancy already exists in tree, e.g. dev-libs/lib* or sys-libs/lib*. I would deviate from upstream name only when there is a good reason to. > There's also the other thing to consider, and thats there's a lot of > hardware related stuff that is similar to firmware in a way, but also > totally devoid of a central category for it. Namely, kernel level > drivers. ( Which are not /that/ far removed from firmware, considering > that you can compile firmware into kernels and they're of similar > levels of necessity ). The only other thing I would group together with firmware is the Atheros HAL from the madwifi driver. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] UTF-8 locale by default
Ulrich Mueller schrieb: > As I had pointed out before [1], changing from POSIX to an en_US > locale will have undesirable side effects, like commas as thousands > separators in numbers (because of LC_NUMERIC). Also the defaults of > en_US for LC_MEASUREMENT and LC_PAPER are only useful in the U.S. > > So if we change the default (but I still don't see the need), we > should go for a less intrusive setting like: > >LANG="POSIX" >LC_CTYPE="en_US.utf8" This would be better than LANG="en_US.utf8" but I would still prefer not to have any country/region attached to the locale. The C.UTF-8 locale which Debian uses for this purpose (a UTF-8 locale without side effects) appears more suitable to me. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] force verbose build log as per PMS policy?
hasufell schrieb: > When I sum that up again... > - we are on gentoo and need as much information as possible for > backtracing, resolving bugs, checking whether CFLAGS and such have been > respected > - no need to tell the user to recompile with > EXTRA_ECONF="--disable-silent-rules" or similar just to be able to help him > - some QA checks might depend on verbose build log and are not yet > implemented therefor > - if people want nice build _output_ (not log), they can use --quiet-build Sorry that I am late to the party, but I would add some concerns to this discussion. Verbose build logs are can be several times as large as non-verbose ones, which can run into our Bugzilla's attachment size limit. When a user is unable to attach the build.log file, typically one of the following happens: 1. User compresses build.log with a common compressor like gzip, bzip2 or xz and manually sets the attachment MIME type correctly (best case). 2. User makes a compressed tarball, containing a single file 3. User cuts off the build.log somewhere in the middle, supplies the bottom part 4. User uploads build.log to a public file hoster or his own private web server, the link expires / 404s after some time (IMO worst case). In my opinion, build verbosity should not be dictated by policy, but rather left to the discretion of the maintainer. After all, he is the one who needs to deal with the bug reports. Having verbose build logs by default (with the possibility for the maintainer to override) would be ok with me though. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Questions about SystemD and OpenRC
Olivier Crête schrieb: > Can we also have a desktop that doesn't use X? Yes, through Wayland or DirectFB. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: Questions about SystemD and OpenRC
Rich Freeman schrieb: > So, I could see how many linux users might think that interpreting a > complex root= parameter is a kernel function, when it is really just > the fact that they use an initramfs. > > If somebody is running with root=LABEL=foo or something like that > without an initramfs I'll happily stand corrected. If your disk is GPT partitioned, then you can use root=PARTUUID=... without initramfs. Note that PARTUUID is the partition UUID, not the filesystem UUID. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] app-emulation/qemu & app-emulation/qemu-kvm folding into one package
Doug Goldstein schrieb: > Just an announcement that app-emulation/qemu-kvm will be pkgmove'd to > app-emulation/qemu at some point this week. The app-emulation/qemu > ebuilds will effectively die and be replaced by the > app-emulation/qemu-kvm ebuilds. I've brought this up before and there > was a bunch of rabble about "keep our pristine qemu ebuilds!!!". The > fact of the matter is that the app-emulation/qemu just isn't getting > the same maintenance care that app-emulation/qemu-kvm is. I've really > only got the bandwidth to handle one at a time. Additionally this will > bring us inline with a few other distros use of qemu as they're really > building their binaries from qemu-kvm. Is such a takeover really necessary? If there is no maintainer for app-emulation/qemu and it is broken, lastrite it. That other distros pretend to install qemu while actually installing qemu-kvm doesn't make it the Right Thing™. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Clarify the "as-is" license?
Ian Stakenvicius schrieb: > IE: - -'as-is' would be the generic "as-is" statement - > -'free-non-commercial' would be a "free/unrestricted for > non-commercial use" statement - -'free-unrestricted' would be a > statement of more or less public domain > > - -..etc... Why not directly use the FSF freedoms: The freedom to run the program, for any purpose (freedom 0). The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). The freedom to redistribute copies so you can help your neighbor (freedom 2). The freedom to distribute copies of your modified versions to others (freedom 3). I think when combined appropriately, they nicely cover most of the cases of current "as-is" packages. > ..and then ebuilds can include the particular phrases that apply? > ie, LICENSE="(as-is free-non-commercial)" , essentially an > 'assemble-your-own-license' from the snippets. We would maybe have to find a different operator for license concatenation. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2
Michael Mol schrieb: > A few months ago, I filed bug 423651 to ask that bzip2 on the install > media be replaced with > pbzip2. If I understand correctly, pbzip2 depends on bzip2. So what you are asking is that pbzip2 is preferred over bzip2 when both are installed, and that pbzip2 is installed by default? I have so far encountered only one anecdotal case in #gentoo IRC where pbzip2[symlink] caused problems in emerging a package. Disabling the symlink flag made the problem go away. However I can't point to the report right now, maybe someone with searchable backlog can uncover it. A different question is whether in the cases where parallel bzip2 makes sense, is it really the best solution? xz is outperforming bzip2's compression ratio for large files (for an informal comparison, see bug 434350). And xz is faster at decompression, which offsets the parallel advantage to some degree. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: Clarify the "as-is" license?
Ulrich Mueller schrieb: > I've created licenses/HPND [1] now, and added it to the @OSI-APPROVED > group. So packages whose license matches this template can be changed > from as-is to HPND. (And please, _only_ OSD-compliant packages. > We don't want the same mess again, as we have with as-is.) I have one question: The license can be GPL-compatible but the software itself non-free. So binary-only packages distributed under e.g. BSD license should remain BSD or not? If we start to measure the software freedom of the code inside the package, then maybe LICENSE is the wrong variable to express this. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Clarify the "as-is" license?
Ulrich Mueller schrieb: >> Why not directly use the FSF freedoms: >> The freedom to run the program, for any purpose (freedom 0). >> The freedom to study how the program works, and change it so it does >> your computing as you wish (freedom 1). >> The freedom to redistribute copies so you can help your neighbor >> (freedom 2). >> The freedom to distribute copies of your modified versions to others >> (freedom 3). > >> I think when combined appropriately, they nicely cover most of the >> cases of current "as-is" packages. > > This has been suggested before, but for license groups. The problem > is that the four freedoms are good criteria for Free Software, but > there's no good mapping to the elements of most non-free licenses. > > Try it yourself for a few concrete cases (of non-free licenses in our > tree), and you'll see what I mean. I tried it on two non-free packages that I maintain (bitstream-cyberbit and radeon-ucode) and it works well there: bitstream-cyberbit: 0 but not 1, 2 or 3. radeon-ucode: 0 and 2 but not 1 or 3. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] CIA replacement
Ben de Groot schrieb: > Since CIA.vc is dead [1], I think we should be looking into a > replacement service, or host our own [2]. I understand that ohloh is already tracking us (sometimes at least). http://www.ohloh.net/p/gentoo/ Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Re: About unresolved bugs assigned to voip for ages
Pacho Ramos schrieb: > Hello > > I am noticing for a long time that bugs related with ekiga, opal, > yate... are completely unattended by voip team for years. If nobody > from that team is willing to maintain them, please move them to > maintainer-needed to, at least, reflect reality. The members of the voip team are usually interested in a few specific packages only. Many of the packages which have become unmaintained had a maintainer once, but these were retired from Gentoo at some point. The package was then left with the herd. Nobody in the herd was interested to maintain them but nobody was sufficiently motivated to speak out against this either. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] RFC: fortran-2.eclass to depend on virtual/fortran
justin schrieb: > Hi, > > I want to add following change to fortran-2.eclass to achieve more > simpler usage. > > The patch will make the eclass depend on virtual/fortran so that > no manual addition is needed. Two exception are present, a) the > ebuild has the USE flag fortran, then we check for that, or b) the > FORTRAN_OPTIONAL variable is set, which leaves the control to the > ebuild (e.g. for cases like "lapack? ( virtual/fortran )"). I suggest that you do something similar to the XORG_DRI variable in xorg-2.eclass. For example: FORTRAN_WANT_COMPILER=no would not add a virtual/fortran dependency FORTRAN_WANT_COMPILER=always would unconditionally depend on virtual/fortran FORTRAN_WANT_COMPILER=useflag would depend on useflag? ( virtual/fortran ) To avoid breaking existing packages, you could default to FORTRAN_WANT_COMPILER=fortran Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] RFC: fortran-2.eclass to depend on virtual/fortran
Chí-Thanh Christopher Nguyễn schrieb: > To avoid breaking existing packages, you could default to > FORTRAN_WANT_COMPILER=fortran Sorry, it has to be FORTRAN_WANT_COMPILER=always Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages
Pacho Ramos schrieb: >>>>> I am noticing for a long time that bugs related with ekiga, >>>>> opal, yate... are completely unattended by voip team for >>>>> years. If nobody from that team is willing to maintain >>>>> them, please move them to maintainer-needed to, at least, >>>>> reflect reality. > Any news here? I can move that packages to maintainer-needed if you > send me the list of packages you don't want to maintain. Also, > maybe telepathy stuff could be moved to its own herd (that is > basically gnome team + tester... or maybe tester could join gnome > team ;)) There is now one proxy maintainer for a couple of packages, he is currently waiting for voip overlay access in bug 437538. He will take care of linphone and related packages (see bug 399735 and its dependencies). Regarding the packages that can be moved to maintainer-needed: I think a good heuristic is if the package has several open bugs with no maintainer reaction, and hasn't been touched by anyone from voip herd in over a year. This would include the ekiga, opal and yate packages mentioned above. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] libxul.so in gentoo
Jauhien Piatlicki schrieb: > Both firefox and thunderbird have xul library. Before there was a > separate package xulrunner in the tree, but as Mozilla does not > provide it as a separate package now (as far as I remember) both > firefox and thunderbird use there own libxul.so. That is not correct. Mozilla does provide xulrunner, released in sync with firefox versions: http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/ It was decided some time ago to remove xulrunner from Gentoo (bug 403415). > It seems this is the same library (Or am I wrong?). So may be it > could be splitted into a separate package? (The reason is its > compilation takes a lot of time on week machines and compiling it > one time would be better than twice). Also as far as I can see > xulrunner is splitted into a separate package in Debian and at > least Iceweasel uses it. Building firefox, thunderbird or seamonkey against xulrunner is possible, but not a supported configuration by Mozilla. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Last rites: x11-apps/grandr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Chí-Thanh Christopher Nguyễn (31 Oct 2012) # Build and runtime issues, bugs #340883, #369385, #435444. # If you require a graphical monitor configuration tool and your desktop # environment doesn't provide any, try x11-misc/arandr or lxde-base/lxrandr # Masked for removal in 30 days. x11-apps/grandr -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCRpkUACgkQ+gvH2voEPRB7/QCfdP2Kki7H/OSu5OYKUneG7T8r zFMAn2VPWA0gwpm0mrqFEcA3SFyf8k5A =dagW -END PGP SIGNATURE-
Re: [gentoo-dev] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
Matt Turner schrieb: >> Then udev switched to kmod as a build-time dep. I could no longer >> package.provide kmod as I had module-init-tools, because it was required >> to /build/ udev. For no valid reason on my system. Like any unnecessary >> feature that can be used to load an exploit, it's worse than useless. > # du -sh /var/tmp/portage/sys-apps/kmod-11-r1/image/ > 240K /var/tmp/portage/sys-apps/kmod-11-r1/image/ I think the complaint was not about the installed size. Some people have "install as little unnecessary code as possible" as part of their security concepts. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele
Pacho Ramos schrieb:> # Pacho Ramos (24 Nov 2012) > # Doesn't build with current kernels (#344889). People needs to > # migrate to x11-drivers/xf86-video-fbdev and be sure they have > # CONFIG_STUB_POULSBO enabled in their kernels. > # Removal in a month. > x11-drivers/psb-kmod > x11-drivers/xf86-video-psb Telling people to use xf86-video-fbdev for Poulsbo would be bad advice, they should use xf86-video-modesetting. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele
Walter Dnes schrieb: >> Telling people to use xf86-video-fbdev for Poulsbo would be bad >> advice, they should use xf86-video-modesetting. > Since > the "Intel GMA5/600 KMS Framebuffer" option is selected, xf86-video-fbdev > *MUST* be used as the video driver. I did try xf86-video-modesetting, a > few minutes ago and it does not support X Windows on my machine. The in-kernel GMA500 driver is being used with xf86-video-modesetting and it has some advantages over xf86-video-fbdev (like xrandr 1.2 so you can configure the resolution of your external monitor). I have seen occasional reports from users that the modesetting driver fails to detect the Poulsbo graphics, but due to lack of hardware I could not investigate further. If the modesetting driver does not work for you, then it would be a good idea to report a bug at https://bugs.freedesktop.org/ and include the relevant logs. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
hasufell schrieb: >> create_pkgconfig() > > this sounds like a very bad idea. > > pkgconfig files are common interfaces and should almost never be > created/modified/renamed anywhere except upstream. X11 team considered doing exactly that once after the nouveau API break in libdrm-2.4.33, splitting libdrm_nouveau-2.4.32 into its own separate package and renaming/modifying libdrm_nouveau.pc to make it installable in parallel to more recent libdrm[video_cards_nouveau] (bug 409593 comment 30). We ultimately decided against it though. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele
Walter Dnes schrieb: > Xorg appears to segfault with the xf86-video-modesetting driver. This > includes "Xorg -config". Normally, I run with no xorg.conf, no evdev, > and no udev (I use mdev) and the machine works. I don't know if > they'll accept a bug report due to my non-standard setup. Then try to reproduce the issue in a standard setup. X -configure does not work with KMS. > I did some Google-searching. The vast majority of hits either had > links to https://wiki.archlinux.org/index.php/Poulsbo (the Arch Linux > wiki) or else copied large portions of that page. I followed their > instructions, but it did not help. I'll do some more testing first, to > see if I can narrow down the bug. Other distros invent other names for the X11 drivers (Debian calls it xserver-xorg-video-modesetting and Fedora xorg-x11-drv-modesetting for instance). This may help in finding more information via Google. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Packages up for grabs due lavajoe retirement
Tomáš Chvátal schrieb: > Bundling few libs and bundling 40 of them is bit of difference, will YOU do > the audit? > Also other teams actively work on the unbundling, while there is track of no > will to actually make it buildable with system libs. > > Also the security is not the only problem here, it can also cause runtime > issues. Like bundled lib does not work with xyz because it does not apply > patch X that we have in main tree. I agree that this package should not be marked stable unless the security team agrees. But IMO the package can stay ~arch unless there are actual security/runtime problems. If such problems are found, then it can be p.masked with reference to the bug report. > Still keep in mind most distros won't allow inclusion of such software into > main repositories at all, so we allow something fishy others avoid a lot. The same is true for non-redistributable software (RESTRICT="mirror" and/or "bindist"), software redistributable only in source form (bindist) or software that may only be downloaded manually (fetch). Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] [RFC] Defaulting desktop profiles to net-nds/openldap[minimal]
Diego Elio Pettenò schrieb: > In > the mean time, I would suggest that, since the desktop profiles already > have USE=ldap enabled, we should default on the same profiles to > > net-nds/openldap minimal > > to make sure that the default desktop users don't get a copy of openldap > (server) installed. I like to think of the desktop profile as a (functionality wise) superset of the default profile. The proposed change will be contrary to this idea. > So, should we change the profiles' defaults? I would vote for no. If this change is applied anyway, I suggest to at least produce a news item in order to not surprise users about the sudden loss of their openldap server. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: [RFC] Defaulting desktop profiles to net-nds/openldap[minimal]
Duncan schrieb: > However, hasn't it always been gentoo policy to *STRONGLY* encourage > users to run emerge --pretend/--ask and EXAMINE THE RESULTS for anything > unexpected, and resolve it in one way or another to "expected", before > going ahead? > > Thus, anyone suddenly losing their openldap server as a result of a > simple uncaught USE flag change, "gets to keep the pieces", as the saying > commonly goes. Gentoo has /always/ been about reasonable documentation > but has /never/ been about handholding. We've never been afraid to point > users who expect to be handheld or babysat to other distributions that > are a more appropriate match to their expectations. In the days before we started playing fast and loose with profiles, this change would have been confined to an "under development" profile, and users would need to explicitly switch to that. After some time, the old profile would become unsupported and users told to use the new profile. But today that practice is typically not considered for profile changes any more. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] [RFC] New Manifest hashes and how to enable them
Michał Górny schrieb: I think the first reasonable change would be to deprecate SHA256. It is pretty much the same algorithm as SHA512, except for different parameters. It is weaker than SHA512, and SHA512 is supported on all existing platforms anyway. I think there is nothing wrong or insecure with continuing to use SHA256, even though it is technically weaker than SHA512. If it is already included in all Manifests then keeping it as standard is preferable I think. Some people consider having a second dissimilar algorithm at hand a good idea. I suggest SHA3 in that case. manifest-hashes = SHA256 SHA3-256 Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc
Michał Górny schrieb: The most important goal of having the packages masked is that it would cause Portage to verbosely complain whenever the users have it installed. With appropriate comment (displayed by Portage), we could clearly inform users that they need to upgrade gcc and switch to a new version to ensure that majority of packages work. Portage already tells users to run --depclean after each @world update, which will remove old gcc versions (except if stuff like gcj-jdk is installed). What your proposal does is to remind users who don't act on the first message, or who never do world updates, do I get this right? Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Bugzilla package list editing
Paweł Hajdan, Jr. schrieb: Please stop editing package lists when you are not the maintainer and arches are already CCed. +1 Please stop it. And yes that's also true for arch team members. Package list is maintainer territory. Curious, what are the reasons and what changes people make that they shouldn't? I'm wondering if there's some solution to these issues (maybe better documentation, or an alternative way of accomplishing what these people try to do). As dilfridge pur jer in CC, I guess that some of jer's changes to bugs were not welcomed by maintainers. One recent example of non-maintainer activity in the package list field is bug 613104, where he just removed the entire package list (and then marked the bug WONTFIX). Also very common is that he changes fully qualified package names (which is the correct syntax per [1]) into fully qualified package atoms (which is the legacy syntax). Bug 616260 is one such example. Best regards, Chí-Thanh Christopher Nguyễn [1] https://bugs.gentoo.org/page.cgi?id=fields.html
Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"
Mike Gilbert schrieb: I disagree. We might want to default the "pie" USE flag differently depending on the profile, but there's no need to force it. I think we should force the pie USE flag on/off depending on the profile. My proposal: For all profiles except hardened, introduce a pie/nopie variant. Deprecate the nopie profiles once enough packages build successfully (maybe request a tinderbox run?) In the profile depreciation message, point to a document how to migrate to pie. Setting pie default depending on GCC version is not a good idea IMO. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] [RFC] New global USE flag: unwind
Suggested description: Add support for stack traces and function name resolution via sys-libs/libunwind That description is a little unwieldy though, better suggestions are welcome. Currently in use by the following packages: dev-cpp/glog:unwind - Use sys-libs/libunwind for stack unwinding instead of glibc/gcc (may be more reliable on x86_64) dev-libs/efl:unwind - Enable debug support via sys-libs/libunwind dev-libs/weston:unwind - Enable libunwind usage for backtraces dev-util/ltrace:unwind - Use sys-libs/libunwind for frame unwinding support dev-util/perf:unwind - Use sys-libs/libunwind for frame unwinding support. dev-util/strace:unwind - Enable stack backtraces (-k flag) via sys-libs/libunwind media-libs/gstreamer:unwind - Enable sys-libs/libunwind usage for better backtrace support in leaks tracer module www-apache/mod_backtrace:unwind - Use sys-libs/libunwind to provide better resolution of function names. x11-apps/intel-gpu-tools:unwind - Provide automatic stack traces on test failures x11-base/xorg-server:unwind - Enable libunwind usage for backtraces I understand that dev-cpp/glog uses the unwind flag differently from the other packages. If that is an issue that package's flag could be renamed to "libunwind" as sys-libs/libcxx et al. currently use. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] [RFC] New global USE flag: unwind
Michał Górny schrieb: On czw, 2017-05-11 at 11:29 +0200, Chí-Thanh Christopher Nguyễn wrote: Suggested description: Add support for stack traces and function name resolution via sys-libs/libunwind Maybe skip the library name. Note that there's also llvm-libunwind, and some packages may be actually happy with libgcc_s. Ok, then how about: "Add support for stack trace unwinding and function name resolution" I understand that dev-cpp/glog uses the unwind flag differently from the other packages. If that is an issue that package's flag could be renamed to "libunwind" as sys-libs/libcxx et al. currently use. Yeah, that makes sense. Reported: https://bugs.gentoo.org/show_bug.cgi?id=618190 Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] [RFC] New global USE flag: unwind
As there were no further comments or objections, I added to profiles/use.desc unwind - Add support for call stack unwinding and function name resolution https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d62064cb2ac36c7443bd9dcd46019b9816c5ef9e Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] last rites: app-text/acroread
Jason A. Donenfeld schrieb: RIP acroread. The only PDF reader on linux that can properly parse PDF Reference XObjects. Thou shall be missed. I found the Chrome PDF reader (pdfium) to be a somewhat adequate replacement. pdfium recently gained the ability to deal with XFA forms, which are unsupported by most other PDF readers on Linux. Alternatively you can use Wine to run the Windows version. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Manifest2 hashes, take n+1-th
Michał Górny schrieb: > to: > > manifest-hashes = SHA512 SHA3_512 +1 Just wondering about the performance argument on weak systems: Does Portage absolutely have to check all of the hashes or can it be configured by the user to check only a subset of them? Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Manifest2 hashes, take n+1-th: 3 hashes for the tie-breaker case
Michał Górny schrieb: > Oh, and most notably, the speed loss will be mostly visible to users. > An attacker would have to compute the additional hashes only > if the fastest hash already matched, i.e. rarely. Users will have to > compute them all the time. That is currently the case with portage, but not an inevitable consequence of having 3 hash functions in the Manifest. Portage could be made to check only one or two of them (even by default), giving the tie-breaking ability to those who need it, and speeding up things for those who don't. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/
Michał Górny schrieb: Breaking the dependency tree was a *honest* mistake on the person who reverted this commit. Andrey pretty clearly stated that he did this *on purpose*. The removal of the package in violation of Gentoo policy was fully intentional from what I can see. There was no 30-day prior notice + p.mask which is required before removing a package. But even that it is not bad, just fix that mistake. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/
gro...@gentoo.org schrieb: If the developers of liblinebreak had not decided to rename their library, I could safely bump it from 2.1 to 4.0, in spite of the fact that it is maintainer-needed, right? Am I personally responsible for their decision to use the new name libunibreak? I think you could alternatively have used a pkgmove from liblinebreak to libunibreak, then do the bump. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] LINGUAS to be removed from USE_EXPAND
gro...@gentoo.org schrieb: > The package sci-mathematics/maxima for ages uses linguas_* flags for > installing translated documentation, the possible values of * are > > de es pt pt_BR > > This usage is, I suppose, wrong. I tried simply to replace all linguas_ to > l10n_ in the ebuild, but repoman complains about pt_BR. It should be l10n_pt-BR. LINGUAS used POSIX locales which define _ as separator between language and territory, while L10N uses BCP 47 which defines - as separator. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
Michał Górny schrieb: I guess you should have voiced your opinion back when discussion was taking place instead of being hostile *now* because the Council listened to what the developers requested. The arguments why these posting restrictions are a pretty bad idea have all been voiced back then already. So no point in posting them again each time. But of course it is also true that Council is elected by and acts on behalf of the developers. So my suggestion for developers who heavily disagree with this decision is to look at who voted which way in the public logs. Then read carefully who in their next Council election manifesto plans to lift this restriction again. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Package up for grabs: games-engines/love
Hi all! Due to lack of time, I have to drop maintainership of games-engines/love. There is some user interest in this package, and a version bump is needed (bug 640802). Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Re: [gentoo-project] rfc: council members and appeals
Dean Stephens schrieb: >> QA and Comrel are special in that they can take disciplinary action against >> non-members, which there is no recourse against except appeal to the Council. >> > At the very least: QA, Comrel, IRC ops (in every project specific > channel), planet/universe, forums, and wiki. Council, QA and Comrel are effectively the governing bodies of Gentoo, enacting and/or enforcing project-wide policy on their own accord. The others that you mention have only direct power in a very limited area. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Re: [gentoo-project] rfc: council members and appeals
Dean Stephens schrieb: >> Suppose that the council decides to accept an appeal from comrel. Is it >> a conflict of interest for a member of the council who is also a member >> of comrel to vote in the appeal? If it isn't, it is at least a pretty >> strong perception that it is. >> > Why? How? Exactly what sort of conflicting interest is supposed to be > present? I think in Comrel vs. Council is not a conflict of interest, but rather throwing the appeals process off balance. Can you expect someone to neutrally review material and actions (question the authenticity of evidence, identify potential misconduct, etc.) that they themselves used to build the case against the reprimanded? Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Re: [gentoo-project] rfc: council members and appeals
Ulrich Mueller schrieb: > Don't vote for that person then? Why would we need a general rule > restricting voters from electing any specific candidate? For the same reason why governing bodies sometimes restrict accumulation of mandates (and have term limits etc.). Of course the electorate can just vote for another person, but that is not the point. In the case of Gentoo, if one body is supposed to supervise the other, holding positions in both can lead to problems. While this may be ok if one of them is small and limited in scope, the more powerful both are the more problematic it gets. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Mailing list moderation and community openness
Kristian Fiskerstrand schrieb: > Switching to mailman might have some good merits on its own, but as I > understand it it isn't necessary for the proposal at hand, that can be > solved using access control lists in mlmmj-process? I would advise caution that Council better not try to micro-manage Infra here. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Mailing list moderation and community openness
Michael Palimaka schrieb: > I see that in bug #650964[1] Council is pushing forward again with > implementing user whitelisting on this mailing list (ie. anyone that is > not "approved" will have their mail rejected). > > Could someone please explain how this doesn't directly contradict the > core tenets of an open and inclusive community? (I do not intend to single out your post, just replying to the thread in general here) I would like to ask people to stay respectful in their disagreement towards the Council and their decision here. You might not agree with the decision, but the Council is an elected body and was given these powers by the developer community which they represent. Also I have no doubt that Council members who voted for -dev moderation are aware of the counter arguments and honestly expect a net positive effect from this. If you dislike mailing list moderation, campaign and/or vote in the next period for candidates who want to reverse this decision. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Mailing list moderation and community openness
Rich Freeman schrieb: > Actually, I think it is more of a technical constraint. It is > basically impossible to blacklist somebody on a mailing list, since > all they need to do is roll up a new email address. > > I can think of various arguments for whitelisting or not whitelisting, > but it seems silly to blacklist. And how often did it actually happen that blacklisting was evaded on -dev mailing list? Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Re: Monthly x11@ project status for June 2018
Matt Turner schrieb: Without eselect-mesa, the Gallium i915 and swrast drivers are installed if USE=gallium; otherwise the classic versions are installed. I suspect this is good enough. To my knowledge, the i915g driver supports only 915/945 hardware. The intel classic driver supports older chips (down to 810, though I believe that everything below 830 has been quite broken for years). Of course it is questionable whether there are any such users left at all. Best regards, Chí-Thanh Christopher Nguyễn
boot loader in @system, was Re: [gentoo-dev] Changing order of default virtual/udev provider
William Hubbs schrieb: A boot loader is also needed for a working system, but we do not > have one in @system. Instead, we direct the user to choose one. Actually it is not strictly necessary to install a separate boot loader. On EFI systems (arm and x86, not ia64 though), the kernel's EFI stub will function as boot loader. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing order of default virtual/udev provider
Alexis Ballier schrieb: It would probably generate controversy indeed, but my comment was more to understand what is the root of the f34R of udev being absorbed by systemd: "it is supposedly unsupported upstream and might not work at some point". Well, as far as I can see, you are maintaining sys-fs/udev standalone and don't intend to drop it. Even if you did, we could still pkgmove it to systemd. My conclusion is that this claim of udev being a dead end is pure FUD. This claim was made by upstream, no less. And it refers to *running* udev without systemd as opposed to building (which upstream already made impossible). Here is the exact wording: "Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call." https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html Not sure what about this is FUD. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing order of default virtual/udev provider
Sorry about the messed up quoting, somehow enigmail and format=flowed do not work well together.
Re: [gentoo-dev] Changing order of default virtual/udev provider
William Hubbs schrieb: Maybe FUD is the incorrect way to put it, but I think us doing > something about it at this point is definitely premature since > KDBUS is no where near ready to go -- they were forced to retract > it a while back because they had to re-think the design. kdbus got sent for inclusion in the kernel, and they were sure ready to pull off their plan back then if kdbus had been accepted. Whether switching to eudev now is premature is actually the central issue of this whole discussion. Given that dropping support for udev on non-systemd systems was narrowly avoided once, and upstream leaves no doubt that they are ready to do so once their redesigned kernel message bus goes upstream, I say describing such a move as "definitely premature" is not warranted. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing order of default virtual/udev provider
Alexis Ballier schrieb:
I also fail to see how udev using a new linux ipc would make it require
systemd. Quoting Lennart:
"You need the userspace code to set up the bus and its policy and handle
activation. That's not a trivial task. For us, that's what sytemd does
in PID 1. You'd need to come up with an alternative for that."
If it's just that, it's not limited to udev, but anything using
kdbus/bus1, and would mean openrc/${favorite init system} will have to
do the same thing anyway. But again, almost 2 years is extremely
old considering all the flux that has been around kbus.
OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel
IPC system comes next. But if upstream udev makes use of the systemd
userspace interface to the kernel IPC system, then OpenRC would have to
implement the same interface in order to have working udev.
Also given the close relationship between systemd and udev, there is no
guarantee that supporting other users of kdbus/bus1 will make udev
automagically work. As these two are released together, there is no
reason to have a stable, public API between them.
Best regards,
Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing order of default virtual/udev provider
Brian Dolbec schrieb: Thank you for bringing this information to the forefront of this debate. So, is it not better for us Gentoo-er's that wish to not install systemd, to set the default non-systemd udev to eudev. Note that I am not advocating for or against this move. I was just pointing out what I consider bad arguments. This includes labeling valid concerns as "pure FUD", and calling a move "definitely premature" when it was only circumstances beyond udev upstream's control which prevented it from becoming a necessity. I do feel that the eudev critics are correct in pointing out that both the real-world exposure of eudev so far and the size of its development team are too small. Whether it is a good idea to attempt to increase them by making eudev the Gentoo default I don't think I am qualified to answer. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing order of default virtual/udev provider
Michał Górny schrieb: This all is going into some bickering nonsense and noise made by systemd haters just to feed their troll, FUD and whatever else they made around here. As you directed this reply at me: If you think that calling out someone for labeling valid concerns as "pure FUD" is itself bickering and FUD then I am sorry, but that is not a way we can have an argument. I explained why the concerns are valid given upstream's past behaviour and public announcements. Whether they carry more weight than the other side's concerns is a different matter, but they can certainly not be dismissed as FUD. So, yes, we should definitely switch to semi-maintained, semi-documented fork made plainly of systemd hate. That is a false dichotomy. Apparently in this world there exist only systemd love and systemd hate. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing order of default virtual/udev provider
Alexis Ballier schrieb:
If it's just that, it's not limited to udev, but anything using
kdbus/bus1, and would mean openrc/${favorite init system} will have
to do the same thing anyway. But again, almost 2 years is extremely
old considering all the flux that has been around kbus.
OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel
IPC system comes next.
Well, as Lennart wrote it, kbus would have needed some initialisation.
Just like we have a dbus init script, openrc would have a kdbus one.
But if upstream udev makes use of the systemd
userspace interface to the kernel IPC system, then OpenRC would have
to implement the same interface in order to have working udev.
As I understand it, a kernel IPC doesn't need systemd to work. udev
might use wrappers from libsystemd, or libbus1, just like we have
programs using libv4l or libbluetooth currently.
In a follow-up, upstream wrote about how you should only run udev together
with systemd, and if you don't want to do that (spelling as in original):
"we will not support the udev-on-netlink case anymore. I see three options:
a) fork things, b) live with systemd, c) if hate systemd that much, but
love udev so much, then implement an alternative userspace for kdbus to
do initialiuzation/policy/activation."
https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html
So it seems a bit more than only initialization is needed.
Also given the close relationship between systemd and udev, there is
no guarantee that supporting other users of kdbus/bus1 will make udev
automagically work. As these two are released together, there is no
reason to have a stable, public API between them.
Yes, which would mean systemd requires matching udev, not the other way
around. I'm a bit clueless here: Do you have any pointers on the recent
trends on this side ?
I have only upstream's statements from 2014. They talk about a kdbus
userspace that systemd will provide to udev, which will be necessary for udev
to function.
If and when upstream comes forward with statements about whether udev will
only use public and stable API, these concerns could be either dispelled or
confirmed.
Best regards,
Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing order of default virtual/udev provider
Michał Górny schrieb: In a follow-up, upstream wrote about how you should only run udev together with systemd, and if you don't want to do that (spelling as in original): "we will not support the udev-on-netlink case anymore. I see three options: a) fork things, b) live with systemd, c) if hate systemd that much, but love udev so much, then implement an alternative userspace for kdbus to do initialiuzation/policy/activation." https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html So it seems a bit more than only initialization is needed. You're missing the third option which is a sane option, and jump straight to pitchforks. Are you serious? The quoted line directly above your comment shows clearly that I have read and understood the third option. If Lennart's single statement from 2014 is a reason to use eudev instead of systemd-udevd, my statement from today is a more important reason not to use eudev. With the exception that Lennart Poettering is the lead developer of systemd/udev, while such a thing cannot be said about you and eudev. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing order of default virtual/udev provider
Michał Górny schrieb: With the exception that Lennart Poettering is the lead developer of systemd/udev, while such a thing cannot be said about you and eudev. He's lead developer of *systemd*. udev is a split part of systemd codebase which has specific maintainers. systemd and udev share the same codebase. You can no longer build udev without systemd. udev is only a sub-project of systemd now, hence the name "systemd-udevd". Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing order of default virtual/udev provider
Michał Górny schrieb: systemd and udev share the same codebase. You can no longer build udev without systemd. udev is only a sub-project of systemd now, hence the name "systemd-udevd". Of course, sure. But since you seem not to be able to understand basics: this *does not* mean Lennart is the only person having influence on how udev progresses. Sharing the same repository and utility libraries is not the same as being the same thing. Ok, apparently I am too dense to understand that the someone who is the lead developer and visionary of a project naturally has the same say as someone who is only bickering from the sidelines. Maybe if you had pointed out a systemd developer who disagreed with Lennart's words I could have seen the light earlier. Also I am obviously unable to understand that when the kernel folks complained about the "new maintainers" of udev breaking things, they would of course never suspect that these "new maintainers" have anything to do with systemd at all. http://thread.gmane.org/gmane.linux.kernel/1368617 Seriously. You gave good reasons why udev should remain the default over eudev, I acknowledged as much already. But do not continue the path of labelling your opponents as stupid and their arguments as FUD, because this is clearly not the case. It really doesn't help your argument, it just makes you look bad. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Gentoo logo trademark renewal: photographs/usage documentation sought
Robin H. Johnson schrieb: So, I'm looking for photos (or videos) that show the Gentoo stand/banner at recent conferences, esp. if the Gentoo logo is also visible on the shirts of one or more people in the photo. Photos of other Gentoo-logo swag, in the active environment would also be appreciated. Here are some pictures from Prague LinuxDays 2015: http://www.root.cz/galerie/linuxdays-2015-nedele/#61 http://www.root.cz/galerie/linuxdays-2015-nedele/#62 http://www.root.cz/galerie/linuxdays-2015-sobota/#54 http://www.root.cz/galerie/linuxdays-2015-sobota/#74 Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/
Gordon Pettey schrieb: So, it's perfectly okay to make direct commits of obviously broken code that has no chance of working, because community something mumble... You may have missed some sarcasm in the post which you replied to. Plus, I don't think anybody said or implied that committing broken things is ok. Best regards, Chí-Thanh Christopher Nguyễn signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 07/17] profiles: Remove unused INPUT_DEVICES
Michał Górny schrieb: -none - INPUT_DEVICES setting to build no drivers (useful when using binary drivers) Not sure about this one, I think it was never used nor intended to be ever used. Same for VIDEO_CARDS. Otherwise looks fine to me. Best regards, Chí-Thanh Christopher Nguyễn signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems
Michał Górny schrieb: Request changing LINGUAS to L10N in make.conf, and make LINGUAS considered an 'advanced variable' for implicit localization control (i.e. passed through to build systems). Recommend clean INSTALL_MASK solution instead. Can we have this change happen (semi-)automatically, via config_protect? Also, will there be a transition period where users need to have both variables set? Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] [RFC] New global USE flag: webp
Suggested description: Add support for the WebP image format Currently in use by the following packages: app-text/tesseract:webp - Enable support for webp image format. dev-games/aseprite:webp - Enable webp image format support dev-libs/DirectFB:webp - build WebP image provider dev-libs/efl:webp - Enable WebP image loader dev-python/pillow:webp - Enable support for webp image format. dev-qt/qtwebkit:webp - Add support for WebP image format media-gfx/darktable:webp - Enable WebP export support media-gfx/fbida:webp - Enable support for the WebP image format media-gfx/graphicsmagick:webp - Enable support for webp image format media-gfx/gthumb:webp - Enable support for webp image format media-gfx/imagemagick:webp - Enable webp image format support using media-libs/libwebp media-gfx/imageworsener:webp - enable webp image format support media-gfx/nomacs:webp - Build support for WEBP image format media-gfx/qiviewer:webp - Build support for WEBP image format media-libs/gd:webp - Enable support for the webp format media-libs/gegl:webp - Enable support for media-libs/libwebp media-libs/jbig2enc:webp - Add support for WEBP image format media-libs/leptonica:webp - Adds support for the WebP image format media-libs/opencv:webp - Enable support for webp image format media-libs/sdl-image:webp - support loading WEBP images media-libs/sdl2-image:webp - support loading WEBP images media-video/ffmpeg:webp - Enables WebP encoding with media-libs/libwebp. media-video/libav:webp - Enable WebP encoding with media-libs/libwebp. www-client/netsurf:webp - WebP image support (media-libs/libwebp) x11-wm/windowmaker:webp - Enables WebP image format support using media-libs/libwebp x11-wm/xpra:webp - Enable webp image format support Best regards, Chí-Thanh Christopher Nguyễn signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] New global USE flag: webp
Kristian Fiskerstrand schrieb: Personally I'da thought an ewarning would be sufficient based on the old flag, and perhaps a news item if considered important enough?! as long as it is sufficient time and it notifies ahead of time, and the new use flag can be added to package.use immediately, indeed, although I believe an elog is more appropriate than ewarn in that case. I vaguely remember that this can be done automatically, through config_protect to create/update a package.use entry. Don't ask me on any details though. ;) Best regards, Chí-Thanh Christopher Nguyễn signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N
Ulrich Mueller schrieb: On Mon, 06 Jun 2016, Mart Raudsepp wrote: Usually only two letter language codes suffice, but can be limited with country codes with a 'll_CC' formatting, where 'll' is the language code and 'CC' is the country code, e.g en_GB. Some rare languages also have three letter language codes. s/country code/territory code/g Question related to this, do we take the opportunity to standardise the values? Looks like the vast majority follows language[_territory][@modifier] specified by POSIX [1] but some don't. What do we do with locales that don't fit into this scheme? Catalan Valencian is one such locale. Packages currently use modifiers (ca@valencia) or ISO 3166-1 reserved area (ca_XV) or something entirely different (ca_valencia). ISO 3166-1:ES defines ES-VC as region code, so maybe ca_ES-VC would be best. Though a quick Google search didn't find any major usage of that either. Best regards, Chí-Thanh Christopher Nguyễn signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N
Ulrich Mueller schrieb:
On Mon, 6 Jun 2016, Chí-Thanh Christopher Nguyễn wrote:
Ulrich Mueller schrieb:
Question related to this, do we take the opportunity to standardise
the values? Looks like the vast majority follows
language[_territory][@modifier] specified by POSIX [1] but some
don't.
What do we do with locales that don't fit into this scheme? Catalan
Valencian is one such locale.
Packages currently use modifiers (ca@valencia) or ISO 3166-1
reserved area (ca_XV) or something entirely different (ca_valencia).
According to [1], "valencia" is a valid variant subtag, therefore
ca@valencia should be fine.
ISO 3166-1:ES defines ES-VC as region code, so maybe ca_ES-VC would
be best. Though a quick Google search didn't find any major usage of
that either.
Neither XV nor ES-VC are registered as a subtag though, so presumably
these should be avoided.
I'm not totally convinced yet.
Following the BCP-47 spec the format is
Language-Tag = langtag ; normal language tags
langtag = language
["-" script]
["-" region]
*("-" variant)
*("-" extension)
["-" privateuse]
So using the language ca, region es, and variant valencia, the BCP-47
language tag is ca-es-valencia (or ca-valencia if you omit the region).
POSIX.1-2008[2] as you mentioned defines a slightly different format for
locales
language[_territory][.codeset]
Only LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, and
LC_TIME additionally accept specification of a modifier.
[language[_territory][.codeset][@modifier]]
Where territory is implementation defined and the modifier "select[s] a
specific instance of localization data within a single category". Which
I think does not match what we want with "valencia" variant of the "ca"
language.
Hence I think POSIX locale cannot handle Catalan Valencian, unless
territory is made accept ISO3166-2 region subdivisions.
Best regards,
Chí-Thanh Christopher Nguyễn
[1] https://tools.ietf.org/rfc/bcp/bcp47.txt
[2]
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02
Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N
Ulrich Mueller schrieb: POSIX.1-2008[2] as you mentioned defines a slightly different format for locales language[_territory][.codeset] Only LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, and LC_TIME additionally accept specification of a modifier. [language[_territory][.codeset][@modifier]] Where territory is implementation defined and the modifier "select[s] a specific instance of localization data within a single category". Which I think does not match what we want with "valencia" variant of the "ca" language. As I understand it: 1. Gettext documentation says that locale names can be LL_CC or LL_CC@VARIANT. The natural mapping to the (implementation defined) format mentioned by POSIX seems to be that LL, CC, and VARIANT correspond to language, territory, and modifier, respectively. 2. Language codes are taken from ISO 639, namely the two-letter code if one exists, otherwise the three-letter code. Yes. 3. Territory codes are taken from ISO 3166-1, usually the two-letter country codes. Yes. 4. According to Gettext documentation, "'@VARIANT' can denote any kind of characteristics that is not already implied by the language LL and the country CC." (So IIUC the BCP-47 variant "valencia" would become "@valencia".) This I think is wrong and collides with POSIX. POSIX modifiers are not allowed for LANG or LC_ALL in POSIX.1-2008[1] Section 8.2 says you can have at most one modifier field to "select a specific instance of localization data within a single category", which I don't think applies because it is its own locale, not an instance of an existing one. Furthermore (but that doesn't apply in our use case), POSIX spec lists the example LC_COLLATE=De_DE@dict So what if you want Catalan Valencian with dictionary order? Or if someone hypothetically came up with a different script? Hence I think POSIX locale cannot handle Catalan Valencian, unless territory is made accept ISO3166-2 region subdivisions. I haven't found any mention or usage of ISO 3166-2 region subdivisions in the context of locale. Can you provide any references for this? As I wrote before, it is not used. But I think it is the only spec-compliant way to marry POSIX locales with Catalan Valencian. BCP-47 does it in a more natural way. Best regards, Chí-Thanh Christopher Nguyễn [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The future of the Sunrise project
Michał Górny schrieb: Therefore, I'd like to ask the following question: is it time to announce the project dead, or do some developers want to revive it? If the former, could someone try to contact last active contributors and ask them if they'd like to move their ebuilds to ::gentoo via proxy-maint? I agree that the Sunrise repository should be removed from repositories.xml. I don't know if there is any way of informing users beforehand of this change happening. If not, then a grace period is probably pointless. Moving ebuilds to proxy-maint and ::gentoo is complicated by the fact that there is no concept of maintainer in sunrise. (This is also why we were stricter than the portage tree, because the original committer might not be around when the next person would have to make changes.) As every package in sunrise has an associated maintainer-wanted bug, it would be good to post a message to each such bug to encourage interested users to contact proxy-maint. I should point out that Sunrise has lost a lot of popularity to proxy-maint, then also to GitHub pull requests (and the two combined). The developers involved with those provide quite a good review workflow, with the extra advantage of getting packages straight into ::gentoo. I don't know how many users would be interested in keeping them in ::sunrise if they could have them straight in ::gentoo with similar (if not less...) effort. Your thoughts? I do think there is value in having a user repository. There are different ways to manage it: curated, non-curated, only trusted users get access, everybody gets access, etc. Sunrise is on one end of the spectrum and bgo-overlay probably on the other. The Sunrise approach ultimately did not scale and hinged on developers doing most of the work that proxy-maint would do but ending up in a much less visible repository. Maybe an approach similar to what grobian initially suggested for the portage tree git migration[0] would be a good idea: Have individual user-managed repositories for packages, and an automated script that merges them. But of course someone needs to step up and make it happen. [1]:https://wiki.gentoo.org/wiki/Project:Sunrise Until further steps are decided, I'll add a statement that the project is inactive and refer people to proxy-maintainers. Best regards, Chí-Thanh Christopher Nguyễn [0] https://archives.gentoo.org/gentoo-dev/message/753620a99ab88b9525a253590617db3c
Re: [gentoo-dev] [RFC] Global USE=gui
Michał Górny schrieb: 2. Packages use REQUIRED_USE to force an appropriate choice. That would be a policy violation. Packages should pick a reasonable default if flags are conflicting, but not force users to micro-manage their flags. Who did establish that *idiotic* policy and why is he still a developer? The whole *point of USE Flags* is to let people micro-manage stuff. Picking up a random default makes flags meaningless, confusing and makes it impossible to establish appropriate USE dependencies. I assume "micro-manage" means users maintaining extensive lists of per-package flags in package.use, which I agree with ulm is to be avoided. Setting the USE flags once in make.conf would not qualify as micro-managing in my opinion. There is an exception though, in cases where this breaks reverse USE dependencies, it may be allowed and necessary to use REQUIRED_USE[0]. Best regards, Chí-Thanh Christopher Nguyễn [0] https://devmanual.gentoo.org/general-concepts/use-flags/index.html#conflicting-use-flags signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: BCP 47 for L10N?
Michał Górny schrieb: On the other hand, there will be some cost: - If BCP 47 tags containing a script or a variant should be used to generate LINGUAS, they will require explicit mapping. (OTOH, such mapping will also be needed if we stick to Gettext syntax but unify variants like "sr@latin" and "sr@Latn".) - Different syntax for LINGUAS and L10N might be confusing to users, so additional documentation will be needed. As pointed out below, users better not mess with LINGUAS anyway. But one thing which might still cause confusion is that LANG and L10N use different syntax if we decide for BCP 47. Comments? I'd say BCP-47. +1 for BCP-47 The gettext tags aren't 100% defined anyway, so we'd end up having to choose between one upstream and another eventually, and map to the other. Worse, gettext locales, while apparently designed to resemble POSIX locales, can change at any time without notice and may be different between glibc versions. Also, when it makes mapping L10N to LINGUAS harder, it will discourage people from abusing the latter. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] the graveyard overlay
Rich Freeman schrieb: You say that there are no bugs in those packages. How do you know? You don't know unless you test it, and no maintainer means nobody is known to test it regularly. The package can be pretty much completely broken and we'll not know unless someone tests it. This sounds like a tree falling in the forest with nobody around... If a package is in the tree, and it has no known bugs, and no users, who cares? If somebody tries to use it, and it doesn't work, then they can file a bug, and then we can treeclean it. One might add here that toralf is doing a great job at building all packages and reporting those that fail. So at least we see build failures. Having a graveyard that ONLY contains broken stuff as an overlay just doesn't make sense to me. Why would you install packages directly from it without fixing them first? Certainly for build failures you'd be forced to do this. I guess for security issues you could decide that you don't care, or that your host is in a locked room with no network access or something. However, these seem like such minor use cases that somebody could just stick the ebuilds in their own overlay if they needed them. I think the point of a graveyard repository is that discovering and extracting deleted ebuilds from git is more cumbersome than from CVS attic. It would be even better if the graveyard repository preserved the commit history, but I don't see any easy solution for that. Best regards, Chí-Thanh Christopher Nguyễn signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] the graveyard overlay
Rich Freeman schrieb: On Fri, Jul 8, 2016 at 2:22 PM, Chí-Thanh Christopher Nguyễn wrote: I think the point of a graveyard repository is that discovering and extracting deleted ebuilds from git is more cumbersome than from CVS attic. It would be even better if the graveyard repository preserved the commit history, but I don't see any easy solution for that. Like I said. If the only use case is helping people who don't know how to use git find deleted ebuilds, then just create a directory tree with everything that was ever in the Gentoo repo. That would be pretty easy to script. QA doesn't need to have anything to do with it. I'm sorry for harping on that topic again, but if we had used grobian's initial proposal for git migration[0] - one repository per package, and the portage tree would be an aggregation of those - then we could have such a thing basically for free now. But that's how it is now. Getting ebuilds from CVS attic could be done via the sources.g.o web interface even, no local checkout needed. Best regards, Chí-Thanh Christopher Nguyễn [0] https://archives.gentoo.org/gentoo-dev/message/753620a99ab88b9525a253590617db3c signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Signed push & clock drift rejection
Kent Fredric schrieb: On Mon, 18 Jul 2016 22:21:22 -0400 waltd...@waltdnes.org wrote: I'm amazed that "robust linux servers" are deathly afraid of simply setting the time, and being done with it. There's problems at the software level everywhere that are not so simply solved. A more obvious example is in the event your system time gets *ahead* of real-time. And even if the system is behind time, it can cause problems. cronjobs running unexpectedly close to each other (or missed cronjobs in extreme cases). User sessions expiring early, etc. And even if there is only one second, and that is known well ahead (e.g. leap seconds): Unless you know that there isn't going to be a problem, a great deal of care needs to go into handling that. Best regards, Chí-Thanh Christopher Nguyễn signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Signed push & clock drift rejection
waltd...@waltdnes.org schrieb: And even if the system is behind time, it can cause problems. cronjobs running unexpectedly close to each other (or missed cronjobs in extreme cases). User sessions expiring early, etc. And even if there is only one second, and that is known well ahead (e.g. leap seconds): Unless you know that there isn't going to be a problem, a great deal of care needs to go into handling that. In that case, the dev machine should be a separate machine from the server. They don't even have to be separate physical machines. Do the dev work in a VM, and set the time in the VM just before doing the push. I am not talking about bircoph's dev machine, I am explaining why ntpd works the way it does. Which usually doesn't lead to problems as the drift will be corrected sooner or later. So there was never a problem nor reason for action in either case, until it was decided that 5 seconds is the maximum drift for a push to gentoo.git. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts
Michał Górny schrieb: Ensure that proper number of parameters is passed to each versionator function; die otherwise. This prevents the functions from proceeding with undefined behavior when mis-called. You are making what versionator.eclass accepts stricter. That it used to work when passed multiple versions may be unintentional, but I think you need to introduce a new eclass or new function names in this case. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts
Michał Górny schrieb: So, to summarize we shouldn't fix existing code because people did assume accepting invalid parameters was fine. You are changing the API of versionator.eclass, even if it was unintentional API. Then ebuilds will fail just the same No. Before, ebuilds would maybe display an upgrading message when they shouldn't, or vice versa. Now the eclass dies on them. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts
Ciaran McCreesh schrieb: On Sun, 24 Jul 2016 10:17:24 +0200 Chí-Thanh Christopher Nguyễn wrote: Then ebuilds will fail just the same No. Before, ebuilds would maybe display an upgrading message when they shouldn't, or vice versa. Now the eclass dies on them. This attitude that invisible failures (which don't get fixed, and which lead to occasional weirdness) are better than visible failures (which must be fixed) is an odd one... Postel has a lot to answer for. I would agree with you when it comes to upstreams' -Werror but I do realize that I am in the minority there. My point here is that this change will affect the behaviour of ebuilds using this eclass. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts
Michał Górny schrieb: You are changing the API of versionator.eclass, even if it was unintentional API. There is no such thing as 'unintentional API'. API is what's described. If you rely on internals, random undefined behaviors or whatever, it's not a part of the API. Well there is the API according to the docs, and then there is the API according to the implementation... Then ebuilds will fail just the same No. Before, ebuilds would maybe display an upgrading message when they shouldn't, or vice versa. Now the eclass dies on them. So what's the alternative? Design another eclass where ebuilds will fail just the same because people will ignore the more explicit requirement just the same as they do ignore the API? I don't know what is your problem here. The eclass needs not be designed again from the ground up. All ebuilds which are unaffected by bug 589444 can be switched to the new eclass/functions immediately. The others after they are changed no longer make the implicit assumption that REPLACING_VERSIONS contains only a single version. The problem is not 'there is a valid case to pass useless parameters to the function'. The problem is 'I make an invalid assumption about what will happen based on my limited knowledge which I believe is more correct than people who wrote package managers'. I don't say it is a correct use of versionator.eclass. I just say it has become (unintentionally) part of the API, and therefore is subject to the rules about changing APIs in eclasses. I agree that relying on unintentional or undocumented API is bad and needs to be addressed. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts
Chí-Thanh Christopher Nguyễn schrieb: I don't say it is a correct use of versionator.eclass. I just say it has become (unintentionally) part of the API, and therefore is subject to the rules about changing APIs in eclasses. Actually, after reading those rules[1] again, it would be enough to fix all ebuilds in the tree and wait 30 days to be in compliance with eclass policy. So from my side I will no longer object to your proposed change, provided these conditions are met. Best regards, Chí-Thanh Christopher Nguyễn [1] https://devmanual.gentoo.org/eclass-writing/
