Re: [arch-dev-public] Orphaned packages from arcanis
On Sat, 2020-11-21 at 20:09 +0100, Morten Linderud via arch-dev-public wrote: > scala Adopted. -- Regards, Felix Yan signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] News draft: nvidia 455.28 is incompatible with linux >= 5.9
On Mon, 2020-10-19 at 23:01 +0200, Sven-Hendrik Haase via arch-dev- public wrote: > nvidia is currently partially incompatible with linux >= 5.9 [1][2]. > While graphics should work fine, CUDA and OpenCL are broken. Users > who've already upgraded and need those features are advised to switch > to > the linux-lts kernel for the time being. > > [1] > https://forums.developer.nvidia.com/t/nvidia-driver-not-yet-supported-for-linux-kernel-5-9/157263 > [2] https://bugs.archlinux.org/task/68312 Looks good to me. Hope nvidia will fix this sooner. -- Regards, Felix Yan signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] Packages up for adoption
On Wed, 2020-10-14 at 14:39 -0300, Giancarlo Razzolini via arch-dev- public wrote: > Em outubro 14, 2020 14:31 Bartłomiej Piotrowski via arch-dev-public > escreveu: > > Hi, > > > > Due to lack of free time, I've orphaned some packages I don't want > > to > > think about: > > > > bash > > bash-completion > > chrome-gnome-shell > > expat > > gdbm > > libcap > > libffi > > libunistring > > libusb > > networkmanager-fortisslvpn > > ncurses > > openfortivpn > > readline > > texinfo > > wpa_supplicant > > > > I've also disowned some packages I've been co-maintaining with > > other > > packagers but that's not so interesting. > > > > Bart > > > > Hi, > > I have adopted both bash and bash-completion and I'm also going to > adopt > readline. But I think these packages should have at least one co- > maintainer, > given their importance, so, co-maintain away, please. Adopted expat, libcap, libffi, libunistring, libusb, ncurses, wpa_supplicant and co-maintained bash, bash-completion, readline. Please feel free to co-maintain, too. -- Regards, Felix Yan signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages
I noticed that xorg-fonts-alias and xorg-fonts-encodings were still kept: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/ttf-indic-otf=104e24f18c7138d6a0a260a86465375682d4edfa If they should be removed as well, perhaps this could also be mentioned in the TODO? -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Proposal to remove PyGTK
On 3/17/20 7:15 AM, Eli Schwartz wrote: > - zbar > > Felix, the zbar package currently builds python2-zbar bindings using > pygtk. These aren't used by any package, and upstream documents support > for python3 and GObject Introspection bindings usable via > python2/python3: https://github.com/mchehab/zbar#python-widgets > > Please drop the unused pygtk bindings and build python3/gobject ones > instead. :D Thanks for the info. I have enabled gir for zbar-gtk and switched the binding to python 3 in 0.23-3. > - python2-twisted > > ported to gobject for gtk3, which should work fine in python3, maybe we > can just drop this checkdepends/optdepends and disable those tests to > not advertise its existence? Done in 19.10.0-3. -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
[arch-dev-public] deepin-kwin removed from [community-testing]
There are multiple major issues with the new version 5.0.0, and upstream doesn't yet have figured them out after a month. Currently it would be better to stick with 0.1.0. -- Regards, Felix Yan
[arch-dev-public] Dropping dingo from [community]
Hi All, I have removed dingo the Google DNS-over-HTTPS client from [community]. The upstream is inactive for years and supports Google only. I would recommend dns-over-https [1] instead which has support for multiple protocols and is still actively maintained. Note that Google announced [2] yesterday that they recommend to use the newer IETF protocol (at a new endpoint), which is also the protocol of all other major DoH providers (CloudFlare, Quad9, etc). [1] https://www.archlinux.org/packages/community/x86_64/dns-over-https/ [2] https://security.googleblog.com/2019/06/google-public-dns-over-https-doh.html -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
[arch-dev-public] nodejs 12 removed from [community-testing]
Binary packages do not build as nan doesn't support the new version yet [1]. nodejs 11.15.0 has been pushed to [community] instead. [1] https://github.com/nodejs/nan/issues/849 -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Mongodb and SSPL
On 2019/1/16 下午10:35, Allan McRae via arch-dev-public wrote: > Drop the package. I have dropped the two packages (mongodb and wiredtiger) to the AUR, since I did not use MongoDB for quite some time anyway. Thanks for all the input here. -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] /r/linux AMA
On 8/10/18 12:41 AM, Morten Linderud via arch-dev-public wrote: > If you are interested participating please reply to the list with the > following > information: > > * Reddit username. > * What you do. > * What Monday fits for you? * /u/felixonmars * Python, Haskell, Nodejs, Qt, KDE, DDE, Chinese i18n, VPN/Proxies, Wine, and some others. * Most Mondays Hope I'm not too late! -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Improving the package guidelines
On 06/29/2018 05:06 AM, Eli Schwartz via arch-dev-public wrote: > Also I'd like to discuss what seems to me a common misconception in > python packaging -- specifically, the use of cp -r source source-py2 and > building both separately. > > Best I can tell, this is primarily motivated by fear of py2/py3 specific > bytecode being generated, but the thing is, this bytecode is all > generated during package() inside of "$pkgdir" during the install step. > You can check the contents of the build/ directory... it just copies the > .py files and builds any ext_modules. The main reason behind this (or why I started doing this) was sometimes the tests run inside the sources tree made both versions' .pyc files into the tree itself, and finally end up in the package. I had this problem for several times and end up having the separated build directories as template for new packages. This seems not the case for most packages now, so I agree that it should be avoided. -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [core] / [extra] cleanup
On 06/23/2018 10:37 PM, Doug Newgard via arch-dev-public wrote: >>>> *Remove* >>>> - pcmciautils - Ancient technology >>> >>> Felix moved it to [extra], not sure why? So removed it from [core] >> >> Was a mistake when trying to rebuild for the BUILDINFO todo. Sorry for that. >> > > And two and a half weeks later and it's still there? I'm still waiting for a conclusion of original proposal, the other packages are still not removed either. -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [core] / [extra] cleanup
On 06/05/2018 04:01 AM, Jelle van der Waa wrote: > On 02/06/18 17:06, Jelle van der Waa wrote: >> Looking at the packages in the BUILDINFO rebuild list, I've found some >> packages which are so old that they might not longer suit [core] or our >> repos in general. So I'd like to propose that we either move or remove >> the following packages: >> >> *Remove* >> - pcmciautils - Ancient technology > > Felix moved it to [extra], not sure why? So removed it from [core] Was a mistake when trying to rebuild for the BUILDINFO todo. Sorry for that. -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Unit tests for python packages
For testing with not installed python modules, invoking setup.py commands are often preferable and addresses both PYTHONPATH and 2to3. For nosetests: Use "python setup.py nosetests" instead. For pytest: Use "python setup.py pytest" instead. Note that "python-pytest-runner" needs to be in checkdepends. There are additional common hacks if the tests need to invoke an entry points or requires the versioned distribution object. Either: 1) Installing it in a temporary place and hack PYTHONPATH/PATH. 2) Create a sitecustomize.py and add the build dir to site. (See python2-faulthandler for an example) And finally if above still didn't solve it, you may choose to skip the problematic part of the tests or use "heavier" workarounds like a venv. -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Orphaned packages
On 08/20/2017 09:13 PM, Sébastien Luttringer wrote: > - laptop-detect > - python-docutils Adopted these two. -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Packages for adoption
On 04/18/2017 02:53 PM, Bartłomiej Piotrowski wrote: > git-review Adopted this one as I use it regularly. -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Away on business next week
On 02/23/2017 11:53 PM, Dave Reisner wrote: > - core/util-linux: maintenance release, 2.29.2. Don't forget to bump > multilib/lib32-util-linux if you touch this. Bumped for CVE-2017-2616. -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Phasing out gstreamer0.10
On 01/19/2017 09:18 AM, Balló György via arch-dev-public wrote: > │ │ ├─deepin-music Bumped to new version, which doesn't require gstreamer anymore. > │ │ ├─morituri Dropped. > │ │ ├─boinc Should be fixed when wxgtk supports gst-1.0. -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
[arch-dev-public] Dropping nvidia-304xx series
I have recently disowned nvidia-304xx as I don't own relevant hardware anymore. Given that it's now an orphan and blocks xorg-server 1.19, I'm planning to move it to AUR in a few days, if nobody else wants to pick it up. -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Long out of date packages
On 10/20/2016 08:25 PM, Florian Pritz via arch-dev-public wrote: > fyan: > community/any/soundfont-fluid > multilib/x86_64/lib32-libxml2 > community/x86_64/reaver > community/any/scrapy > extra/x86_64/xapian-core > multilib/x86_64/lib32-nss > community/x86_64/wiznote > community/x86_64/git-annex > community/any/python2-pydot > multilib/x86_64/lib32-glib2 > multilib/x86_64/lib32-libpng > multilib/x86_64/lib32-gdk-pixbuf2 > community/x86_64/python2-matplotlib > community/x86_64/python-matplotlib Except for some lib32-foo (still working on), I have either bumped or re-flagged with a reason. Sorry for the delay. -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
[arch-dev-public] GHC 8.0.1 entering [community-testing]
Hi, The Gkasgow Haskell Compiler 8.0.1 is entering [community-testing] with all haskell-* packages in the official repos rebuilt except the following two: - idris - hedgewars Since GHC is only a makedepend, they should still work as before. The TODO will remain open until they are fixed eventually. You may have installed some extra modules from the AUR or with cabal-install, please rebuild/reinstall them as needed. We have switched to use hooks for doc index updates and module (un)registering. This should speed up haskell package operations significantly. Please report any issues you encounter. -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Hooks rebuild #1
On 04/28/2016 12:28 PM, keenerd wrote: > Namcap 3.2.7 is released. It removes the old .install warnings and > adds a new one if the .install does anything covered by a hook. > > All it needs is a dev to update the package. Updated. Tested with some of my rebuilds and it works nicely. Thanks! -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] ANNOUNCEMENT: pacman hooks
On 03/23/2016 11:30 AM, Allan McRae wrote: > The release of pacman-5.0 bought support for transactional hooks. Spotted a typo: bought -> brought The rest looks good to me. -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] TU Resignation
On 01/22/2016 05:34 AM, Daniel Wallace wrote: > Hey all, > > Over the last two months I have been considering this, and finally came to > the decision that it was time to resign as a Trusted User. > > I haven't been able to dedicated a meaningful amount of time to Arch Linux > for some time now, and think it is just time to give it up. See you around and thanks for all your contributions to Arch :) -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] PHP 7
On 12/30/2015 05:49 AM, Ike Devolder wrote: > The legacy driver will not gain support for php7 so we must add > php-mongodb (the new version which is not api compatible with the legacy > driver). > > So I would add the php-mongodb package that replaces the current > php-mongo package with an extra note that its api is not compatible. I have uploaded the new php-mongodb package, some upstream fixes for PHP7 after the latest release were included. Feel free to adopt it :) -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Orphaning dhcp, looking for a maintainer
On 09/11/2015 01:14 PM, Daniel Isenmann wrote: > Thanks for adopting it. I have assigned 3 more bugs to you which was > assigned to me in flyspray. Nothing big I think, but I had not the time to > fix them. Ah, looks like I missed the bugs for dhclient. Thanks! -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Orphaning dhcp, looking for a maintainer
On 09/10/2015 01:26 AM, Daniel Isenmann wrote: > Hi, > > anyone interested in dhcp/dhclient package in [extra] repository? I don't > use it anymore and its used by archboot and some other network package from > [extra]. > > I have orphaned it already, so feel free to adopt it. Adopted and updated, also addressed the only one open issue on flyspray. Please let me know if anything else is needed, thanks. -- Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] linux 4.0 in [testing]
On Monday, April 13, 2015 09:25:28 Tobias Powalowski wrote: - nvidia-304xx Fixed in [testing]. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] linux 3.19 in [testing]
On Monday, February 09, 2015 08:21:30 Tobias Powalowski wrote: - nvidia-304xx Fixed and pushed to [testing]. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] Cleaning [extra]
On Monday, January 19, 2015 19:11:03 Andrea Scarpino wrote: * tsocks (needed by none) Adopted. +1 for dropping the rest if no one is interested. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
[arch-dev-public] Moving libidn to [core]
Hi, Internationalized Domain Names are gaining more interest these days, and curl has the support for libidn for quite some years. I would like to have IDN support enabled on curl, which means libidn will be moved into [core] to satisfy the dependency. A task [1] was opened on the bug tracker, too. If no one raises objection in a few days, I'll move libidn to [core], thanks. [1] https://bugs.archlinux.org/task/42352 Regards, Felix Yan signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Rethinking our CA certificate setup
On Sunday, August 24, 2014 11:47:56 Jan Alexander Steffens wrote:
The current issues are:
- Mozilla NSS uses its own root store and not /etc/ssl/certs
- ca-certificates ships outdated Mozilla roots
- Shipping additional roots outside ca-certificates is difficult,
requiring patching /etc/ca-certificates.conf
A quick search shows that we have more packages shipping their own (maybe
outdated) CA certificates copy in package. Since we are already on the topic
about the inconsistency between nss and ca-certificates, I would like to also
bring these up. I'd think it a good idea to make them use /etc/ssl/certs too.
(Maybe not the ones in examples? Thoughts?)
perl-mozilla-ca ships usr/share/perl5/vendor_perl/Mozilla/CA/cacert.pem
- serves as the reference for some other projects, for example spamassassin,
gnucash, bugzilla, shutter...
- There was a discussion around this package in Debian [1], which resulted in
not adding this package at all.
python{,2}-pip ship usr/lib/python{3.4,2.7}/site-
packages/pip/_vendor/requests/cacert.pem
- We already have a patch for python{,2}-requests to use ca-certificates [2],
but the embedded version in pip didn't use it.
python{,2}-certifi ship usr/lib/python{3.4,2.7}/site-
packages/certifi/cacert.pem
- only affects tornado for now, consider removing the package and patching
tornado?
vagrant ships opt/vagrant/embedded/cacert.pem
- looks like it has an option to use system-wide ca-certificates [3], would we
patch it or simply remove the embedded version?
goagent ships usr/share/goagent/local/cacert.pem
- looks like a simple patching.
And some others I didn't look further into:
- opensips ships etc/opensips/tls/rootCA/cacert.pem
- owncloud ships usr/share/webapps/owncloud/apps/files_external/3rdparty/aws-
sdk-php/Guzzle/Http/Resources/cacert.pem,
usr/share/webapps/owncloud/apps/files_external/3rdparty/google-api-php-
client/src/io/cacerts.pem, ...
- swi-prolog ships
usr/lib/swipl-6.6.5/doc/packages/examples/ssl/etc/demoCA/cacert.pem
- erlang/erlang-nox ship
usr/lib/erlang/lib/ssl-5.3.5/examples/certs/etc/client/cacerts.pem,
usr/lib/erlang/lib/ssl-5.3.5/examples/certs/etc/server/cacerts.pem
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698101
[2]
https://projects.archlinux.org/svntogit/community.git/tree/trunk/certs.patch?h=packages/python-requests
[3]
https://www.digitalocean.com/community/tutorials/how-to-use-digitalocean-as-your-provider-in-vagrant-on-an-ubuntu-12-10-vps
Regards,
Felix Yan
signature.asc
Description: This is a digitally signed message part.
[arch-dev-public] Dropping libgee06 from [extra]
Hi, Since libskk, the last reverse-dependency of libgee06 in our repos, has adopted to the libgee-0.8 API with an upstream patch, there's no package in the repos depending on this legacy library anymore. If no objection were raised, I'm going to drop libgee06 directly from [extra] to [unsupported], since some packages in the AUR might still need it for some time. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] Busy until mid-July, maybe?
On Thursday, July 03, 2014 11:30:48 Thomas Bächler wrote: * cryptsetup (flagged 29.06.) - easy version bump * intel-ucode (flagged 26.06.) - easy version bump, finding the correct download link requires a few minutes though Both bumped and pushed to [testing]. * lvm2 (flagged 23.06.) - easy version bump (hopefully, sometimes it breaks) lvm2-make-sockets-static.patch has some conflicts, I'll look into it later if no one else is interested (I don't use LVM myself, so I may not be able to test it). * v4l-utils / lib32-v4l-utils (flagged 01.07.) - easy version bump. Bumped and pushed to [testing]/[multilib-testing]. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] Busy until mid-July, maybe?
On Thursday, July 03, 2014 13:26:20 Thomas Bächler wrote: Am 03.07.2014 12:09, schrieb Felix Yan: * lvm2 (flagged 23.06.) - easy version bump (hopefully, sometimes it breaks) lvm2-make-sockets-static.patch has some conflicts, I'll look into it later if no one else is interested (I don't use LVM myself, so I may not be able to test it). It's probably trivial to fix. The patch simply removes the [Install] sections from the .socket files and the PKGBUILD enables them unconditionally. lvm2_lvmetad_systemd_red_hat.socket.in has WantedBy=sysinit.target instead of WantedBy=sockets.target (which is in the patch). dm_event_systemd_red_hat.socket.in has added RemoveOnStop=true That's the two conflicts. Let me know if you think it is okay to push :) Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] [Draft] - News announcement for GHC 7.8.2
On Thursday, May 01, 2014 10:51:57 Florian Pritz wrote: you should also increase the pkgrel There are some packages depending explicitly on the specific pkgrel (7.8.2-2), such as: https://www.archlinux.org/packages/community-testing/i686/haskell-haskeline/ I'm not sure if adding a provides item will fix this. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] [Draft] - News announcement for GHC 7.8.2
On Thursday, May 01, 2014 19:05:09 Gaetan Bisson wrote: [2014-05-01 16:55:49 +0800] Felix Yan: There are some packages depending explicitly on the specific pkgrel (7.8.2-2), such as: https://www.archlinux.org/packages/community-testing/i686/haskell-haskeli ne/ I'm not sure if adding a provides item will fix this. Why not? Then it's the way to go :P I didn't do this before so I was not very sure... Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] Inactivity for 1-2 weeks
On Wednesday, April 09, 2014 17:56:34 Rashif Ray Rahman wrote: Hey folks My laptop broke down several days ago and I thought I might be able to get back to my system one way or another, but it has proven to be difficult. I will not be able to package for at least another week. I will read e-mails. Eric (4 and 5) needs updated, and they're both trouble-free. I also have 3 non-critical open tasks for a while in the bugtracker which I expect to close as soon as I can verify a number of things. Other than that, all is well. I just updated both Erics. FYI: There's an error during start-up, but doesn't seem to affect any functionality. The same error also exists in earlier version, though. 'UserInterface' object has no attribute '_UserInterface__inVersionCheck' File /usr/lib/python3.4/site-packages/eric5/UI/UserInterface.py, line 2851, in __showHelpMenu self.checkUpdateAct.setEnabled(not self.__inVersionCheck) Anyway, good luck with a new laptop (or PC) :) Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] Kingsoft Office License
On Tuesday, April 01, 2014 14:14:35 Lukas Jirkovsky wrote: It looks quite OK to me, so I'm supporting this. They have quite good support for the proprietary formats. Bonus points for that they are willing to communicate and fix the problems, which isn't that common with proprietary software. Thank you :) As for the PRC export law part, I'm still trying to get some sort of clarification from their lawyers. Once this got confirmed, and other part of the license also looks OK to everyone here too, they'll publish the license, and make their next release (within this month) to comply with the license, so we can actually distribute the package. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] Kingsoft Office License
On Tuesday, March 18, 2014 21:31:50 Allan McRae wrote: - Distributed as a deb file - Requires libpng12 (why is that in [community]...) - I don't trust licenses with multiple obvious typos - Is linking at runtime integrating with other software - Are dontations to Arch counted as us making a profit from having it in our repos? - The terms indicate we are legally responsible to stop (e.g.) Manjaro redistributing this. - we have to comply with PRC export laws and restrict distribution by country Overall, that is a no from me. It is a deb, so packaging is no burden for its users. Allan Hi, I've got an updated license from Kingsoft, most of the problems should have been addressed (except for the PRC export laws problem, which doesn't seem to be avoidable, but should not be a problem if I read the laws correctly...) I've updated the package in AUR to use their general-purpose tarball (.tar.xz file). And as for libpng12, they would provide it into the tarball if we were going to rip it out from [community] and [multilib], so the package is always self-contained and won't introduce any new dependency. Link to the updated version: https://paste.xinu.at/cDX/ Disclaimer: I'm not working for Kingsoft in any form, or getting anything from them as return for the inclusion. The idea to add the office suite to our repos was suggested by someone else, and I like the idea because it fills in the blank for good MSO compatibility and good Chinese support. For reference only: http://www.techrepublic.com/blog/10-things/10-reasons-why-kingsoft-office-is-better-than-the-competition/ (I don't mean that LibreOffice is bad, both the two tools can have their job done nicely. I don't want to start a war =P) At the end, I'll respect your decision if you still think this idea not acceptable. I'm sorry for taking up so much time of yours. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
[arch-dev-public] nvidia 334.21-3 / nvidia-lts 334.21-4 pulled from [testing]
Hi all, The nvidia-modprobe binary was provided in the nvidia / nvidia-lts packages, but this doesn't work well because the two packages should not be prevented from installing together. To fix this, I've pulled the two packages from [testing], and will upload a new nvidia-utils package containing the binary to [testing]. FS#39203 and FS#39636 will be closed if the new package fixed everything. (A setuid binary is not good, but no trivial workaround was found) If you still have one of the packages installed, please revert them to the corresponding version in [extra]. If you failed to do so, a file conflict error is expected after the new nvidia-utils get pushed. Sorry for the inconvenience! Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] nvidia 334.21-3 / nvidia-lts 334.21-4 pulled from [testing]
On Thursday, March 27, 2014 16:15:21 Thomas Bächler wrote: Am 27.03.2014 16:02, schrieb Felix Yan: Hi all, The nvidia-modprobe binary was provided in the nvidia / nvidia-lts packages, but this doesn't work well because the two packages should not be prevented from installing together. To fix this, I've pulled the two packages from [testing], and will upload a new nvidia-utils package containing the binary to [testing]. FS#39203 and FS#39636 will be closed if the new package fixed everything. (A setuid binary is not good, but no trivial workaround was found) Seriously, that is a crappy solution. If nvidia would properly register its devices with linux, these devices could be created dynamically. It's really up to nvidia to fix their kernel module. (By the way, the /dev/nvidia* devices do not even generate proper uevents and thus cannot be caught by udev or systemd. I wish they would stop relying on a closed-source kernel driver with debatable quality.) Yeah, I totally agree with you. I played a lot with udev but only produced a hacky (and certainly wrong except works) udev rule. I don't think that one better than the upstream-provided crappy binary. I've also asked upstream for help, but still didn't get a reply. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] [RFC] Add ARM to archlinux.org
On Monday, March 24, 2014 21:15:06 keenerd wrote: On 3/24/14, Sébastien Luttringer se...@seblu.net wrote: - add AUR This doesn't make sense. We already have a git repo which does a far better job of compressing the deltas between versions of text files. Keeping the git backend or not, it makes sense to me to move this from the build server (pkgbuild.com) to the archive server (something like archive.archlinux.org). Git is an awesome SCM, but it was not think to backup stuff, especially with a big directory tree. My feeling trying to find a previous version of a PKGBUILD with aur-mirror.git is: - a very long time to fetch the repository - a space based dig into changelog to find the right commit for my date - a long checkout to get the tree at this commit Having something with faster access and in a similar hierarchy may have use cases. The Rollback Machine has a convenient CLI wrapper to access packages. Have you tried using the Rollback Machine with just a browser? It is nearly impossible. The CLI wrapper makes it much nicer. Just want to add a side note here, that the two most popular CLI wrappers (downgrade and downgrader in AUR) are using the web service hosted by Arch Linux Chinese Community (archlinuxcn). We are also hosting the service right at the day when the old A.R.M was down. I think we're implementing the services in two aspects: Sébastien is providing daily-based folders, which is great to rollback or freeze a system at some point, while archlinuxcn is providing API for CLI wrappers to query packages, which makes more sense for users using the CLI helpers. About the server resources: 83G ./community 70G ./packages There were some users from the forums gave us their old backups, so we have oldest package back to 2007 here, while packages (not including [testing]) from 2011 are generally available for search download. For example, a search for kernel26 returns every version down to 2.6.38.3, which was released on 2011-04-17 according to our svn log. So the resource consumption doesn't look scary at all :) I don't actually have a preference on making the service official or not, the current domain repo- arm.archlinuxcn.org looks OK to me as well. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
[arch-dev-public] Kingsoft Office License
to use the Founder Fonts of the “Product” in office applications (i.e. use the Founder Fonts only in the “Product” for merely screen display and printing) when they get the legal license of the “Product” according to Kingsoft EULA. If end users need to use Founder Fonts beyond the authorized scope in the above- mentioned term, end users shall negotiate with Founder, copyright owner of Fonder Fonts, separately and get the license from Founder. Any violation of intellectual property right of Founder Fonts by end users has no concern with Kingsoft. Kingsoft thereby shall not bear any responsibility for guarantee and joint responsibility. End users shall bear full legal responsibility for Founder and other right owners of Founder Fonts independently and directly. Admission You acknowledge that you have now read and understood the Agreement and have expressly agreed to be bound by all the terms and conditions of it. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] Kingsoft Office License
Thanks a lot for the feedback. I'm going to give some quick answers to what I have in mind: On Tuesday, March 18, 2014 21:31:50 Allan McRae wrote: - Distributed as a deb file - Requires libpng12 (why is that in [community]...) I've mentioned this to them just one day ago. Actually the PKGBUILD will be re-written once the issues on license were solved. I'll also mention particularly about libpng12, to see if a specific version with latest libpng can be made available. - I don't trust licenses with multiple obvious typos - Is linking at runtime integrating with other software - Are dontations to Arch counted as us making a profit from having it in our repos? - The terms indicate we are legally responsible to stop (e.g.) Manjaro redistributing this. I'll forward these questions/problems to them. - we have to comply with PRC export laws and restrict distribution by country Unfortunately I don't think they can do much about the export laws - But after a quick look, I don't see any more regional limitations in the laws than the restrictions by UN (I may be wrong since I'm not a lawyer, though). And currently skype, steam and flashplugin in our repos are also subjected to the U.S. export laws. Overall, that is a no from me. It is a deb, so packaging is no burden for its users. It would still be nicer to have popular software in our repos - but of course they have to meet our essential requirements. Only after the licensing issues been addressed, I'd like to ask again about the inclusion. Thanks again! Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] libssh - X2goclient
On Saturday, March 15, 2014 08:29:42 Andrea Scarpino wrote: On Tue 21, January 11:20:07 Andreas Radke wrote: There is a libssh 0.6.0 release update pending for us. I'd like to ask you stay with 0.5.x branch for a bit longer. Any news here? KDE 4.13 requires libssh = 0.6.0 [1] [1] https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/4007 6246be995cc006a12f8afc2c18cfacbf0604 May be relevant: https://bugzilla.redhat.com/show_bug.cgi?id=1053305 Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] clearing the [testing] repo
On Wednesday, February 12, 2014 16:34:46 Allan McRae wrote: python (why?) I guess Ángel updated it last night but didn't have time to test it. Anyway it works for me, signed off x86_64. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] drift between repo packages and ABS
cgminer - makedepends I was using CARCH hacks to make i686 and x86_64 having different makedepends, maybe this was the cause. Anyway, turns out the only one additional makedepend (yasm) was not needed anymore since some versions ago, so removed that line. Now it should work :) Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] Orphans
On Friday, October 04, 2013 02:41:53 Rashif Ray Rahman wrote: On 2 October 2013 23:02, Alexander Rødseth rods...@gmail.com wrote: Hi, The wiki page has been up for a while now (thanks Balló György) and activity seems to have stopped in terms of adoptions. I'll start moving over the packages that are on the list shortly: https://wiki.archlinux.org/index.php/Midyear_Cleanup/2013#Packages_that_will_be_dropped New TUs that want to learn how to move packages from [community] to AUR: feel free to join in on the moving process. Just ask on IRC if you are stuck or want to know how it can be done. The following orphans should (IMO) be adopted by the people that consider them too important to be moved to AUR. Please adopt them now: ... wvstreams This one's a dep of wvdial. I've adopted it (thanks Balló György). Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] Starting work on TeXLive 2013
On Tuesday, July 02, 2013 09:15:06 Rémy Oudompheng wrote: The packages are ready but they will tend to install /etc/texmf files as .pacnew instead of replacing the old ones. When it happens fmtutil will not unhappy and the things will be unusable until the user overwrites the old files with the pacnews then re-runs fmtutil --all as root. What do you advise? Leave the behaviour as is and write instructions in the news page? Forcibly overwriting old files? I would prefer just echo these notes in .install. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] BIND10? No, thanks.
On Wednesday, March 20, 2013 11:07:34 Ionut Biru wrote: On 03/20/2013 11:05 AM, Thomas Bächler wrote: Am 20.03.2013 04:50, schrieb Gaetan Bisson: Consequently, official packages using [dnsutils](https://www.archlinux.org/packages/core/x86_64/dnsutils/) were migrated to [ldns](https://www.archlinux.org/packages/core/x86_64/ldns/), a much nicer library which provides a `drill` command that replaces `dig`, `nslookup`, and `host`. Wait, I think I misunderstood your original email. I was under the impression that ldns provides drop-in replacements for the commands. This is not the case and thus I will have no 'host' command anymore. Not that I particularly rely on dnsutils, but I imagine *everyone* expects the 'host' command to exist. host and dig are tools that I use every day and they are the standard. i don't see why they should be dropped just because bind (as in the server) doesn't suite you well now. why cannot we keep the tools? I'd +1 for keeping dnsutils 9 as is in the repos for now, if my vote counts :P Felix Yan Twitter: @felixonmars Wiki: http://felixc.at signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] Please provide Info for my talk!
On Wednesday, February 20, 2013 00:15:40 Allan McRae wrote: Hi, I am giving an hour long talk at the end of next week about Arch, how it works and why we are successful. I will focus on stuff I am involved with (i.e. pacman...), but will give examples of things like how we decided on systemd, the new installer, etc. (other suggestions welcome) One thing I would like to talk about is our interaction with upstream. I know a few of us have commit access to various upstream projects, or have regularly contributed patches, or have upstream bug tracker privileges etc. Could people let me know about these things so I can make a summary. I am always helping Chinese and Taiwanese upstream follow the bugs on our tracker (librime, fcitx, etc), but not so much patches yet (got some pull-requests accepted on pidgin-lwqq upstream during these months), but wrote some (really) small tools like ydcv, fcitx-tsundere, etc. I am also admin of Archlinux CN community (archlinuxcn.org), and active on #archlinux-cn IRC and Baidu Tieba (a large active Chinese community of Baidu Inc.), always posting there some newly introduced sweets in our repos and getting some user feedbacks (or sometimes bug reports). Since Chinese users sometimes getting trouble in language when trying to report bugs upstream, sometimes I did it for them (though my English is poor too :P). That's all I could say about interaction with upstream =) Something else I was specifically asked to cover is future plans for Arch. Does anyone have things beyond updating packages they want to do? In my dreams: * Kernel versioning, to make Arch the best server os. * Splitted packages support in AUR. Oh wait, forget those trivial things. Let's say: * Official ARM support * Drop i686 support (yes!) Enjoy the trip :) Felix Yan Twitter: @felixonmars Wiki: http://felixc.at signature.asc Description: This is a digitally signed message part.
[arch-dev-public] Adopt extra/stardict
Hi, I'd like to adopt [extra]/stardict since I'm a user of it and it's an unneeded orphan in [extra], could anyone move it for me? Thanks! -- Felix Yan Twitter: @felixonmars Wiki: http://felixc.at signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] Anyone want mongodb?
On 11/05/2012 07:13 AM, Sven-Hendrik Haase wrote: I don't use mongodb, it keeps breaking and upstream is nuts. Anyone want this ungodly package? Otherwise I'll drop it into AUR in a few. Hi, I use mongodb at everyday work, but not so confident to deal with all its naughty nuts. If no one else is going to take it in a few, I'll adopt it. Felix Yan signature.asc Description: OpenPGP digital signature
